ProHoster > Blog > Pentadbiran > Menaik taraf Kluster Kubernetes Tanpa Masa Henti

Menaik taraf Kluster Kubernetes Tanpa Masa Henti

Menaik taraf Kluster Kubernetes Tanpa Masa Henti

Proses naik taraf untuk kluster Kubernetes anda

Pada satu ketika, apabila menggunakan kluster Kubernetes, terdapat keperluan untuk mengemas kini nod yang sedang berjalan. Ini mungkin termasuk kemas kini pakej, kemas kini kernel atau penggunaan imej mesin maya baharu. Dalam istilah Kubernetes ini dipanggil "Gangguan Sukarela".

Siaran ini adalah sebahagian daripada siri 4 jawatan:

  1. Jawatan ini.
  2. Penutupan pod yang betul dalam gugusan Kubernetes
  3. Penamatan pod tertunda apabila ia dipadamkan
  4. Cara Mengelakkan Masa Henti Kluster Kubernetes Menggunakan PodDisruptionBudgets

(lebih kurang. Jangkakan terjemahan artikel yang tinggal dalam siri ini dalam masa terdekat)

Dalam artikel ini, kami akan menerangkan semua alatan yang Kubernetes sediakan untuk mencapai masa henti sifar untuk nod yang berjalan dalam kluster anda.

Mendefinisikan masalah

Kami akan mengambil pendekatan naif pada mulanya, mengenal pasti masalah dan menilai potensi risiko pendekatan ini, dan membina pengetahuan untuk menyelesaikan setiap masalah yang kami hadapi sepanjang kitaran. Hasilnya ialah konfigurasi yang menggunakan cangkuk kitaran hayat, probe kesediaan dan belanjawan gangguan Pod untuk mencapai matlamat masa henti sifar kami.

Untuk memulakan perjalanan kita, mari kita ambil contoh konkrit. Katakan kita mempunyai kelompok Kubernetes dua nod, di mana aplikasi berjalan dengan dua pod terletak di belakang Service:

Menaik taraf Kluster Kubernetes Tanpa Masa Henti

Mari mulakan dengan dua pod dengan Nginx dan Perkhidmatan berjalan pada dua nod kluster Kubernetes kami.

Kami ingin mengemas kini versi kernel dua nod pekerja dalam kelompok kami. Bagaimana kita melakukan ini? Penyelesaian mudah adalah dengan boot nod baharu dengan konfigurasi yang dikemas kini dan kemudian menutup nod lama semasa memulakan yang baharu. Walaupun ini akan berfungsi, akan terdapat beberapa masalah dengan pendekatan ini:

  • Apabila anda mematikan nod lama, pod yang berjalan padanya juga akan dimatikan. Bagaimana jika pod perlu dibersihkan untuk penutupan yang anggun? Sistem virtualisasi yang anda gunakan mungkin tidak menunggu proses pembersihan selesai.
  • Bagaimana jika anda mematikan semua nod pada masa yang sama? Anda akan mendapat masa henti yang baik semasa pod berpindah ke nod baharu.

Kami memerlukan cara untuk memindahkan pod dari nod lama dengan anggun sambil memastikan tiada proses pekerja kami berjalan semasa kami membuat perubahan pada nod. Atau apabila kami melakukan penggantian lengkap kluster, seperti dalam contoh (iaitu, kami menggantikan imej VM), kami ingin memindahkan aplikasi yang sedang berjalan dari nod lama kepada yang baharu. Dalam kedua-dua kes, kami mahu menghalang pod baharu daripada dijadualkan pada nod lama, dan kemudian mengusir semua pod yang sedang berjalan daripadanya. Untuk mencapai matlamat ini kita boleh menggunakan arahan kubectl drain.

Mengagihkan semula semua pod daripada nod

Operasi longkang membolehkan anda mengagihkan semula semua pod daripada nod. Semasa pelaksanaan longkang, nod ditandakan sebagai tidak boleh dijadualkan (bendera NoSchedule). Ini menghalang pod baharu daripada muncul padanya. Kemudian longkang mula mengusir pod dari nod, menutup bekas yang sedang berjalan pada nod dengan menghantar isyarat TERM bekas dalam pod.

Walaupun kubectl drain akan melakukan kerja yang baik untuk mengusir pod, terdapat dua faktor lain yang boleh menyebabkan operasi longkang gagal:

  • Permohonan anda mesti boleh ditamatkan dengan baik apabila diserahkan TERM isyarat. Apabila pod diusir, Kubernetes menghantar isyarat TERM bekas dan menunggu mereka berhenti untuk jangka masa tertentu, selepas itu, jika mereka tidak berhenti, ia menamatkannya secara paksa. Walau apa pun, jika bekas anda tidak melihat isyarat dengan betul, anda masih boleh memadamkan pod secara tidak betul jika ia sedang dijalankan (contohnya, transaksi pangkalan data sedang dijalankan).
  • Anda kehilangan semua pod yang mengandungi aplikasi anda. Ia mungkin tidak tersedia apabila bekas baharu dilancarkan pada nod baharu atau jika pod anda digunakan tanpa pengawal, ia mungkin tidak dimulakan semula sama sekali.

Mengelakkan masa henti

Untuk meminimumkan masa henti akibat gangguan sukarela, seperti daripada operasi longkang pada nod, Kubernetes menyediakan pilihan pengendalian kegagalan berikut:

Dalam siri yang lain, kami akan menggunakan ciri Kubernetes ini untuk mengurangkan kesan pemindahan pod. Untuk memudahkan anda mengikuti idea utama, kami akan menggunakan contoh kami di atas dengan konfigurasi sumber berikut:

---
apiVersion: apps/v1
kind: Deployment
metadata:
 name: nginx-deployment
 labels:
   app: nginx
spec:
 replicas: 2
 selector:
   matchLabels:
     app: nginx
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx:1.15
       ports:
       - containerPort: 80
---
kind: Service
apiVersion: v1
metadata:
 name: nginx-service
spec:
 selector:
   app: nginx
 ports:
 - protocol: TCP
   targetPort: 80
   port: 80

Konfigurasi ini adalah contoh minimum Deployment, yang menguruskan pod nginx dalam kelompok. Di samping itu, konfigurasi menerangkan sumber Service, yang boleh digunakan untuk mengakses pod nginx dalam kelompok.

Sepanjang kitaran, kami akan mengembangkan konfigurasi ini secara berulang supaya ia akhirnya merangkumi semua keupayaan yang disediakan oleh Kubernetes untuk mengurangkan masa henti.

Untuk versi kemas kini kelompok Kubernetes yang dilaksanakan dan diuji sepenuhnya untuk masa henti sifar pada AWS dan seterusnya, lawati Gruntwork.io.

Baca juga artikel lain di blog kami:

Sumber: www.habr.com

Tambah komen