**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.
# Menerapkan Amazon EKS lokal dengan Outposts AWS
Anda dapat menggunakan Amazon EKS untuk menjalankan aplikasi Kubernetes lokal di Outposts. AWS Anda dapat menerapkan Amazon EKS di Outposts dengan cara berikut:
+ **Extended cluster** — Jalankan control plane Kubernetes di AWS Region dan node di Outpost Anda.
+ **Cluster lokal** — Jalankan control plane Kubernetes dan node di Outpost Anda.
Untuk kedua opsi penerapan, pesawat kontrol Kubernetes dikelola sepenuhnya oleh. AWS Anda dapat menggunakan Amazon EKS APIs, alat, dan konsol yang sama yang Anda gunakan di cloud untuk membuat dan menjalankan Amazon EKS di Outposts.
Diagram berikut menunjukkan opsi penyebaran ini.
![\[Opsi penyebaran pos terdepan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/outposts-deployment-options.png)
## Kapan menggunakan setiap opsi penerapan
Cluster lokal dan diperluas adalah opsi penyebaran tujuan umum dan dapat digunakan untuk berbagai aplikasi.
Dengan kluster lokal, Anda dapat menjalankan seluruh kluster Amazon EKS secara lokal di Outposts. Opsi ini dapat mengurangi risiko downtime aplikasi yang mungkin diakibatkan oleh pemutusan jaringan sementara ke cloud. Pemutusan jaringan ini dapat disebabkan oleh pemotongan serat atau peristiwa cuaca. Karena seluruh kluster Amazon EKS berjalan secara lokal di Outposts, aplikasi tetap tersedia. Anda dapat melakukan operasi cluster selama pemutusan jaringan ke cloud. Untuk informasi selengkapnya, lihat [Siapkan kluster Amazon EKS lokal di AWS Outposts untuk pemutusan jaringan](eks-outposts-network-disconnects.md). Jika Anda khawatir tentang kualitas koneksi jaringan dari Outposts Anda ke AWS Wilayah induk dan memerlukan ketersediaan tinggi melalui pemutusan jaringan, gunakan opsi penyebaran cluster lokal.
Dengan klaster yang diperluas, Anda dapat menghemat kapasitas di Pos Luar karena bidang kontrol Kubernetes berjalan di Wilayah induk. AWS Opsi ini cocok jika Anda dapat berinvestasi dalam konektivitas jaringan yang andal dan redundan dari Pos Luar Anda ke Wilayah. AWS Kualitas koneksi jaringan sangat penting untuk opsi ini. Cara Kubernetes menangani pemutusan jaringan antara bidang kontrol Kubernetes dan node dapat menyebabkan downtime aplikasi. Untuk informasi selengkapnya tentang perilaku Kubernetes, lihat [Penjadwalan, Preemption, dan Penggusuran di dokumentasi Kubernetes](https://kubernetes.io/docs/concepts/scheduling-eviction/).
## Membandingkan opsi penerapan
Tabel berikut membandingkan perbedaan antara dua opsi.
| Fitur | Cluster yang diperluas | Cluster lokal |
| --- | --- | --- |
| Kubernetes mengontrol lokasi pesawat | AWS Wilayah | Pos terdepan |
| Akun pesawat kontrol Kubernetes | AWS akun | Akun Anda |
| Ketersediaan wilayah | lihat [Titik akhir layanan](https://docs.aws.amazon.com/general/latest/gr/eks.html#eks_region) | AS Timur (Ohio), AS Timur (Virginia N.), AS Barat (California N.), AS Barat (Oregon), Asia Pasifik (Seoul), Asia Pasifik (Singapura), Asia Pasifik (Sydney), Asia Pasifik (Tokyo), Kanada (Tengah), Eropa (Frankfurt), Eropa (Irlandia), Eropa (London), Timur Tengah (Bahrain), dan Amerika Selatan (Sao Paulo) |
| Kubernetes versi minor | eks/latest/userguide/kubernetes-versions.html [Versi Amazon EKS yang didukung, type="documentation "]. | eks/latest/userguide/kubernetes-versions.html [Versi Amazon EKS yang didukung, type="documentation "]. |
| Versi platform | Lihat versi [platform EKS](https://docs.aws.amazon.com/eks/latest/userguide/platform-versions.html) | Lihat [Pelajari versi platform Kubernetes dan Amazon EKS untuk Outposts AWS](eks-outposts-platform-versions.md) |
| Faktor bentuk pos terdepan | Rak pos terdepan | Rak pos terdepan |
| Antarmuka pengguna | Konsol Manajemen AWS, AWS CLI, Amazon EKS API,, `eksctl` AWS CloudFormation, dan Terraform | Konsol Manajemen AWS, AWS CLI, Amazon EKS API,, `eksctl` AWS CloudFormation, dan Terraform |
| Kebijakan terkelola | [EKSClusterKebijakan Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksclusterpolicy) dan [AWS kebijakan terkelola: Amazon EKSService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazoneksservicerolepolicy) | [Amazon EKSLocal OutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) dan [AWS kebijakan terkelola: Amazon EKSLocal OutpostServiceRolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostservicerolepolicy) |
| Cluster VPC dan subnet | Lihat [Lihat persyaratan jaringan Amazon EKS untuk VPC dan subnet](network-reqs.md) | Lihat [Buat VPC dan subnet untuk cluster Amazon EKS di Outposts AWS](eks-outposts-vpc-subnet-requirements.md) |
| Akses titik akhir klaster | Publik atau swasta atau keduanya | Hanya pribadi |
| Autentikasi server API Kubernetes | AWS Identity and Access Management (IAM) dan OIDC | IAM dan sertifikat `x.509` |
| Jenis simpul | Hanya dikelola sendiri | Hanya dikelola sendiri |
| Jenis komputasi simpul | Amazon EC2 sesuai permintaan | Amazon EC2 sesuai permintaan |
| Jenis penyimpanan simpul | Amazon EBS `gp2` dan SSD lokal NVMe | Amazon EBS `gp2` dan SSD lokal NVMe |
| Amazon EKS dioptimalkan AMIs | Amazon Linux, Windows, dan Bottlerocket | Hanya Amazon Linux |
| Versi IP | `IPv4`hanya | `IPv4`hanya |
| Pengaya | Pengaya Amazon EKS atau add-on yang dikelola sendiri | Hanya add-on yang dikelola sendiri |
| Antarmuka Jaringan Kontainer Default | Plugin Amazon VPC CNI untuk Kubernetes | Plugin Amazon VPC CNI untuk Kubernetes |
| Log pesawat kontrol Kubernetes | CloudWatch Log Amazon | CloudWatch Log Amazon |
| Penyeimbangan beban | Gunakan [AWS Load Balancer Controller](aws-load-balancer-controller.md) untuk menyediakan Application Load Balancer saja (tidak ada Network Load Balancer) | Gunakan [AWS Load Balancer Controller](aws-load-balancer-controller.md) untuk menyediakan Application Load Balancer saja (tidak ada Network Load Balancer) |
| Rahasia enkripsi amplop | Lihat [Enkripsi rahasia Kubernetes dengan KMS di cluster yang ada](enable-kms.md) | Tidak didukung |
| IAM role untuk akun layanan | Lihat [IAM role untuk akun layanan](iam-roles-for-service-accounts.md) | Tidak didukung |
| Pemecahan Masalah | Lihat [Memecahkan masalah dengan kluster dan node Amazon EKS](troubleshooting.md) | Lihat [Memecahkan masalah cluster Amazon EKS lokal di Outposts AWS](eks-outposts-troubleshooting.md) |
**Topics**
# Buat cluster Amazon EKS lokal di AWS Outposts untuk ketersediaan tinggi
Anda dapat menggunakan kluster lokal untuk menjalankan seluruh kluster Amazon EKS secara lokal di AWS Outposts. Ini membantu mengurangi risiko downtime aplikasi yang mungkin diakibatkan oleh pemutusan jaringan sementara ke cloud. Pemutusan ini dapat disebabkan oleh pemotongan serat atau peristiwa cuaca. Karena seluruh klaster Kubernetes berjalan secara lokal di Outposts, aplikasi tetap tersedia. Anda dapat melakukan operasi cluster selama pemutusan jaringan ke cloud. Untuk informasi selengkapnya, lihat [Siapkan kluster Amazon EKS lokal di AWS Outposts untuk pemutusan jaringan](eks-outposts-network-disconnects.md). Diagram berikut menunjukkan penyebaran cluster lokal.
![\[Kluster lokal pos terdepan\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/outposts-local-cluster.png)
Cluster lokal umumnya tersedia untuk digunakan dengan rak Outposts.
## AWS Wilayah yang Didukung
Anda dapat membuat cluster lokal di AWS Wilayah berikut: AS Timur (Ohio), AS Timur (Virginia N.), AS Barat (California N.), AS Barat (Oregon), Asia Pasifik (Seoul), Asia Pasifik (Singapura), Asia Pasifik (Sydney), Asia Pasifik (Tokyo), Kanada (Tengah), Eropa (Frankfurt), Eropa (Irlandia), Eropa (London), Timur Tengah (Bahrain), dan Amerika Selatan (São Paulo). Untuk informasi rinci tentang fitur yang didukung, lihat[Membandingkan opsi penerapan](eks-outposts.md#outposts-overview-comparing-deployment-options).
**Topics**
# Menerapkan cluster Amazon EKS di Outposts AWS
Topik ini memberikan gambaran umum tentang apa yang harus dipertimbangkan saat menjalankan cluster lokal di Outpost. Topik ini juga memberikan instruksi tentang cara menyebarkan cluster lokal di Outpost.
**penting**
Pertimbangan ini tidak direplikasi dalam dokumentasi Amazon EKS terkait. Jika topik dokumentasi Amazon EKS lainnya bertentangan dengan pertimbangan di sini, ikuti pertimbangannya di sini.
Pertimbangan ini dapat berubah dan mungkin sering berubah. Jadi, kami sarankan Anda meninjau topik ini secara teratur.
Banyak pertimbangan yang berbeda dari pertimbangan untuk membuat cluster di Cloud. AWS
+ Cluster lokal hanya mendukung rak Outpost. Sebuah cluster lokal tunggal dapat berjalan di beberapa rak Outpost fisik yang terdiri dari satu pos logis. Satu cluster lokal tidak dapat berjalan di beberapa Outposts logis. Setiap Outpost logis memiliki ARN Outpost tunggal.
+ Cluster lokal menjalankan dan mengelola control plane Kubernetes di akun Anda di Outpost. Anda tidak dapat menjalankan beban kerja pada instance control plane Kubernetes atau memodifikasi komponen control plane Kubernetes. Node ini dikelola oleh layanan Amazon EKS. Perubahan pada bidang kontrol Kubernetes tidak bertahan melalui tindakan manajemen Amazon EKS otomatis, seperti patching.
+ Cluster lokal mendukung add-on yang dikelola sendiri dan grup node Amazon Linux yang dikelola sendiri. [Plugin Amazon VPC CNI untuk Kubernetes, kube-proxy,](managing-vpc-cni.md) [[dan CoreDNS add-on secara otomatis diinstal pada cluster lokal.](managing-coredns.md)](managing-kube-proxy.md)
+ Cluster lokal memerlukan penggunaan Amazon EBS di Outposts. Pos Luar Anda harus memiliki Amazon EBS yang tersedia untuk penyimpanan pesawat kontrol Kubernetes. Outposts hanya mendukung volume Amazon EBS`gp2`.
+ Kubernetes yang didukung Amazon EBS `PersistentVolumes` didukung menggunakan driver Amazon EBS CSI.
+ Contoh bidang kontrol cluster lokal diatur dalam topologi [bertumpuk yang sangat tersedia](https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/ha-topology/). Dua dari tiga contoh bidang kontrol harus sehat setiap saat untuk mempertahankan kuorum. Jika kuorum hilang, hubungi AWS dukungan, karena beberapa tindakan sisi layanan akan diperlukan untuk mengaktifkan instance terkelola yang baru.
**Prasyarat**
+ [Keakraban dengan opsi [penyebaran Outposts](eks-outposts.md#outposts-overview-comparing-deployment-options)[, Pilih jenis instans, dan grup penempatan untuk klaster Amazon EKS di AWS Outposts berdasarkan pertimbangan kapasitas, serta persyaratan serta pertimbangan VPC.](eks-outposts-capacity-considerations.md)](eks-outposts-vpc-subnet-requirements.md)
+ Pos terdepan yang ada. Untuk informasi selengkapnya, lihat [Apa itu AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ Alat baris `kubectl` perintah diinstal pada komputer 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 | 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 (pengguna atau peran) 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).
Saat kluster Amazon EKS lokal dibuat, [prinsipal IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html#iam-term-principal) yang membuat cluster ditambahkan secara permanen. Prinsipal secara khusus ditambahkan ke tabel otorisasi Kubernetes RBAC sebagai administrator. Entitas ini memiliki `system:masters` izin. Identitas entitas ini tidak terlihat dalam konfigurasi klaster Anda. Jadi, penting untuk mencatat entitas yang membuat cluster dan pastikan Anda tidak pernah menghapusnya. Awalnya, hanya prinsipal yang membuat server yang dapat melakukan panggilan ke server API Kubernetes menggunakan. `kubectl` Jika Anda menggunakan konsol untuk membuat klaster, pastikan kredenal IAM yang sama ada di rantai kredensi AWS SDK saat Anda menjalankan `kubectl` perintah di klaster. Setelah klaster Anda dibuat, Anda dapat memberikan prinsipal IAM lainnya akses ke klaster Anda.
## Buat klaster lokal Amazon EKS
Anda dapat membuat klaster lokal dengan alat berikut yang dijelaskan di halaman ini:
+ [`eksctl`](#eksctl_create_cluster_outpost)
+ [Konsol Manajemen AWS](#console_create_cluster_outpost)
Anda juga dapat menggunakan [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/eks/create-cluster.html), [Amazon EKS API](https://docs.aws.amazon.com/eks/latest/APIReference/API_CreateCluster.html), the [AWS SDKs](https://aws.amazon.com/developer/tools/), [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-eks-cluster-outpostconfig.html)atau [Terraform](https://registry.terraform.io/modules/terraform-aws-modules/eks/aws/latest) untuk membuat cluster di Outposts.
### `eksctl`
**Untuk membuat cluster lokal dengan `eksctl`**
1. Instal versi `0.215.0` atau yang lebih baru dari alat baris `eksctl` perintah di perangkat Anda atau AWS CloudShell. Untuk menginstal atau memperbarui`eksctl`, lihat [Instalasi](https://eksctl.io/installation) dalam `eksctl` dokumentasi.
1. Salin konten yang mengikuti ke perangkat Anda. Ganti nilai-nilai berikut dan kemudian jalankan perintah yang dimodifikasi untuk membuat `outpost-control-plane.yaml` file:
+ Ganti *region-code* dengan [AWS Wilayah yang didukung](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions) tempat Anda ingin membuat klaster.
+ 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. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ Ganti *vpc-ExampleID1* dan *subnet-ExampleID1* dengan VPC dan subnet Anda yang ada. IDs VPC dan subnet harus memenuhi persyaratan di Buat [VPC dan subnet untuk cluster Amazon](eks-outposts-vpc-subnet-requirements.md) EKS di Outposts. AWS
+ Ganti *uniqueid* dengan ID Outpost Anda.
+ Ganti *m5.large* dengan jenis instance yang tersedia di Outpost Anda. Sebelum memilih jenis instance, lihat[Pilih jenis instans dan grup penempatan untuk klaster Amazon EKS di AWS Outposts berdasarkan pertimbangan kapasitas](eks-outposts-capacity-considerations.md). Tiga instance pesawat kontrol dikerahkan. Anda tidak dapat mengubah nomor ini.
```
cat >outpost-control-plane.yaml <
**Untuk membuat cluster Anda dengan Konsol Manajemen AWS **
1. Anda memerlukan VPC dan subnet yang sudah ada yang memenuhi persyaratan Amazon EKS. Untuk informasi selengkapnya, lihat [Buat VPC dan subnet untuk cluster Amazon EKS di Outposts AWS](eks-outposts-vpc-subnet-requirements.md).
1. Jika Anda sudah memiliki peran IAM cluster lokal, 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": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
```
1. Buat peran IAM cluster Amazon EKS. 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 myAmazonEKSLocalClusterRole --assume-role-policy-document file://"eks-local-cluster-role-trust-policy.json"
```
1. Lampirkan kebijakan terkelola Amazon EKS bernama [Amazon EKSLocal OutpostClusterPolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonEKSLocalOutpostClusterPolicy.html) 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/AmazonEKSLocalOutpostClusterPolicy --role-name myAmazonEKSLocalClusterRole
```
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Di bagian atas layar konsol, pastikan Anda telah memilih [AWS Wilayah yang didukung](eks-outposts-local-cluster-overview.md#outposts-control-plane-supported-regions).
1. Pilih **Add cluster** dan kemudian pilih **Create**.
1. Pada halaman **Configure cluster**, masukkan atau pilih nilai untuk bidang berikut:
+ **Kubernetes mengontrol lokasi pesawat — Pilih Outposts**. AWS
+ **Outpost ID** - Pilih ID Outpost tempat Anda ingin membuat pesawat kontrol Anda.
+ **Jenis instans** - Pilih jenis instans. Hanya jenis instans yang tersedia di Outpost Anda yang ditampilkan. Dalam daftar dropdown, setiap jenis instance menjelaskan berapa banyak node yang direkomendasikan untuk jenis instance. Sebelum memilih jenis instance, lihat[Pilih jenis instans dan grup penempatan untuk klaster Amazon EKS di AWS Outposts berdasarkan pertimbangan kapasitas](eks-outposts-capacity-considerations.md). Semua replika dikerahkan menggunakan jenis instance yang sama. Anda tidak dapat mengubah jenis instance setelah cluster Anda dibuat. Tiga instance pesawat kontrol dikerahkan. Anda tidak dapat mengubah nomor ini.
+ **Nama** — Nama untuk klaster Anda. Itu harus unik di AWS akun 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. Nama harus unik di dalam AWS Wilayah dan AWS akun tempat Anda membuat klaster.
+ Versi **Kubernetes — Pilih versi** Kubernetes yang ingin Anda gunakan untuk klaster Anda. Sebaiknya pilih versi terbaru, kecuali jika Anda perlu menggunakan versi sebelumnya.
+ **Peran layanan klaster — Pilih peran** IAM klaster Amazon EKS yang Anda buat pada langkah sebelumnya untuk memungkinkan bidang kontrol Kubernetes mengelola sumber daya. AWS
+ **Akses administrator klaster Kubernetes** — Jika Anda ingin prinsipal IAM (peran atau pengguna) yang membuat klaster memiliki akses administrator ke objek Kubernetes di klaster, terima default (allow). Amazon EKS membuat entri akses untuk prinsipal IAM dan memberikan izin administrator klaster ke entri akses. Untuk informasi selengkapnya tentang entri akses, lihat[Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md).
Jika Anda menginginkan prinsipal IAM yang berbeda dari prinsipal yang membuat klaster memiliki akses administrator ke objek cluster Kubernetes, pilih opsi disallow. Setelah pembuatan klaster, setiap prinsipal IAM yang memiliki izin IAM untuk membuat entri akses dapat menambahkan entri akses untuk setiap prinsipal IAM yang memerlukan akses ke objek klaster Kubernetes. Untuk informasi selengkapnya tentang izin IAM yang diperlukan, lihat [Tindakan yang ditentukan oleh Amazon Elastic Kubernetes Service](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonelastickubernetesservice.html#amazonelastickubernetesservice-actions-as-permissions) di Referensi Otorisasi Layanan. Jika Anda memilih opsi disallow dan tidak membuat entri akses apa pun, maka tidak ada prinsipal IAM yang akan memiliki akses ke objek Kubernetes di cluster.
+ **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 ada. VPC harus memiliki cukup banyak alamat IP yang tersedia untuk cluster, node apa pun, dan sumber daya Kubernetes lainnya yang ingin Anda buat. VPC Anda harus memenuhi persyaratan dalam persyaratan dan pertimbangan [VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **Subnet** — Secara default, semua subnet yang tersedia di VPC yang ditentukan di bidang sebelumnya telah dipilih sebelumnya. Subnet yang Anda pilih harus memenuhi persyaratan dalam [persyaratan dan pertimbangan Subnet](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements).
+ **Grup keamanan** — (Opsional) Tentukan satu atau beberapa grup keamanan yang ingin Anda kaitkan Amazon EKS ke antarmuka jaringan yang dibuatnya. Amazon EKS secara otomatis 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 memilih untuk menambahkan grup keamanan Anda sendiri, Anda tidak dapat mengubah grup yang Anda pilih setelah pembuatan klaster. Agar host lokal dapat berkomunikasi dengan titik akhir klaster, Anda harus mengizinkan lalu lintas masuk dari grup keamanan klaster. Untuk cluster yang tidak memiliki koneksi internet ingress dan egress (juga dikenal sebagai cluster pribadi), Anda harus melakukan salah satu hal berikut:
+ Tambahkan grup keamanan yang terkait dengan titik akhir VPC yang diperlukan. Untuk informasi selengkapnya tentang titik akhir yang diperlukan, lihat [Menggunakan VPC endpoint antarmuka](eks-outposts-vpc-subnet-requirements.md#vpc-subnet-requirements-vpc-endpoints) di [Subnet akses ke AWS layanan](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services).
+ Ubah grup keamanan yang dibuat Amazon EKS untuk memungkinkan lalu lintas dari grup keamanan yang terkait dengan titik akhir VPC. Setelah selesai dengan halaman ini, pilih **Berikutnya**.
1. Pada halaman **Konfigurasi observabilitas**, Anda dapat secara opsional memilih opsi **pencatatan bidang **Metrik** dan Kontrol** mana yang ingin Anda aktifkan. 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 **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.
Penyediaan klaster memerlukan waktu beberapa menit.
## Lihat kluster lokal Amazon EKS Anda
1. Setelah klaster dibuat, Anda dapat melihat instans bidang kontrol Amazon EC2 yang dibuat.
```
aws ec2 describe-instances --query 'Reservations[*].Instances[*].{Name:Tags[?Key==`Name`]|[0].Value}' | grep my-cluster-control-plane
```
Contoh output adalah sebagai berikut.
```
"Name": "my-cluster-control-plane-id1"
"Name": "my-cluster-control-plane-id2"
"Name": "my-cluster-control-plane-id3"
```
Setiap instance dicemari `node-role.eks-local.amazonaws.com/control-plane` sehingga tidak ada beban kerja yang dijadwalkan pada instance bidang kontrol. Untuk informasi selengkapnya tentang taints, lihat [Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) dalam dokumentasi Kubernetes. Amazon EKS terus memantau keadaan cluster lokal. Kami melakukan tindakan manajemen otomatis, seperti patch keamanan dan memperbaiki instans yang tidak sehat. Ketika cluster lokal terputus dari cloud, kami menyelesaikan tindakan untuk memastikan bahwa klaster diperbaiki ke keadaan sehat setelah tersambung kembali.
1. Jika Anda membuat cluster Anda menggunakan`eksctl`, maka Anda dapat melewati langkah ini. `eksctl`Selesaikan langkah ini untuk Anda. Aktifkan `kubectl` untuk berkomunikasi dengan cluster Anda dengan menambahkan konteks baru ke `kubectl` `config` file. Untuk petunjuk 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. Untuk terhubung ke server API Kubernetes kluster lokal Anda, dapatkan akses ke gateway lokal untuk subnet, atau sambungkan dari dalam VPC. Untuk informasi selengkapnya tentang menghubungkan rak Outpost ke jaringan lokal, lihat [Cara kerja gateway lokal untuk rak di](https://docs.aws.amazon.com/outposts/latest/userguide/how-racks-work.html) Panduan Pengguna Outposts. AWS Jika Anda menggunakan Direct VPC Routing dan subnet Outpost memiliki rute ke gateway lokal Anda, alamat IP pribadi dari instans control plane Kubernetes secara otomatis disiarkan melalui jaringan lokal Anda. Titik akhir server Kubernetes API cluster lokal di-host di Amazon Route 53 (Route 53). Endpoint layanan API dapat diselesaikan oleh server DNS publik ke alamat IP pribadi server Kubernetes API.
Instance bidang kontrol Kubernetes cluster lokal dikonfigurasi dengan antarmuka jaringan elastis statis dengan alamat IP pribadi tetap yang tidak berubah sepanjang siklus hidup klaster. Mesin yang berinteraksi dengan server API Kubernetes mungkin tidak memiliki konektivitas ke Route 53 selama jaringan terputus. Jika ini masalahnya, kami sarankan untuk mengonfigurasi `/etc/hosts` dengan alamat IP pribadi statis untuk operasi lanjutan. Kami juga merekomendasikan untuk menyiapkan server DNS lokal dan menghubungkannya ke Outpost Anda. Untuk informasi selengkapnya, lihat [AWS dokumentasi Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns). Jalankan perintah berikut untuk mengonfirmasi bahwa komunikasi telah dibuat dengan cluster Anda.
```
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
```
1. (Opsional) Uji otentikasi ke klaster lokal Anda saat dalam status terputus dari Cloud. AWS Untuk petunjuk, lihat [Siapkan kluster Amazon EKS lokal di AWS Outposts untuk pemutusan jaringan](eks-outposts-network-disconnects.md).
### Sumber daya internal
Amazon EKS membuat sumber daya berikut di cluster Anda. Sumber dayanya untuk penggunaan internal Amazon EKS. Agar klaster berfungsi dengan baik, jangan mengedit atau memodifikasi sumber daya ini.
+ [Pod cermin](https://kubernetes.io/docs/reference/glossary/?all=true#term-mirror-pod) berikut:
+ `aws-iam-authenticator-node-hostname `
+ `eks-certificates-controller-node-hostname `
+ `etcd-node-hostname `
+ `kube-apiserver-node-hostname `
+ `kube-controller-manager-node-hostname `
+ `kube-scheduler-node-hostname `
+ Pengaya yang dikelola sendiri berikut ini:
+ `kube-system/coredns`
+ `kube-system/``kube-proxy`(tidak dibuat sampai Anda menambahkan node pertama Anda)
+ `kube-system/aws-node`(tidak dibuat sampai Anda menambahkan node pertama Anda). Cluster lokal menggunakan plugin Amazon VPC CNI untuk plugin Kubernetes untuk jaringan cluster. Jangan mengubah konfigurasi untuk instance control plane (Pod bernama`aws-node-controlplane-*`). Ada variabel konfigurasi yang dapat Anda gunakan untuk mengubah nilai default ketika plugin membuat antarmuka jaringan baru. Untuk informasi lebih lanjut, lihat [dokumentasi](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) di GitHub.
+ Layanan berikut:
+ `default/kubernetes`
+ `kube-system/kube-dns`
+ Sebuah `PodSecurityPolicy` bernama `eks.system`
+ Sebuah `ClusterRole` bernama `eks:system:podsecuritypolicy`
+ Sebuah `ClusterRoleBinding` bernama `eks:system`
+ Selain [grup keamanan cluster](sec-group-reqs.md), Amazon EKS membuat grup keamanan di AWS akun Anda yang diberi nama`eks-local-internal-do-not-use-or-edit-cluster-name-uniqueid `. Grup keamanan ini memungkinkan lalu lintas mengalir bebas di antara komponen Kubernetes yang berjalan pada instance control plane.
Langkah selanjutnya yang disarankan:
+ [Berikan prinsipal IAM yang membuat klaster izin yang diperlukan untuk melihat sumber daya Kubernetes di Konsol Manajemen AWS](view-kubernetes-resources.md#view-kubernetes-resources-permissions)
+ [Berikan akses entitas IAM ke klaster Anda](grant-k8s-access.md). Jika Anda ingin entitas melihat resource Kubernetes di konsol Amazon EKS, berikan [izin yang Diperlukan](view-kubernetes-resources.md#view-kubernetes-resources-permissions) ke entitas.
+ [Konfigurasikan logging untuk klaster Anda](control-plane-logs.md)
+ Biasakan diri Anda dengan apa yang terjadi selama [pemutusan jaringan.](eks-outposts-network-disconnects.md)
+ [Tambahkan node ke cluster Anda](eks-outposts-self-managed-nodes.md)
+ Pertimbangkan untuk menyiapkan rencana cadangan untuk Anda`etcd`. Amazon EKS tidak mendukung pencadangan dan pemulihan otomatis `etcd` untuk kluster lokal. Untuk informasi selengkapnya, lihat [Mencadangkan klaster etcd](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) di dokumentasi Kubernetes. Dua opsi utama digunakan `etcdctl` untuk mengotomatiskan pengambilan snapshot atau menggunakan cadangan volume penyimpanan Amazon EBS.
# Pelajari versi platform Kubernetes dan Amazon EKS untuk Outposts AWS
Versi platform cluster lokal mewakili kemampuan cluster Amazon EKS di AWS Outposts. Versi-versi tersebut menyertakan komponen yang berjalan pada control plane Kubernetes, dimana flag server API Kubernetes diaktifkan. Mereka juga menyertakan versi patch Kubernetes saat ini. Setiap versi minor Kubernetes memiliki satu atau lebih versi platform terkait. Versi platform untuk versi minor Kubernetes yang berbeda bersifat independen. Versi platform untuk cluster lokal dan kluster Amazon EKS di cloud bersifat independen.
Ketika versi minor Kubernetes baru tersedia untuk klaster lokal, seperti`1.31`, versi platform awal untuk versi minor Kubernetes dimulai pada. `eks-local-outposts.1` Namun, Amazon EKS merilis versi platform baru secara berkala guna mengaktifkan pengaturan pesawat kendali Kubernetes baru dan untuk menyediakan perbaikan keamanan.
Saat versi platform cluster lokal baru tersedia untuk versi minor:
+ Nomor versi platform bertambah (`eks-local-outposts.n+1`).
+ Amazon EKS secara otomatis memperbarui semua cluster lokal yang ada ke versi platform terbaru untuk versi minor Kubernetes yang sesuai. Pembaruan otomatis versi platform yang ada diluncurkan secara bertahap. Proses roll-out terdiri dari penggantian instans control plane Kubernetes terkelola yang berjalan di Outpost, satu per satu, hingga ketiga instans diganti dengan yang baru.
+ Proses penggantian instans pesawat kontrol Kubernetes akan berhenti berkembang jika ada risiko gangguan layanan. Amazon EKS hanya akan mencoba mengganti instance jika 2 instance control-plane Kubernetes lainnya sehat dan melewati semua kondisi kesiapan sebagai node cluster.
+ Peluncuran versi platform biasanya akan memakan waktu kurang dari 30 menit untuk menyelesaikannya. Jika klaster tetap dalam `UPDATING` status untuk jangka waktu yang lama, lihat [Memecahkan masalah cluster Amazon EKS lokal di Outposts AWS](eks-outposts-troubleshooting.md) dan cari bantuan dari AWS Support. Jangan pernah menghentikan instance control-plane Kubernetes secara manual kecuali diinstruksikan oleh Support. AWS
+ Amazon EKS boleh menerbitkan AMI simpul baru dengan versi patch yang sesuai. Semua versi patch kompatibel antara bidang kontrol Kubernetes dan node AMIs untuk satu versi minor Kubernetes.
Versi platform baru tidak memperkenalkan perubahan yang melanggar atau menyebabkan gangguan layanan.
Cluster lokal selalu dibuat dengan versi platform terbaru yang tersedia (`eks-local-outposts.n`) untuk versi Kubernetes yang ditentukan.
Versi platform saat ini dan terbaru dijelaskan dalam tabel berikut.
Untuk menerima pemberitahuan semua perubahan file sumber ke halaman dokumentasi khusus ini, Anda dapat berlangganan URL berikut dengan pembaca RSS:
```
https://github.com/awsdocs/amazon-eks-user-guide/commits/mainline/latest/ug/outposts/eks-outposts-platform-versions.adoc.atom
```
## Versi Kubernetes `1.31`
Pengontrol penerimaan berikut diaktifkan untuk semua versi `1.31` platform:`CertificateApproval`,,,`CertificateSigning`,`CertificateSubjectRestriction`,`ClusterTrustBundleAttest`,`DefaultIngressClass`,,`DefaultStorageClass`,`DefaultTolerationSeconds`,`ExtendedResourceToleration`,`LimitRanger`,`MutatingAdmissionWebhook`,`NamespaceLifecycle`,`NodeRestriction`,`PersistentVolumeClaimResize`,`PodSecurity`,`Priority`,`ResourceQuota`,`RuntimeClass`,`ServiceAccount`,`StorageObjectInUseProtection`, `TaintNodesByCondition``ValidatingAdmissionPolicy`, dan`ValidatingAdmissionWebhook`.
| Versi Kubernetes | Amazon EKS versi platform | Catatan rilis | Tanggal rilis |
| --- | --- | --- | --- |
| `1.31.14` | `eks-local-outposts.8` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.31.14` AWS IAM Authenticator diperbarui ke. `v0.7.8` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.4` Versi bottlerocket diperbarui ke. `v1.52.0` | Desember 23, 2025 |
| `1.31.12` | `eks-local-outposts.5` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.31.10` AWS IAM Authenticator diperbarui ke. `v0.7.4` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.2` Versi bottlerocket diperbarui ke. `v1.47.0` | Oktober 3, 2025 |
| `1.31.9` | `eks-local-outposts.4` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.31.9` AWS IAM Authenticator diperbarui ke. `v0.7.2` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke versi Bottlerocket diperbarui ke. `v1.20.0` `v1.43.0` | Agustus 9, 2025 |
| `1.31.7` | `eks-local-outposts.3` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.31.9` AWS IAM Authenticator diperbarui ke. `v0.7.1` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.19.5` Versi bottlerocket diperbarui ke. `v1.40.0` | Juni 19, 2025 |
| `1.31.6` | `eks-local-outposts.2` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. Versi bottlerocket diperbarui ke. `v1.36.0` | April 24, 2025 |
| `1.31.6` | `eks-local-outposts.1` | Rilis awal versi Kubernetes untuk cluster Amazon EKS `v1.31` lokal di Outposts. | April 9, 2025 |
## Versi Kubernetes `1.30`
Pengontrol penerimaan berikut diaktifkan untuk semua versi `1.30` platform:`CertificateApproval`,,,`CertificateSigning`,`CertificateSubjectRestriction`,`ClusterTrustBundleAttest`,`DefaultIngressClass`,,`DefaultStorageClass`,`DefaultTolerationSeconds`,`ExtendedResourceToleration`,`LimitRanger`,`MutatingAdmissionWebhook`,`NamespaceLifecycle`,`NodeRestriction`,`PersistentVolumeClaimResize`,`PodSecurity`,`Priority`,`ResourceQuota`,`RuntimeClass`,`ServiceAccount`,`StorageObjectInUseProtection`, `TaintNodesByCondition``ValidatingAdmissionPolicy`, dan`ValidatingAdmissionWebhook`.
| Versi Kubernetes | Amazon EKS versi platform | Catatan rilis | Tanggal rilis |
| --- | --- | --- | --- |
| `1.30.14` | `eks-local-outposts.10` | Versi platform baru dengan perbaikan keamanan dan penyempurnaan. AWS IAM Authenticator diperbarui ke. `v0.7.8` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.4` Versi bottlerocket diperbarui ke. `v1.52.0` | Desember 23, 2025 |
| `1.30.14` | `eks-local-outposts.7` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.30.14` AWS IAM Authenticator diperbarui ke. `v0.7.4` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.2` Versi bottlerocket diperbarui ke. `v1.47.0` | Oktober 3, 2025 |
| `1.30.13` | `eks-local-outposts.6` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.30.13` AWS IAM Authenticator diperbarui ke. `v0.7.2` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.0` Versi bottlerocket diperbarui ke. `v1.43.0` | Agustus 09, 2025 |
| `1.30.11` | `eks-local-outposts.5` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.30.11` AWS IAM Authenticator diperbarui ke. `v0.7.1` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke versi Bottlerocket diperbarui ke. `v1.19.5` `v1.40.0` | Juni 19, 2025 |
| `1.30.10` | `eks-local-outposts.4` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. Versi bottlerocket diperbarui ke. `v1.36.0` | April 24, 2025 |
| `1.30.10` | `eks-local-outposts.3` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.30.10` AWS IAM Authenticator diperbarui ke. `v0.6.29` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.19.2` CoreDNS diperbarui ke. `v1.11.4` AWS Cloud Controller Manager diperbarui ke`v1.30.8`. Versi bottlerocket diperbarui ke. `v1.34.0` | Maret 27, 2025 |
| `1.30.7` | `eks-local-outposts.2` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.30.7` AWS IAM Authenticator diperbarui ke. `v0.6.28` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.19.0` Diperbarui versi Bottlerocket ke. `v1.29.0` | Januari 10, 2025 |
| `1.30.5` | `eks-local-outposts.1` | Rilis awal versi Kubernetes untuk cluster Amazon EKS `v1.30` lokal di Outposts. | November 13, 2024 |
## Versi Kubernetes `1.29`
Pengontrol penerimaan berikut diaktifkan untuk semua versi `1.29` platform:`CertificateApproval`,,,`CertificateSigning`,`CertificateSubjectRestriction`,`ClusterTrustBundleAttest`,`DefaultIngressClass`,,`DefaultStorageClass`,`DefaultTolerationSeconds`,`ExtendedResourceToleration`,`LimitRanger`,`MutatingAdmissionWebhook`,`NamespaceLifecycle`,`NodeRestriction`,`PersistentVolumeClaimResize`,`PodSecurity`,`Priority`,`ResourceQuota`,`RuntimeClass`,`ServiceAccount`,`StorageObjectInUseProtection`, `TaintNodesByCondition``ValidatingAdmissionPolicy`, dan`ValidatingAdmissionWebhook`.
| Versi Kubernetes | Amazon EKS versi platform | Catatan rilis | Tanggal rilis |
| --- | --- | --- | --- |
| `1.29.15` | `eks-local-outposts.13` | Versi platform baru dengan perbaikan keamanan dan penyempurnaan. AWS IAM Authenticator diperbarui ke. `v0.7.8` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.4` Versi bottlerocket diperbarui ke. `v1.52.0` | Desember 23, 2025 |
| `v1.29.15` | `eks-local-outposts.10` | Versi platform baru dengan perbaikan keamanan dan penyempurnaan. AWS IAM Authenticator diperbarui ke. `v0.7.4` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.2` Versi bottlerocket diperbarui ke. `v1.47.0` | Oktober 3, 2025 |
| `v1.29.15` | `eks-local-outposts.9` | Versi platform baru dengan perbaikan keamanan dan penyempurnaan. AWS IAM Authenticator diperbarui ke. `v0.7.2` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.20.0` Versi bottlerocket diperbarui ke. `v1.43.0` | Agustus 9, 2025 |
| `v1.29.15` | `eks-local-outposts.8` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.29.15` AWS IAM Authenticator diperbarui ke. `v0.7.1` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.19.5` Versi bottlerocket diperbarui ke. `v1.40.0` | Juni 19, 2025 |
| `v1.29.14` | `eks-local-outposts.7` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. Versi bottlerocket diperbarui ke. `v1.36.0` | Maret 24, 2025 |
| `v1.29.14` | `eks-local-outposts.6` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.29.14` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.19.2` CoreDNS diperbarui ke. `v1.11.4` AWS Cloud Controller Manager diperbarui ke`v1.29.8`. Versi bottlerocket diperbarui ke. `v1.34.0` | Maret 27, 2025 |
| `v1.29.11` | `eks-local-outposts.5` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.29.11` Plugin Amazon VPC CNI untuk Kubernetes diperbarui ke. `v1.19.0` Diperbarui gambar CoreDNS ke. `v1.11.3` Diperbarui versi Bottlerocket ke. `v1.29.0` | Januari 10, 2025 |
| `1.29.9` | `eks-local-outposts.4` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. kube-proxy diperbarui ke. `v1.29.9` AWS IAM Authenticator diperbarui ke. `v0.6.26` Diperbarui versi Bottlerocket ke. `v1.26.0` | November 8, 2024 |
| `1.29.6` | `eks-local-outposts.3` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. Diperbarui versi Bottlerocket ke. `v1.22.0` | Oktober 22, 2024 |
| `1.29.6` | `eks-local-outposts.2` | Versi platform baru dengan perbaikan dan penyempurnaan keamanan. Diperbarui versi Bottlerocket ke. `v1.21.0` | Agustus 27, 2024 |
| `1.29.6` | `eks-local-outposts.1` | Rilis awal versi Kubernetes untuk cluster Amazon EKS `v1.29` lokal di Outposts. | Agustus 20, 2024 |
# Buat VPC dan subnet untuk cluster Amazon EKS di Outposts AWS
Saat membuat cluster lokal, Anda menentukan VPC dan setidaknya satu subnet pribadi yang berjalan di Outposts. Topik ini memberikan gambaran umum tentang persyaratan dan pertimbangan VPC dan subnet untuk klaster lokal Anda.
## Persyaratan dan pertimbangan VPC
Saat Anda membuat klaster lokal, VPC yang Anda tentukan harus memenuhi persyaratan dan pertimbangan berikut:
+ Pastikan VPC memiliki cukup alamat IP untuk cluster lokal, node apa pun, dan sumber daya Kubernetes lainnya yang ingin Anda buat. Jika VPC yang ingin Anda gunakan tidak memiliki cukup alamat IP, tingkatkan jumlah alamat IP yang tersedia. Anda dapat melakukan ini dengan [mengaitkan blok Classless Inter-Domain Routing (CIDR) tambahan](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-vpcs.html#add-ipv4-cidr) dengan VPC Anda. Anda dapat mengaitkan blok CIDR pribadi (RFC 1918) dan publik (non-RFC 1918) ke VPC Anda baik sebelum atau setelah Anda membuat cluster Anda. Diperlukan waktu cluster hingga 5 jam agar blok CIDR yang Anda kaitkan dengan VPC dikenali.
+ VPC tidak dapat menetapkan awalan IP atau blok CIDR. IPv6 Karena kendala ini, informasi yang tercakup dalam [Menetapkan lebih banyak alamat IP ke node Amazon EKS dengan awalan](cni-increase-ip-addresses.md) dan [Pelajari tentang IPv6 alamat ke klaster, Pod, dan layanan](cni-ipv6.md) tidak berlaku untuk VPC Anda.
+ VPC memiliki nama host DNS dan resolusi DNS diaktifkan. Tanpa fitur-fitur ini, cluster lokal gagal dibuat, dan Anda perlu mengaktifkan fitur dan membuat ulang cluster Anda. Untuk informasi selengkapnya, lihat [atribut DNS untuk VPC Anda](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html) di Panduan Pengguna Amazon VPC.
+ Untuk mengakses kluster lokal Anda melalui jaringan lokal Anda, VPC harus dikaitkan dengan tabel rute gateway lokal Outpost Anda. Untuk informasi selengkapnya, lihat [asosiasi VPC](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html#vpc-associations) di Panduan Pengguna AWS Outposts.
## Persyaratan dan pertimbangan subnet
Saat Anda membuat cluster, tentukan setidaknya satu subnet pribadi. Jika Anda menentukan lebih dari satu subnet, instance bidang kontrol Kubernetes didistribusikan secara merata di seluruh subnet. Jika lebih dari satu subnet ditentukan, subnet harus ada di Outpost yang sama. Selain itu, subnet juga harus memiliki rute yang tepat dan izin grup keamanan untuk berkomunikasi satu sama lain. Saat Anda membuat cluster lokal, subnet yang Anda tentukan harus memenuhi persyaratan berikut:
+ Subnet semuanya berada di Outpost logis yang sama.
+ Subnet bersama-sama memiliki setidaknya tiga alamat IP yang tersedia untuk instance control plane Kubernetes. Jika tiga subnet ditentukan, setiap subnet harus memiliki setidaknya satu alamat IP yang tersedia. Jika dua subnet ditentukan, setiap subnet harus memiliki setidaknya dua alamat IP yang tersedia. Jika satu subnet ditentukan, subnet harus memiliki setidaknya tiga alamat IP yang tersedia.
+ Subnet memiliki rute ke [gateway lokal](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-local-gateways.html) rak Outpost untuk mengakses server API Kubernetes melalui jaringan lokal Anda. Jika subnet tidak memiliki rute ke gateway lokal rak Outpost, Anda harus berkomunikasi dengan server API Kubernetes Anda dari dalam VPC.
+ Subnet harus menggunakan penamaan berbasis alamat IP. EC2 [Penamaan berbasis sumber daya](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-naming.html#instance-naming-rbn) Amazon tidak didukung oleh Amazon EKS.
## Akses subnet ke layanan AWS
Subnet pribadi cluster lokal di Outposts harus dapat berkomunikasi dengan AWS layanan Regional. [Anda dapat mencapai ini dengan menggunakan [gateway NAT](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) untuk akses internet keluar atau, jika Anda ingin menjaga semua lalu lintas pribadi dalam VPC Anda, menggunakan titik akhir VPC antarmuka.](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html)
### Menggunakan gateway NAT
Subnet pribadi cluster lokal di Outposts harus memiliki tabel rute terkait yang memiliki rute ke gateway NAT di subnet publik yang berada di Availability Zone induk Outpost. Subnet publik harus memiliki rute ke [gateway internet](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html). Gateway NAT memungkinkan akses internet keluar dan mencegah koneksi masuk yang tidak diminta dari internet ke instance di Outpost.
### Menggunakan VPC endpoint antarmuka
Jika subnet pribadi cluster lokal di Outposts tidak memiliki koneksi internet keluar, atau jika Anda ingin menjaga semua lalu lintas pribadi dalam VPC Anda, maka Anda harus membuat titik akhir VPC antarmuka berikut [dan titik akhir gateway](https://docs.aws.amazon.com/vpc/latest/privatelink/gateway-endpoints.html) di subnet Regional sebelum membuat cluster Anda.
| Titik Akhir | Jenis titik akhir |
| --- | --- |
| `com.amazonaws.region-code.ssm` | Antarmuka |
| `com.amazonaws.region-code.ssmmessages` | Antarmuka |
| `com.amazonaws.region-code.ec2messages` | Antarmuka |
| `com.amazonaws.region-code.ec2` | Antarmuka |
| `com.amazonaws.region-code.secretsmanager` | Antarmuka |
| `com.amazonaws.region-code.logs` | Antarmuka |
| `com.amazonaws.region-code.sts` | Antarmuka |
| `com.amazonaws.region-code.ecr.api` | Antarmuka |
| `com.amazonaws.region-code.ecr.dkr` | Antarmuka |
| `com.amazonaws.region-code.s3` | Gateway |
Titik akhir harus memenuhi persyaratan berikut:
+ Dibuat di subnet pribadi yang terletak di Availability Zone induk Outpost Anda
+ Miliki nama DNS pribadi diaktifkan
+ Memiliki grup keamanan terlampir yang memungkinkan lalu lintas HTTPS masuk dari kisaran CIDR dari subnet pos terdepan pribadi.
Membuat titik akhir menimbulkan biaya. Untuk informasi selengkapnya, lihat [harga AWS PrivateLink ](https://aws.amazon.com/privatelink/pricing/). Jika Pod Anda memerlukan akses ke AWS layanan lain, maka Anda perlu membuat titik akhir tambahan. 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).
## Buat VPC
Anda dapat membuat VPC yang memenuhi persyaratan sebelumnya menggunakan salah satu templat berikut: AWS CloudFormation
+ **[Template 1](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2022-09-20/amazon-eks-local-outposts-vpc-subnet.yaml)** - Template ini membuat VPC dengan satu subnet pribadi di Outpost dan satu subnet publik di Wilayah. AWS Subnet pribadi memiliki rute ke internet melalui NAT Gateway yang berada di subnet publik di Wilayah. AWS Template ini dapat digunakan untuk membuat cluster lokal di subnet dengan akses internet jalan keluar.
+ **[Template 2](https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2023-03-20/amazon-eks-local-outposts-fully-private-vpc-subnet.yaml)** — Template ini membuat VPC dengan satu subnet pribadi di Outpost dan set minimum VPC Endpoint yang diperlukan untuk membuat cluster lokal di subnet yang tidak memiliki akses internet ingress atau egress (juga disebut sebagai subnet pribadi).
# Siapkan kluster Amazon EKS lokal di AWS Outposts untuk pemutusan jaringan
Jika jaringan lokal Anda kehilangan konektivitas dengan AWS Cloud, Anda dapat terus menggunakan kluster Amazon EKS lokal Anda di Outpost. Topik ini mencakup bagaimana Anda dapat mempersiapkan cluster lokal Anda untuk pemutusan jaringan dan pertimbangan terkait.
+ Cluster lokal memungkinkan stabilitas dan operasi lanjutan selama pemutusan jaringan sementara yang tidak direncanakan. AWS Outposts tetap merupakan penawaran yang terhubung penuh yang bertindak sebagai perpanjangan AWS Cloud di pusat data Anda. Jika jaringan terputus antara Outpost dan AWS Cloud Anda, kami sarankan untuk mencoba memulihkan koneksi Anda. *Untuk instruksi, lihat [daftar periksa pemecahan masalah jaringan rak AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/network-troubleshoot.html) di Panduan Pengguna Outposts. AWS * Untuk informasi selengkapnya tentang cara memecahkan masalah dengan kluster lokal, lihat. [Memecahkan masalah cluster Amazon EKS lokal di Outposts AWS](eks-outposts-troubleshooting.md)
+ Outposts memancarkan `ConnectedStatus` metrik yang dapat Anda gunakan untuk memantau status konektivitas Outpost Anda. *Untuk informasi selengkapnya, lihat [Metrik Outposts di Panduan](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-cloudwatch-metrics.html#outposts-metrics) Pengguna Outposts AWS .*
+ Cluster lokal menggunakan IAM sebagai mekanisme autentikasi default menggunakan [AWS Identity and Access Management authenticator](https://github.com/kubernetes-sigs/aws-iam-authenticator) untuk Kubernetes. IAM tidak tersedia selama pemutusan jaringan. Jadi, cluster lokal mendukung mekanisme otentikasi alternatif menggunakan `x.509` sertifikat yang dapat Anda gunakan untuk terhubung ke cluster Anda selama pemutusan jaringan. Untuk informasi tentang cara mendapatkan dan menggunakan `x.509` sertifikat untuk klaster Anda, lihat[Mengautentikasi ke cluster lokal Anda selama pemutusan jaringan](#outposts-network-disconnects-authentication).
+ Jika Anda tidak dapat mengakses Route 53 selama pemutusan jaringan, pertimbangkan untuk menggunakan server DNS lokal di lingkungan lokal Anda. Instance control plane Kubernetes menggunakan alamat IP statis. Anda dapat mengonfigurasi host yang Anda gunakan untuk terhubung ke cluster Anda dengan nama host endpoint dan alamat IP sebagai alternatif untuk menggunakan server DNS lokal. Untuk informasi selengkapnya, lihat [DNS](https://docs.aws.amazon.com/outposts/latest/userguide/how-outposts-works.html#dns) di Panduan * AWS Pengguna Outposts*.
+ Jika Anda mengharapkan peningkatan lalu lintas aplikasi selama pemutusan jaringan, Anda dapat menyediakan kapasitas komputasi cadangan di cluster Anda saat terhubung ke cloud. EC2 Instans Amazon sudah termasuk dalam harga AWS Outposts. Jadi, menjalankan instance cadangan tidak memengaruhi biaya AWS penggunaan Anda.
+ Selama pemutusan jaringan untuk mengaktifkan operasi pembuatan, pembaruan, dan skala untuk beban kerja, gambar kontainer aplikasi Anda harus dapat diakses melalui jaringan lokal dan cluster Anda harus memiliki kapasitas yang cukup. Cluster lokal tidak meng-host registri kontainer untuk Anda. Jika Pod sebelumnya telah berjalan pada node tersebut, image kontainer akan di-cache pada node. Jika Anda biasanya menarik gambar kontainer aplikasi Anda dari Amazon ECR di cloud, pertimbangkan untuk menjalankan cache atau registri lokal. Cache atau registri lokal sangat membantu jika Anda memerlukan operasi buat, perbarui, dan skala untuk sumber daya beban kerja selama pemutusan jaringan.
+ Cluster lokal menggunakan Amazon EBS sebagai kelas penyimpanan default untuk volume persisten dan driver Amazon EBS CSI untuk mengelola siklus hidup volume persisten Amazon EBS. Selama pemutusan jaringan, Pod yang didukung oleh Amazon EBS tidak dapat dibuat, diperbarui, atau diskalakan. Ini karena operasi ini memerlukan panggilan ke Amazon EBS API di cloud. Jika Anda menerapkan beban kerja stateful pada kluster lokal dan memerlukan operasi pembuatan, pembaruan, atau skala selama pemutusan jaringan, pertimbangkan untuk menggunakan mekanisme penyimpanan alternatif.
+ Snapshot Amazon EBS tidak dapat dibuat atau dihapus jika AWS Outposts tidak dapat mengakses AWS wilayah yang relevan APIs (seperti untuk APIs Amazon EBS atau Amazon S3).
+ Saat mengintegrasikan ALB (Ingress) dengan AWS Certificate Manager (ACM), sertifikat didorong dan disimpan dalam memori instance Outposts AWS ALB Compute. Penghentian TLS saat ini akan terus beroperasi jika terjadi pemutusan hubungan dari Wilayah. AWS Operasi mutasi dalam konteks ini akan gagal (seperti definisi ingress baru, operasi API sertifikat berbasis ACM baru, skala komputasi ALB, atau rotasi sertifikat). Untuk informasi selengkapnya, lihat [Memecahkan masalah perpanjangan sertifikat terkelola di Panduan Pengguna AWS](https://docs.aws.amazon.com/acm/latest/userguide/troubleshooting-renewal.html) *Certificate Manager*.
+ Log bidang kontrol Amazon EKS di-cache secara lokal pada instance bidang kontrol Kubernetes selama pemutusan jaringan. Setelah tersambung kembali, log dikirim ke CloudWatch Log di AWS Wilayah induk. Anda dapat menggunakan solusi mitra [Prometheus](https://prometheus.io/), [Grafana](https://grafana.com/), atau Amazon EKS untuk memantau klaster secara lokal menggunakan titik akhir metrik server Kubernetes API atau menggunakan Fluent Bit untuk log.
+ Jika Anda menggunakan AWS Load Balancer Controller di Outposts untuk lalu lintas aplikasi, Pod yang ada di depan oleh Load Balancer AWS Controller akan terus menerima lalu lintas selama jaringan terputus. Pod baru yang dibuat selama pemutusan jaringan tidak menerima lalu lintas hingga Outpost tersambung kembali ke Cloud. AWS Pertimbangkan untuk mengatur jumlah replika untuk aplikasi Anda saat terhubung ke AWS Cloud untuk mengakomodasi kebutuhan penskalaan Anda selama pemutusan jaringan.
+ [Plugin Amazon VPC CNI untuk Kubernetes default ke mode IP sekunder.](https://aws.github.io/aws-eks-best-practices/networking/vpc-cni/#overview) Ini dikonfigurasi dengan `WARM_ENI_TARGET` =`1`, yang memungkinkan plugin untuk menjaga “full elastic network interface” dari alamat IP yang tersedia. Pertimbangkan untuk mengubah`WARM_ENI_TARGET`,`WARM_IP_TARGET`, dan `MINIMUM_IP_TARGET` nilai sesuai dengan kebutuhan penskalaan Anda selama keadaan terputus. Untuk informasi selengkapnya, lihat file [readme](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/README.md) untuk plugin di GitHub. Untuk daftar jumlah maksimum Pod yang didukung oleh setiap jenis instans, lihat [eni-max-podsfile.txt](https://github.com/aws/amazon-vpc-cni-k8s/blob/master/misc/eni-max-pods.txt) di. GitHub
## Mengautentikasi ke cluster lokal Anda selama pemutusan jaringan
AWS Identity and Access Management (IAM) tidak tersedia selama pemutusan jaringan. Anda tidak dapat mengautentikasi ke klaster lokal menggunakan kredensyal IAM saat terputus. Namun, Anda dapat terhubung ke cluster Anda melalui jaringan lokal Anda menggunakan `x509` sertifikat saat terputus. Anda perlu mengunduh dan menyimpan `X509` sertifikat klien untuk digunakan selama pemutusan sambungan. Dalam topik ini, Anda mempelajari cara membuat dan menggunakan sertifikat untuk mengautentikasi ke klaster Anda saat berada dalam keadaan terputus.
1. Buat permintaan penandatanganan sertifikat.
1. Buat permintaan penandatanganan sertifikat.
```
openssl req -new -newkey rsa:4096 -nodes -days 365 \
-keyout admin.key -out admin.csr -subj "/CN=admin"
```
1. Buat permintaan penandatanganan sertifikat di Kubernetes.
```
BASE64_CSR=$(cat admin.csr | base64 -w 0)
cat << EOF > admin-csr.yaml
apiVersion: certificates.k8s.io/v1
kind: CertificateSigningRequest
metadata:
name: admin-csr
spec:
signerName: kubernetes.io/kube-apiserver-client
request: ${BASE64_CSR}
usages:
- client auth
EOF
```
1. Buat permintaan penandatanganan sertifikat menggunakan`kubectl`.
```
kubectl create -f admin-csr.yaml
```
1. Periksa status permintaan penandatanganan sertifikat.
```
kubectl get csr admin-csr
```
Contoh output adalah sebagai berikut.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Pending
```
Kubernetes membuat permintaan penandatanganan sertifikat.
1. Menyetujui permintaan penandatanganan sertifikat.
```
kubectl certificate approve admin-csr
```
1. Periksa kembali status permintaan penandatanganan sertifikat untuk persetujuan.
```
kubectl get csr admin-csr
```
Contoh output adalah sebagai berikut.
```
NAME AGE REQUESTOR CONDITION
admin-csr 11m kubernetes-admin Approved
```
1. Ambil dan verifikasi sertifikat.
1. Ambil sertifikat.
```
kubectl get csr admin-csr -o jsonpath='{.status.certificate}' | base64 --decode > admin.crt
```
1. Verifikasi sertifikat.
```
cat admin.crt
```
1. Buat pengikatan peran klaster untuk `admin` pengguna.
```
kubectl create clusterrolebinding admin --clusterrole=cluster-admin \
--user=admin --group=system:masters
```
1. Hasilkan kubeconfig dengan cakupan pengguna untuk status terputus.
Anda dapat membuat `kubeconfig` file menggunakan `admin` sertifikat yang diunduh. Ganti *my-cluster* dan *apiserver-endpoint* dalam perintah berikut.
```
aws eks describe-cluster --name my-cluster \
--query "cluster.certificateAuthority" \
--output text | base64 --decode > ca.crt
```
```
kubectl config --kubeconfig admin.kubeconfig set-cluster my-cluster \
--certificate-authority=ca.crt --server apiserver-endpoint --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-credentials admin \
--client-certificate=admin.crt --client-key=admin.key --embed-certs
```
```
kubectl config --kubeconfig admin.kubeconfig set-context admin@my-cluster \
--cluster my-cluster --user admin
```
```
kubectl config --kubeconfig admin.kubeconfig use-context admin@my-cluster
```
1. Lihat `kubeconfig` file Anda.
```
kubectl get nodes --kubeconfig admin.kubeconfig
```
1. Jika Anda memiliki layanan yang sudah diproduksi di Outpost Anda, lewati langkah ini. Jika Amazon EKS adalah satu-satunya layanan yang berjalan di Outpost Anda dan Outpost saat ini tidak dalam produksi, Anda dapat mensimulasikan pemutusan jaringan. Sebelum Anda masuk ke produksi dengan cluster lokal Anda, simulasikan pemutusan untuk memastikan bahwa Anda dapat mengakses klaster Anda saat berada dalam keadaan terputus.
1. Terapkan aturan firewall pada perangkat jaringan yang menghubungkan Outpost Anda ke AWS Wilayah. Ini memutus tautan layanan dari Outpost. Anda tidak dapat membuat instance baru. Saat ini instans yang sedang berjalan kehilangan konektivitas ke AWS Wilayah dan internet.
1. Anda dapat menguji koneksi ke cluster lokal Anda saat terputus menggunakan `x509` sertifikat. Pastikan untuk mengubah Anda `kubeconfig` ke `admin.kubeconfig` yang Anda buat pada langkah sebelumnya. Ganti *my-cluster* dengan nama cluster lokal Anda.
```
kubectl config use-context admin@my-cluster --kubeconfig admin.kubeconfig
```
Jika Anda melihat ada masalah dengan kluster lokal Anda saat berada dalam keadaan terputus, sebaiknya buka tiket dukungan.
# Pilih jenis instans dan grup penempatan untuk klaster Amazon EKS di AWS Outposts berdasarkan pertimbangan kapasitas
Topik ini memberikan panduan untuk memilih jenis instans bidang kontrol Kubernetes dan (opsional) menggunakan grup penempatan untuk memenuhi persyaratan ketersediaan tinggi untuk klaster Amazon EKS lokal Anda di Outpost.
Sebelum Anda memilih tipe instans (seperti`m5`,`c5`, atau`r5`) yang akan digunakan untuk control plane Kubernetes kluster lokal Anda di Outposts, konfirmasikan jenis instance yang tersedia pada konfigurasi Outpost Anda. Setelah Anda mengidentifikasi jenis instans yang tersedia, pilih ukuran instans (seperti `large``xlarge`,, atau`2xlarge`) berdasarkan jumlah node yang dibutuhkan beban kerja Anda. Tabel berikut memberikan rekomendasi untuk memilih ukuran instance.
**catatan**
Ukuran instans harus ditempatkan di Outposts Anda. Pastikan Anda memiliki kapasitas yang cukup untuk tiga contoh ukuran yang tersedia di Outposts Anda selama masa pakai cluster lokal Anda. Untuk daftar jenis EC2 instans Amazon yang tersedia, lihat bagian Komputasi dan penyimpanan di fitur rak [AWS Outposts](https://aws.amazon.com/outposts/rack/features/).
| Jumlah node | Ukuran instance bidang kontrol Kubernetes |
| --- | --- |
| 1—20 | `large` |
| 21—100 | `xlarge` |
| 101—250 | `2xlarge` |
| 251—500 | `4xlarge` |
Penyimpanan untuk bidang kontrol Kubernetes membutuhkan 246 GB penyimpanan Amazon EBS untuk setiap cluster lokal untuk memenuhi IOPS yang diperlukan. `etcd` Saat kluster lokal dibuat, volume Amazon EBS disediakan secara otomatis untuk Anda.
## Kontrol penempatan pesawat
Jika Anda tidak menentukan grup penempatan dengan `OutpostConfig.ControlPlanePlacement.GroupName` properti, EC2 instans Amazon yang disediakan untuk bidang kontrol Kubernetes Anda tidak menerima penegakan penempatan perangkat keras tertentu di seluruh kapasitas dasar yang tersedia di Outpost Anda.
Anda dapat menggunakan grup penempatan untuk memenuhi persyaratan ketersediaan tinggi untuk klaster Amazon EKS lokal Anda di Outpost. Dengan menentukan grup penempatan selama pembuatan klaster, Anda memengaruhi penempatan instance bidang kontrol Kubernetes. Instans tersebar di perangkat keras independen yang mendasari (rak atau host), meminimalkan dampak instance yang berkorelasi pada peristiwa kegagalan perangkat keras.
Jenis spread yang dapat Anda konfigurasi tergantung pada jumlah rak Outpost yang Anda miliki dalam penerapan Anda.
+ **Deployment dengan satu atau dua rak fisik dalam satu Outpost logis** — Anda harus memiliki setidaknya tiga host yang dikonfigurasi dengan tipe instans yang Anda pilih untuk instance control plane Kubernetes Anda. Grup penempatan *spread* menggunakan *spread tingkat host* memastikan bahwa semua instans pesawat kontrol Kubernetes berjalan pada host yang berbeda di dalam rak dasar yang tersedia dalam penyebaran Outpost Anda.
+ **Deployment dengan tiga atau lebih rak fisik dalam satu Outpost logis** — Anda harus memiliki setidaknya tiga host yang dikonfigurasi dengan tipe instans yang Anda pilih untuk instance control plane Kubernetes Anda. Grup penempatan *spread* menggunakan *spread tingkat rak* memastikan bahwa semua instance pesawat kontrol Kubernetes berjalan di rak yang berbeda dalam penerapan Outpost Anda. Anda dapat menggunakan grup penempatan *spread tingkat host* seperti yang dijelaskan pada opsi sebelumnya.
Anda bertanggung jawab untuk membuat grup penempatan yang diinginkan. Anda menentukan grup penempatan saat memanggil `CreateCluster` API. Untuk informasi selengkapnya tentang grup penempatan dan cara membuatnya, lihat [Grup Penempatan](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html) di Panduan EC2 Pengguna Amazon.
+ Ketika grup penempatan ditentukan, harus ada kapasitas slotted yang tersedia di Outpost Anda agar berhasil membuat kluster Amazon EKS lokal. Kapasitas bervariasi berdasarkan apakah Anda menggunakan tipe host atau rack spread. Jika tidak ada kapasitas yang cukup, cluster tetap dalam `Creating` keadaan. Anda dapat memeriksa `Insufficient Capacity Error` bidang kesehatan respons [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)API. Anda harus membebaskan kapasitas untuk proses penciptaan untuk maju.
+ Selama pembaruan platform cluster lokal dan versi Amazon EKS, instans control plane Kubernetes dari klaster Anda akan digantikan oleh instance baru menggunakan strategi pembaruan bergulir. Selama proses penggantian ini, setiap instance bidang kontrol dihentikan, membebaskan slotnya masing-masing. Sebuah instance baru yang diperbarui disediakan di tempatnya. Instance yang diperbarui dapat ditempatkan di slot yang dirilis. Jika slot dikonsumsi oleh instance lain yang tidak terkait dan tidak ada lagi kapasitas yang tersisa yang menghormati persyaratan topologi spread yang diperlukan, maka cluster tetap dalam keadaan. `Updating` Anda dapat melihat masing-masing `Insufficient Capacity Error` di bidang kesehatan respons [DescribeCluster](https://docs.aws.amazon.com/eks/latest/APIReference/API_DescribeCluster.html)API. Anda harus membebaskan kapasitas sehingga proses pembaruan dapat berkembang dan membangun kembali tingkat ketersediaan tinggi sebelumnya.
+ Anda dapat membuat maksimal 500 grup penempatan per akun di setiap AWS Wilayah. Untuk informasi selengkapnya, lihat [Aturan dan batasan umum](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups.html#placement-groups-limitations-general) di Panduan EC2 Pengguna Amazon.
# Memecahkan masalah cluster Amazon EKS lokal di Outposts AWS
Topik ini mencakup beberapa kesalahan umum yang mungkin Anda lihat saat menggunakan kluster lokal dan cara memecahkan masalah. Cluster lokal mirip dengan cluster Amazon EKS di cloud, tetapi ada beberapa perbedaan dalam cara mereka dikelola oleh Amazon EKS.
**penting**
Jangan pernah menghentikan instans `Kubernetes` pesawat kontrol kluster lokal EKS terkelola yang berjalan di Outpost kecuali diinstruksikan secara eksplisit oleh Support. AWS Mengakhiri instance ini menimbulkan risiko terhadap ketersediaan layanan klaster lokal, termasuk hilangnya klaster lokal jika beberapa instance dihentikan secara bersamaan. Instance `Kubernetes` bidang kontrol kluster lokal EKS diidentifikasi oleh tag `eks-local:controlplane-name` pada konsol instance. EC2
## Perilaku API
Cluster lokal dibuat melalui Amazon EKS API, tetapi dijalankan secara asinkron. Ini berarti bahwa permintaan ke Amazon EKS API segera dikembalikan untuk cluster lokal. Namun, permintaan ini mungkin berhasil, gagal cepat karena kesalahan validasi input, atau gagal dan memiliki kesalahan validasi deskriptif. Perilaku ini mirip dengan Kubernetes API.
Cluster lokal tidak bertransisi ke `FAILED` status. Amazon EKS mencoba untuk mendamaikan status cluster dengan status yang diinginkan pengguna secara berkelanjutan. Akibatnya, klaster lokal mungkin tetap berada dalam `CREATING` status untuk jangka waktu yang lama sampai masalah mendasar diselesaikan.
## Jelaskan bidang kesehatan cluster
Masalah klaster lokal dapat ditemukan menggunakan perintah AWS CLI Amazon EKS [CLI klaster deskripsikan](https://docs.aws.amazon.com/cli/latest/reference/eks/describe-cluster.html). Masalah cluster lokal muncul oleh `cluster.health` bidang respons `describe-cluster` perintah. Pesan yang terkandung dalam bidang ini mencakup kode kesalahan, pesan deskriptif, dan sumber daya IDs terkait. Informasi ini tersedia melalui Amazon EKS API dan AWS CLI saja. Dalam contoh berikut, ganti *my-cluster* dengan nama cluster lokal Anda.
```
aws eks describe-cluster --name my-cluster --query 'cluster.health'
```
Contoh output adalah sebagai berikut.
```
{
"issues": [
{
"code": "ConfigurationConflict",
"message": "The instance type 'm5.large' is not supported in Outpost 'my-outpost-arn'.",
"resourceIds": [
"my-cluster-arn"
]
}
]
}
```
Jika masalahnya tidak dapat diperbaiki, Anda mungkin perlu menghapus cluster lokal dan membuat yang baru. Misalnya, mencoba menyediakan cluster dengan tipe instance yang tidak tersedia di Outpost Anda. Tabel berikut mencakup kesalahan umum terkait kesehatan.
| Skenario kesalahan | Kode | Pesan | ResourceIds |
| --- | --- | --- | --- |
| Subnet yang disediakan tidak dapat ditemukan. | `ResourceNotFound` | `The subnet ID subnet-id does not exist` | Semua subnet yang disediakan IDs |
| Subnet yang disediakan bukan milik VPC yang sama. | `ConfigurationConflict` | `Subnets specified must belong to the same VPC` | Semua subnet yang disediakan IDs |
| Beberapa subnet yang disediakan bukan milik Outpost yang ditentukan. | `ConfigurationConflict` | `Subnet subnet-id expected to be in outpost-arn, but is in other-outpost-arn ` | ID subnet bermasalah |
| Beberapa subnet yang disediakan bukan milik Pos Luar mana pun. | `ConfigurationConflict` | `Subnet subnet-id is not part of any Outpost` | ID subnet bermasalah |
| Beberapa subnet yang disediakan tidak memiliki cukup alamat gratis untuk membuat antarmuka jaringan elastis untuk instance bidang kontrol. | `ResourceLimitExceeded` | `The specified subnet does not have enough free addresses to satisfy the request.` | ID subnet bermasalah |
| Jenis instans bidang kontrol yang ditentukan tidak didukung di Outpost Anda. | `ConfigurationConflict` | `The instance type type is not supported in Outpost outpost-arn ` | ARN klaster |
| Anda menghentikan EC2 instans Amazon bidang kontrol atau `run-instance` berhasil, tetapi status yang diamati berubah menjadi. `Terminated` Ini dapat terjadi untuk jangka waktu tertentu setelah Outpost Anda terhubung kembali dan kesalahan internal Amazon EBS menyebabkan alur kerja EC2 internal Amazon gagal. | `InternalFailure` | `EC2 instance state "Terminated" is unexpected` | ARN klaster |
| Anda memiliki kapasitas yang tidak mencukupi di Pos Luar Anda. Hal ini juga dapat terjadi ketika sebuah cluster sedang dibuat jika Outpost terputus dari Region. AWS | `ResourceLimitExceeded` | `There is not enough capacity on the Outpost to launch or start the instance.` | ARN klaster |
| Akun Anda melebihi kuota grup keamanan Anda. | `ResourceLimitExceeded` | Pesan galat yang dikembalikan oleh Amazon EC2 API | ID VPC Target |
| Akun Anda melebihi kuota elastic network interface Anda. | `ResourceLimitExceeded` | Pesan galat yang dikembalikan oleh Amazon EC2 API | ID subnet target |
| Instance control plane tidak dapat dijangkau melalui Systems Manager. AWS Untuk resolusi, lihat[Instance control plane tidak dapat dijangkau melalui Systems Manager AWS](#outposts-troubleshooting-control-plane-instances-ssm). | `ClusterUnreachable` | Instans pesawat kontrol Amazon EKS tidak dapat dijangkau melalui SSM. Harap verifikasi SSM dan konfigurasi jaringan Anda, dan rujuk dokumentasi pemecahan masalah EKS on Outposts. | EC2 Contoh Amazon IDs |
| Terjadi kesalahan saat mendapatkan detail untuk grup keamanan terkelola atau elastic network interface. | Berdasarkan kode kesalahan EC2 klien Amazon. | Pesan galat yang dikembalikan oleh Amazon EC2 API | Semua grup keamanan terkelola IDs |
| Terjadi kesalahan saat mengotorisasi atau mencabut aturan masuknya grup keamanan. Ini berlaku untuk kelompok keamanan cluster dan pesawat kontrol. | Berdasarkan kode kesalahan EC2 klien Amazon. | Pesan galat yang dikembalikan oleh Amazon EC2 API | ID grup keamanan bermasalah |
| Terjadi kesalahan saat menghapus elastic network interface untuk instance control plane. | Berdasarkan kode kesalahan EC2 klien Amazon. | Pesan galat yang dikembalikan oleh Amazon EC2 API | ID antarmuka elastis network yang bermasalah |
Tabel berikut mencantumkan kesalahan dari AWS layanan lain yang disajikan di bidang kesehatan `describe-cluster` respons.
| Kode EC2 kesalahan Amazon | Kode masalah kesehatan cluster | Deskripsi |
| --- | --- | --- |
| `AuthFailure` | `AccessDenied` | Kesalahan ini dapat terjadi karena berbagai alasan. Alasan paling umum adalah Anda secara tidak sengaja menghapus tag yang digunakan layanan untuk menutupi kebijakan peran terkait layanan dari bidang kontrol. Jika ini terjadi, Amazon EKS tidak dapat lagi mengelola dan memantau AWS sumber daya ini. |
| `UnauthorizedOperation` | `AccessDenied` | Kesalahan ini dapat terjadi karena berbagai alasan. Alasan paling umum adalah Anda secara tidak sengaja menghapus tag yang digunakan layanan untuk menutupi kebijakan peran terkait layanan dari bidang kontrol. Jika ini terjadi, Amazon EKS tidak dapat lagi mengelola dan memantau AWS sumber daya ini. |
| `InvalidSubnetID.NotFound` | `ResourceNotFound` | Kesalahan ini terjadi ketika subnet ID untuk aturan masuknya grup keamanan tidak dapat ditemukan. |
| `InvalidPermission.NotFound` | `ResourceNotFound` | Kesalahan ini terjadi ketika izin untuk aturan masuknya grup keamanan tidak benar. |
| `InvalidGroup.NotFound` | `ResourceNotFound` | Kesalahan ini terjadi ketika grup aturan masuk grup keamanan tidak dapat ditemukan. |
| `InvalidNetworkInterfaceID.NotFound` | `ResourceNotFound` | Kesalahan ini terjadi ketika ID antarmuka jaringan untuk aturan masuknya grup keamanan tidak dapat ditemukan. |
| `InsufficientFreeAddressesInSubnet` | `ResourceLimitExceeded` | Kesalahan ini terjadi ketika kuota sumber daya subnet terlampaui. |
| `InsufficientCapacityOnOutpost` | `ResourceLimitExceeded` | Kesalahan ini terjadi ketika kuota kapasitas pos terlampaui. |
| `NetworkInterfaceLimitExceeded` | `ResourceLimitExceeded` | Kesalahan ini terjadi ketika kuota elastic network interface terlampaui. |
| `SecurityGroupLimitExceeded` | `ResourceLimitExceeded` | Kesalahan ini terjadi ketika kuota grup keamanan terlampaui. |
| `VcpuLimitExceeded` | `ResourceLimitExceeded` | Ini diamati saat membuat EC2 instance Amazon di akun baru. Kesalahannya mungkin mirip dengan yang berikut: `You have requested more vCPU capacity than your current vCPU limit of 32 allows for the instance bucket that the specified instance type belongs to. Please visit http://aws.amazon.com/contact-us/ec2-request to request an adjustment to this limit."` |
| `InvalidParameterValue` | `ConfigurationConflict` | Amazon EC2 mengembalikan kode kesalahan ini jika jenis instance yang ditentukan tidak didukung di Outpost. |
| Semua kegagalan lainnya | `InternalFailure` | Tidak ada |
## Tidak dapat membuat atau memodifikasi kluster
Cluster lokal memerlukan izin dan kebijakan yang berbeda dari kluster Amazon EKS yang di-host di cloud. Jika klaster gagal membuat dan menghasilkan `InvalidPermissions` kesalahan, periksa kembali apakah peran klaster yang Anda gunakan memiliki kebijakan EKSLocal OutpostClusterPolicy terkelola [Amazon](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) yang dilampirkan padanya. Semua panggilan API lainnya memerlukan set izin yang sama dengan kluster Amazon EKS di cloud.
## Cluster macet dalam `CREATING` keadaan
Jumlah waktu yang dibutuhkan untuk membuat cluster lokal bervariasi tergantung pada beberapa faktor. Faktor-faktor ini termasuk konfigurasi jaringan Anda, konfigurasi Outpost, dan konfigurasi cluster. Secara umum, cluster lokal dibuat dan berubah `ACTIVE` status dalam 15-20 menit. Jika cluster lokal tetap dalam `CREATING` status, Anda dapat `describe-cluster` meminta informasi tentang penyebabnya di bidang `cluster.health` output.
Masalah yang paling umum adalah sebagai berikut:
+ Cluster Anda tidak dapat terhubung ke instance control plane dari AWS Region tempat Systems Manager berada. Anda dapat memverifikasi ini dengan menelepon `aws ssm start-session --target instance-id ` dari host benteng In-region. Jika perintah itu tidak berfungsi, periksa apakah Systems Manager berjalan pada instance control plane. Atau, solusi lain adalah menghapus cluster dan kemudian membuatnya kembali.
+ Instans bidang kontrol gagal dibuat karena izin kunci KMS untuk volume EBS. Dengan kunci KMS yang dikelola pengguna untuk volume EBS terenkripsi, instance bidang kontrol akan berakhir jika kunci tidak dapat diakses. Jika instance dihentikan, beralihlah ke kunci KMS AWS terkelola atau pastikan bahwa kebijakan kunci terkelola pengguna Anda memberikan izin yang diperlukan ke peran klaster.
+ Instans pesawat kontrol Systems Manager mungkin tidak memiliki akses internet. Periksa apakah subnet yang Anda berikan saat membuat cluster memiliki gateway NAT dan VPC dengan gateway internet. Gunakan penganalisis jangkauan VPC untuk memverifikasi bahwa instance bidang kontrol dapat mencapai gateway internet. Untuk informasi selengkapnya, lihat [Memulai dengan VPC Reachability](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) Analyzer.
+ Peran ARN yang Anda berikan adalah kebijakan yang hilang. Periksa apakah [kebijakan AWS terkelola: Amazon EKSLocal OutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) telah dihapus dari peran. Ini juga dapat terjadi jika AWS CloudFormation tumpukan salah dikonfigurasi.
+ Semua subnet yang disediakan harus dikaitkan dengan Outpost yang sama dan harus saling menjangkau. Saat beberapa subnet ditentukan saat kluster dibuat, Amazon EKS mencoba menyebarkan instance bidang kontrol di beberapa subnet.
+ Grup keamanan terkelola Amazon EKS diterapkan di elastic network interface. Namun, elemen konfigurasi lain seperti aturan firewall NACL mungkin bertentangan dengan aturan untuk elastic network interface.
**Konfigurasi DNS VPC dan subnet salah dikonfigurasi atau hilang**
Tinjau [Buat VPC dan subnet untuk cluster Amazon EKS di Outposts](eks-outposts-vpc-subnet-requirements.md). AWS
## Cluster macet dalam `UPDATING` keadaan
Amazon EKS secara otomatis memperbarui semua cluster lokal yang ada ke versi platform terbaru untuk versi minor Kubernetes yang sesuai. Untuk informasi lebih lanjut tentang versi platform, silakan lihat[Pelajari versi platform Kubernetes dan Amazon EKS untuk Outposts AWS](eks-outposts-platform-versions.md).
Selama peluncuran versi platform otomatis, status klaster berubah menjadi. `UPDATING` Proses pembaruan terdiri dari penggantian semua instans control-plane Kubernetes dengan yang baru yang berisi jalur keamanan terbaru dan perbaikan bug yang dirilis untuk masing-masing versi minor Kubernetes. Secara umum, proses pembaruan platform cluster lokal selesai dalam waktu kurang dari 30 menit dan klaster berubah kembali ke `ACTIVE` status. Jika klaster lokal tetap dalam `UPDATING` status untuk jangka waktu yang lama, Anda dapat menelepon `describe-cluster` untuk memeriksa informasi tentang penyebab di bidang `cluster.health` output.
Amazon EKS memastikan setidaknya 2 dari 3 instans control-plane Kubernetes adalah node cluster yang sehat dan operasional untuk menjaga ketersediaan klaster lokal dan mencegah gangguan layanan. Jika klaster lokal terhenti dalam `UPDATING` keadaan, biasanya karena ada beberapa masalah infrastruktur atau konfigurasi yang mencegah ketersediaan minimum dua instance dijamin jika proses berlanjut. Jadi proses pembaruan berhenti berkembang untuk melindungi gangguan layanan cluster lokal.
Penting untuk memecahkan masalah klaster lokal yang terjebak dalam `UPDATING` status dan mengatasi penyebab akar sehingga proses pembaruan dapat menyelesaikan dan memulihkan cluster lokal kembali `ACTIVE` dengan ketersediaan tinggi 3 instance bidang kontrol Kubernetes.
Jangan menghentikan `Kubernetes` instans kluster lokal EKS terkelola di Outposts kecuali secara eksplisit diinstruksikan oleh Support. AWS Ini sangat penting untuk cluster lokal yang terjebak dalam `UPDATING` keadaan karena ada kemungkinan besar bahwa node bidang kontrol lain tidak sepenuhnya sehat dan menghentikan instance yang salah dapat menyebabkan gangguan layanan dan risiko kehilangan data cluster lokal.
Masalah yang paling umum adalah sebagai berikut:
+ Satu atau beberapa instans bidang kontrol tidak dapat terhubung ke Manajer Sistem karena perubahan konfigurasi jaringan sejak cluster lokal pertama kali dibuat. Anda dapat memverifikasi ini dengan menelepon `aws ssm start-session --target instance-id ` dari host benteng In-region. Jika perintah itu tidak berfungsi, periksa apakah Systems Manager berjalan pada instance control plane.
+ Instans bidang kontrol baru gagal dibuat karena izin kunci KMS untuk volume EBS. Dengan kunci KMS yang dikelola pengguna untuk volume EBS terenkripsi, instance bidang kontrol akan berakhir jika kunci tidak dapat diakses. Jika instance dihentikan, beralihlah ke kunci KMS AWS terkelola atau pastikan bahwa kebijakan kunci terkelola pengguna Anda memberikan izin yang diperlukan ke peran klaster.
+ Instans pesawat kontrol Systems Manager mungkin telah kehilangan akses internet. Periksa apakah subnet yang disediakan saat Anda membuat cluster memiliki gateway NAT dan VPC dengan gateway internet. Gunakan penganalisis jangkauan VPC untuk memverifikasi bahwa instance bidang kontrol dapat mencapai gateway internet. Untuk informasi selengkapnya, lihat [Memulai dengan VPC Reachability](https://docs.aws.amazon.com/vpc/latest/reachability/getting-started.html) Analyzer. Jika jaringan pribadi Anda tidak memiliki koneksi internet keluar, pastikan bahwa semua titik akhir VPC dan titik akhir gateway yang diperlukan masih ada di subnet Regional dari cluster Anda (lihat). [Akses subnet ke layanan AWS](eks-outposts-vpc-subnet-requirements.md#subnet-access-to-services)
+ Peran ARN yang Anda berikan adalah kebijakan yang hilang. Periksa apakah [kebijakan AWS terkelola: Amazon EKSLocal OutpostClusterPolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-amazonekslocaloutpostclusterpolicy) tidak dihapus dari peran.
+ Salah satu instance control-plane Kubernetes baru mungkin mengalami kegagalan bootstrap yang tidak terduga. Silakan ajukan tiket ke [AWS Support Center](https://console.aws.amazon.com/support/home) untuk panduan lebih lanjut tentang pemecahan masalah dan pengumpulan log dalam kasus luar biasa ini.
## Tidak dapat menggabungkan node ke cluster
+ Masalah AMI:
+ Anda menggunakan AMI yang tidak kompatibel. Hanya Amazon EKS yang dioptimalkan Amazon Linux 2 AMIs yang didukung (`amazon-linux-2``amazon-linux-2-gpu`,,`amazon-linux-2-arm64`). Jika Anda mencoba menggabungkan AL2 023 node ke EKS LocalClusters di AWS Outposts, node gagal bergabung dengan cluster. Untuk informasi selengkapnya, lihat [Membuat node Amazon Linux di AWS Outposts](eks-outposts-self-managed-nodes.md).
+ Jika Anda menggunakan AWS CloudFormation template untuk membuat node, pastikan itu tidak menggunakan AMI yang tidak didukung.
+ Kehilangan AWS IAM Authenticator `ConfigMap` — Jika hilang, Anda harus membuatnya. Untuk informasi selengkapnya, lihat [Terapkan `aws-auth` `ConfigMap` ke cluster Anda](auth-configmap.md#aws-auth-configmap).
+ Kelompok keamanan yang salah digunakan — Pastikan untuk digunakan `eks-cluster-sg-cluster-name-uniqueid ` untuk kelompok keamanan node pekerja Anda. Grup keamanan yang dipilih diubah oleh AWS CloudFormation untuk memungkinkan grup keamanan baru setiap kali tumpukan digunakan.
+ Mengikuti langkah-langkah VPC tautan pribadi yang tidak terduga — Data CA yang salah (`--b64-cluster-ca`) atau API Endpoint (`--apiserver-endpoint`) diteruskan.
## Mengumpulkan log
Ketika Outpost terputus dari AWS Region yang terkait dengannya, klaster Kubernetes kemungkinan akan terus bekerja secara normal. Namun, jika klaster tidak berfungsi dengan baik, ikuti langkah-langkah pemecahan masalah di [Siapkan kluster Amazon EKS lokal di AWS Outposts](eks-outposts-network-disconnects.md) untuk pemutusan jaringan. Jika Anda mengalami masalah lain, hubungi AWS Support. AWS Support dapat memandu Anda dalam mengunduh dan menjalankan alat pengumpulan log. Dengan begitu, Anda dapat mengumpulkan log dari instance control plane cluster Kubernetes dan mengirimkannya ke Support AWS Support untuk penyelidikan lebih lanjut.
## Instance control plane tidak dapat dijangkau melalui Systems Manager AWS
Jika instans bidang kontrol Amazon EKS tidak dapat dijangkau melalui AWS Systems Manager (Systems Manager), Amazon EKS menampilkan error berikut untuk klaster Anda.
```
Amazon EKS control plane instances are not reachable through SSM. Please verify your SSM and network configuration, and reference the EKS on Outposts troubleshooting documentation.
```
Untuk mengatasi masalah ini, pastikan VPC dan subnet Anda memenuhi persyaratan di Buat [VPC dan subnet untuk klaster Amazon EKS di AWS Outposts dan](eks-outposts-vpc-subnet-requirements.md) Anda menyelesaikan langkah-langkah dalam Menyiapkan [Session Manager di Panduan Pengguna Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started.html). AWS
# Buat node Amazon Linux di AWS Outposts
**penting**
Cluster Lokal Amazon EKS di Outposts hanya mendukung node yang dibuat dari Amazon Linux Linux 2023 yang dioptimalkan Amazon EKS berikut: AMIs
Standar Amazon Linux 2023 () `amazon-linux-2023/x86_64/standard`
Nvidia Amazon Linux yang Dipercepat 2023 () `amazon-linux-2023/x86_64/nvidia`
Neuron yang Dipercepat Amazon Linux 2023 () `amazon-linux-2023/x86_64/neuron`
AWS mengakhiri dukungan untuk EKS AL2 -dioptimalkan dan AL2 -dipercepat AMIs, efektif 26 November 2025. Meskipun Anda dapat terus menggunakan EKS AL2 AMIs setelah tanggal end-of-support (EOS) (26 November 2025), EKS tidak akan lagi merilis versi atau pembaruan Kubernetes baru AL2 AMIs, termasuk rilis minor, tambalan, dan perbaikan bug setelah tanggal ini. Lihat [ini](https://docs.aws.amazon.com/eks/latest/userguide/eks-ami-deprecation-faqs.html) untuk informasi lebih lanjut tentang AL2 penghentian.
Topik ini menjelaskan bagaimana Anda dapat meluncurkan grup Auto Scaling dari node Amazon Linux di Outpost yang mendaftar dengan kluster Amazon EKS Anda. Cluster dapat berada di AWS Cloud atau di Outpost.
+ Pos terdepan yang ada. Untuk informasi selengkapnya, lihat [Apa itu AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/what-is-outposts.html).
+ Sebuah klaster Amazon EKS yang sudah ada. Untuk menerapkan cluster di AWS Cloud, lihat[Buat kluster Amazon EKS](create-cluster.md). Untuk menyebarkan cluster di Outpost, lihat. [Buat cluster Amazon EKS lokal di AWS Outposts untuk ketersediaan tinggi](eks-outposts-local-cluster-overview.md)
+ Misalkan Anda membuat node di cluster di AWS Cloud dan Anda memiliki subnet di AWS Wilayah tempat Anda mengaktifkan AWS Outposts, AWS Wavelength, atau Local Zones. AWS Kemudian, subnet tersebut seharusnya tidak diteruskan saat Anda membuat cluster Anda. Jika Anda membuat node di cluster di Outpost, Anda pasti telah melewati subnet Outpost saat membuat cluster Anda.
+ (Direkomendasikan untuk cluster di AWS Cloud) Plugin Amazon VPC CNI untuk add-on Kubernetes dikonfigurasi dengan peran IAM sendiri yang memiliki kebijakan IAM yang diperlukan yang melekat padanya. Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md). Cluster lokal tidak mendukung peran IAM untuk akun layanan.
Anda dapat membuat grup node Amazon Linux yang dikelola sendiri dengan `eksctl` atau Konsol Manajemen AWS (dengan AWS CloudFormation templat). Anda juga dapat menggunakan Terraform.
Anda dapat membuat grup node yang dikelola sendiri untuk klaster lokal dengan alat berikut yang dijelaskan di halaman ini:
+ [`eksctl`](#eksctl_create_nodes_outpost)
+ [Konsol Manajemen AWS](#console_create_nodes_outpost)
**penting**
Grup node yang dikelola sendiri menyertakan EC2 instans Amazon di akun Anda. Instans ini tidak ditingkatkan secara otomatis saat Anda atau Amazon EKS memperbarui versi pesawat kontrol atas nama Anda. Grup node yang dikelola sendiri tidak memiliki indikasi apa pun di konsol bahwa ia perlu diperbarui. Anda dapat melihat versi `kubelet` yang diinstal pada sebuah simpul dengan memilih simpul di dalam daftar **Simpul** pada tab **Gambaran Umum** klaster Anda untuk menentukan simpul-simpul yang perlu diperbarui. Anda harus memperbarui simpul secara manual. Untuk informasi selengkapnya, lihat [Perbarui node yang dikelola sendiri untuk klaster Anda](update-workers.md).
Sertifikat yang digunakan oleh kubelet pada node yang dikelola sendiri diterbitkan dengan kedaluwarsa satu tahun. Secara default, rotasi sertifikat **tidak** diaktifkan (lihat: https://kubernetes. io/docs/reference/config-api/kubelet-config.v1beta1/\$1 kubelet-config-k 8 s-io-v 1beta1-KubeletConfiguration), ini berarti jika Anda memiliki node yang dikelola sendiri yang berjalan selama lebih dari satu tahun, itu tidak akan lagi dapat mengautentikasi ke Kubernetes API.
Sebagai praktik terbaik, kami menyarankan pelanggan untuk secara teratur memperbarui grup node yang dikelola sendiri untuk menerima CVEs dan patch keamanan dari AMI Amazon EKS terbaru yang dioptimalkan. Memperbarui AMI yang digunakan dalam grup node yang dikelola sendiri juga memicu pembuatan ulang node dan memastikan mereka tidak mengalami masalah karena sertifikat kubelet yang kedaluwarsa.
Atau Anda juga dapat mengaktifkan rotasi sertifikat klien (lihat: https://kubernetes. io/docs/tasks/tls/certificate-rotation/) saat membuat grup node yang dikelola sendiri untuk memastikan sertifikat kubelet diperbarui saat sertifikat saat ini mendekati kedaluwarsa.
## `eksctl`
**Untuk meluncurkan node Linux yang dikelola sendiri menggunakan `eksctl`**
1. Instal 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. Jika klaster Anda ada di AWS Cloud dan kebijakan IAM terkelola **Amazoneks\$1CNI\$1Policy** dilampirkan ke peran IAM [node Amazon EKS Anda, kami sarankan untuk menetapkannya ke peran IAM yang Anda](create-node-role.md) kaitkan ke akun layanan Kubernetes sebagai gantinya. `aws-node` Untuk informasi selengkapnya, lihat [Konfigurasikan plugin Amazon VPC CNI untuk menggunakan IRSA](cni-iam-role.md). Jika klaster Anda berada di Outpost Anda, kebijakan harus dilampirkan ke peran node Anda.
1. Perintah berikutnya membuat grup simpul dalam klaster yang ada. Cluster harus dibuat menggunakan`eksctl`. Ganti *al-nodes* dengan nama untuk grup node Anda. Nama grup node tidak boleh lebih dari 63 karakter. Itu harus dimulai dengan huruf atau digit, tetapi juga dapat menyertakan tanda hubung dan garis bawah untuk karakter yang tersisa. Ganti *my-cluster* dengan nama klaster 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. Jika klaster Anda ada di Outpost, ganti *id* dengan ID subnet Outpost. Jika klaster Anda ada di AWS Cloud, ganti *id* dengan ID subnet yang tidak Anda tentukan saat membuat klaster. Ganti nilai contoh yang tersisa dengan nilai Anda sendiri. Simpul dibuat dengan versi Kubernetes yang sama dengan bidang kendali, secara default.
Ganti *instance-type* dengan jenis instance yang tersedia di Outpost Anda.
Ganti *my-key* dengan nama Amazon EC2 key pair atau public key Anda. Kunci ini digunakan untuk SSH ke simpul Anda setelah diluncurkan. Jika Anda belum memiliki EC2 key pair Amazon, Anda dapat membuatnya di Konsol Manajemen AWS. Untuk informasi selengkapnya, lihat [pasangan EC2 kunci Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) *di Panduan EC2 Pengguna Amazon*.
Buat grup simpul Anda dengan perintah berikut.
```
eksctl create nodegroup --cluster my-cluster --name al-nodes --node-type instance-type \
--nodes 3 --nodes-min 1 --nodes-max 4 --managed=false \
--node-volume-type gp2 --subnet-ids subnet-id \
--node-ami-family AmazonLinux2023
```
Jika klaster Anda di-deploy di AWS Cloud:
+ Grup node yang Anda deploy dapat menetapkan `IPv4` alamat ke Pod dari blok CIDR yang berbeda dari instance. Untuk informasi selengkapnya, lihat [Menerapkan Pod di subnet alternatif dengan jaringan khusus](cni-custom-network.md).
+ Grup node yang Anda terapkan tidak memerlukan akses internet keluar. Untuk informasi selengkapnya, lihat [Menyebarkan kluster pribadi dengan akses internet terbatas](private-clusters.md).
Untuk daftar lengkap semua opsi dan default yang tersedia, lihat [AWS Outposts Support](https://eksctl.io/usage/outposts/) dalam dokumentasi. `eksctl`
+ Jika node gagal bergabung dengan cluster, lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) di [Memecahkan masalah dengan kluster dan node Amazon EKS dan di Troubleshoot cluster](troubleshooting.md) [Amazon EKS lokal [Tidak dapat menggabungkan node ke cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster)](eks-outposts-troubleshooting.md) di Outposts. AWS
+ Contoh output adalah sebagai berikut. Beberapa baris adalah output sementara node dibuat. Salah satu baris terakhir dari output adalah baris contoh berikutnya.
```
[✔] created 1 nodegroup(s) in cluster "my-cluster"
```
1. (Opsional) Deploy [aplikasi sampel](sample-deployment.md) untuk menguji simpul klaster dan Linux Anda.
## Konsol Manajemen AWS
**Langkah 1: Luncurkan node Linux yang dikelola sendiri menggunakan Konsol Manajemen AWS **
1. Unduh versi terbaru dari AWS CloudFormation template.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2025-11-24/amazon-eks-outpost-nodegroup.yaml
```
1. Buka [konsol AWS CloudFormation ](https://console.aws.amazon.com/cloudformation/).
1. Pilih **Buat tumpukan** dan kemudian pilih **Dengan sumber daya baru (standar)**.
1. Untuk **Menentukan templat**, pilih **Unggah sebuah file templat** dan kemudian pilih **Pilih file**. Pilih `amazon-eks-nodegroup.yaml` file yang Anda unduh pada langkah sebelumnya dan kemudian pilih **Berikutnya**.
1. Pada halaman **Tentukan detail tumpukan**, masukkan parameter berikut yang sesuai, lalu pilih **Berikutnya**:
+ **Nama tumpukan**: Pilih nama tumpukan untuk AWS CloudFormation tumpukan Anda. Misalnya, Anda bisa menyebutnya*al-nodes*. 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.
+ **ApiServerEndpoint**: Masukkan endpoint Kubernetes API Server, terlihat di konsol EKS atau melalui API. DescribeCluster
+ **ClusterName**: Masukkan nama cluster Anda. Jika nama ini tidak cocok dengan nama cluster Anda, node Anda tidak dapat bergabung dengan cluster.
+ **ClusterId**: Masukkan id yang ditetapkan ke cluster oleh layanan EKS. Terlihat melalui DescribeCluster API. Jika id ini tidak cocok dengan id cluster Anda, node Anda tidak dapat bergabung dengan cluster.
+ **CertificateAuthority**: Masukkan string berkode base64 dari Kubernetes Certificate Authority. Terlihat di konsol EKS atau melalui DescribeCluster API.
+ **ServiceCidr**: Masuk ke CIDR Layanan Kubernetes. Terlihat di konsol EKS atau melalui DescribeCluster API.
+ **ClusterControlPlaneSecurityGroup**: Pilih **SecurityGroups**nilai dari AWS CloudFormation output yang Anda hasilkan saat Anda membuat [VPC](creating-a-vpc.md) Anda.
Langkah-langkah berikut menunjukkan satu operasi untuk mengambil grup yang berlaku.
1. Buka [konsol Amazon EKS](https://console.aws.amazon.com/eks/home#/clusters).
1. Pilih nama cluster.
1. Pilih tab **Jaringan**.
1. Gunakan nilai **grup keamanan tambahan** sebagai referensi saat memilih dari daftar **ClusterControlPlaneSecurityGroup**tarik-turun.
+ **NodeGroupName**: Masukkan nama untuk grup node Anda. Nama ini dapat digunakan nanti untuk mengidentifikasi grup node Auto Scaling yang dibuat untuk node Anda.
+ **NodeAutoScalingGroupMinSize**: Masukkan jumlah minimum node yang dapat diskalakan oleh grup Auto Scaling node Anda.
+ **NodeAutoScalingGroupDesiredCapacity**: Masukkan jumlah node yang diinginkan untuk diskalakan saat tumpukan Anda dibuat.
+ **NodeAutoScalingGroupMaxSize**: Masukkan jumlah maksimum node yang dapat diskalakan oleh grup Auto Scaling node Anda.
+ **NodeInstanceType**: Pilih jenis instance untuk node Anda. Jika klaster Anda berjalan di AWS Cloud, maka untuk informasi selengkapnya, lihat[Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md). Jika cluster Anda berjalan di Outpost, maka Anda hanya dapat memilih jenis instans yang tersedia di Outpost Anda.
+ **NodeImageIdSSMParam**: Diisi sebelumnya dengan parameter Amazon EC2 Systems Manager dari Amazon EKS baru-baru ini yang dioptimalkan AMI untuk versi Kubernetes variabel. [Untuk menggunakan versi minor Kubernetes berbeda yang didukung dengan Amazon EKS, ganti *1.XX* dengan versi lain yang didukung.](https://docs.aws.amazon.com/eks/latest/userguide/kubernetes-versions.html) Sebaiknya tentukan versi Kubernetes yang sama dengan klaster Anda.
Untuk menggunakan AMI akselerasi Amazon EKS yang dioptimalkan, perbarui *NodeImageIdSSMParam* nilai ke parameter SSM yang diinginkan. [Lihat cara mengambil EKS AMI IDs dari SSM di sini.](https://docs.aws.amazon.com/eks/latest/userguide/retrieve-ami-id.html)
**catatan**
Node Amazon EKS AMIs didasarkan pada Amazon Linux. Anda dapat melacak peristiwa keamanan atau privasi untuk Amazon Linux di [pusat keamanan Amazon Linux](https://alas.aws.amazon.com/) dengan memilih tab untuk versi yang Anda inginkan. Anda juga dapat berlangganan umpan RSS yang berlaku. Kejadian keamanan dan privasi mencakup gambaran umum mengenai masalah, paket apa yang terpengaruh, dan cara memperbarui instans Anda untuk memperbaiki masalah tersebut.
+ **NodeImageId**: (Opsional) Jika Anda menggunakan AMI kustom Anda sendiri (bukan AMI yang dioptimalkan Amazon EKS), masukkan ID AMI node untuk AWS Wilayah Anda. Jika Anda menentukan nilai di sini, itu akan mengganti nilai apa pun di bidang. **NodeImageIdSSMParam**
+ **NodeVolumeSize**: Tentukan ukuran volume root untuk node Anda, di GiB.
+ **NodeVolumeType**: Tentukan jenis volume root untuk node Anda.
+ **KeyName**: Masukkan nama key pair Amazon EC2 SSH yang dapat Anda gunakan untuk terhubung menggunakan SSH ke node Anda setelah diluncurkan. Jika Anda belum memiliki EC2 key pair Amazon, Anda dapat membuatnya di Konsol Manajemen AWS. Untuk informasi selengkapnya, lihat [pasangan EC2 kunci Amazon](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html) *di Panduan EC2 Pengguna Amazon*.
**catatan**
Jika Anda tidak menyediakan key pair di sini, pembuatan AWS CloudFormation stack gagal.
+ **Nonaktifkan IMDSv1**: Secara default, setiap node mendukung Layanan Metadata Instans Versi 1 (IMDSv1) dan. IMDSv2 Anda dapat menonaktifkan IMDSv1. Untuk mencegah penggunaan node dan Pod future dalam grup node IMDSv1, setel **Disable IMDSv1** ke **true**. Untuk informasi selengkapnya tentang IMDS, lihat [Mengonfigurasi layanan metadata instans](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html). Untuk informasi selengkapnya tentang membatasi akses ke node Anda, lihat [Membatasi akses ke profil instance yang ditetapkan ke node pekerja](https://aws.github.io/aws-eks-best-practices/security/docs/iam/#restrict-access-to-the-instance-profile-assigned-to-the-worker-node).
+ **VpcId**: Masukkan ID untuk [VPC](creating-a-vpc.md) yang Anda buat. Sebelum memilih VPC, tinjau persyaratan dan pertimbangan [VPC](eks-outposts-vpc-subnet-requirements.md#outposts-vpc-requirements).
+ **Subnet**: Jika cluster Anda berada di Outpost, maka pilih setidaknya satu subnet pribadi di VPC Anda. Sebelum memilih subnet, tinjau [persyaratan dan pertimbangan Subnet](eks-outposts-vpc-subnet-requirements.md#outposts-subnet-requirements). Anda dapat melihat subnet mana yang bersifat pribadi dengan membuka setiap subnet link dari tab **Networking** cluster Anda.
1. Pilih pilihan yang Anda inginkan di halaman **Configure stack options**, lalu pilih **Next**.
1. Pilih kotak centang di sebelah kiri **Saya mengakui yang AWS CloudFormation mungkin membuat sumber daya IAM**. , dan kemudian pilih **Buat tumpukan**.
1. Setelah tumpukan Anda selesai dibuat, pilih tumpukan di konsol dan pilih **Outputs**.
1. Rekam **NodeInstanceRole**untuk grup node yang telah dibuat. Anda memerlukan ini saat mengonfigurasi simpul Amazon EKS Anda.
**Langkah 2: Aktifkan node untuk bergabung dengan cluster Anda**
1. Periksa untuk melihat apakah Anda sudah memiliki `aws-auth``ConfigMap`.
```
kubectl describe configmap -n kube-system aws-auth
```
1. Jika Anda ditampilkan `aws-auth``ConfigMap`, maka perbarui sesuai kebutuhan.
1. Buka `ConfigMap` untuk mengedit.
```
kubectl edit -n kube-system configmap/aws-auth
```
1. Tambahkan `mapRoles` entri baru sesuai kebutuhan. Tetapkan `rolearn` nilai ke **NodeInstanceRole**nilai yang Anda rekam dalam prosedur sebelumnya.
```
[...]
data:
mapRoles: |
- rolearn:
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
[...]
```
1. Simpan file dan keluar dari editor teks Anda.
1. Jika Anda menerima kesalahan yang menyatakan "`Error from server (NotFound): configmaps "aws-auth" not found`, maka terapkan stok`ConfigMap`.
1. Unduh peta konfigurasi.
```
curl -O https://s3.us-west-2.amazonaws.com/amazon-eks/cloudformation/2020-10-29/aws-auth-cm.yaml
```
1. Dalam `aws-auth-cm.yaml` file, atur `rolearn` ke **NodeInstanceRole**nilai yang Anda rekam dalam prosedur sebelumnya. Anda dapat melakukan ini dengan editor teks, atau dengan mengganti *my-node-instance-role* dan menjalankan perintah berikut:
```
sed -i.bak -e 's||my-node-instance-role|' aws-auth-cm.yaml
```
1. Terapkan konfigurasi. Perintah ini mungkin memerlukan waktu beberapa menit untuk diselesaikan.
```
kubectl apply -f aws-auth-cm.yaml
```
1. Perhatikan status simpul Anda dan tunggu sampai simpul mencapai Status `Ready`.
```
kubectl get nodes --watch
```
Masukkan `Ctrl`\$1`C` untuk kembali ke prompt shell.
**catatan**
Jika Anda menerima kesalahan otorisasi atau jenis sumber daya, lihat [Tidak sah atau akses ditolak (`kubectl`)](troubleshooting.md#unauthorized) di topik pemecahan masalah.
Jika node gagal bergabung dengan cluster, lihat [Simpul gagal untuk bergabung dengan klaster](troubleshooting.md#worker-node-fail) di [Memecahkan masalah dengan kluster dan node Amazon EKS dan di Troubleshoot cluster](troubleshooting.md) [Amazon EKS lokal [Tidak dapat menggabungkan node ke cluster](eks-outposts-troubleshooting.md#outposts-troubleshooting-unable-to-join-nodes-to-a-cluster)](eks-outposts-troubleshooting.md) di Outposts. AWS
1. Instal driver Amazon EBS CSI. Untuk informasi selengkapnya, lihat [Instalasi](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/install.md) di GitHub. Di bagian **Siapkan izin driver**, pastikan untuk mengikuti instruksi untuk opsi **Menggunakan profil instans IAM**. Anda harus menggunakan kelas `gp2` penyimpanan. Kelas `gp3` penyimpanan tidak didukung.
Untuk membuat kelas `gp2` penyimpanan di cluster Anda, selesaikan langkah-langkah berikut.
1. Jalankan perintah berikut untuk membuat `gp2-storage-class.yaml` file.
```
cat >gp2-storage-class.yaml <