Cara Mengonfigurasi Kubernetes untuk Pembaruan Bergulir

Pendahuluan

Pembaruan berkelanjutan adalah bagian penting dari siklus hidup aplikasi modern, dengan pengguna terus-menerus mengharapkan fitur baru dan nol waktu henti. Sementara Kubernetes menggunakan Pengontrol Replikasi untuk mengaktifkan fungsi ini di masa lalu, versi yang lebih baru merekomendasikan penggunaan Deployment.

Tutorial ini menunjukkan cara melakukan pembaruan bergulir menggunakan Kubernetes Deployments. Metode ini memungkinkan Anda memperbarui aplikasi dengan cepat dan mencapai waktu henti nol sambil memastikan dukungan rollback.

Prasyarat

• Kluster Kubernetes
• Akses ke jendela terminal
• Alat baris perintah kubectl

Aktifkan Pembaruan Bergulir

Kubernetes Deployments bertindak sebagai pembungkus di sekitar ReplicaSet, yang merupakan pengontrol Kubernetes yang bertanggung jawab atas manajemen pod. Deployment menyediakan fungsionalitas tambahan untuk ReplicaSet - mereka melakukan health check, rolling update, dan rollback.

1. Pertama, buat yaml file dengan spesifikasi penerapan menggunakan editor teks, seperti Nano:

nano nginx-test.yaml

Contoh file di bawah ini berisi deklarasi dasar yang diperlukan untuk Deployment Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2

        ports:
        - containerPort: 80

2. Simpan dan keluar dari file.

3. Kemudian, buat penerapan menggunakan kubectl create perintah dan yaml file yang baru saja Anda buat:

kubectl create -f nginx-test.yaml

4. Periksa penerapan:

kubectl get deployment

Keluaran harus mengonfirmasi bahwa penerapan sudah siap:

4. Selanjutnya cek ReplicaSets dengan menjalankan perintah:

kubectl get rs

File sampel menentukan empat replika, yang semuanya ditampilkan sebagai siap:

5. Terakhir, periksa apakah pod sudah aktif:

kubectl get pod

Output menunjukkan pod sebagai siap dan berjalan:

Pastikan Nol Waktu Henti

Untuk mengonfigurasi pembaruan bergulir tanpa waktu henti, Anda perlu menentukan strategi pembaruan.

1. Tambahkan deklarasi berikut ke penerapan yaml file di bawah spec kategori:

minReadySeconds: 5
strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

• minReadySeconds memberi tahu Kubernetes berapa lama ia harus menunggu hingga ia membuat pod berikutnya. Properti ini memastikan bahwa semua pod aplikasi dalam keadaan siap selama pembaruan.
• maxSurge menentukan jumlah maksimum (atau persentase) pod di atas jumlah replika yang ditentukan. Pada contoh di atas, jumlah maksimum pod adalah 5 sejak 4 replika ditentukan dalam yaml berkas.
• maxUnavailable mendeklarasikan jumlah (atau persentase) maksimum dari pod yang tidak tersedia selama pembaruan. Jika maxSurge disetel ke 0 , bidang ini tidak boleh 0 .

Menambahkan spesifikasi di atas ke penerapan yaml file cukup untuk mulai melakukan pembaruan bergulir Kubernetes. Namun, itu tidak menjamin waktu henti nol. Kubernetes tidak dapat mengetahui kapan pod baru siap - ia akan menghapus pod lama segera setelah pod baru dibuat. Masalah ini menyebabkan waktu henti hingga pod baru dapat menerima permintaan.

Untuk memperbaiki masalah ini, Kubernetes menampilkan konsep Readiness Probe . Probe memeriksa status pod dan memungkinkan pembaruan bergulir untuk dilanjutkan hanya ketika semua kontainer dalam pod sudah siap. Pod dianggap siap jika pemeriksaan kesiapan berhasil dan setelah waktu yang ditentukan dalam minReadySeconds telah berlalu.

2. Untuk menyiapkan Probe Kesiapan, tambahkan baris berikut ke spec.template.spec kategori dalam file penerapan:

readinessProbe:
  httpGet:
    path: /
    port: 8080
    initialDelaySeconds: 5
    periodSeconds: 5
    successThreshold: 1

• initialDelaySeconds menentukan berapa lama probe harus menunggu untuk memulai setelah container dimulai.
• periodSeconds adalah waktu antara dua probe. Standarnya adalah 10 detik, sedangkan nilai minimalnya adalah 1 kedua.
• successThreshold adalah jumlah minimum pemeriksaan yang berhasil berturut-turut setelah yang gagal agar seluruh proses dianggap berhasil. Nilai default dan minimal keduanya 1 .

Seluruh file penerapan yang dikonfigurasi dengan benar untuk pembaruan bergulir akan terlihat seperti ini:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 4
  selector:

    matchLabels:
      app: nginx
  minReadySeconds: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.0

        ports:
        - containerPort: 80
        readinessProbe:
          httpGet:
            path: /
            port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5
            successThreshold: 1
        

3. Simpan file dan keluar.

4. Kemudian, gunakan kubectl apply untuk menerapkan perubahan:

kubectl apply -f nginx-text.yaml --record

--record flag akan memiliki tujuan dalam proses rollback.

Keluaran menunjukkan bahwa penerapan telah berhasil dikonfigurasi.

Lakukan Pembaruan Bergulir

Ada tiga cara untuk melakukan pembaruan bergulir.

Misalnya, untuk mengubah gambar aplikasi:

Opsi 1:Anda dapat menggunakan kubectl set untuk melakukan tindakan pada baris perintah:

kubectl set image deployment nginx-deployment nginx=nginx:1.14.2 --record

Opsi 2:Atau, ubah versi gambar di spec.templates.spec.containers bagian yaml mengajukan. Kemudian, gunakan kubectl replace untuk melakukan pembaruan:

kubectl replace -f nginx-test.yaml

Opsi 3:Anda juga dapat menggunakan kubectl edit untuk mengedit penerapan secara langsung:

kubectl edit deployment nginx-deployment --record

Buat perubahan yang diperlukan di editor yang terbuka:

Perubahan diterapkan saat Anda menutup editor.

Periksa Status Peluncuran

Periksa status peluncuran penerapan menggunakan sintaks berikut:

kubectl rollout status deployment nginx-deployment

Output mengonfirmasi peluncuran yang berhasil:

Jeda dan Lanjutkan Pembaruan Bergulir

Jeda dan lanjutkan pembaruan bergulir dengan masing-masing kubectl rollout perintah.

Untuk menjeda pembaruan, jalankan:

kubectl rollout pause deployment nginx-deployment

Untuk melanjutkan pembaruan, jalankan:

kubectl rollout resume deployment nginx-deployment

Jadwalkan Pod untuk Deployment

Gunakan properti afinitas dan anti-afinitas untuk mengontrol node mana yang Kubernetes menjadwalkan pod tertentu dalam penerapan Anda.

Afinitas Pod

Ada dua jenis afinitas saat ini tersedia di Kubernetes:

• requiredDuringSchedulingIgnoredDuringExecution memberitahu Kubernetes untuk hanya menjalankan pod pada node yang memenuhi kriteria tertentu, seperti jenis prosesor tertentu.
• preferredDuringSchedulingIgnoredDuringExecution memungkinkan pod dijalankan di tempat lain, jika dan hanya jika tidak ada node yang memenuhi kriteria yang diberikan.

Properti ini tercantum dalam PodSpec mengajukan. Misalnya, sebuah pod dapat ditentukan sebagai berikut:

apiVersion: v1
kind: Pod
metadata:
  name: affinity-test
spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: kubernetes.io/test-name
            operator: In
            values:
            - test1
            - test2
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: example-node-label-key
            operator: In
            values:
            - example-node-label-value
  containers:
  - name: affinity-test
    image: k8s.gcr.io/pause:2.0

File di atas memberi tahu Kubernetes untuk menjalankan pod hanya pada node dengan label yang kuncinya adalah kubernetes.io/test-name dan yang nilainya adalah test1 atau test2 . Selanjutnya, Kubernetes akan memilih node yang kuncinya adalah example-node-label-key , dengan example-node-label-value nilai.

Anti-Afinitas Pod

Anti-afinitas pod berguna jika Anda tidak ingin semua pod dijalankan pada node yang sama. Ini berfungsi mirip dengan afinitas, dengan dua jenis yang sama tersedia - requiredDuringSchedulingIgnoredDuringExecution dan preferredDuringSchedulingIgnoredDuringExecution .

Contoh berikut menetapkan aturan anti-afinitas yang memberi tahu Kubernetes untuk menghindari penjadwalan pod aplikasi "test" ke node yang sudah memiliki pod "test":

podAntiAffinity:
  preferredDuringSchedulingIgnoredDuringExecution:
  - weight: 100
    podAffinityTerm:
      labelSelector:
        matchExpressions:
        - key: app
          operator: In
          values: 
          - test
      topologyKey: Kubernetes.io/hostname

Perubahan Kembalikan

Jika ada yang salah dengan proses pembaruan, Anda dapat mengembalikan perubahan dan kembali ke versi aplikasi sebelumnya. Untuk melakukannya, gunakan kubectl rollout berikut ini perintah:

kubectl rollout history deployment nginx-deployment

Output mencantumkan revisi yang tersedia, dibuat dengan menambahkan --record tandai saat melakukan pembaruan:

Pilih revisi yang Anda inginkan dan ketik perintah berikut untuk mengembalikan perubahan:

kubectl rollout undo deployment nginx-deployment --to-revision=1

Perintah di atas memutar kembali ke revisi 1 dan menghasilkan output berikut: