View a markdown version of this page

Siapkan kluster Amazon EKS lokal di AWS Outposts dikonfigurasi dengan penyimpanan instans EC2 untuk pemutusan jaringan - Amazon EKS

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 ConnectedStatus metrik 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,) aws-auth ConfigMap

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:

  1. Buat kunci pribadi dan permintaan penandatanganan sertifikat (CSR):

    openssl req -new -newkey rsa:4096 -nodes \ -keyout admin.key -out admin.csr -subj "/CN=admin"
  2. Buat CertificateSigningRequest sumber daya Kubernetes dan setujui:

    cat admin.csr | base64 | tr -d '\n' > admin.csr.b64
    apiVersion: certificates.k8s.io/v1 kind: CertificateSigningRequest metadata: name: admin-csr spec: request: <base64-encoded-csr> signerName: kubernetes.io/kube-apiserver-client usages: - client auth
    kubectl apply -f admin-csr.yaml kubectl certificate approve admin-csr
  3. Ambil sertifikat yang ditandatangani:

    kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
  4. Buat a ClusterRoleBinding untuk memberikan akses admin:

    kubectl create clusterrolebinding admin --clusterrole=cluster-admin \ --user=admin --group=system:masters
  5. Buat kubeconfig yang 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 berjalankubectl.

  • Worker node (kubelet) mengirimkan detak jantung node dan menarik spesifikasi.

  • kube-proxypada setiap node, yang mengatur IP Layanan cluster.

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 kubeconfig untuk menunjuk langsung ke alamat IP pribadi ENI lintas akun. Temukan ENI dengan mencari antarmuka jaringan dengan deskripsi Amazon EKS cluster-name di akun Anda AWS . Setiap alamat IP ENI stabil untuk masa pakai cluster dalam operasi normal.

  • 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/hosts dengan alamat IP ENI. Tidak diperlukan konfigurasi tambahan.

  • Node pekerja (AMI khusus): Tambahkan nama host titik akhir cluster dan alamat IP ENI ke /etc/hosts dalam bootstrap khusus Anda. Jika tidak, kubelet dan tidak kube-proxy dapat 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 region-code.compute.internal pencarian dari konfigurasi DNS pod, mencegah kueri diteruskan ke resolver DNS VPC yang tidak dapat dijangkau saat terputus.

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, Grafana, atau solusi pihak ketiga lainnya untuk mengikis titik akhir metrik server Kubernetes API.

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.

  1. Terapkan aturan firewall pada perangkat jaringan yang menghubungkan Outpost Anda ke AWS Wilayah. Ini memutus tautan layanan dari Outpost.

  2. 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.