Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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 redundan dan tangguh dari lingkungan lokal Anda ke dan dari AWS. Lihat AWS Direct Connect Resiliency Toolkit dan dokumentasi AWS Site-to-Site VPN untuk informasi selengkapnya tentang merancang jaringan hibrida 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 node, zona, dan domain regional. Penggunaan mekanisme ini tergantung pada arsitektur aplikasi, lingkungan, dan persyaratan ketersediaan. Misalnya, aplikasi stateless sering dapat digunakan dengan beberapa replika dan dapat bergerak melintasi host dan kapasitas infrastruktur arbitrer, 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 penerapan dengan node yang berjalan di beberapa pusat data atau lokasi fisik, tetapkan zona untuk setiap node berdasarkan pusat data atau lokasi fisiknya. Saat Anda menjalankan EKS dengan node di cloud, label zona ini secara otomatis diterapkan oleh pengelola pengontrol cloud AWS. Namun, pengelola pengontrol cloud tidak 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 dilewatkan saat Anda menghubungkan node hybrid Anda ke cluster Anda dengan node hybrid CLI (nodeadm). Untuk informasi selengkapnya tentang topology.kubernetes.io/zone label, lihat dokumentasi Kubernetes.
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 keadaan koneksi hybrid dan mendiagnosis masalah. Untuk informasi selengkapnya, lihat Memantau sumber daya AWS Direct Connect dan Meman tau koneksi AWS Site-to-Site VPN.
Disarankan untuk membuat alarm untuk NodeNotReady peristiwa yang dilaporkan oleh node-lifecycle-controller yang berjalan di bidang kontrol EKS, yang menandakan bahwa node hybrid mungkin mengalami pemutusan jaringan. Anda dapat membuat alarm ini dengan mengaktifkan pencatatan bidang kontrol EKS untuk Manajer Pengontrol 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 untuk log dalam CloudWatch dokumentasi.
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, menunjukkan potensi masalah jaringan antara node hybrid 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 yang dikirim dari TGW ke lampiran (node hybrid 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 hybrid) |
|
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 Monitor CloudWatch Jaringan
EKS menawarkan beberapa opsi untuk memantau kesehatan cluster dan aplikasi Anda. Untuk kesehatan cluster, 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 CloudWatch untuk pemantauan cluster, aplikasi, dan infrastruktur. Untuk informasi selengkapnya tentang opsi pengamatan EKS, lihat Mem antau kinerja cluster Anda dan melihat log.
Pemecahan masalah lokal
Untuk mempersiapkan pemutusan jaringan antara node hybrid dan bidang kontrol EKS, Anda dapat mengatur pemantauan sekunder dan pencatatan backend untuk mempertahankan pengamatan aplikasi saat layanan AWS regional tidak dapat dijangkau. Misalnya, Anda dapat mengonfigurasi pengumpul 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 wadah sebagai pengganti kubectl atau API-compatible klien Kubernetes lainnya yang biasanya menanyakan titik akhir server API Kubernetes. Untuk informasi lebih lanjutcrictl, lihat crictl dokumentasi 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 kontainer 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 aliran 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 masuk berperilaku berbeda selama pemutusan jaringan. Misalnya, jika Anda menggunakan kemampuan BGP Control Plane Cilium untuk penyeimbangan beban aplikasi, sesi BGP untuk pod dan layanan Anda mungkin mati selama pemutusan jaringan. Hal ini terjadi karena fungsionalitas 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: #31702
Meninjau 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 CloudWatch untuk metrik dan log, menggunakan Application and Network Load Balancers untuk Region-originated lalu lintas, dan menarik wadah 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 membahayakan stabilitas statis aplikasi Anda.
Menyetel 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. Umumnya, penting untuk mempertimbangkan persyaratan sumber daya aplikasi Anda dan memiliki kapasitas yang cukup untuk satu atau lebih instance aplikasi gagal beralih ke host yang berbeda jika node gagal.
-
Opsi 1 - Gunakan DaemonSets: Opsi ini berlaku untuk aplikasi yang dapat dan harus berjalan pada semua node di cluster. DaemonSets secara otomatis dikonfigurasi untuk mentolerir noda yang tidak dapat dijangkau, yang membuat pod tetap ter DaemonSet ikat ke node mereka melalui pemutusan jaringan.
-
Opsi 2 - Setel
tolerationSecondsuntuk noda yang tidak dapat dijangkau: Anda dapat menyetel jumlah waktu pod Anda tetap terikat ke node selama pemutusan jaringan. Lakukan ini dengan mengonfigurasi pod aplikasi untuk mentolerir noda yang tidak dapat dijangkau denganNoExecuteefek selama durasi yang Anda tentukan (tolerationSecondsdalam spesifikasi aplikasi). Dengan opsi ini, ketika ada pemutusan jaringan, pod aplikasi Anda tetap terikat ke node hingga kedaluwarsatolerationSeconds. Pertimbangkan hal ini dengan cermat, karena peningkatantolerationSecondsuntuk noda yang tidak dapat dijangkauNoExecuteberarti bahwa pod yang berjalan di host yang tidak dapat dijangkau mungkin membutuhkan waktu lebih lama untuk pindah ke host lain yang sehat dan dapat dijangkau. -
Opsi 3: Pengontrol khusus: Anda dapat membuat dan menjalankan pengontrol khusus (atau perangkat lunak lain) yang memantau Kubernetes untuk noda yang tidak dapat dijangkau dengan efeknya.
NoExecuteKetika noda ini terdeteksi, pengontrol khusus dapat memeriksa metrik khusus aplikasi untuk menilai kesehatan aplikasi. Jika aplikasi sehat, pengontrol khusus dapat menghapus noda yang tidak dapat dijangkau, mencegah penggusuran pod dari node selama pemutusan jaringan.
Contoh cara mengonfigurasi Deployment dengan tolerationSeconds tinta 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
