Container Service for Kubernetes:Konfigurasi yang Direkomendasikan untuk Arsitektur Ketersediaan Tinggi Kluster ACK

Panduan untuk Dokumen Ini

Topik ini ditujukan bagi pengembang dan administrator kluster yang menggunakan Container Service for Kubernetes. Dokumen ini memberikan rekomendasi umum untuk merencanakan dan membangun kluster ketersediaan tinggi. Konfigurasi aktual dapat bervariasi tergantung pada lingkungan kluster dan kebutuhan bisnis Anda. Anda dapat menggunakan konfigurasi HA yang disarankan untuk lapisan kontrol dan bidang data dalam topik ini sebagai referensi.

Arsitektur Contoh Kluster

Kluster ACK terdiri dari dua bagian utama: lapisan kontrol serta node reguler atau virtual.

• Lapisan kontrol kluster mengelola dan mengoordinasikan operasi kluster, seperti penjadwalan workload dan pemeliharaan status kluster. Sebagai contoh, pertimbangkan kluster ACK yang dikelola. Kluster ACK yang dikelola menggunakan arsitektur Kubernetes-on-Kubernetes untuk menghost komponen lapisan kontrol kluster Anda, seperti Kube API Server, etcd, dan Kube Scheduler.

• Node reguler atau virtual: Kluster ACK mendukung node reguler, yaitu instance ECS, dan node virtual. Node menjalankan workload aktual dan menyediakan sumber daya untuk menjalankan kontainer.

Secara default, kluster ACK menyediakan arsitektur penerapan kluster ketersediaan tinggi multi-zona (multi-AZ). Sebagai contoh, gambar berikut menunjukkan arsitektur kluster untuk kluster ACK yang dikelola.

Ketersediaan Tinggi Arsitektur Lapisan Kontrol

Untuk kluster ACK yang dikelola—seperti kluster ACK yang dikelola (Edisi Pro dan Edisi Dasar), kluster ACK Serverless (Edisi Pro dan Edisi Dasar), kluster ACK Edge, dan LINGJUN Clusters—ACK mengelola lapisan kontrol beserta komponen terkaitnya, seperti kube-apiserver, etcd, dan kube-scheduler.

• Wilayah multi-zona: Semua komponen yang dikelola menggunakan strategi penerapan seimbang multi-replika dan multi-AZ, sehingga kluster tetap menyediakan layanan meskipun satu zona atau node mengalami kegagalan.

• Wilayah zona tunggal: Semua komponen yang dikelola menggunakan strategi penerapan multi-replika dan multi-node, sehingga kluster tetap menyediakan layanan meskipun satu node mengalami kegagalan.

Secara spesifik, etcd memiliki setidaknya tiga replika, dan kube-apiserver memiliki setidaknya dua replika. Semua replika kube-apiserver mencapai konektivitas jaringan dengan VPC kluster melalui pemasangan Elastic Network Interfaces (ENI). Kubelet dan Kube Proxy pada node terhubung ke kube-apiserver melalui Classic Load Balancer (CLB) API Server atau ENI.

Semua komponen inti yang dikelola ACK dapat diskalakan secara elastis berdasarkan penggunaan sumber daya aktual, seperti penggunaan CPU dan memori. Fitur ini secara dinamis memenuhi kebutuhan sumber daya API Server dan memberikan jaminan Service-Level Agreement (SLA) yang stabil.

Selain arsitektur ketersediaan tinggi multi-zona default untuk lapisan kontrol kluster, Anda juga harus mengonfigurasi arsitektur ketersediaan tinggi untuk bidang data kluster. Ini mencakup Konfigurasi Ketersediaan Tinggi untuk Kelompok Node dan Node Virtual, Konfigurasi Ketersediaan Tinggi untuk Workload, Konfigurasi Ketersediaan Tinggi untuk Load Balancing, dan Konfigurasi Komponen yang Direkomendasikan.

Konfigurasi Ketersediaan Tinggi Kelompok Node dan Node Virtual

Kluster ACK mendukung node reguler (instance ECS) dan node virtual. Anda dapat mengelola node menggunakan kelompok node, sehingga memungkinkan pengelompokan node untuk operasi seperti peningkatan, penskalaan, dan O&M harian. Jika lalu lintas layanan Anda relatif stabil atau memiliki puncak dan lembah yang dapat diprediksi, kami merekomendasikan penggunaan instance ECS. Jika layanan Anda mengalami lonjakan instan yang tidak terduga, Anda dapat menggunakan node virtual untuk menangani trafik lonjakan tersebut dan mengurangi biaya komputasi. Untuk informasi lebih lanjut, lihat Kelompok node, Ikhtisar kelompok node terkelola, dan Node virtual.

Konfigurasi Ketersediaan Tinggi Kelompok Node

Anda dapat mengombinasikan penyesuaian otomatis node, set penyebaran, dan penerapan multi-zona dengan batasan penyebaran topologi penjadwalan Kubernetes. Pendekatan ini memastikan layanan memiliki sumber daya yang cukup dan terisolasi di berbagai domain kegagalan, sehingga tetap berjalan meskipun salah satu domain mengalami masalah. Hal ini mengurangi risiko titik kegagalan tunggal serta meningkatkan keandalan dan ketersediaan sistem secara keseluruhan.

Konfigurasikan Penyesuaian Otomatis Node

Setiap kelompok node didukung oleh grup Auto Scaling (ESS), yang mendukung penskalaan manual dan otomatis pada lapisan penjadwalan beban atau lapisan sumber daya kluster. Dengan demikian, Anda dapat menyesuaikan sumber daya komputasi elastis dengan biaya lebih rendah dan fleksibilitas lebih besar. Untuk informasi lebih lanjut tentang solusi autoscaling ACK, lihat Penyesuaian skala otomatis dan Aktifkan penyesuaian otomatis node.

Aktifkan Set Penyebaran

Set penyebaran adalah strategi yang mengontrol distribusi instance ECS dengan menyebarkannya di berbagai server fisik, sehingga mencegah beberapa instance gagal akibat kegagalan satu mesin fisik. Anda dapat menentukan set penyebaran untuk kelompok node guna memastikan instance ECS yang diskalakan tidak tersebar di mesin fisik yang sama. Konfigurasi afinitas memungkinkan aplikasi Anda memahami topologi node dasar dan tersebar merata di berbagai node, sehingga menjamin kemampuan pemulihan bencana dan ketersediaan tinggi aplikasi Anda. Untuk informasi lebih lanjut tentang cara mengaktifkan fitur set penyebaran, lihat Praktik terbaik untuk set penyebaran kelompok node.

Konfigurasikan Distribusi Multi-Zona

ACK mendukung kelompok node multi-zona. Saat membuat dan menjalankan kelompok node, Anda dapat memilih beberapa vSwitch dari zona berbeda. Saat mengonfigurasi Scaling Policy, pilih Distribution Balancing. Hal ini memungkinkan instance ECS tersebar merata di zona yang ditentukan dalam grup penskalaan, yang sesuai dengan beberapa vSwitch. Jika terjadi ketidakseimbangan sumber daya antar zona karena alasan seperti stok habis, Anda dapat melakukan operasi rebalance untuk menyeimbangkan distribusi sumber daya di seluruh zona. Untuk informasi lebih lanjut tentang cara mengonfigurasi kebijakan autoscaling, lihat Aktifkan penyesuaian otomatis node.

Aktifkan Topology Spread Constraints

Penyesuaian otomatis node, set penyebaran, dan distribusi multi-zona, dikombinasikan dengan batasan penyebaran topologi penjadwalan Kubernetes (Topology Spread Constraints), membantu mencapai tingkat isolasi domain kegagalan yang berbeda. Semua node dalam kelompok node ACK secara otomatis memiliki label terkait topologi yang ditambahkan, seperti kubernetes.io/hostname, topology.kubernetes.io/zone, dan topology.kubernetes.io/region. Anda dapat menggunakan topology spread constraints untuk mengontrol cara Pod didistribusikan di berbagai domain kegagalan, sehingga meningkatkan toleransi terhadap kegagalan infrastruktur dasar.

Untuk informasi lebih lanjut tentang cara menggunakan penjadwalan sadar topologi dalam kluster ACK, seperti mencoba ulang Pod di beberapa domain topologi atau menjadwalkan Pod ke instance ECS yang termasuk dalam set penyebaran latensi rendah yang sama, lihat Penjadwalan sadar topologi.

Konfigurasi Ketersediaan Tinggi Node Virtual

Anda dapat menggunakan node virtual ACK untuk menjadwalkan Pod secara cepat agar berjalan di Elastic Container Instance (ECI). Dengan ECI, Anda tidak perlu membeli dan mengelola server ECS dasar, sehingga dapat fokus pada aplikasi kontainer Anda daripada pemeliharaan infrastruktur dasar. Anda dapat membuat instance ECI sesuai kebutuhan dan hanya membayar sumber daya yang dikonfigurasi untuk kontainer Anda dengan model bayar sesuai penggunaan, ditagih per detik.

Namun, saat melakukan penskalaan horizontal layanan secara cepat untuk menangani lonjakan trafik atau meluncurkan banyak instance untuk pemrosesan tugas Job, Anda mungkin mengalami situasi seperti stok instance tidak mencukupi di zona tertentu atau kehabisan alamat IP di vSwitch yang ditentukan, yang dapat menyebabkan kegagalan pembuatan instance ECI. Fitur multi-zona kluster ACK Serverless membantu meningkatkan tingkat keberhasilan pembuatan instance ECI.

Anda dapat mengonfigurasi Profil ECI untuk node virtual dan menentukan vSwitch di berbagai zona untuk mencapai penerapan aplikasi multi-zona.

• ECI mendistribusikan permintaan pembuatan Pod di semua vSwitch untuk menyebarkan beban secara efektif.

• Jika Pod tidak dapat dibuat karena stok tidak mencukupi untuk vSwitch tertentu, ECI secara otomatis mencoba membuat Pod menggunakan vSwitch berikutnya.

Anda dapat menjalankan perintah berikut untuk memodifikasi bidang vSwitchIds dalam ConfigMap kube-system/eci-profile. Anda dapat menambahkan ID vSwitch dan memisahkan beberapa ID dengan koma (,). Perubahan berlaku langsung. Untuk informasi lebih lanjut, lihat Buat Pod ECI multi-zona.

kubectl -n kube-system edit cm eci-profile

apiVersion: v1
data:
  kube-proxy: "true"
  privatezone: "true"
  quota-cpu: "192000"
  quota-memory: 640Ti
  quota-pods: "4000"
  regionId: cn-hangzhou
  resourcegroup: ""
  securitygroupId: sg-xxx
  vpcId: vpc-xxx
  vSwitchIds: vsw-xxx,vsw-yyy,vsw-zzz
kind: ConfigMap

Konfigurasi Ketersediaan Tinggi Workload

Ketersediaan tinggi workload memastikan Pod aplikasi berjalan normal atau dapat pulih dengan cepat jika terjadi kegagalan. Anda dapat mencapai ketersediaan tinggi untuk Pod aplikasi dengan mengonfigurasi topology spread constraints, pod anti-affinity, Pod Disruption Budgets (PDB), serta pemeriksaan kesehatan Pod dengan self-healing.

Konfigurasi Kendala Penyebaran Topologi

Topology spread constraints (Topology Spread Constraints) adalah fitur dalam kluster Kubernetes yang mengelola distribusi Pod untuk memastikan Pod tersebar merata di berbagai node dan zona, sehingga meningkatkan ketersediaan tinggi dan stabilitas aplikasi. Fitur ini berlaku untuk jenis workload seperti Deployment, StatefulSet, DaemonSet, Job, dan CronJob.

Anda dapat mengatur konfigurasi seperti maxSkew.topologyKey untuk mengontrol distribusi Pod, sehingga memastikan Pod diterapkan berdasarkan topologi yang diinginkan dalam kluster. Misalnya, Anda dapat mendistribusikan workload secara merata di berbagai zona untuk meningkatkan keandalan dan ketersediaan. Berikut adalah contohnya.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-zone
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-zone
  template:
    metadata:
      labels:
        app: app-run-per-zone
    spec:
      containers:
        - name: app-container
          image: app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "topology.kubernetes.io/zone"
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: app-run-per-zone

Konfigurasikan Pod Anti-Affinity

Pod anti-affinity adalah kebijakan penjadwalan Kubernetes yang memastikan Pod tidak dijadwalkan ke node yang sama untuk meningkatkan ketersediaan tinggi aplikasi dan isolasi kesalahan. Berikut adalah contohnya.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-run-per-node
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-run-per-node
  template:
    metadata:
      labels:
        app: app-run-per-node
    spec:
      containers:
        - name: app-container
          image: app-image
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app
                    operator: In
                    values:
                      - app-run-per-node
              topologyKey: "kubernetes.io/hostname"

Dengan menggunakan topology spread constraints, Anda juga dapat memastikan maksimal satu Pod berjalan di setiap node. Saat Anda menentukan topologyKey: "kubernetes.io/hostname", setiap node bertindak sebagai domain topologi.

Contoh berikut membuat batasan penyebaran topologi. maxSkew diatur ke 1, topologyKey diatur ke "kubernetes.io/hostname", dan whenUnsatisfiable diatur ke DoNotSchedule. Hal ini menunjukkan bahwa jumlah Pod dalam domain topologi yang sama (node) paling banyak satu lebih banyak daripada di domain lain, sehingga memaksa Pod didistribusikan untuk mencapai ketersediaan tinggi node.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-app-container
          image: my-app-image
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: "kubernetes.io/hostname"
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels:
              app: my-app

Konfigurasikan Pod Disruption Budget

Anda dapat menggunakan Pod Disruption Budget (PDB) untuk lebih meningkatkan ketersediaan aplikasi. PDB menentukan jumlah minimum replika yang tersedia. Saat node berada dalam status pemeliharaan atau gagal, kluster memastikan setidaknya jumlah replika yang ditentukan tetap berjalan. PDB mencegah terlalu banyak replika dihentikan secara bersamaan, sehingga sangat cocok untuk skenario di mana beberapa replika menangani volume trafik tinggi. Berikut adalah contohnya.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-with-pdb
spec:
  replicas: 3
  selector:
    matchLabels:
      app: app-with-pdb
  template:
    metadata:
      labels:
        app: app-with-pdb
    spec:
      containers:
        - name: app-container
          image: app-container-image
          ports:
            - containerPort: 80
--- 
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: pdb-for-app
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: app-with-pdb

Konfigurasikan Pemeriksaan Kesehatan Pod dan Self-Healing

Dalam kluster ACK, Anda dapat mengonfigurasi berbagai jenis probe untuk memantau dan mengelola status serta ketersediaan kontainer, termasuk pemeriksaan kelangsungan hidup (liveness probes), pemeriksaan kesiapan (readiness probes), dan pemeriksaan startup (startup probes). Anda dapat mengonfigurasi probe ini dengan menambahkannya beserta kebijakan restart ke konfigurasi Pod. Berikut adalah contohnya.

apiVersion: v1
kind: Pod
metadata:
  name: app-with-probe
spec:
  containers:
    - name: app-container
      image: app-image
      livenessProbe:
        httpGet:
          path: /health
          port: 80
        initialDelaySeconds: 10
        periodSeconds: 5
      readinessProbe:
        tcpSocket:
          port: 8080
        initialDelaySeconds: 15
        periodSeconds: 10
      startupProbe:
        exec:
          command:
            - cat
            - /tmp/ready
        initialDelaySeconds: 20
        periodSeconds: 15
  restartPolicy: Always

Konfigurasi Ketersediaan Tinggi Load Balancing

Mencapai ketersediaan tinggi untuk load balancing dalam kluster sangat penting untuk meningkatkan stabilitas layanan, kecepatan respons, dan isolasi kesalahan. Anda dapat mencapainya dengan menentukan zona primer dan sekunder untuk instance Server Load Balancer (SLB) serta mengaktifkan petunjuk sadar topologi.

Tentukan Zona Primer dan Sekunder untuk Instance CLB

Classic Load Balancer (CLB) diterapkan di beberapa zona di sebagian besar wilayah untuk mencapai pemulihan bencana lintas pusat data dalam wilayah yang sama. Anda dapat menentukan zona primer dan sekunder untuk instance CLB menggunakan anotasi Service, sehingga memastikan konsistensi antara zona primer dan sekunder instance CLB dengan zona instance ECS dalam kelompok node. Hal ini mengurangi penerusan data lintas zona dan meningkatkan kinerja akses jaringan. Untuk informasi lebih lanjut tentang wilayah dan zona yang didukung CLB, lihat Wilayah dan zona yang mendukung CLB. Untuk informasi lebih lanjut tentang cara menentukan zona primer dan sekunder untuk instance CLB, lihat Tentukan zona primer dan sekunder saat membuat instance CLB.

Berikut adalah contohnya.

apiVersion: v1
kind: Service
metadata:
  annotations:
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "cn-hangzhou-b"
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "cn-hangzhou-i"
  name: nginx
  namespace: default
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer

Aktifkan Topology Aware Hints

Untuk mengurangi lalu lintas jaringan lintas zona dan meningkatkan kinerja jaringan, Kubernetes 1.23 memperkenalkan routing sadar topologi, juga dikenal sebagai topology-aware hints. Fitur ini memungkinkan routing kedekatan sadar topologi.

Anda dapat mengaktifkan fitur ini dalam Service. Setelah diaktifkan, jika cukup endpoint tersedia dalam satu zona, pengontrol EndpointSlice memprioritaskan pengarahan trafik ke endpoint yang lebih dekat dengan asal permintaan berdasarkan informasi petunjuk topologi pada EndpointSlice. Dalam skenario dengan lalu lintas jaringan lintas zona, fitur ini memprioritaskan menjaga lalu lintas jaringan dalam zona yang sama, sehingga meningkatkan efisiensi jaringan dan mengurangi biaya terkait. Untuk informasi lebih lanjut, lihat Topology Aware Routing.

Konfigurasi Komponen yang Direkomendasikan

ACK menyediakan berbagai jenis komponen. Anda dapat mengonfigurasi komponen tertentu untuk kluster baru atau yang sudah ada sesuai kebutuhan untuk memperluas fungsionalitas kluster. Untuk informasi lebih lanjut tentang komponen yang didukung ACK, deskripsinya, dan catatan perubahan, lihat Ikhtisar komponen dan catatan rilis. Untuk informasi lebih lanjut tentang cara meningkatkan dan mengelola komponen, seperti konfigurasi, uninstall, dan peningkatan, lihat Kelola komponen.

Referensi

• Gunakan tipe instance ECS yang lebih besar untuk node pekerja Anda. Untuk informasi lebih lanjut, lihat Konfigurasi tipe instance ECS yang direkomendasikan.

• Jika kluster ACK yang dikelola Edisi Pro Anda berskala besar (biasanya lebih dari 500 node atau 10.000 Pod), lihat Rekomendasi penggunaan untuk kluster berskala besar untuk saran penggunaan.

• Untuk informasi lebih lanjut tentang praktik terbaik untuk node dan kelompok node, lihat Praktik terbaik untuk node dan kelompok node.

• Untuk informasi lebih lanjut tentang praktik terbaik untuk autoscaling, lihat Praktik terbaik untuk autoscaling.