Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pesawat Kontrol EKS

Amazon Elastic Kubernetes Service (EKS) adalah layanan Kubernetes terkelola yang memudahkan Anda menjalankan Kubernetes di AWS tanpa perlu menginstal, mengoperasikan, dan memelihara bidang kontrol Kubernetes atau node pekerja Anda sendiri. Ini berjalan di hulu Kubernetes dan bersertifikat sesuai Kubernetes. Kesesuaian ini memastikan bahwa EKS mendukung API Kubernetes, sama seperti versi komunitas sumber terbuka yang dapat Anda instal di EC2 atau lokal. Aplikasi yang ada yang berjalan di hulu Kubernetes kompatibel dengan Amazon EKS.

EKS secara otomatis mengelola ketersediaan dan skalabilitas node bidang kontrol Kubernetes, dan secara otomatis menggantikan node bidang kontrol yang tidak sehat.

Arsitektur EKS

Arsitektur EKS dirancang untuk menghilangkan titik kegagalan tunggal yang dapat membahayakan ketersediaan dan daya tahan bidang kontrol Kubernetes.

Pesawat kontrol Kubernetes yang dikelola oleh EKS berjalan di dalam VPC yang dikelola EKS. Bidang kontrol EKS terdiri dari node server API Kubernetes, cluster etcd. Node server API Kubernetes yang menjalankan komponen seperti server API, penjadwal, dan kube-controller-manager berjalan dalam grup penskalaan otomatis. EKS menjalankan minimal dua node server API di Availability Zone (AZ) yang berbeda dalam wilayah AWS. Demikian juga, untuk daya tahan, node server etcd juga berjalan dalam grup penskalaan otomatis yang mencakup tiga AZ. EKS menjalankan NAT Gateway di setiap AZ, dan server API dan server etcd berjalan di subnet pribadi. Arsitektur ini memastikan bahwa peristiwa dalam satu AZ tidak mempengaruhi ketersediaan cluster EKS.

Saat Anda membuat cluster baru, Amazon EKS membuat titik akhir yang sangat tersedia untuk server API Kubernetes terkelola yang Anda gunakan untuk berkomunikasi dengan cluster Anda (menggunakan alat seperti). kubectl Titik akhir yang dikelola menggunakan NLB untuk menyeimbangkan beban server API Kubernetes. EKS juga menyediakan dua ENI di AZ yang berbeda untuk memfasilitasi komunikasi ke node pekerja Anda.

Konektivitas jaringan pesawat data EKS

Anda dapat mengonfigurasi apakah server API cluster Kubernetes Anda dapat dijangkau dari internet publik (menggunakan titik akhir publik) atau melalui VPC Anda (menggunakan ENI) atau keduanya. EKS-managed

Apakah pengguna dan node pekerja terhubung ke server API menggunakan titik akhir publik atau EKS-managed ENI, ada jalur redundan untuk koneksi.

Rekomendasi

Tinjau rekomendasi berikut.

Monitor Metrik Pesawat Kontrol

Memantau metrik API Kubernetes dapat memberi Anda wawasan tentang kinerja bidang kontrol dan mengidentifikasi masalah. Bidang kontrol yang tidak sehat dapat membahayakan ketersediaan beban kerja yang berjalan di dalam cluster. Misalnya, pengontrol yang ditulis dengan buruk dapat membebani server API, memengaruhi ketersediaan aplikasi Anda.

Kubernetes mengekspos metrik bidang kontrol di titik akhir. /metrics

Anda dapat melihat metrik yang diekspos menggunakankubectl:

kubectl get --raw /metrics

Metrik ini direpresentasikan dalam format teks Prometheus.

Anda dapat menggunakan Prometheus untuk mengumpulkan dan menyimpan metrik ini. Pada Mei 2020, CloudWatch menambahkan dukungan untuk memantau metrik Prometheus di CloudWatch Container Insights. Jadi Anda juga dapat menggunakan Amazon CloudWatch untuk memantau pesawat kontrol EKS. Anda dapat menggunakan Tutorial untuk Menambahkan Target Scrape Prometheus Baru: Metrik Server KPI Prometheus untuk mengumpulkan metrik dan membuat CloudWatch dasbor untuk memantau bidang kontrol cluster Anda.

Anda dapat menemukan metrik server API Kubernetes di sini. https://github.com/kubernetes/apiserver/blob/master/pkg/endpoints/metrics/metrics.go Misalnya, apiserver_request_duration_seconds dapat menunjukkan berapa lama permintaan API yang dibutuhkan untuk dijalankan.

Pertimbangkan untuk memantau metrik bidang kontrol ini:

Server API

etcd

Pertimbangkan untuk menggunakan Dasbor Ikhtisar Pemantauan Kubernetes untuk memvisualisasikan dan memantau permintaan server Kubernetes API dan metrik latensi dan latensi etcd.

Otentikasi Cluster

EKS saat ini mendukung dua jenis otentikasi: token bearer/service akun dan otentikasi IAM yang menggunakan otentikasi token webhook. Ketika pengguna memanggil API Kubernetes, webhook meneruskan token otentikasi yang disertakan dalam permintaan ke IAM. Token, URL bertanda dasar 64, dihasilkan oleh AWS Command Line Interface (AWS CLI).

Pengguna atau peran IAM yang membuat Cluster EKS secara otomatis mendapatkan akses penuh ke cluster. Anda dapat mengelola akses ke cluster EKS dengan mengedit configmap aws-auth.

Jika Anda salah mengkonfigurasi aws-auth configmap dan kehilangan akses ke cluster, Anda masih dapat menggunakan pengguna atau peran pembuat cluster untuk mengakses cluster EKS Anda.

Jika tidak mungkin Anda tidak dapat menggunakan layanan IAM di wilayah AWS, Anda juga dapat menggunakan token pembawa akun layanan Kubernetes untuk mengelola cluster.

Buat super-admin akun yang diizinkan untuk melakukan semua tindakan di cluster:

kubectl -n kube-system create serviceaccount super-admin

Buat pengikatan peran yang memberikan peran cluster-admin super-admin:

kubectl create clusterrolebinding super-admin-rb --clusterrole=cluster-admin --serviceaccount=kube-system:super-admin

Dapatkan rahasia akun layanan:

SECRET_NAME=`kubectl -n kube-system get serviceaccount/super-admin -o jsonpath='{.secrets[0].name}'`

Dapatkan token yang terkait dengan rahasia:

TOKEN=`kubectl -n kube-system get secret $SECRET_NAME -o jsonpath='{.data.token}'| base64 --decode`

Tambahkan akun layanan dan token kekubeconfig:

kubectl config set-credentials super-admin --token=$TOKEN

Atur konteks saat ini kubeconfig untuk menggunakan akun super-admin:

kubectl config set-context --current --user=super-admin

Final kubeconfig akan terlihat seperti ini:

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data:<REDACTED>
    server: https://<CLUSTER>.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
contexts:
- context:
    cluster: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
    user: super-admin
  name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
current-context: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
kind: Config
preferences: {}
users:
#- name: arn:aws:eks:us-west-2:<account number>:cluster/<cluster name>
#  user:
#    exec:
#      apiVersion: client.authentication.k8s.io/v1beta1
#      args:
#      - --region
#      - us-west-2
#      - eks
#      - get-token
#      - --cluster-name
#      - <<cluster name>>
#      command: aws
#      env: null
- name: super-admin
  user:
    token: <<super-admin sa's secret>>

Webhooks Pendaftaran

Kubernetes memiliki dua jenis webhook penerimaan: memvalidasi webhook penerimaan dan memutasi webhook penerimaan. Ini memungkinkan pengguna untuk memperluas API kubernetes dan memvalidasi atau mengubah objek sebelum diterima oleh API. Konfigurasi yang buruk dari webhook ini dapat mengacaukan bidang kontrol EKS dengan memblokir operasi kritis cluster.

Untuk menghindari dampak operasi kritis cluster, hindari pengaturan webhook “catch-all” seperti berikut:

- name: "pod-policy.example.com"
  rules:
  - apiGroups:   ["*"]
    apiVersions: ["*"]
    operations:  ["*"]
    resources:   ["*"]
    scope: "*"

Atau pastikan webhook memiliki kebijakan pembukaan gagal dengan batas waktu lebih pendek dari 30 detik untuk memastikan bahwa jika webhook Anda tidak tersedia, itu tidak akan mengganggu beban kerja kritis cluster.

Blokir Pod dengan sysctls yang tidak aman

Sysctladalah utilitas Linux yang memungkinkan pengguna untuk memodifikasi parameter kernel selama runtime. Parameter kernel ini mengontrol berbagai aspek perilaku sistem operasi, seperti jaringan, sistem file, memori virtual, dan manajemen proses.

Kubernetes memungkinkan penetapan profil untuk Pod. sysctl Kubernetes mengkategorikan systcls sebagai aman dan tidak aman. Safe sysctls memiliki ruang nama dalam wadah atau Pod, dan mengaturnya tidak berdampak pada Pod lain pada node atau node itu sendiri. Sebaliknya, sysctl yang tidak aman dinonaktifkan secara default karena berpotensi mengganggu Pod lain atau membuat node tidak stabil.

Karena tidak aman dinonaktifkan sysctls secara default, kubelet tidak akan membuat Pod dengan profil tidak amansysctl. Jika Anda membuat Pod seperti itu, penjadwal akan berulang kali menetapkan Pod tersebut ke node, sementara node gagal meluncurkannya. Loop tak terbatas ini akhirnya meregangkan bidang kontrol cluster, membuat cluster tidak stabil.

Pertimbangkan untuk menggunakan OPA Gatekeeper atau Kyverno untuk menolak Pod yang tidak aman. sysctls

Menangani Upgrade Cluster

Sejak April 2021, siklus rilis Kubernetes telah diubah dari empat rilis setahun (seperempat sekali) menjadi tiga rilis setahun. Versi minor baru (seperti 1. 21 atau 1. 22) dirilis kira-kira setiap lima belas minggu. Dimulai dengan Kubernetes 1.19, setiap versi minor didukung selama sekitar dua belas bulan setelah pertama kali dirilis. Dengan munculnya Kubernetes v1.28, kemiringan kompatibilitas antara bidang kontrol dan node pekerja telah berkembang dari n-2 ke n-3 versi minor. Untuk mempelajari selengkapnya, lihat Praktik Terbaik untuk Upgrade Cluster.

Konektivitas Titik Akhir Cluster

Saat bekerja dengan Amazon EKS (Layanan Kubernetes Elastic), Anda mungkin mengalami batas waktu koneksi atau kesalahan selama peristiwa seperti penskalaan atau tambalan bidang kontrol Kubernetes. Peristiwa ini dapat menyebabkan instance kube-apiserver diganti, berpotensi mengakibatkan alamat IP yang berbeda dikembalikan saat menyelesaikan FQDN. Dokumen ini menguraikan praktik terbaik bagi konsumen API Kubernetes untuk mempertahankan konektivitas yang andal.

Masalah utama berasal dari caching sisi klien DNS dan potensi alamat IP basi titik akhir EKS - NLB publik untuk titik akhir publik atau untuk titik akhir pribadi. X-ENI Ketika instance kube-apiserver diganti, Nama Domain yang Kualifikasi Penuh (FQDN) dapat diselesaikan ke alamat IP baru. Namun, karena pengaturan DNS Time to Live (TTL), yang diatur ke 60 detik di zona Route 53 yang dikelola AWS, klien dapat terus menggunakan alamat IP usang untuk waktu yang singkat.

Untuk mengurangi masalah ini, konsumen API Kubernetes (seperti kubectl, CI/CD pipeline, dan aplikasi khusus) harus menerapkan praktik terbaik berikut:

Dengan menerapkan praktik terbaik ini, Anda dapat secara signifikan meningkatkan keandalan dan ketahanan aplikasi Anda saat berinteraksi dengan Kubernetes API. Ingatlah untuk menguji implementasi ini secara menyeluruh, terutama di bawah kondisi kegagalan yang disimulasikan, untuk memastikan mereka berperilaku seperti yang diharapkan selama peristiwa penskalaan atau tambalan aktual.

Menjalankan cluster besar

EKS secara aktif memantau beban pada instans bidang kontrol dan secara otomatis menskalakannya untuk memastikan kinerja tinggi. Namun, Anda harus memperhitungkan potensi masalah kinerja dan batasan dalam Kubernetes dan kuota di layanan AWS saat menjalankan cluster besar.

Sumber Daya Tambahan: