Praktek-praktek Terbaik

1 - Menjalankan klaster dalam beberapa zona

Laman ini menjelaskan tentang bagaimana menjalankan sebuah klaster dalam beberapa zona.

Pendahuluan

Kubernetes 1.2 menambahkan dukungan untuk menjalankan sebuah klaster dalam beberapa zona kegagalan (multiple failure zones) (GCE secara sederhana menyebutnya sebagai "zones", AWS menyebutnya sebagai "availability zones", dan di sini kita akan menyebutnya sebagai "zona"). Fitur ini adalah versi sederhana dari fitur federasi klaster yang lebih luas (yang sebelumnya ditujukan pada sebuah nama panggilan yang ramah (affectionate nickname) "Ubernetes"). Federasi klaster yang penuh memungkinkan untuk menggabungkan klaster Kubernetes terpisah, yang berjalan pada wilayah atau penyedia cloud yang berbeda (baik dalam datacenter atau on-premise). Namun banyak pengguna yang ingin menjalankan klaster Kubernetes dengan tingkat ketersediaan yang lebih, dalam beberapa zona dari satu penyedia cloud mereka, dan dukungan inilah yang akhirnya memperbolehkan fitur multi-zona dalam versi Kubernetes 1.2 (sebelumnya fitur ini dikenal dengan nama panggilan "Ubernetes Lite").

Dukungan multi-zona sengaja dibuat terbatas: dimana satu klaster Kubernetes hanya dapat berjalan dalam beberapa zona, tetapi hanya pada wilayah yang sama (dan penyedia cloud yang sama pula). Hanya GCE dan AWS yang saat ini mendukung fitur ini secara otomatis (meskipun cukup mudah untuk menambahkan dukungan serupa untuk penyedia cloud yang lain atau bahkan untuk perangkat baremetal, hanya dengan mengatur label yang sesuai untuk ditambahkan ke Node dan volume).

Fungsionalitas

Ketika Node mulai dijalankan, kubelet secara otomatis menambahkan label informasi pada Node tersebut.

Kubernetes akan menyebarkan Pod secara otomatis dalam sebuah controller replikasi atau Service lintas Node dalam sebuah klaster zona tunggal (untuk mengurangi dampak kegagalan). Dengan klaster multi-zona, perilaku penyebaran ini akan dilanjutkan hingga melintasi zona (untuk mengurangi dampak kegagalan dalam satu zona.) (Ini dicapai melalui opsi SelectorSpreadPriority). Hal tersebut adalah untuk upaya penempatan terbaik, apabila zona pada klaster kamu bersifat heterogen (mis. jumlah Node yang berbeda, tipe Node yang berbeda, atau persyaratan sumber daya Pod yag berbeda), yang akan mencegah dengan sempurna penyebaran Pod kamu untuk melintasi zona yang berbeda. Jika diinginkan, kamu bisa menggunakan zona yang homogen (jumlah dan jenis Node yang sama) untuk mengurangi probabilitas penyebaran yang tidak merata.

Pada saat volume persisten dibuat, controller penerima PersistentVolumeLabel akan secara otomatis menambahkan label zona pada volume tersebut. Penjadwal (melalui predikat VolumeZonePredicate) kemudian akan memastikan bahwa Pod yang mengklaim suatu volume hanya akan ditempatkan pada zona yang sama dengan volume tersebut, karena volume tidak dapat di-attach melintasi zona yang berbeda.

Batasan

Ada beberapa batasan penting dari dukungan multi-zona:

• Kami berasumsi bahwa zona yang berbeda terletak secara berdekatan satu sama lain dalam jaringan, jadi kami tidak melakukan routing yang sadar akan zona. Secara khusus, lalu lintas (traffic) yang berjalan melalui Service mungkin melintasi beberapa zona (bahkan ketika beberapa Pod yang mendukung Service itu berada pada zona yang sama dengan klien), dan hal ini dapat menimbulkan latensi dan biaya tambahan.

• Volume zone-afinity hanya akan bekerja dengan PersistentVolume, dan tidak akan berfungsi apabila kamu secara langsung menentukan volume EBS dalam spesifikasi Pod (misalnya).

• Klaster tidak dapat melebarkan jangkauan cloud atau region (fungsi ini akan membutuhkan dukungan penuh federasi).

• Meskipun Node kamu berada dalam beberapa zona, saat ini kube-up hanya membuat satu Node master secara bawaan (default). Karena Service memerlukan ketersediaan (availability) yang tinggi dan dapat mentolerir akan hilangnya sebuah zona, maka control plane diletakkan pada setiap zona. Pengguna yang menginginkan control plane yang memiliki ketersediaan tinggi harus mengikuti instruksi ketersediaan tinggi.

Batasan Volume

Batasan berikut ditunjukkan dengan menggunakan pengikatan volume yang sadar topologi.

• Penyebaran zona volume StatefulSet yang menggunakan penyediaan secara dinamis, saat ini tidak sesuai dengan kebijakan afinitas atau anti-afinitas Pod.

• Jika nama StatefulSet berisi tanda hubung ("-"), maka penyebaran zona volume mungkin saja tidak menyediakan distribusi penyimpanan (storage) yang seragam di seluruh zona yang berbeda.

• Ketika menentukan beberapa PVC dalam spesifikasi Deployment atau Pod, StorageClass perlu dikonfigurasi untuk zona tunggal tertentu, atau PV perlu disediakan secara statis pada zona tertentu. Solusi lainnya adalah menggunakan sebuah StatefulSet, yang akan memastikan bahwa semua volume untuk sebuah replika disediakan dalam zona yang sama.

Panduan

Kita sekarang akan berjalan melalui pengaturan dan menggunakan multi-zona klaster pada GCE & AWS. Untuk melakukannya, kamu perlu mengaktifkan klaster penuh (dengan menentukan MULTIZONE=true), dan kemudian kamu menambahkan Node di zona tambahan dengan menjalankan kube-up lagi (dengan menetapkan opsi KUBE_USE_EXISTING_MASTER=true).

Mengaktifkan klaster kamu

Buatlah klaster seperti biasa, tetapi teruskan opsi MULTIZONE untuk memberi tahu klaster untuk mengelola beberapa zona; dan membuat Node di zona us-central1-a.

GCE:

curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a NUM_NODES=3 bash

AWS:

curl -sS https://get.k8s.io | MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a NUM_NODES=3 bash

Langkah ini akan mengaktifkan klaster seperti biasa, namun masih berjalan dalam satu zona (tetapi opsi MULTIZONE=true telah mengaktifkan kapabilitas multi-zona).

Node yang telah diberi label

Lihatlah Node; dimana kamu bisa melihat Node tersebut diberi label sesuai dengan informasi zona. Node tersebut sejauh ini berada di zona us-central1-a (GCE) atau zona us-west-2a (AWS). Label dari Node itu adalah failure-domain.beta.kubernetes.io/region untuk informasi wilayah, dan failure-domain.beta.kubernetes.io/zone untuk informasi zona:

kubectl get nodes --show-labels

Tampilan akan seperti dibawah ini:

NAME                     STATUS                     ROLES    AGE   VERSION          LABELS
kubernetes-master        Ready,SchedulingDisabled   <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-87j9   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q   Ready                      <none>   6m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q

Menambah lebih banyak Node di zona kedua

Mari kita tambahkan sekumpulan Node ke dalam klaster yang ada, dengan menggunakan kembali master yang ada, namun dijalankan pada zona yang berbeda (zona us-central1-b atau zona us-west-2b). Kemudian kita jalankan kube-up lagi, tetapi dengan menentukan opsi KUBE_USE_EXISTING_MASTER=true sehingga kube-up tidak akan membuat master baru, tetapi akan menggunakan kembali master yang dibuat sebelumnya.

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-b NUM_NODES=3 kubernetes/cluster/kube-up.sh

Pada AWS, kita juga perlu menentukan CIDR jaringan sebagai tambahan subnet, bersama dengan alamat IP internal dari master:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2b NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.1.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh

Lihat lagi Node; dimana 3 Node lainnya harus sudah dijalankan dan ditandai berada di us-central1-b:

kubectl get nodes --show-labels

Hasil tampilan akan terlihat seperti dibawah ini:

NAME                     STATUS                     ROLES    AGE   VERSION           LABELS
kubernetes-master        Ready,SchedulingDisabled   <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-1,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-master
kubernetes-minion-281d   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-87j9   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-87j9
kubernetes-minion-9vlv   Ready                      <none>   16m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-a12q   Ready                      <none>   17m   v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-a12q
kubernetes-minion-pp2f   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-pp2f
kubernetes-minion-wf8i   Ready                      <none>   2m    v1.13.0           beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-wf8i

Afinitas Volume

Buatlah sebuah volume dengan menggunakan pembuatan volume yang dinamis (hanya PersistentVolume yang didukung untuk afinitas zona):

kubectl apply -f - <<EOF
{
  "apiVersion": "v1",
  "kind": "PersistentVolumeClaim",
  "metadata": {
    "name": "claim1",
    "annotations": {
        "volume.alpha.kubernetes.io/storage-class": "foo"
    }
  },
  "spec": {
    "accessModes": [
      "ReadWriteOnce"
    ],
    "resources": {
      "requests": {
        "storage": "5Gi"
      }
    }
  }
}
EOF

Sekarang marilah kita memvalidasi bahwa Kubernetes secara otomatis memberikan label zona & wilayah di mana PV itu dibuat.

kubectl get pv --show-labels

Hasil tampilan akan terlihat seperti dibawah ini:

NAME           CAPACITY   ACCESSMODES   RECLAIM POLICY   STATUS    CLAIM            STORAGECLASS    REASON    AGE       LABELS
pv-gce-mj4gm   5Gi        RWO           Retain           Bound     default/claim1   manual                    46s       failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a

Kemudian sekarang kita akan membuat Pod yang menggunakan klaim akan volume persisten. Karena volume pada GCE PDs / AWS EBS tidak dapat di-attach melewati zona yang berbeda, hal ini berarti bahwa Pod ini hanya dapat dibuat pada zona yang sama dengan volume tersebut:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: claim1
EOF

Perhatikan bahwa Pod secara otomatis dibuat pada zona yang sama dengan volume, karena pada umumnya lampiran lintas zona tidak diizinkan oleh penyedia cloud:

kubectl describe pod mypod | grep Node

Node:        kubernetes-minion-9vlv/10.240.0.5

Kemudian cek label Node:

kubectl get node kubernetes-minion-9vlv --show-labels

NAME                     STATUS    AGE    VERSION          LABELS
kubernetes-minion-9vlv   Ready     22m    v1.6.0+fff5156   beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv

Pod yang tersebar melintasi zona yang berbeda

Pod dalam controller atau Service replikasi tersebar secara otomatis melintasi zona yang berbeda. Pertama-tama, mari kita luncurkan lebih banyak Node di zona ketiga:

GCE:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-f NUM_NODES=3 kubernetes/cluster/kube-up.sh

AWS:

KUBE_USE_EXISTING_MASTER=true MULTIZONE=true KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2c NUM_NODES=3 KUBE_SUBNET_CIDR=172.20.2.0/24 MASTER_INTERNAL_IP=172.20.0.9 kubernetes/cluster/kube-up.sh

Pastikan bahwa kamu mempunyai Node dalam 3 zona berbeda:

kubectl get nodes --show-labels

Buatlah contoh dengan program guestbook-go, yang mencakup RC dengan ukuran 3, dan menjalankan sebuah aplikasi web sederhana:

find kubernetes/examples/guestbook-go/ -name '*.json' | xargs -I {} kubectl apply -f {}

Beberapa Pod seharusnya tersebar di ketiga zona semuanya:

kubectl describe pod -l app=guestbook | grep Node

Node:        kubernetes-minion-9vlv/10.240.0.5
Node:        kubernetes-minion-281d/10.240.0.8
Node:        kubernetes-minion-olsh/10.240.0.11

kubectl get node kubernetes-minion-9vlv kubernetes-minion-281d kubernetes-minion-olsh --show-labels

NAME                     STATUS    ROLES    AGE    VERSION          LABELS
kubernetes-minion-9vlv   Ready     <none>   34m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-a,kubernetes.io/hostname=kubernetes-minion-9vlv
kubernetes-minion-281d   Ready     <none>   20m    v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-b,kubernetes.io/hostname=kubernetes-minion-281d
kubernetes-minion-olsh   Ready     <none>   3m     v1.13.0          beta.kubernetes.io/instance-type=n1-standard-2,failure-domain.beta.kubernetes.io/region=us-central1,failure-domain.beta.kubernetes.io/zone=us-central1-f,kubernetes.io/hostname=kubernetes-minion-olsh

Load-balancer menjangkau semua zona dalam satu klaster; program contoh guestbook-go sudah termasuk contoh Service dengan beban seimbang (load-balanced service):

kubectl describe service guestbook | grep LoadBalancer.Ingress

Hasil tampilan akan terlihat seperti di bawah ini:

LoadBalancer Ingress:   130.211.126.21

Atur alamat IP di atas:

export IP=130.211.126.21

Telusurilah dengan curl melalui alamat IP tersebut:

curl -s http://${IP}:3000/env | grep HOSTNAME

Hasil tampilan akan terlihat seperti di bawah ini:

  "HOSTNAME": "guestbook-44sep",

Kemudian, telusurilah beberapa kali:

(for i in `seq 20`; do curl -s http://${IP}:3000/env | grep HOSTNAME; done)  | sort | uniq

Hasil tampilan akan terlihat seperti dibawah ini:

  "HOSTNAME": "guestbook-44sep",
  "HOSTNAME": "guestbook-hum5n",
  "HOSTNAME": "guestbook-ppm40",

Load balancer telah menargetkan ke semua Pod dengan benar, meskipun semuanya berada di beberapa zona yang berbeda.

Menghentikan Klaster

Shutting down the cluster

Apabila kamu sudah selesai, maka bersihkanlah:

GCE:

KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-f kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_USE_EXISTING_MASTER=true KUBE_GCE_ZONE=us-central1-b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=gce KUBE_GCE_ZONE=us-central1-a kubernetes/cluster/kube-down.sh

AWS:

KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2c kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_USE_EXISTING_MASTER=true KUBE_AWS_ZONE=us-west-2b kubernetes/cluster/kube-down.sh
KUBERNETES_PROVIDER=aws KUBE_AWS_ZONE=us-west-2a kubernetes/cluster/kube-down.sh

2 - Pertimbangan untuk klaster besar

Klaster adalah kumpulan (node) berupa mesin fisik ataupun virtual yang menjalankan agen Kubernetes, dan dikelola oleh bidang kontrol. Kubernetes v1.35 mendukung klaster hingga 5000 node. Lebih tepatnya, Kubernetes didesain untuk mengakomodasi konfigurasi yang mendukung kriteria dibawah ini:

• Jumlah pods tidak lebih dari 110 pods per node
• Jumlah node tidak lebih dari 5000
• Total pods tidak lebih dari 150000
• Total kontainer tidak lebih dari 300000

Kamu dapat mengubah ukuran klaster dengan menambah atau menghapus node. Cara yang digunakan untuk pengubahan ukuran ini tergantung dari bagaimana kamu membangun klaster.

Kuota sumber daya penyedia cloud

Untuk menghindari masalah kuota penyedia cloud, ketika membuat klaster dengan banyak node, pertimbangkanlah hal berikut ini:

• Mengajukan penambahan kuota untuk sumber daya cloud berikut ini:
  • Jumlah mesin virtual
  • CPU
  • Volume penyimpanan
  • Penggunaan alamat IP
  • Aturan penyaringan paket
  • Jumlah penyeimbang beban (load balancer)
  • Subnet jaringan
  • Aliran log
• Mengatur pengubahan ukuran klaster untuk menambah node baru menggunakan mode batches, dengan jeda antar batches, karena sejumlah penyedia cloud membatasi laju (rate limit) pembuatan mesin baru.

Komponen bidang kontrol

Untuk klaster besar, kamu membutuhkan bidang kontrol dengan komputasi yang cukup dan sumber daya lainnya.

Biasanya, kamu akan menjalankan satu atau dua bidang kontrol untuk tiap zona kegagalan (failure zone), mengubah ukuran bidang kontrol secara vertikal terlebih dahulu dan kemudian mengubah ukurannya secara horizontal setelah mencapai batas dari mengubah ukuran secara vertikal.

Kamu harus menjalankan paling tidak satu bidang kontrol per zona kegagalan untuk memberikan toleransi kegagalan (fault-tolerance). node Kubernetes tidak secara otomatis mengendalikan arus ke bidang kontrol yang berada di zona kegagalan yang sama; bagaimanapun, penyedia cloud kamu mungkin memiliki mekanisme toleransi kegagalan mereka sendiri untuk menangani hal tersebut.

Sebagai contoh, dengan menggunakan penyeimbang beban bawaan (managed load balancer), kamu dapat mengonfigurasi penyeimbang beban untuk mengirim arus yang berasal dari kubelet dan pods di zona A, kemudian hanya mengarahkan arus tersebut ke bidang kontrol yang hanya ada di zona A. Jika salah satu bidang kontrol atau zona kegagalan A mati, artinya semua arus bidang kontrol untuk node di zona A akan dikirim ke zona lain. Menjalankan banyak bidang kontrol di setiap zona dapat mencegah masalah tersebut.

Penyimpanan etcd

Untuk meningkatkan performa klaster besar, kamu dapat menyimpan objek Event di instance etcd terpisah.

Ketika membangun sebuah klaster, kamu dapat (menggunakan alat khusus):

• Nyalakan dan konfigurasikan instance tambahan etcd
• konfigurasikan API server untuk menggunakan instance etcd tambahan tersebut dalam penyimpanan events

Lihat juga Mengoperasikan klaster etcd untuk Kubernetes dan Membangun klaster etcd dengan ketersediaan tinggi (high-availability) menggunakan kubeadm untuk detail tentang konfigurasi dan mengelola etcd untuk klaster besar.

Resource tambahan

Batas sumber daya Kubernetes membantu untuk meminimalisasi dampak dari kebocoran memori dan hal lainnya yang dapat membuat pods dan kontainer memberikan dampak terhadap komponen lainnya. Batasan sumber daya ini berlaku untuk sumber daya addon layaknya berlaku untuk workload aplikasi.

Sebagai contoh, kamu dapat mengatur batas CPU dan memori untuk komponen logging berikut ini:

  ...
  containers:
  - name: fluentd-cloud-logging
    image: fluent/fluentd-kubernetes-daemonset:v1
    resources:
      limits:
        cpu: 100m
        memory: 200Mi

Batas bawaan addon biasanya diatur berdasarkan data yang dikumpulkan dari pengalaman menjalankan addon pada klaster Kubernetes kecil atau menengah. Ketika menjalankan klaster besar, addon biasanya menggunakan lebih banyak sumber daya dibanding batasnya. Jika klaster besar dijalankan tanpa mengubah nilai batasan, addon dapat terhenti terus menerus karena mencapai batas memori. Selain itu, addon dapat berjalan dengan performa buruk karena pembatasan potongan waktu (time slice) CPU.

Untuk mencegah masalah sumber daya addon di Kubernetes, saat membangun klaster dengan node yang banyak, pertimbangkanlah beberapa hal berikut ini:

• Beberapa addon memperbesar ukurannya secara vertikal - terdapat satu replika dari addon untuk satu klaster atau melayani hanya satu zona kegagalan. Untuk addon tersebut, tambahkan permintaan (request) dan batasan ketika kamu memperbesar ukuran klaster.
• Banyak addon memperbesar ukurannya secara horizontal - kamu dapat menambah kapasitas dengan menjalankan lebih banyak pods - tapi dengan klaster yang sangat besar, kamu juga perlu untuk menaikan batas CPU atau memori secukupnya. Vertical Pod Autoscaler dapat berjalan dalam mode recommender untuk menyediakan angka yang disarankan bagi permintaan dan batasan.
• Beberapa addon berjalan di setiap node yang dikontrol oleh DaemonSet. Sebagai contoh, agregator log tingkat node. Mirip dengan kasus addon yang memperbesar ukuran secara horizontal, kamu juga dapat menaikkan batas CPU dan memori secukupnya.

Selanjutnya

• VerticalPodAutoscaler adalah custom resource yang dapat dijalankan di klaster untuk membantu kamu mengelola permintaan sumber daya dan batasan untuk pods. Pelajari lebih lanjut tentang Vertical Pod Autoscaler dan bagaimana kamu dapat menggunakannya untuk mengubah ukuran klaster.

• Baca juga tentang Node autoscaling.

• addon resizer membantu kamu mengubah ukuran addon secara otomatis ketika ukuran klaster kamu berubah.

3 - Validasi Pengaturan Node

Tes Kesesuaian Node

Node conformance test atau tes kesesuaian Node adalah kerangka kerja tes berbasis kontainer yang menyediakan sistem verifikasi dan tes untuk Node. Tes memvalidasi apakah Node memenuhi syarat minimum untuk Kubernetes; Node yang lolos tes dianggap lolos untuk bergabung dengan klaster Kubernetes.

Prasyarat Node

Untuk menjalankan tes kesesuaian Node, sebuah Node harus memenuhi prasyarat yang sama dengan Node Kubernetes standar. Sekurang - kurangnya, daemon dibawah ini harus terpasang di Node:

• runtime kontainer yang kompatibel dengan CRI seperti Docker, containerd dan CRI-O
• kubelet

Menjalankan Tes Kesesuaian Node

Untuk menjalankan tes kesesuaian Node, lakukanlah langkah-langkah berikut ini:

1. Sesuaikan nilai opsi dari --kubeconfig untuk kubelet; sebagai contoh: --kubeconfig=/var/lib/kubelet/config.yaml. Karena kerangka kerja tes akan menjalankan panel kontrol lokal untuk menguji kubelet, menggunakan http://localhost:8080 sebagai URL dari API Server. Terdapat beberapa parameter command line untuk kubelet yang mungkin bisa kamu gunakan:

   • --cloud-provider: Jika kamu menggunakan --cloud-provider=gce, maka kamu harus menghapus flag untuk menjalankan tes

2. Jalankan tes kesesuaian Node dengan perintah:

   # $CONFIG_DIR adalah path dari manifest untuk kubelet kamu
   # $LOG_DIR adalah path untuk output
   sudo docker run -it --rm --privileged --net=host \
     -v /:/rootfs -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
     registry.k8s.io/node-test:0.2
   

Menjalankan Tes Kesesuaian Node untuk Arsitektur lainnya

Kubernetes juga menyediakan image tes kesesuaian Node untuk arsitektur lainnya:

Menjalankan Tes Tertentu

Untuk menjalankan tes-tes tertentu, ganti nilai environment variable FOCUS dengan ekspresi reguler dari tes-tes yang ingin kamu jalankan.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e FOCUS=MirrorPod \ # Hanya menjalankan tes MirrorPod
  registry.k8s.io/node-test:0.2

Untuk melewat tes-tes tertentu, ganti nilai environment variable SKIP dengan ekspresi reguler dari tes-tes yang ingin kamu lewati.

sudo docker run -it --rm --privileged --net=host \
  -v /:/rootfs:ro -v $CONFIG_DIR:$CONFIG_DIR -v $LOG_DIR:/var/result \
  -e SKIP=MirrorPod \ # Menjalankan semua tes skesesuaian dengan melewat tes MirrorPod
  registry.k8s.io/node-test:0.2

Tes kesesuaian Node adalah versi kontainer dari node e2e test. Secara bawaan, tes ini menjalankan semua tes kesesuaian.

Secara teori, kamu dapat menjalankan tes node-e2e manapun jika kamu mengkonfigurasi kontainer dan mount yang dibutuhkan volume dengan benar. Tapi sangat direkomendasikan hanya untuk menjalankan tes kesesuaian, karena banyak sekali konfigurasi yang dibutuhkan untuk menjalankan tes ketidaksesuaian dan tentunya lebih kompleks.

Kekurangan

• Tes ini meninggalkan sisa-sisa image Docker di dalam Node, termasuk image dari tes kesesuaian Node dan image kontainer yang digunakan untuk tes fungsionalitas.
• Tes ini meninggalkan kontainer mati di dalam Node. Kontainer-kontainer ini dibuat selama tes fungsionalitas.

4 - Memberlakukan Standar Keamanan Pod

Laman ini memberikan sebuah gambaran umum tentang cara memberlakukan Standar Keamanan Pod.

Menggunakan Kontroler Pod Security Admission Bawaan

Kontroler Pod Security Admission bermaksud untuk menggantikan PodSecurityPolicies yang sudah tidak berlaku lagi (deprecated).

Mengkonfigurasi semua Namespace di klaster

Namespace yang tidak memiliki konfigurasi apapun sebaiknya dianggap sebagai gap dalam model keamanan klaster kamu. Kami menyarankan agar mengambil waktu untuk menganalisis jenis-jenis beban kerja yang terjadi di setiap Namespace, dan dengan merujuk pada Standar Keamanan Pod, lalu tentukan tingkat yang sesuai pada setiap Namespace. Namespace yang tidak berlabel sebaiknya hanya menunjukkan bahwa Namespace tersebut belum dievaluasi.

Dalam skenario dimana semua beban kerja di semua Namespace memiliki persyaratan keamanan yang sama, Kami menyediakan sebuah contoh yang mengilustrasikan bagaimana label PodSecurity dapat diterapkan secara massal.

Mengikuti prinsip hak istimewa paling sedikit

Di dunia yang ideal, semua pod di semua Namespace akan memenuhi persyaratan dari kebijakan terbatas . Namun, hal ini tidak mungkin dan tidak praktis, karena beberapa beban kerja akan memerlukan hak istimewa lebih untuk alasan yang sah.

• Namespace memperbolehkan beban kerja yang memiliki hak istimewa sebaiknya mendirikan dan memberlakukan kontrol akses yang sesuai.
• Untuk beban kerja yang berjalan di Namespace permisif, jagalah keunikan persyaratan keamanan dokumentasi tersebut. Jika memungkinkan, pertimbangkan bagaimana persyaratan tersebut dapat dibatasi lebih lanjut.

Mengadopsi strategi multi mode

Mode audit dan warn pada kontroler Pod Security Admission memudahkan pengumpulan wawasan keamanan penting tentang pod tanpa mengganggu beban kerja yang sudah ada.

Merupakan praktik yang baik untuk mengaktifkan mode-mode ini untuk semua Namespace, dan mengaturnya ke tingkat yang diinginkan dan versi yang akan kamu enforce. Notasi peringatan dan audit yang dihasilkan di fase ini bisa memandu kamu menuju keadaan yang diinginkan. Jika kamu mengharapkan pembuat beban kerja akan membuat perubahan untuk memenuhi tingkat yang diinginkan, maka aktifkan mode warn. Jika kamu berharap akan menggunakan log audit untuk memantau/mendorong perubahan untuk memenuhi tingkat yang diinginkan, maka aktifkan mode audit.

Ketika kamu memiliki mode enforce dipasang ke tingkat yang kamu inginkan, mode-mode ini masih dapat berguna dalam beberapa cara berbeda:

• Dengan menetapkan warn ke tingkat yang sama dengan enforce, maka klien akan menerima peringatan ketika mencoba membuat Pod-pod (atau sumber daya yang memiliki template Pod) yang tidak memenuhi validasi. Hal ini akan membantu mereka memperbarui sumber daya tersebut untuk menjadi patuh.
• Dalam Namespace yang menyematkan enforce ke spesifik versi yang tidak terbaru, menetapkan mode audit dan warn ke tingkat yang sama dengan enforce, tetapi ke versi terakhir akan memberikan visibilitas tentang pengaturan yang diperbolehkan oleh versi-versi sebelumnya namun tidak diperbolehkan per praktik terbaik saat ini.

Alternatif Pihak Ketiga

Alternatif pihak ketiga untuk memberlakukan profil keamanan yang dibuat di ekosistem Kubernetes:

• Kubewarden.
• Kyverno.
• OPA Gatekeeper.

Keputusan untuk menggunakan solusi bawaan (misalnya Kontroler PodSecurity Admission ) dengan alat pihak ketiga sepenuhnya bergantung pada situasimu. Ketika mengevaluasi solusi apapun, kepercayaanmu terhadap rantai pasokmu adalah yang terpenting. Pada akhirnya, menggunakan salah satu dari pendekatan yang disebutkan akan lebih baik dari tidak menggunakan apapun.