Gambaran umum Parameter bidang kontrol Kubernetes didukung Pertimbangan-pertimbangan Langkah selanjutnya

Konfigurasi bidang kontrol Kubernetes lanjutan

Gambaran umum

Amazon EKS mengelola bidang kontrol Kubernetes untuk cluster Anda, termasuk server API, penjadwal, dan pengelola pengontrol. EKS menjalankan komponen ini dengan pengaturan Kubernetes hulu default yang berfungsi dengan baik untuk sebagian besar beban kerja, dan Anda tidak perlu mengubahnya untuk sebagian besar cluster. Tetapi beberapa beban kerja mendapat manfaat dari pengaturan bidang kontrol yang berbeda. Anda mungkin ingin penjadwal mengemas pod ke node yang lebih sedikit untuk mengurangi biaya komputasi, mempertahankan peristiwa Kubernetes untuk periode yang lebih singkat untuk membatasi pertumbuhan database cluster (etcd), atau mengevaluasi keputusan penskalaan otomatis lebih sering.

Dengan konfigurasi bidang kontrol Kubernetes lanjutan, Anda mengatur parameter ini langsung pada cluster Anda. EKS menerapkannya ke bidang kontrol, dan cluster Anda terus beroperasi dengan ketersediaan dan karakteristik kinerja yang sama.

Ini adalah konfigurasi lanjutan. Setiap parameter konfigurasi mengubah cara komponen bidang kontrol Kubernetes inti berperilaku untuk beban kerja yang berjalan di cluster, dan nilai yang tepat tergantung pada beban kerja Anda. Sebelum Anda mengubah parameter, baca pertimbangannya di bagian berikut dan uji perubahan dalam cluster non-produksi.

Anda dapat mengatur parameter konfigurasi bidang kontrol lanjutan saat membuat cluster, atau memperbaruinya pada cluster yang ada kapan saja. Kemampuan ini menggunakan yang ada CreateCluster dan UpdateClusterConfig operasi dengan parameter baru, sehingga Anda dapat mengaturnya melalui Konsol Manajemen AWS, AWS CLI, AWS SDK, atau. AWS CloudFormation EKS memvalidasi setiap konfigurasi sebelum menerapkannya, dan mencatat perubahan di AWS CloudTrail.

Parameter bidang kontrol lanjutan berlaku untuk seluruh cluster dan semua beban kerja yang berjalan di atasnya. Anda tidak dapat mencakupnya ke ruang nama individu atau beban kerja. EKS membatasi setiap parameter ke rentang yang divalidasi. Nilai yang didukung untuk setiap parameter terdaftar dengan parameter itu di bagian berikut.

Parameter bidang kontrol Kubernetes didukung

Amazon EKS mendukung parameter berikut. Setiap parameter milik komponen bidang kontrol dan diatur melalui bidang konfigurasi untuk komponen itu:kubeSchedulerConfig,kubeControllerManagerConfig, ataukubeApiServerConfig.

Komponen	Parameter	Nilai yang didukung	Default	Membutuhkan Pesawat Kontrol yang Disediakan
penjadwal kubus	`nodeResourcesFit.scoringStrategy`	`LeastAllocated`, `MostAllocated`	`LeastAllocated`, dengan `cpu: 1` dan `memory: 1`	Tidak
manajer pengontrol kubus	`horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod`	`10s` untuk `15s`	`15s`(detik)	Ya
manajer pengontrol kubus	`podGcControllerConfig.terminatedPodGcThreshold`	`10000` untuk `12500`	`12500`	Ya
kubus apiserver	`eventTtl`	`10m` untuk `60m`	`60m`(menit)	Tidak
kubus apiserver	`serviceNodePortRange`	`minPort`dan `maxPort` antara `10260` dan `32767`	`minPort: 30000`, `maxPort: 32767`	Tidak

Nilai default dan didukung dalam topik ini berlaku untuk versi Kubernetes (EKS v1.31 ke atas) yang tersedia saat publikasi, dan mungkin berubah di versi yang lebih baru. DescribeClusterVersionsOperasi melaporkan nilai default dan didukung saat ini untuk setiap parameter dan versi Kubernetes, jadi gunakan itu sebagai sumber kebenaran jika Anda mengelola cluster di beberapa versi atau mengotomatiskan konfigurasi cluster. Untuk informasi selengkapnya, lihat Konfigurasikan parameter bidang kontrol Kubernetes lanjutan.

Bagian berikut menjelaskan setiap parameter, kapan harus mengubahnya, dan apa yang harus dipertimbangkan sebelum Anda melakukannya.

Penjadwal: sumber daya simpul cocok

Penjadwal menetapkan pod ke node dalam dua fase. Pertama-tama menyaring node yang dapat menjalankan pod, kemudian menilai kandidat yang tersisa dan menempatkan pod pada node skor tertinggi. nodeResourcesFitPlugin memeriksa apakah node memiliki sumber daya yang diminta pod, dan menilai node sesuai dengan strategi penilaian.

Bidang	Deskripsi	Nilai yang didukung	Default
`nodeResourcesFit.scoringStrategy.type`	Strategi yang digunakan untuk menilai node dengan alokasi sumber daya.	`LeastAllocated`, `MostAllocated`	`LeastAllocated`
`nodeResourcesFit.scoringStrategy.resources`	Sumber daya dipertimbangkan saat mencetak skor, masing-masing dengan bobot relatif.	`cpu`,`memory`,`nvidia.com/gpu`,`aws.amazon.com/neuron`,`aws.amazon.com/neuroncore`. Bobot dari `1` ke`100`.	`cpu: 1`, `memory: 1`

LeastAllocatedmendukung node dengan alokasi sumber daya yang lebih rendah, yang menyebarkan pod di seluruh node di cluster Anda dan menyisakan ruang kepala pada setiap node. Ini adalah perilaku Kubernetes default dan merupakan pilihan yang baik ketika Anda ingin kapasitas tersedia di setiap node untuk menyerap pertumbuhan pada pod yang ada.

MostAllocatedmendukung node yang sudah memiliki alokasi sumber daya yang lebih tinggi, yang mengemas pod ke node yang lebih sedikit. Karena beban kerja Anda menempati kapasitas total yang lebih sedikit, Anda dapat menjalankannya pada jumlah node yang lebih sedikit dan mengurangi pengeluaran komputasi. Seiring waktu, perilaku pengepakan ini membuat node yang jarang digunakan bebas dari beban kerja baru, sehingga kumpulan node yang mendukung konsolidasi dapat menghapusnya.

EKS mendukung MostAllocated strategi LeastAllocated dan. RequestedToCapacityRatioStrategi hulu Kubernetes tidak didukung.

Bobot sumber daya

Anda dapat secara opsional menentukan resources array dengan bobot khusus untuk mempengaruhi sumber daya mana yang paling penting dalam keputusan penilaian. Ini berguna ketika sumber daya tertentu adalah kendala di cluster Anda. Misalnya, pada cluster di mana akselerator (GPU) adalah sumber daya yang langka, bobot nvidia.com/gpu di atas CPU dan memori memusatkan pod yang meminta akselerator ke node yang sudah sebagian ditempati.

Bobot relatif, bukan absolut. Pengaturan cpu: 100 dan memory: 1 tidak menyebabkan penjadwal mengabaikan memori. Beratnya CPU 100 kali lebih berat daripada memori dalam formula penilaian. Jika setiap node kandidat memiliki ketersediaan CPU yang identik, CPU tidak lagi membedakannya dan skor secara efektif jatuh ke memori.

Menghilangkan sumber daya berbeda dengan memberinya bobot yang rendah. Saat Anda menentukan resources array, hanya sumber daya yang Anda daftarkan yang diberi skor. Sumber daya yang Anda tinggalkan dikecualikan dari perhitungan sepenuhnya. Misalnya, cpu: 100 tanpa nilai memory entri node pada CPU saja, dan ketersediaan memori tidak berpengaruh pada hasilnya. Untuk menjaga sumber daya dalam perhitungan sambil mengurangi pengaruhnya, daftarkan dengan bobot rendah daripada menghilangkannya.

Pembobotan sumber daya akselerator seperti nvidia.com/gpu hanya memengaruhi penilaian untuk pod yang benar-benar mendeklarasikan resources.requests untuk sumber daya tersebut. Pod yang tidak meminta akselerator tidak dipengaruhi oleh bobot akselerator.

Tiga sumber daya akselerator adalah sumber daya diperluas Kubernetes, yang berarti sumber daya tingkat node yang diiklankan ke Kubernetes oleh plugin daripada bawaan. Mereka diberi skor hanya ketika plugin perangkat mengiklankannya ke kubelet melalui API plugin perangkat. Sumber daya yang tersedia pada node oleh driver perangkat saja tidak terlihat oleh nodeResourcesFit plugin dan tidak diberi skor. Sumber daya yang dikelola melalui Dynamic Resource Allocation (DRA) dijadwalkan oleh plugin terpisah dan bukan bagian dari nodeResourcesFit penilaian, jadi mengaktifkan DRA tidak mengubah cara parameter ini berperilaku. Untuk informasi selengkapnya tentang mengkonfigurasi plugin perangkat NVIDIA, lihat NVIDIA DRA dan plugin perangkat. Untuk informasi selengkapnya tentang mengonfigurasi perangkat N euron, lihat Manajemen perangkat Neuron.

Strategi penilaian adalah salah satu dari beberapa input yang digunakan penjadwal untuk menghitung skor untuk setiap node. Untuk informasi selengkapnya tentang cara penjadwal memfilter dan menilai node, lihat Kerangka Pen jadwalan di dokumentasi Kubernetes.

Pertimbangan untuk strategi penilaian

Pod yang sedang berjalan tidak dipindahkan. Penjadwal Kubernetes tidak pernah memindahkan pod yang sudah berjalan. Mengubah strategi penilaian hanya memengaruhi keputusan penjadwalan di masa mendatang, dan penempatan pod yang ada bersifat permanen. Untuk menyeimbangkan kembali pod yang sudah berjalan, singkirkan atau mulai ulang.
Perilaku penyaringan tidak berubah. Strategi penilaian hanya memengaruhi fase penilaian, di mana penjadwal memberi peringkat node berdasarkan preferensi. Fase penyaringan, yang menentukan apakah pod dapat berjalan pada node sama sekali, tidak berubah. Pod yang tidak sesuai dengan node masih belum dijadwalkan di sana di bawah kedua strategi.
MostAllocatedberkonsentrasi radius ledakan. Mengepak beban kerja ke node yang lebih sedikit berarti lebih banyak pod yang terpengaruh sekaligus jika node menjadi tidak sehat, instance dihentikan, atau Zona Ketersediaan terganggu. Di bawah churn pod yang tinggi, node yang padat juga terisi lebih cepat, yang dapat membuat pod dalam Pending keadaan sementara kapasitas baru disediakan.
Penjadwal dan manajemen node beroperasi pada lapisan yang berbeda. Strategi penilaian mempengaruhi di mana pod ditempatkan di antara node yang sudah dapat menjalankannya. Itu tidak mengubah cara EKS Auto Mode atau Karpenter menyediakan atau menghapus node. Validasi perilaku gabungan untuk beban kerja Anda sebelum Anda mengubah konfigurasi.

Manajer pengontrol: Periode sinkronisasi Horizontal Pod Autoscaler

Pengelola pengontrol menjalankan pengontrol Kubernetes yang mendorong status cluster menuju status yang diinginkan, termasuk pengontrol Horizontal Pod Autoscaler (HPA). Pada setiap siklus, pengontrol HPA mengambil metrik untuk setiap HorizontalPodAutoscaler objek, menghitung jumlah replika yang diinginkan, dan memperbarui beban kerja target jika jumlah telah berubah.

Bidang	Deskripsi	Nilai yang didukung	Default
`horizontalPodAutoscalerControllerConfig.horizontalPodAutoscalerSyncPeriod`	Seberapa sering pengontrol HPA mengevaluasi keputusan penskalaan.	`10s` untuk `15s`	`15s`

Memperpendek periode sinkronisasi berarti beban kerja Anda berskala lebih cepat setelah beban meningkat, daripada menunggu siklus penuh sebelum menambah kapasitas.

Untuk mengonfigurasi parameter ini, cluster Anda harus berada di Amazon EKS Provisioned Control Plane. Memperpendek interval meningkatkan kecepatan di mana pengontrol HPA mendamaikan setiap HorizontalPodAutoscaler objek di cluster, yang menghasilkan lebih banyak permintaan API. Setiap rekonsiliasi mengkonsumsi setidaknya satu permintaan API, dan rekonsiliasi yang mengubah jumlah replika mengkonsumsi dua lagi. Cluster Control Plane yang disediakan telah mengalokasikan kapasitas bidang kontrol yang selalu siap untuk beban kerja yang menuntut, sehingga ukurannya disesuaikan untuk menyerap beban tambahan tersebut. Untuk informasi selengkapnya, lihat Pesawat Kontrol Tersediakan Amazon EKS.

Efek pada jumlah objek HPA yang didukung cluster Anda

Memperpendek periode sinkronisasi mengurangi jumlah HorizontalPodAutoscaler objek yang dapat direkonsiliasi bidang kontrol Anda sesuai jadwal, karena pengontrol memiliki lebih sedikit waktu untuk bekerja melalui antrian yang sama. Mengurangi periode dari 15s ke 10s menurunkan jumlah objek yang didukung kira-kira sepertiga. Sebelum mempersingkat periode sinkronisasi, hitung HorizontalPodAutoscaler objek di cluster Anda dan konfirmasikan periode yang lebih pendek masih mendukung penghitungan pada tingkat penskalaan Anda:
```
kubectl get hpa --all-namespaces --no-headers | wc -l
```
EKS tidak memvalidasi periode sinkronisasi terhadap jumlah objek HPA Anda. Perubahan konfigurasi berhasil bahkan jika cluster Anda sudah memiliki lebih banyak HorizontalPodAutoscaler objek daripada yang didukung periode yang lebih pendek. Periksa sendiri penghitungannya sebelum melakukan perubahan.
Melebihi jumlah yang didukung menurunkan skala otomatis secara diam-diam. Jika pengontrol tidak dapat bekerja melalui setiap objek dalam periode tersebut, beberapa objek tidak direkonsiliasi sesuai jadwal. EKS tidak memancarkan alarm atau peristiwa Kubernetes untuk kondisi ini, dan gejalanya adalah penskalaan otomatis yang merespons lebih lambat dari yang diharapkan — kebalikan dari efek yang dimaksudkan. Jika Anda mengamati penskalaan tertunda setelah memperpendek periode sinkronisasi, kembalikan parameter ke default. 15s
Periode sinkronisasi berlaku untuk setiap objek HPA di cluster. Anda tidak dapat mengatur periode sinkronisasi yang berbeda untuk objek atau ruang nama yang berbeda.

Manajer pengontrol: Ambang pengumpulan sampah pod yang dihentikan

Pengelola pengontrol menjalankan pengumpul sampah pod yang dihentikan (pengontrol pod GC). Pengontrol ini menghapus pod yang dihentikan—pod dalam Failed fase Succeeded or—setelah jumlah pod yang dihentikan dalam cluster melebihi ambang batas. terminatedPodGcThresholdParameter menetapkan ambang batas itu.

Bidang	Deskripsi	Nilai yang didukung	Default
`podGcControllerConfig.terminatedPodGcThreshold`	Jumlah pod yang dihentikan yang dapat ada sebelum pengumpul sampah pod yang dihentikan mulai menghapus pod yang dihentikan.	`10000` untuk `12500`	`12500`

Pengumpul sampah berjalan pada siklus 20 detik tetap. Saat Anda menurunkan ambang batas, kolektor mulai menghapus paksa pod terputus tertua pada siklus berikutnya hingga hitungan mencapai ambang batas baru.

Untuk mengonfigurasi parameter ini, cluster Anda harus berada di Amazon EKS Provisioned Control Plane. Menurunkan ambang batas meningkatkan pekerjaan pengumpulan sampah yang dilakukan pengontrol terhadap database cluster (etcd). Setiap pass pengumpulan memenuhi syarat untuk menanyakan, memproses, dan menghapus lebih banyak pod yang dihentikan. Cluster Control Plane yang disediakan telah mengalokasikan kapasitas bidang kontrol yang selalu siap untuk beban kerja yang menuntut, sehingga mereka dapat menyerap beban tambahan tersebut. Untuk informasi selengkapnya, lihat Pesawat Kontrol Tersediakan Amazon EKS.

Pertimbangan untuk ambang pengumpulan sampah pod yang dihentikan

Menurunkan ambang batas akan segera menghapus kelebihan pod yang dihentikan. Jika Anda menurunkan ambang batas (misalnya, dari 12500 ke10000), pengontrol pengumpulan sampah mulai menghapus paksa pod terputus tertua pada siklus berikutnya. Pengontrol berlanjut hingga jumlah pod yang dihentikan mencapai ambang batas baru. Pengurangannya tidak bertahap.
Ambang batas berlaku untuk semua pod yang dihentikan terlepas dari pemiliknya. Ini memengaruhi pod dalam Failed fase Succeeded atau apakah mereka dimiliki oleh Job, CronJob, atau Deployment, atau mandiri. Dalam praktiknya, Job CronJob dan pod adalah kontributor paling umum untuk jumlah pod yang dihentikan.
Menurunkan ambang batas mengurangi jendela debugging. Pod yang selesai dan gagal menghilang dari kubectl get pods dan lebih kubectl logs cepat. Otomatisasi yang memeriksa kode keluar atau log dari pod Job yang sudah selesai memiliki jendela yang lebih kecil untuk beroperasi.
Ambang batas adalah pengaturan cluster global. Anda tidak dapat mengonfigurasinya per namespace atau per Pekerjaan. Untuk mengontrol siklus hidup pod Job individual, gunakan ttlSecondsAfterFinished pada Job tersebut.

Server API: retensi acara

Server API adalah ujung depan untuk bidang kontrol Kubernetes. Ini melayani Kubernetes API dan mempertahankan status cluster ke database cluster (etcd). Kubernetes merekam peristiwa untuk menggambarkan apa yang terjadi di cluster Anda, seperti keputusan penjadwalan pod, penarikan gambar, kegagalan pemeriksaan kesehatan, dan tindakan penskalaan.

Bidang	Deskripsi	Nilai yang didukung	Default
`eventTtl`	Berapa lama server API menyimpan peristiwa Kubernetes sebelum menghapusnya.	`10m` untuk `60m`	`60m`

Cluster yang menjalankan beban kerja dengan churn tinggi, seperti pekerjaan batch skala besar, beban kerja AI, CI/CD pipeline, dan sering CronJobs, mengumpulkan ribuan peristiwa dengan cepat. Setiap peristiwa yang dipertahankan menghabiskan ruang database cluster yang bersaing dengan objek yang perlu dijalankan cluster Anda, dan koleksi peristiwa besar membuat operasi daftar server API lebih mahal untuk dilayani.

Memperpendek retensi peristiwa akan menghapus data diagnostik berumur pendek ini lebih cepat, yang mengurangi tekanan penyimpanan database cluster dan meningkatkan waktu respons server API untuk kueri yang padat peristiwa.

Periode retensi yang lebih pendek sangat cocok ketika:

Cluster Anda menjalankan batch CI/CD, AI, atau CronJob beban kerja yang menghasilkan volume peristiwa yang tinggi.
Anda mengamati penyimpanan database cluster tumbuh menuju batasnya.
Anda mengandalkan sistem eksternal untuk menangkap peristiwa secara tahan lama, dan Anda tidak bergantung pada kubectl get events debugging historis.

Pertimbangan untuk retensi acara

Perubahan hanya berlaku untuk acara baru. Kubernetes menetapkan kedaluwarsa acara saat acara dibuat. Peristiwa yang sudah ada mempertahankan periode retensi yang berlaku pada saat pembuatannya dan berakhir pada jadwal tersebut. Pemende eventTtl kan tidak mempersingkat masa pakai peristiwa yang sudah ada di database cluster, sehingga pengurangan penyimpanan berlaku secara bertahap seiring bertambahnya usia peristiwa yang ada.
Peristiwa yang dihapus tidak dapat dipulihkan. Setelah Kubernetes menghapus suatu peristiwa, peristiwa itu hilang secara permanen. Jika Anda mempersingkat retensi lebih dari yang dimaksudkan dan kehilangan riwayat peristiwa, tidak ada cara untuk memulihkannya. Verifikasi bahwa apa pun yang Anda andalkan untuk pemecahan masalah diambil di luar cluster sebelum memperpendek nilai ini.
Peristiwa dapat bertahan sedikit di luar periode yang dikonfigurasi. Dalam beberapa kondisi, kedaluwarsa acara dapat diperpanjang melewati nilai yang Anda konfigurasikan karena pembaruan sewa etcd yang mungkin terjadi selama pemilihan pemimpin pesawat kontrol.
Mengurangi jendela debugging. Periode retensi yang lebih pendek mempersempit jendela yang ditunjukkan oleh kubectl get events dankubectl describe. Alat pemantauan yang mengikis peristiwa dari cluster memiliki lebih sedikit data yang tersedia. Pilih nilai yang menyeimbangkan efisiensi penyimpanan terhadap alur kerja debugging Anda.
Pengaturannya di seluruh cluster. Retensi berlaku untuk semua peristiwa, termasuk penjadwalan pod, kondisi node, dan peristiwa penskalaan, di setiap namespace. Anda tidak dapat mengatur periode retensi yang berbeda per namespace.

Server API: rentang port simpul layanan

Kubernetes mengalokasikan port dari rentang ini pada setiap node untuk setiap layanan yang membutuhkannya. Ini termasuk layanan jenis NodePort dan, secara default, layanan jenisLoadBalancer.

Bidang	Deskripsi	Nilai yang didukung	Default
`serviceNodePortRange.minPort`	Port terendah dalam kisaran.	`10260` untuk `32767`	`30000`
`serviceNodePortRange.maxPort`	Port tertinggi dalam kisaran.	`10260` untuk `32767`	`32767`

minPortharus kurang dari atau sama denganmaxPort. Amazon EKS menolak konfigurasi yang minPort lebih besar darimaxPort.

Dengan mengubah rentang, Anda dapat menyelaraskan alokasi port node dengan kebijakan jaringan dan firewall yang sudah diberlakukan organisasi Anda. Memperluas jangkauan juga meningkatkan jumlah layanan yang dapat didukung oleh satu cluster. Parameter ini sangat berguna selama migrasi. Aplikasi yang pindah ke Amazon EKS, dan klien yang memanggilnya, sering mengharapkan layanan pada port tetap tertentu. Ketika port tersebut berada di luar rentang default, opsi yang biasa adalah memodifikasi aplikasi atau menempatkan proxy di depannya. Menyelaraskan rentang dengan port yang sudah digunakan aplikasi Anda menghapus pekerjaan itu, sehingga Anda dapat memindahkan beban kerja ke EKS tanpa menulis ulang atau menambahkan komponen jaringan untuk dipelihara.

Mengapa rentang dibatasi pada 10260 dan 32767

Batas bawah 10260 menjaga NodePort alokasi tetap bersih dari port yang sudah digunakan komponen sistem Kubernetes pada node Anda, termasuk port kesehatan kubelet (10248) dan port pemeriksaan kesehatan kube-proxy (). 10256

Batas atas 32767 menjaga jangkauan jauh dari rentang port sementara Linux, yang biasanya dimulai pada. 32768 Jika a NodePort berada di dalam rentang sementara, kernel dapat memilih port itu untuk koneksi keluar dari node dan bertentangan dengan layanan.

Pertimbangan untuk rentang port node layanan

Layanan yang ada mempertahankan port yang ditugaskan. Jika Anda mempersempit jangkauan, layanan yang sudah memiliki port di luar jangkauan baru terus berfungsi, dan kube-proxy terus merutekan lalu lintas ke mereka. Amazon EKS tidak menetapkan kembali port untuk layanan yang ada saat jangkauan berubah.
Menciptakan kembali layanan mengalokasikan kembali portnya. Jika layanan yang memiliki port di luar jangkauan dihapus dan dibuat ulang, port itu tidak dapat lagi ditetapkan. Rencanakan ini sebelum Anda mempersempit rentang yang bergantung pada layanan yang ada, terutama jika proses penerapan Anda membuat ulang layanan daripada memperbaruinya.
Alokasi baru di luar kisaran ditolak. Membuat atau memperbarui layanan yang memerlukan port di luar rentang yang dikonfigurasi gagal dengan kesalahan validasi dari server API.
Port yang ditentukan secara eksplisit juga divalidasi. Jika layanan menentukan nodePort nilai secara langsung daripada membiarkan Kubernetes menetapkannya, port itu harus berada dalam rentang yang dikonfigurasi. Permintaan port statis di luar jangkauan ditolak, bahkan jika port yang sama valid di bawah rentang yang lebih luas yang Anda konfigurasikan sebelumnya.
Kisarannya luas cluster. Anda tidak dapat mengonfigurasi rentang yang berbeda untuk ruang nama yang berbeda.

Sebelum Anda mengubah parameter ini, konfirmasikan bahwa grup keamanan dan ACL jaringan Anda mengizinkan lalu lintas pada rentang baru, dan jangkauan tersebut tidak bertentangan dengan port yang digunakan oleh perangkat lunak lain di node Anda.

Pertimbangan-pertimbangan

Tinjau hal berikut sebelum Anda mengonfigurasi parameter bidang kontrol lanjutan.

Cluster-wide cakupan — Parameter bidang kontrol berlaku untuk seluruh cluster dan untuk semua beban kerja yang berjalan di atasnya. Anda tidak dapat mencakupnya ke ruang nama individu atau beban kerja. Menguji perubahan parameter dalam cluster non-produksi sebelum Anda menerapkannya ke produksi.
Pesawat Kontrol Tersediakan diperlukan untuk periode sinkronisasi Horizontal Pod Autoscaler dan ambang pengumpulan sampah pod yang dihentikan — terminatedPodGcThreshold Parameter horizontalPodAutoscalerSyncPeriod dan hanya tersedia pada cluster yang menggunakan Amazon EKS Provisioned Control Plane. Amazon EKS membatasi parameter yang secara material meningkatkan konsumsi sumber daya bidang kontrol ke cluster dengan kapasitas bidang kontrol yang telah dialokasikan sebelumnya. Mengatur salah satu parameter pada cluster dalam mode bidang kontrol standar gagal. Untuk menggunakannya, pertama-tama pindahkan cluster Anda ke tingkat penskalaan Provisioned Control Plane. Untuk informasi selengkapnya, lihat Pesawat Kontrol Tersediakan Amazon EKS.
Batasan keluar untuk periode sinkronisasi Horizontal Pod Autoscaler dan ambang pengumpulan sampah pod yang dihentikan — Jika horizontalPodAutoscalerSyncPeriod atau terminatedPodGcThreshold disetel ke nilai selain default, Anda tidak dapat memindahkan bidang kontrol cluster Anda dari mode Penyediaan kembali ke mode Standar. Untuk kembali ke mode Standar, pertama-tama atur kedua parameter kembali ke defaultnya (15sdan12500), lalu ubah tingkat penskalaan bidang kontrol menjadistandard.
Kembali ke nilai default — Amazon EKS tidak menyediakan operasi reset khusus, dan menghilangkan bidang dari pembaruan membuat nilai saat ini tetap di tempatnya daripada menghapusnya. Untuk mengembalikan parameter ke defaultnya, atur secara eksplisit ke nilai default. Ambil nilai default DescribeClusterVersions untuk versi Kubernetes yang dijalankan cluster Anda. Untuk informasi selengkapnya, lihat Konfigurasikan parameter bidang kontrol Kubernetes lanjutan.
Perbarui semantik - Pembaruan bergabung dengan konfigurasi yang ada. Hanya bidang yang Anda tentukan berubah, dan bidang yang Anda hilangkan mempertahankan nilainya saat ini. Ini berlaku baik di seluruh komponen maupun dalam satu komponen. Misalnya, pembaruan yang hanya menentukan konfigurasi penjadwal membuat pengelola pengontrol dan konfigurasi server API Anda tidak berubah.
Melihat konfigurasi saat ini — describe-cluster Operasi mengembalikan konfigurasi lengkap yang berjalan di bidang kontrol Anda, termasuk parameter yang belum Anda sesuaikan dan nilai defaultnya.
Nilai default dan didukung dapat berubah di antara versi Kubernetes — Nilai yang didokumentasikan dalam topik ini berlaku untuk versi Kubernetes yang tersedia saat publikasi. Gunakan DescribeClusterVersions untuk mengambil nilai default dan didukung saat ini untuk setiap parameter dan versi Kubernetes. Lihat Konfigurasikan parameter bidang kontrol Kubernetes lanjutan.
Cluster yang ada tidak berubah — Amazon EKS tidak mengubah perilaku cluster yang ada. Semua cluster terus berjalan dengan nilai parameter default sampai Anda secara eksplisit menetapkan parameter.
Perubahan tidak diterapkan secara instan — Perubahan konfigurasi tidak berlaku saat pengem UpdateClusterConfig balian. Amazon EKS menerapkan konfigurasi baru melalui pembaruan bergulir dari bidang kontrol Anda, jadi harapkan beberapa menit sebelum perubahan berlaku penuh. Cluster kembali ke ACTIVE status saat pembaruan selesai. Anda dapat melacak kemajuan menggunakan DescribeUpdate operasi, atau memblokir hingga perubahan selesai menggunakanaws eks wait cluster-active.
Auditabilitas — Amazon EKS memvalidasi setiap konfigurasi sebelum menerapkannya, dan mencatat perubahan konfigurasi di. AWS CloudTrail
Dukungan perkakas — Konfigurasi bidang kontrol Kubernetes lanjutan tersedia melalui Konsol Manajemen AWS, eksctl, AWS CLI, Amazon EKS API, dan CDK saat peluncuran. AWS CloudFormation AWS Dukungan untuk Peng AWS ontrol untuk Kubernetes (ACK), dan Terraform akan segera hadir.
Dukungan versi Kubernetes — Konfigurasi bidang kontrol Kubernetes lanjutan didukung pada cluster baru dan yang sudah ada yang menjalankan Kubernetes versi 1.31 atau yang lebih baru.
AWS Dukungan wilayah — Konfigurasi pesawat kontrol Kubernetes lanjutan tersedia di semua Wilayah AWS komersial, Wilayah AWS GovCloud (AS), dan Wilayah AWS China di mana Amazon EKS tersedia.
Harga - Tidak ada biaya tambahan untuk mengonfigurasi parameter bidang kontrol. Penggunaan horizontalPodAutoscalerSyncPeriod memerlukan Provisioned Control Plane, yang ditagih dengan tarif per jam untuk tingkat penskalaan Anda. Untuk informasi selengkapnya, lihat harga Amazon EKS.

Langkah selanjutnya

Konfigurasikan parameter bidang kontrol Kubernetes lanjutan— Mengatur dan melihat parameter bidang kontrol menggunakan AWS CLI dan Konsol Manajemen AWS.
Pesawat Kontrol Tersediakan Amazon EKS— kapasitas pesawat Pre-allocate kontrol untuk kinerja tinggi yang dapat diprediksi.

Awas Javascript dinonaktifkan atau tidak tersedia di browser Anda.

Untuk menggunakan Dokumentasi AWS, Javascript harus diaktifkan. Lihat halaman Bantuan browser Anda untuk petunjuk.

Konvensi Dokumen

Memulai dengan Provisioned Control Plane

Konfigurasikan parameter bidang kontrol