Container Service for Kubernetes：Konfigurasi yang Disarankan untuk Membuat Klaster HA

Tentang topik ini

Topik ini ditujukan untuk pengembang dan administrator klaster ACK. Saran dalam topik ini dapat membantu mereka merencanakan dan membuat klaster HA.Container Service for Kubernetes Konfigurasi aktual dapat bervariasi tergantung pada lingkungan klaster dan bisnis Anda. Anda dapat merujuk pada konfigurasi HA yang disarankan untuk control plane dan data plane dalam topik ini.

Arsitektur klaster

Sebuah klaster ACK terdiri dari control plane dan node biasa atau node virtual.

• Control plane bertanggung jawab atas manajemen dan koordinasi klaster, seperti penjadwalan workload dan pemeliharaan status klaster. Contohnya adalah ACK managed cluster. ACK managed cluster mengadopsi arsitektur Kubernetes on Kubernetes untuk menampung komponen control plane, seperti API server, etcd, dan Kubernetes scheduler.

• Klaster ACK mendukung Elastic Compute Service (ECS) node (node biasa) dan node virtual. Node ini bertanggung jawab menjalankan workload dan menyediakan sumber daya yang diperlukan untuk menjalankan pod.

Anda dapat menerapkan klaster ACK di beberapa zona untuk memastikan HA klaster. Gambar berikut menunjukkan arsitektur ACK managed cluster.

Arsitektur HA control plane

Control plane dan komponen control plane (seperti kube-apiserver, etcd, dan kube-scheduler) dari ACK managed cluster (edisi Basic dan Pro), ACK Serverless cluster (edisi Basic dan Pro), ACK Edge cluster, dan ACK Lingjun cluster dikelola oleh ACK.

• HA multi-zona: Setiap komponen yang dikelola berjalan di beberapa pod replika yang tersebar merata di beberapa zona untuk memastikan bahwa klaster tetap berfungsi sebagaimana mestinya ketika sebuah zona atau node down.

• HA satu-zona: Setiap komponen yang dikelola berjalan di beberapa pod replika yang tersebar di beberapa node untuk memastikan bahwa klaster tetap berfungsi sebagaimana mestinya ketika sebuah node down.

Etcd membutuhkan setidaknya tiga pod replika dan API server membutuhkan setidaknya dua pod replika. Elastic network interfaces (ENI) dipasang ke pod replika API server sehingga pod dapat berkomunikasi dengan virtual private cloud (VPC) klaster. Kubelet dan kube-proxy pada node terhubung ke API server melalui instance Classic Load Balancer (CLB) API server atau ENI.

Komponen utama yang dikelola oleh ACK dapat diskalakan berdasarkan penggunaan CPU dan memori aktual untuk secara dinamis memenuhi permintaan sumber daya API server guna menjamin SLA.

Selain arsitektur HA multi-zona default yang digunakan oleh control plane, Anda juga dapat menggunakan arsitektur HA data plane dengan merujuk pada bagian Konfigurasi HA Pool Node dan Node Virtual, Konfigurasi HA Workload, Konfigurasi HA Load Balancer, dan Konfigurasi Komponen yang Disarankan.

Konfigurasi HA pool node dan node virtual

Klaster ACK mendukung ECS node (node biasa) dan node virtual. Anda dapat menambahkan node ke pool node yang berbeda lalu meningkatkan, menskalakan, atau memelihara node berdasarkan pool node. Jika bisnis Anda tidak fluktuatif atau fluktuasi tersebut dapat diprediksi, Anda dapat menggunakan ECS node. Jika bisnis Anda sering fluktuatif dan sulit diprediksi, kami sarankan Anda menggunakan node virtual untuk menangani lonjakan lalu lintas dan mengurangi biaya komputasi. Untuk informasi lebih lanjut, lihat Pool Node, Gambaran Umum Pool Node Terkelola, dan Node Virtual.

Konfigurasi HA pool node

Anda dapat menggunakan penskalaan otomatis node, deployment set, dan penerapan multi-zona bersama dengan batasan penyebaran topologi dari penjadwal Kubernetes untuk memastikan pasokan sumber daya di domain kegagalan yang berbeda dan mengisolasi titik kegagalan tunggal. Ini memastikan kelangsungan layanan ketika domain kegagalan down, mengurangi risiko titik kegagalan tunggal, dan meningkatkan keandalan dan ketersediaan keseluruhan sistem.

Konfigurasikan penskalaan otomatis node

Setiap pool node sesuai dengan grup penskalaan. Node dalam pool node dapat diskalakan secara manual atau otomatis berdasarkan penjadwalan workload atau sumber daya klaster untuk mengurangi biaya sumber daya dan secara fleksibel mengalokasikan sumber daya komputasi elastis. Untuk informasi lebih lanjut tentang solusi penskalaan otomatis yang disediakan oleh ACK, lihat Penskalaan Otomatis dan Aktifkan Penskalaan Otomatis Node.

Aktifkan deployment set

Deployment set adalah kebijakan yang digunakan untuk mengontrol distribusi Instance ECS. Deployment set menyebarkan Instance ECS di server fisik yang berbeda untuk menghindari mematikan semua Instance ECS di server fisik ketika server fisik down. Anda dapat menentukan deployment set untuk pool node untuk memastikan bahwa Instance ECS yang ditambahkan ke pool node tersebar di server fisik yang berbeda. Lalu, Anda dapat menambahkan aturan afinitas untuk memastikan bahwa pod aplikasi Anda mengetahui topologi node yang mendasarinya dan menyebarkan pod di node yang berbeda secara bergantian. Ini memastikan bahwa aplikasi Anda memiliki ketersediaan tinggi dan dapat pulih dari gangguan besar. Untuk informasi lebih lanjut tentang cara mengaktifkan deployment set, lihat Praktik Terbaik untuk Mengaitkan Deployment Set dengan Pool Node.

Konfigurasikan penerapan multi-zona

ACK mendukung pool node multi-zona. Saat Anda membuat atau menjalankan pool node, kami sarankan Anda memilih vSwitch yang berada di zona berbeda untuk pool node, dan atur Scaling Policy ke Distribution Balancing. Dengan cara ini, Instance ECS dapat tersebar di zona (vSwitch dalam VPC) grup penskalaan. Jika distribusi sumber daya di antara zona tidak dapat diseimbangkan karena inventaris tidak mencukupi, Anda dapat melakukan operasi penyeimbangan. Untuk informasi lebih lanjut tentang cara mengonfigurasi kebijakan penskalaan otomatis, lihat Langkah 2: Konfigurasikan Pool Node yang Memiliki Penskalaan Otomatis Diaktifkan.

Aktifkan batasan penyebaran topologi

Anda dapat menggunakan penskalaan otomatis node, deployment set, dan penerapan multi-zona bersama dengan batasan penyebaran topologi dari penjadwal Kubernetes untuk mengisolasi domain kegagalan di berbagai level. Label terkait topologi secara otomatis ditambahkan ke node dalam pool node ACK, seperti kubernetes.io/hostname, topology.kubernetes.io/zone, dan topology.kubernetes.io/region. Anda dapat menggunakan batasan penyebaran topologi untuk mengontrol distribusi pod di antara domain kegagalan untuk meningkatkan kemampuan toleransi kesalahan infrastruktur.

Untuk informasi lebih lanjut tentang cara menggunakan penjadwalan sadar topologi dalam klaster ACK, lihat Penjadwalan Sadar Topologi. Sebagai contoh, Anda dapat menggunakan fitur ini untuk mencoba ulang penjadwalan pod di antara beberapa domain topologi atau menjadwalkan pod ke Instance ECS dalam deployment set dengan latensi rendah.

Konfigurasi HA node virtual

Anda dapat menggunakan node virtual untuk dengan cepat menjadwalkan pod ke instance kontainer elastis. Elastic Container Instance menghilangkan kebutuhan untuk membeli atau mengelola Instance ECS dan memungkinkan Anda fokus pada pengembangan aplikasi alih-alih pemeliharaan infrastruktur. Anda dapat membuat instance kontainer elastis untuk memenuhi kebutuhan bisnis Anda. Anda akan dikenakan biaya berdasarkan penggunaan sumber daya per detik.

Saat Anda secara horizontal menskalakan bisnis untuk menangani lonjakan lalu lintas atau meluncurkan sejumlah besar instance untuk memproses pekerjaan, Anda mungkin menghadapi masalah seperti instance tipe tertentu habis stok atau alamat IP vSwitch habis. Akibatnya, sistem gagal membuat instance kontainer elastis. Fitur penerapan multi-zona klaster ACK Serverless dapat secara efisien meningkatkan tingkat keberhasilan pembuatan instance kontainer elastis.

Anda dapat mengonfigurasi eci-profiles pada node virtual untuk menentukan vSwitch di zona berbeda untuk menerapkan penerapan multi-zona.

• Instance kontainer elastis mendistribusikan permintaan pembuatan pod ke semua vSwitch yang ditentukan. Ini menyeimbangkan beban.

• Jika sumber daya yang diperlukan untuk membuat pod habis stok di vSwitch, sistem secara otomatis beralih ke vSwitch lain.

Jalankan perintah berikut untuk menentukan satu atau lebih ID vSwitch di bidang vSwitchIds dari kube-system/eci-profile ConfigMap. Pisahkan ID vSwitch dengan koma (,). Modifikasi berlaku segera. Untuk informasi lebih lanjut, lihat Buat ECI Lintas 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 HA workload

HA workload memastikan bahwa pod aplikasi masih dapat berjalan sebagaimana mestinya atau pulih dengan cepat ketika terjadi pengecualian. Anda dapat menggunakan batasan penyebaran topologi, anti-afinitas pod, anggaran gangguan pod, pemeriksaan kesehatan pod, dan pemulihan otomatis pod untuk memastikan HA pod aplikasi.

Konfigurasikan batasan penyebaran topologi

Batasan Penyebaran Topologi digunakan untuk mengontrol distribusi pod dalam klaster Kubernetes. Anda dapat menggunakan batasan penyebaran topologi untuk menyebarkan pod secara merata di node dan zona untuk meningkatkan ketersediaan dan stabilitas aplikasi. Fitur ini berlaku untuk Deployment, StatefuSets, DaemonSets, Jobs, dan CronJobs.

Anda dapat mengonfigurasi maxSkew.topologyKey untuk mengontrol distribusi pod agar pod diterapkan berdasarkan topologi yang diharapkan. Sebagai contoh, Anda dapat menyebarkan pod workload tertentu secara merata di zona untuk meningkatkan ketersediaan dan keandalan aplikasi. Contoh:

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

Konfigurasikan anti-afinitas pod

Anti-afinitas pod adalah kebijakan penjadwalan yang digunakan dalam klaster Kubernetes. Kebijakan ini memastikan bahwa pod tidak dijadwalkan ke node yang sama. Ini meningkatkan ketersediaan aplikasi dan meningkatkan kemampuan isolasi kesalahan. Contoh:

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"

Anda juga dapat mengonfigurasi batasan penyebaran topologi untuk menjalankan hanya satu pod di setiap node. Saat topologyKey: "kubernetes.io/hostname" ditentukan, setiap node dianggap sebagai domain topologi.

Contoh berikut membuat batasan penyebaran topologi, di mana maxSkew diatur ke 1, topologyKey diatur ke "kubernetes.io/hostname", dan whenUnsatisfiable menggunakan DoNotSchedule. Konfigurasi ini menegakkan distribusi pod dengan ketersediaan tinggi dengan memungkinkan skew maksimum satu pod di antara domain topologi (node), memastikan tidak ada penjadwalan yang terjadi jika skew tidak dapat dipertahankan.

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

Konfigurasikan anggaran gangguan pod

Anda dapat mengonfigurasi anggaran gangguan pod untuk lebih meningkatkan ketersediaan aplikasi. Anggaran gangguan pod memungkinkan Anda menentukan jumlah minimum pod replika yang harus dipertahankan di node. Ketika node sedang dalam pemeliharaan atau mengalami kerusakan, klaster memastikan bahwa setidaknya jumlah pod yang ditentukan masih berjalan di node. Anda juga dapat mengonfigurasi anggaran gangguan pod untuk menghindari masalah bahwa sejumlah besar pod replika dihentikan secara bersamaan. Anggaran gangguan pod cocok untuk skenario di mana beberapa pod replika diterapkan untuk memproses lalu lintas bisnis. Contoh:

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/v1beta1
  kind: PodDisruptionBudget
  metadata:
    name: pdb-for-app
  spec:
    minAvailable: 2
    selector:
      matchLabels:
        app: app-with-pdb

Konfigurasikan pemeriksaan kesehatan pod dan pemulihan otomatis pod

Anda dapat menggunakan jenis probe berikut untuk memantau dan mengelola status serta ketersediaan kontainer: liveness probes, readiness probes, dan startup probes. Untuk melakukannya, tambahkan probe dan kebijakan restart ke konfigurasi pod. Contoh:

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 HA load balancer

HA load balancer sangat penting untuk mengoptimalkan stabilitas, waktu respons, dan kemampuan isolasi kesalahan layanan. Anda dapat menentukan zona utama dan sekunder serta mengaktifkan petunjuk sadar topologi untuk memastikan HA load balancer.

Tentukan zona utama dansekunder untuk instance CLB

Instance CLB menggunakan penerapan multi-zona di sebagian besar wilayah untuk menerapkan pemulihan bencana lintas pusat data dalam satu wilayah. Anda dapat menambahkan Anotasi Service untuk menentukan zona utama dan sekunder untuk instance CLB dan memastikan bahwa zona utama dan sekunder sama dengan zona node ECS dalam pool node. Ini mengurangi transfer data lintas zona dan mempercepat komunikasi jaringan. Untuk informasi lebih lanjut tentang wilayah dan zona yang mendukung CLB, lihat Wilayah Tempat CLB Tersedia. Untuk informasi lebih lanjut tentang cara menentukan zona utama dan sekunder untuk instance CLB, lihat Tentukan Zona Utama dan Sekunder saat Anda Membuat Instance CLB.

Contoh:

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

Aktifkan petunjuk sadar topologi

Untuk mengurangi transfer data lintas zona dan mempercepat komunikasi jaringan, routing sadar topologi (juga dikenal sebagai petunjuk sadar topologi) diperkenalkan dalam Kubernetes 1.23 untuk mendukung routing terdekat sadar topologi.

Anda dapat menggunakan fitur ini dalam Service. Setelah fitur ini diaktifkan, ketika sebuah zona memiliki endpoint yang cukup, controller EndpointSlice merutekan lalu lintas ke endpoint terdekat dari sumber lalu lintas berdasarkan petunjuk topologi pada EndpointSlice. Dalam skenario komunikasi lintas zona, fitur ini lebih memilih merutekan lalu lintas dalam wilayah yang sama untuk mengurangi biaya dan meningkatkan efisiensi transfer data. Untuk informasi lebih lanjlanjut, lihat Routing Sadar Topologi.

Konfigurasi komponen yang disarankan

ACK menyediakan berbagai komponen. Anda dapat menerapkan komponen di klaster baru atau yang sudah ada untuk memperluas kemampuan klaster. Untuk informasi lebih lanjut tentang komponen ACK dan catatan rilis, lihat Catatan Rilis untuk Komponen. Untuk informasi lebih lanjut tentang cara memperbarui, mengonfigurasi, dan menghapus komponen, lihat Kelola Komponen.

Referensi

• Kami sarankan Anda membuat node pekerja pada Instance ECS dengan spesifikasi tinggi. Untuk informasi lebih lanjut, lihat Rekomendasi Spesifikasi ECS untuk Klaster ACK.

• Jika Anda menggunakan ACK Pro Cluster yang besar, misalnya, klaster tersebut berisi lebih dari 500 node atau 10.000 pod, lihat saran dalam topik Saran Penggunaan Klaster Berskala Besar.

• Untuk informasi lebih lanjut tentang praktik terbaik untuk node dan pool node, lihat Praktik Terbaik untuk Node dan Pool Node.

• Untuk informasi lebih lanjut tentang praktik terbaik untuk penskalaan otomatis, lihat Praktik Terbaik untuk Penskalaan Otomatis.