Bantu tingkatkan halaman ini
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Untuk berkontribusi pada panduan pengguna ini, pilih Edit halaman ini pada GitHub tautan yang terletak di panel kanan setiap halaman.
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Siapkan kluster Amazon EKS lokal di AWS Outposts dikonfigurasi dengan penyimpanan instans EC2 untuk pemutusan jaringan
Jika tautan layanan AWS Outposts yang menghubungkan jaringan lokal Anda ke AWS Cloud kehilangan konektivitas, Anda dapat terus menggunakan kluster Amazon EKS lokal Anda di Outpost. Topik ini mencakup cara mempersiapkan klaster lokal Anda untuk pemutusan jaringan dan pertimbangan terkait.
-
Cluster lokal memungkinkan stabilitas dan operasi lanjutan selama pemutusan jaringan sementara yang tidak direncanakan. AWS Outposts tetap merupakan penawaran yang terhubung penuh yang bertindak sebagai perpanjangan AWS Cloud di pusat data Anda. Jika jaringan terputus antara Outpost Anda dan AWS Cloud, kami sarankan untuk mencoba memulihkan koneksi Anda. Untuk petunjuk, lihat daftar periksa pemecahan masalah jaringan rak AWS Outposts di Panduan Pengguna Outposts. AWS
-
Outposts memancarkan
ConnectedStatusmetrik yang dapat Anda gunakan untuk memantau status konektivitas Outpost Anda. Untuk informasi selengkapnya, lihat Metrik Outposts di Panduan Pengguna Outposts AWS .
Otentikasi selama pemutusan jaringan
Cluster lokal mendukung beberapa mekanisme otentikasi. Ketersediaannya selama pemutusan jaringan bervariasi:
| Mekanisme autentikasi | Tersedia selama pemutusan? |
|---|---|
|
AWS IAM (entri akses,) |
Tidak. IAM membutuhkan konektivitas ke AWS Wilayah. |
|
OIDC (penyedia yang disediakan pelanggan) |
Tergantung pada lokasi penyedia. Jika penyedia OIDC dapat dijangkau dari jaringan lokal Outpost, otentikasi terus berfungsi. |
|
sertifikat klien x.509 |
Ya. Sertifikat divalidasi secara lokal oleh server API Kubernetes. |
|
IRSA (Peran IAM untuk Akun Layanan) |
Tidak. LihatIRSA dan Pod Identity saat terputus. |
|
Identitas Pod EKS |
Tidak. LihatIRSA dan Pod Identity saat terputus. |
sertifikat klien x.509
Untuk mempertahankan kubectl akses selama pemutusan jaringan, buat sertifikat x.509 klien sebelum pemutusan terjadi.
Untuk membuat sertifikat admin:
-
Buat kunci pribadi dan permintaan penandatanganan sertifikat (CSR):
openssl req -new -newkey rsa:4096 -nodes \ -keyout admin.key -out admin.csr -subj "/CN=admin" -
Buat
CertificateSigningRequestsumber daya Kubernetes dan setujui:cat admin.csr | base64 | tr -d '\n' > admin.csr.b64apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: request: <base64-encoded-csr> signerName: kubernetes.io/kube-apiserver-client usages: - client authkubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr -
Ambil sertifikat yang ditandatangani:
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt -
Buat a
ClusterRoleBindinguntuk memberikan akses admin:kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters -
Buat
kubeconfigyang menggunakan sertifikat:kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \ --certificate-authority=ca.crt --server $APISERVER_ENDPOINT --embed-certs kubectl config --kubeconfig admin.kubeconfig set-credentials admin \ --client-certificate=admin.crt --client-key=admin.key --embed-certs kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \ --cluster my-cluster --user admin kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
Resolusi DNS titik akhir cluster selama pemutusan
Endpoint server API Kubernetes untuk cluster lokal di-host di Amazon Route 53 dan diselesaikan ke alamat IP pribadi dari antarmuka jaringan elastis lintas akun (ENI) yang dibuat Amazon EKS di subnet Anda. ENI ini memiliki alamat IP pribadi statis yang tidak berubah selama operasi cluster normal.
Selama pemutusan jaringan, Outpost tidak dapat mencapai Route 53, sehingga nama host titik akhir cluster tidak dapat diselesaikan kecuali Anda telah menyiapkan jalur resolusi lokal. Tiga kategori klien perlu mencapai server API:
-
Administrator cluster berjalan
kubectl. -
Worker node (
kubelet) mengirimkan detak jantung node dan menarik spesifikasi. -
kube-proxypada setiap node, yang mengatur IP Layanan cluster.
Opsi 1: solusi DNS lokal (disarankan)
AWS merekomendasikan penerapan solusi DNS lokal yang menyimpan catatan titik akhir cluster dan menyajikannya saat Outpost terputus. Anda dapat menjalankan server DNS Anda sendiri di lingkungan lokal yang menyimpan catatan titik akhir klaster dalam cache.
Jika Anda menggunakan solusi DNS lokal, sebaiknya arahkan AMI Anda kubeconfig dan worker-node Anda ke nama host titik akhir cluster (bukan pada alamat IP ENI) sehingga resolusi konsisten dengan solusi DNS lokal.
Opsi 2: IP-based akses statis
Jika Anda tidak ingin menjalankan solusi DNS lokal, Anda dapat menggunakan IP-based akses statis.
-
Administrator: Konfigurasikan
kubeconfiguntuk menunjuk langsung ke alamat IP pribadi ENI lintas akun. Temukan ENI dengan mencari antarmuka jaringan dengan deskripsiAmazon EKSdi akun Anda AWS . Setiap alamat IP ENI stabil untuk masa pakai cluster dalam operasi normal.cluster-name -
Node pekerja (AMI yang dioptimalkan Amazon EKS): Saat Anda meluncurkan node pekerja dari AMI yang dioptimalkan Amazon EKS, skrip bootstrap menambahkan titik akhir cluster
/etc/hostsdengan alamat IP ENI. Tidak diperlukan konfigurasi tambahan. -
Node pekerja (AMI khusus): Tambahkan nama host titik akhir cluster dan alamat IP ENI ke
/etc/hostsdalam bootstrap khusus Anda. Jika tidak,kubeletdan tidakkube-proxydapat mencapai server API selama pemutusan sambungan.
penting
Jika ENI lintas akun dihapus atau alamat IP-nya berubah — misalnya, jika Anda menghapusnya atau memodifikasinya dengan cara yang mencegah Amazon EKS melampirkannya kembali — setiap node dan setiap administrator yang menggunakan IP-based akses statis harus diperbarui secara manual. Dengan solusi DNS lokal, tidak diperlukan intervensi manual.
Resolusi Pod DNS selama pemutusan
Untuk mencegah kegagalan DNS selama operasi terputus, konfigurasikan template peluncuran node pekerja Anda untuk mengganti kubelet’s `resolvConf pengaturan. Di data pengguna Anda, buat resolv.conf file kustom (misalnya,/etc/kubernetes/resolv.conf) yang hanya berisi nameserver 10.0.0.2 (tanpa domain pencarian VPC), lalu spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf atur di file Anda. NodeConfig Ini menghapus domain
pencarian dari konfigurasi DNS pod, mencegah kueri diteruskan ke resolver DNS VPC yang tidak dapat dijangkau saat terputus.region-code.compute.internal
Contoh berikut menunjukkan pekerja node userdata:
MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="BOUNDARY" --BOUNDARY Content-Type: text/x-shellscript; charset="us-ascii" #!/bin/bash mkdir -p /etc/kubernetes echo "nameserver [.replaceable]``10.0.0.2``" > /etc/kubernetes/resolv.conf --BOUNDARY Content-Type: application/node.eks.aws --- apiVersion: node.eks.aws/v1alpha1 kind: NodeConfig spec: cluster: name: my-cluster ... kubelet: config: resolvConf: /etc/kubernetes/resolv.conf --BOUNDARY--
IRSA dan Pod Identity saat terputus
penting
IRSA dan EKS Pod Identity bergantung pada AWS STS, yang berjalan di AWS Region. Selama pemutusan jaringan, beban kerja yang menggunakan IRSA atau Pod Identity tidak dapat memperoleh kredensi baru. Kredensi yang ada kedaluwarsa setelah jangka waktu tertentu.
Kami tidak menyarankan untuk mengambil dependensi fungsional atau operasional pada Region-based AWS layanan untuk beban kerja yang harus tetap tersedia selama pemutusan jaringan.
perilaku etcd selama pemutusan
Selama pemutusan jaringan, etcd snapshot tidak dapat dicadangkan. Jika lebih dari satu etcd instance menjadi tidak tersedia selama pemutusan sambungan, kuorum akan etcd hilang dan operasi API Kubernetes tidak tersedia sampai Outpost Anda tersambung kembali dan kuorum telah dipulihkan. etcd Beban kerja yang sudah berjalan terus beroperasi.
Kontrol logging pesawat selama pemutusan
Selama pemutusan jaringan, log bidang kontrol di-cache secara lokal pada instance bidang kontrol. Saat konektivitas dipulihkan, log dikirim ke Amazon CloudWatch Logs di AWS Wilayah induk. Anda tidak perlu menginstal atau memelihara agen penebangan apa pun di bidang kontrol.
Observabilitas lokal
Anda dapat memantau klaster Anda secara lokal selama pemutusan koneksi dengan menggunakan Prometheus
Repositori gambar lokal
Untuk menskalakan penerapan dengan replika tambahan atau untuk memulihkan dari kegagalan pod selama pemutusan sambungan, Anda harus memiliki repositori gambar kontainer lokal (seperti registri Docker), atau gambar harus di-cache pada node sebelum pemutusan sambungan. Amazon ECR tidak tersedia selama pemutusan jaringan.
Tune perilaku failover pod Kubernetes
Selama pemutusan jaringan, pesawat kontrol Kubernetes tidak dapat berkomunikasi dengan Region. AWS Jika sebuah node menjadi tidak dapat dijangkau, perilaku default Kubernetes adalah mengusir pod setelah periode timeout. Anda dapat menyetel perilaku ini menggunakan toleransi dan tolerationSeconds spesifikasi pod Anda untuk mengontrol seberapa cepat pod dijadwalkan ulang selama partisi. Untuk panduan dan contoh terperinci, lihat https://docs.aws.amazon.com/eks/latest/best-practices/hybrid-nodes-network-disconnection-best-practices.html # tune_kubernetes_pod_failover_behavior [Tune Kubernetes pod failover behavior] di Panduan Praktik Terbaik _Amazon EKS.
Simulasikan pemutusan jaringan
Sebelum Anda masuk ke produksi dengan cluster lokal Anda, simulasikan pemutusan untuk memverifikasi bahwa Anda dapat mengakses klaster Anda saat berada dalam keadaan terputus.
-
Terapkan aturan firewall pada perangkat jaringan yang menghubungkan Outpost Anda ke AWS Wilayah. Ini memutus tautan layanan dari Outpost.
-
Uji koneksi ke cluster lokal Anda menggunakan sertifikat x.509 yang Anda buat:
kubectl --kubeconfig admin.kubeconfig get nodes
catatan
Jika Anda memiliki layanan yang sudah diproduksi di Outpost Anda, jangan mensimulasikan pemutusan sambungan. Memutuskan sambungan tautan layanan memengaruhi semua layanan yang berjalan di Outpost.