Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Praktik Terbaik untuk Penerapan Hybrid
Panduan ini memberikan panduan tentang menjalankan penerapan di lingkungan on-premise atau edge dengan EKS Hybrid Nodes atau EKS Anywhere.
Saat ini kami telah menerbitkan panduan untuk topik-topik berikut:
+ [Praktik Terbaik untuk Node Hibrid EKS dan pemutusan jaringan](hybrid-nodes-network-disconnections.md)
# EKS Hybrid Node dan pemutusan jaringan
Arsitektur EKS Hybrid Nodes dapat menjadi hal baru bagi pelanggan yang terbiasa menjalankan cluster Kubernetes lokal sepenuhnya di pusat data atau lokasi edge mereka sendiri. Dengan EKS Hybrid Nodes, control plane Kubernetes berjalan di Wilayah AWS dan hanya node yang berjalan di lokasi, menghasilkan arsitektur klaster Kubernetes yang “diregangkan” atau “diperpanjang”.
Ini mengarah ke pertanyaan umum, “Apa yang terjadi jika node saya terputus dari bidang kontrol Kubernetes?”
Dalam panduan ini, kami menjawab pertanyaan itu melalui tinjauan topik-topik berikut. Disarankan untuk memvalidasi stabilitas dan keandalan aplikasi Anda melalui pemutusan jaringan karena setiap aplikasi dapat berperilaku berbeda berdasarkan dependensi, konfigurasi, dan lingkungannya. Lihat eks-hybrid-examples GitHub aws-samples/repo untuk penyiapan pengujian, prosedur, dan hasil yang dapat Anda referensikan untuk menguji pemutusan jaringan dengan EKS Hybrid Nodes dan aplikasi Anda sendiri. GitHub Repo juga berisi detail tambahan dari tes yang digunakan untuk memvalidasi perilaku yang dijelaskan dalam panduan ini.
+ [Praktik terbaik untuk stabilitas melalui pemutusan jaringan](hybrid-nodes-network-disconnection-best-practices.md)
+ [Perilaku failover pod Kubernetes melalui pemutusan jaringan](hybrid-nodes-kubernetes-pod-failover.md)
+ [Lalu lintas jaringan aplikasi melalui pemutusan jaringan](hybrid-nodes-app-network-traffic.md)
+ [Kredensi host melalui pemutusan jaringan](hybrid-nodes-host-creds.md)
# Praktik terbaik untuk stabilitas melalui pemutusan jaringan
## Jaringan yang sangat tersedia
Pendekatan terbaik untuk menghindari pemutusan jaringan antara node hybrid dan bidang kontrol Kubernetes adalah dengan menggunakan koneksi yang berlebihan dan tangguh dari lingkungan lokal Anda ke dan dari AWS. Lihat [AWS Direct Connect Resiliency Toolkit dan](https://docs.aws.amazon.com/directconnect/latest/UserGuide/resiliency_toolkit.html) [dokumentasi AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/vpn-redundant-connection.html) untuk informasi selengkapnya tentang merancang jaringan hybrid yang sangat tersedia dengan solusi tersebut.
## Aplikasi yang sangat tersedia
Saat merancang aplikasi, pertimbangkan domain kegagalan Anda dan efek dari berbagai jenis pemadaman. Kubernetes menyediakan mekanisme bawaan untuk menyebarkan dan memelihara replika aplikasi di seluruh domain node, zona, dan regional. Penggunaan mekanisme ini bergantung pada arsitektur aplikasi, lingkungan, dan persyaratan ketersediaan Anda. Misalnya, aplikasi stateless sering dapat digunakan dengan beberapa replika dan dapat berpindah melintasi host arbitrer dan kapasitas infrastruktur, dan Anda dapat menggunakan pemilih node dan batasan penyebaran topologi untuk menjalankan instance aplikasi di berbagai domain. [Untuk detail teknik tingkat aplikasi untuk membangun aplikasi tangguh di Kubernetes, lihat Panduan Praktik Terbaik EKS.](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/)
Kubernetes mengevaluasi informasi zonal untuk node yang terputus dari bidang kontrol Kubernetes saat menentukan apakah akan memindahkan pod ke node lain. Jika semua node di zona tidak dapat dijangkau, Kubernetes membatalkan penggusuran pod untuk node di zona tersebut. Sebagai praktik terbaik, jika Anda memiliki penyebaran dengan node yang berjalan di beberapa pusat data atau lokasi fisik, tetapkan zona ke setiap node berdasarkan pusat data atau lokasi fisiknya. Saat Anda menjalankan EKS dengan node di cloud, label zona ini diterapkan secara otomatis oleh AWS cloud-controller-manager. Namun, a tidak cloud-controller-manager digunakan dengan node hybrid, sehingga Anda dapat meneruskan informasi ini melalui konfigurasi kubelet Anda. Contoh cara mengkonfigurasi zona dalam konfigurasi node Anda untuk node hybrid ditunjukkan di bawah ini. Konfigurasi diteruskan ketika Anda menghubungkan node hybrid Anda ke cluster Anda dengan node hybrid CLI ()`nodeadm`. Untuk informasi lebih lanjut tentang `topology.kubernetes.io/zone` label, lihat dokumentasi [Kubernetes](https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone). Untuk informasi lebih lanjut tentang CLI node hybrid, lihat referensi nodeadm [Hybrid Nodes](https://docs.aws.amazon.com/eks/latest/userguide/hybrid-nodes-nodeadm.html).
```
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
region: my-region
kubelet:
flags:
- --node-labels=topology.kubernetes.io/zone=dc1
hybrid:
...
```
## Pemantauan jaringan
Jika Anda menggunakan AWS Direct Connect atau AWS Site-to-Site VPN untuk konektivitas hybrid, Anda dapat memanfaatkan CloudWatch alarm, log, dan metrik untuk mengamati status koneksi hybrid dan mendiagnosis masalah. Untuk informasi selengkapnya, lihat [Memantau sumber daya AWS Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/monitoring-overview.html) dan [Memantau koneksi AWS Site-to-Site VPN](https://docs.aws.amazon.com/vpn/latest/s2svpn/monitoring-overview-vpn.html).
Disarankan untuk membuat alarm untuk `NodeNotReady` peristiwa yang dilaporkan oleh node-lifecycle-controller berjalan pada bidang kontrol EKS, yang menandakan bahwa node hibrida mungkin mengalami pemutusan jaringan. Anda dapat membuat alarm ini dengan mengaktifkan pencatatan bidang kontrol EKS untuk Controller Manager dan membuat Filter Metrik CloudWatch untuk pesan “Merekam pesan peristiwa perubahan status untuk node” dengan status= “”. NodeNotReady Setelah membuat Filter Metrik, Anda dapat membuat alarm untuk filter ini berdasarkan ambang batas yang Anda inginkan. Untuk informasi selengkapnya, lihat [Mengkhawatirkan log dalam dokumentasi. CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Alarm-On-Logs.html)
Anda dapat menggunakan metrik bawaan Transit Gateway (TGW) dan Virtual Private Gateway (VGW) untuk mengamati lalu lintas jaringan masuk dan keluar dari TGW atau VGW Anda. Anda dapat membuat alarm untuk metrik ini untuk mendeteksi skenario di mana lalu lintas jaringan turun di bawah level normal, yang menunjukkan potensi masalah jaringan antara node hibrida dan bidang kontrol EKS. Metrik TGW dan VGW dijelaskan dalam tabel berikut.
| Gateway | Metrik | Deskripsi |
| --- | --- | --- |
| Transit Gateway | BytesIn | Byte yang diterima oleh TGW dari lampiran (bidang kontrol EKS ke node hibrida) |
| Transit Gateway | BytesOut | Byte dikirim dari TGW ke lampiran (node hibrida ke bidang kontrol EKS) |
| Gerbang Pribadi Virtual | TunnelDataIn | Byte yang dikirim dari sisi AWS koneksi melalui terowongan VPN ke gateway pelanggan (bidang kontrol EKS ke node hibrida) |
| Gerbang Pribadi Virtual | TunnelDataOut | Byte yang diterima di sisi AWS koneksi melalui terowongan VPN dari gateway pelanggan (node hybrid ke bidang kontrol EKS) |
Anda juga dapat menggunakan [CloudWatch Network Monitor](https://aws.amazon.com/blogs/networking-and-content-delivery/monitor-hybrid-connectivity-with-amazon-cloudwatch-network-monitor/) untuk mendapatkan wawasan yang lebih dalam tentang koneksi hybrid Anda guna mengurangi waktu pemulihan dan menentukan apakah masalah jaringan berasal dari AWS atau lingkungan Anda. CloudWatch Network Monitor dapat digunakan untuk memvisualisasikan kehilangan paket dan latensi dalam koneksi jaringan hybrid Anda, mengatur peringatan dan ambang batas, dan kemudian mengambil tindakan untuk meningkatkan kinerja jaringan Anda. Untuk informasi selengkapnya, lihat [Menggunakan Monitor CloudWatch Jaringan Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/what-is-network-monitor.html).
EKS menawarkan beberapa opsi untuk memantau kesehatan cluster dan aplikasi Anda. Untuk kesehatan klaster, Anda dapat menggunakan dasbor observabilitas di konsol EKS untuk mendeteksi, memecahkan masalah, dan memperbaiki masalah dengan cepat. Anda juga dapat menggunakan Amazon Managed Service untuk Prometheus, AWS Distro for Open Telemetry (ADOT), dan untuk pemantauan klaster, aplikasi CloudWatch , dan infrastruktur. Untuk informasi selengkapnya tentang opsi observabilitas EKS, lihat [Memantau kinerja klaster Anda dan melihat log](https://docs.aws.amazon.com/eks/latest/userguide/eks-observe.html).
## Pemecahan masalah lokal
Untuk mempersiapkan pemutusan jaringan antara node hibrida dan bidang kontrol EKS, Anda dapat menyiapkan backend pemantauan dan pencatatan sekunder untuk mempertahankan observabilitas aplikasi saat layanan AWS regional tidak dapat dijangkau. Misalnya, Anda dapat mengonfigurasi kolektor AWS Distro for Open Telemetry (ADOT) untuk mengirim metrik dan log ke beberapa backend. Anda juga dapat menggunakan alat lokal, seperti `crictl` CLI, untuk berinteraksi secara lokal dengan pod dan kontainer sebagai pengganti `kubectl` atau klien lain yang kompatibel dengan API Kubernetes yang biasanya menanyakan endpoint server API Kubernetes. Untuk informasi lebih lanjut tentang`crictl`, lihat [`crictl`dokumentasi](https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md) di cri-tools GitHub. Beberapa `crictl` perintah yang berguna tercantum di bawah ini.
Daftar pod yang berjalan di host:
```
crictl pods
```
Daftar kontainer yang berjalan di host:
```
crictl ps
```
Daftar gambar yang berjalan di host:
```
crictl images
```
Dapatkan log wadah yang berjalan di host:
```
crictl logs CONTAINER_NAME
```
Dapatkan statistik pod yang berjalan di host:
```
crictl statsp
```
## Lalu lintas jaringan aplikasi
Saat menggunakan node hybrid, penting untuk mempertimbangkan dan memahami arus jaringan lalu lintas aplikasi Anda dan teknologi yang Anda gunakan untuk mengekspos aplikasi Anda secara eksternal ke cluster Anda. Teknologi yang berbeda untuk penyeimbangan beban aplikasi dan masuknya berperilaku berbeda selama pemutusan jaringan. Misalnya, jika Anda menggunakan kemampuan BGP Control Plane Cilium untuk load balancing aplikasi, sesi BGP untuk pod dan layanan Anda mungkin tidak aktif selama pemutusan jaringan. Ini terjadi karena fungsi speaker BGP terintegrasi dengan agen Cilium, dan agen Cilium akan terus restart ketika terputus dari bidang kontrol Kubernetes. Alasan restart adalah karena pemeriksaan kesehatan Cilium gagal karena kesehatannya digabungkan dengan akses ke bidang kontrol Kubernetes (lihat [CFP: \$131702](https://github.com/cilium/cilium/issues/31702) dengan peningkatan keikutsertaan di Cilium v1.17). Demikian pula, jika Anda menggunakan Application Load Balancers (ALB) atau Network Load Balancers (NLB) untuk lalu lintas aplikasi yang berasal dari AWS Region, lalu lintas tersebut mungkin akan turun sementara jika lingkungan lokal Anda kehilangan konektivitas ke Wilayah AWS. Disarankan untuk memvalidasi bahwa teknologi yang Anda gunakan untuk load balancing dan ingress tetap stabil selama pemutusan jaringan sebelum diterapkan ke produksi. Contoh di [aws-samples/ eks-hybrid-examples](https://github.com/aws-samples/eks-hybrid-examples) GitHub repo menggunakan MetalLB untuk penyeimbangan beban dalam [mode L2](https://metallb.universe.tf/concepts/layer2/), yang tetap stabil selama pemutusan jaringan antara node hibrida dan bidang kontrol EKS.
## Tinjau dependensi pada layanan AWS jarak jauh
Saat menggunakan node hybrid, perhatikan dependensi yang Anda ambil pada layanan AWS regional yang berada di luar lingkungan lokal atau edge Anda. Contohnya termasuk mengakses Amazon S3 atau Amazon RDS untuk data aplikasi, menggunakan Amazon Managed Service untuk Prometheus atau untuk metrik dan log, menggunakan Application and Network Load Balancers untuk CloudWatch lalu lintas yang berasal dari Wilayah, dan menarik kontainer dari Amazon Elastic Container Registry. Layanan ini tidak akan dapat diakses selama pemutusan jaringan antara lingkungan lokal Anda dan AWS. Jika lingkungan lokal Anda rentan terhadap pemutusan jaringan dengan AWS, tinjau penggunaan layanan AWS Anda dan pastikan bahwa kehilangan koneksi ke layanan tersebut tidak mengganggu stabilitas statis aplikasi Anda.
## Tune perilaku failover pod Kubernetes
Ada opsi untuk menyetel perilaku failover pod selama pemutusan jaringan untuk aplikasi yang tidak portabel di seluruh host, atau untuk lingkungan terbatas sumber daya yang tidak memiliki kapasitas cadangan untuk failover pod. Secara umum, penting untuk mempertimbangkan persyaratan sumber daya aplikasi Anda dan memiliki kapasitas yang cukup untuk satu atau lebih contoh aplikasi gagal ke host yang berbeda jika node gagal.
+ Opsi 1 - Gunakan DaemonSets: Opsi ini berlaku untuk aplikasi yang dapat dan harus berjalan di semua node di cluster. DaemonSets secara otomatis dikonfigurasi untuk mentolerir taint yang tidak dapat dijangkau, yang membuat DaemonSet pod terikat ke node mereka melalui pemutusan jaringan.
+ Opsi 2 - Tune `tolerationSeconds` for unreachable taint: Anda dapat menyetel jumlah waktu pod Anda tetap terikat ke node selama pemutusan jaringan. Lakukan ini dengan mengonfigurasi pod aplikasi untuk mentolerir taint yang tidak dapat dijangkau dengan `NoExecute` efek selama durasi yang Anda tentukan (`tolerationSeconds`dalam spesifikasi aplikasi). Dengan opsi ini, ketika ada pemutusan jaringan, pod aplikasi Anda tetap terikat ke node hingga `tolerationSeconds` kedaluwarsa. Pertimbangkan hal ini dengan cermat, karena peningkatan `tolerationSeconds` untuk noda yang tidak dapat dijangkau dengan `NoExecute` berarti bahwa pod yang berjalan pada host yang tidak dapat dijangkau mungkin membutuhkan waktu lebih lama untuk pindah ke host lain yang sehat dan dapat dijangkau.
+ Opsi 3: Pengontrol kustom: Anda dapat membuat dan menjalankan pengontrol kustom (atau perangkat lunak lain) yang memantau Kubernetes untuk noda yang tidak dapat dijangkau dengan efeknya. `NoExecute` Ketika noda ini terdeteksi, pengontrol khusus dapat memeriksa metrik khusus aplikasi untuk menilai kesehatan aplikasi. Jika aplikasi sehat, pengontrol kustom dapat menghapus taint yang tidak dapat dijangkau, mencegah penggusuran pod dari node selama pemutusan jaringan.
Contoh cara mengonfigurasi Deployment dengan `tolerationSeconds` untuk taint yang tidak dapat dijangkau ditunjukkan di bawah ini. Dalam contoh, `tolerationSeconds` diatur ke `1800` (30 menit), yang berarti pod yang berjalan pada node yang tidak dapat dijangkau hanya akan diusir jika pemutusan jaringan berlangsung lebih dari 30 menit.
```
apiVersion: apps/v1
kind: Deployment
metadata:
...
spec:
...
tolerations:
- key: "node.kubernetes.io/unreachable"
operator: "Exists"
effect: "NoExecute"
tolerationSeconds: 1800
```
# Kubernetes pod failover melalui pemutusan jaringan
Kita mulai dengan meninjau konsep kunci, komponen, dan pengaturan yang mempengaruhi bagaimana Kubernetes berperilaku selama pemutusan jaringan antara node dan bidang kontrol Kubernetes. EKS adalah kesesuaian Kubernetes hulu, sehingga semua konsep, komponen, dan pengaturan Kubernetes yang dijelaskan di sini berlaku untuk penerapan EKS dan EKS Hybrid Nodes.
Ada perbaikan yang telah dilakukan pada EKS secara khusus untuk meningkatkan perilaku failover pod selama pemutusan jaringan, untuk informasi selengkapnya lihat GitHub masalah [\$1131294](https://github.com/kubernetes/kubernetes/pull/131294) dan [\$1131481](https://github.com/kubernetes/kubernetes/issues/131481) di repositori Kubernetes hulu.
## Konsep
Taints and Tolerations: Taints dan tolerations digunakan di Kubernetes untuk mengontrol penjadwalan pod ke node. Taints ditetapkan oleh node-lifecycle-controller untuk menunjukkan bahwa node tidak memenuhi syarat untuk penjadwalan atau bahwa pod pada node tersebut harus diusir. Ketika node tidak dapat dijangkau karena pemutusan jaringan, node akan diterapkan node.kubernetes. node-lifecycle-controller io/unreachable taint with a NoSchedule effect, and with a NoExecute effect if certain conditions are met. The node.kubernetes.io/unreachabletaint sesuai dengan NodeCondition Ready being Unknown. Pengguna dapat menentukan toleransi untuk noda di tingkat aplikasi di. PodSpec
+ NoSchedule: Tidak ada Pod baru yang dijadwalkan pada node yang tercemar kecuali mereka memiliki toleransi yang cocok. Pod yang sudah berjalan di node tidak diusir.
+ NoExecute: Pod yang tidak mentolerir noda segera diusir. Pod yang mentolerir taint (tanpa menentukan TolerationSeconds) tetap terikat selamanya. Pod yang mentolerir taint dengan TolerationSeconds tertentu tetap terikat untuk waktu yang ditentukan. Setelah waktu itu berlalu, pengontrol siklus hidup node mengeluarkan Pod dari node.
Node Leases: Kubernetes menggunakan Lease API untuk mengkomunikasikan detak jantung node kubelet ke server API Kubernetes. Untuk setiap node, ada objek Lease dengan nama yang cocok. Secara internal, setiap detak jantung kubelet memperbarui bidang spec.renewTime dari objek Lease. Bidang kontrol Kubernetes menggunakan stempel waktu bidang ini untuk menentukan ketersediaan node. Jika node terputus dari bidang kontrol Kubernetes, mereka tidak dapat memperbarui Spec.renewTime untuk Lease mereka, dan control plane menafsirkannya sebagai Ready being Unknown. NodeCondition
## Komponen-komponen
![\[Komponen Kubernetes yang terlibat dalam perilaku failover pod\]](http://docs.aws.amazon.com/id_id/eks/latest/best-practices/images/hybrid/k8s-components-pod-failover.png)
| Komponen | Sub-komponen | Deskripsi |
| --- | --- | --- |
| Pesawat kontrol Kubernetes | kube-api-server | Server API adalah komponen inti dari bidang kontrol Kubernetes yang mengekspos API Kubernetes. |
| Pesawat kontrol Kubernetes | node-lifecycle-controller | Salah satu pengontrol yang kube-controller-manager dijalankan. Ini bertanggung jawab untuk mendeteksi dan menanggapi masalah node. |
| Pesawat kontrol Kubernetes | penjadwal kube | Komponen control plane yang mengawasi Pod yang baru dibuat tanpa node yang ditetapkan, dan memilih node untuk dijalankan. |
| Node Kubernetes | kubelet | Agen yang berjalan pada setiap node di cluster. Kubelet mengawasi PodSpecs dan memastikan bahwa wadah yang dijelaskan di dalamnya berjalan dan sehat. PodSpecs |
## Pengaturan konfigurasi
| Komponen | Pengaturan | Deskripsi | K8s standar | EKS standar | Dapat dikonfigurasi di EKS |
| --- | --- | --- | --- | --- | --- |
| kube-api-server | default-unreachable-toleration-seconds | `tolerationSeconds`Menunjukkan toleransi untuk `unreachable:NoExecute` itu ditambahkan secara default ke setiap pod yang belum memiliki toleransi seperti itu. | 300 | 300 | Tidak |
| node-lifecycle-controller | node-monitor-grace-period | Jumlah waktu node dapat menjadi tidak responsif sebelum ditandai tidak sehat. Harus N kali lebih banyak dari kubelet`nodeStatusUpdateFrequency`, di mana N adalah jumlah percobaan ulang yang diizinkan untuk kubelet untuk memposting status node. | 40 | 40 | Tidak |
| node-lifecycle-controller | large-cluster-size-threshold | Jumlah node di mana cluster node-lifecycle-controller memperlakukan cluster sebagai besar untuk logika penggusuran. `--secondary-node-eviction-rate`diganti menjadi 0 untuk cluster dengan ukuran ini atau lebih kecil. | 50 | 100.000 | Tidak |
| node-lifecycle-controller | unhealthy-zone-threshold | Persentase node di zona yang harus Tidak Siap untuk zona itu diperlakukan sebagai tidak sehat. | 55% | 55% | Tidak |
| kubelet | node-status-update-frequency | Seberapa sering kubelet memposting status node ke bidang kontrol. Harus kompatibel dengan `nodeMonitorGracePeriod` in node-lifecycle-controller. | 10 | 10 | Ya |
| kubelet | label simpul | Label untuk ditambahkan saat mendaftarkan node di cluster. Label `topology.kubernetes.io/zone` dapat ditentukan dengan node hybrid untuk mengelompokkan node ke dalam zona. | Tidak ada | Tidak ada | Ya |
## Kubernetes pod failover melalui pemutusan jaringan
Perilaku yang dijelaskan di sini mengasumsikan pod berjalan sebagai Deployment Kubernetes dengan pengaturan default, dan EKS digunakan sebagai penyedia Kubernetes. Perilaku aktual mungkin berbeda berdasarkan lingkungan Anda, jenis pemutusan jaringan, aplikasi, dependensi, dan konfigurasi cluster. Konten dalam panduan ini divalidasi menggunakan aplikasi tertentu, konfigurasi cluster, dan subset plugin. Sangat disarankan untuk menguji perilaku di lingkungan Anda sendiri dan dengan aplikasi Anda sendiri sebelum pindah ke produksi.
Ketika ada pemutusan jaringan antara node dan bidang kontrol Kubernetes, kubelet pada setiap node yang terputus tidak dapat berkomunikasi dengan bidang kontrol Kubernetes. Akibatnya, kubelet tidak dapat mengusir pod pada node tersebut sampai koneksi dipulihkan. Ini berarti bahwa pod yang berjalan pada node tersebut sebelum pemutusan jaringan terus berjalan selama pemutusan, dengan asumsi tidak ada kegagalan lain yang menyebabkannya dimatikan. Singkatnya, Anda dapat mencapai stabilitas statis selama pemutusan jaringan antara node dan bidang kontrol Kubernetes, tetapi Anda tidak dapat melakukan operasi mutasi pada node atau beban kerja Anda sampai koneksi dipulihkan.
Ada lima skenario utama yang menghasilkan perilaku failover pod yang berbeda berdasarkan sifat pemutusan jaringan. Dalam semua skenario, cluster menjadi sehat kembali tanpa intervensi operator setelah node terhubung kembali ke bidang kontrol Kubernetes. Skenario di bawah menguraikan hasil yang diharapkan berdasarkan pengamatan kami, tetapi hasil ini mungkin tidak berlaku untuk semua kemungkinan aplikasi dan konfigurasi cluster.
### Skenario 1: Gangguan cluster penuh
**Hasil yang diharapkan**: Pod pada node yang tidak dapat dijangkau tidak diusir dan terus berjalan pada node tersebut.
Gangguan cluster penuh berarti semua node di cluster terputus dari bidang kontrol Kubernetes. Dalam skenario ini, node-lifecycle-controller on the control plane mendeteksi bahwa semua node di cluster tidak dapat dijangkau dan membatalkan penggusuran pod apa pun.
Administrator cluster akan melihat semua node dengan status `Not Ready` selama pemutusan. Status Pod tidak berubah, dan tidak ada pod baru yang dijadwalkan pada node manapun selama pemutusan dan penyambungan ulang berikutnya.
### Skenario 2: Gangguan zona penuh
**Hasil yang diharapkan**: Pod pada node yang tidak dapat dijangkau tidak diusir dan terus berjalan pada node tersebut.
Gangguan zona penuh berarti semua node di zona terputus dari bidang kontrol Kubernetes. Dalam skenario ini, node-lifecycle-controller on the control plane mendeteksi bahwa semua node di zona tidak dapat dijangkau dan membatalkan penggusuran pod apa pun.
Administrator cluster akan melihat semua node dengan status `Not Ready` selama pemutusan. Status Pod tidak berubah, dan tidak ada pod baru yang dijadwalkan pada node manapun selama pemutusan dan penyambungan ulang berikutnya.
### Skenario 3: Gangguan zona mayoritas
**Hasil yang diharapkan**: Pod pada node yang tidak dapat dijangkau tidak diusir dan terus berjalan pada node tersebut.
Gangguan zona mayoritas berarti bahwa sebagian besar node di zona tertentu terputus dari bidang kontrol Kubernetes. Zona di Kubernetes didefinisikan oleh node dengan label yang sama. `topology.kubernetes.io/zone` Jika tidak ada zona yang didefinisikan dalam cluster, gangguan mayoritas berarti mayoritas node di seluruh cluster terputus. Secara default, mayoritas didefinisikan oleh node-lifecycle-controller's`unhealthy-zone-threshold`, yang disetel ke 55% di Kubernetes dan EKS. Karena `large-cluster-size-threshold` disetel ke 100.000 di EKS, jika 55% atau lebih dari node di zona tidak dapat dijangkau, penggusuran pod dibatalkan (mengingat bahwa sebagian besar cluster jauh lebih kecil dari 100.000 node).
Administrator klaster akan melihat mayoritas node di zona dengan status `Not Ready` selama pemutusan, tetapi status pod tidak akan berubah, dan mereka tidak akan dijadwalkan ulang pada node lain.
Perhatikan bahwa perilaku di atas hanya berlaku untuk cluster yang lebih besar dari tiga node. Dalam klaster yang terdiri dari tiga node atau kurang, pod pada node yang tidak dapat dijangkau dijadwalkan untuk penggusuran, dan pod baru dijadwalkan pada node yang sehat.
Selama pengujian, kami kadang-kadang mengamati bahwa pod diusir dari tepat satu node yang tidak dapat dijangkau selama pemutusan jaringan, bahkan ketika sebagian besar node zona tidak dapat dijangkau. Kami masih menyelidiki kemungkinan kondisi balapan di Kubernetes node-lifecycle-controller sebagai penyebab perilaku ini.
### Skenario 4: Gangguan zona minoritas
**Hasil yang diharapkan**: Pod dikeluarkan dari node yang tidak dapat dijangkau, dan pod baru dijadwalkan pada node yang tersedia dan memenuhi syarat.
Gangguan minoritas berarti bahwa persentase node yang lebih kecil di zona terputus dari bidang kontrol Kubernetes. Jika tidak ada zona yang didefinisikan dalam cluster, gangguan minoritas berarti minoritas node di seluruh cluster terputus. Sebagaimana dinyatakan, minoritas didefinisikan oleh `unhealthy-zone-threshold` pengaturan node-lifecycle-controller, yaitu 55% secara default. Dalam skenario ini, jika pemutusan jaringan berlangsung lebih lama dari `default-unreachable-toleration-seconds` (5 menit) dan `node-monitor-grace-period` (40 detik), dan kurang dari 55% node di zona tidak dapat dijangkau, pod baru dijadwalkan pada node sehat sementara pod pada node yang tidak dapat dijangkau ditandai untuk penggusuran.
Administrator klaster akan melihat pod baru yang dibuat pada node yang sehat, dan pod pada node yang terputus akan ditampilkan sebagai. `Terminating` Ingatlah bahwa, meskipun Pod pada node yang terputus memiliki `Terminating` status, mereka tidak sepenuhnya diusir sampai node terhubung kembali ke bidang kontrol Kubernetes.
## Skenario 5: Node restart selama gangguan jaringan
**Hasil yang diharapkan**: Pod pada node yang tidak dapat dijangkau tidak dimulai sampai node terhubung kembali ke bidang kontrol Kubernetes. Failover Pod mengikuti logika yang dijelaskan dalam Skenario 1-3, tergantung pada jumlah node yang tidak dapat dijangkau.
Node restart selama gangguan jaringan berarti bahwa kegagalan lain (seperti siklus daya, out-of-memory peristiwa, atau masalah lain) terjadi pada node pada saat yang sama dengan pemutusan jaringan. Pod yang berjalan pada node tersebut ketika pemutusan jaringan dimulai tidak secara otomatis dimulai ulang selama pemutusan sambungan jika kubelet juga telah dimulai ulang. Kubelet menanyakan server API Kubernetes selama startup untuk mempelajari pod mana yang harus dijalankan. Jika kubelet tidak dapat mencapai server API karena pemutusan jaringan, kubelet tidak dapat mengambil informasi yang diperlukan untuk memulai pod.
Dalam skenario ini, alat pemecahan masalah lokal seperti `crictl` CLI tidak dapat digunakan untuk memulai pod secara manual sebagai ukuran “break-glass”. Kubernetes biasanya menghapus pod yang gagal dan membuat yang baru daripada memulai ulang pod yang ada (lihat \$110213 [di](https://github.com/containerd/containerd/pull/10213) repo containerd untuk detailnya). GitHub Pod statis adalah satu-satunya objek beban kerja Kubernetes yang dikendalikan oleh kubelet dan dapat di-restart selama skenario ini. Namun, umumnya tidak disarankan untuk menggunakan pod statis untuk penerapan aplikasi. Sebagai gantinya, gunakan beberapa replika di host yang berbeda untuk memastikan ketersediaan aplikasi jika terjadi beberapa kegagalan simultan, seperti kegagalan node ditambah pemutusan jaringan antara node Anda dan bidang kontrol Kubernetes.
# Lalu lintas jaringan aplikasi melalui pemutusan jaringan
Topik pada halaman ini terkait dengan jaringan klaster Kubernetes dan lalu lintas aplikasi selama pemutusan jaringan antara node dan bidang kontrol Kubernetes.
## Cilium
Cilium memiliki beberapa mode untuk IP address management (IPAM), enkapsulasi, load balancing, dan cluster routing. Mode yang divalidasi dalam panduan ini menggunakan Cluster Scope IPAM, overlay VXLAN, load balancing BGP, dan kube-proxy. Cilium juga digunakan tanpa load balancing BGP, menggantinya dengan load balancing MetalLB L2.
Basis pemasangan Cilium terdiri dari operator Cilium dan agen Cilium. [Operator Cilium berjalan sebagai Deployment dan mendaftarkan Cilium Custom Resource Definitions (CRDs), mengelola IPAM, dan menyinkronkan objek cluster dengan server API Kubernetes di antara kemampuan lainnya.](https://docs.cilium.io/en/stable/internals/cilium_operator/) Agen Cilium berjalan pada setiap node sebagai DaemonSet dan mengelola program eBPF untuk mengontrol aturan jaringan untuk beban kerja yang berjalan di cluster.
Umumnya, routing in-cluster yang dikonfigurasi oleh Cilium tetap tersedia dan di tempat selama pemutusan jaringan, yang dapat dikonfirmasi dengan mengamati arus lalu lintas in-cluster dan aturan tabel IP (iptables) untuk jaringan pod.
```
ip route show table all | grep cilium
```
```
10.86.2.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.64/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.128/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.2.192/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16 mtu 1450
10.86.3.0/26 via 10.86.3.16 dev cilium_host proto kernel src 10.86.3.16
10.86.3.16 dev cilium_host proto kernel scope link
...
```
Namun, selama pemutusan jaringan, operator Cilium dan agen Cilium memulai ulang karena penggabungan pemeriksaan kesehatan mereka dengan kesehatan koneksi dengan server API Kubernetes. Diharapkan untuk melihat hal berikut di log operator Cilium dan agen Cilium selama pemutusan jaringan. Selama pemutusan jaringan, Anda dapat menggunakan alat seperti `crictl` CLI untuk mengamati restart komponen ini termasuk lognya.
```
msg="Started gops server" address="127.0.0.1:9890" subsys=gops
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Establishing connection to apiserver" host="https://:443" subsys=k8s-client
msg="Unable to contact k8s api-server" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" ipAddr="https://:443" subsys=k8s-client
msg="Start hook failed" function="client.(*compositeClientset).onStart (agent.infra.k8s-client)" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout"
msg="Start failed" error="Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" duration=1m5.003834026s
msg=Stopping
msg="Stopped gops server" address="127.0.0.1:9890" subsys=gops
msg="failed to start: Get \"https://:443/api/v1/namespaces/kube-system\": dial tcp :443: i/o timeout" subsys=daemon
```
Jika Anda menggunakan kemampuan BGP Control Plane Cilium untuk load balancing aplikasi, sesi BGP untuk pod dan layanan Anda mungkin tidak aktif selama pemutusan jaringan karena fungsi speaker BGP terintegrasi dengan agen Cilium, dan agen Cilium akan terus restart ketika terputus dari bidang kontrol Kubernetes. Untuk informasi lebih lanjut, lihat Panduan Operasi Pesawat Kontrol Cilium BGP di dokumentasi Cilium. Selain itu, jika Anda mengalami kegagalan simultan selama pemutusan jaringan seperti siklus daya atau reboot mesin, rute Cilium tidak akan dipertahankan melalui tindakan ini, meskipun rute dibuat ulang ketika node terhubung kembali ke bidang kontrol Kubernetes dan Cilium dimulai lagi.
## Calico
*Segera hadir*
## MetalB
[MetalLB memiliki dua mode untuk penyeimbangan beban: mode [L2 dan mode](https://metallb.universe.tf/concepts/layer2/) BGP.](https://metallb.universe.tf/concepts/bgp/) Referensikan dokumentasi MetalLB untuk detail tentang cara kerja mode load balancing ini dan keterbatasannya. Validasi untuk panduan ini menggunakan MetalLB dalam mode L2, di mana satu mesin di klaster mengambil kepemilikan Layanan Kubernetes, dan menggunakan ARP IPv4 untuk membuat alamat IP penyeimbang beban dapat dijangkau di jaringan lokal. Saat menjalankan MetalLB ada pengontrol yang bertanggung jawab atas penugasan IP dan speaker yang berjalan pada setiap node yang bertanggung jawab untuk layanan iklan dengan alamat IP yang ditetapkan. Pengontrol MetalLB berjalan sebagai Deployment dan speaker MetalLB berjalan sebagai file. DaemonSet Selama pemutusan jaringan, pengontrol dan speaker MetalLB gagal menonton server API Kubernetes untuk sumber daya klaster tetapi terus berjalan. Yang terpenting, Layanan yang menggunakan MetalLB untuk konektivitas eksternal tetap tersedia dan dapat diakses selama pemutusan jaringan.
## kube-proxy
Dalam kluster EKS, kube-proxy berjalan sebagai a DaemonSet pada setiap node dan bertanggung jawab untuk mengelola aturan jaringan untuk mengaktifkan komunikasi antara layanan dan pod dengan menerjemahkan alamat IP layanan ke alamat IP dari pod yang mendasarinya. Aturan IP tables (iptables) yang dikonfigurasi oleh kube-proxy dipertahankan selama pemutusan jaringan dan routing in-cluster terus berfungsi dan pod kube-proxy terus berjalan.
Anda dapat mengamati aturan kube-proxy dengan perintah iptables berikut. Perintah pertama menunjukkan paket melalui `PREROUTING` rantai diarahkan ke `KUBE-SERVICES` rantai.
```
iptables -t nat -L PREROUTING
```
```
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
KUBE-SERVICES all -- anywhere anywhere /* kubernetes service portals */
```
Memeriksa `KUBE-SERVICES` rantai kita dapat melihat aturan untuk berbagai layanan cluster.
```
Chain KUBE-SERVICES (2 references)
target prot opt source destination
KUBE-SVL-NZTS37XDTDNXGCKJ tcp -- anywhere 172.16.189.136 /* kube-system/hubble-peer:peer-service cluster IP /
KUBE-SVC-2BINP2AXJOTI3HJ5 tcp -- anywhere 172.16.62.72 / default/metallb-webhook-service cluster IP /
KUBE-SVC-LRNEBRA3Z5YGJ4QC tcp -- anywhere 172.16.145.111 / default/redis-leader cluster IP /
KUBE-SVC-I7SKRZYQ7PWYV5X7 tcp -- anywhere 172.16.142.147 / kube-system/eks-extension-metrics-api:metrics-api cluster IP /
KUBE-SVC-JD5MR3NA4I4DYORP tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:metrics cluster IP /
KUBE-SVC-TCOU7JCQXEZGVUNU udp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns cluster IP /
KUBE-SVC-ERIFXISQEP7F7OF4 tcp -- anywhere 172.16.0.10 / kube-system/kube-dns:dns-tcp cluster IP /
KUBE-SVC-ENODL3HWJ5BZY56Q tcp -- anywhere 172.16.7.26 / default/frontend cluster IP /
KUBE-EXT-ENODL3HWJ5BZY56Q tcp -- anywhere / default/frontend loadbalancer IP /
KUBE-SVC-NPX46M4PTMTKRN6Y tcp -- anywhere 172.16.0.1 / default/kubernetes:https cluster IP /
KUBE-SVC-YU5RV2YQWHLZ5XPR tcp -- anywhere 172.16.228.76 / default/redis-follower cluster IP /
KUBE-NODEPORTS all -- anywhere anywhere / kubernetes service nodeports; NOTE: this must be the last rule in this chain */
```
Memeriksa rantai layanan frontend untuk aplikasi, kita dapat melihat alamat IP pod mendukung layanan.
```
iptables -t nat -L KUBE-SVC-ENODL3HWJ5BZY56Q
```
```
Chain KUBE-SVC-ENODL3HWJ5BZY56Q (2 references)
target prot opt source destination
KUBE-SEP-EKXE7ASH7Y74BGBO all -- anywhere anywhere /* default/frontend -> 10.86.2.103:80 / statistic mode random probability 0.33333333349
KUBE-SEP-GCY3OUXWSVMSEAR6 all -- anywhere anywhere / default/frontend -> 10.86.2.179:80 / statistic mode random probability 0.50000000000
KUBE-SEP-6GJJR3EF5AUP2WBU all -- anywhere anywhere / default/frontend -> 10.86.3.47:80 */
```
Pesan log kube-proxy berikut diharapkan selama pemutusan jaringan saat mencoba menonton server API Kubernetes untuk pembaruan ke sumber daya node dan titik akhir.
```
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.Node: failed to list *v1.Node: Get \"https:///api/v1/nodes?fieldSelector=metadata.name%3D&resourceVersion=2241908\": dial tcp :443: i/o timeout" logger="UnhandledError"
"Unhandled Error" err="k8s.io/client-go/informers/factory.go:160: Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get \"https:///apis/discovery.k8s.io/v1/endpointslices?labelSelector=%21service.kubernetes.io%2Fheadless%2C%21service.kubernetes.io%2Fservice-proxy-name&resourceVersion=2242090\": dial tcp :443: i/o timeout" logger="UnhandledError"
```
## CoreDNS
Secara default, pod di kluster EKS menggunakan alamat IP cluster CoreDNS sebagai server nama untuk kueri DNS in-cluster. Di kluster EKS, CoreDNS berjalan sebagai Deployment pada node. Dengan node hybrid, pod dapat terus berkomunikasi dengan CoreDNS selama pemutusan jaringan ketika ada replika CoreDNS yang berjalan secara lokal pada node hybrid. Jika Anda memiliki kluster EKS dengan node di cloud dan node hybrid di lingkungan lokal Anda, disarankan untuk memiliki setidaknya satu replika CoreDNS di setiap lingkungan. CoreDNS terus melayani kueri DNS untuk catatan yang dibuat sebelum pemutusan jaringan dan terus berjalan melalui koneksi ulang jaringan untuk stabilitas statis.
Pesan log CoreDNS berikut diharapkan selama pemutusan jaringan saat mencoba membuat daftar objek dari server API Kubernetes.
```
Failed to watch *v1.Namespace: failed to list *v1.Namespace: Get "https://:443/api/v1/namespaces?resourceVersion=2263964": dial tcp :443: i/o timeout
Failed to watch *v1.Service: failed to list *v1.Service: Get "https://:443/api/v1/services?resourceVersion=2263966": dial tcp :443: i/o timeout
Failed to watch *v1.EndpointSlice: failed to list *v1.EndpointSlice: Get "https://:443/apis/discovery.k8s.io/v1/endpointslices?resourceVersion=2263896": dial tcp : i/o timeout
```
# Kredensi host melalui pemutusan jaringan
EKS Hybrid Nodes terintegrasi dengan aktivasi hybrid AWS Systems Manager (SSM) dan AWS IAM Roles Anywhere untuk kredensyal IAM sementara yang digunakan untuk mengautentikasi node dengan bidang kontrol EKS. Peran SSM dan IAM Anywhere secara otomatis menyegarkan kredensyal sementara yang mereka kelola di host lokal. Disarankan untuk menggunakan penyedia kredensyal tunggal di seluruh node hibrida di cluster Anda—baik aktivasi hibrida SSM atau Peran IAM Di Mana Saja, tetapi tidak keduanya.
## Aktivasi hibrida SSM
Kredensyal sementara yang disediakan oleh SSM berlaku selama satu jam. Anda tidak dapat mengubah durasi validitas kredensyal saat menggunakan SSM sebagai penyedia kredensi Anda. Kredensyal sementara secara otomatis diputar oleh SSM sebelum kedaluwarsa, dan rotasi tidak mempengaruhi status node atau aplikasi Anda. Namun, ketika ada pemutusan jaringan antara agen SSM dan titik akhir Regional SSM, SSM tidak dapat menyegarkan kredensialnya, dan kredensialnya mungkin kedaluwarsa.
SSM menggunakan backoff eksponensial untuk percobaan ulang penyegaran kredenal jika tidak dapat terhubung ke titik akhir Regional SSM. Dalam versi agen SSM `3.3.808.0` dan yang lebih baru (dirilis Agustus 2024), backoff eksponensial dibatasi pada 30 menit. Bergantung pada durasi pemutusan jaringan Anda, SSM mungkin memerlukan waktu hingga 30 menit untuk menyegarkan kredensialnya, dan node hibrida tidak akan terhubung kembali ke bidang kontrol EKS sampai kredensialnya diperbarui. Dalam skenario ini, Anda dapat memulai ulang agen SSM untuk memaksa penyegaran kredenal. Sebagai efek samping dari perilaku penyegaran kredenal SSM saat ini, node mungkin terhubung kembali pada waktu yang berbeda tergantung pada kapan agen SSM pada setiap node berhasil menyegarkan kredensialnya. Karena itu, Anda mungkin melihat pod failover dari node yang belum terhubung kembali ke node yang sudah terhubung kembali.
Dapatkan versi agen SSM. Anda juga dapat memeriksa bagian Fleet Manager di konsol SSM:
```
# AL2023, RHEL
yum info amazon-ssm-agent
# Ubuntu
snap list amazon-ssm-agent
```
Mulai ulang agen SSM:
```
# AL2023, RHEL
systemctl restart amazon-ssm-agent
# Ubuntu
systemctl restart snap.amazon-ssm-agent.amazon-ssm-agent
```
Lihat log agen SSM:
```
tail -f /var/log/amazon/ssm/amazon-ssm-agent.log
```
Pesan log yang diharapkan selama pemutusan jaringan:
```
INFO [CredentialRefresher] Credentials ready
INFO [CredentialRefresher] Next credential rotation will be in 29.995040663666668 minutes
ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed
INFO [CredentialRefresher] Sleeping for 35s before retrying retrieve credentials
ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed
INFO [CredentialRefresher] Sleeping for 56s before retrying retrieve credentials
ERROR [CredentialRefresher] Retrieve credentials produced error: RequestError: send request failed
INFO [CredentialRefresher] Sleeping for 1m24s before retrying retrieve credentials
```
## IAM Roles Anywhere
Kredensyal sementara yang disediakan oleh IAM Roles Anywhere berlaku selama satu jam secara default. Anda dapat mengonfigurasi durasi validitas kredensyal dengan IAM Roles Anywhere melalui [https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/authentication-create-session.html#credentials-object)bidang di profil IAM Roles Anywhere Anda. Durasi validitas kredenal maksimum adalah 12 jam. [https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html](https://docs.aws.amazon.com/managedservices/latest/ctref/management-advanced-identity-and-access-management-iam-update-maxsessionduration.html)Pengaturan pada peran IAM Hybrid Nodes Anda harus lebih besar dari `durationSeconds` pengaturan pada profil IAM Roles Anywhere Anda.
Saat menggunakan IAM Roles Anywhere sebagai penyedia kredensi untuk node hybrid Anda, koneksi ulang ke bidang kontrol EKS setelah pemutusan jaringan biasanya terjadi dalam hitungan detik setelah restorasi jaringan, karena kubelet memanggil `aws_signing_helper credential-process` untuk mendapatkan kredensyal sesuai permintaan. Meskipun tidak terkait langsung dengan node hibrida atau pemutusan jaringan, Anda dapat mengonfigurasi notifikasi dan peringatan untuk kedaluwarsa sertifikat saat menggunakan Peran IAM Di Mana Saja. Untuk informasi selengkapnya, lihat [Menyesuaikan setelan notifikasi di Peran IAM Di Mana Saja](https://docs.aws.amazon.com/rolesanywhere/latest/userguide/customize-notification-settings.html).