**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.
# Siklus hidup dan konfigurasi klaster Amazon EKS
Bagian ini memberikan panduan mendalam tentang pengelolaan siklus hidup penuh klaster Kubernetes dan berbagai cara untuk mengonfigurasinya. Ini mencakup pembuatan cluster, memantau kesehatan klaster, memperbarui versi Kubernetes, dan menghapus cluster. Ini juga mencakup topik lanjutan tentang cara mengkonfigurasi akses titik akhir, dukungan enable/disable Windows, mengatur cluster pribadi, menerapkan penskalaan otomatis, dan cara meningkatkan ketahanan dengan pergeseran zona untuk pengalihan lalu lintas dalam pengaturan multi-AZ.
**Topics**
+ [Buat kluster Mode Otomatis Amazon EKS](create-cluster-auto.md)
+ [Buat kluster Amazon EKS](create-cluster.md)
+ [Pesawat Kontrol yang Disediakan Amazon EKS](eks-provisioned-control-plane.md)
+ [Bersiaplah untuk upgrade versi Kubernetes dan pecahkan masalah kesalahan konfigurasi dengan wawasan klaster](cluster-insights.md)
+ [Perbarui klaster yang ada ke versi Kubernetes baru](update-cluster.md)
+ [Hapus klaster](delete-cluster.md)
+ [Titik akhir server API kluster](cluster-endpoint.md)
+ [Menerapkan node Windows pada kluster EKS](windows-support.md)
+ [Nonaktifkan dukungan Windows](disable-windows-support.md)
+ [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md)
+ [Komputasi klaster skala dengan Karpenter dan Cluster Autoscaler](autoscaling.md)
+ [Pelajari tentang pergeseran zona Amazon Application Recovery Controller (ARC) di Amazon EKS](zone-shift.md)
+ [Aktifkan pergeseran zona EKS untuk menghindari Zona Ketersediaan yang terganggu](zone-shift-enable.md)
# Buat kluster Mode Otomatis Amazon EKS
Topik ini memberikan petunjuk terperinci untuk membuat kluster Mode Otomatis Amazon EKS menggunakan opsi konfigurasi lanjutan. Ini mencakup prasyarat, opsi jaringan, dan konfigurasi add-on. Prosesnya meliputi pengaturan peran IAM, mengonfigurasi pengaturan cluster, menentukan parameter jaringan, dan memilih add-on. Pengguna dapat membuat cluster menggunakan CLI Konsol Manajemen AWS atau, step-by-step dengan panduan yang disediakan untuk kedua metode. AWS
Untuk pengguna yang mencari proses penyiapan yang kurang kompleks, lihat berikut ini untuk langkah-langkah pembuatan klaster yang disederhanakan:
+ [Buat Kluster Mode Otomatis EKS dengan CLI eksctl](automode-get-started-eksctl.md)
+ [Buat Kluster Mode Otomatis EKS dengan AWS CLI](automode-get-started-cli.md)
+ [Buat Kluster Mode Otomatis EKS dengan Konsol Manajemen AWS](automode-get-started-console.md)
Panduan konfigurasi lanjutan ini ditujukan untuk pengguna yang memerlukan kontrol lebih terperinci atas pengaturan kluster Mode Otomatis EKS mereka dan terbiasa dengan konsep dan persyaratan Amazon EKS. Sebelum melanjutkan dengan konfigurasi lanjutan, pastikan Anda telah memenuhi semua prasyarat dan memiliki pemahaman menyeluruh tentang jaringan dan persyaratan IAM untuk kluster Mode Otomatis EKS.
Mode Otomatis EKS memerlukan izin IAM tambahan. Untuk informasi lebih lanjut, lihat:
+ [Peran IAM untuk Kluster Mode Otomatis EKS](automode-get-started-cli.md#auto-mode-create-roles)
+ [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md)
**catatan**
Jika Anda ingin membuat cluster tanpa Mode Otomatis EKS, lihat[Buat kluster Amazon EKS](create-cluster.md).
Topik ini mencakup konfigurasi lanjutan. Jika Anda ingin memulai dengan Mode Otomatis EKS, lihat[Buat cluster dengan Amazon EKS Auto Mode](create-auto.md).
## Prasyarat
+ VPC dan subnet yang ada yang memenuhi persyaratan [Amazon](network-reqs.md) EKS. Sebelum Anda menerapkan klaster untuk penggunaan produksi, kami sarankan Anda memiliki pemahaman menyeluruh tentang persyaratan VPC dan subnet. Jika Anda tidak memiliki VPC dan subnet, Anda dapat membuatnya menggunakan template yang disediakan [Amazon EKS](creating-a-vpc.md). AWS CloudFormation
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Misalnya, jika versi cluster Anda`1.29`, Anda dapat menggunakan `kubectl` versi`1.28`,`1.29`, atau `1.30` dengan itu. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version`. Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*.
+ [Prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) dengan izin untuk membuat dan memodifikasi sumber daya EKS dan IAM.
## Buat cluster - AWS konsol
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih **Add cluster** dan kemudian pilih **Create**.
1. Di bawah *Opsi konfigurasi*, pilih **Konfigurasi kustom**.
+ Topik ini mencakup konfigurasi kustom. Untuk informasi tentang Konfigurasi cepat, lihat[Buat Kluster Mode Otomatis EKS dengan Konsol Manajemen AWS](automode-get-started-console.md).
1. Konfirmasikan **Gunakan Mode Otomatis EKS** diaktifkan.
+ Topik ini mencakup pembuatan cluster dengan Mode Otomatis EKS. Untuk informasi selengkapnya tentang membuat cluster tanpa Mode Otomatis EKS, lihat[Buat kluster Amazon EKS](create-cluster.md).
1. Pada halaman **Configure cluster**, masukkan bidang-bidang berikut:
+ **Nama** — Nama untuk klaster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil), tanda hubung, dan garis bawah. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ Peran **IAM Cluster — Pilih peran** IAM klaster Amazon EKS yang Anda buat untuk memungkinkan bidang kontrol Kubernetes mengelola AWS sumber daya atas nama Anda. Jika sebelumnya Anda belum membuat peran IAM Cluster untuk Mode Otomatis EKS, pilih tombol **Buat peran yang disarankan** untuk membuat peran dengan izin yang diperlukan di konsol IAM.
+ **Versi Kubernetes** — Versi Kubernetes untuk digunakan untuk klaster Anda. Sebaiknya pilih versi terbaru, kecuali jika Anda memerlukan versi sebelumnya.
+ **Kebijakan upgrade — Kebijakan** versi Kubernetes yang ingin Anda tetapkan untuk klaster Anda. Jika Anda ingin klaster Anda hanya berjalan pada versi dukungan standar, Anda dapat memilih **Standar**. Jika Anda ingin klaster Anda memasukkan dukungan yang diperluas di akhir dukungan standar untuk sebuah versi, Anda dapat memilih **Extended**. Jika Anda memilih versi Kubernetes yang saat ini dalam dukungan diperpanjang, Anda tidak dapat memilih dukungan standar sebagai opsi.
1. Di bagian **Komputasi Mode Otomatis** pada halaman cluster konfigurasi, masukkan bidang berikut:
+ **Node pool** — Tentukan apakah Anda ingin menggunakan build in node pool. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
+ **Peran IAM Node** - Jika Anda mengaktifkan salah satu kumpulan node bawaan, Anda harus memilih Peran IAM Node. Mode Otomatis EKS akan menetapkan peran ini ke node baru. Anda tidak dapat mengubah nilai ini setelah cluster dibuat. Jika sebelumnya Anda belum membuat peran IAM Node untuk Mode Otomatis EKS, pilih tombol Buat peran yang disarankan untuk membuat peran dengan izin yang diperlukan. Untuk informasi selengkapnya tentang peran ini, silakan lihat [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md).
1. Di bagian **akses Cluster** pada halaman cluster konfigurasi, masukkan bidang berikut:
+ **Akses administrator klaster Bootstrap** - Pembuat klaster secara otomatis adalah administrator Kubernetes. Jika Anda ingin menonaktifkan ini, pilih **Larang akses administrator klaster**.
+ Mode **otentikasi cluster — Mode** Otomatis EKS memerlukan entri akses EKS, mode otentikasi EKS API. Anda dapat mengaktifkan mode `ConfigMap` otentikasi secara opsional dengan memilih **EKS API** dan. ConfigMap
1. Masukkan bidang yang tersisa di halaman konfigurasikan cluster:
+ **Enkripsi rahasia** — (Opsional) Pilih untuk mengaktifkan enkripsi rahasia rahasia Kubernetes menggunakan kunci KMS. Anda juga dapat mengaktifkan ini setelah Anda membuat cluster Anda. Sebelum Anda mengaktifkan kemampuan ini, pastikan Anda sudah terbiasa dengan informasi di dalamnya[Enkripsi rahasia Kubernetes dengan KMS di cluster yang ada](enable-kms.md).
+ **ARC Zonal shift** — Mode Otomatis EKS tidak mendukung pergeseran Arc Zonal.
+ **Tanda** — (Opsional) Tambahkan tanda apapun ke klaster Anda. Untuk informasi selengkapnya, lihat [Mengatur sumber daya Amazon EKS dengan tag](eks-using-tags.md).
Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Tentukan jaringan**, pilih nilai untuk kolom berikut:
+ **VPC** — Pilih VPC yang sudah ada yang memenuhi [persyaratan Amazon EKS VPC](network-reqs.md#network-requirements-vpc) untuk membuat klaster Anda. Sebelum memilih VPC, kami sarankan Anda memahami semua persyaratan dan pertimbangan di dalamnya. [Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet](network-reqs.md) Anda tidak dapat mengubah VPC mana yang ingin Anda gunakan setelah pembuatan cluster. Jika tidak VPCs terdaftar, maka Anda harus membuatnya terlebih dahulu. Untuk informasi selengkapnya, lihat [Buat VPC Amazon untuk kluster Amazon EKS Anda](creating-a-vpc.md).
+ **Subnet** — Secara default, semua subnet yang tersedia di VPC yang ditentukan di bidang sebelumnya telah dipilih sebelumnya. Anda harus memilih setidaknya dua.
Subnet yang Anda pilih harus memenuhi persyaratan [subnet Amazon EKS](network-reqs.md#network-requirements-subnets). Sebelum memilih subnet, sebaiknya Anda terbiasa dengan semua persyaratan dan pertimbangan [VPC Amazon EKS dan subnet](network-reqs.md).
**Grup keamanan** — (Opsional) Tentukan satu atau beberapa grup keamanan yang ingin Anda kaitkan Amazon EKS ke antarmuka jaringan yang dibuatnya.
Apakah Anda memilih grup keamanan atau tidak, Amazon EKS membuat grup keamanan yang memungkinkan komunikasi antara cluster dan VPC Anda. Amazon EKS mengaitkan grup keamanan ini, dan apa pun yang Anda pilih, ke antarmuka jaringan yang dibuatnya. Untuk informasi selengkapnya tentang grup keamanan klaster yang dibuat Amazon EKS, lihat[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Anda dapat mengubah aturan di grup keamanan klaster yang dibuat Amazon EKS.
+ **Pilih keluarga alamat IP cluster** — Anda dapat memilih salah satu **IPv4**dan **IPv6**.
Kubernetes memberikan `IPv4` alamat ke Pod dan layanan, secara default. Sebelum memutuskan untuk menggunakan `IPv6` keluarga, pastikan Anda sudah terbiasa dengan semua pertimbangan dan persyaratan dalam persyaratan dan pertimbangan [VPC[Persyaratan dan pertimbangan subnet](network-reqs.md#network-requirements-subnets),[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md), dan](network-reqs.md#network-requirements-vpc) topik. [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) Jika Anda memilih `IPv6` keluarga, Anda tidak dapat menentukan rentang alamat untuk Kubernetes untuk menetapkan alamat `IPv6` layanan seperti yang Anda bisa untuk keluarga. `IPv4` Kubernetes memberikan alamat layanan dari rentang alamat lokal yang unik (). `fc00::/7`
+ **(Opsional) Pilih **Konfigurasi rentang alamat IP Layanan Kubernetes dan tentukan rentang** Layanan. `IPv4`**
Menentukan jangkauan Anda sendiri dapat membantu mencegah konflik antara layanan Kubernetes dan jaringan lain yang di-peer atau terhubung ke VPC Anda. Masukkan rentang dalam notasi CIDR. Sebagai contoh: `10.2.0.0/16`.
Blok CIDR harus memenuhi persyaratan berikut:
+ Berada dalam salah satu rentang berikut:`10.0.0.0/8`,`172.16.0.0/12`, atau`192.168.0.0/16`.
+ Memiliki ukuran minimum `/24` dan ukuran maksimum`/12`.
+ Tidak tumpang tindih dengan kisaran VPC untuk sumber daya Amazon EKS Anda.
Anda hanya dapat menentukan opsi ini saat menggunakan keluarga `IPv4` alamat dan hanya pada pembuatan cluster. Jika Anda tidak menentukan ini, maka Kubernetes memberikan alamat IP layanan dari blok atau CIDR. `10.100.0.0/16` `172.20.0.0/16`
+ Untuk **akses endpoint Cluster**, pilih opsi. Setelah cluster Anda dibuat, Anda dapat mengubah opsi ini. Sebelum memilih opsi non-default, pastikan untuk membiasakan diri dengan opsi dan implikasinya. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. (Opsional) Pada halaman **Konfigurasi observabilitas**, pilih opsi **pencatatan bidang **Metrik** dan Kontrol** mana yang akan diaktifkan. Secara default, setiap jenis log dimatikan.
+ Untuk informasi selengkapnya tentang opsi metrik Prometheus, lihat. [Langkah 1: Aktifkan metrik Prometheus](prometheus.md#turn-on-prometheus-metrics)
+ Untuk informasi selengkapnya tentang opsi **Pencatatan bidang kontrol**, lihat[Kirim log pesawat kontrol ke CloudWatch Log](control-plane-logs.md).
+ Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Pilih add-on**, pilih add-on yang ingin Anda tambahkan ke cluster Anda. Anda dapat memilih add-on **Amazon EKS dan add-on AWS ** **Marketplace** sebanyak yang Anda butuhkan. Jika **add-on AWS Marketplace** yang ingin Anda instal tidak terdaftar, Anda dapat mengklik penomoran halaman untuk melihat hasil halaman tambahan atau mencari **add-on AWS Marketplace** yang tersedia dengan memasukkan teks di kotak pencarian. Anda juga dapat memfilter berdasarkan **kategori**, **vendor**, atau **model harga** dan kemudian memilih add-on dari hasil pencarian. Saat membuat cluster, Anda dapat melihat, memilih, dan menginstal add-on apa pun yang mendukung EKS Pod Identities seperti yang dijelaskan di dalamnya. [Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS](pod-identities.md)
+ Mode Otomatis EKS mengotomatiskan fungsionalitas add-on tertentu. Jika Anda berencana untuk menerapkan Grup Node Terkelola EKS ke Kluster Mode Otomatis EKS Anda, pilih **Add-on Amazon EKS Tambahan** dan tinjau opsinya. Anda mungkin perlu menginstal add-on seperti CoreDNS dan kube-proxy. EKS hanya akan menginstal add-on di bagian ini pada node dan grup node yang dikelola sendiri.
+ Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Konfigurasi pengaturan add-on yang dipilih**, pilih versi yang ingin Anda instal. Anda selalu dapat memperbarui ke versi yang lebih baru setelah pembuatan cluster.
Untuk add-on yang mendukung Identitas Pod EKS, Anda dapat menggunakan konsol untuk membuat peran secara otomatis dengan nama, kebijakan AWS terkelola, dan kebijakan kepercayaan yang telah diisi sebelumnya secara khusus untuk add-on. Anda dapat menggunakan kembali peran yang ada atau membuat peran baru untuk add-on yang didukung. Untuk langkah-langkah menggunakan konsol untuk membuat peran untuk add-on yang mendukung EKS Pod Identities, lihat. [Buat add-on (AWS Konsol)](creating-an-add-on.md#create_add_on_console) Jika add-on tidak mendukung EKS Pod Identity, pesan akan ditampilkan dengan instruksi untuk menggunakan wizard untuk membuat peran IAM untuk akun layanan (IRSA) setelah cluster dibuat.
Anda dapat memperbarui konfigurasi setiap add-on setelah pembuatan cluster. Untuk informasi selengkapnya tentang mengonfigurasi add-on, lihat. [Perbarui add-on Amazon EKS](updating-an-add-on.md) Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Tinjau dan buat**, tinjau informasi yang Anda masukkan atau pilih pada halaman sebelumnya. Jika Anda perlu melakukan perubahan, pilih **Edit**. Saat Anda puas, pilih **Buat**. Bidang **Status** menunjukkan **CREATING** saat cluster disediakan.
**catatan**
Anda mungkin menerima kesalahan bahwa salah satu Availability Zone dalam permintaan Anda tidak memiliki kapasitas yang cukup untuk membuat klaster Amazon EKS. Jika hal ini terjadi, output galat berisi Availability Zones yang dapat mendukung klaster baru. Cobalah untuk kembali membuat klaster dengan setidaknya dua subnet yang terletak di Availability Zones yang didukung untuk akun Anda. Untuk informasi selengkapnya, lihat [Kapasitas tidak mencukupi](troubleshooting.md#ice).
Penyediaan klaster memerlukan waktu beberapa menit.
## Buat cluster - AWS CLI
Instruksi CLI berikut mencakup pembuatan sumber daya IAM dan membuat cluster.
### Membuat Peran IAM Kluster Mode Otomatis EKS
#### Langkah 1: Buat Kebijakan Kepercayaan
Buat kebijakan kepercayaan yang memungkinkan layanan Amazon EKS untuk mengambil peran. Simpan kebijakan sebagai`trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": [
"sts:AssumeRole",
"sts:TagSession"
]
}
]
}
```
#### Langkah 2: Buat Peran IAM
Gunakan kebijakan kepercayaan untuk membuat Peran IAM Cluster:
```
aws iam create-role \
--role-name AmazonEKSAutoClusterRole \
--assume-role-policy-document file://trust-policy.json
```
#### Langkah 3: Perhatikan Peran ARN
Ambil dan simpan ARN dari peran baru untuk digunakan dalam langkah-langkah selanjutnya:
```
aws iam get-role --role-name AmazonEKSAutoClusterRole --query "Role.Arn" --output text
```
#### Langkah 4: Lampirkan Kebijakan yang Diperlukan
Lampirkan kebijakan AWS terkelola berikut ke Peran IAM Cluster untuk memberikan izin yang diperlukan:
**EKSClusterKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy
```
**EKSComputeKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSComputePolicy
```
**Amazon EKSBlock StoragePolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSBlockStoragePolicy
```
**Amazon EKSLoad BalancingPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSLoadBalancingPolicy
```
**EKSNetworkingKebijakan Amazon**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSNetworkingPolicy
```
### Buat Peran IAM Node Mode Otomatis EKS
#### Langkah 1: Buat Kebijakan Kepercayaan
Buat kebijakan kepercayaan yang memungkinkan layanan Amazon EKS untuk mengambil peran. Simpan kebijakan sebagai`node-trust-policy.json`:
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
#### Langkah 2: Buat Peran IAM Node
Gunakan **node-trust-policyfile.json** dari langkah sebelumnya untuk menentukan entitas mana yang dapat mengambil peran. Jalankan perintah berikut untuk membuat Peran IAM Node:
```
aws iam create-role \
--role-name AmazonEKSAutoNodeRole \
--assume-role-policy-document file://node-trust-policy.json
```
#### Langkah 3: Perhatikan Peran ARN
Setelah membuat peran, ambil dan simpan ARN dari Peran IAM Node. Anda akan membutuhkan ARN ini pada langkah selanjutnya. Gunakan perintah berikut untuk mendapatkan ARN:
```
aws iam get-role --role-name AmazonEKSAutoNodeRole --query "Role.Arn" --output text
```
#### Langkah 4: Lampirkan Kebijakan yang Diperlukan
Lampirkan kebijakan AWS terkelola berikut ke Peran IAM Node untuk memberikan izin yang diperlukan:
**Amazon EKSWorker NodeMinimalPolicy**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSWorkerNodeMinimalPolicy
```
**Amazon EC2 ContainerRegistryPullOnly**:
```
aws iam attach-role-policy \
--role-name AmazonEKSAutoNodeRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEC2ContainerRegistryPullOnly
```
### Buat cluster
1. Buat cluster Anda dengan perintah berikut. Sebelum menjalankan perintah, buat penggantian berikut:
+ Ganti *region-code* dengan AWS Region tempat Anda ingin membuat cluster Anda.
+ Ganti *my-cluster* dengan nama untuk cluster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil), tanda hubung, dan garis bawah. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ Ganti *1.30* dengan [versi yang didukung Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Ganti *111122223333* dengan ID akun Anda
+ Jika Anda telah membuat Peran IAM dengan nama berbeda untuk peran Cluster dan Node, ganti. ARNs
+ Ganti nilainya `subnetIds` dengan nilai Anda sendiri. Anda juga dapat menambahkan tambahan IDs. Anda harus menentukan setidaknya dua subnet IDs.
Subnet yang Anda pilih harus memenuhi persyaratan [subnet Amazon EKS](network-reqs.md#network-requirements-subnets). Sebelum memilih subnet, sebaiknya Anda terbiasa dengan semua persyaratan dan pertimbangan [VPC Amazon EKS dan subnet](network-reqs.md).
+ Jika Anda tidak ingin menentukan ID grup keamanan, hapus `,securityGroupIds=sg-` dari perintah. Jika Anda ingin menentukan satu atau beberapa grup keamanan IDs, ganti nilainya `securityGroupIds` dengan milik Anda sendiri. Anda juga dapat menambahkan tambahan IDs.
Apakah Anda memilih grup keamanan atau tidak, Amazon EKS membuat grup keamanan yang memungkinkan komunikasi antara cluster dan VPC Anda. Amazon EKS mengaitkan grup keamanan ini, dan apa pun yang Anda pilih, ke antarmuka jaringan yang dibuatnya. Untuk informasi selengkapnya tentang grup keamanan klaster yang dibuat Amazon EKS, lihat[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Anda dapat mengubah aturan di grup keamanan klaster yang dibuat Amazon EKS.
```
aws eks create-cluster \
--region region-code \
--name my-cluster \
--kubernetes-version 1.30 \
--role-arn arn:aws: iam::111122223333:role/AmazonEKSAutoClusterRole \
--resources-vpc-config '{"subnetIds": ["subnet-ExampleID1","subnet-ExampleID2"], "securityGroupIds": ["sg-ExampleID1"], "endpointPublicAccess": true, "endpointPrivateAccess": true}' \
--compute-config '{"enabled": true, "nodeRoleArn": "arn:aws: iam::111122223333:role/AmazonEKSAutoNodeRole", "nodePools": ["general-purpose", "system"]}' \
--kubernetes-network-config '{"elasticLoadBalancing": {"enabled": true}}' \
--storage-config '{"blockStorage": {"enabled": true}}' \
--access-config '{"authenticationMode": "API"}'
```
**catatan**
Anda mungkin menerima kesalahan bahwa salah satu Availability Zone dalam permintaan Anda tidak memiliki kapasitas yang cukup untuk membuat klaster Amazon EKS. Jika hal ini terjadi, output galat berisi Availability Zones yang dapat mendukung klaster baru. Cobalah untuk kembali membuat klaster dengan setidaknya dua subnet yang terletak di Availability Zones yang didukung untuk akun Anda. Untuk informasi selengkapnya, lihat [Kapasitas tidak mencukupi](troubleshooting.md#ice).
Berikut ini adalah pengaturan opsional yang, jika diperlukan, harus ditambahkan ke perintah sebelumnya. Anda hanya dapat mengaktifkan opsi ini saat Anda membuat cluster, bukan setelahnya.
+ Jika Anda ingin menentukan dari mana `IPv4` Classless Inter-domain Routing (CIDR) blok Kubernetes memberikan alamat IP layanan, Anda harus menentukannya dengan menambahkan ke perintah berikut. `--kubernetes-network-config serviceIpv4Cidr=`
Menentukan jangkauan Anda sendiri dapat membantu mencegah konflik antara layanan Kubernetes dan jaringan lain yang di-peer atau terhubung ke VPC Anda. Masukkan rentang dalam notasi CIDR. Sebagai contoh: `10.2.0.0/16`.
Blok CIDR harus memenuhi persyaratan berikut:
+ Berada dalam salah satu rentang berikut:`10.0.0.0/8`,`172.16.0.0/12`, atau`192.168.0.0/16`.
+ Memiliki ukuran minimum `/24` dan ukuran maksimum`/12`.
+ Tidak tumpang tindih dengan kisaran VPC untuk sumber daya Amazon EKS Anda.
Anda hanya dapat menentukan opsi ini saat menggunakan keluarga `IPv4` alamat dan hanya pada pembuatan cluster. Jika Anda tidak menentukan ini, maka Kubernetes memberikan alamat IP layanan dari blok atau CIDR. `10.100.0.0/16` `172.20.0.0/16`
+ Jika Anda membuat klaster dan ingin klaster menetapkan `IPv6` alamat ke Pod dan layanan, bukan `IPv4` alamat, tambahkan `--kubernetes-network-config ipFamily=ipv6` ke perintah berikut.
Kubernetes memberikan `IPv4` alamat ke Pod dan layanan, secara default. Sebelum memutuskan untuk menggunakan `IPv6` keluarga, pastikan Anda sudah terbiasa dengan semua pertimbangan dan persyaratan dalam persyaratan dan pertimbangan [VPC[Persyaratan dan pertimbangan subnet](network-reqs.md#network-requirements-subnets),[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md), dan](network-reqs.md#network-requirements-vpc) topik. [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) Jika Anda memilih `IPv6` keluarga, Anda tidak dapat menentukan rentang alamat untuk Kubernetes untuk menetapkan alamat `IPv6` layanan seperti yang Anda bisa untuk keluarga. `IPv4` Kubernetes memberikan alamat layanan dari rentang alamat lokal yang unik (). `fc00::/7`
1. Dibutuhkan beberapa menit untuk menyediakan cluster. Anda dapat melakukan kueri status klaster Anda dengan perintah berikut.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
## Langkah selanjutnya
+ [Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md)
+ [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md)
+ [Aktifkan enkripsi rahasia untuk cluster Anda](enable-kms.md).
+ [Konfigurasikan logging untuk klaster Anda](control-plane-logs.md).
+ [Tambahkan node ke cluster Anda](eks-compute.md).
# Buat kluster Amazon EKS
**catatan**
Topik ini mencakup pembuatan cluster Amazon EKS tanpa Mode Otomatis EKS.
Untuk petunjuk rinci tentang membuat kluster Mode Otomatis EKS, lihat[Buat kluster Mode Otomatis Amazon EKS](create-cluster-auto.md).
Untuk memulai dengan Mode Otomatis EKS, lihat[Memulai Amazon EKS — Mode Otomatis EKS](getting-started-automode.md).
Topik ini memberikan ikhtisar opsi yang tersedia dan menjelaskan apa yang harus dipertimbangkan saat Anda membuat klaster Amazon EKS. Jika Anda perlu membuat klaster dengan infrastruktur lokal sebagai komputasi untuk node, lihat. [Buat klaster Amazon EKS dengan node hybrid](hybrid-nodes-cluster-create.md) Jika ini adalah pertama kalinya Anda membuat cluster Amazon EKS, kami sarankan Anda mengikuti salah satu panduan kami di[Memulai dengan Amazon EKS](getting-started.md). Panduan ini membantu Anda membuat cluster default yang sederhana tanpa memperluas ke semua opsi yang tersedia.
## Prasyarat
+ VPC dan subnet yang ada yang memenuhi persyaratan [Amazon](network-reqs.md) EKS. Sebelum Anda menerapkan klaster untuk penggunaan produksi, kami sarankan Anda memiliki pemahaman menyeluruh tentang persyaratan VPC dan subnet. Jika Anda tidak memiliki VPC dan subnet, Anda dapat membuatnya menggunakan template yang disediakan [Amazon EKS](creating-a-vpc.md). AWS CloudFormation
+ Alat baris `kubectl` perintah diinstal pada perangkat Anda atau AWS CloudShell. Versinya bisa sama dengan atau hingga satu versi minor lebih awal atau lebih lambat dari versi Kubernetes dari klaster Anda. Untuk menginstal atau memutakhirkan `kubectl`, lihat [Mengatur `kubectl` dan `eksctl`](install-kubectl.md).
+ Versi `2.12.3` atau yang lebih baru atau versi `1.27.160` atau yang lebih baru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda atau. AWS CloudShell Untuk memeriksa versi Anda saat ini, gunakan`aws --version | cut -d / -f2 | cut -d ' ' -f1`. Package manager seperti `yum``apt-get`,, atau Homebrew untuk macOS seringkali merupakan beberapa versi di belakang versi terbaru CLI. AWS Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) dan [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Versi AWS CLI yang diinstal AWS CloudShell mungkin juga beberapa versi di belakang versi terbaru. Untuk memperbaruinya, lihat [Menginstal AWS CLI ke direktori home Anda](https://docs.aws.amazon.com/cloudshell/latest/userguide/vm-specs.html#install-cli-software) di * AWS CloudShell Panduan Pengguna*.
+ [Prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) dengan izin `create` dan kluster `describe` Amazon EKS. Untuk informasi selengkapnya, lihat [Buat klaster Kubernetes lokal di Outpost](security-iam-id-based-policy-examples.md#policy-create-local-cluster) dan [Buat daftar atau deskripsikan semua klaster](security-iam-id-based-policy-examples.md#policy-example2).
## Langkah 1: Buat peran IAM cluster
1. Jika Anda sudah memiliki peran IAM cluster, atau Anda akan membuat cluster Anda dengan`eksctl`, maka Anda dapat melewati langkah ini. Secara default, `eksctl` buat peran untuk Anda.
1. Jalankan perintah berikut untuk membuat file JSON kebijakan kepercayaan IAM.
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat peran IAM cluster Amazon EKS. Jika perlu, kata pengantar *eks-cluster-role-trust-policy.json* dengan jalur di komputer Anda tempat Anda menulis file pada langkah sebelumnya. Perintah tersebut mengaitkan kebijakan kepercayaan yang Anda buat pada langkah sebelumnya dengan peran tersebut. Untuk membuat peran IAM, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang membuat peran harus diberi `iam:CreateRole` tindakan (izin).
```
aws iam create-role --role-name myAmazonEKSClusterRole --assume-role-policy-document file://"eks-cluster-role-trust-policy.json"
```
1. Anda dapat menetapkan kebijakan terkelola Amazon EKS atau membuat kebijakan kustom Anda sendiri. Untuk izin minimum yang harus Anda gunakan dalam kebijakan kustom, lihat[IAM role klaster Amazon EKS](cluster-iam-role.md).
Lampirkan kebijakan terkelola Amazon EKS bernama [EKSClusterKebijakan Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSClusterPolicy.html#AmazonEKSClusterPolicy-json) ke peran tersebut. Untuk melampirkan kebijakan IAM ke kepala sekolah [IAM, prinsipal](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang melampirkan kebijakan harus diberikan salah satu tindakan IAM berikut (izin): atau. `iam:AttachUserPolicy` `iam:AttachRolePolicy`
```
aws iam attach-role-policy --policy-arn arn:aws: iam::aws:policy/AmazonEKSClusterPolicy --role-name myAmazonEKSClusterRole
```
### Peran Tertaut Layanan
Amazon EKS secara otomatis membuat peran terkait layanan yang disebut`AWSServiceRoleForAmazonEKS`.
Ini adalah tambahan untuk peran IAM cluster. Peran tertaut layanan adalah jenis IAM role unik yang terkait langsung dengan Amazon EKS. Peran ini memungkinkan Amazon EKS untuk mengelola cluster di akun Anda. Untuk informasi selengkapnya, lihat [Menggunakan peran untuk klaster Amazon EKS](using-service-linked-roles-eks.md).
Identitas IAM yang Anda gunakan untuk membuat kluster EKS harus memiliki izin untuk membuat peran terkait layanan. Ini termasuk `iam:CreateServiceLinkedRole` izin.
Jika peran terkait layanan belum ada, dan peran IAM Anda saat ini tidak memiliki izin yang cukup untuk membuatnya, operasi pembuatan klaster akan gagal.
## Langkah 2: Buat cluster
Anda dapat membuat cluster dengan menggunakan:
+ [`eksctl`](#step2-eksctl)
+ [yang Konsol Manajemen AWS](#step2-console)
+ [AWS CLI](#step2-cli)
### Buat cluster - eksctl
1. Anda memerlukan versi `0.215.0` atau yang lebih baru dari alat baris `eksctl` perintah yang diinstal pada perangkat Anda atau AWS CloudShell. Untuk menginstal atau memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
1. Buat `IPv4` klaster Amazon EKS dengan versi Kubernetes default Amazon EKS di Region default Anda. AWS Sebelum menjalankan perintah, buat penggantian berikut:
1. Ganti *region-code* dengan AWS Region tempat Anda ingin membuat cluster Anda.
1. Ganti *my-cluster* dengan nama untuk cluster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil) dan tanda hubung. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
1. Ganti *1.35* dengan [versi yang didukung Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
1. Ubah nilai `vpc-private-subnets` untuk memenuhi kebutuhan Anda. Anda juga dapat menambahkan tambahan IDs. Anda harus menentukan setidaknya dua subnet IDs. Jika Anda lebih suka menentukan subnet publik, Anda dapat mengubah `--vpc-private-subnets` ke`--vpc-public-subnets`. Subnet publik memiliki tabel rute terkait dengan rute ke gateway internet, tetapi subnet pribadi tidak memiliki tabel rute terkait. Sebaiknya gunakan subnet pribadi bila memungkinkan.
Subnet yang Anda pilih harus memenuhi persyaratan [subnet Amazon EKS](network-reqs.md#network-requirements-subnets). Sebelum memilih subnet, sebaiknya Anda terbiasa dengan semua persyaratan dan pertimbangan [VPC Amazon EKS dan subnet](network-reqs.md).
1. Jalankan perintah berikut:
```
eksctl create cluster --name my-cluster --region region-code --version 1.35 --vpc-private-subnets subnet-ExampleID1,subnet-ExampleID2 --without-nodegroup
```
Penyediaan klaster memerlukan waktu beberapa menit. Saat cluster sedang dibuat, beberapa baris output muncul. Baris terakhir output mirip dengan baris contoh berikut.
```
[✓] EKS cluster "my-cluster" in "region-code" region is ready
```
1. Lanjutkan dengan [Langkah 3: Perbarui kubeconfig](#step3)
#### Pengaturan Opsional
Untuk melihat sebagian besar opsi yang dapat Anda tentukan saat membuat cluster`eksctl`, gunakan `eksctl create cluster --help` perintah. Untuk melihat semua opsi yang tersedia, Anda dapat menggunakan `config` file. Untuk informasi selengkapnya, lihat [Menggunakan file config](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) dan [skema file config](https://eksctl.io/usage/schema/) di dokumentasi `eksctl`. Anda dapat menemukan [contoh file konfigurasi](https://github.com/weaveworks/eksctl/tree/master/examples) di GitHub.
Berikut ini adalah pengaturan opsional yang, jika diperlukan, harus ditambahkan ke perintah sebelumnya. Anda hanya dapat mengaktifkan opsi ini saat membuat cluster, bukan setelahnya. Jika Anda perlu menentukan opsi ini, Anda harus membuat cluster dengan [file konfigurasi eksctl](https://eksctl.io/usage/creating-and-managing-clusters/#using-config-files) dan menentukan pengaturan, daripada menggunakan perintah sebelumnya.
+ Jika Anda ingin menentukan satu atau beberapa grup keamanan yang ditetapkan Amazon EKS ke antarmuka jaringan yang dibuatnya, tentukan opsi [SecurityGroup](https://eksctl.io/usage/schema/#vpc-securityGroup).
Apakah Anda memilih grup keamanan atau tidak, Amazon EKS membuat grup keamanan yang memungkinkan komunikasi antara cluster dan VPC Anda. Amazon EKS mengaitkan grup keamanan ini, dan apa pun yang Anda pilih, ke antarmuka jaringan yang dibuatnya. Untuk informasi selengkapnya tentang grup keamanan klaster yang dibuat Amazon EKS, lihat[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Anda dapat mengubah aturan di grup keamanan klaster yang dibuat Amazon EKS.
+ [Jika Anda ingin menentukan blok `IPv4` Classless Inter-domain Routing (CIDR) mana Kubernetes memberikan alamat IP layanan, tentukan opsi CIDR layanan. IPv4](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-serviceIPv4CIDR)
Menentukan jangkauan Anda sendiri dapat membantu mencegah konflik antara layanan Kubernetes dan jaringan lain yang di-peer atau terhubung ke VPC Anda. Masukkan rentang dalam notasi CIDR. Sebagai contoh: `10.2.0.0/16`.
Blok CIDR harus memenuhi persyaratan berikut:
+ Berada dalam salah satu rentang berikut:`10.0.0.0/8`,`172.16.0.0/12`, atau`192.168.0.0/16`.
+ Memiliki ukuran minimum `/24` dan ukuran maksimum`/12`.
+ Tidak tumpang tindih dengan kisaran VPC untuk sumber daya Amazon EKS Anda.
Anda hanya dapat menentukan opsi ini saat menggunakan keluarga `IPv4` alamat dan hanya pada pembuatan cluster. Jika Anda tidak menentukan ini, maka Kubernetes memberikan alamat IP layanan dari blok atau CIDR. `10.100.0.0/16` `172.20.0.0/16`
+ Jika Anda membuat klaster dan ingin klaster menetapkan `IPv6` alamat ke Pod dan layanan, bukan `IPv4` alamat, tentukan opsi [IPFamily](https://eksctl.io/usage/schema/#kubernetesNetworkConfig-ipFamily).
Kubernetes memberikan `IPv4` alamat ke Pod dan layanan, secara default. Sebelum memutuskan untuk menggunakan `IPv6` keluarga, pastikan bahwa Anda sudah terbiasa dengan semua pertimbangan dan persyaratan dalam[Persyaratan dan pertimbangan VPC](network-reqs.md#network-requirements-vpc), [Persyaratan dan pertimbangan subnet](network-reqs.md#network-requirements-subnets)[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md), dan [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) topik. Jika Anda memilih `IPv6` keluarga, Anda tidak dapat menentukan rentang alamat untuk Kubernetes untuk menetapkan alamat `IPv6` layanan seperti yang Anda bisa untuk keluarga. `IPv4` Kubernetes memberikan alamat layanan dari rentang alamat lokal yang unik (). `fc00::/7`
### Buat cluster - AWS konsol
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih **Add cluster** dan kemudian pilih **Create**.
1. Di bawah **Opsi konfigurasi** pilih **Konfigurasi khusus**
+ Untuk informasi tentang membuat cluster dengan cepat dengan Mode Otomatis EKS, lihat[Buat Kluster Mode Otomatis EKS dengan Konsol Manajemen AWS](automode-get-started-console.md).
1. Di bawah **Mode Otomatis EKS**, matikan **Gunakan Mode Otomatis EKS**.
+ Untuk informasi tentang membuat kluster Mode Otomatis EKS dengan konfigurasi khusus, lihat[Buat kluster Mode Otomatis Amazon EKS](create-cluster-auto.md).
1. Pada halaman **Configure cluster**, masukkan bidang-bidang berikut:
+ **Nama** — Nama untuk klaster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil), tanda hubung, dan garis bawah. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ Peran **IAM Cluster — Pilih peran** IAM klaster Amazon EKS yang Anda buat untuk memungkinkan bidang kontrol Kubernetes mengelola AWS sumber daya atas nama Anda.
+ **Versi Kubernetes** — Versi Kubernetes untuk digunakan untuk klaster Anda. Sebaiknya pilih versi terbaru, kecuali jika Anda memerlukan versi sebelumnya.
+ **Jenis Support** - Kebijakan versi Kubernetes yang ingin Anda tetapkan untuk klaster Anda. Jika Anda ingin klaster Anda hanya berjalan pada versi dukungan standar, Anda dapat memilih **Dukungan standar**. Jika Anda ingin klaster Anda memasukkan dukungan yang diperluas di akhir dukungan standar untuk sebuah versi, Anda dapat memilih **Dukungan diperpanjang**. Jika Anda memilih versi Kubernetes yang saat ini dalam dukungan diperpanjang, Anda tidak dapat memilih dukungan standar sebagai opsi.
+ **Enkripsi rahasia** — (Opsional) Pilih untuk mengaktifkan enkripsi rahasia rahasia Kubernetes menggunakan kunci KMS. Anda juga dapat mengaktifkan ini setelah Anda membuat cluster Anda. Sebelum Anda mengaktifkan kemampuan ini, pastikan Anda sudah terbiasa dengan informasi di dalamnya[Enkripsi rahasia Kubernetes dengan KMS di cluster yang ada](enable-kms.md).
+ **Tanda** — (Opsional) Tambahkan tanda apapun ke klaster Anda. Untuk informasi selengkapnya, lihat [Mengatur sumber daya Amazon EKS dengan tag](eks-using-tags.md).
+ **ARC Zonal shift** - (Opsional) Anda dapat menggunakan pengontrol Pemulihan Aplikasi Route53 untuk mengurangi zona ketersediaan yang terganggu. Untuk informasi selengkapnya, lihat [Pelajari tentang pergeseran zona Amazon Application Recovery Controller (ARC) di Amazon EKS](zone-shift.md).
1. Di bagian **akses Cluster** pada halaman cluster konfigurasi, masukkan bidang berikut:
+ **Akses administrator klaster Bootstrap** - Pembuat klaster secara otomatis adalah administrator Kubernetes. Jika Anda ingin menonaktifkan ini, pilih **Larang akses administrator klaster**.
+ **Mode otentikasi klaster** — Tentukan cara Anda ingin memberikan akses kepada pengguna dan peran IAM ke Kubernetes. APIs Untuk informasi selengkapnya, lihat [Mengatur Mode Autentikasi Klaster](grant-k8s-access.md#set-cam).
Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Tentukan jaringan**, pilih nilai untuk kolom berikut:
+ **VPC** — Pilih VPC yang sudah ada yang memenuhi [persyaratan Amazon EKS VPC](network-reqs.md#network-requirements-vpc) untuk membuat klaster Anda. Sebelum memilih VPC, kami sarankan Anda memahami semua persyaratan dan pertimbangan di dalamnya. [Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet](network-reqs.md) Anda tidak dapat mengubah VPC mana yang ingin Anda gunakan setelah pembuatan cluster. Jika tidak VPCs terdaftar, maka Anda harus membuatnya terlebih dahulu. Untuk informasi selengkapnya, lihat [Buat VPC Amazon untuk kluster Amazon EKS Anda](creating-a-vpc.md).
+ **Subnet** — Secara default, semua subnet yang tersedia di VPC yang ditentukan di bidang sebelumnya telah dipilih sebelumnya. Anda harus memilih setidaknya dua.
Subnet yang Anda pilih harus memenuhi persyaratan [subnet Amazon EKS](network-reqs.md#network-requirements-subnets). Sebelum memilih subnet, sebaiknya Anda terbiasa dengan semua persyaratan dan pertimbangan [VPC Amazon EKS dan subnet](network-reqs.md).
**Grup keamanan** — (Opsional) Tentukan satu atau beberapa grup keamanan yang ingin Anda kaitkan Amazon EKS ke antarmuka jaringan yang dibuatnya.
Apakah Anda memilih grup keamanan atau tidak, Amazon EKS membuat grup keamanan yang memungkinkan komunikasi antara cluster dan VPC Anda. Amazon EKS mengaitkan grup keamanan ini, dan apa pun yang Anda pilih, ke antarmuka jaringan yang dibuatnya. Untuk informasi selengkapnya tentang grup keamanan klaster yang dibuat Amazon EKS, lihat[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Anda dapat mengubah aturan di grup keamanan klaster yang dibuat Amazon EKS.
+ **Pilih keluarga alamat IP cluster** — Anda dapat memilih salah satu **IPv4**dan **IPv6**.
Kubernetes memberikan `IPv4` alamat ke Pod dan layanan, secara default. Sebelum memutuskan untuk menggunakan `IPv6` keluarga, pastikan Anda sudah terbiasa dengan semua pertimbangan dan persyaratan dalam persyaratan dan pertimbangan [VPC[Persyaratan dan pertimbangan subnet](network-reqs.md#network-requirements-subnets),[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md), dan](network-reqs.md#network-requirements-vpc) topik. [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) Jika Anda memilih `IPv6` keluarga, Anda tidak dapat menentukan rentang alamat untuk Kubernetes untuk menetapkan alamat `IPv6` layanan seperti yang Anda bisa untuk keluarga. `IPv4` Kubernetes memberikan alamat layanan dari rentang alamat lokal yang unik (). `fc00::/7`
+ **(Opsional) Pilih **Konfigurasi rentang alamat IP Layanan Kubernetes dan tentukan rentang** Layanan. `IPv4`**
Menentukan jangkauan Anda sendiri dapat membantu mencegah konflik antara layanan Kubernetes dan jaringan lain yang di-peer atau terhubung ke VPC Anda. Masukkan rentang dalam notasi CIDR. Sebagai contoh: `10.2.0.0/16`.
Blok CIDR harus memenuhi persyaratan berikut:
+ Berada dalam salah satu rentang berikut:`10.0.0.0/8`,`172.16.0.0/12`, atau`192.168.0.0/16`.
+ Memiliki ukuran minimum `/24` dan ukuran maksimum`/12`.
+ Tidak tumpang tindih dengan kisaran VPC untuk sumber daya Amazon EKS Anda.
Anda hanya dapat menentukan opsi ini saat menggunakan keluarga `IPv4` alamat dan hanya pada pembuatan cluster. Jika Anda tidak menentukan ini, maka Kubernetes memberikan alamat IP layanan dari blok atau CIDR. `10.100.0.0/16` `172.20.0.0/16`
+ Untuk **akses endpoint Cluster**, pilih opsi. Setelah cluster Anda dibuat, Anda dapat mengubah opsi ini. Sebelum memilih opsi non-default, pastikan untuk membiasakan diri dengan opsi dan implikasinya. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. (Opsional) Pada halaman **Konfigurasi observabilitas**, pilih opsi **pencatatan bidang **Metrik** dan Kontrol** mana yang akan diaktifkan. Secara default, setiap jenis log dimatikan.
+ Untuk informasi selengkapnya tentang opsi metrik Prometheus, lihat. [Langkah 1: Aktifkan metrik Prometheus](prometheus.md#turn-on-prometheus-metrics)
+ Untuk informasi selengkapnya tentang opsi **Pencatatan bidang kontrol**, lihat[Kirim log pesawat kontrol ke CloudWatch Log](control-plane-logs.md).
Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Pilih add-on**, pilih add-on yang ingin Anda tambahkan ke cluster Anda. Add-on tertentu telah dipilih sebelumnya. Anda dapat memilih add-on **Amazon EKS dan add-on AWS ** **Marketplace** sebanyak yang Anda butuhkan. Jika **add-on AWS Marketplace** yang ingin Anda instal tidak terdaftar, Anda dapat mengklik penomoran halaman untuk melihat hasil halaman tambahan atau mencari **add-on AWS Marketplace** yang tersedia dengan memasukkan teks di kotak pencarian. Anda juga dapat memfilter berdasarkan **kategori**, **vendor**, atau **model harga** dan kemudian memilih add-on dari hasil pencarian. Saat membuat cluster, Anda dapat melihat, memilih, dan menginstal add-on apa pun yang mendukung EKS Pod Identities seperti yang dijelaskan di dalamnya. [Pelajari cara EKS Pod Identity memberikan akses Pod ke layanan AWS](pod-identities.md)
Setelah selesai dengan halaman ini, pilih **Berikutnya**.
Beberapa add-on, seperti Amazon VPC CNI, CoreDNS, dan kube-proxy, diinstal secara default. Jika Anda menonaktifkan salah satu add-on default, ini dapat memengaruhi kemampuan Anda untuk menjalankan aplikasi Kubernetes.
1. Pada halaman **Konfigurasi pengaturan add-on yang dipilih**, pilih versi yang ingin Anda instal. Anda selalu dapat memperbarui ke versi yang lebih baru setelah pembuatan cluster.
Untuk add-on yang mendukung Identitas Pod EKS, Anda dapat menggunakan konsol untuk membuat peran secara otomatis dengan nama, kebijakan AWS terkelola, dan kebijakan kepercayaan yang telah diisi sebelumnya secara khusus untuk add-on. Anda dapat menggunakan kembali peran yang ada atau membuat peran baru untuk add-on yang didukung. Untuk langkah-langkah menggunakan konsol untuk membuat peran untuk add-on yang mendukung EKS Pod Identities, lihat. [Buat add-on (AWS Konsol)](creating-an-add-on.md#create_add_on_console) Jika add-on tidak mendukung EKS Pod Identity, pesan akan ditampilkan dengan instruksi untuk menggunakan wizard untuk membuat peran IAM untuk akun layanan (IRSA) setelah cluster dibuat.
Anda dapat memperbarui konfigurasi setiap add-on setelah pembuatan cluster. Untuk informasi selengkapnya tentang mengonfigurasi add-on, lihat. [Perbarui add-on Amazon EKS](updating-an-add-on.md) Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Tinjau dan buat**, tinjau informasi yang Anda masukkan atau pilih pada halaman sebelumnya. Jika Anda perlu melakukan perubahan, pilih **Edit**. Saat Anda puas, pilih **Buat**. Bidang **Status** menunjukkan **CREATING** saat cluster disediakan.
**catatan**
Anda mungkin menerima kesalahan bahwa salah satu Availability Zone dalam permintaan Anda tidak memiliki kapasitas yang cukup untuk membuat klaster Amazon EKS. Jika hal ini terjadi, output galat berisi Availability Zones yang dapat mendukung klaster baru. Cobalah untuk kembali membuat klaster dengan setidaknya dua subnet yang terletak di Availability Zones yang didukung untuk akun Anda. Untuk informasi selengkapnya, lihat [Kapasitas tidak mencukupi](troubleshooting.md#ice).
Penyediaan klaster memerlukan waktu beberapa menit.
1. Lanjutkan dengan [Langkah 3: Perbarui kubeconfig](#step3)
### Buat cluster - AWS CLI
1. Buat cluster Anda dengan perintah berikut. Sebelum menjalankan perintah, buat penggantian berikut:
+ Ganti *region-code* dengan AWS Region tempat Anda ingin membuat cluster Anda.
+ Ganti *my-cluster* dengan nama untuk cluster Anda. Nama hanya dapat berisi karakter alfanumerik (peka huruf besar/kecil), tanda hubung, dan garis bawah. Itu harus dimulai dengan karakter alfanumerik dan tidak boleh lebih dari 100 karakter. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ Ganti *1.35* dengan [versi yang didukung Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
+ Ganti *111122223333* dengan ID akun Anda dan *myAmazonEKSClusterRole* dengan nama peran IAM cluster Anda.
+ Ganti nilainya `subnetIds` dengan nilai Anda sendiri. Anda juga dapat menambahkan tambahan IDs. Anda harus menentukan setidaknya dua subnet IDs.
Subnet yang Anda pilih harus memenuhi persyaratan [subnet Amazon EKS](network-reqs.md#network-requirements-subnets). Sebelum memilih subnet, sebaiknya Anda terbiasa dengan semua persyaratan dan pertimbangan [VPC Amazon EKS dan subnet](network-reqs.md).
+ Jika Anda tidak ingin menentukan ID grup keamanan, hapus `,securityGroupIds=sg-` dari perintah. Jika Anda ingin menentukan satu atau beberapa grup keamanan IDs, ganti nilainya `securityGroupIds` dengan milik Anda sendiri. Anda juga dapat menambahkan tambahan IDs.
Apakah Anda memilih grup keamanan atau tidak, Amazon EKS membuat grup keamanan yang memungkinkan komunikasi antara cluster dan VPC Anda. Amazon EKS mengaitkan grup keamanan ini, dan apa pun yang Anda pilih, ke antarmuka jaringan yang dibuatnya. Untuk informasi selengkapnya tentang grup keamanan klaster yang dibuat Amazon EKS, lihat[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md). Anda dapat mengubah aturan di grup keamanan klaster yang dibuat Amazon EKS.
```
aws eks create-cluster --region region-code --name my-cluster --kubernetes-version 1.35 \
--role-arn arn:aws: iam::111122223333:role/myAmazonEKSClusterRole \
--resources-vpc-config subnetIds=subnet-ExampleID1,subnet-ExampleID2,securityGroupIds=sg-ExampleID1
```
**catatan**
Anda mungkin menerima kesalahan bahwa salah satu Availability Zone dalam permintaan Anda tidak memiliki kapasitas yang cukup untuk membuat klaster Amazon EKS. Jika hal ini terjadi, output galat berisi Availability Zones yang dapat mendukung klaster baru. Cobalah untuk kembali membuat klaster dengan setidaknya dua subnet yang terletak di Availability Zones yang didukung untuk akun Anda. Untuk informasi selengkapnya, lihat [Kapasitas tidak mencukupi](troubleshooting.md#ice).
Berikut ini adalah pengaturan opsional yang, jika diperlukan, harus ditambahkan ke perintah sebelumnya. Anda hanya dapat mengaktifkan opsi ini saat membuat cluster, bukan setelahnya.
+ Secara default, EKS menginstal beberapa add-on jaringan selama pembuatan klaster. Ini termasuk Amazon VPC CNI, CoreDNS, dan kube-proxy.
Jika Anda ingin menonaktifkan penginstalan add-on jaringan default ini, gunakan parameter di bawah ini. Ini dapat digunakan untuk alternatif CNIs, seperti Cilium. Tinjau [referensi EKS API](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html) untuk informasi lebih lanjut.
`aws eks create-cluster --no-bootstrap-self-managed-addons …`
+ Jika Anda ingin menentukan dari mana `IPv4` Classless Inter-domain Routing (CIDR) blok Kubernetes memberikan alamat IP layanan, Anda harus menentukannya dengan menambahkan ke perintah berikut. `--kubernetes-network-config serviceIpv4Cidr=`
Menentukan jangkauan Anda sendiri dapat membantu mencegah konflik antara layanan Kubernetes dan jaringan lain yang di-peer atau terhubung ke VPC Anda. Masukkan rentang dalam notasi CIDR. Sebagai contoh: `10.2.0.0/16`.
Blok CIDR harus memenuhi persyaratan berikut:
+ Berada dalam salah satu rentang berikut:`10.0.0.0/8`,`172.16.0.0/12`, atau`192.168.0.0/16`.
+ Memiliki ukuran minimum `/24` dan ukuran maksimum`/12`.
+ Tidak tumpang tindih dengan kisaran VPC untuk sumber daya Amazon EKS Anda.
Anda hanya dapat menentukan opsi ini saat menggunakan keluarga `IPv4` alamat dan hanya pada pembuatan cluster. Jika Anda tidak menentukan ini, maka Kubernetes memberikan alamat IP layanan dari blok atau CIDR. `10.100.0.0/16` `172.20.0.0/16`
+ Jika Anda membuat klaster dan ingin klaster menetapkan `IPv6` alamat ke Pod dan layanan, bukan `IPv4` alamat, tambahkan `--kubernetes-network-config ipFamily=ipv6` ke perintah berikut.
Kubernetes memberikan `IPv4` alamat ke Pod dan layanan, secara default. Sebelum memutuskan untuk menggunakan `IPv6` keluarga, pastikan Anda sudah terbiasa dengan semua pertimbangan dan persyaratan dalam persyaratan dan pertimbangan [VPC[Persyaratan dan pertimbangan subnet](network-reqs.md#network-requirements-subnets),[Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md), dan](network-reqs.md#network-requirements-vpc) topik. [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) Jika Anda memilih `IPv6` keluarga, Anda tidak dapat menentukan rentang alamat untuk Kubernetes untuk menetapkan alamat `IPv6` layanan seperti yang Anda bisa untuk keluarga. `IPv4` Kubernetes memberikan alamat layanan dari rentang alamat lokal yang unik (). `fc00::/7`
1. Dibutuhkan beberapa menit untuk menyediakan cluster. Anda dapat melakukan kueri status klaster Anda dengan perintah berikut.
```
aws eks describe-cluster --region region-code --name my-cluster --query "cluster.status"
```
Jangan lanjutkan ke langkah berikutnya sampai output yang dikembalikan`ACTIVE`.
1. Lanjutkan dengan [Langkah 3: Perbarui kubeconfig](#step3)
## Langkah 3: Perbarui kubeconfig
1. Jika Anda membuat cluster Anda menggunakan`eksctl`, maka Anda dapat melewati langkah ini. Ini karena `eksctl` sudah menyelesaikan langkah ini untuk Anda. Aktifkan `kubectl` untuk berkomunikasi dengan cluster Anda dengan menambahkan konteks baru ke `kubectl` `config` file. Untuk informasi selengkapnya tentang cara membuat dan memperbarui file, lihat[Connect kubectl ke kluster EKS dengan membuat file kubeconfig](create-kubeconfig.md).
```
aws eks update-kubeconfig --region region-code --name my-cluster
```
Contoh output adalah sebagai berikut.
```
Added new context arn:aws: eks:region-code:111122223333:cluster/my-cluster to /home/username/.kube/config
```
1. Konfirmasikan komunikasi dengan cluster Anda dengan menjalankan perintah berikut.
```
kubectl get svc
```
Contoh output adalah sebagai berikut.
```
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.100.0.1 443/TCP 28h
```
## Langkah 4: Pengaturan cluster
1. (Disarankan) Untuk menggunakan beberapa add-on Amazon EKS, atau untuk mengaktifkan beban kerja Kubernetes individual agar memiliki izin AWS Identity and Access Management (IAM) tertentu, [buat penyedia IAM OpenID Connect (OIDC](enable-iam-roles-for-service-accounts.md)) untuk klaster Anda. Anda hanya perlu membuat penyedia IAM OIDC untuk cluster Anda sekali. Untuk mempelajari selengkapnya tentang add-on Amazon EKS, lihat [Add-on Amazon EKS](eks-add-ons.md). Untuk mempelajari selengkapnya tentang penugasa izin IAM tertentu untuk beban kerja Anda, lihat [IAM role untuk akun layanan](iam-roles-for-service-accounts.md).
1. (Disarankan) Konfigurasikan klaster Anda untuk plugin Amazon VPC CNI untuk plugin Kubernetes sebelum menerapkan node Amazon EC2 ke cluster Anda. Secara default, plugin diinstal dengan cluster Anda. Saat Anda menambahkan node Amazon EC2 ke cluster Anda, plugin secara otomatis diterapkan ke setiap node Amazon EC2 yang Anda tambahkan. Plugin mengharuskan Anda untuk melampirkan salah satu kebijakan IAM berikut ke peran IAM. Jika klaster Anda menggunakan `IPv4` keluarga, gunakan kebijakan IAM terkelola [Amazoneks\$1CNI\$1Policy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKS_CNI_Policy.html). Jika klaster Anda menggunakan `IPv6` keluarga, gunakan [kebijakan IAM yang Anda buat](cni-iam-role.md#cni-iam-role-create-ipv6-policy).
Peran IAM yang Anda lampirkan kebijakan dapat menjadi peran IAM node, atau peran khusus yang hanya digunakan untuk plugin. Kami merekomendasikan untuk melampirkan kebijakan untuk peran ini. Untuk informasi selengkapnya tentang membuat peran, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md) atau [Amazon EKS node IAM role](create-node-role.md).
1. Jika Anda menerapkan cluster Anda menggunakan Konsol Manajemen AWS, Anda dapat melewati langkah ini. Aplikasi ini Konsol Manajemen AWS menerapkan plugin Amazon VPC CNI untuk add-on Kubernetes, CoreDNS, dan Amazon EKS, secara default. `kube-proxy`
Jika Anda menerapkan klaster menggunakan salah satu `eksctl` atau AWS CLI, maka plugin Amazon VPC CNI untuk Kubernetes, CoreDNS, dan add-on yang dikelola sendiri akan di-deploy. `kube-proxy` Anda dapat memigrasikan plugin Amazon VPC CNI untuk Kubernetes, CoreDNS, dan add-on yang `kube-proxy` dikelola sendiri yang di-deploy dengan klaster Anda ke add-on Amazon EKS. Untuk informasi selengkapnya, lihat [Add-on Amazon EKS](eks-add-ons.md).
1. (Opsional) Jika Anda belum melakukannya, Anda dapat mengaktifkan metrik Prometheus untuk klaster Anda. Untuk informasi selengkapnya, lihat [Membuat scraper](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-create) di *Amazon Managed Service for Prometheus* User Guide.
1. Jika Anda berencana untuk menerapkan beban kerja ke klaster yang menggunakan volume Amazon EBS, Anda harus menginstal [Amazon EBS CSI](ebs-csi.md) ke klaster sebelum menerapkan beban kerja.
## Langkah selanjutnya
+ [Prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang menciptakan cluster adalah satu-satunya prinsipal yang memiliki akses ke cluster. [Berikan izin kepada prinsipal IAM lainnya sehingga mereka dapat mengakses klaster](grant-k8s-access.md) Anda.
+ Jika prinsipal IAM yang membuat klaster hanya memiliki izin IAM minimum yang direferensikan dalam prasyarat, maka Anda mungkin ingin menambahkan izin Amazon EKS tambahan untuk prinsipal tersebut. Untuk informasi selengkapnya tentang pemberian izin Amazon EKS kepada prinsipal IAM, lihat. [Identity and access management untuk Amazon EKS](security-iam.md)
+ [Jika Anda ingin prinsipal IAM yang membuat klaster, atau prinsipal lainnya untuk melihat sumber daya Kubernetes di konsol Amazon EKS, berikan izin yang Diperlukan ke entitas.](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
+ Jika Anda ingin node dan prinsipal IAM mengakses cluster Anda dari dalam VPC Anda, aktifkan titik akhir pribadi untuk cluster Anda. Titik akhir publik diaktifkan secara default. Anda dapat menonaktifkan titik akhir publik setelah Anda mengaktifkan titik akhir pribadi, jika diinginkan. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
+ [Aktifkan enkripsi rahasia untuk cluster Anda](enable-kms.md).
+ [Konfigurasikan logging untuk klaster Anda](control-plane-logs.md).
+ [Tambahkan node ke cluster Anda](eks-compute.md).
# Pesawat Kontrol yang Disediakan Amazon EKS
## Ikhtisar
Amazon EKS Provisioned Control Plane adalah fitur yang memungkinkan administrator klaster memilih dari serangkaian tingkatan penskalaan dan menetapkan tingkat pilihan mereka untuk kinerja yang sangat tinggi dan dapat diprediksi dari bidang kontrol cluster. Hal ini memungkinkan administrator cluster untuk memastikan bahwa bidang kontrol selalu disediakan dengan kapasitas yang ditentukan.
Amazon EKS menawarkan dua mode operasi untuk bidang kontrol cluster Anda. Secara default, klaster Amazon EKS menggunakan **mode Standar**, di mana bidang kontrol secara otomatis menskalakan naik dan turun berdasarkan tuntutan beban kerja Anda. Mode standar secara dinamis mengalokasikan kapasitas bidang kontrol yang memadai untuk memenuhi kebutuhan beban kerja Anda dan merupakan solusi yang direkomendasikan untuk sebagian besar kasus penggunaan. **Namun, untuk beban kerja khusus yang tidak dapat mentolerir variabilitas kinerja apa pun karena penskalaan bidang kontrol atau yang membutuhkan kapasitas bidang kontrol dalam jumlah sangat tinggi, Anda dapat menggunakan mode Provisioned secara opsional.** Mode yang disediakan memungkinkan Anda mengalokasikan kapasitas bidang kontrol terlebih dahulu yang selalu siap menangani persyaratan beban kerja yang menuntut.
**catatan**
Mode yang disediakan adalah mode operasi bidang kontrol tambahan di samping mode Standar default. Pengenalan mode Provisioned tidak mengubah perilaku mode Standar.
Dengan EKS Provisioned Control Plane, administrator cluster dapat melakukan pra-penyediaan kapasitas bidang kontrol yang diinginkan sebelumnya, memberikan kinerja yang dapat diprediksi dan tinggi dari bidang kontrol cluster yang selalu tersedia. EKS Provisioned Control Plane juga memungkinkan administrator cluster untuk menyediakan kapasitas pesawat kontrol yang sama di seluruh lingkungan, mulai dari pementasan hingga lokasi produksi dan pemulihan bencana. Hal ini penting untuk memastikan bahwa kinerja bidang kontrol yang diperoleh di seluruh lingkungan konsisten dan dapat diprediksi. Terakhir, EKS Provisioned Control Plane memberi Anda akses ke tingkat kinerja bidang kontrol yang sangat tinggi, memungkinkan menjalankan beban kerja AI yang dapat diskalakan secara besar-besaran, komputasi berkinerja tinggi, dan beban kerja pemrosesan data skala besar di Kubernetes.
Semua cluster Amazon EKS yang ada dan baru beroperasi dalam mode Standar secara default. Untuk cluster yang membutuhkan kinerja tinggi dan dapat diprediksi dari bidang kontrol, Anda dapat memilih untuk menggunakan fitur EKS Provisioned Control Plane. Anda akan ditagih dengan tarif per jam untuk tingkat penskalaan pesawat kontrol tertentu selain biaya per jam EKS dukungan standar atau diperpanjang. Untuk informasi selengkapnya tentang harga, lihat [harga Amazon EKS](https://aws.amazon.com/eks/pricing/).
![\[Mode Pesawat Kontrol Amazon EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/control-plane-modes.png)
## Kasus penggunaan
EKS Provisioned Control Plane dirancang untuk mengatasi skenario tertentu di mana kinerja bidang kontrol yang tinggi dan dapat diprediksi sangat penting untuk operasi Anda. Memahami kasus penggunaan ini dapat membantu Anda menentukan apakah EKS Provisioned Control Plane adalah solusi yang tepat untuk beban kerja Anda.
**Beban kerja kritis kinerja — Untuk beban kerja** yang menuntut latensi minimal dan kinerja maksimum dari bidang kontrol Kubernetes, EKS Provisioned Control Plane menyediakan kapasitas yang menghilangkan variabilitas kinerja dengan penskalaan bidang kontrol.
**Beban kerja yang dapat diskalakan secara besar-besaran** — Jika Anda menjalankan beban kerja yang sangat skalabel seperti pelatihan dan inferensi AI, komputasi berkinerja tinggi, atau pemrosesan data skala besar yang memerlukan sejumlah besar node yang berjalan di cluster, Provisioned Control Plane menyediakan kapasitas bidang kontrol yang diperlukan untuk mendukung beban kerja yang menuntut ini.
**Peristiwa permintaan tinggi yang diantisipasi** — Ketika Anda mengharapkan lonjakan permintaan pesawat kontrol tiba-tiba karena acara mendatang seperti penjualan atau promosi e-commerce, peluncuran produk, musim belanja liburan, atau acara olahraga atau hiburan besar, Provisioned Control Plane memungkinkan Anda untuk meningkatkan kapasitas pesawat kontrol Anda terlebih dahulu. Pendekatan proaktif ini memastikan pesawat kontrol Anda siap menangani peningkatan beban tanpa menunggu penskalaan otomatis untuk menanggapi permintaan.
**Konsistensi lingkungan** — Provisioned Control Plane memungkinkan Anda untuk mencocokkan kapasitas dan kinerja bidang kontrol di seluruh lingkungan pementasan dan produksi, membantu Anda mengidentifikasi potensi masalah lebih awal sebelum penerapan ke produksi. Dengan mempertahankan tingkat bidang kontrol yang sama di seluruh lingkungan, Anda dapat memastikan bahwa hasil pengujian secara akurat mencerminkan perilaku produksi, mengurangi risiko kejutan terkait kinerja selama peluncuran.
**Pemulihan bencana dan kelangsungan bisnis** - Untuk skenario pemulihan bencana, Provisioned Control Plane memungkinkan Anda menyediakan lingkungan failover dengan tingkat kapasitas yang sama dengan lingkungan utama Anda. Ini memastikan gangguan minimal dan pemulihan cepat selama peristiwa failover, karena cluster pemulihan bencana Anda akan memiliki karakteristik kinerja bidang kontrol yang identik dengan cluster produksi Anda sejak saat diaktifkan.
## Kontrol Tingkat Penskalaan Pesawat
EKS Provisioned Control Plane menawarkan tingkatan penskalaan yang diberi nama menggunakan ukuran t-shirt (XL, 2XL, 4XL, dan 8XL). Setiap tingkatan mendefinisikan kapasitasnya melalui tiga atribut utama Kubernetes yang menentukan karakteristik kinerja bidang kontrol cluster Anda. Memahami atribut ini membantu Anda memilih tingkat yang sesuai untuk persyaratan beban kerja Anda.
**Konkurensi permintaan API** mengukur jumlah permintaan yang dapat diproses oleh server API pesawat kontrol Kubernetes secara bersamaan, yang sangat penting untuk beban kerja throughput yang tinggi.
**Tingkat penjadwalan Pod** menunjukkan seberapa cepat penjadwal Kubernetes default dapat menjadwalkan pod pada node, diukur dalam pod per detik.
**Ukuran database cluster** menunjukkan ruang penyimpanan yang dialokasikan untuk etcd, database yang menyimpan state/metadata cluster.
Saat Anda menyediakan bidang kontrol klaster Anda pada tingkat penskalaan tertentu menggunakan Provisioned Control Plane, EKS memastikan bidang kontrol klaster Anda mempertahankan batas yang sesuai dengan tingkat tersebut. Batas tingkatan penskalaan bidang kontrol bervariasi menurut versi Kubernetes, seperti yang ditunjukkan pada tabel berikut.
### EKS v1.28 dan v1.29
| Tingkat Penskalaan Pesawat Kontrol yang Diberikan | Konkurensi permintaan API (kursi) | Tingkat penjadwalan pod (pods/detik) | Ukuran basis data cluster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 100 | 16 |
| 2XL | 3400 | 100 | 16 |
| 4XL | 6800 | 100 | 16 |
| 8XL | 13600 | 100 | 16 |
### EKS v1.30 dan yang lebih baru
| Tingkat Penskalaan Pesawat Kontrol yang Diberikan | Konkurensi permintaan API (kursi) | Tingkat penjadwalan pod (pods/detik) | Ukuran basis data cluster (GB) |
| --- | --- | --- | --- |
| XL | 1700 | 167 | 16 |
| 2XL | 3400 | 283 | 16 |
| 4XL | 6800 | 400 | 16 |
| 8XL | 13600 | 400 | 16 |
### Pemantauan pemanfaatan tingkat penskalaan bidang kontrol
Amazon EKS menyediakan beberapa metrik untuk membantu Anda memantau pemanfaatan tingkat pesawat kontrol Anda. Metrik ini diterbitkan sebagai [ CloudWatch metrik Amazon](cloudwatch.md) dan dapat diakses melalui konsol CloudWatch dan EKS. [Selain itu, metrik ini dapat diambil dari titik akhir Prometheus kluster EKS Anda (lihat di sini).](prometheus.md)
| | **Metrik Prometheus** | **CloudWatch Metrik** |
| --- | --- | --- |
| **Konkurensi permintaan API** | apiserver\$1flowcontrol\$1current\$1executing\$1seats | apiserver\$1flowcontrol\$1current\$1executing\$1seats |
| **Tingkat penjadwalan pod** | scheduler\$1schedule\$1attempts\$1total | scheduler\$1schedule\$1attempts\$1total, Scheduler\$1schedule\$1trial, scheduler\$1schedule\$1attempts\$1unschedulable |
| **Ukuran basis data cluster** | apiserver\$1storage\$1size\$1bytes | apiserver\$1storage\$1size\$1bytes |
Anda dapat melihat pemanfaatan bidang kontrol di konsol Amazon EKS. Dari halaman ikhtisar klaster Anda, pilih **Monitor cluster** untuk mengakses dasbor observabilitas, lalu pilih tab **Pemantauan bidang kontrol** untuk melihat pemanfaatan bidang kontrol di bawah bagian **Penskalaan bidang kontrol**.
![\[Pantau kluster EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/monitor-cluster.png)
![\[Pemantauan Pesawat Kontrol EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/control-plane-monitoring.png)
### Memahami kapasitas Tier versus kinerja aktual
Saat Anda memilih tingkat penskalaan Pesawat Kontrol Tertentu, atribut tier mewakili konfigurasi dasar yang diterapkan Amazon EKS pada bidang kontrol Anda. Namun, kinerja aktual yang Anda capai bergantung pada pola beban kerja, konfigurasi, dan kepatuhan spesifik Anda terhadap praktik terbaik Kubernetes. Misalnya, saat tingkat 4XL mengonfigurasi Prioritas dan Keadilan API (APF) dengan 6.800 kursi permintaan bersamaan, throughput permintaan aktual yang Anda peroleh dari bidang kontrol bergantung pada jenis operasi yang dilakukan. [Misalnya, Kubernetes menghukum permintaan daftar lebih dari get, dan karenanya jumlah efektif permintaan daftar yang diproses secara bersamaan oleh control plane lebih rendah daripada permintaan get (lihat di sini).](https://docs.aws.amazon.com/eks/latest/best-practices/scale-control-plane.html#_api_priority_and_fairness) Demikian pula, meskipun QPS penjadwal default diatur ke 400 untuk tingkat 4XL, tingkat penjadwalan pod Anda yang sebenarnya bergantung pada faktor-faktor seperti node yang siap dan sehat untuk penjadwalan. Untuk mencapai kinerja optimal, pastikan aplikasi Anda mengikuti praktik terbaik Kubernetes (lihat [di sini](https://docs.aws.amazon.com/eks/latest/best-practices/scalability.html)) dan dikonfigurasi dengan benar untuk karakteristik beban kerja Anda.
## Pertimbangan-pertimbangan
+ **Kapasitas bidang kontrol standar** — Mode bidang kontrol standar EKS menawarkan rasio harga terhadap kinerja terbaik, dan merupakan opsi yang direkomendasikan untuk sebagian besar kasus penggunaan. Namun, untuk beban kerja khusus yang tidak dapat mentolerir variabilitas kinerja apa pun karena penskalaan bidang kontrol atau yang membutuhkan kapasitas bidang kontrol dalam jumlah sangat tinggi, Anda dapat mempertimbangkan untuk menggunakan mode Provisioned.
+ **Diperlukan keikutsertaan** - Cluster yang ada tidak akan secara otomatis meningkatkan skala dari bidang kontrol Standar ke tingkat Pesawat Kontrol Tertentu EKS [dengan harga](https://aws.amazon.com/eks/pricing/) lebih tinggi. Anda harus secara eksplisit memilih salah satu tingkatan penskalaan Pesawat Kontrol yang Disediakan EKS yang baru.
+ **Pembatasan keluar** - Mode bidang kontrol standar mendukung hingga 8 GB ukuran database cluster (etcd). Jika ukuran database cluster Anda melebihi 8 GB saat menggunakan mode Provisioned, Anda tidak dapat beralih kembali ke mode Standar hingga Anda mengurangi ukuran database menjadi di bawah 8 GB. Misalnya, jika Anda menggunakan penyimpanan database 14 GB dalam mode Provisioned, Anda harus terlebih dahulu mengurangi penggunaan database Anda menjadi kurang dari 8GB sebelum kembali ke mode Standar.
+ **Tidak ada penskalaan tingkat otomatis** — EKS Provisioned Control Plane tidak secara otomatis menskalakan antar tingkatan. Setelah Anda memilih tingkat penskalaan, bidang kontrol klaster Anda tetap disematkan ke tingkat tersebut, memastikan kinerja yang konsisten dan dapat diprediksi. Namun, Anda memiliki fleksibilitas untuk menerapkan solusi penskalaan otomatis Anda sendiri dengan memantau metrik pemanfaatan tingkat dan menggunakan EKS Provisioned Control Plane APIs untuk meningkatkan atau menurunkan skala ketika metrik ini melewati ambang batas yang Anda tentukan, memberi Anda kendali penuh atas strategi penskalaan dan pengoptimalan biaya Anda.
+ **Melihat tingkat saat ini** — Anda dapat menggunakan konsol Amazon EKS, Amazon Web Services CLI, atau API untuk melihat tingkat penskalaan bidang kontrol saat ini. Di CLI, Anda dapat menjalankan perintah: `describe-cluster` `aws eks describe-cluster --name cluster-name`
+ **Waktu transisi tingkat** - Anda dapat menggunakan konsol Amazon EKS, Amazon EKS APIs, atau CLI untuk keluar atau berpindah di antara tingkatan penskalaan. Amazon EKS telah memperkenalkan jenis pembaruan cluster baru yang disebut`ScalingTierConfigUpdate`, yang dapat Anda periksa untuk memantau kemajuan transisi. Setelah menjalankan perintah perubahan tingkat, Anda dapat membuat daftar pembaruan di cluster untuk melihat pembaruan tipe baru `ScalingTierConfigUpdate` dengan status`Updating`. Status berubah menjadi `Successful` setelah selesai pembaruan, atau `Failed` jika terjadi kesalahan. Bidang kesalahan dalam pembaruan menunjukkan alasan kegagalan. Tidak ada batasan seberapa sering Anda dapat beralih antar tingkatan. Mengubah tingkat bidang kontrol membutuhkan waktu beberapa menit untuk menyelesaikannya. Tidak ada downtime server API selama proses ini, karena EKS memunculkan server API baru sebelum menghentikan yang lama.
+ **Memilih tier optimal** — Untuk menentukan tingkat penskalaan Provisioned Control Plane yang optimal untuk klaster Anda, Anda dapat melakukan pengujian beban dengan menyediakan klaster Anda pada tingkat tertinggi (8XL). Kemudian lakukan uji beban untuk mensimulasikan permintaan puncak pada bidang kontrol cluster Anda. Amati metrik pemanfaatan tingkat bidang kontrol pada beban puncak, dan gunakan pengamatan ini sebagai faktor penuntun untuk memilih tingkat yang sesuai untuk mode Provisioned.
+ **Harga Provisioned Control Plane** — Anda akan ditagih dengan tarif per jam untuk tingkat penskalaan Provisioned Control Plane yang digunakan klaster Anda. Ini merupakan tambahan dari biaya per jam dukungan standar atau diperpanjang. Lihat [halaman](https://aws.amazon.com/eks/pricing/) Harga Amazon EKS untuk detailnya.
+ **Tingkat penskalaan yang lebih besar** — Jika Anda ingin menjalankan klaster Anda pada tingkat penskalaan yang lebih besar dari 8XL, hubungi tim akun Amazon Web Services Anda untuk informasi harga tambahan.
+ **Dukungan versi dan wilayah Kubernetes** — EKS Provisioned Control Plane didukung di semua wilayah komersial Amazon Web Services, GovCloud dan China. Provisioned Control Plane bekerja pada EKS v1.28 dan yang lebih tinggi.
# Memulai dengan Amazon EKS Provisioned Control Plane
Panduan ini memandu Anda melalui langkah-langkah untuk mengatur dan menggunakan EKS Provisioned Control Plane menggunakan CLI AWS dan. Konsol Manajemen AWS
## Prasyarat
Sebelum Anda mulai, pastikan Anda memiliki:
+ ** AWS CLI** — Alat baris perintah untuk bekerja dengan AWS layanan, termasuk Amazon EKS. Untuk informasi selengkapnya, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Setelah menginstal AWS CLI, kami sarankan Anda juga mengkonfigurasinya. Untuk informasi selengkapnya, lihat [Konfigurasi cepat dengan aws configure](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-quickstart.html#cli-configure-quickstart-config) di *Panduan Pengguna Antarmuka Baris AWS Perintah*. Perhatikan bahwa AWS CLI v2 diperlukan untuk menggunakan opsi **update-kubeconfig** yang ditampilkan di halaman ini.
+ **Izin IAM yang diperlukan** - Prinsip keamanan IAM yang Anda gunakan harus memiliki izin untuk bekerja dengan peran Amazon EKS IAM, peran terkait layanan,, VPC, dan sumber AWS CloudFormation daya terkait. Untuk informasi selengkapnya, lihat [Tindakan](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html) dan [Menggunakan peran terkait layanan](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html) di Panduan Pengguna *IAM*. Anda harus menyelesaikan semua langkah dalam panduan ini sebagai pengguna yang sama. Untuk memeriksa pengguna saat ini, jalankan perintah berikut:
```
aws sts get-caller-identity
```
**catatan**
Kami menyarankan Anda menyelesaikan langkah-langkah dalam topik ini di shell Bash. Jika Anda tidak menggunakan shell Bash, beberapa perintah skrip seperti karakter kelanjutan baris dan cara variabel diatur dan digunakan memerlukan penyesuaian untuk shell Anda. Selain itu, aturan mengutip dan melarikan diri untuk shell Anda mungkin berbeda. Untuk informasi selengkapnya, lihat [Menggunakan tanda kutip dengan string di AWS CLI di](https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-parameters-quoting-strings.html) Panduan Pengguna Antarmuka *Baris AWS Perintah*.
## Pesawat Kontrol yang Disediakan EKS - CLI AWS
### Buat cluster dengan EKS Provisioned Control Plane Scaling Tier
```
aws eks create-cluster --name prod-cluster \
--role-arn arn:aws:iam::012345678910:role/eks-service-role-AWSServiceRoleForAmazonEKS-J7ONKE3BQ4PI \
--resources-vpc-config subnetIds=subnet-6782e71e,subnet-e7e761ac,securityGroupIds=sg-6979fe18 \
--control-plane-scaling-config tier=tier-xl
```
Respons:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "CREATING",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Lihat Tingkat Penskalaan Pesawat Kontrol cluster
```
aws eks describe-cluster --name prod-cluster
```
Respons:
```
{
"cluster": {
"name": "my-eks-cluster",
"arn": "arn:aws:eks:us-east-2:111122223333:cluster/my-eks-cluster",
"createdAt": "2024-03-14T11:31:44.348000-04:00",
"version": "1.26",
"endpoint": "https://JSA79429HJDASKJDJ8223829MNDNASW.yl4.us-east-2.eks.amazonaws.com",
"roleArn": "arn:aws:iam::111122223333:role/eksctl-my-eks-cluster-cluster-ServiceRole-zMF6CBakwwbW",
"resourcesVpcConfig": {
"subnetIds": [
"subnet-0fb75d2d8401716e7",
"subnet-02184492f67a3d0f9",
"subnet-04098063527aab776",
"subnet-0e2907431c9988b72",
"subnet-04ad87f71c6e5ab4d",
"subnet-09d912bb63ef21b9a"
],
"securityGroupIds": [
"sg-0c1327f6270afbb36"
],
"clusterSecurityGroupId": "sg-01c84d09d70f39a7f",
"vpcId": "vpc-0012b8e1cc0abb17d",
"endpointPublicAccess": true,
"endpointPrivateAccess": true,
"publicAccessCidrs": [
"22.19.18.2/32"
]
},
"controlPlaneScalingConfig": {
"tier": "tier-xl"
},
"kubernetesNetworkConfig": {
"serviceIpv4Cidr": "10.100.0.0/16",
"ipFamily": "ipv4"
},
"logging": {
"clusterLogging": [
{
"types": [
"api",
"audit",
"authenticator",
"controllerManager",
"scheduler"
],
"enabled": true
}
]
},
"identity": {
"oidc": {
"issuer": "https://oidc.eks.us-east-2.amazonaws.com/id/JSA79429HJDASKJDJ8223829MNDNASW"
}
},
"status": "ACTIVE",
"certificateAuthority": {
"data": "CA_DATA_STRING..."
},
"platformVersion": "eks.14",
"tags": {
"aws:cloudformation:stack-name": "eksctl-my-eks-cluster-cluster",
"alpha.eksctl.io/cluster-name": "my-eks-cluster",
"karpenter.sh/discovery": "my-eks-cluster",
"aws:cloudformation:stack-id": "arn:aws:cloudformation:us-east-2:111122223333:stack/eksctl-my-eks-cluster-cluster/e752ea00-e217-11ee-beae-0a9599c8c7ed",
"auto-delete": "no",
"eksctl.cluster.k8s.io/v1alpha1/cluster-name": "my-eks-cluster",
"EKS-Cluster-Name": "my-eks-cluster",
"alpha.eksctl.io/cluster-oidc-enabled": "true",
"aws:cloudformation:logical-id": "ControlPlane",
"alpha.eksctl.io/eksctl-version": "0.173.0-dev+a7ee89342.2024-03-01T03:40:57Z",
"Name": "eksctl-my-eks-cluster-cluster/ControlPlane"
},
"health": {
"issues": []
},
"accessConfig": {
"authenticationMode": "API_AND_CONFIG_MAP"
}
}
}
```
### Perbarui cluster untuk menggunakan EKS Provisioned Control Plane
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=tier-2xl
```
Respons:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "tier-2xl"
},
{
"type": "PreviousTier",
"value": "tier-xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
### Lihat pembaruan Penskalaan Pesawat Kontrol
```
aws eks list-updates --name example
```
Respons:
```
{
"updateIds": [
"7551c64b-1d27-4b1e-9f8e-c45f056eb6fd1"
]
}
```
### Keluar dari Pesawat Kontrol yang Disediakan ke Bidang Kontrol Standar
```
aws eks update-cluster-config --name prod-cluster \
--control-plane-scaling-config tier=standard
```
Respons:
```
{
"update": {
"id": "7551c64b-1d27-4b1e-9f8e-c45f056eb6fd",
"status": "InProgress",
"type": "ScalingTierConfigUpdate",
"params": [
{
"type": "UpdatedTier",
"value": "standard"
},
{
"type": "PreviousTier",
"value": "tier-2xl"
}
],
"createdAt": 1565807210.37,
"errors": []
}
}
```
## Pesawat Kontrol yang Disediakan EKS - Konsol Manajemen AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih **Buat klaster**.
1. Di bawah *Opsi konfigurasi*, pilih **Konfigurasi kustom**.
1. Gulir ke bawah ke **tingkat penskalaan bidang Kontrol**. Pilih **Gunakan tingkat penskalaan** untuk mengaktifkan Provisioned Control Plane.
1. Pilih tingkat penskalaan bidang kontrol yang ingin Anda sediakan untuk klaster dari berbagai opsi tingkat penskalaan seperti XL, 2XL, 4XL, dan 8XL.
1. Pilih opsi konfigurasi cluster lainnya sesuai kebutuhan. Pada langkah terakhir pilih **Buat cluster**. Perhatikan bahwa mungkin perlu beberapa menit untuk menyelesaikan pembuatan klaster.
# Bersiaplah untuk upgrade versi Kubernetes dan pecahkan masalah kesalahan konfigurasi dengan wawasan klaster
Wawasan klaster Amazon EKS menyediakan deteksi masalah dan rekomendasi untuk menyelesaikannya guna membantu Anda mengelola klaster. Setiap klaster Amazon EKS menjalani pemeriksaan otomatis dan berulang terhadap daftar wawasan yang dikuratori Amazon EKS. *Pemeriksaan wawasan* ini dikelola sepenuhnya oleh Amazon EKS dan menawarkan rekomendasi tentang cara mengatasi temuan apa pun.
## Jenis wawasan cluster
+ **Wawasan konfigurasi**: Mengidentifikasi kesalahan konfigurasi dalam penyiapan Node Hibrid EKS Anda yang dapat mengganggu fungsionalitas klaster atau beban kerja Anda.
+ **Upgrade insights**: Mengidentifikasi masalah yang dapat memengaruhi kemampuan Anda untuk meningkatkan ke versi baru Kubernetes.
## Pertimbangan
+ **Frekuensi**: Amazon EKS menyegarkan wawasan cluster setiap 24 jam, atau Anda dapat menyegarkannya secara manual untuk melihat status terbaru. Misalnya, Anda dapat menyegarkan wawasan klaster secara manual setelah mengatasi masalah untuk melihat apakah masalah telah teratasi.
+ **Izin**: Amazon EKS secara otomatis membuat entri akses klaster untuk wawasan klaster di setiap kluster EKS. Entri ini memberikan izin EKS untuk melihat informasi tentang cluster Anda. Amazon EKS menggunakan informasi ini untuk menghasilkan wawasan. Untuk informasi selengkapnya, lihat [Amazon EKSCluster InsightsPolicy](access-policy-permissions.md#access-policy-permissions-AmazonEKSClusterInsightsPolicy).
## Kasus penggunaan
Wawasan klaster di Amazon EKS menyediakan pemeriksaan otomatis untuk membantu menjaga kesehatan, keandalan, dan konfigurasi optimal klaster Kubernetes Anda. Di bawah ini adalah kasus penggunaan utama untuk wawasan klaster, termasuk kesiapan pemutakhiran dan pemecahan masalah konfigurasi.
### Tingkatkan wawasan
Wawasan upgrade adalah jenis pemeriksaan wawasan tertentu dalam wawasan klaster. Pemeriksaan ini mengembalikan wawasan yang terkait dengan kesiapan peningkatan versi Kubernetes. Amazon EKS menjalankan pemeriksaan wawasan pemutakhiran pada setiap cluster EKS.
**penting**
Amazon EKS telah mengembalikan sementara fitur yang mengharuskan Anda menggunakan `--force` flag untuk memutakhirkan klaster Anda ketika ada masalah wawasan klaster tertentu. Untuk informasi selengkapnya, lihat [Pengembalian sementara untuk menerapkan wawasan pemutakhiran pada versi klaster pembaruan pada](https://github.com/aws/containers-roadmap/issues/2570). GitHub
Untuk informasi selengkapnya tentang memperbarui klaster Anda, lihat[Langkah 3: Perbarui bidang kontrol cluster](update-cluster.md#update-cluster-control-plane).
[Sebelum memperbarui versi Kubernetes cluster Anda, Anda dapat menggunakan tab **Upgrade insights** dari dasbor observability di konsol Amazon EKS.](https://console.aws.amazon.com/eks/home#/clusters) Jika klaster Anda telah mengidentifikasi masalah, tinjau dan buat perbaikan yang sesuai. Masalahnya termasuk tautan ke Amazon EKS dan dokumentasi Kubernetes. Setelah memperbaiki masalah, segarkan wawasan klaster sesuai permintaan untuk mengambil wawasan terbaru. Jika semua masalah telah diselesaikan, [perbarui klaster Anda](update-cluster.md).
Amazon EKS mengembalikan wawasan yang terkait dengan kesiapan peningkatan versi Kubernetes. Wawasan upgrade mengidentifikasi kemungkinan masalah yang dapat memengaruhi peningkatan klaster Kubernetes. Ini meminimalkan upaya yang dihabiskan administrator untuk mempersiapkan peningkatan dan meningkatkan keandalan aplikasi pada versi Kubernetes yang lebih baru. Cluster secara otomatis dipindai oleh Amazon EKS terhadap daftar kemungkinan peningkatan versi Kubernetes yang berdampak pada masalah. Amazon EKS sering memperbarui daftar pemeriksaan wawasan berdasarkan ulasan perubahan yang dibuat di setiap rilis versi Kubernetes.
Wawasan peningkatan Amazon EKS mempercepat proses pengujian dan verifikasi untuk versi baru. Mereka juga memungkinkan administrator klaster dan pengembang aplikasi untuk memanfaatkan kemampuan Kubernetes terbaru dengan menyoroti masalah dan menawarkan saran remediasi.
### Wawasan konfigurasi
Insight kluster EKS secara otomatis memindai klaster Amazon EKS dengan node hybrid untuk mengidentifikasi masalah konfigurasi yang mengganggu plane-to-webhook komunikasi kontrol Kubernetes, perintah kubectl seperti exec dan log, dan banyak lagi. Wawasan konfigurasi memunculkan masalah dan memberikan rekomendasi remediasi, mempercepat waktu ke pengaturan node hibrida yang berfungsi penuh.
## Memulai
Untuk melihat daftar pemeriksaan wawasan yang dilakukan dan masalah relevan apa pun yang telah diidentifikasi Amazon EKS, Anda dapat menggunakan Konsol Manajemen AWS operasi, AWS CLI AWS SDKs, dan Amazon EKS `ListInsights` API. Untuk memulai, lihat [Lihat wawasan cluster](view-cluster-insights.md).
# Lihat wawasan cluster
Amazon EKS menyediakan dua jenis wawasan: Wawasan **konfigurasi dan wawasan** **Peningkatan**. **Wawasan konfigurasi** mengidentifikasi kesalahan konfigurasi dalam penyiapan Node Hibrid EKS Anda yang dapat mengganggu fungsionalitas klaster atau beban kerja Anda. **Upgrade insight** mengidentifikasi masalah yang dapat memengaruhi kemampuan Anda untuk meningkatkan ke versi Kubernetes yang baru.
Untuk melihat daftar pemeriksaan wawasan yang dilakukan dan masalah relevan apa pun yang telah diidentifikasi Amazon EKS, Anda dapat memanggil tampilan dalam Konsol Manajemen AWS operasi, AWS CLI AWS SDKs, dan Amazon EKS `ListInsights` API.
## Lihat wawasan konfigurasi (Konsol)
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dari daftar cluster, pilih nama cluster Amazon EKS yang ingin Anda lihat wawasannya.
1. Pilih **Monitor cluster**.
1. Pilih tab **Kesehatan cluster**.
1. Dalam tabel **Configuration insights**, Anda akan melihat kolom berikut:
+ **Nama** — Pemeriksaan yang dilakukan oleh Amazon EKS terhadap cluster.
+ **Status wawasan** — Wawasan dengan status `Error` berarti ada kesalahan konfigurasi yang kemungkinan memengaruhi fungsionalitas klaster. Wawasan dengan status `Warning` berarti bahwa konfigurasi tidak cocok dengan pendekatan yang didokumentasikan, tetapi fungsionalitas klaster itu mungkin berfungsi jika Anda mengonfigurasinya dengan sengaja. Wawasan dengan status `Passing` berarti Amazon EKS tidak menemukan masalah apa pun yang terkait dengan pemeriksaan wawasan ini di cluster Anda.
+ **Versi - Versi** yang berlaku.
+ **Waktu penyegaran terakhir** — Waktu status wawasan terakhir disegarkan untuk cluster ini.
+ **Deskripsi** — Informasi dari pemeriksaan wawasan, yang mencakup peringatan dan tindakan yang direkomendasikan untuk perbaikan.
## Lihat wawasan peningkatan (Konsol)
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Dari daftar cluster, pilih nama cluster Amazon EKS yang ingin Anda lihat wawasannya.
1. Pilih **Monitor cluster**.
1. Pilih tab **Upgrade insights**.
1. Untuk melihat data terbaru, pilih tombol **Refresh insight** dan tunggu hingga operasi penyegaran selesai.
1. Dalam tabel **Upgrade insights**, Anda akan melihat kolom berikut:
+ **Nama** — Pemeriksaan yang dilakukan oleh Amazon EKS terhadap cluster.
+ **Insight status** — Insight dengan status “Error” biasanya berarti versi Kubernetes yang terkena dampak adalah N\$11 dari versi klaster saat ini, sedangkan status “Peringatan” berarti wawasan tersebut berlaku untuk Kubernetes versi N\$12 yang akan datang atau lebih. Wawasan dengan status “Passing” berarti Amazon EKS tidak menemukan masalah apa pun yang terkait dengan pemeriksaan wawasan ini di klaster Anda. Status wawasan “Tidak Diketahui” berarti Amazon EKS tidak dapat menentukan apakah klaster Anda terpengaruh oleh pemeriksaan wawasan ini.
+ **Versi — Versi** Kubernetes yang diperiksa wawasan untuk kemungkinan masalah.
+ **Waktu penyegaran terakhir** — Waktu status wawasan terakhir disegarkan untuk cluster ini.
+ **Waktu transisi terakhir** — Waktu status wawasan ini terakhir berubah.
+ **Deskripsi** — Informasi dari pemeriksaan wawasan, yang mencakup peringatan dan tindakan yang direkomendasikan untuk perbaikan.
## Lihat wawasan cluster (AWS CLI)
1. Untuk melihat data terbaru, segarkan wawasan untuk klaster tertentu. Buat modifikasi berikut pada perintah sesuai kebutuhan dan kemudian jalankan perintah yang dimodifikasi.
+ Ganti *region-code* dengan kode untuk AWS Wilayah Anda.
+ Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks start-insights-refresh --region region-code --cluster-name my-cluster
```
1. Untuk melacak status penyegaran wawasan, jalankan perintah berikut. Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks describe-insights-refresh --cluster-name my-cluster
```
Contoh output adalah sebagai berikut.
```
{
"message": "Insights refresh is in progress",
"status": "IN_PROGRESS",
"startedAt": "2025-07-30T13:36:09-07:00"
}
```
1. Buat daftar wawasan untuk cluster tertentu. Buat modifikasi berikut pada perintah sesuai kebutuhan dan kemudian jalankan perintah yang dimodifikasi.
+ Ganti *region-code* dengan kode untuk AWS Wilayah Anda.
+ Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks list-insights --region region-code --cluster-name my-cluster
```
Contoh output adalah sebagai berikut.
```
{
"insights":
[
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE33333",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa",
"name": "Cluster health issues",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for any cluster health issues that prevent successful upgrade to the next Kubernetes version on EKS.",
"insightStatus":
{
"status": "PASSING",
"reason": "No cluster health issues detected.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb",
"name": "EKS add-on version compatibility",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of installed EKS add-ons to ensure they are compatible with the next version of Kubernetes. ",
"insightStatus": { "status": "PASSING", "reason": "All installed EKS add-on versions are compatible with next Kubernetes version."},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEccccc",
"name": "kube-proxy version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557314.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks version of kube-proxy in cluster to see if upgrade would cause non compliance with supported Kubernetes kube-proxy version skew policy.",
"insightStatus":
{
"status": "PASSING",
"reason": "kube-proxy versions match the cluster control plane version.",
},
},
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLEddddd",
"name": "Deprecated APIs removed in Kubernetes vX.XX",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "X.XX",
"lastRefreshTime": 1734557315.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for usage of deprecated APIs that are scheduled for removal in Kubernetes vX.XX. Upgrading your cluster before migrating to the updated APIs supported by vX.XX could cause application impact.",
"insightStatus":
{
"status": "PASSING",
"reason": "No deprecated API usage detected within the last 30 days.",
},
},
],
"nextToken": null,
}
```
1. Untuk informasi deskriptif tentang wawasan, jalankan perintah berikut. Buat modifikasi berikut pada perintah sesuai kebutuhan dan kemudian jalankan perintah yang dimodifikasi.
+ Ganti *region-code* dengan kode untuk AWS Wilayah Anda.
+ Ganti *a1b2c3d4-5678-90ab-cdef-EXAMPLE22222* dengan ID wawasan yang diambil dari daftar wawasan cluster.
+ Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks describe-insight --region region-code --id a1b2c3d4-5678-90ab-cdef-EXAMPLE22222 --cluster-name my-cluster
```
Contoh output adalah sebagai berikut.
```
{
"insight":
{
"id": "a1b2c3d4-5678-90ab-cdef-EXAMPLE22222",
"name": "Kubelet version skew",
"category": "UPGRADE_READINESS",
"kubernetesVersion": "1.27",
"lastRefreshTime": 1734557309.000,
"lastTransitionTime": 1734557309.000,
"description": "Checks for kubelet versions of worker nodes in the cluster to see if upgrade would cause non compliance with supported Kubernetes kubelet version skew policy.",
"insightStatus":
{
"status": "UNKNOWN",
"reason": "Unable to determine status of node kubelet versions.",
},
"recommendation": "Upgrade your worker nodes to match the Kubernetes version of your cluster control plane.",
"additionalInfo":
{
"Kubelet version skew policy": "https://kubernetes.io/releases/version-skew-policy/#kubelet",
"Updating a managed node group": "https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html",
},
"resources": [],
"categorySpecificSummary":
{ "deprecationDetails": [], "addonCompatibilityDetails": [] },
},
}
```
# Perbarui klaster yang ada ke versi Kubernetes baru
**Tip**
[Daftar](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) untuk lokakarya Amazon EKS mendatang.
Ketika versi Kubernetes baru tersedia di Amazon EKS, Anda dapat memperbarui kluster Amazon EKS Anda ke versi terbaru.
**penting**
Setelah Anda memutakhirkan cluster, Anda tidak dapat menurunkan versi ke versi sebelumnya. Sebelum Anda memperbarui ke versi Kubernetes yang baru, kami sarankan Anda meninjau informasi di [Memahami siklus hidup versi Kubernetes di EKS dan langkah-langkah pembaruan dalam topik](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) ini.
Versi Kubernetes baru terkadang memperkenalkan perubahan signifikan. Oleh karena itu, kami merekomendasikan Anda menguji perilaku aplikasi Anda terhadap versi Kubernetes baru sebelum Anda memperbarui klaster produksi Anda. Anda dapat melakukannya dengan membangun alur kerja integrasi berkelanjutan untuk menguji perilaku aplikasi Anda sebelum pindah ke versi Kubernetes yang baru.
Proses update terdiri dari Amazon EKS meluncurkan simpul server API baru dengan versi Kubernetes yang diperbarui untuk menggantikan yang sudah ada. Amazon EKS melakukan infrastruktur standar dan pemeriksaan kesehatan kesiapan untuk lalu lintas jaringan pada node baru ini untuk memverifikasi bahwa mereka berfungsi seperti yang diharapkan. Namun, setelah Anda memulai upgrade cluster, Anda tidak dapat menjeda atau menghentikannya. Jika salah satu pemeriksaan ini gagal, Amazon EKS mengembalikan deployment infrastruktur itu, dan klaster Anda tetap pada versi Kubernetes sebelumnya. Menjalankan aplikasi tidak terpengaruh, dan klaster Anda tidak pernah dibiarkan dalam keadaan non-deterministik atau tidak dapat dipulihkan. Amazon EKS secara teratur mendukung semua klaster terkelola, dan mekanisme yang ada untuk memulihkan klaster jika diperlukan. Kami terus mengevaluasi dan meningkatkan proses manajemen infrastruktur Kubernetes kami.
Untuk memperbarui klaster, Amazon EKS memerlukan hingga lima alamat IP yang tersedia dari subnet yang Anda tentukan saat membuat klaster. Amazon EKS membuat antarmuka jaringan elastis klaster baru (antarmuka jaringan) di salah satu subnet yang Anda tentukan. Antarmuka jaringan dapat dibuat dalam subnet yang berbeda dari antarmuka jaringan yang ada, jadi pastikan bahwa aturan grup keamanan Anda mengizinkan [komunikasi cluster yang diperlukan](sec-group-reqs.md) untuk setiap subnet yang Anda tentukan saat Anda membuat cluster Anda. Jika salah satu subnet yang Anda tentukan saat membuat klaster tidak ada, tidak memiliki cukup alamat IP yang tersedia, atau tidak memiliki aturan grup keamanan yang memungkinkan komunikasi cluster yang diperlukan, maka pembaruan dapat gagal.
Untuk memastikan bahwa endpoint server API untuk klaster Anda selalu dapat diakses, Amazon EKS menyediakan bidang kontrol Kubernetes yang sangat tersedia dan melakukan pembaruan bergulir instance server API selama operasi pembaruan. Untuk memperhitungkan perubahan alamat IP instance server API yang mendukung endpoint server API Kubernetes Anda, Anda harus memastikan bahwa klien server API Anda mengelola koneksi ulang secara efektif. Versi terbaru `kubectl` dan [pustaka](https://kubernetes.io/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) klien Kubernetes yang didukung secara resmi, melakukan proses penyambungan kembali ini secara transparan.
**catatan**
Untuk mempelajari lebih lanjut tentang apa yang masuk ke pembaruan klaster, lihat [Praktik Terbaik untuk Peningkatan Cluster](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html) di Panduan Praktik Terbaik EKS. Sumber daya ini membantu Anda merencanakan peningkatan, dan memahami strategi peningkatan klaster.
## Pertimbangan untuk Mode Otomatis Amazon EKS
+ Kemampuan komputasi Amazon EKS Auto Mode mengontrol node versi Kubernetes. Setelah Anda memutakhirkan bidang kontrol, Mode Otomatis EKS akan mulai memperbarui node terkelola secara bertahap. Mode Otomatis EKS menghormati anggaran gangguan pod.
+ Anda tidak perlu memutakhirkan kemampuan Amazon EKS Auto Mode secara manual, termasuk kemampuan penskalaan otomatis komputasi, penyimpanan blok, dan penyeimbangan beban.
## Ringkasan
Ringkasan tingkat tinggi dari proses upgrade cluster Amazon EKS adalah sebagai berikut:
1. Pastikan klaster Anda dalam keadaan yang akan mendukung peningkatan. Ini termasuk memeriksa Kubernetes yang APIs digunakan oleh sumber daya yang digunakan ke dalam klaster, memastikan klaster bebas dari masalah kesehatan apa pun. Anda harus menggunakan wawasan pemutakhiran Amazon EKS saat mengevaluasi kesiapan pemutakhiran klaster Anda.
1. Tingkatkan bidang kontrol ke versi minor berikutnya (misalnya, dari 1,34 menjadi 1,35).
1. Tingkatkan node di bidang data agar sesuai dengan bidang kontrol.
1. Tingkatkan aplikasi tambahan apa pun yang berjalan di cluster (misalnya,`cluster-autoscaler`).
1. Tingkatkan add-on yang disediakan oleh Amazon EKS, seperti yang disertakan secara default:
+ [Versi yang direkomendasikan Amazon VPC CNI](managing-vpc-cni.md)
+ [CoreDNS versi yang direkomendasikan](managing-coredns.md)
+ [`kube-proxy`versi yang direkomendasikan](managing-kube-proxy.md)
1. Tingkatkan setiap klien yang berkomunikasi dengan cluster (misalnya,`kubectl`).
## Langkah 1: Bersiaplah untuk upgrade
Bandingkan versi Kubernetes dari pesawat kontrol klaster Anda ke versi Kubernetes simpul Anda.
+ Dapatkan versi Kubernetes dari bidang kontrol cluster Anda.
```
kubectl version
```
+ Dapatkan versi Kubernetes dari node Anda. Perintah ini mengembalikan semua node Amazon EC2, Fargate, dan hybrid yang dikelola sendiri dan dikelola. Setiap Pod Fargate terdaftar sebagai simpulnya sendiri.
```
kubectl get nodes
```
Sebelum memperbarui control plane Anda ke versi Kubernetes baru, pastikan bahwa versi minor Kubernetes dari kedua node terkelola dan node Fargate di cluster Anda sama dengan versi control plane Anda. Misalnya, jika bidang kontrol Anda menjalankan versi `1.29` dan salah satu node Anda menjalankan versi`1.28`, maka Anda harus memperbarui node Anda ke versi `1.29` sebelum memperbarui bidang kontrol Anda ke 1.30. Kami juga menyarankan agar Anda memperbarui node yang dikelola sendiri dan node hibrida ke versi yang sama dengan bidang kontrol Anda sebelum memperbarui bidang kontrol. Lihat informasi selengkapnya di [Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md), [Perbarui node yang dikelola sendiri untuk klaster Anda](update-workers.md), dan [Tingkatkan node hybrid untuk klaster Anda](hybrid-nodes-upgrade.md). Jika Anda memiliki node Fargate dengan versi minor lebih rendah dari versi control plane, pertama-tama hapus Pod yang diwakili oleh node tersebut. Kemudian perbarui pesawat kontrol Anda. Pod yang tersisa akan diperbarui ke versi baru setelah Anda menerapkannya kembali.
## Langkah 2: Tinjau pertimbangan peningkatan
Wawasan klaster Amazon EKS secara otomatis memindai klaster terhadap daftar potensi peningkatan versi Kubernetes yang memengaruhi masalah seperti penggunaan API Kubernetes yang tidak digunakan lagi. Amazon EKS memperbarui daftar pemeriksaan wawasan secara berkala untuk dilakukan berdasarkan evaluasi perubahan dalam proyek Kubernetes. Amazon EKS juga memperbarui daftar pemeriksaan wawasan saat perubahan diperkenalkan di layanan Amazon EKS bersama dengan versi baru. Untuk informasi selengkapnya, lihat [Bersiaplah untuk upgrade versi Kubernetes dan pecahkan masalah kesalahan konfigurasi dengan wawasan klaster](cluster-insights.md).
Tinjau [Panduan Migrasi API yang Tidak Digunakan Lagi di dokumen Kubernetes](https://kubernetes.io/docs/reference/using-api/deprecation-guide/).
### Tinjau wawasan peningkatan
Gunakan wawasan pemutakhiran Amazon EKS untuk mengidentifikasi masalah. Untuk informasi selengkapnya, lihat [Lihat wawasan peningkatan (Konsol)](view-cluster-insights.md#view-upgrade-insights-console).
### Pertimbangan terperinci
+ Karena Amazon EKS menjalankan bidang pengendali yang banyak tersedia, Anda dapat memperbarui hanya satu versi minor pada satu waktu. Untuk informasi selengkapnya tentang persyaratan ini, lihat [Kubernetes Version and Version Skew](https://kubernetes.io/docs/setup/version-skew-policy/#kube-apiserver) Support Policy. Asumsikan bahwa versi cluster Anda saat ini adalah versi `1.28` dan Anda ingin memperbaruinya ke versi`1.30`. Anda harus terlebih dahulu memperbarui `1.28` klaster versi Anda ke versi `1.29` dan kemudian memperbarui `1.29` klaster versi Anda ke versi`1.30`.
+ Tinjau versi miring antara Kubernetes `kube-apiserver` dan pada node Anda. `kubelet`
+ Mulai dari versi Kubernetes`1.28`, `kubelet` mungkin sampai tiga versi minor lebih lama dari. `kube-apiserver` Lihat Kebijakan [miring versi upstream Kubernetes](https://kubernetes.io/releases/version-skew-policy/#kubelet).
+ Jika `kubelet` pada node terkelola dan Fargate Anda ada di versi Kubernetes `1.25` atau yang lebih baru, Anda dapat memperbarui klaster Anda hingga tiga versi ke depan tanpa memperbarui versinya. `kubelet` Misalnya, jika versi aktif `kubelet``1.25`, Anda dapat memperbarui versi kluster Amazon EKS Anda dari `1.25` ke`1.26`, ke`1.27`, dan ke `1.28` sementara versi `kubelet` tetap ada`1.25`.
+ Sebagai praktik terbaik sebelum memulai pembaruan, pastikan bahwa pada node Anda `kubelet` berada pada versi Kubernetes yang sama dengan bidang kontrol Anda.
+ Jika cluster Anda dikonfigurasi dengan versi plugin Amazon VPC CNI untuk Kubernetes yang lebih awal dari`1.8.0`, maka sebaiknya Anda memperbarui plugin ke versi terbaru sebelum memperbarui cluster Anda. Untuk memperbarui plugin, lihat[Tetapkan IPs ke Pod dengan Amazon VPC CNI](managing-vpc-cni.md).
+ Anda dapat mengambil cadangan kluster Amazon EKS Anda, untuk memungkinkan Anda memulihkan status klaster Amazon EKS dan penyimpanan persisten jika terjadi kegagalan selama proses pemutakhiran. Lihat [Backup Kluster EKS Anda dengan AWS Backup](integration-backup.md)
## Langkah 3: Perbarui bidang kontrol cluster
**penting**
Amazon EKS telah mengembalikan sementara fitur yang mengharuskan Anda menggunakan `--force` flag untuk memutakhirkan klaster Anda ketika ada masalah wawasan klaster tertentu. Untuk informasi selengkapnya, lihat [Pengembalian sementara untuk menerapkan wawasan pemutakhiran pada versi klaster pembaruan pada](https://github.com/aws/containers-roadmap/issues/2570). GitHub
Amazon EKS menyegarkan wawasan cluster 24 jam setelah “waktu penyegaran terakhir”. Anda dapat membandingkan waktu Anda mengatasi masalah dengan “waktu penyegaran terakhir” dari wawasan cluster.
Selain itu, status insight dapat diperbaharui hingga 30 hari setelah menangani penggunaan API yang tidak digunakan lagi. Upgrade insights selalu mencari penggunaan API yang tidak digunakan lagi selama 30 hari yang bergulir.
Anda dapat mengirimkan permintaan untuk meningkatkan versi pesawat kontrol EKS Anda menggunakan:
+ [eksctl](#step3-eksctl)
+ [AWS konsol](#step3-console)
+ [AWS CLI](#step3-cli)
### Perbarui cluster - eksctl
Prosedur ini membutuhkan `eksctl` versi `0.215.0` atau yang lebih baru. Anda dapat memeriksa versi Anda dengan perintah berikut:
```
eksctl version
```
Untuk petunjuk tentang cara menginstal dan memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
Perbarui versi Kubernetes dari pesawat kontrol Amazon EKS Anda. Ganti `` dengan nama klaster Anda. Ganti `` dengan nomor versi yang didukung Amazon EKS yang ingin Anda perbarui klaster Anda. Untuk daftar nomor versi yang didukung, lihat [versi yang didukung Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
eksctl upgrade cluster --name --version --approve
```
Pembaruan memerlukan waktu beberapa menit.
Lanjutkan ke [Langkah 4: Perbarui komponen cluster](#step4).
### Perbarui cluster - AWS konsol
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih **Upgrade sekarang** untuk cluster yang ingin Anda upgrade.
1. Pilih versi untuk memperbarui cluster Anda dan pilih **Upgrade**.
1. Pembaruan memerlukan waktu beberapa menit. Lanjutkan ke [Langkah 4: Perbarui komponen cluster](#step4).
### Perbarui cluster - AWS CLI
1. Verifikasi bahwa AWS CLI diinstal dan Anda masuk. Untuk informasi selengkapnya, lihat [Menginstal atau memperbarui ke versi terbaru AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html).
1. Perbarui cluster Amazon EKS Anda dengan perintah AWS CLI berikut. Ganti `` dan `` cluster yang ingin Anda tingkatkan. Ganti `` dengan nomor versi yang didukung Amazon EKS yang ingin Anda perbarui klaster Anda. Untuk daftar nomor versi yang didukung, lihat [versi yang didukung Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html).
```
aws eks update-cluster-version --name \
--kubernetes-version --region
```
Contoh output adalah sebagai berikut.
```
{
"update": {
"id": "",
"status": "InProgress",
"type": "VersionUpdate",
"params": [
{
"type": "Version",
"value": ""
},
{
"type": "PlatformVersion",
"value": "eks.1"
}
],
[...]
"errors": []
}
```
1. Pembaruan memerlukan waktu beberapa menit. Pantau status pembaruan klaster Anda dengan perintah berikut. Selain menggunakan yang sama `` dan``, gunakan `` yang dikembalikan oleh perintah sebelumnya.
```
aws eks describe-update --name \
--region --update-id
```
Ketika `Successful` status ditampilkan, pembaruan selesai.
1. Lanjutkan ke [Langkah 4: Perbarui komponen cluster](#step4).
## Langkah 4: Perbarui komponen cluster
1. Setelah pembaruan klaster Anda selesai, perbarui node Anda ke versi minor Kubernetes yang sama dengan klaster Anda yang diperbarui. Lihat informasi selengkapnya di [Perbarui node yang dikelola sendiri untuk klaster Anda](update-workers.md), [Memperbarui grup node terkelola untuk klaster Anda](update-managed-node-group.md), dan [Tingkatkan node hybrid untuk klaster Anda](hybrid-nodes-upgrade.md). Pod baru apa pun yang diluncurkan di Fargate memiliki `kubelet` versi yang cocok dengan versi klaster Anda. Pod Fargate yang ada tidak diubah.
1. (Opsional) Jika Anda men-deploy Kubernetes Cluster Autoscaler ke klaster Anda sebelum memperbarui klaster, perbarui Cluster Autoscaler ke versi terbaru yang cocok dengan Kubernetes versi major dan minor yang Anda perbarui.
1. Buka halaman [rilis](https://github.com/kubernetes/autoscaler/releases) Cluster Autoscaler di browser web dan temukan versi Cluster Autoscaler terbaru yang cocok dengan versi mayor dan minor Kubernetes klaster Anda. Misalnya, jika versi Kubernetes klaster Anda `1.30` menemukan rilis Cluster Autoscaler terbaru yang dimulai dengan. `1.30` Catat nomor versi semantik (`1.30.n`, misalnya) untuk rilis yang akan digunakan pada langkah berikutnya.
1. Atur tanda citra Cluster Autoscaler ke versi yang Anda catat di langkah sebelumnya dengan perintah berikut. Jika perlu, ganti `X.XX.X` dengan nilai Anda sendiri.
```
kubectl -n kube-system set image deployment.apps/cluster-autoscaler cluster-autoscaler=registry.k8s.io/autoscaling/cluster-autoscaler:vX.XX.X
```
1. (Cluster dengan node GPU saja) Jika cluster Anda memiliki grup node dengan dukungan GPU (misalnya,`p3.2xlarge`), Anda harus memperbarui [plugin perangkat NVIDIA untuk DaemonSet Kubernetes](https://github.com/NVIDIA/k8s-device-plugin) di cluster Anda. Ganti `` dengan s-device-plugin versi [NVIDIA/K8](https://github.com/NVIDIA/k8s-device-plugin/releases) yang Anda inginkan sebelum menjalankan perintah berikut.
```
kubectl apply -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin//deployments/static/nvidia-device-plugin.yml
```
1. Perbarui plugin Amazon VPC CNI untuk Kubernetes, CoreDNS, dan add-on. `kube-proxy` Kami menyarankan untuk memperbarui add-on ke versi minimum yang tercantum dalam [token akun Layanan](service-accounts.md#boundserviceaccounttoken-validated-add-on-versions).
+ Jika Anda menggunakan add-on Amazon EKS, pilih **Cluster** di konsol Amazon EKS, lalu pilih nama cluster yang Anda perbarui di panel navigasi kiri. Pemberitahuan muncul di konsol. Mereka memberi tahu Anda bahwa versi baru tersedia untuk setiap add-on yang memiliki pembaruan yang tersedia. Untuk memperbarui add-on, pilih tab **Add-ons.** Di salah satu kotak untuk add-on yang memiliki pembaruan yang tersedia, pilih **Perbarui sekarang**, pilih versi yang tersedia, lalu pilih **Perbarui**.
+ Sebagai alternatif, Anda dapat menggunakan AWS CLI atau `eksctl` memperbarui add-on. Untuk informasi selengkapnya, lihat [Perbarui add-on Amazon EKS](updating-an-add-on.md).
1. Jika perlu, perbarui versi Anda`kubectl`. Anda harus menggunakan versi `kubectl` yang tidak lebih dari satu perbedaan kecil dari bidang kendali Amazon EKS klaster Anda.
## Turunkan versi Kubernetes untuk klaster Amazon EKS
Anda tidak dapat menurunkan versi Kubernetes dari cluster Amazon EKS. Sebagai gantinya, buat cluster baru pada versi Amazon EKS sebelumnya dan migrasi beban kerja.
# Hapus klaster
Setelah selesai menggunakan kluster Amazon EKS, Anda harus menghapus sumber daya yang terkait dengannya sehingga Anda tidak dikenakan biaya yang tidak perlu.
Anda dapat menghapus cluster dengan`eksctl`, Konsol Manajemen AWS, atau AWS CLI.
## Pertimbangan-pertimbangan
+ Jika Anda menerima kesalahan karena pembuat klaster telah dihapus, lihat [artikel ini](https://aws.amazon.com/premiumsupport/knowledge-center/eks-api-server-unauthorized-error) untuk menyelesaikannya.
+ Layanan Terkelola Amazon untuk sumber daya Prometheus berada di luar siklus hidup klaster dan perlu dipertahankan secara independen dari klaster. Saat Anda menghapus klaster Anda, pastikan juga untuk menghapus pencakar yang berlaku untuk menghentikan biaya yang berlaku. Untuk informasi selengkapnya, lihat [Menemukan dan menghapus pencakar](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-collector-how-to.html#AMP-collector-list-delete) di *Amazon Managed Service for Prometheus* User Guide.
+ Untuk menghapus klaster yang terhubung, lihat [Membatalkan pendaftaran cluster Kubernetes dari konsol Amazon EKS](deregister-connected-cluster.md)
+ Sebelum Anda dapat menghapus klaster, pastikan proteksi penghapusan dinonaktifkan untuk klaster Anda.
### Pertimbangan untuk Mode Otomatis EKS
+ Setiap Node Mode Otomatis EKS akan dihapus, termasuk instans terkelola EC2
+ Semua load balancer akan dihapus
Untuk informasi selengkapnya, lihat [Nonaktifkan Mode Otomatis EKS](auto-disable.md).
## Langkah prasyarat
Berikut ini adalah langkah-langkah yang harus Anda lakukan terlebih dahulu sebelum Anda dapat menghapus cluster. Langkah-langkah ini berlaku terlepas dari metode yang Anda gunakan untuk menghapus klaster Anda.
1. Buat daftar semua layanan yang berjalan di klaster Anda.
```
kubectl get svc --all-namespaces
```
1. Hapus layanan apa pun yang memiliki nilai `EXTERNAL-IP` yang terkait. Layanan-layanan ini didukung oleh penyeimbang beban Elastic Load Balancing, dan Anda harus menghapusnya di Kubernetes agar penyeimbang beban dan sumber daya terkait dilepaskan dengan benar. Ganti *service-name* dengan nama setiap layanan yang tercantum seperti yang dijelaskan.
```
kubectl delete svc service-name
```
1. Hapus sumber daya masuk apa pun juga. Jika Anda tidak menghapus sumber daya masuk, penyeimbang beban aplikasi tetap ada meskipun Anda menghapus klaster. Ganti *ingress-name* dengan nama sumber daya masuk Anda.
```
kubectl get ingress --all-namespaces
```
```
kubectl delete ing ingress-name
```
## Hapus cluster (eksctl)
Prosedur ini membutuhkan `eksctl` versi `0.215.0` atau yang lebih baru. Anda dapat memeriksa versi Anda dengan perintah berikut:
```
eksctl version
```
Untuk petunjuk tentang cara menginstal atau meningkatkan`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
1. Pergi melalui langkah-langkah [prasyarat](#prerequisite-steps). Setelah melakukannya, hapus cluster Anda dan node yang terkait dengan perintah berikut, ganti *prod* dengan nama cluster Anda.
```
eksctl delete cluster --name prod
```
Output:
```
[ℹ] using region region-code
[ℹ] deleting EKS cluster "prod"
[ℹ] will delete stack "eksctl-prod-nodegroup-standard-nodes"
[ℹ] waiting for stack "eksctl-prod-nodegroup-standard-nodes" to get deleted
[ℹ] will delete stack "eksctl-prod-cluster"
[✔] the following EKS cluster resource(s) for "prod" will be deleted: cluster. If in doubt, check CloudFormation console
```
## Hapus cluster (AWS konsol)
1. Pergi melalui langkah-langkah [prasyarat](#prerequisite-steps). Setelah melakukannya, hapus semua grup node dan profil Fargate.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di panel navigasi kiri, pilih Amazon **EKS Clusters**, lalu di daftar tab cluster, pilih nama cluster yang ingin Anda hapus.
1. Pilih tab **Compute** dan pilih grup node untuk dihapus. Pilih **Hapus**, masukkan nama grup simpul, lalu pilih **Hapus**. Hapus semua grup simpul dalam klaster.
**catatan**
Grup-grup simpul yang terdaftar hanyalah [grup simpul dikelola](managed-node-groups.md).
1. **Pilih **Profil Fargate** untuk dihapus, pilih **Hapus**, masukkan nama profil, lalu pilih Hapus.** Hapus semua profil Fargate di klaster.
1. Hapus semua [AWS CloudFormation tumpukan node yang dikelola sendiri](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Pilih tumpukan simpul yang akan dihapus, lalu pilih **Hapus**.
1. Di kotak dialog **Hapus tumpukan** konfirmasi, pilih **Hapus tumpukan**. Hapus semua tumpukan simpul swakelola di dalam klaster.
1. Hapus klaster .
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. pilih cluster yang akan dihapus dan pilih **Hapus**.
1. Pada layar konfirmasi hapus klaster, pilih **Hapus**.
1. (Opsional) Hapus tumpukan VPC AWS CloudFormation .
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. **Pilih tumpukan VPC yang akan dihapus, lalu pilih Hapus.**
1. Di kotak dialog **Hapus tumpukan** konfirmasi, pilih **Hapus tumpukan**.
## Hapus cluster (AWS CLI)
1. Pergi melalui langkah-langkah [prasyarat](#prerequisite-steps). Setelah melakukannya, hapus semua grup node dan profil Fargate.
1. Buat daftar grup simpul di klaster Anda dengan perintah berikut.
```
aws eks list-nodegroups --cluster-name my-cluster
```
**catatan**
Grup-grup simpul yang terdaftar adalah [grup simpul dikelola](managed-node-groups.md) saja.
1. Hapus setiap grup simpul dengan perintah berikut. Hapus semua grup simpul dalam klaster.
```
aws eks delete-nodegroup --nodegroup-name my-nodegroup --cluster-name my-cluster
```
1. Buat daftar profil Fargate di klaster Anda dengan perintah berikut.
```
aws eks list-fargate-profiles --cluster-name my-cluster
```
1. Hapus setiap profil Fargate dengan perintah berikut. Hapus semua profil Fargate di dalam klaster.
```
aws eks delete-fargate-profile --fargate-profile-name my-fargate-profile --cluster-name my-cluster
```
1. Hapus semua [AWS CloudFormation tumpukan node yang dikelola sendiri](https://docs.aws.amazon.com/eks/latest/userguide/worker).
1. Buat daftar AWS CloudFormation tumpukan yang tersedia dengan perintah berikut. Temukan nama templat simpul dalam output yang dihasilkan.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Hapus setiap tumpukan node dengan perintah berikut, ganti *node-stack* dengan nama tumpukan node Anda. Hapus semua tumpukan simpul swakelola di dalam klaster.
```
aws cloudformation delete-stack --stack-name node-stack
```
1. Hapus cluster dengan perintah berikut, ganti *my-cluster* dengan nama cluster Anda.
```
aws eks delete-cluster --name my-cluster
```
1. (Opsional) Hapus tumpukan VPC AWS CloudFormation .
1. Buat daftar AWS CloudFormation tumpukan yang tersedia dengan perintah berikut. Temukan nama templat VPC dalam output yang dihasilkan.
```
aws cloudformation list-stacks --query "StackSummaries[].StackName"
```
1. Hapus tumpukan VPC dengan perintah berikut, ganti *my-vpc-stack* dengan nama tumpukan VPC Anda.
```
aws cloudformation delete-stack --stack-name my-vpc-stack
```
# Melindungi klaster EKS dari penghapusan yang tidak disengaja
Menghapus klaster EKS secara tidak sengaja dapat mengganggu operasi klaster Kubernetes.
Anda sekarang dapat melindungi kluster EKS dari penghapusan yang tidak disengaja. Jika Anda mengaktifkan perlindungan penghapusan pada klaster, Anda harus terlebih dahulu menonaktifkan perlindungan penghapusan sebelum Anda dapat menghapus klaster.
Tujuan dari perlindungan penghapusan adalah untuk mencegah kecelakaan. Anda harus hati-hati membatasi siapa yang berwenang untuk menghapus cluster.
Jika Anda mencoba menghapus klaster aktif yang memiliki perlindungan penghapusan diaktifkan, Anda akan menerima file. `InvalidRequestException`
**penting**
**Jika Anda mengaktifkan perlindungan penghapusan pada klaster, Anda harus memiliki izin UpdateClusterConfig dan DeleteCluster IAM untuk menghapus perlindungan penghapusan terlebih dahulu, dan akhirnya menghapus klaster.**
**catatan**
Jika status klaster membuat, gagal, atau menghapus, Anda dapat menghapus klaster meskipun perlindungan penghapusan diaktifkan.
## Untuk mengaktifkan perlindungan penghapusan untuk klaster yang ada
Anda hanya dapat menjalankan ini di klaster dalam status aktif.
```
aws eks update-cluster-config --name --region --deletion-protection
```
## Untuk menonaktifkan perlindungan penghapusan untuk klaster yang ada
```
aws eks update-cluster-config --name --region --no-deletion-protection
```
# Titik akhir server API kluster
Topik ini membantu Anda mengaktifkan akses pribadi untuk titik akhir server API Kubernetes klaster Amazon EKS Anda dan membatasi, atau sepenuhnya menonaktifkan, akses publik dari internet.
Ketika Anda membuat klaster baru, Amazon EKS membuat titik akhir untuk server API Kubernetes terkelola yang Anda gunakan untuk berkomunikasi dengan klaster Anda (alat pengelolaan Kubernetes seperti `kubectl`). Secara default, endpoint server API ini bersifat publik ke internet, dan akses ke server API diamankan menggunakan kombinasi AWS Identity and Access Management (IAM) and Access Management (IAM) dan native [Kubernetes](https://kubernetes.io/docs/reference/access-authn-authz/rbac/) Role Based Access Control (RBAC). Endpoint ini dikenal sebagai *cluster public endpoint*. Juga ada *titik akhir pribadi cluster*. Untuk informasi selengkapnya tentang titik akhir pribadi cluster, lihat bagian [Titik akhir pribadi cluster](#cluster-endpoint-private) berikut.
## `IPv6`format titik akhir cluster
EKS membuat titik akhir dual-stack unik dalam format berikut untuk `IPv6` cluster baru yang dibuat setelah Oktober 2024. Cluster adalah *IPv6 cluster* yang Anda pilih `IPv6` dalam pengaturan IP family (`ipFamily`) cluster.
**Example**
public/private Titik akhir kluster EKS: `eks-cluster.region.api.aws`
public/private Titik akhir kluster EKS: `eks-cluster.region.api.aws`
public/private Titik akhir kluster EKS: `eks-cluster---region---api.amazonwebservices.com.rproxy.goskope.com.cn`
**catatan**
Titik akhir cluster dual-stack diperkenalkan pada Oktober 2024. Untuk informasi selengkapnya tentang `IPv6` cluster, lihat[Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md). Cluster yang dibuat sebelum Oktober 2024, gunakan format titik akhir berikut sebagai gantinya.
## `IPv4`format titik akhir cluster
EKS membuat titik akhir unik dalam format berikut untuk setiap cluster yang memilih `IPv4` dalam pengaturan keluarga IP (IPFamily) cluster:
**Example**
Titik public/private akhir kluster EKS `eks-cluster.region.eks.amazonaws.com`
Titik public/private akhir kluster EKS `eks-cluster.region.eks.amazonaws.com`
Titik public/private akhir kluster EKS `eks-cluster---region.amazonwebservices.com.rproxy.goskope.com.cn`
**catatan**
Sebelum Oktober 2024, `IPv6` cluster menggunakan format titik akhir ini juga. Untuk cluster tersebut, titik akhir publik dan titik akhir pribadi hanya memiliki `IPv4` alamat penyelesaian dari titik akhir ini.
## Titik akhir pribadi cluster
Anda dapat mengaktifkan akses privat ke server API Kubernetes sehingga semua komunikasi antara simpul Anda dan server API tetap berada di dalam VPC Anda. Anda dapat membatasi alamat IP yang dapat mengakses server API Anda dari internet, atau menonaktifkan sepenuhnya akses internet ke server API.
**catatan**
Karena titik akhir ini untuk server API Kubernetes dan bukan AWS PrivateLink titik akhir tradisional untuk berkomunikasi dengan AWS API, titik akhir ini tidak muncul sebagai titik akhir di konsol VPC Amazon.
Saat Anda mengaktifkan akses pribadi titik akhir untuk klaster Anda, Amazon EKS membuat zona host pribadi Route 53 atas nama Anda dan mengaitkannya dengan VPC klaster Anda. Zona host pribadi ini dikelola oleh Amazon EKS, dan tidak muncul di sumber daya Route 53 akun Anda. Agar zona privat yang di-hosting dapat merutekan lalu lintas ke server API Anda dengan benar, VPC Anda harus memiliki `enableDnsHostnames` dan `enableDnsSupport` yang diatur ke `true`, dan opsi DHCP yang diatur untuk VPC Anda harus menyertakan `AmazonProvidedDNS` dalam daftar server nama domainnya. Untuk informasi selengkapnya, lihat [Memperbarui DNS dukungan untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-updating) dalam *Panduan Pengguna Amazon VPC*.
Anda dapat menentukan persyaratan akses titik akhir server API ketika membuat klaster baru, dan dapat memperbarui akses tersebut untuk klaster kapanpun.
## Memodifikasi akses titik akhir klaster
Gunakan prosedur di bagian ini untuk memodifikasi akses titik akhir untuk klaster yang sudah ada. Tabel berikut menunjukkan kombinasi akses titik akhir server API yang didukung dan perilaku terkaitnya.
| Akses publik titik akhir | Akses privat titik akhir | Perilaku |
| --- | --- | --- |
| Diaktifkan | Dinonaktifkan | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/cluster-endpoint.html) |
| Diaktifkan | Diaktifkan | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/cluster-endpoint.html) |
| Nonaktif | Diaktifkan | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/cluster-endpoint.html) |
**Kontrol akses titik akhir**
Perhatikan bahwa setiap metode berikut untuk mengontrol akses titik akhir hanya memengaruhi titik akhir masing-masing.
*Grup keamanan cluster*
Grup keamanan klaster mengontrol dua jenis koneksi: koneksi ke *kubelet API dan titik* akhir pribadi. Koneksi ke `kubelet` API digunakan dalam`kubectl attach`,,`kubectl cp`, `kubectl exec``kubectl logs`, dan `kubectl port-forward` perintah. Grup keamanan klaster tidak memengaruhi titik akhir publik.
*Akses publik CIDRs*
*Akses CIDRs kontrol akses publik* ke titik akhir publik dengan daftar blok CIDR. Perhatikan bahwa akses publik CIDRs tidak memengaruhi titik akhir pribadi. Akses publik CIDRs berperilaku berbeda pada `IPv6` cluster dan `IPv4` cluster tergantung pada tanggal pembuatannya, yang dijelaskan sebagai berikut:
**Blok CIDR di titik akhir publik (cluster) `IPv6`**
Anda dapat menambahkan `IPv6` dan `IPv4` CIDR memblokir ke titik akhir publik sebuah `IPv6` cluster, karena titik akhir publik adalah dual-stack. Ini hanya berlaku untuk cluster baru dengan `ipFamily` set `IPv6` yang Anda buat pada Oktober 2024 atau lebih baru. Anda dapat mengidentifikasi klaster ini dengan nama domain endpoint baru. `api.aws`
**Blok CIDR di titik akhir publik (cluster) `IPv4`**
Anda dapat menambahkan blok `IPv4` CIDR ke titik akhir publik sebuah `IPv4` cluster. Anda tidak dapat menambahkan blok `IPv6` CIDR ke titik akhir publik klaster. `IPv4` Jika Anda mencoba, EKS mengembalikan pesan galat berikut: `The following CIDRs are invalid in publicAccessCidrs`
**Blok CIDR di titik akhir publik (`IPv6`cluster dibuat sebelum Oktober 2024)**
Anda dapat menambahkan blok `IPv4` CIDR ke titik akhir publik dari `IPv6` cluster lama yang Anda buat sebelum Oktober 2024. Anda dapat mengidentifikasi cluster ini dengan titik `eks.amazonaws.com` akhir. Anda tidak dapat menambahkan blok `IPv6` CIDR ke titik akhir publik dari `IPv6` cluster lama yang Anda buat sebelum Oktober 2024. Jika Anda mencoba, EKS mengembalikan pesan galat berikut: `The following CIDRs are invalid in publicAccessCidrs`
## Mengakses server API privat saja
[Jika Anda telah menonaktifkan akses publik untuk titik akhir server Kubernetes API klaster Anda, Anda hanya dapat mengakses server API dari dalam VPC atau jaringan yang terhubung.](https://docs.aws.amazon.com/whitepapers/latest/aws-vpc-connectivity-options/introduction.html) Berikut adalah beberapa alternatif cara untuk mengakses titik akhir server Kubernetes API:
**Jaringan yang terhubung**
Hubungkan jaringan Anda ke VPC dengan [gateway AWS transit](https://docs.aws.amazon.com/vpc/latest/tgw/what-is-transit-gateway.html) atau opsi [konektivitas](https://docs.aws.amazon.com/aws-technical-content/latest/aws-vpc-connectivity-options/introduction.html) lainnya dan kemudian gunakan komputer di jaringan yang terhubung. Anda harus memastikan bahwa grup keamanan pesawat kendali Amazon EKS Anda berisi aturan yang mengizinkan lalu lintas masuk di port 443 dari jaringan terhubung milik Anda.
**Tuan rumah EC2 benteng Amazon**
Anda dapat meluncurkan EC2 instans Amazon ke subnet publik di VPC klaster Anda dan kemudian masuk melalui SSH ke instance tersebut untuk menjalankan perintah. `kubectl` Untuk informasi selengkapnya, lihat [Linux bastion host di AWS](https://aws.amazon.com/quickstart/architecture/linux-bastion/). Anda harus memastikan bahwa grup keamanan pesawat kendali Amazon EKS Anda berisi aturan yang mengizinkan lalu lintas masuk di port 443 dari host bastion milik Anda. Untuk informasi selengkapnya, lihat [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md).
Saat Anda mengonfigurasi `kubectl` untuk host bastion Anda, pastikan untuk menggunakan AWS kredenal yang sudah dipetakan ke konfigurasi RBAC cluster Anda, atau tambahkan [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang akan digunakan bastion Anda ke konfigurasi RBAC sebelum Anda menghapus akses publik titik akhir. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md) dan [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized).
** AWS Cloud9 IDE**
AWS Cloud9 adalah lingkungan pengembangan terintegrasi berbasis cloud (IDE) yang memungkinkan Anda menulis, menjalankan, dan men-debug kode Anda hanya dengan browser. Anda dapat membuat AWS Cloud9 IDE di VPC klaster Anda dan menggunakan IDE untuk berkomunikasi dengan cluster Anda. Untuk informasi selengkapnya, lihat [Membuat lingkungan di AWS Cloud9](https://docs.aws.amazon.com/cloud9/latest/user-guide/create-environment.html). Anda harus memastikan bahwa grup keamanan pesawat kendali Amazon EKS Anda berisi aturan yang mengizinkan lalu lintas masuk di port 443 dari grup keamanan IDE milik Anda. Untuk informasi selengkapnya, lihat [Lihat persyaratan grup keamanan Amazon EKS untuk cluster](sec-group-reqs.md).
Saat Anda mengonfigurasi `kubectl` untuk AWS Cloud9 IDE, pastikan untuk AWS menggunakan kredensional yang sudah dipetakan ke konfigurasi RBAC klaster Anda, atau tambahkan prinsip IAM yang akan digunakan IDE Anda ke konfigurasi RBAC sebelum Anda menghapus akses publik titik akhir. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna dan peran IAM ke Kubernetes APIs](grant-k8s-access.md) dan [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized).
📝 [Edit halaman ini di GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23cluster-endpoint%5D&type=code)
# Konfigurasikan akses jaringan ke titik akhir server API cluster
Anda dapat memodifikasi akses endpoint server API cluster menggunakan Konsol Manajemen AWS atau AWS CLI di bagian berikut.
## Konfigurasikan akses titik akhir - konsol AWS
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama klaster untuk menampilkan informasi klaster Anda.
1. Pilih tab **Jaringan** dan pilih **Kelola akses titik akhir**.
1. Untuk **akses Pribadi**, pilih apakah akan mengaktifkan atau menonaktifkan akses pribadi untuk titik akhir server Kubernetes API klaster Anda. Jika Anda mengaktifkan akses pribadi, permintaan Kubernetes API yang berasal dari dalam VPC klaster Anda menggunakan titik akhir VPC pribadi. Anda harus mengaktifkan akses privat untuk menonaktifkan akses publik.
1. Untuk **akses Publik**, pilih apakah akan mengaktifkan atau menonaktifkan akses publik untuk titik akhir server Kubernetes API klaster Anda. Jika Anda menonaktifkan akses publik, server Kubernetes API klaster Anda hanya dapat menerima permintaan dari dalam VPC klaster.
1. (Opsional) Jika Anda telah mengaktifkan **akses Publik**, Anda dapat menentukan alamat mana dari internet yang dapat berkomunikasi ke titik akhir publik. Pilih **Pengaturan lanjutan**. Masukkan blok CIDR, seperti*203.0.113.5/32*. Blok tidak dapat mencakup [reserved addresses](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Anda dapat memasukkan blok tambahan dengan memilih **Tambahkan sumber**. Ada jumlah maksimum blok CIDR yang dapat Anda tentukan. Untuk informasi selengkapnya, lihat [Lihat dan kelola kuota layanan Amazon EKS dan Fargate](service-quotas.md). Jika Anda menetapkan tidak ada blok, maka titik akhir server API publik menerima permintaan dari semua alamat IP untuk keduanya `IPv4` (`0.0.0.0/0`) dan tambahan `IPv6` (`::/0`) untuk cluster dual-stack`IPv6`. Jika Anda membatasi akses ke titik akhir publik Anda menggunakan blok CIDR, kami sarankan Anda juga mengaktifkan akses endpoint pribadi sehingga node dan Fargate Pods (jika Anda menggunakannya) dapat berkomunikasi dengan cluster. Tanpa mengaktifkan titik akhir privat, sumber CIDR titik akhir akses publik Anda harus menyertakan sumber keluar dari VPC Anda. Misalnya, jika Anda memiliki simpul di subnet privat yang berkomunikasi dengan internet melalui NAT Gateway, Anda perlu menambahkan alamat IP keluar dari NAT Gateway sebagai bagian dari blok CIDR yang diizinkan di titik akhir publik Anda.
1. Pilih **Perbarui** untuk menyelesaikan.
## Konfigurasikan akses titik akhir - AWS CLI
Selesaikan langkah-langkah berikut menggunakan versi AWS CLI `1.27.160` atau yang lebih baru. Anda dapat memeriksa versi saat ini dengan `aws --version`. Untuk menginstal atau meningkatkan AWS CLI, lihat [Menginstal CLI AWS](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html).
1. Perbarui akses endpoint server API cluster Anda dengan perintah AWS CLI berikut. Gantikan nama klaster Anda dan nilai akses titik akhir yang diinginkan. Jika Anda mengatur `endpointPublicAccess=true`, maka Anda dapat (opsional) memasukkan satu blok CIDR, atau daftar blok CIDR yang dipisahkan koma untuk `publicAccessCidrs`. Blok tidak dapat mencakup [alamat yang disimpan](https://en.wikipedia.org/wiki/Reserved_IP_addresses). Jika Anda menentukan blok CIDR, maka titik akhir server API publik hanya akan menerima permintaan dari blok yang terdaftar. Ada jumlah maksimum blok CIDR yang dapat Anda tentukan. Untuk informasi selengkapnya, lihat [Lihat dan kelola kuota layanan Amazon EKS dan Fargate](service-quotas.md). Jika Anda membatasi akses ke titik akhir publik Anda menggunakan blok CIDR, disarankan agar Anda juga mengaktifkan akses endpoint pribadi sehingga node dan Fargate Pods (jika Anda menggunakannya) dapat berkomunikasi dengan cluster. Tanpa mengaktifkan titik akhir privat, sumber CIDR titik akhir akses publik Anda harus menyertakan sumber keluar dari VPC Anda. Misalnya, jika Anda memiliki simpul di subnet privat yang berkomunikasi dengan internet melalui NAT Gateway, Anda perlu menambahkan alamat IP keluar dari NAT Gateway sebagai bagian dari blok CIDR yang diizinkan di titik akhir publik Anda. Jika Anda menentukan tidak ada blok CIDR, maka titik akhir server API publik menerima permintaan dari semua alamat IP (0.0.0.0/0) dan tambahan `IPv6` () untuk cluster dual-stack. `::/0` `IPv6`
**catatan**
Perintah berikut memungkinkan akses privat dan akses publik dari satu alamat IP untuk titik akhir server API. Ganti *203.0.113.5/32* dengan satu blok CIDR, atau daftar blok CIDR yang dipisahkan koma yang ingin Anda batasi akses jaringan.
```
aws eks update-cluster-config \
--region region-code \
--name my-cluster \
--resources-vpc-config endpointPublicAccess=true,publicAccessCidrs="203.0.113.5/32",endpointPrivateAccess=true
```
Contoh output adalah sebagai berikut.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "InProgress",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
1. Pantau status pembaruan akses titik akhir Anda dengan perintah berikut, menggunakan nama klaster dan ID pembaruan yang dikembalikan oleh perintah sebelumnya. Pembaruan Anda selesai saat status ditampilkan sebagai `Successful`.
```
aws eks describe-update \
--region region-code \
--name my-cluster \
--update-id e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000
```
Contoh output adalah sebagai berikut.
```
{
"update": {
"id": "e6f0905f-a5d4-4a2a-8c49-EXAMPLE00000",
"status": "Successful",
"type": "EndpointAccessUpdate",
"params": [
{
"type": "EndpointPublicAccess",
"value": "true"
},
{
"type": "EndpointPrivateAccess",
"value": "true"
},
{
"type": "publicAccessCidrs",
"value": "[\"203.0.113.5/32\"]"
}
],
"createdAt": 1576874258.137,
"errors": []
}
}
```
📝 [Edit halaman ini di GitHub](https://github.com/search?q=repo%3Aawsdocs%2Famazon-eks-user-guide+%5B%23config-cluster-endpoint%5D&type=code)
# Menerapkan node Windows pada kluster EKS
Pelajari cara mengaktifkan dan mengelola dukungan Windows untuk klaster Amazon EKS Anda untuk menjalankan container Windows bersama container Linux.
## Pertimbangan-pertimbangan
Sebelum men-deploy simpul Windows, perhatikan pertimbangan-pertimbangan berikut.
+ Mode Otomatis EKS tidak mendukung node Windows
+ Anda dapat menggunakan jaringan host pada node Windows menggunakan `HostProcess` Pod. Untuk informasi selengkapnya, lihat [Membuat Windows HostProcessPod](https://kubernetes.io/docs/tasks/configure-pod-container/create-hostprocess-pod/) di dokumentasi Kubernetes.
+ Cluster Amazon EKS harus berisi satu atau lebih node Linux atau Fargate untuk menjalankan Pod sistem inti yang hanya berjalan di Linux, seperti CoreDNS.
+ Log `kube-proxy` peristiwa `kubelet` dan diarahkan ke Log `EKS Windows` Peristiwa dan diatur ke batas 200 MB.
+ Anda tidak dapat menggunakan [Tetapkan grup keamanan ke pod individual dengan Pod](security-groups-for-pods.md) yang berjalan di node Windows.
+ Anda tidak dapat menggunakan [jaringan khusus](cni-custom-network.md) dengan node Windows.
+ Anda tidak dapat menggunakan `IPv6` dengan node Windows.
+ Simpul Windows mendukung satu antarmuka jaringan elastis per simpul. Secara default, jumlah Pod yang dapat Anda jalankan per node Windows sama dengan jumlah alamat IP yang tersedia per elastic network interface untuk jenis instance node, minus satu. Untuk informasi selengkapnya, lihat [alamat IP per antarmuka jaringan per jenis instans](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/using-eni.html#AvailableIpPerENI) di *Panduan EC2 Pengguna Amazon*.
+ Dalam klaster Amazon EKS, satu layanan dengan load balancer dapat mendukung hingga 1024 Pod back-end. Setiap Pod memiliki alamat IP uniknya sendiri. Batas sebelumnya 64 Pod tidak lagi terjadi, setelah [pembaruan Windows Server](https://github.com/microsoft/Windows-Containers/issues/93) dimulai dengan [OS Build 17763.2746](https://support.microsoft.com/en-us/topic/march-22-2022-kb5011551-os-build-17763-2746-preview-690a59cd-059e-40f4-87e8-e9139cc65de4).
+ Kontainer Windows tidak didukung untuk Pod Amazon EKS di Fargate.
+ Anda tidak dapat menggunakan Amazon EKS Hybrid Nodes dengan Windows sebagai sistem operasi untuk host.
+ Anda tidak dapat mengambil log dari `vpc-resource-controller` Pod. Anda sebelumnya bisa ketika Anda menyebarkan pengontrol ke bidang data.
+ Ada periode pendinginan sebelum `IPv4` alamat ditetapkan ke Pod baru. Hal ini mencegah lalu lintas mengalir ke Pod lama dengan `IPv4` alamat yang sama karena `kube-proxy` aturan basi.
+ Sumber untuk pengontrol dikelola pada GitHub. Untuk berkontribusi, atau mengajukan masalah terhadap pengontrol, kunjungi [proyek](https://github.com/aws/amazon-vpc-resource-controller-k8s) di GitHub.
+ Saat menentukan ID AMI khusus untuk grup node terkelola Windows, tambahkan `eks:kube-proxy-windows` ke peta konfigurasi AWS IAM Authenticator Anda. Untuk informasi selengkapnya, lihat [Batas dan ketentuan saat menentukan ID AMI](launch-templates.md#mng-ami-id-conditions).
+ Jika menjaga IPv4 alamat yang tersedia sangat penting untuk subnet Anda, lihat [Panduan Praktik Terbaik EKS - Manajemen Alamat IP Jaringan Windows](https://aws.github.io/aws-eks-best-practices/windows/docs/networking/#ip-address-management) untuk panduan.
+ Pertimbangan untuk Entri Akses EKS
+ Akses Entri untuk digunakan dengan node Windows memerlukan jenis. `EC2_WINDOWS` Untuk informasi selengkapnya, lihat [Buat entri akses](creating-access-entries.md).
Untuk membuat entri akses untuk node Windows:
```
aws eks create-access-entry --cluster-name my-cluster --principal-arn arn:aws: iam::111122223333:role/ --type EC2_Windows
```
## Prasyarat
+ Sebuah klaster yang sudah ada.
+ Cluster Anda harus memiliki setidaknya satu (kami sarankan setidaknya dua) node Linux atau Fargate Pod untuk menjalankan CoreDNS. Jika Anda mengaktifkan dukungan Windows lama, Anda harus menggunakan node Linux (Anda tidak dapat menggunakan Fargate Pod) untuk menjalankan CoreDNS.
+ Peran [IAM cluster Amazon EKS](cluster-iam-role.md) yang ada.
## Aktifkan dukungan Windows
1. Jika Anda tidak memiliki node Amazon Linux di klaster dan menggunakan grup keamanan untuk Pod, lanjutkan ke langkah berikutnya. Jika tidak, konfirmasikan bahwa kebijakan `AmazonEKSVPCResourceController` terkelola dilampirkan ke [peran klaster](cluster-iam-role.md) Anda. Ganti *eksClusterRole* dengan nama peran cluster Anda.
```
aws iam list-attached-role-policies --role-name eksClusterRole
```
Contoh output adalah sebagai berikut.
```
{
"AttachedPolicies": [
{
"PolicyName": "AmazonEKSClusterPolicy",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSClusterPolicy"
},
{
"PolicyName": "AmazonEKSVPCResourceController",
"PolicyArn": "arn:aws: iam::aws:policy/AmazonEKSVPCResourceController"
}
]
}
```
Jika kebijakan dilampirkan, seperti pada output sebelumnya, lewati langkah berikutnya.
1. Lampirkan kebijakan terkelola **[EKSVPCResourcePengontrol Amazon](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSVPCResourceController.html)** ke [peran IAM klaster Amazon EKS](cluster-iam-role.md) Anda. Ganti *eksClusterRole* dengan nama peran cluster Anda.
```
aws iam attach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
```
1. Perbarui VPC CNI ConfigMap untuk mengaktifkan Windows IPAM. Catatan, jika VPC CNI diinstal pada klaster Anda menggunakan bagan Helm atau sebagai Add-on Amazon EKS, Anda mungkin tidak dapat langsung memodifikasi. ConfigMap Untuk informasi tentang mengonfigurasi Add-on Amazon EKS, lihat. [Tentukan bidang yang dapat Anda sesuaikan untuk add-on Amazon EKS](kubernetes-field-management.md)
1. Buat file bernama *vpc-resource-controller-configmap.yaml* dengan isi berikut ini.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-windows-ipam: "true"
```
1. Terapkan `ConfigMap` ke cluster Anda.
```
kubectl apply -f vpc-resource-controller-configmap.yaml
```
1. Jika cluster Anda memiliki mode otentikasi yang disetel untuk mengaktifkan `aws-auth` configmap:
+ Verifikasi bahwa Anda `aws-auth` `ConfigMap` berisi pemetaan untuk peran instance node Windows untuk menyertakan grup izin `eks:kube-proxy-windows` RBAC. Anda dapat memverifikasi dengan menjalankan perintah berikut.
```
kubectl get configmap aws-auth -n kube-system -o yaml
```
Contoh output adalah sebagai berikut.
```
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- groups:
- system:bootstrappers
- system:nodes
- eks:kube-proxy-windows # This group is required for Windows DNS resolution to work
rolearn: arn:aws: iam::111122223333:role/eksNodeRole
username: system:node:{{EC2PrivateDNSName}}
[...]
```
Anda harus melihat `eks:kube-proxy-windows` terdaftar di bawah grup. Jika grup tidak ditentukan, Anda perlu memperbarui `ConfigMap` atau membuatnya untuk menyertakan grup yang diperlukan. Untuk informasi lebih lanjut tentang `aws-auth``ConfigMap`, lihat[Terapkan `aws-auth` `ConfigMap` ke cluster Anda](auth-configmap.md#aws-auth-configmap).
1. Jika cluster Anda memiliki mode otentikasi yang disetel untuk menonaktifkan `aws-auth` configmap, maka Anda dapat menggunakan Entri Akses EKS. Buat peran node baru untuk digunakan dengan instance Windows, dan EKS akan secara otomatis membuat entri akses tipe`EC2_WINDOWS`.
## Menerapkan Pod Windows
Saat Anda menerapkan Pod ke klaster Anda, Anda perlu menentukan sistem operasi yang mereka gunakan jika Anda menjalankan campuran tipe node.
Untuk Pod Linux, gunakan teks pemilih node berikut dalam manifes Anda.
```
nodeSelector:
kubernetes.io/os: linux
kubernetes.io/arch: amd64
```
Untuk Pod Windows, gunakan teks pemilih node berikut dalam manifes Anda.
```
nodeSelector:
kubernetes.io/os: windows
kubernetes.io/arch: amd64
```
Anda dapat menerapkan [aplikasi sampel](sample-deployment.md) untuk melihat pemilih node yang digunakan.
## Mendukung kepadatan Pod yang lebih tinggi pada node Windows
Di Amazon EKS, setiap Pod dialokasikan `IPv4` alamat dari VPC Anda. Karena hal ini, jumlah Pod yang dapat Anda deploy ke sebuah node dibatasi oleh alamat IP yang tersedia, bahkan jika ada sumber daya yang cukup untuk menjalankan lebih banyak Pod pada node. Karena hanya satu elastic network interface yang didukung oleh node Windows, secara default, jumlah maksimum alamat IP yang tersedia pada node Windows sama dengan:
```
Number of private IPv4 addresses for each interface on the node - 1
```
Satu alamat IP digunakan sebagai alamat IP utama dari antarmuka jaringan, sehingga tidak dapat dialokasikan ke Pod.
Anda dapat mengaktifkan kepadatan Pod yang lebih tinggi pada node Windows dengan mengaktifkan delegasi awalan IP. Fitur ini memungkinkan Anda untuk menetapkan `/28` `IPv4` awalan ke antarmuka jaringan utama, bukan menetapkan alamat sekunder. `IPv4` Menetapkan awalan IP meningkatkan `IPv4` alamat maksimum yang tersedia pada node menjadi:
```
(Number of private IPv4 addresses assigned to the interface attached to the node - 1) * 16
```
Dengan jumlah alamat IP yang tersedia secara signifikan lebih besar ini, alamat IP yang tersedia seharusnya tidak membatasi kemampuan Anda untuk menskalakan jumlah Pod pada node Anda. Lihat informasi yang lebih lengkap di [Tetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md).
# Nonaktifkan dukungan Windows
1. Jika klaster Anda berisi node Amazon Linux dan Anda menggunakan [grup keamanan untuk Pod](security-groups-for-pods.md) bersamanya, lewati langkah ini.
Hapus kebijakan IAM `AmazonVPCResourceController` terkelola dari [peran klaster](cluster-iam-role.md) Anda. Ganti *eksClusterRole* dengan nama peran cluster Anda.
```
aws iam detach-role-policy \
--role-name eksClusterRole \
--policy-arn arn:aws: iam::aws:policy/AmazonEKSVPCResourceController
```
1. Nonaktifkan Windows IPAM di. `amazon-vpc-cni` ConfigMap
```
kubectl patch configmap/amazon-vpc-cni \
-n kube-system \
--type merge \
-p '{"data":{"enable-windows-ipam":"false"}}'
```
# Menyebarkan kluster pribadi dengan akses internet terbatas
Topik ini menjelaskan cara menerapkan kluster Amazon EKS yang diterapkan di AWS Cloud, tetapi tidak memiliki akses internet keluar. Jika Anda memiliki cluster lokal di AWS Outposts, lihat[Buat node Amazon Linux di AWS Outposts](eks-outposts-self-managed-nodes.md), bukan topik ini.
Jika Anda tidak terbiasa dengan jaringan Amazon EKS, lihat [De-mystifying jaringan cluster untuk node pekerja Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Jika klaster Anda tidak memiliki akses internet keluar, maka klaster harus memenuhi persyaratan berikut:
## Persyaratan arsitektur cluster
+ Cluster Anda harus menarik gambar dari registri kontainer yang ada di VPC Anda. Anda dapat membuat Amazon Elastic Container Registry di VPC Anda dan menyalin gambar kontainer ke sana untuk diambil node Anda. Untuk informasi selengkapnya, lihat [Salin gambar kontainer dari satu repositori ke repositori lain](copy-image-to-repository.md).
+ Cluster Anda harus mengaktifkan akses pribadi endpoint. Hal ini diperlukan untuk node untuk mendaftar dengan endpoint cluster. titik akhir akses publik adalah opsional. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
## Persyaratan node
+ Node Linux dan Windows yang dikelola sendiri harus menyertakan argumen bootstrap berikut sebelum diluncurkan. Argumen ini melewati introspeksi Amazon EKS dan tidak memerlukan akses ke Amazon EKS API dari dalam VPC.
1. Tentukan nilai endpoint cluster Anda dengan perintah berikut. Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
Contoh output adalah sebagai berikut.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Tentukan nilai otoritas sertifikat klaster Anda dengan perintah berikut. Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
Output yang dikembalikan adalah string panjang.
1. Ganti nilai `apiServerEndpoint` dan `certificateAuthority` di NodeConfig objek dengan nilai yang dikembalikan dalam output dari perintah sebelumnya. Untuk informasi selengkapnya tentang menentukan argumen bootstrap saat meluncurkan node Amazon Linux 2023 yang dikelola sendiri, lihat dan. [Buat node Amazon Linux yang dikelola sendiri](launch-workers.md) [Buat node Microsoft Windows yang dikelola sendiri](launch-windows-workers.md)
+ Untuk node Linux:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Untuk argumen tambahan, lihat [skrip bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) pada GitHub.
+ Untuk node Windows:
**catatan**
Jika Anda menggunakan layanan khusus CIDR, maka Anda perlu menentukannya menggunakan `-ServiceCIDR` parameter. Jika tidak, resolusi DNS untuk Pod di cluster akan gagal.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Untuk argumen tambahan, lihat[Parameter konfigurasi skrip bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ Cluster Anda `aws-auth` `ConfigMap` harus dibuat dari dalam VPC Anda. Untuk informasi selengkapnya tentang membuat dan menambahkan entri ke `aws-auth``ConfigMap`, masukkan `eksctl create iamidentitymapping --help` di terminal Anda. Jika `ConfigMap` tidak ada di server Anda, `eksctl` akan membuatnya ketika Anda menggunakan perintah untuk menambahkan pemetaan identitas.
## Persyaratan pod
+ **Pod Identity** - Pod yang dikonfigurasi dengan EKS Pod Identity memperoleh kredensyal dari EKS Auth API. Jika tidak ada akses internet keluar, Anda harus membuat dan menggunakan titik akhir VPC untuk EKS Auth API:. `com.amazonaws.region-code.eks-auth` Untuk informasi lebih lanjut tentang titik akhir VPC EKS dan EKS Auth, lihat. [Akses Amazon EKS menggunakan AWS PrivateLink](vpc-interface-endpoints.md)
+ **IRSA** - Pod yang dikonfigurasi dengan [peran IAM untuk akun layanan](iam-roles-for-service-accounts.md) memperoleh kredensyal dari panggilan API AWS Security Token Service (AWS STS). Jika tidak ada akses internet keluar, Anda harus membuat dan menggunakan titik akhir VPC AWS STS di VPC Anda. Sebagian besar AWS `v1` SDKs menggunakan endpoint AWS STS global secara default (`sts.amazonaws.com`), yang tidak menggunakan titik akhir AWS STS VPC. Untuk menggunakan titik akhir VPC AWS STS, Anda mungkin perlu mengonfigurasi SDK Anda untuk menggunakan endpoint AWS STS regional (). `sts.region-code.amazonaws.com` Untuk informasi selengkapnya, lihat [Konfigurasikan titik akhir Layanan Token AWS Keamanan untuk akun layanan](configure-sts-endpoint.md).
+ Subnet VPC klaster Anda harus memiliki titik akhir antarmuka VPC untuk AWS layanan apa pun yang perlu diakses oleh Pod Anda. Untuk informasi selengkapnya, lihat [Mengakses AWS layanan menggunakan titik akhir VPC antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Beberapa layanan dan titik akhir yang umum digunakan tercantum dalam tabel berikut. Untuk daftar lengkap titik akhir, lihat [AWS layanan yang terintegrasi dengan AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) dalam [AWS PrivateLink Panduan](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Kami menyarankan Anda [mengaktifkan nama DNS pribadi](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) untuk titik akhir VPC Anda, sehingga beban kerja dapat terus menggunakan titik akhir layanan AWS publik tanpa masalah.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/private-clusters.html)
+ Setiap node yang dikelola sendiri harus disebarkan ke subnet yang memiliki titik akhir antarmuka VPC yang Anda butuhkan. Jika Anda membuat grup node terkelola, grup keamanan titik akhir antarmuka VPC harus mengizinkan CIDR untuk subnet, atau Anda harus menambahkan grup keamanan node yang dibuat ke grup keamanan titik akhir antarmuka VPC.
+ **EFS storage** - Jika Pod Anda menggunakan volume Amazon EFS, maka sebelum menerapkan [sistem file elastis Store dengan Amazon EFS](efs-csi.md), file [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) driver harus diubah untuk mengatur image container agar menggunakan Region AWS yang sama dengan cluster Amazon EKS.
+ Route53 tidak mendukung. AWS PrivateLink Anda tidak dapat mengelola catatan DNS Route53 dari kluster Amazon EKS pribadi. [Ini berdampak pada Kubernetes external-dns.](https://github.com/kubernetes-sigs/external-dns)
+ Jika Anda menggunakan AMI EKS Optimized, Anda harus mengaktifkan `ec2` endpoint pada tabel di atas. Atau, Anda dapat secara manual mengatur nama DNS Node. AMI yang dioptimalkan digunakan EC2 APIs untuk mengatur nama DNS node secara otomatis.
+ Anda dapat menggunakan [AWS Load Balancer Controller](aws-load-balancer-controller.md) untuk menyebarkan AWS Application Load Balancers (ALB) dan Network Load Balancer ke cluster pribadi Anda. Saat menerapkannya, Anda harus menggunakan [flag baris perintah](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) untuk mengatur`enable-shield`,`enable-waf`, dan `enable-wafv2` ke false. [Penemuan sertifikat](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) dengan nama host dari objek Ingress tidak didukung. Ini karena pengontrol perlu mencapai AWS Certificate Manager, yang tidak memiliki titik akhir antarmuka VPC.
Pengendali yang didukung pada penyeimbang beban jaringan dengan target IP, yang diperlukan untuk penggunaan pada Fargate. Untuk informasi selengkapnya, lihat [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md) dan [Buat penyeimbang beban jaringan](network-load-balancing.md#network-load-balancer).
+ [Cluster Autoscaler didukung.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Saat menerapkan Cluster Autoscaler Pod, pastikan bahwa baris perintah termasuk. `--aws-use-static-instance-list=true` Untuk informasi selengkapnya, lihat [Menggunakan Daftar Instans Statis](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) pada GitHub. VPC node pekerja juga harus menyertakan titik akhir VPC STS dan titik akhir AWS VPC penskalaan otomatis.
+ Beberapa produk perangkat lunak kontainer menggunakan panggilan API yang mengakses AWS Marketplace Metering Service untuk memantau penggunaan. Cluster pribadi tidak mengizinkan panggilan ini, jadi Anda tidak dapat menggunakan jenis penampung ini di kluster pribadi.
# Komputasi klaster skala dengan Karpenter dan Cluster Autoscaler
Autoscaling adalah fungsi yang secara otomatis mengukur sumber daya Anda keluar dan masuk untuk memenuhi permintaan yang berubah. Ini adalah fungsi utama Kubernetes yang seharusnya membutuhkan sumber daya manusia yang luas untuk bekerja secara manual.
## Mode Otomatis EKS
Mode Otomatis Amazon EKS secara otomatis menskalakan sumber daya komputasi klaster. Jika sebuah pod tidak dapat masuk ke node yang ada, Mode Otomatis EKS akan membuat yang baru. Mode Otomatis EKS juga mengkonsolidasikan beban kerja dan menghapus node. Mode Otomatis EKS dibangun di atas Karpenter.
Untuk informasi selengkapnya, lihat:
+ [Mengotomatiskan infrastruktur klaster dengan Mode Otomatis EKS](automode.md)
+ [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md)
+ [Menerapkan sampel beban kerja inflate ke klaster Mode Otomatis Amazon EKS](automode-workload.md)
## Solusi Tambahan
Amazon EKS mendukung dua produk penskalaan otomatis tambahan:
**Karpenter**
Karpenter adalah autoscaler cluster Kubernetes yang fleksibel dan berkinerja tinggi yang membantu meningkatkan ketersediaan aplikasi dan efisiensi klaster. Karpenter meluncurkan sumber daya komputasi berukuran tepat (misalnya, EC2 instans Amazon) sebagai respons terhadap perubahan beban aplikasi dalam waktu kurang dari satu menit. Dengan mengintegrasikan Kubernetes dengan Kubernetes AWS, Karpenter dapat menyediakan sumber daya just-in-time komputasi yang secara tepat memenuhi persyaratan beban kerja Anda. Karpenter secara otomatis menyediakan sumber daya komputasi baru berdasarkan persyaratan spesifik beban kerja cluster. Ini termasuk persyaratan komputasi, penyimpanan, akselerasi, dan penjadwalan. Amazon EKS mendukung cluster menggunakan Karpenter, meskipun Karpenter bekerja dengan klaster Kubernetes yang sesuai. Untuk informasi lebih lanjut, lihat dokumentasi [Karpenter](https://karpenter.sh/docs/).
Karpenter adalah perangkat lunak open-source yang AWS pelanggan bertanggung jawab untuk menginstal, mengonfigurasi, dan mengelola di klaster Kubernetes mereka. AWS memberikan dukungan teknis saat Karpenter dijalankan tanpa dimodifikasi menggunakan versi yang kompatibel di kluster Amazon EKS. Sangat penting bahwa pelanggan menjaga ketersediaan dan keamanan pengontrol Karpenter serta prosedur pengujian yang tepat saat memutakhirkannya atau cluster Kubernetes di mana ia berjalan, sama seperti perangkat lunak yang dikelola pelanggan lainnya. Tidak ada Perjanjian Tingkat AWS Layanan (SLA) untuk Karpenter dan pelanggan bertanggung jawab untuk memastikan bahwa EC2 instans yang diluncurkan oleh Karpenter memenuhi persyaratan bisnis mereka.
**Cluster Autoscaler**
Kubernetes Autoscaler Klaster secara otomatis menyesuaikan jumlah simpul di klaster Anda ketika pod gagal atau dijadwal ulang ke simpul lain. Cluster Autoscaler menggunakan grup Auto Scaling. Untuk informasi selengkapnya, lihat [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) di. AWS
# Pelajari tentang pergeseran zona Amazon Application Recovery Controller (ARC) di Amazon EKS
Kubernetes memiliki fitur asli yang memungkinkan Anda membuat aplikasi Anda lebih tahan terhadap peristiwa seperti penurunan kesehatan atau gangguan Availability Zone (AZ). [Saat menjalankan beban kerja di klaster Amazon EKS, Anda dapat lebih meningkatkan toleransi kesalahan lingkungan aplikasi dan pemulihan aplikasi dengan menggunakan pergeseran zona [Amazon Application Recovery Controller (ARC) atau pergeseran otomatis zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.html).](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.html) Pergeseran zona ARC dirancang untuk menjadi tindakan sementara yang memungkinkan Anda memindahkan lalu lintas untuk sumber daya dari AZ yang rusak hingga pergeseran zona berakhir atau Anda membatalkannya. Anda dapat memperpanjang pergeseran zona, jika perlu.
Anda dapat memulai pergeseran zona untuk kluster EKS, atau Anda dapat mengizinkan AWS untuk menggeser lalu lintas untuk Anda dengan mengaktifkan pergeseran otomatis zona. Pergeseran ini memperbarui alur lalu lintas east-to-west jaringan di klaster Anda untuk hanya mempertimbangkan titik akhir jaringan untuk Pod yang berjalan di node pekerja dalam keadaan sehat AZs. Selain itu, ALB atau NLB apa pun yang menangani lalu lintas masuk untuk aplikasi di kluster EKS Anda akan secara otomatis merutekan lalu lintas ke target yang sehat. AZs Bagi pelanggan yang mencari tujuan ketersediaan tertinggi, jika AZ menjadi terganggu, penting untuk dapat mengarahkan semua lalu lintas dari AZ yang rusak hingga pulih. Untuk ini, Anda juga dapat [https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html) zonal shift.
## Memahami arus lalu lintas jaringan timur-barat antar Pod
Diagram berikut menggambarkan dua contoh beban kerja, Pesanan, dan Produk. Tujuan dari contoh ini adalah untuk menunjukkan bagaimana beban kerja dan Pod dalam AZs komunikasi yang berbeda.
![\[Ilustrasi lalu lintas jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-traffic-flow-before-1.png)
![\[Ilustrasi lalu lintas jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-traffic-flow-before-2.png)
1. Agar Pesanan dapat berkomunikasi dengan Produk, Pesanan harus terlebih dahulu menyelesaikan nama DNS dari layanan tujuan. Pesanan berkomunikasi dengan CoreDNS untuk mengambil alamat IP virtual (Cluster IP) untuk layanan itu. Setelah Pesanan menyelesaikan nama layanan Produk, ia mengirimkan lalu lintas ke alamat IP target tersebut.
1. Kube-proxy berjalan pada setiap node di cluster dan terus mengawasi [EndpointSlices](https://kubernetes.io/docs/concepts/services-networking/endpoint-slices/)layanan. Ketika layanan dibuat, sebuah EndpointSlice dibuat dan dikelola di latar belakang oleh EndpointSlice pengontrol. Masing-masing EndpointSlice memiliki daftar atau tabel titik akhir yang berisi subset alamat Pod, bersama dengan node yang mereka jalankan. Kube-proxy mengatur aturan routing untuk masing-masing titik akhir Pod yang digunakan pada node. `iptables` Kube-proxy juga bertanggung jawab untuk bentuk dasar load balancing, mengarahkan lalu lintas yang ditujukan ke alamat IP Cluster layanan untuk dikirim ke alamat IP Pod secara langsung. Kube-proxy melakukan ini dengan menulis ulang alamat IP tujuan pada koneksi keluar.
1. Paket jaringan kemudian dikirim ke Products Pod di AZ 2 dengan menggunakan ENIs pada node masing-masing, seperti yang ditunjukkan pada diagram sebelumnya.
### Memahami pergeseran zona ARC di Amazon EKS
Jika ada gangguan AZ di lingkungan Anda, Anda dapat memulai pergeseran zona untuk lingkungan cluster EKS Anda. Atau, Anda dapat mengizinkan AWS untuk mengelola lalu lintas yang bergeser untuk Anda dengan zonal autoshift. Dengan pergeseran otomatis zona, AWS memantau kesehatan AZ secara keseluruhan dan merespons potensi gangguan AZ dengan secara otomatis mengalihkan lalu lintas dari AZ yang terganggu di lingkungan klaster Anda.
Setelah klaster Amazon EKS Anda mengaktifkan pergeseran zona dengan ARC, Anda dapat memulai pergeseran zona atau mengaktifkan pergeseran otomatis zona dengan menggunakan Konsol ARC, AWS CLI, atau pergeseran zona dan pergeseran otomatis zona. APIs Selama pergeseran zona EKS, berikut ini dilakukan secara otomatis:
+ Semua node di AZ yang terkena dampak ditutup. Hal ini mencegah Kubernetes Scheduler menjadwalkan Pod baru ke node di AZ yang tidak sehat.
+ Jika Anda menggunakan [Grup Node Terkelola](managed-node-groups.md), [https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-benefits.html#AutoScalingBehavior.InstanceUsage) ditangguhkan, dan grup Auto Scaling Anda diperbarui untuk memastikan bahwa node pesawat data EKS baru hanya diluncurkan dalam keadaan sehat. AZs
+ Node di AZ yang tidak sehat tidak dihentikan, dan Pod tidak diusir dari node. Ini memastikan bahwa ketika pergeseran zona berakhir atau dibatalkan, lalu lintas Anda dapat dikembalikan dengan aman ke AZ untuk kapasitas penuh.
+ EndpointSlice Pengontrol menemukan semua titik akhir Pod di AZ yang rusak, dan menghapusnya dari yang relevan EndpointSlices. Ini memastikan bahwa hanya titik akhir Pod yang sehat yang AZs ditargetkan untuk menerima lalu lintas jaringan. Ketika pergeseran zona dibatalkan atau kedaluwarsa, EndpointSlice pengontrol memperbarui EndpointSlices untuk menyertakan titik akhir di AZ yang dipulihkan.
Diagram berikut memberikan gambaran tingkat tinggi tentang bagaimana pergeseran zona EKS memastikan bahwa hanya titik akhir Pod yang sehat yang ditargetkan di lingkungan klaster Anda.
![\[Ilustrasi lalu lintas jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-traffic-flow-after-1.png)
![\[Ilustrasi lalu lintas jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-traffic-flow-after-2.png)
## Persyaratan pergeseran zona EKS
Agar pergeseran zona berhasil bekerja dengan EKS, Anda harus mengatur lingkungan cluster Anda sebelumnya agar tahan terhadap gangguan AZ. Berikut ini adalah daftar opsi konfigurasi yang membantu memastikan ketahanan.
+ Menyediakan node pekerja klaster Anda di beberapa AZs
+ Menyediakan kapasitas komputasi yang cukup untuk mengakomodasi penghapusan AZ tunggal
+ Pra-skala Pod Anda, termasuk CoreDNS, di setiap AZ
+ Sebarkan beberapa replika Pod di semua AZs, untuk membantu memastikan bahwa ketika Anda beralih dari satu AZ, Anda masih akan memiliki kapasitas yang cukup
+ Kolokasi Pod yang saling bergantung atau terkait di AZ yang sama
+ Uji apakah lingkungan cluster Anda berfungsi seperti yang diharapkan tanpa satu AZ dengan memulai pergeseran zona secara manual dari AZ. Atau, Anda dapat mengaktifkan pergeseran otomatis zona dan mengandalkan latihan autoshift. Pengujian dengan pergeseran zona manual atau praktik tidak diperlukan agar pergeseran zona bekerja di EKS tetapi sangat disarankan.
### Menyediakan node pekerja EKS Anda di beberapa Availability Zone
AWS Wilayah memiliki beberapa lokasi terpisah dengan pusat data fisik, yang dikenal sebagai Availability Zones (AZs). AZs dirancang untuk secara fisik terisolasi satu sama lain untuk menghindari dampak simultan yang dapat mempengaruhi seluruh Wilayah. Saat Anda menyediakan kluster EKS, sebaiknya Anda menerapkan node pekerja Anda AZs di beberapa Region. Ini membantu membuat lingkungan klaster Anda lebih tahan terhadap kerusakan satu AZ, dan memungkinkan Anda mempertahankan ketersediaan tinggi untuk aplikasi Anda yang berjalan di AZ lainnya. AZs Saat Anda memulai pergeseran zona dari AZ yang terkena dampak, jaringan in-cluster lingkungan EKS Anda secara otomatis diperbarui untuk hanya menggunakan sehat AZs, untuk membantu menjaga ketersediaan tinggi untuk klaster Anda.
Memastikan bahwa Anda memiliki pengaturan Multi-AZ untuk lingkungan EKS Anda meningkatkan keandalan keseluruhan sistem Anda. Namun, lingkungan multi-AZ memengaruhi cara data aplikasi ditransfer dan diproses, yang pada gilirannya berdampak pada biaya jaringan lingkungan Anda. Secara khusus, lalu lintas lintas zona keluar yang sering (lalu lintas didistribusikan antara AZs) dapat berdampak besar pada biaya terkait jaringan Anda. Anda dapat menerapkan berbagai strategi untuk mengontrol jumlah lalu lintas lintas zona antar Pod di klaster EKS Anda dan menurunkan biaya terkait. Untuk informasi selengkapnya tentang cara mengoptimalkan biaya jaringan saat menjalankan lingkungan EKS yang sangat tersedia, lihat [https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/](https://aws.github.io/aws-eks-best-practices/cost_optimization/cost_opt_networking/).
Diagram berikut menggambarkan lingkungan EKS yang sangat tersedia dengan tiga sehat. AZs
![\[Ilustrasi jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-ha-before-failure.png)
Diagram berikut menggambarkan bagaimana lingkungan EKS dengan tiga AZs tahan terhadap gangguan AZ dan tetap sangat tersedia karena ada dua yang tetap sehat. AZs
![\[Ilustrasi jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-ha-after-failure.png)
### Menyediakan kapasitas komputasi yang cukup untuk menahan penghapusan satu Availability Zone
Untuk mengoptimalkan pemanfaatan sumber daya dan biaya untuk infrastruktur komputasi Anda di bidang data EKS, ini adalah praktik terbaik untuk menyelaraskan kapasitas komputasi dengan persyaratan beban kerja Anda. Namun, **jika semua node pekerja Anda berada pada kapasitas penuh**, Anda bergantung pada node pekerja baru yang ditambahkan ke bidang data EKS sebelum Pod baru dapat dijadwalkan. Saat Anda menjalankan beban kerja kritis, umumnya merupakan praktik yang baik untuk dijalankan dengan kapasitas berlebihan secara online untuk menangani skenario seperti peningkatan beban dan masalah kesehatan node secara tiba-tiba. Jika Anda berencana untuk menggunakan pergeseran zona, Anda berencana untuk menghapus seluruh AZ kapasitas ketika ada gangguan. Ini berarti Anda harus menyesuaikan kapasitas komputasi redundan Anda sehingga cukup untuk menangani beban bahkan dengan salah satu offline. AZs
Saat Anda menskalakan sumber daya komputasi Anda, proses menambahkan node baru ke bidang data EKS membutuhkan waktu. Ini dapat berimplikasi pada kinerja real-time dan ketersediaan aplikasi Anda, terutama jika terjadi gangguan zona. Lingkungan EKS Anda harus dapat menyerap beban kehilangan satu AZ tanpa menghasilkan pengalaman yang terdegradasi bagi pengguna akhir atau klien Anda. Ini berarti meminimalkan atau menghilangkan jeda antara waktu ketika Pod baru dibutuhkan dan kapan sebenarnya dijadwalkan pada node pekerja.
Selain itu, ketika ada gangguan zona, Anda harus bertujuan untuk mengurangi risiko mengalami kendala kapasitas komputasi yang akan mencegah node yang baru diperlukan ditambahkan ke bidang data EKS Anda dalam keadaan sehat. AZs
Untuk mengurangi risiko dampak negatif potensial ini, kami menyarankan Anda untuk menyediakan kapasitas komputasi yang berlebihan di beberapa node pekerja di masing-masing node. AZs Dengan melakukan ini, Penjadwal Kubernetes memiliki kapasitas yang sudah ada sebelumnya yang tersedia untuk penempatan Pod baru, yang sangat penting ketika Anda kehilangan salah satu di lingkungan Anda. AZs
### Jalankan dan sebarkan beberapa replika Pod di seluruh Availability Zone
Kubernetes memungkinkan Anda untuk melakukan pra-skala beban kerja Anda dengan menjalankan beberapa instance (replika Pod) dari satu aplikasi. Menjalankan beberapa replika Pod untuk sebuah aplikasi menghilangkan satu titik kegagalan dan meningkatkan kinerja secara keseluruhan dengan mengurangi ketegangan sumber daya pada satu replika. Namun, untuk memiliki ketersediaan tinggi dan toleransi kesalahan yang lebih baik untuk aplikasi Anda, kami sarankan Anda menjalankan beberapa replika aplikasi Anda dan menyebarkan replika di berbagai domain kegagalan, juga disebut sebagai domain topologi. Domain kegagalan dalam skenario ini adalah Availability Zones. Dengan menggunakan [kendala penyebaran topologi](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/), Anda dapat mengatur aplikasi Anda agar memiliki stabilitas statis yang sudah ada sebelumnya. Kemudian, ketika ada gangguan AZ, lingkungan Anda akan memiliki cukup replika dalam kondisi sehat AZs untuk segera menangani lonjakan atau lonjakan lalu lintas.
Diagram berikut menggambarkan lingkungan EKS yang memiliki arus east-to-west lalu lintas ketika AZs semuanya sehat.
![\[Ilustrasi jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-spread-constraints.png)
Diagram berikut menggambarkan lingkungan EKS yang memiliki arus east-to-west lalu lintas di mana satu AZ gagal dan Anda telah memulai pergeseran zona.
![\[Ilustrasi jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-spread-constraints-2.png)
Cuplikan kode berikut adalah contoh cara mengatur beban kerja Anda dengan beberapa replika di Kubernetes.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: orders
spec:
replicas: 9
selector:
matchLabels:
app:orders
template:
metadata:
labels:
app: orders
tier: backend
spec:
topologySpreadConstraints:
- maxSkew: 1
topologyKey: "topology.kubernetes.io/zone"
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app: orders
```
Yang terpenting, Anda harus menjalankan beberapa replika perangkat lunak server DNS Anda (CoreDNS/Kube-DNS) dan menerapkan batasan penyebaran topologi serupa, jika tidak dikonfigurasi secara default. Hal ini membantu memastikan bahwa, jika ada satu gangguan AZ, Anda memiliki cukup Pod DNS dalam kondisi sehat AZs untuk terus menangani permintaan penemuan layanan untuk Pod lain yang berkomunikasi di klaster. Add-on [CoreDNS EKS](managing-coredns.md) memiliki pengaturan default untuk Pod CoreDNS yang memastikan bahwa, jika ada node dalam AZs beberapa yang tersedia, mereka tersebar di Availability Zone klaster Anda. Jika mau, Anda dapat mengganti pengaturan default ini dengan konfigurasi kustom Anda sendiri.
Saat Anda menginstal [CoreDNS dengan](https://github.com/coredns/helm/tree/master) Helm, Anda dapat memperbarui `replicaCount` file in [values.yaml](https://github.com/coredns/helm/blob/master/charts/coredns/values.yaml) untuk memastikan bahwa Anda memiliki replika yang cukup di setiap AZ. Selain itu, untuk memastikan bahwa replika ini tersebar AZs di berbagai lingkungan klaster Anda, pastikan Anda memperbarui `topologySpreadConstraints` properti dalam `values.yaml` file yang sama. Cuplikan kode berikut menggambarkan bagaimana Anda dapat mengonfigurasi CoreDNS untuk melakukan ini.
**CoreDNS Helm nilai.yaml**
```
replicaCount: 6
topologySpreadConstraints:
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
k8s-app: kube-dns
```
Jika ada gangguan AZ, Anda dapat menyerap peningkatan beban pada Pod CoreDNS dengan menggunakan sistem penskalaan otomatis untuk CoreDNS. Jumlah instans DNS yang Anda perlukan bergantung pada jumlah beban kerja yang berjalan di klaster Anda. CoreDNS adalah CPU bound, yang memungkinkannya untuk menskalakan berdasarkan CPU dengan menggunakan [Horizontal Pod Autoscaler](https://aws.github.io/aws-eks-best-practices/reliability/docs/application/#horizontal-pod-autoscaler-hpa) (HPA). Berikut ini adalah contoh yang dapat Anda modifikasi sesuai dengan kebutuhan Anda.
```
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
name: coredns
namespace: default
spec:
maxReplicas: 20
minReplicas: 2
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: coredns
targetCPUUtilizationPercentage: 50
```
Atau, EKS dapat mengelola penskalaan otomatis penerapan CoreDNS di CoreDNS versi add-on EKS. Autoscaler CoreDNS ini terus memantau status cluster, termasuk jumlah node dan core CPU. Berdasarkan informasi tersebut, pengontrol secara dinamis menyesuaikan jumlah replika penerapan CoreDNS di cluster EKS.
Untuk mengaktifkan [konfigurasi penskalaan otomatis di add-on CoreDNS EKS](coredns-autoscaling.md), gunakan pengaturan konfigurasi berikut:
```
{
"autoScaling": {
"enabled": true
}
}
```
Anda juga dapat menggunakan [NodeLocal DNS](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/) atau [autoscaler proporsional cluster](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler) untuk menskalakan CoreDNS. Untuk informasi selengkapnya, lihat [Menskalakan CoreDNS](https://aws.github.io/aws-eks-best-practices/scalability/docs/cluster-services/#scale-coredns-horizontally) secara horizontal.
### Kolokasi Pod yang saling bergantung di Availability Zone yang sama
Biasanya, aplikasi memiliki beban kerja yang berbeda yang perlu berkomunikasi satu sama lain untuk berhasil menyelesaikan suatu end-to-end proses. Jika aplikasi yang berbeda ini tersebar di berbagai tempat AZs dan tidak ditempatkan di AZ yang sama, maka satu gangguan AZ dapat memengaruhi proses end-to-end. **Misalnya, jika **Aplikasi A** memiliki beberapa replika di AZ 1 dan AZ 2, tetapi **Aplikasi B** memiliki semua replika di AZ 3, maka hilangnya AZ 3 akan mempengaruhi end-to-end proses antara dua beban kerja, **Aplikasi A dan Aplikasi** B.** Jika Anda menggabungkan batasan penyebaran topologi dengan afinitas pod, Anda dapat meningkatkan ketahanan aplikasi Anda dengan menyebarkan Pod ke semua. AZs Selain itu, ini mengonfigurasi hubungan antara Pod tertentu untuk memastikan bahwa mereka terkolokasi.
Dengan [aturan afinitas pod](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/), Anda dapat menentukan hubungan antar beban kerja untuk memengaruhi perilaku Penjadwal Kubernetes sehingga Colocates Pod pada node pekerja yang sama atau di AZ yang sama. Anda juga dapat mengonfigurasi seberapa ketat batasan penjadwalan seharusnya.
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: products
namespace: ecommerce
labels:
app.kubernetes.io/version: "0.1.6"
spec:
serviceAccountName: graphql-service-account
affinity:
podAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: app
operator: In
values:
- orders
topologyKey: "kubernetes.io/hostname"
```
Diagram berikut menunjukkan beberapa pod yang telah dikolokasi pada node yang sama dengan menggunakan aturan afinitas pod.
![\[Ilustrasi jaringan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/zs-pod-affinity-rule.png)
### Uji apakah lingkungan cluster Anda dapat menangani hilangnya AZ
Setelah Anda menyelesaikan persyaratan yang dijelaskan di bagian sebelumnya, langkah selanjutnya adalah menguji apakah Anda memiliki kapasitas komputasi dan beban kerja yang cukup untuk menangani hilangnya AZ. Anda dapat melakukan ini dengan memulai pergeseran zona secara manual di EKS. Atau, Anda dapat mengaktifkan zonal autoshift dan mengkonfigurasi praktik berjalan, yang juga menguji apakah aplikasi Anda berfungsi seperti yang diharapkan dengan satu AZ yang lebih sedikit di lingkungan cluster Anda.
## Pertanyaan umum
**Mengapa saya harus menggunakan fitur ini?**
Dengan menggunakan ARC zonal shift atau zonal autoshift di kluster EKS Anda, Anda dapat mempertahankan ketersediaan aplikasi Kubernetes dengan lebih baik dengan mengotomatiskan proses pemulihan cepat untuk mengalihkan lalu lintas jaringan in-cluster dari AZ yang rusak. Dengan ARC, Anda dapat menghindari langkah-langkah panjang dan rumit yang dapat menyebabkan periode pemulihan yang diperpanjang selama peristiwa AZ yang terganggu.
**Bagaimana cara kerja fitur ini dengan AWS layanan lain?**
EKS terintegrasi dengan ARC, yang menyediakan antarmuka utama bagi Anda untuk menyelesaikan operasi pemulihan di. AWS Untuk memastikan bahwa lalu lintas in-cluster dialihkan dengan tepat dari AZ yang rusak, EKS membuat modifikasi pada daftar titik akhir jaringan untuk Pod yang berjalan di bidang data Kubernetes. Jika Anda menggunakan Elastic Load Balancing untuk merutekan lalu lintas eksternal ke cluster, Anda dapat mendaftarkan penyeimbang beban Anda dengan ARC dan memulai pergeseran zona untuk mencegah lalu lintas mengalir ke AZ yang terdegradasi. Zonal shift juga berfungsi dengan grup Amazon EC2 Auto Scaling yang dibuat oleh grup node terkelola EKS. Untuk mencegah AZ yang rusak digunakan untuk Pod Kubernetes atau peluncuran node baru, EKS menghapus AZ yang rusak dari grup Auto Scaling.
**Apa perbedaan fitur ini dengan perlindungan Kubernetes default?**
Fitur ini bekerja bersama-sama dengan beberapa perlindungan bawaan Kubernetes yang membantu ketahanan aplikasi pelanggan. Anda dapat mengonfigurasi probe kesiapan dan keaktifan Pod yang menentukan kapan Pod harus mengambil lalu lintas. Ketika probe ini gagal, Kubernetes menghapus Pod ini sebagai target untuk layanan, dan lalu lintas tidak lagi dikirim ke Pod. Meskipun ini berguna, tidak mudah bagi pelanggan untuk mengonfigurasi pemeriksaan kesehatan ini sehingga dijamin gagal ketika AZ terdegradasi. Fitur ARC zonal shift menyediakan jaring pengaman tambahan yang membantu Anda mengisolasi AZ yang terdegradasi sepenuhnya ketika perlindungan asli Kubernetes tidak cukup. Pergeseran zona juga memberi Anda cara mudah untuk menguji kesiapan operasional dan ketahanan arsitektur Anda.
**Bisakah AWS memulai pergeseran zona atas nama saya?**
Ya, jika Anda menginginkan cara yang sepenuhnya otomatis menggunakan pergeseran zona ARC, Anda dapat mengaktifkan pergeseran otomatis zona ARC. Dengan pergeseran otomatis zona, Anda dapat mengandalkan AWS untuk memantau kesehatan klaster EKS Anda, dan untuk secara otomatis memulai pergeseran zona ketika gangguan AZ terdeteksi. AZs
**Apa yang terjadi jika saya menggunakan fitur ini dan node pekerja serta beban kerja saya tidak diskalakan sebelumnya?**
Jika Anda tidak melakukan pra-skala dan mengandalkan penyediaan node atau Pod tambahan selama pergeseran zona, Anda berisiko mengalami pemulihan yang tertunda. Proses penambahan node baru ke bidang data Kubernetes membutuhkan waktu lama, yang dapat memengaruhi kinerja dan ketersediaan aplikasi Anda secara real-time, terutama ketika ada gangguan zona. Selain itu, jika terjadi gangguan zona, Anda mungkin menghadapi kendala kapasitas komputasi potensial yang dapat mencegah node yang baru diperlukan ditambahkan ke yang sehat. AZs
Jika beban kerja Anda tidak diskalakan sebelumnya dan tersebar AZs di semua klaster Anda, gangguan zona dapat memengaruhi ketersediaan aplikasi yang hanya berjalan pada node pekerja di AZ yang terkena dampak. Untuk mengurangi risiko pemadaman ketersediaan lengkap untuk aplikasi Anda, EKS memiliki keamanan yang gagal untuk lalu lintas yang dikirim ke titik akhir Pod di zona yang terganggu jika beban kerja tersebut memiliki semua titik akhir di AZ yang tidak sehat. Namun, kami sangat menyarankan Anda melakukan pra-skala dan menyebarkan aplikasi Anda AZs ke semua untuk menjaga ketersediaan jika terjadi masalah zona.
**Bagaimana cara kerjanya jika saya menjalankan aplikasi stateful?**
Jika Anda menjalankan aplikasi stateful, Anda harus menilai toleransi kesalahannya, berdasarkan kasus penggunaan dan arsitektur Anda. Jika Anda memiliki active/standby arsitektur atau pola, mungkin ada contoh di mana aktif berada di AZ yang rusak. Pada tingkat aplikasi, jika siaga tidak diaktifkan, Anda mungkin mengalami masalah dengan aplikasi Anda. Anda mungkin juga mengalami masalah ketika Pod Kubernetes baru diluncurkan dalam keadaan sehat AZs, karena mereka tidak akan dapat dilampirkan ke volume persisten yang dibatasi ke AZ yang rusak.
**Apakah fitur ini berfungsi dengan Karpenter?**
Dukungan Karpenter saat ini tidak tersedia dengan ARC zonal shift dan zonal autoshift di EKS. Jika AZ terganggu, Anda dapat menyesuaikan NodePool konfigurasi Karpenter yang relevan dengan menghapus AZ yang tidak sehat sehingga node pekerja baru hanya diluncurkan di yang lain. AZs
**Apakah fitur ini berfungsi dengan EKS Fargate?**
Fitur ini tidak berfungsi dengan EKS Fargate. Secara default, ketika EKS Fargate mengenali peristiwa kesehatan zona, Pod akan lebih memilih untuk berjalan di acara lainnya. AZs
**Apakah pesawat kontrol Kubernetes yang dikelola EKS akan terkena dampak?**
Tidak, secara default Amazon EKS menjalankan dan menskalakan bidang kontrol Kubernetes di beberapa bidang AZs untuk memastikan ketersediaan yang tinggi. ARC zonal shift dan zonal autoshift hanya bekerja pada bidang data Kubernetes.
**Apakah ada biaya yang terkait dengan fitur baru ini?**
Anda dapat menggunakan ARC zonal shift dan zonal autoshift di kluster EKS Anda tanpa biaya tambahan. Namun, Anda akan terus membayar instans yang telah disediakan dan kami sangat menyarankan agar Anda melakukan pra-skala pesawat data Kubernetes sebelum menggunakan fitur ini. Anda harus mempertimbangkan keseimbangan antara biaya dan ketersediaan aplikasi.
## Sumber daya tambahan
+ [Cara kerja peralihan zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
+ [Praktik terbaik untuk pergeseran zona di ARC](https://docs.aws.amazon.com/r53recovery/latest/dg/route53-arc-best-practices.zonal-shifts.html#zonalshift.route53-arc-best-practices.zonal-shifts)
+ [Sumber daya dan skenario yang didukung untuk pergeseran zona dan pergeseran otomatis zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.resource-types.html)
+ [Mengoperasikan beban kerja tangguh di Amazon EKS](https://aws.amazon.com/blogs/containers/operating-resilient-workloads-on-amazon-eks)
+ [Hilangkan lag penskalaan node Kubernetes dengan prioritas pod dan penyediaan berlebih](https://aws.amazon.com/blogs/containers/eliminate-kubernetes-node-scaling-lag-with-pod-priority-and-over-provisioning)
+ [Menskalakan Pod CoreDNS untuk lalu lintas DNS tinggi](coredns-autoscaling.md)
# Aktifkan pergeseran zona EKS untuk menghindari Zona Ketersediaan yang terganggu
Amazon Application Recovery Controller (ARC) membantu Anda mengelola dan mengoordinasikan pemulihan untuk aplikasi Anda di seluruh Availability Zones (AZs) dan bekerja dengan banyak layanan, termasuk Amazon EKS. Dengan dukungan EKS untuk pergeseran zona ARC, Anda dapat mengalihkan lalu lintas jaringan in-cluster dari AZ yang rusak. Anda juga dapat mengizinkan AWS untuk memantau kesehatan Anda AZs dan mengalihkan lalu lintas jaringan untuk sementara dari AZ yang tidak sehat atas nama Anda.
**Cara menggunakan EKS zonal shift:**
1. Aktifkan kluster EKS Anda dengan Amazon Application Recovery Controller (ARC). Ini dilakukan di tingkat cluster menggunakan Amazon EKS Console, AWS CLI, CloudFormation, atau eksctl.
1. Setelah diaktifkan, Anda dapat mengelola pergeseran zona atau pergeseran otomatis zona menggunakan Konsol ARC, AWS CLI, atau pergeseran zona dan pergeseran otomatis zona. APIs
Perhatikan bahwa setelah Anda mendaftarkan cluster EKS dengan ARC, Anda masih perlu mengkonfigurasi ARC. Misalnya, Anda dapat menggunakan konsol ARC untuk mengonfigurasi zonal autoshift.
Untuk informasi lebih rinci tentang cara kerja shift zona EKS, dan cara mendesain beban kerja Anda untuk menangani zona ketersediaan yang terganggu, lihat. [Pelajari tentang pergeseran zona Amazon Application Recovery Controller (ARC) di Amazon EKS](zone-shift.md)
## Pertimbangan-pertimbangan
+ Mode Otomatis EKS tidak mendukung Amazon Application Recovery Controller, zonal shift, dan zonal autoshift.
+ Kami merekomendasikan menunggu setidaknya 60 detik antara operasi pergeseran zona untuk memastikan pemrosesan yang tepat dari setiap permintaan.
Saat mencoba melakukan pergeseran zona secara berurutan (dalam waktu 60 detik satu sama lain), layanan Amazon EKS mungkin tidak memproses semua permintaan shift dengan benar. Hal ini disebabkan mekanisme polling saat ini yang memperbarui status zona klaster. Jika Anda perlu melakukan beberapa pergeseran zona, pastikan ada waktu yang cukup antara operasi bagi sistem untuk memproses setiap perubahan.
## Apa itu Pengontrol Pemulihan Aplikasi Amazon?
Amazon Application Recovery Controller (ARC) membantu Anda mempersiapkan dan menyelesaikan pemulihan yang lebih cepat untuk aplikasi yang berjalan AWS. Pergeseran zona memungkinkan Anda pulih dengan cepat dari gangguan Availability Zone (AZ), dengan memindahkan lalu lintas sementara untuk sumber daya yang didukung dari AZ, menjadi sehat AZs di AWS Wilayah.
[Pelajari selengkapnya tentang Amazon Application Recovery Controller (ARC)](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route53-recovery.html)
## Apa itu pergeseran zona?
Zonal shift adalah kemampuan di ARC yang memungkinkan Anda memindahkan lalu lintas untuk sumber daya seperti cluster EKS atau Elastic Load Balancer jauh dari Availability Zone di AWS Region untuk mengurangi masalah dengan cepat dan memulihkan aplikasi Anda dengan cepat. Anda mungkin memilih untuk mengalihkan lalu lintas, misalnya, karena penerapan yang buruk menyebabkan masalah latensi, atau karena Availability Zone terganggu. Pergeseran zona tidak memerlukan langkah konfigurasi lanjutan.
[Pelajari selengkapnya tentang ARC zonal shift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.how-it-works.html)
## Apa itu zonal autoshift?
Zonal autoshift adalah kemampuan di ARC yang dapat Anda aktifkan untuk mengotorisasi AWS untuk mengalihkan lalu lintas dari AZ untuk sumber daya yang didukung, atas nama Anda, menjadi sehat AZs di Wilayah. AWS AWS memulai pergeseran otomatis ketika telemetri internal menunjukkan bahwa ada gangguan pada satu AZ di Wilayah yang berpotensi berdampak pada pelanggan. Telemetri internal menggabungkan metrik dari berbagai sumber, termasuk AWS jaringan, dan layanan Amazon dan Elastic EC2 Load Balancing.
AWS mengakhiri pergeseran otomatis ketika indikator menunjukkan bahwa tidak ada lagi masalah atau masalah potensial.
[Pelajari selengkapnya tentang ARC zonal autoshift](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.how-it-works.html)
## Apa yang dilakukan EKS selama autoshift?
EKS memperbarui konfigurasi jaringan untuk menghindari mengarahkan lalu lintas ke gangguan. AZs Selain itu, jika Anda menggunakan Grup Node Terkelola, EKS hanya akan meluncurkan node baru dalam kondisi sehat AZs selama pergeseran zona. Ketika shift berakhir atau dibatalkan, konfigurasi jaringan akan dipulihkan untuk menyertakan AZ yang sebelumnya terdeteksi sebagai tidak sehat.
[Pelajari lebih lanjut tentang pergeseran zona EKS](zone-shift.md).
## Daftarkan cluster EKS dengan Amazon Application Recovery Controller (ARC) (AWS konsol)
1. Temukan nama dan wilayah cluster EKS yang ingin Anda daftarkan dengan ARC.
1. Arahkan ke [konsol EKS](https://console.aws.amazon.com/eks) di wilayah tersebut, dan pilih klaster Anda.
1. Pada halaman **Info cluster**, pilih tab **Ikhtisar**.
1. Di bawah judul **Zonal Shift**, pilih tombol **Kelola**.
1. Pilih **aktifkan** atau **nonaktifkan** untuk *pergeseran zona EKS*.
Sekarang cluster EKS Anda terdaftar dengan ARC.
Jika Anda AWS ingin mendeteksi dan menghindari zona ketersediaan yang terganggu, Anda perlu mengonfigurasi autoshift zona ARC. Misalnya, Anda dapat melakukan ini di konsol ARC.
## Langkah Berikutnya
+ Pelajari cara [mengaktifkan pergeseran otomatis zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-autoshift.start-cancel.html).
+ Pelajari cara [memulai pergeseran zona](https://docs.aws.amazon.com/r53recovery/latest/dg/arc-zonal-shift.start-cancel.html) secara manual.