Kubernetes dari Nol hingga Profesional: 100 Contoh dengan kubectl, Manifes, Helm, dan GitOps

Kubernetes menjalankan kontainer di seluruh klaster yang terdiri atas banyak mesin. Ia memulai ulang kontainer yang gagal, menyebarkannya ke seluruh node, merilis versi baru tanpa downtime, dan menskalakannya sesuai beban. Artikel ini membawa Anda dari Pod pertama hingga pengaturan yang siap produksi dalam 100 contoh. Anda akan mempelajari kubectl dan konteks, Pod, Deployment dan pembaruan bergulir, Service dan Ingress, ConfigMap dan Secret, penyimpanan persisten, Job dan CronJob, StatefulSet dan DaemonSet, autoskala, permintaan sumber daya dan probe, penjadwalan, RBAC dan keamanan Pod, Helm dan Kustomize, observabilitas dan debugging, serta GitOps dan cadangan. Catatan jujur: klaster Kubernetes dan kubectl tidak terpasang di komputer yang dipakai menyiapkan artikel ini, jadi 100 contoh tersebut tidak dijalankan di sini. Manifes ditulis mengikuti API Kubernetes saat ini, tetapi terapkan sendiri setiap manifes ke klaster uji sebelum Anda mengandalkannya.

Yang Anda butuhkan

Docker Desktop dengan Kubernetes bawaan, atau kind atau minikube untuk klaster latihan lokal, serta kubectl dan Helm. Pengetahuan dasar tentang kontainer akan membantu; artikel Docker dalam seri ini adalah awal yang baik. Beberapa contoh memakai penyedia cloud seperti Azure Kubernetes Service dan pengontrol ingress. Gunakan host contoh seperti shop.example.com dan kata sandi contoh seperti <strong-password>, dan jangan pernah menempelkan kredensial asli ke dalam manifes atau perintah.

Cara memakai contoh

Contoh bash memakai kubectl, Helm, dan Kustomize. Contoh YAML disimpan dalam berkas .yaml lalu diterapkan dengan kubectl apply -f memakai nama berkas yang disebut dalam teks. Contoh Python memakai klien Python Kubernetes resmi.

Topik 1: Memulai dengan Kubernetes

Kubernetes adalah loop kontrol. Anda mendeskripsikan keadaan yang diinginkan dalam YAML, lalu klaster terus bekerja sampai kenyataan sesuai dengan deskripsi itu. Pelajari bagian-bagian klaster, klien kubectl, konteks, dan namespace.

Control plane dan node

Control plane menyimpan keadaan yang diinginkan dan membuat keputusan, sedangkan node pekerja menjalankan kontainer Anda. Anda berkomunikasi dengan klaster lewat API server, dan kubectl adalah klien standar yang mengirim permintaan Anda.

Konteks dan namespace

Konteks menyimpan klaster, pengguna, dan namespace yang dipakai perintah Anda. Periksa dengan kubectl config current-context sebelum mengubah apa pun, agar Anda tidak pernah menghapus sumber daya di klaster yang salah.

Manifes dan perubahan deklaratif

Manifes memiliki apiVersion, kind, metadata, dan spec. kubectl apply membandingkan berkas Anda dengan klaster dan hanya mengubah bagian yang berbeda, sehingga perubahan dapat diulang dan mudah ditinjau di Git.

Ilustrasi

Contoh 1: Periksa klien dan klaster

Pastikan kubectl dapat berkomunikasi dengan klaster.

kubectl version --client
kubectl cluster-info
kubectl get nodes -o wide

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 2: Buat klaster latihan dengan kind

Klaster lokal di komputer Anda untuk belajar.

kind create cluster --name learn
kubectl config current-context
kubectl get nodes

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 3: Pindah antarkonteks

Pilih klaster yang dituju perintah Anda.

kubectl config get-contexts
kubectl config use-context kind-learn
kubectl config view --minify --output "jsonpath={.current-context}"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 4: Buat namespace

Pisahkan tim dan aplikasi dalam satu klaster.

kubectl create namespace shop
kubectl config set-context --current --namespace=shop
kubectl get pods

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 5: Baca manifes

Empat kolom tingkat atas yang dimiliki setiap objek.

apiVersion: v1
kind: Namespace
metadata:
  name: shop
  labels:
    team: platform

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 6: Terapkan manifes

Buat perubahan deklaratif dengan kubectl apply.

kubectl apply -f namespace.yaml
kubectl get namespace shop --show-labels
kubectl describe namespace shop

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 2: Pod: unit terkecil

Pod adalah satu atau lebih kontainer yang berbagi alamat jaringan dan penyimpanan. Sebagian besar Pod menjalankan satu kontainer, tetapi Pod juga dapat memuat pembantu yang harus berjalan berdampingan dengan aplikasi utama.

Apa itu Pod

Semua kontainer dalam satu Pod berbagi alamat IP yang sama dan dapat saling mengakses lewat localhost. Pod bersifat sementara: saat satu mati, klaster membuat yang baru dengan nama dan alamat baru, jadi jangan bergantung pada alamat Pod.

Kontainer init dan sidecar

Kontainer init berjalan sampai selesai sebelum kontainer utama dimulai, cocok untuk menunggu basis data. Kontainer sidecar berjalan di samping kontainer utama untuk pencatatan log, proksi, atau sinkronisasi berkas, dan berbagi volumenya.

Log, event, dan exec

kubectl logs menampilkan keluaran, kubectl describe menampilkan event seperti galat pengambilan image dan kegagalan penjadwalan, dan kubectl exec membuka shell. Baca describe lebih dulu, karena penjelasannya mencakup sebagian besar kegagalan saat mulai.

Contoh 7: Jalankan Pod dengan cepat

Perintah imperatif, hanya untuk uji cepat.

kubectl run hello --image=nginx:1.27 --port=80
kubectl get pod hello -o wide

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 8: Pod deklaratif

Unit terkecil yang Anda terapkan.

apiVersion: v1
kind: Pod
metadata:
  name: web
  labels:
    app: web
spec:
  containers:
    - name: web
      image: nginx:1.27
      ports:
        - containerPort: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 9: Baca log dan event

Cari tahu apa yang terjadi pada Pod.

kubectl logs web
kubectl logs web --previous
kubectl get events --sort-by=.lastTimestamp

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 10: Jalankan perintah di dalam Pod

Debug dari dalam.

kubectl exec -it web -- sh
kubectl exec web -- nginx -v

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 11: Port-forward ke Pod

Akses Pod dari komputer Anda untuk pengujian.

kubectl port-forward pod/web 8080:80
curl http://localhost:8080

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 12: Dua kontainer berbagi volume

Pola sidecar.

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-demo
spec:
  volumes:
    - name: logs
      emptyDir: {}
  containers:
    - name: app
      image: busybox:1.36
      command: ["sh", "-c", "while true; do date >> /logs/app.log; sleep 5; done"]
      volumeMounts:
        - name: logs
          mountPath: /logs
    - name: log-reader
      image: busybox:1.36
      command: ["sh", "-c", "tail -F /logs/app.log"]
      volumeMounts:
        - name: logs
          mountPath: /logs

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 13: Kontainer init menunggu

Jalankan langkah persiapan sebelum aplikasi mulai.

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
    - name: wait-for-db
      image: busybox:1.36
      command: ["sh", "-c", "until nslookup db; do sleep 2; done"]
  containers:
    - name: app
      image: nginx:1.27

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 14: Hapus Pod uji

Bersihkan objek yang tidak lagi dibutuhkan.

kubectl delete pod hello web sidecar-demo init-demo --ignore-not-found
kubectl get pods

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 3: Deployment dan pembaruan bergulir

Anda jarang membuat Pod secara langsung. Deployment mengelola ReplicaSet, yang menjaga jumlah Pod yang diminta tetap berjalan, dan melakukan pembaruan bergulir sehingga versi baru menggantikan versi lama secara bertahap.

Replika dan selector

Kolom replicas menetapkan berapa Pod yang Anda inginkan. Selector harus cocok dengan label Pod, sehingga Deployment tahu Pod mana yang dimilikinya. Ketidakcocokan ditolak saat pembuatan.

Strategi pembaruan bergulir

maxSurge menetapkan berapa Pod tambahan yang boleh ada selama pembaruan, dan maxUnavailable menetapkan berapa Pod yang boleh hilang. Menetapkan maxUnavailable ke 0 menjaga kapasitas penuh selama rilis.

Riwayat rollout dan rollback

Setiap perubahan membuat ReplicaSet baru dan nomor revisi. kubectl rollout undo kembali ke versi sebelumnya, dan kubectl rollout history mendaftar revisi sehingga Anda dapat memilih satu yang spesifik.

Contoh 15: Deployment menjaga replika tetap berjalan

Pembaruan bergulir yang dikelola untuk Anda.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.27
          ports:
            - containerPort: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 16: Buat dan pantau Deployment

Periksa status rollout.

kubectl apply -f deployment.yaml
kubectl rollout status deployment/web
kubectl get deploy,rs,pods -l app=web

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 17: Skala secara manual

Ubah jumlah replika.

kubectl scale deployment web --replicas=5
kubectl get pods -l app=web -o wide

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 18: Rilis image baru

Perbarui versi aplikasi.

kubectl set image deployment/web web=nginx:1.27.2
kubectl rollout status deployment/web
kubectl rollout history deployment/web

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 19: Kembalikan rilis yang bermasalah

Batalkan rollout yang gagal.

kubectl rollout undo deployment/web
kubectl rollout undo deployment/web --to-revision=1

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 20: Kendalikan pembaruan bergulir

maxSurge dan maxUnavailable.

spec:
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 21: Jeda dan lanjutkan rollout

Gabungkan beberapa perubahan sekaligus.

kubectl rollout pause deployment/web
kubectl set resources deployment/web -c web --limits=memory=256Mi
kubectl rollout resume deployment/web

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 22: Readiness probe

Lalu lintas menunggu sampai aplikasi siap.

containers:
  - name: web
    image: nginx:1.27
    readinessProbe:
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 3
      periodSeconds: 5

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 4: Service dan jaringan

Pod datang dan pergi, jadi klien memerlukan nama dan alamat yang stabil. Service memilih Pod berdasarkan label dan memberi mereka satu IP virtual serta nama DNS yang tetap sama.

Jenis Service

ClusterIP hanya dapat dijangkau dari dalam klaster. NodePort membuka port di setiap node. LoadBalancer meminta penyeimbang beban eksternal dari penyedia cloud. Pilih jenis terkecil yang memenuhi kebutuhan.

DNS dan endpoint

Setiap Service mendapat nama DNS seperti web-svc.shop.svc.cluster.local, dan dalam namespace yang sama nama pendek juga berfungsi. kubectl get endpoints menampilkan alamat Pod di balik Service, dan ini adalah hal pertama yang diperiksa saat Service tidak merespons.

Service headless

Dengan clusterIP diatur ke None, DNS mengembalikan alamat setiap Pod, bukan satu IP virtual. Basis data dan sistem berklaster memakai ini agar klien dapat berkomunikasi dengan anggota tertentu.

Contoh 23: Service ClusterIP

Alamat tetap di dalam klaster.

apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 24: Ekspos dengan kubectl

Cara cepat membuat Service.

kubectl expose deployment web --port=80 --target-port=80 --name=web-svc
kubectl get svc web-svc
kubectl get endpoints web-svc

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 25: Panggil Service dari Pod sementara

Uji DNS di dalam klaster.

kubectl run tmp-client --rm -it --image=busybox:1.36 --restart=Never -- wget -qO- http://web-svc

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 26: Service NodePort

Buka port di setiap node.

apiVersion: v1
kind: Service
metadata:
  name: web-nodeport
spec:
  type: NodePort
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30080

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 27: Service LoadBalancer

Penyeimbang beban cloud untuk akses publik.

apiVersion: v1
kind: Service
metadata:
  name: web-public
  annotations:
    service.beta.kubernetes.io/azure-load-balancer-internal: "false"
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 28: Temukan alamat eksternal

Baca alamat yang diberikan cloud.

kubectl get svc web-public -o jsonpath="{.status.loadBalancer.ingress[0].ip}"
kubectl get svc web-public -w

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 29: Port bernama

Gunakan nama port agar nomornya aman diubah.

apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
    - name: http
      port: 8000
      targetPort: http

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 30: Service headless

Dapatkan alamat tiap Pod.

apiVersion: v1
kind: Service
metadata:
  name: db-headless
spec:
  clusterIP: None
  selector:
    app: db
  ports:
    - port: 5432

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 5: Konfigurasi dengan ConfigMap dan Secret

Simpan konfigurasi di luar image. ConfigMap menyimpan pengaturan biasa, dan Secret menyimpan nilai sensitif. Keduanya dapat menjadi variabel lingkungan atau berkas di dalam Pod, sehingga Anda dapat mengubah pengaturan tanpa membangun ulang image.

ConfigMap

ConfigMap menyimpan pasangan kunci-nilai atau seluruh berkas. Gunakan envFrom untuk memuat setiap kunci sebagai variabel lingkungan, atau pasang ConfigMap sebagai direktori saat aplikasi membaca berkas.

Secret

Secret menyimpan nilai yang dikodekan base64. Base64 adalah pengodean, bukan enkripsi, jadi aktifkan enkripsi saat diam di klaster, batasi siapa yang dapat membaca Secret dengan RBAC, dan pasang sebagai berkas bila memungkinkan.

Memuat ulang perubahan

Variabel lingkungan hanya dibaca saat start, sehingga ConfigMap yang berubah memerlukan rollout baru. Berkas yang dipasang diperbarui setelah jeda, tetapi aplikasi harus membacanya ulang. Rencanakan pemuatan ulang setiap kali Anda mengubah konfigurasi.

Contoh 31: ConfigMap dari nilai literal

Simpan pengaturan yang tidak rahasia.

kubectl create configmap app-config --from-literal=LOG_LEVEL=info --from-literal=FEATURE_X=on
kubectl get configmap app-config -o yaml

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 32: Manifes ConfigMap

Pengaturan ditulis dalam YAML.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  LOG_LEVEL: info
  FEATURE_X: "on"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 33: ConfigMap sebagai variabel lingkungan

Muat semua kunci dengan envFrom.

containers:
  - name: api
    image: sample-api:1.4.2
    envFrom:
      - configMapRef:
          name: app-config

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 34: Pasang ConfigMap sebagai berkas

Berkas konfigurasi di dalam kontainer.

containers:
  - name: web
    image: nginx:1.27
    volumeMounts:
      - name: site-config
        mountPath: /etc/nginx/conf.d
        readOnly: true
volumes:
  - name: site-config
    configMap:
      name: nginx-conf

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 35: Buat Secret

Simpan kata sandi tanpa menuliskannya ke berkas.

kubectl create secret generic db-secret --from-literal=DB_PASSWORD='<strong-password>'
kubectl get secret db-secret -o jsonpath="{.type}"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 36: Manifes Secret

stringData memungkinkan teks biasa.

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:
  DB_PASSWORD: <strong-password>

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 37: Baca nilai Secret

Periksa nilai yang sudah didekode dan jaga kerahasiaannya.

kubectl get secret db-secret -o jsonpath="{.data.DB_PASSWORD}" | base64 --decode; echo
# Do not print secrets in shared logs or screenshots.

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 38: Pasang Secret sebagai berkas

Berkas kredensial hanya-baca.

containers:
  - name: api
    image: sample-api:1.4.2
    volumeMounts:
      - name: db-creds
        mountPath: /var/run/secrets/db
        readOnly: true
volumes:
  - name: db-creds
    secret:
      secretName: db-secret

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 6: Penyimpanan persisten

Kontainer kehilangan berkasnya saat restart. PersistentVolumeClaim meminta penyimpanan yang bertahan lebih lama daripada umur Pod, dan StorageClass memberi tahu klaster cara membuat penyimpanan tersebut.

PV, PVC, dan StorageClass

PersistentVolume adalah penyimpanan yang sebenarnya, PersistentVolumeClaim adalah permintaan untuk itu, dan StorageClass menentukan cara volume dibuat sesuai permintaan. Sebagian besar klaster menyediakan StorageClass bawaan, sehingga claim sering hanya memerlukan ukuran.

Mode akses

ReadWriteOnce memasang volume di satu node dalam satu waktu, cocok untuk sebagian besar basis data. ReadWriteMany memungkinkan banyak node menulis, tetapi hanya sebagian jenis penyimpanan yang mendukungnya. Pilih mode yang didukung penyimpanan Anda.

Kebijakan reclaim

Delete menghapus penyimpanan saat claim dihapus, sedangkan Retain menyimpan data untuk pemulihan manual. Gunakan Retain untuk data yang harus selamat dari penghapusan tidak sengaja, dan cadangkan data penting dalam kedua kasus.

Contoh 39: PersistentVolumeClaim

Minta penyimpanan dari klaster.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 1Gi

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 40: Pod yang memakai claim

Data tetap ada walau Pod di-restart.

apiVersion: v1
kind: Pod
metadata:
  name: writer
spec:
  containers:
    - name: writer
      image: busybox:1.36
      command: ["sh", "-c", "echo hello >> /data/out.txt; sleep 3600"]
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: data-pvc

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 41: Periksa penyimpanan yang terikat

Baca status claim dan volume.

kubectl get pvc data-pvc
kubectl get pv
kubectl describe pvc data-pvc

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 42: Pilih StorageClass

Pilih jenis disk.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: fast-pvc
spec:
  storageClassName: managed-premium
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 10Gi

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 43: Daftar StorageClass

Temukan kelas bawaan.

kubectl get storageclass
kubectl get storageclass -o custom-columns=NAME:.metadata.name,DEFAULT:.metadata.annotations."storageclass\.kubernetes\.io/is-default-class"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 44: Perbesar claim

Tambah kapasitas jika kelasnya mendukung.

kubectl patch pvc data-pvc -p '{"spec":{"resources":{"requests":{"storage":"2Gi"}}}}'
kubectl get pvc data-pvc

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 45: Kebijakan reclaim

Simpan data setelah claim dihapus.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: archive-pv
spec:
  capacity:
    storage: 5Gi
  accessModes: ["ReadWriteOnce"]
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /srv/archive

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 46: Batasi penyimpanan sementara

Hentikan berkas sementara yang terus membesar.

containers:
  - name: worker
    image: busybox:1.36
    resources:
      limits:
        ephemeral-storage: 1Gi

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 7: Ingress dan perutean lalu lintas

Ingress mengekspos rute HTTP dan HTTPS dari luar klaster ke Service. Ia merutekan berdasarkan nama host dan path, serta mengakhiri TLS, sehingga satu alamat publik dapat melayani banyak aplikasi.

Ingress dan pengontrol

Resource Ingress tidak melakukan apa pun sendirian. Pengontrol ingress, seperti ingress-nginx, membaca objek Ingress dan mengonfigurasi proksi. Pasang satu pengontrol per klaster dan atur ingressClassName di setiap Ingress.

Sertifikat TLS

Bagian tls menunjuk ke Secret yang berisi sertifikat dan kunci. cert-manager dapat meminta dan memperbarui sertifikat secara otomatis, sehingga Anda tidak perlu menangani masa berlaku secara manual.

Perutean berdasarkan path dan host

Aturan mencocokkan nama host dan awalan path. Path yang paling spesifik menang, sehingga /api dapat menuju API sementara / menuju situs web. Jaga rute tetap sederhana agar tabel perutean mudah ditinjau.

Contoh 47: Ingress berdasarkan nama host

Perutean HTTP ke Service.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 48: Ingress dengan TLS

HTTPS memakai sertifikat yang disimpan di Secret.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-tls
spec:
  ingressClassName: nginx
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 49: Pasang ingress controller

Pasang pengontrol dengan Helm.

helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx
helm repo update
helm install ingress ingress-nginx/ingress-nginx --namespace ingress --create-namespace

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 50: Perutean berdasarkan path

Kirim /api dan / ke Service yang berbeda.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: shop-routes
spec:
  ingressClassName: nginx
  rules:
    - host: shop.example.com
      http:
        paths:
          - path: /api
            pathType: Prefix
            backend:
              service:
                name: api
                port:
                  number: 8000
          - path: /
            pathType: Prefix
            backend:
              service:
                name: web
                port:
                  number: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 51: Anotasi Ingress untuk unggahan

Naikkan batas ukuran unggahan dan timeout untuk satu situs.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: upload-ingress
  annotations:
    nginx.ingress.kubernetes.io/proxy-body-size: "20m"
    nginx.ingress.kubernetes.io/proxy-read-timeout: "60"
spec:
  ingressClassName: nginx
  rules:
    - host: upload.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: uploader
                port:
                  number: 80

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 52: ClusterIssuer cert-manager

Minta sertifikat dari Let's Encrypt secara otomatis.

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: [email protected]
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
      - http01:
          ingress:
            ingressClassName: nginx

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 53: Minta sertifikat dari Ingress

Gunakan anotasi agar TLS dikelola untuk Anda.

metadata:
  annotations:
    cert-manager.io/cluster-issuer: letsencrypt-prod
spec:
  tls:
    - hosts: [shop.example.com]
      secretName: shop-tls

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 54: NetworkPolicy untuk API

Hanya lapisan web yang boleh menjangkau API.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow-web
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: web
      ports:
        - port: 8000

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 8: Job dan CronJob

Tidak semua beban kerja berjalan selamanya. Job menjalankan tugas sampai berhasil, dan CronJob memulai Job sesuai jadwal, seperti tabel cron yang berjalan di dalam klaster.

Job dan jumlah penyelesaian

Job membuat Pod sampai jumlah completions yang diminta berhasil. backoffLimit membatasi percobaan ulang. Gunakan restartPolicy Never atau OnFailure, karena Always tidak diizinkan untuk Job.

Pekerjaan paralel

parallelism menetapkan berapa Pod yang berjalan bersamaan, dan completions menetapkan berapa eksekusi berhasil yang dibutuhkan. Pola ini memproses sekumpulan item dengan beberapa pekerja.

CronJob dan riwayat

CronJob memakai sintaks cron pada jadwalnya. concurrencyPolicy Forbid mencegah eksekusi yang tumpang-tindih, dan batas riwayat menghapus Job lama sehingga klaster tetap rapi.

Contoh 55: Job berjalan sampai selesai

Tugas sekali jalan seperti migrasi basis data.

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migrate
spec:
  backoffLimit: 2
  template:
    spec:
      restartPolicy: Never
      containers:
        - name: migrate
          image: sample-api:1.4.2
          command: ["python", "manage.py", "migrate"]

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 56: Jalankan Job dan tunggu

Tunggu sampai tugas selesai, lalu baca log.

kubectl apply -f job.yaml
kubectl wait --for=condition=complete job/db-migrate --timeout=120s
kubectl logs job/db-migrate

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 57: Job paralel

Proses banyak item dengan beberapa worker.

apiVersion: batch/v1
kind: Job
metadata:
  name: thumbnails
spec:
  completions: 10
  parallelism: 3
  template:
    spec:
      restartPolicy: OnFailure
      containers:
        - name: worker
          image: thumbnailer:2.0

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 58: CronJob terjadwal

Jalankan laporan setiap malam pukul 02.00.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: nightly-report
spec:
  schedule: "0 2 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: report
              image: reporter:1.1

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 59: Periksa dan picu CronJob

Lihat eksekusi sebelumnya dan jalankan satu secara manual.

kubectl get cronjob nightly-report
kubectl get jobs --sort-by=.metadata.creationTimestamp
kubectl create job --from=cronjob/nightly-report manual-report-1

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 60: Batas riwayat Job

Cegah Job yang selesai menumpuk.

spec:
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 5
  startingDeadlineSeconds: 300

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 9: StatefulSet dan DaemonSet

Beberapa beban kerja memerlukan identitas yang stabil atau satu Pod per node. StatefulSet memberi Pod nama yang berurutan dan penyimpanan sendiri, sedangkan DaemonSet menjalankan satu salinan Pod di setiap node yang cocok.

Identitas StatefulSet

Pod diberi nama name-0, name-1, dan seterusnya, dan masing-masing menyimpan claim-nya sendiri dari volumeClaimTemplates. Nama tetap bersama Pod saat restart, cocok untuk basis data dan broker pesan.

Operasi berurutan

Secara bawaan StatefulSet memulai dan menghentikan Pod secara berurutan. Pembaruan dengan partition memungkinkan Anda mengubah Pod bernomor tertinggi lebih dulu, yang memberi kanari terkendali untuk sistem stateful.

DaemonSet

DaemonSet menjaga satu Pod di setiap node, cocok untuk pengumpul log, agen pemantauan, dan plugin jaringan. nodeSelector atau tolerations membatasinya ke node tertentu.

Contoh 61: StatefulSet

Nama dan penyimpanan yang stabil untuk basis data.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: redis
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
        - name: redis
          image: redis:7-alpine
          volumeMounts:
            - name: data
              mountPath: /data
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        resources:
          requests:
            storage: 1Gi

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 62: Periksa StatefulSet

Nama berurutan dan satu claim per Pod.

kubectl get statefulset redis
kubectl get pods -l app=redis
kubectl get pvc

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 63: DaemonSet

Satu Pod di setiap node, untuk agen.

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-agent
spec:
  selector:
    matchLabels:
      app: node-agent
  template:
    metadata:
      labels:
        app: node-agent
    spec:
      containers:
        - name: agent
          image: busybox:1.36
          command: ["sh", "-c", "sleep 3600"]

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 64: DaemonSet pada node berlabel

Gunakan nodeSelector untuk memilih node.

spec:
  template:
    spec:
      nodeSelector:
        workload: edge

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 65: Partition StatefulSet

Perbarui sebagian Pod lebih dulu.

spec:
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 2

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 66: Skala StatefulSet dengan hati-hati

Periksa claim setelah pengecilan.

kubectl get statefulset redis -o jsonpath="{.spec.replicas}"; echo
kubectl scale statefulset redis --replicas=2
kubectl get pvc -l app=redis

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 10: Autoskala

Beban berubah sepanjang hari. Autoskala menambah Pod saat permintaan tinggi dan menguranginya saat turun, sehingga Anda membayar sesuai pemakaian dan pengguna tetap mendapat respons yang cepat.

Horizontal Pod Autoscaler

HPA membandingkan metrik, seperti rata-rata pemakaian CPU, dengan target dan mengubah jumlah replika. Ia memerlukan metrics server dan permintaan CPU pada Pod, karena pemakaian diukur terhadap permintaan.

Perilaku penskalaan

Kolom behavior mengendalikan seberapa cepat HPA menaik dan menurunkan skala. Jendela stabilisasi saat penurunan skala mencegah naik-turun yang cepat setelah lonjakan singkat.

Penskalaan berbasis peristiwa

KEDA menskalakan berdasarkan sinyal eksternal, seperti panjang antrean atau keterlambatan pesan, dan dapat diskalakan ke nol saat tidak ada pekerjaan. Gunakan untuk pekerja yang mengonsumsi antrean.

Contoh 67: Pemakaian sumber daya langsung

kubectl top membutuhkan metrics server.

kubectl top nodes
kubectl top pods -l app=web

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 68: Autoskala berdasarkan CPU

Tambah Pod saat beban rata-rata tinggi.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 69: Buat HPA dari baris perintah

Autoskala dan amati reaksinya.

kubectl autoscale deployment web --min=2 --max=10 --cpu-percent=70
kubectl get hpa web -w

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 70: Autoskala berdasarkan memori

Gunakan lebih dari satu metrik.

spec:
  metrics:
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 75

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 71: Batasi kecepatan penurunan HPA

Hindari naik-turun dengan jendela stabilisasi.

spec:
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
        - type: Pods
          value: 1
          periodSeconds: 60

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 72: Penskalaan berbasis peristiwa

Skalakan worker menurut panjang antrean dengan KEDA.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: worker-scaler
spec:
  scaleTargetRef:
    name: worker
  minReplicaCount: 0
  maxReplicaCount: 20
  triggers:
    - type: rabbitmq
      metadata:
        queueName: orders
        mode: QueueLength
        value: "50"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 11: Sumber daya, probe, dan penjadwalan

Beri tahu Kubernetes berapa CPU dan memori yang dibutuhkan setiap kontainer, serta cara mengetahui apakah kontainer itu sehat. Penjadwal menggunakan requests untuk menempatkan Pod, dan probe memutuskan kapan harus memulai ulang atau mengirim lalu lintas.

Requests dan limits

Request adalah jumlah yang dicadangkan penjadwal untuk kontainer. Limit adalah jumlah maksimum yang boleh dipakai. Memori melebihi limit membuat kontainer dihentikan, sedangkan CPU melebihi limit dibatasi. Tetapkan keduanya berdasarkan pemakaian yang diukur.

Probe

Liveness probe memulai ulang kontainer yang macet. Readiness probe mengeluarkan kontainer dari endpoint Service selama belum siap. Startup probe menunda probe lain untuk aplikasi yang lambat dimulai.

Penyebaran dan gangguan

Constraint penyebaran topologi menempatkan replika di node atau zona yang berbeda. PodDisruptionBudget membatasi berapa Pod yang dapat dihapus sekaligus oleh tindakan sukarela seperti drain.

Contoh 73: requests dan limits

Cara penjadwal dan kernel menggunakannya.

containers:
  - name: api
    image: sample-api:1.4.2
    resources:
      requests:
        cpu: 250m
        memory: 256Mi
      limits:
        cpu: "1"
        memory: 512Mi

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 74: Liveness probe

Restart kontainer yang macet.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8000
  initialDelaySeconds: 10
  periodSeconds: 15
  failureThreshold: 3

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 75: Startup probe

Beri waktu bagi aplikasi yang lambat untuk mulai.

startupProbe:
  httpGet:
    path: /healthz
    port: 8000
  failureThreshold: 30
  periodSeconds: 10

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 76: PodDisruptionBudget

Pertahankan replika yang cukup saat pemeliharaan.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: web

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 77: Sebar replika ke beberapa node

Jangan letakkan semua replika di satu mesin.

spec:
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: kubernetes.io/hostname
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app: web

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 78: PriorityClass

Tetap jadwalkan Pod penting saat klaster penuh.

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: business-critical
value: 100000
globalDefault: false
description: "Keep these Pods running when the cluster is full."

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 12: Keamanan: RBAC dan keamanan Pod

Hak akses minimum berlaku untuk orang dan juga aplikasi. RBAC memutuskan siapa boleh melakukan apa, dan pengaturan keamanan Pod membatasi apa yang dapat dilakukan kontainer di node.

ServiceAccount, Role, dan binding

ServiceAccount adalah identitas Pod. Role mendaftar kata kerja yang diizinkan pada resource dalam satu namespace, dan RoleBinding menghubungkannya. Berikan hanya kata kerja yang dibutuhkan aplikasi, dan hindari cluster-admin untuk aplikasi.

Memeriksa akses

kubectl auth can-i menguji suatu izin, dan dapat dijalankan sebagai pengguna atau ServiceAccount lain. Jalankan pada langkah tinjauan agar kesalahan muncul sebelum penerapan, bukan setelah insiden.

Keamanan Pod

Label namespace menerapkan Pod Security Standards, seperti restricted, yang memblokir kontainer root dan eskalasi hak akses. Kombinasikan dengan securityContext yang membuang capability dan membuat sistem berkas root hanya-baca.

Contoh 79: ServiceAccount

Identitas untuk Pod, dengan token dinonaktifkan.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: api-sa
automountServiceAccountToken: false

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 80: Role dengan hak minimum

Hanya membaca ConfigMap di satu namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-config
  namespace: shop
rules:
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list"]

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 81: RoleBinding

Kaitkan role dengan ServiceAccount.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: api-read-config
  namespace: shop
subjects:
  - kind: ServiceAccount
    name: api-sa
    namespace: shop
roleRef:
  kind: Role
  name: read-config
  apiGroup: rbac.authorization.k8s.io

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 82: Periksa izin dengan auth can-i

Verifikasi RBAC sebelum menerapkan.

kubectl auth can-i list configmaps --as=system:serviceaccount:shop:api-sa -n shop
kubectl auth can-i delete pods --as=system:serviceaccount:shop:api-sa -n shop

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 83: Standar keamanan Pod

Terapkan profil restricted pada namespace.

kubectl label namespace shop pod-security.kubernetes.io/enforce=restricted
kubectl label namespace shop pod-security.kubernetes.io/warn=restricted

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 84: Konteks keamanan yang diperkeras

Non-root, hanya-baca, tanpa capability tambahan.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 13: Helm dan Kustomize

Aplikasi nyata memiliki banyak manifes dan beberapa lingkungan. Helm mengemasnya sebagai chart dengan values, sedangkan Kustomize menyimpan satu base dan menerapkan overlay kecil untuk setiap lingkungan.

Chart dan release Helm

Chart adalah paket templat dengan nilai bawaan. Release adalah satu salinan yang terpasang. Pasang, perbarui, dan kembalikan dengan helm, dan gunakan --atomic agar pembaruan yang gagal kembali otomatis.

Values per lingkungan

Simpan satu berkas values per lingkungan dan berikan dengan -f. Periksa hasil render dengan helm template sebelum memasang, sehingga Anda tahu persis apa yang akan sampai ke klaster.

Overlay Kustomize

Kustomize menggabungkan base dengan overlay yang mengubah replika, image, atau label tanpa templat. kubectl apply -k menerapkan hasilnya, dan kubectl diff menampilkan perubahan lebih dulu.

Contoh 85: Pasang aplikasi dengan Helm

Gunakan chart dari repositori.

helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm install shop-cache bitnami/redis --namespace shop --set architecture=standalone

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 86: Render dan periksa chart

Pratinjau YAML dan validasi di server.

helm template shop-web ./chart --values values-prod.yaml > rendered.yaml
kubectl apply --dry-run=server -f rendered.yaml

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 87: Berkas values Helm

Pengaturan untuk satu lingkungan.

replicaCount: 3
image:
  repository: registry.example.com/team/web
  tag: "1.4.2"
resources:
  limits:
    memory: 512Mi
ingress:
  enabled: true
  host: shop.example.com

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 88: Upgrade dan rollback dengan Helm

Upgrade atomik yang membatalkan diri saat gagal.

helm upgrade shop-web ./chart -n shop -f values-prod.yaml --atomic --wait
helm history shop-web -n shop
helm rollback shop-web 1 -n shop

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 89: Overlay Kustomize

Perubahan lingkungan tanpa templat.

# overlays/prod/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
replicas:
  - name: web
    count: 5
images:
  - name: web
    newTag: "1.4.2"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 90: Terapkan overlay Kustomize

Lihat diff dulu, lalu terapkan.

kubectl kustomize overlays/prod | kubectl diff -f -
kubectl apply -k overlays/prod

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 14: Observabilitas dan debugging

Saat Pod berperilaku tidak semestinya, jawabannya ada di status, event, log, dan metriknya. Rutinitas yang tenang dan berurutan menemukan sebagian besar gangguan dengan cepat, dan sinyal yang sama juga menjadi bahan dasbor dan peringatan.

Status, event, dan describe

kubectl get pod menampilkan fase dan jumlah restart. kubectl describe mendaftar event seperti ImagePullBackOff, CrashLoopBackOff, atau FailedScheduling, dan menjelaskan mengapa Pod macet.

Log lintas Pod

Pilih Pod berdasarkan label dengan kubectl logs -l dan gunakan --prefix untuk melihat Pod mana yang menulis setiap baris. Gunakan --previous untuk membaca log kontainer yang crash lalu di-restart.

Kontainer debug sementara

kubectl debug melampirkan kontainer sementara ke Pod yang sedang berjalan, sehingga Anda dapat memakai alat yang tidak ada di image aplikasi, tanpa memulai ulang aplikasi.

Contoh 91: Log dari beberapa Pod

Pilih Pod dengan label.

kubectl logs -l app=web --all-containers --prefix --tail=20
kubectl logs -l app=web -f --max-log-requests=10

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 92: Mengapa Pod tidak mulai

Baca keluaran describe dan status kontainer.

kubectl describe pod web-6d4cf56db6-abcde
kubectl get pod web-6d4cf56db6-abcde -o jsonpath="{.status.containerStatuses[0].state}"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 93: Kontainer debug sementara

Debug Pod yang berjalan tanpa restart.

kubectl debug -it web-6d4cf56db6-abcde --image=busybox:1.36 --target=web -- sh

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 94: Event dan tekanan node

Temukan masalah kapasitas dan eviksi.

kubectl get events -A --sort-by=.lastTimestamp | tail -20
kubectl describe node worker-1 | grep -A5 "Conditions"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Topik 15: Operasi produksi dan GitOps

Produksi berarti rilis yang dapat diulang, pemeliharaan yang aman, dan pemulihan. GitOps menjaga klaster tetap sesuai dengan repositori Git, dan cadangan melindungi objek serta data yang tidak dapat dibangun ulang.

GitOps

Alat GitOps seperti Argo CD memantau repositori dan menerapkan manifesnya ke klaster. Setiap perubahan melewati pull request, dan selfHeal membatalkan perubahan manual yang menyimpang dari Git.

Pemeliharaan tanpa downtime

kubectl drain memindahkan Pod dari node sebelum Anda meningkatkannya, dan PodDisruptionBudget menjaga cukup replika tetap berjalan. Jalankan kubectl uncordon saat node siap lagi.

Cadangan dan pemulihan

Velero mencadangkan objek klaster dan volume persisten ke penyimpanan objek. Uji pemulihan di klaster terpisah, karena cadangan yang belum pernah dipulihkan belum terbukti.

Contoh 95: GitOps dengan Argo CD

Jaga klaster tetap sinkron dengan repositori Git.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: shop
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/example/shop-deploy
    targetRevision: main
    path: overlays/prod
  destination:
    server: https://kubernetes.default.svc
    namespace: shop
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 96: Deployment untuk produksi

Probe, batas, dan rollout aman digabung.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
  labels:
    app: api
spec:
  replicas: 3
  revisionHistoryLimit: 5
  selector:
    matchLabels:
      app: api
  strategy:
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: api
    spec:
      containers:
        - name: api
          image: registry.example.com/team/api:1.4.2
          ports:
            - containerPort: 8000
          resources:
            requests: {cpu: 250m, memory: 256Mi}
            limits: {memory: 512Mi}
          readinessProbe:
            httpGet: {path: /ready, port: 8000}
          livenessProbe:
            httpGet: {path: /healthz, port: 8000}

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 97: Cadangkan dengan Velero

Simpan objek dan volume klaster ke penyimpanan.

velero install --provider azure --plugins velero/velero-plugin-for-microsoft-azure:v1.10.0 --bucket k8s-backups
velero backup create shop-daily --include-namespaces shop
velero backup describe shop-daily

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 98: Drain dan uncordon node

Pemeliharaan tanpa mematikan Pod.

kubectl cordon worker-1
kubectl drain worker-1 --ignore-daemonsets --delete-emptydir-data
kubectl uncordon worker-1

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 99: Periksa replika dari Python

Gunakan klien Kubernetes resmi.

from kubernetes import client, config

config.load_kube_config()
apps = client.AppsV1Api()
for d in apps.list_namespaced_deployment("shop").items:
    ready = d.status.ready_replicas or 0
    print(d.metadata.name, f"{ready}/{d.spec.replicas}")

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Contoh 100: Skrip daftar periksa rilis

Hentikan rilis jika ada pemeriksaan yang gagal.

#!/usr/bin/env bash
set -euo pipefail
NS="$1"
kubectl -n "$NS" rollout status deployment --timeout=180s
kubectl -n "$NS" get pdb
kubectl -n "$NS" auth can-i --list --as=system:serviceaccount:"$NS":default | grep -q "\*" && { echo "default account has wildcard rights"; exit 1; }
kubectl -n "$NS" get pods -o jsonpath="{range .items[*]}{.metadata.name}{' runAsRoot='}{.spec.securityContext.runAsNonRoot}{'\n'}{end}"
echo "release checks passed for namespace $NS"

*Contoh ini tidak dijalankan di sini karena klaster Kubernetes atau kubectl tidak terpasang di komputer yang menyiapkan artikel ini.*

Lab: Terapkan, Ekspos, dan Rilis Aplikasi Web Kecil

Satukan artikel ini dalam satu klaster latihan: Deployment dengan probe dan limit, Service, Ingress, ConfigMap dan Secret, pembaruan bergulir dengan rollback, dan pemeriksaan rilis.

1. Buat klaster latihan dengan kind, lalu buat namespace shop dan jadikan sebagai default.

2. Terapkan Deployment dengan tiga replika, requests dan limits sumber daya, readiness probe, dan liveness probe.

3. Tambahkan Service ClusterIP dan periksa endpoint-nya, lalu panggil dari Pod sementara.

4. Buat ConfigMap untuk pengaturan dan Secret untuk kata sandi contoh, lalu pasang keduanya ke Pod.

5. Rilis versi image baru, pantau rollout, lalu batalkan dengan kubectl rollout undo.

6. Tambahkan Ingress untuk shop.example.com, lalu batasi API dengan NetworkPolicy.

7. Jalankan daftar periksa rilis dari contoh 100 terhadap namespace, dan hentikan jika ada pemeriksaan yang gagal.

Langkah berikutnya

Setelah lab, berlatih di klaster terkelola dalam langganan sandbox, pelajari chart Helm untuk aplikasi Anda sendiri, dan siapkan GitOps agar setiap perubahan ditinjau di Git. Simpan contoh di repositori dan jalankan ulang saat Anda meningkatkan klaster, karena API Kubernetes berubah antarversi.

Ringkasan

Kubernetes menjaga kontainer Anda tetap berjalan, menyebarkannya ke seluruh node, memperbaruinya tanpa downtime, dan menskalakannya sesuai permintaan. Anda telah mempelajari kubectl dan konteks, Pod, Deployment dan rollback, Service dan Ingress, konfigurasi dan secret, penyimpanan, Job dan CronJob, StatefulSet dan DaemonSet, autoskala, permintaan sumber daya dan probe, RBAC dan keamanan Pod, Helm dan Kustomize, debugging, serta GitOps dengan cadangan untuk produksi.