Siapkan cluster Amazon EKS lokal di AWS Pos terdepan dikonfigurasi dengan penyimpanan instans EC2 untuk pemutusan jaringan - Amazon EKS

View a markdown version of this page

Siapkan cluster Amazon EKS lokal di AWS Pos terdepan dikonfigurasi dengan penyimpanan instans EC2 untuk pemutusan jaringan - Amazon EKS
Otentikasi selama jaringan terputusperilaku etcd selama pemutusanKontrol pencatatan pesawat selama pemutusanPengamatan lokalRepositori gambar lokalMenyetel perilaku failover pod KubernetesSimulasikan pemutusan jaringan

Bantu meningkatkan 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 GitHub tautan Edit halaman ini di 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 cluster Amazon EKS lokal di AWS Pos terdepan 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 cluster Amazon EKS lokal Anda di Outpost. Topik ini mencakup cara mempersiapkan cluster lokal Anda untuk pemutusan jaringan dan pertimbangan terkait.

  • Cluster lokal memungkinkan stabilitas dan operasi lanjutan selama pemutusan jaringan sementara dan tidak direncanakan. AWS Outposts tetap merupakan penawaran yang terhubung sepenuhnya yang bertindak sebagai perpanjangan AWS Cloud di pusat data Anda. Jika jaringan terputus antara Outpost Anda dan AWS Cloud, kami sarankan mencoba memulihkan koneksi Anda. Untuk petunjuk, lihat daftar periksa AWS pemecahan masalah jaringan rak Outposts di Panduan AWS Pengguna Outposts.

  • Pos terdepan memancarkan ConnectedStatus metrik yang dapat Anda gunakan untuk memantau status konektivitas Pos Terdepan Anda. Untuk informasi selengkapnya, lihat Metrik Pos Terdepan di Panduan Pengguna AWS Pos Terdepan.

Otentikasi selama jaringan terputus

Cluster lokal mendukung beberapa mekanisme otentikasi. Ketersediaannya selama pemutusan jaringan bervariasi:

Mekanisme autentikasi Tersedia selama pemutusan hubungan?

AWS IAM (entri akses, aws-auth ConfigMap)

Tidak. IAM membutuhkan konektivitas ke Wil AWS ayah.

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. LihatIdentitas IRSA dan Pod selama pemutusan.

Identitas Pod EKS

Tidak. LihatIdentitas IRSA dan Pod selama pemutusan.

sertifikat klien x.509

Untuk mempertahankan kubectl akses selama pemutusan jaringan, buat sertifikat x.509 klien sebelum pemutusan terjadi.

Untuk membuat sertifikat admin:

  1. Hasilkan 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 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

Titik akhir server API Kubernetes untuk cluster lokal dihosting di Amazon Route 53 dan diselesaikan ke alamat IP pribadi 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 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.

Opsi 1: solusi DNS lokal (disarankan)

AWS merekomendasikan penerapan solusi DNS lokal yang menyimpan catatan titik akhir cluster dan melayaninya saat Outpost terputus. Anda dapat menjalankan server DNS Anda sendiri di lingkungan lokal yang menyimpan catatan titik akhir cluster dalam cache.

Jika Anda menggunakan solusi DNS lokal, sebaiknya arahkan AMI Anda kubeconfig dan node pekerja 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: Konfigur kubeconfig asikan agar mengarah langsung ke alamat IP pribadi ENI lintas akun. Temukan ENI dengan mencari antarmuka jaringan dengan deskripsi Amazon EKS cluster-name di AWS akun Anda. Setiap alamat IP ENI stabil selama 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 ke /etc/hosts 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 kustom Anda. Jika tidak, kubelet dan tidak kube-proxy dapat menjangkau server API selama pemutusan hubungan.

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 setelan. Di data pengguna Anda, buat resolv.conf file khusus (misalnya,/etc/kubernetes/resolv.conf) yang hanya berisi nameserver 10.0.0.2 (tanpa domain pencarian VPC), lalu atur spec.kubelet.config.resolvConf: /etc/kubernetes/resolv.conf 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 data pengguna node pekerja:

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

Identitas IRSA dan Pod selama pemutusan

penting

IRSA dan EKS Pod Identity bergantung pada AWS STS, yang berjalan di Wil AWS ayah. Selama pemutusan jaringan, beban kerja yang menggunakan IRSA atau Pod Identity tidak dapat memperoleh kredenSIAL baru. KredenSIAL yang ada kedaluwarsa setelah jangka waktu tertentu.

Kami tidak merekomendasikan 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 jaringan terputus, etcd snapshot tidak dapat dicadangkan. Jika lebih dari satu etcd instans menjadi tidak tersedia selama pemutusan hubungan, kuor etcd um hilang dan operasi API Kubernetes tidak tersedia sampai Outpost Anda terhubung kembali dan kuorum telah dipulihkan. etcd Beban kerja yang sudah berjalan terus beroperasi.

Kontrol pencatatan 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 Wil AWS ayah induk. Anda tidak perlu menginstal atau memelihara agen logging apa pun di bidang kontrol.

Pengamatan lokal

Anda dapat memantau cluster secara lokal selama pemutusan koneksi dengan menggunakan Prometheus, Grafana, atau solusi pihak ketiga lainnya untuk mengikis titik akhir metrik server API Kubernetes.

Repositori gambar lokal

Untuk menskalakan penerapan dengan replika tambahan atau memulihkan dari kegagalan pod selama pemutusan, Anda harus memiliki repositori image kontainer lokal (seperti registri Docker), atau gambar harus di-cache pada node sebelum pemutusan. Amazon ECR tidak tersedia selama pemutusan jaringan.

Menyetel perilaku failover pod Kubernetes

Selama pemutusan jaringan, bidang kontrol Kubernetes tidak dapat berkomunikasi dengan Wilayah. AWS Jika node menjadi tidak dapat dijangkau, perilaku Kubernetes default adalah mengusir pod setelah periode batas waktu. Anda dapat menyetel perilaku ini menggunakan toleransi dan tolerationSeconds spesifikasi pod untuk mengontrol seberapa cepat pod dijadwal 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 [Menyetel perilaku failover pod Kubernetes] 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 cluster saat berada dalam keadaan terputus.

  1. Terapkan aturan firewall pada perangkat jaringan yang menghubungkan Pos Terdepan Anda ke Wil AWS ayah. Ini memutuskan tautan layanan Pos Terdepan.

  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. Memutuskan sambungan layanan akan mempengaruhi semua layanan yang berjalan di Outpost.