View a markdown version of this page

Penyeimbangan Beban - Amazon EKS
Memilih Jenis Penyeimbang BebanPenyeimbang Beban PenyediaanMemilih Load Balancer Target-TypeMengkonfigurasi Pemeriksaan Kesehatan Penyeimbang BebanKetersediaan dan Siklus Hidup PodReferensiLampiran

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Penyeimbangan Beban

Tip

Jelaj ahi praktik terbaik melalui lokakarya Amazon EKS.

Load Balancer menerima lalu lintas masuk dan mendistribusikannya ke seluruh target aplikasi yang dituju yang dihosting di Cluster EKS. Ini meningkatkan ketahanan aplikasi. Saat digunakan di Cluster EKS, pengontrol AWS Load Balancer akan membuat dan mengelola AWS Elastic Load Balancers untuk cluster tersebut. Ketika Layanan jenis Kubernetes LoadBalancer dibuat, AWS Load Balancer Controller membuat Network Load Balancer (NLB) yang menyeimbangkan beban lalu lintas yang diterima di Layer 4 model OSI. Sementara ketika objek Kubernetes Ingress dibuat, AWS Load Balancer Controller membuat Appl ication Load Balancer (ALB) yang menyeimbangkan beban lalu lintas di Layer 7 model OSI.

Memilih Jenis Penyeimbang Beban

Portofolio AWS Elastic Load Balancing (ELB) mendukung penyeimbang beban berikut: Application Load Balancers (ALB), Network Load Balancers (NLB), Gateway Load Balancers (GWLB), dan Classic Load Balancers (CLB). Bagian praktik terbaik ini akan fokus pada ALB dan NLB yang merupakan dua yang paling relevan untuk Kluster EKS.

Pertimbangan utama dalam memilih jenis penyeimbang beban adalah persyaratan beban kerja.

Untuk informasi lebih rinci dan sebagai referensi untuk semua penyeimbang beban AWS, lihat Perbandingan Produk

Pilih Application Load Balancer (ALB) jika beban kerja Anda adalah HTTP/HTTPS

Jika beban kerja memerlukan penyeimbangan beban di Layer 7 dari Model OSI, AWS Load Balancer Controller dapat digunakan untuk menyediakan ALB; kami membahas penyediaan di bagian berikut. ALB dikendalikan dan dikonfigurasi oleh sumber daya Ingress yang disebutkan sebelumnya dan merutekan lalu lintas HTTP atau HTTPS ke Pod yang berbeda dalam cluster. ALB memberi pelanggan fleksibilitas untuk mengubah algoritma routing lalu lintas aplikasi; algoritma routing default adalah round robin dengan algoritma routing permintaan yang paling tidak menonjol juga merupakan alternatif.

Pilih Network Load Balancer (NLB) jika beban kerja Anda adalah TCP, atau jika beban kerja Anda memerlukan Sumber IP Pelestarian Klien

Network Load Balancer berfungsi pada lapisan keempat (Transport) dari model Open Systems Interconnection (OSI). Sangat cocok untuk beban kerja berbasis TCP & UDP. Network Load Balancer juga secara default mempertahankan IP Sumber alamat klien saat menyajikan lalu lintas ke pod.

Pilih Network Load Balancer (NLB) jika beban kerja Anda tidak dapat menggunakan DNS

Alasan utama lain untuk menggunakan NLB adalah jika klien Anda tidak dapat menggunakan DNS. Dalam hal ini, NLB mungkin lebih cocok untuk beban kerja Anda karena IP pada Network Load Balancer bersifat statis. Sementara klien disarankan untuk menggunakan DNS saat menyelesaikan Nama Domain ke Alamat IP saat menghubungkan ke Load Balancers, jika aplikasi klien tidak mendukung resolusi DNS dan hanya menerima IP kode keras maka NLB lebih cocok karena IP statis dan tetap sama selama masa pakai NLB.

Penyeimbang Beban Penyediaan

Setelah menentukan Load Balancer yang paling cocok untuk beban kerja Anda, pelanggan memiliki sejumlah opsi untuk menyediakan penyeimbang beban.

Menyediakan Load Balancer dengan menerapkan AWS Load Balancer Controller

Ada dua metode utama penyediaan penyeimbang beban dalam Cluster EKS.

  • Memanfaatkan Pengontrol Layanan di Penyedia Cloud AWS (lama)

  • Memanfaatkan AWS Load Balancer Controller (disarankan)

Secara default, Pengontrol Layanan Kubernetes, juga dikenal sebagai pengontrol dalam pohon, merekonsiliasi sumber daya jenis Layanan Kubernetes. LoadBalancer Pengontrol ini dibangun ke dalam komponen AWS Cloud Provider yang berfungsi sebagai Kubernetes Cloud Controller Manager.

Konfigurasi Elastic Load Balancer yang disediakan dikendalikan oleh anotasi yang harus ditambahkan ke manifes Layanan Kubernetes. Anotasi yang digunakan oleh Service Controller dan AWS Load Balancer Controller berbeda.

Pengontrol Layanan adalah warisan dan saat ini hanya menerima perbaikan bug kritis. Saat Anda membuat jenis Layanan Kubernetes LoadBalancer, Pengontrol Layanan membuat AWS CLB secara default, tetapi juga dapat membuat AWS NLB jika Anda menggunakan anotasi yang tepat. Perlu dicatat bahwa Service Controller tidak mendukung sumber daya Kubernetes Ingress dan juga tidak mendukung IPv6.

Sebaiknya gunakan AWS Load Balancer Controller di cluster EKS Anda untuk merekonsiliasi sumber daya Layanan Kubernetes dan Ingress. Anda harus menggunakan anotasi yang tepat di Layanan Kubernetes atau manifes Ingress agar AWS Load Balancer Controller memiliki proses rekonsiliasi. (bukan Pengontrol Layanan)

Jika Anda menggunakan Mode Otomatis EKS, AWS Load Balancer Controller disediakan untuk Anda secara otomatis; tidak perlu instalasi.

Memilih Load Balancer Target-Type

Daftarkan Pod sebagai target menggunakan IP Target-Type

AWS Elastic Load Balancer: Jaringan & Aplikasi, mengirimkan lalu lintas yang diterima ke target terdaftar dalam kelompok target. Untuk Cluster EKS ada 2 jenis target yang dapat Anda daftarkan di grup target: Instance & IP, jenis target mana yang digunakan memiliki implikasi pada apa yang didaftarkan dan bagaimana lalu lintas dialihkan dari Load Balancer ke pod. Secara default, pengontrol AWS Load Balancer akan mendaftarkan target menggunakan tipe “Instance” dan target ini akan menjadi IP Worker Node danNodePort, implikasinya meliputi:

  • Lalu lintas dari Load Balancer akan diteruskan ke Worker Node di NodePort, ini diproses oleh aturan iptables (dikonfigurasi oleh kube-proxy yang berjalan di node), dan diteruskan ke Layanan di ClusterIP-nya (masih di node), akhirnya Layanan secara acak memilih pod yang terdaftar padanya dan meneruskan lalu lintas ke sana. Alur ini melibatkan beberapa lompatan dan latensi ekstra dapat terjadi terutama karena Layanan terkadang akan memilih pod yang berjalan pada node pekerja lain yang mungkin juga berada di AZ lain.

  • Karena Load Balancer mendaftarkan Worker Node sebagai targetnya, ini berarti pemeriksaan kesehatannya yang dikirim ke target tidak akan langsung diterima oleh pod tetapi oleh Worker Node pada nya NodePort dan lalu lintas pemeriksaan kesehatan akan mengikuti jalur yang sama yang dijelaskan di atas.

  • Pemantauan dan Pemecahan Masalah lebih kompleks karena lalu lintas yang diteruskan oleh Load Balancer tidak langsung dikirim ke pod dan Anda harus hati-hati mengkorelasikan paket yang diterima di Worker Node ke Service ClusterIP dan akhirnya pod untuk memiliki visibilitas ujung ke ujung penuh ke jalur paket untuk pemecahan masalah yang tepat.

Diagram yang menggambarkan jenis target instance untuk penyeimbang beban

Sebaliknya jika Anda mengonfigurasi tipe target sebagai “IP” seperti yang kami sarankan implikasinya adalah sebagai berikut:

  • Lalu lintas dari Load Balancer akan diteruskan langsung ke pod, ini menyederhanakan jalur jaringan karena melewati hop tambahan sebelumnya dari Worker Nodes dan IP Cluster Layanan, ini mengurangi latensi yang seharusnya terjadi jika Layanan meneruskan lalu lintas ke pod di AZ lain dan terakhir menghapus pemrosesan overhead aturan iptables pada Worker Nodes.

  • Pemeriksaan kesehatan Load Balancer langsung diterima dan ditanggapi oleh pod, ini berarti status target “sehat” atau “tidak sehat” adalah representasi langsung dari status kesehatan pod.

  • Pemantauan dan Pemecahan Masalah lebih mudah dan alat apa pun yang digunakan untuk menangkap alamat IP paket akan secara langsung mengungkapkan lalu lintas dua arah antara Load Balancer dan pod di bidang sumber dan tujuannya.

Diagram yang menggambarkan tipe target alamat IP untuk penyeimbang beban

Untuk membuat AWS Elastic Load Balancing yang menggunakan Target IP, Anda tambahkan:

  • alb.ingress.kubernetes.io/target-type: ipanotasi ke manifes Ingress Anda saat mengonfigurasi Kubernetes Ingress (Application Load Balancer)

  • service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ipanotasi ke Manifes Layanan Anda saat mengonfigurasi jenis Layanan Kubernetes Anda LoadBalancer (Network Load Balancer).

Mengkonfigurasi Pemeriksaan Kesehatan Penyeimbang Beban

Sementara Kubernetes menyediakan mekanisme pemeriksaan kesehatannya sendiri (dirinci di bagian berikutnya), kami merekomendasikan penerapan pemeriksaan kesehatan ELB sebagai perlindungan pelengkap yang berfungsi di luar bidang kontrol Kubernetes. Lapisan independen ini terus memantau aplikasi Anda bahkan selama:

  • Kubernetes mengontrol gangguan pesawat

  • Penundaan eksekusi probe

  • Partisi jaringan antara kubelet dan pod

Untuk beban kerja kritis yang membutuhkan pemulihan akselerasi ketersediaan maksimum selama skenario yang disebutkan di atas, pemeriksaan kesehatan ELB menyediakan jaring pengaman penting yang bekerja bersama — bukan menggantikan — mekanisme asli Kubernetes.

Untuk mengonfigurasi dan menyempurnakan pemeriksaan kesehatan pada ELB Anda, Anda harus menggunakan anotasi di Layanan Kubernetes atau manifes Ingress yang akan direkonsiliasi oleh Service Controller atau AWS Load Balancer Controller.

Ketersediaan dan Siklus Hidup Pod

Selama pemutakhiran aplikasi, Anda harus memastikan bahwa aplikasi Anda selalu tersedia untuk memproses permintaan sehingga pengguna tidak mengalami downtime. Salah satu tantangan umum dalam skenario ini adalah menyinkronkan status ketersediaan beban kerja Anda antara lapisan Kubernetes, dan infrastruktur, misalnya Load Balancers eksternal. Beberapa bagian berikutnya menyoroti praktik terbaik untuk mengatasi skenario tersebut.

catatan

Penjelasan di bawah ini didasarkan pada EndpointSlices karena merupakan pengganti yang direkomendasikan untuk Titik Akhir di Ku bernetes. Perbedaan antara keduanya dapat diabaikan dalam konteks skenario yang dibahas di bawah ini. AWS Load Balancer Controller secara default menggunakan Endpoint, Anda dapat mengaktifkan EndpointSlices dengan mengaktifkan enable- endpoint-sliceflag pada pengontrol.

Gunakan pemeriksaan kesehatan

Kubernetes secara default menjalankan pemeriksaan kesehatan proses di mana proses kubelet pada node memverifikasi apakah proses utama container sedang berjalan atau tidak. Jika tidak maka secara default ia memulai ulang wadah itu. Namun Anda juga dapat mengonfigurasi probe Kubernetes untuk mengidentifikasi kapan proses kontainer sedang berjalan tetapi dalam keadaan kebuntuan, atau apakah aplikasi telah berhasil dimulai atau tidak. Probe dapat didasarkan pada mekanisme exec, grpc, httpGet dan tcpSocket. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#probe-check-methods Berdasarkan jenis dan hasil probe, wadah dapat dimulai ulang.

Silakan lihat Pem buatan Pod di bagian Lampiran di bawah ini untuk meninjau kembali urutan peristiwa dalam proses pembuatan Pod.

Gunakan probe kesiapan

Secara default ketika semua kontainer dalam Pod sedang menjalankan kondisi Pod dianggap “Siap”. Namun aplikasi mungkin masih tidak dapat memproses permintaan klien. Misalnya aplikasi mungkin perlu menarik beberapa data atau konfigurasi dari sumber daya eksternal untuk dapat memproses permintaan. Dalam keadaan seperti itu Anda tidak akan ingin mematikan aplikasi atau meneruskan permintaan apa pun kepadanya. Probe kesiapan memungkinkan Anda untuk memastikan bahwa Pod tidak dianggap “Siap”, yang berarti bahwa itu tidak akan ditambahkan ke EndpointSlice objek, sampai hasil probe adasuccess. Di sisi lain jika probe gagal lebih jauh ke bawah maka Pod dihapus dari EndpointSlice objek. Anda dapat mengonfigurasi probe kesiapan di manifes Pod untuk setiap wadah. kubeletproses pada setiap node menjalankan probe kesiapan terhadap wadah pada node itu.

Memanfaatkan gerbang kesiapan Pod

Salah satu aspek dari probe kesiapan adalah kenyataan bahwa tidak ada feedback/influence mekanisme eksternal di dalamnya, proses kubelet pada node mengeksekusi probe dan mendefinisikan keadaan probe. Ini tidak berdampak pada permintaan antara layanan mikro itu sendiri di lapisan Kubernetes (lalu lintas timur barat) karena EndpointSlice Controller selalu memperbarui daftar titik akhir (Pod). Mengapa dan kapan Anda membutuhkan mekanisme eksternal?

Ketika Anda mengekspos aplikasi menggunakan jenis Layanan Kubernetes dari Load Balancer atau Kubernetes Ingress (untuk lalu lintas utara - selatan) maka daftar IP Pod untuk Layanan Kubernetes masing-masing harus disebarkan ke penyeimbang beban infrastruktur eksternal sehingga penyeimbang beban juga memiliki target daftar terbaru. AWS Load Balancer Controller men jembatani celah di sini. Saat Anda menggunakan AWS Load Balancer Controller dan leveragetarget group: IP, sama seperti kube-proxy AWS Load Balancer Controller juga menerima pembaruan (viawatch) dan kemudian berkomunikasi dengan API ELB untuk mengonfigurasi dan mulai mendaftarkan IP Pod sebagai target di ELB.

Saat Anda melakukan pembaruan bergulir dari Deployment, Pod baru akan dibuat, dan segera setelah kondisi Pod baru “Siap”, old/existing Pod akan dihentikan. Selama proses ini, EndpointSlice objek Kubernetes diperbarui lebih cepat daripada waktu yang dibutuhkan ELB untuk mendaftarkan Pod baru sebagai target, lihat pendaftaran target. https://docs.aws.amazon.com/elasticloadbalancing/latest/application/target-group-register-targets.html Untuk waktu yang singkat Anda mungkin memiliki ketidakcocokan status antara lapisan Kubernetes dan lapisan infrastruktur tempat permintaan klien dapat dihapus. Selama periode ini dalam lapisan Kubernetes, Pod baru akan siap untuk memproses permintaan tetapi dari sudut pandang ELB tidak.

Pod Readiness Gates memungkinkan Anda menentukan persyaratan tambahan yang harus dipenuhi sebelum kondisi Pod dianggap “Siap”. Dalam kasus AWS ELB, AWS Load Balancer Controller memantau status target (Pod) pada AWS ELB dan setelah pendaftaran target selesai dan statusnya berubah menjadi “Sehat” maka pengontrol memperbarui kondisi Pod menjadi “Siap”. Dengan pendekatan ini Anda memengaruhi kondisi Pod berdasarkan status jaringan eksternal, yang merupakan status target pada AWS ELB. Pod Readiness Gates sangat penting dalam skenario pembaruan bergulir karena memungkinkan Anda mencegah pembaruan bergulir penerapan menghentikan pod lama hingga status target Pod yang baru dibuat berubah menjadi “Sehat” di AWS ELB.

Matikan aplikasi dengan anggun

Aplikasi Anda harus merespons sinyal SIGTERM dengan memulai shutdown yang anggun sehingga klien tidak mengalami downtime. Artinya, aplikasi Anda harus menjalankan prosedur pembersihan seperti menyimpan data, menutup deskriptor file, menutup koneksi database, menyelesaikan permintaan dalam penerbangan dengan anggun dan keluar tepat waktu untuk memenuhi permintaan penghentian Pod. Anda harus mengatur masa tenggang cukup lama sehingga pembersihan dapat selesai. Untuk mempelajari cara menanggapi sinyal SIGTERM, Anda dapat merujuk ke sumber daya dari masing-masing bahasa pemrograman yang Anda gunakan untuk aplikasi Anda.

Jika aplikasi Anda tidak dapat dimatikan dengan anggun setelah menerima sinyal SIGTERM atau jika ignores/does tidak menerima sinyal, maka Anda dapat memanfaatkan PreStop hook untuk memulai shutdown aplikasi yang anggun. Prestop hook dijalankan segera sebelum sinyal SIGTERM dikirim dan dapat melakukan operasi sewenang-wenang tanpa harus mengimplementasikan operasi tersebut dalam kode aplikasi itu sendiri.

Urutan keseluruhan peristiwa ditunjukkan pada diagram di bawah ini. Catatan: terlepas dari hasil prosedur shutdown aplikasi yang anggun, atau hasil peng PreStop ait, wadah aplikasi akhirnya dihentikan pada akhir masa tenggang melalui SIGKILL.

Diagram urutan proses untuk penghentian pod

Silakan lihat Penghapusan Pod di bagian Lampiran di bawah ini untuk meninjau kembali urutan kejadian dalam proses penghapusan Pod.

Tangani permintaan klien dengan anggun

Urutan peristiwa dalam penghapusan Pod berbeda dengan pembuatan Pod. Ketika Pod dibuat kubelet memperbarui IP Pod di Kubernetes API dan hanya kemudian EndpointSlice objek diperbarui. Di sisi lain ketika Pod dihentikan, API Kubernetes memberi tahu kubelet dan EndpointSlice pengontrol secara bersamaan. Hati-hati memeriksa diagram berikut yang menunjukkan urutan peristiwa.

Diagram mengilustrasikan proses untuk memperbarui kubelet

Cara status menyebar dari server API ke aturan iptables pada node yang dijelaskan di atas menciptakan kondisi balapan yang menarik. Karena ada kemungkinan besar bahwa wadah menerima sinyal SIGKILL jauh lebih awal daripada kube-proxy pada setiap node memperbarui aturan iptables lokal. Dalam peristiwa seperti itu dua skenario yang layak disebutkan adalah:

  • Jika aplikasi Anda segera dan terus terang membatalkan permintaan dan koneksi dalam penerbangan setelah menerima SIGTERM yang berarti klien akan melihat kesalahan 50x di semua tempat.

  • Bahkan jika aplikasi Anda memastikan bahwa semua permintaan dan koneksi dalam penerbangan diproses sepenuhnya setelah menerima SIGTERM, selama masa tenggang, permintaan klien baru masih akan dikirim ke wadah aplikasi karena aturan iptables mungkin masih belum diperbarui. Sampai prosedur pembersihan menutup soket server pada wadah, permintaan baru tersebut akan menghasilkan koneksi baru. Ketika masa tenggang berakhir, koneksi tersebut, yang dibuat setelah SIGTERM, pada saat itu dihentikan tanpa syarat sejak SIGKILL dikirim.

Menyetel masa tenggang dalam spesifikasi Pod cukup lama dapat mengatasi tantangan ini tetapi tergantung pada penundaan propagasi dan jumlah permintaan klien aktual, sulit untuk mengantisipasi waktu yang dibutuhkan aplikasi untuk menutup koneksi dengan anggun. Oleh karena itu pendekatan yang tidak begitu sempurna tetapi paling layak di sini adalah menggunakan PreStop kait untuk menunda sinyal SIGTERM sampai aturan iptables diperbarui untuk memastikan bahwa tidak ada permintaan klien baru yang dikirim ke aplikasi, melainkan hanya koneksi yang ada yang melanjutkan. PreStop hook bisa menjadi handler Exec sederhana sepertisleep 10.

Perilaku dan rekomendasi yang disebutkan di atas akan sama berlaku saat Anda mengekspos aplikasi menggunakan jenis Layanan Kubernetes dari Load Balancer atau Kubernetes Ingress (untuk lalu lintas utara-selatan) menggunakan AWS Load Balancer Controller dan leverage. target group: IP Karena sama seperti kube-proxy AWS Load Balancer Controller juga menerima pembaruan (melalui watch) pada EndpointSlice objek dan kemudian berkomunikasi dengan API ELB untuk mulai deregistrasi IP Pod dari ELB. Namun tergantung pada beban pada Kubernetes API atau API ELB, ini juga dapat memakan waktu dan SIGTERM mungkin sudah dikirim ke aplikasi sejak lama. Setelah ELB mulai membatalkan pendaftaran target, ia berhenti mengirim permintaan ke target itu sehingga aplikasi tidak akan menerima permintaan baru dan ELB juga memulai penundaan https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-target-groups.html#deregistration-delay Deregistrasi yang 300 detik secara default. Selama proses deregistrasi, target adalah draining di mana pada dasarnya ELB menunggu requests/existing koneksi dalam penerbangan ke target itu habis. Setelah penundaan deregistrasi berakhir maka target tidak digunakan dan permintaan dalam penerbangan ke target tersebut dibatalkan secara paksa.

Gunakan anggaran gangguan Pod

Konfigurasikan Pod Disruption Budget (PDB) untuk aplikasi Anda. PDBLImMengirimkan jumlah Pod dari aplikasi yang direplikasi yang turun secara bersamaan dari gangguan sukarela. Ini memastikan bahwa jumlah minimum atau persentase pod tetap tersedia di StatefulSet atau Deployment. Misalnya, aplikasi berbasis kuorum perlu memastikan bahwa jumlah replika yang berjalan tidak pernah dibawah jumlah yang dibutuhkan untuk kuorum. Atau front end web mungkin memastikan bahwa jumlah replika yang melayani beban tidak pernah turun di bawah persentase tertentu dari total. PDB akan melindungi aplikasi dari tindakan seperti node yang terkuras, atau versi baru Deployments yang diluncurkan. Perlu diingat bahwa PDB tidak akan melindungi aplikasi dari gangguan yang tidak disengaja seperti kegagalan sistem operasi node atau hilangnya konektivitas jaringan. Untuk informasi selengkapnya, silakan merujuk ke Men entukan Anggaran Gangguan untuk Aplikasi Anda di dokumentasi Kubernetes.

Referensi

Lampiran

Pembuatan Pod

Sangat penting untuk memahami apa urutan peristiwa dalam skenario di mana Pod digunakan dan kemudian menerima dan healthy/ready memproses permintaan klien. Mari kita bicara tentang urutan peristiwa.

  1. Pod dibuat pada bidang kontrol Kubernetes (yaitu dengan perintah kubectl, atau pembaruan Deployment, atau tindakan penskalaan).

  2. kube-schedulermenetapkan Pod ke node di cluster.

  3. Proses kubelet yang berjalan pada node yang ditetapkan menerima pembaruan (viawatch) dan berkomunikasi dengan runtime container untuk memulai kontainer yang ditentukan dalam spesifikasi Pod.

  4. Saat kontainer mulai berjalan, kubelet memperbarui kondisi https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions Pod seperti pada objek Pod Ready di API Kubernetes.

  5. Peng EndpointSlice ontrol menerima pembaruan kondisi Pod (viawatch) dan menambahkan Pod IP/Port sebagai titik akhir baru ke EndpointSlice objek (daftar IP Pod) dari Layanan Kubernetes masing-masing.

  6. https://kubernetes.io/docs/concepts/overview/components/#kube-proxyproses kube-proxy pada setiap node menerima pembaruan (viawatch) pada EndpointSlice objek dan kemudian memperbarui aturan iptables pada setiap node, dengan Pod baru. IP/port

Penghapusan Pod

Sama seperti pembuatan Pod, sangat penting untuk memahami apa urutan peristiwa selama penghapusan Pod. Mari kita bicara tentang urutan peristiwa.

  1. Permintaan penghapusan Pod dikirim ke server API Kubernetes (yaitu dengan kubectl perintah, atau pembaruan Deployment, atau tindakan penskalaan).

  2. Server API Kubernetes memulai masa tenggang, yaitu 30 detik secara default, dengan menyetel bidang deletionTimest amp di objek Pod. (Masa tenggang dapat dikonfigurasi dalam spesifikasi Pod melaluiterminationGracePeriodSeconds)

  3. kubeletProses yang berjalan pada node menerima pembaruan (melalui arloji) pada objek Pod dan mengirimkan sinyal SIGTERM untuk memproses pengenal 1 (PID 1) di dalam setiap wadah di Pod tersebut. Kemudian mengawasiterminationGracePeriodSeconds.

  4. Peng EndpointSlice ontrol juga menerima pembaruan (viawatch) dari Langkah 2 dan menetapkan kondisi titik akhir ke “terminating” di EndpointSlice objek (daftar IP Pod) dari Layanan Kubernetes masing-masing.

  5. https://kubernetes.io/docs/concepts/overview/components/#kube-proxyproses kube-proxy pada setiap node menerima pembaruan (viawatch) pada EndpointSlice objek kemudian aturan iptables pada setiap node diperbarui oleh kube-proxy untuk berhenti meneruskan permintaan klien ke Pod.

  6. Ketika ked terminationGracePeriodSeconds aluwarsa maka kubelet mengirimkan sinyal SIGKILL ke proses induk dari setiap wadah di Pod dan secara paksa menghentikannya.

  7. TheEndpointSliceController menghapus titik akhir dari EndpointSlice objek.

  8. Server API menghapus objek Pod.