ข้อกำหนดเบื้องต้นของแผนภูมิ Helm

แผนภูมิ Helm ของ Tableau Server - ข้อกำหนดเบื้องต้น

สำคัญ: เอกสารนี้จัดทำขึ้นสำหรับผู้มีความรู้เกี่ยวกับ Helm และแผนภูมิ Helm และไม่ได้ยกตัวอย่างที่ละเอียดตามแบบแผน เอกสารได้รับการออกแบบมาสำหรับลูกค้าที่คุ้นเคยกับทั้ง Tableau Server และ Helm และแผนภูมิ Helm

หัวข้อนี้อธิบายข้อกำหนดเบื้องต้นที่จำเป็นในการใช้แผนภูมิ Helm สำหรับการปรับใช้ Tableau Server

การดาวน์โหลดและการกระจายแผนภูมิ Helm

แผนภูมิ Helm จะถูกส่งมอบโดยเป็นส่วนหนึ่งของเครื่องมือการตั้งค่า Tableau Server in a Container (tableau-server-container-setup-tool-<version>.tar.gz) และสามารถดาวน์โหลดได้จากหน้าการดาวน์โหลด Tableau Server

หลังจากแยกข้อมูลแล้ว ไฟล์แผนภูมิ Helm ที่จำเป็นจะอยู่ในไดเรกทอรี helm/tableau

เครื่องมือที่จำเป็น

  • CLI kubectl ที่กำหนดค่าให้เข้าถึงคลัสเตอร์ Kubernetes ของคุณ
  • CLI helm เวอร์ชัน 3.x หรือใหม่กว่า
  • สิทธิ์เข้าถึงคลัสเตอร์ Kubernetes (1.19+)

ข้อกำหนดของคลัสเตอร์

  • อย่างน้อยหนึ่งโหนดที่มี RAM 16GB และ CPU 4 คอร์ (แนะนำ 8 คอร์)
  • StorageClass ที่กำหนดค่าไว้สำหรับการจัดสรร PersistentVolume แบบไดนามิก
  • ความสามารถในการสร้างบริการ LoadBalancer หรือทรัพยากรขาเข้า

ข้อมูลที่จำเป็น

ตรวจสอบให้แน่ใจว่าคุณมีสิ่งต่อไปนี้ก่อนที่จะเริ่มต้น:

  • คีย์ใบอนุญาต Tableau Server ของคุณ
  • username ผู้ดูแล TSM และ passwordสำหรับบัญชีเริ่มต้น
  • ชื่อโฮสต์ Tableau Server สำหรับการเข้าถึง

ข้อกำหนดเบื้องต้นของ Amazon Elastic Kubernetes Service (EKS)

efs-bootstrap StorageClass

ตามค่าเริ่มต้น efs-bootstrap ไม่ได้สร้างใน EKS สำหรับการแชร์ Bootstrap แบบหลายโหนด ให้สร้างก่อนการติดตั้ง Helm

สำหรับการปรับใช้แบบหลายโหนด ต้องจัดสรรพื้นที่เก็บข้อมูล Bootstrap ก่อนจึงจะสามารถกำหนดเวลาพ็อดได้ หาก StorageClass efs-bootstrap ของคุณไม่ได้จัดสรรโวลุ่ม EFS แบบไดนามิก คุณต้อง:

  • สร้าง Bootstrap PV แบบคงที่ล่วงหน้าและผูกเข้ากับ tableau-server-bootstrap

    หรือ

  • ตั้งค่า persistence.bootstrap.createPV: true และให้ valid persistence.bootstrap.pv.csi.volumeHandle (ID EFS จริง, fs-...)

หากไม่เสร็จสิ้น พ็อดจะยังคงอยู่ในสถานะรอดำเนินการโดยมี PVC ที่ไม่ได้ผูก

  1. ตรวจสอบให้แน่ใจว่าได้ติดตั้งไดรเวอร์ EFS CSI ในคลัสเตอร์ของคุณแล้ว

    kubectl get csidriver efs.csi.aws.com

    ออบเจ็กต์ CSIDriver สามารถมีอยู่ได้แม้ว่าจะไม่ได้ติดตั้งส่วนเสริมที่จัดการโดย EKS ยืนยันส่วนเสริมอย่างชัดเจน

    หากคุณได้รับข้อผิดพลาด ResourceNotFoundException (ไม่มีส่วนเสริม) หรือพ็อดที่ล้มเหลวในภายหลังโดยมีข้อผิดพลาดในการติดตั้ง เช่น driver name efs.csi.aws.com not found in the list of registered CSI driversให้ติดตั้งส่วนเสริม EKS และรอจนกว่าสถานะจะเป็น ACTIVE จากนั้นตรวจสอบพ็อดปลั๊กอินของโหนด

    ซึ่งจำเป็นเนื่องจาก Bootstrap แบบหลายโหนดใช้โวลุ่มที่สนับสนุนโดย EFS (ReadWriteMany) หากไม่มีปลั๊กอินโหนด EFS CSI บนโหนดเพิ่มเติม Bootstrap PVC จะสามารถผูกได้ แต่การติดตั้งจะล้มเหลวและพ็อดจะอยู่ในสถานะ Init/Pending

    หากการติดตั้ง EFS ล้มเหลวพร้อม:

      is not authorized to perform: elasticfilesystem:DescribeMountTargets

      หรือ

      Failed to resolve "fs-....efs.<region>.amazonaws.com"

    ให้ใช้วิธีการแก้ไขอย่างใดอย่างหนึ่งต่อไปนี้

    • การแก้ไข IAM ในบทบาทโหนด EKS (แนะนำ): ให้สิทธิ์การอ่าน EFS และ EC2 เพื่อให้เป้าหมายการติดตั้งและการสำรวจ AZ ทำงานได้ แก้ไขชื่อบทบาทอินสแตนซ์โหนดจากกลุ่มโหนดของคุณ:

      aws eks list-nodegroups --cluster-name <cluster-name>
      aws eks describe-nodegroup \
      --cluster-name <cluster-name> \
      --nodegroup-name <nodegroup-name> \
      --query "nodegroup.nodeRole" \
      --output text
    • ใช้ IAM **ชื่อบทบาท** (ส่วนสุดท้ายของ ARN) ใน attach-role-policy:

      aws iam attach-role-policy \
      --role-name <your-node-instance-role> \
      --policy-arn arn:aws:iam::aws:policy/AmazonElasticFileSystemClientReadWriteAccess
      aws iam attach-role-policy \
      --role-name <your-node-instance-role> \
      --policy-arn arn:aws:iam::aws:policy/AmazonEC2ReadOnlyAccess
      • สิทธิ์ทั่วไปที่เกี่ยวข้อง:

        • elasticfilesystem:DescribeMountTargets, 
          elasticfilesystem:DescribeFileSystems
        • ec2:DescribeAvailabilityZones (มักจะจำเป็นเมื่อ DescribeAvailabilityZones ปรากฏในข้อผิดพลาดในการติดตั้ง)

    • ติดตั้ง IP เป้าหมายอย่างชัดเจน: ตั้งค่า mounttargetip บนแอตทริบิวต์โวลุ่ม Bootstrap PV CSI เมื่อ DNS/การสำรวจถูกจำกัดในสภาพแวดล้อมของคุณ

      • ค่าของ Helm (เส้นทาง createPV: true):

        persistence:
        bootstrap:
        pv:
        csi:
        volumeAttributes:
        mounttargetip: "10.x.x.x"
      • เส้นทาง PV ด้วยตนเอง

        spec:
        csi:
        driver: efs.csi.aws.com
        volumeHandle: fs-xxxxxxxx
        volumeAttributes:
        mounttargetip: 10.x.x.x
  2. สร้าง StorageClass efs-bootstrap (ตัวอย่าง):

    apiVersion: storage.k8s.io/v1
    kind: StorageClass metadata:
    name: efs-bootstrap
    provisioner: efs.csi.aws.com
    reclaimPolicy: Retain
    volumeBindingMode: Immediate
    allowVolumeExpansion: true
  3. เลือกเส้นทางการจัดสรร Bootstrap (จำเป็น):

  • เส้นทางการจัดสรร EFS แบบไดนามิก:

    ใช้ StorageClass แบบไดนามิกของ EFS CSI ที่กำหนดค่าไว้สำหรับจุดเข้าใช้งาน (ตัวอย่างเช่น provisioningMode: efs-ap, fileSystemIdและพารามิเตอร์สิทธิ์/basePath ตามมาตรฐานแพลตฟอร์มของคุณ)

  • เส้นทาง PV แบบคงที่:

    สร้าง tableau-bootstrap-pv ด้วยตนเองด้วย csi.driver: efs.csi.aws.com และ csi.volumeHandle: fs-...

    จากนั้นตั้งค่า:

    • persistence.bootstrap.createPV: false

    • persistence.bootstrap.volumeName: tableau-bootstrap-pv

  • เส้นทาง PV แบบคงที่ที่สร้างโดย Helm:

    ตั้งค่า:

    • persistence.bootstrap.createPV: true

    • persistence.bootstrap.pv.csi.volumeHandle: fs-...

ข้อกำหนดเบื้องต้นที่ไม่ใช่ EKS

ReadWriteMany StorageClass

สำหรับคลัสเตอร์ที่ไม่ได้โฮสต์บน EKS (หรือหากไม่ได้ใช้ EFS) ข้อกำหนดที่สำคัญสำหรับการแชร์ Bootstrap แบบหลายโหนดคือการมี StorageClass ที่รองรับโหมดการเข้าถึง ReadWriteMany (RWX) สำหรับโวลุ่ม Bootstrap ซึ่งจำเป็นเนื่องจากต้องจัดสรรพื้นที่เก็บข้อมูล Bootstrap ก่อนจึงจะสามารถกำหนดเวลาพ็อดได้

แบ็กเอนด์ของพื้นที่เก็บข้อมูล RWX ที่โฮสต์ด้วยตนเองทั่วไปสำหรับ Kubernetes ได้แก่

  • NFS (พบบ่อยที่สุด ทดสอบง่ายที่สุด)

  • CephFS

  • Longhorn (หากติดตั้งไว้)

  • GlusterFS

  • NetApp/พื้นที่เก็บข้อมูลอื่นๆ ขององค์กร

คุณต้องตรวจสอบให้แน่ใจว่าได้ติดตั้งไดรเวอร์ CSI ที่สอดคล้องกันสำหรับแบ็กเอนด์ที่คุณเลือกแล้ว

หากต้องการกำหนดค่า Tableau Server ให้ใช้ RWX StorageClass ที่กำหนดเอง ให้อัปเดตค่า Helm ของคุณ (เช่น values-multinode.yaml) เพื่อตั้งค่า persistence.bootstrap.storageClass เป็นชื่อ StorageClass ของคุณ:

persistence:
  # ... other persistence settings ...

  # Bootstrap volume (required for multi-node)
  bootstrap:
    enabled: true
    storageClass: "my-rwx-storage" # <--- Replace with your StorageClass name
    accessMode: ReadWriteMany
    size: 1Gi
    createPV: false

แหล่งข้อมูลเพิ่มเติม