**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.
# Menyebarkan kluster pribadi dengan akses internet terbatas
Topik ini menjelaskan cara menerapkan kluster Amazon EKS yang diterapkan di AWS Cloud, tetapi tidak memiliki akses internet keluar. Jika Anda memiliki cluster lokal di AWS Outposts, lihat[Buat node Amazon Linux di AWS Outposts](eks-outposts-self-managed-nodes.md), bukan topik ini.
Jika Anda tidak terbiasa dengan jaringan Amazon EKS, lihat [De-mystifying jaringan cluster untuk node pekerja Amazon EKS](https://aws.amazon.com/blogs/containers/de-mystifying-cluster-networking-for-amazon-eks-worker-nodes). Jika klaster Anda tidak memiliki akses internet keluar, maka klaster harus memenuhi persyaratan berikut:
## Persyaratan arsitektur cluster
+ Cluster Anda harus menarik gambar dari registri kontainer yang ada di VPC Anda. Anda dapat membuat Amazon Elastic Container Registry di VPC Anda dan menyalin gambar kontainer ke sana untuk diambil node Anda. Untuk informasi selengkapnya, lihat [Salin gambar kontainer dari satu repositori ke repositori lain](copy-image-to-repository.md).
+ Cluster Anda harus mengaktifkan akses pribadi endpoint. Hal ini diperlukan untuk node untuk mendaftar dengan endpoint cluster. titik akhir akses publik adalah opsional. Untuk informasi selengkapnya, lihat [Titik akhir server API kluster](cluster-endpoint.md).
## Persyaratan node
+ Node Linux dan Windows yang dikelola sendiri harus menyertakan argumen bootstrap berikut sebelum diluncurkan. Argumen ini melewati introspeksi Amazon EKS dan tidak memerlukan akses ke Amazon EKS API dari dalam VPC.
1. Tentukan nilai endpoint cluster Anda dengan perintah berikut. Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks describe-cluster --name my-cluster --query cluster.endpoint --output text
```
Contoh output adalah sebagai berikut.
```
https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
```
1. Tentukan nilai otoritas sertifikat klaster Anda dengan perintah berikut. Ganti *my-cluster* dengan nama klaster Anda.
```
aws eks describe-cluster --name my-cluster --query cluster.certificateAuthority --output text
```
Output yang dikembalikan adalah string panjang.
1. Ganti nilai `apiServerEndpoint` dan `certificateAuthority` di NodeConfig objek dengan nilai yang dikembalikan dalam output dari perintah sebelumnya. Untuk informasi selengkapnya tentang menentukan argumen bootstrap saat meluncurkan node Amazon Linux 2023 yang dikelola sendiri, lihat dan. [Buat node Amazon Linux yang dikelola sendiri](launch-workers.md) [Buat node Microsoft Windows yang dikelola sendiri](launch-windows-workers.md)
+ Untuk node Linux:
```
---
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="BOUNDARY"
--BOUNDARY
Content-Type: application/node.eks.aws
---
apiVersion: node.eks.aws/v1alpha1
kind: NodeConfig
spec:
cluster:
name: my-cluster
apiServerEndpoint: [.replaceable]https://EXAMPLE108C897D9B2F1B21D5EXAMPLE.sk1.region-code.eks.amazonaws.com
certificateAuthority: [.replaceable]Y2VydGlmaWNhdGVBdXRob3JpdHk=
...
```
Untuk argumen tambahan, lihat [skrip bootstrap](https://github.com/awslabs/amazon-eks-ami/blob/main/templates/al2/runtime/bootstrap.sh) pada GitHub.
+ Untuk node Windows:
**catatan**
Jika Anda menggunakan layanan khusus CIDR, maka Anda perlu menentukannya menggunakan `-ServiceCIDR` parameter. Jika tidak, resolusi DNS untuk Pod di cluster akan gagal.
```
-APIServerEndpoint cluster-endpoint -Base64ClusterCA certificate-authority
```
Untuk argumen tambahan, lihat[Parameter konfigurasi skrip bootstrap](eks-optimized-windows-ami.md#bootstrap-script-configuration-parameters).
+ Cluster Anda `aws-auth` `ConfigMap` harus dibuat dari dalam VPC Anda. Untuk informasi selengkapnya tentang membuat dan menambahkan entri ke `aws-auth``ConfigMap`, masukkan `eksctl create iamidentitymapping --help` di terminal Anda. Jika `ConfigMap` tidak ada di server Anda, `eksctl` akan membuatnya ketika Anda menggunakan perintah untuk menambahkan pemetaan identitas.
## Persyaratan pod
+ **Pod Identity** - Pod yang dikonfigurasi dengan EKS Pod Identity memperoleh kredensyal dari EKS Auth API. Jika tidak ada akses internet keluar, Anda harus membuat dan menggunakan titik akhir VPC untuk EKS Auth API:. `com.amazonaws.region-code.eks-auth` Untuk informasi lebih lanjut tentang titik akhir VPC EKS dan EKS Auth, lihat. [Akses Amazon EKS menggunakan AWS PrivateLink](vpc-interface-endpoints.md)
+ **IRSA** - Pod yang dikonfigurasi dengan [peran IAM untuk akun layanan](iam-roles-for-service-accounts.md) memperoleh kredensyal dari panggilan API AWS Security Token Service (AWS STS). Jika tidak ada akses internet keluar, Anda harus membuat dan menggunakan titik akhir VPC AWS STS di VPC Anda. Sebagian besar AWS `v1` SDKs menggunakan endpoint AWS STS global secara default (`sts.amazonaws.com`), yang tidak menggunakan titik akhir AWS STS VPC. Untuk menggunakan titik akhir VPC AWS STS, Anda mungkin perlu mengonfigurasi SDK Anda untuk menggunakan endpoint AWS STS regional (). `sts.region-code.amazonaws.com` Untuk informasi selengkapnya, lihat [Konfigurasikan titik akhir Layanan Token AWS Keamanan untuk akun layanan](configure-sts-endpoint.md).
+ Subnet VPC klaster Anda harus memiliki titik akhir antarmuka VPC untuk AWS layanan apa pun yang perlu diakses oleh Pod Anda. Untuk informasi selengkapnya, lihat [Mengakses AWS layanan menggunakan titik akhir VPC antarmuka](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html). Beberapa layanan dan titik akhir yang umum digunakan tercantum dalam tabel berikut. Untuk daftar lengkap titik akhir, lihat [AWS layanan yang terintegrasi dengan AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/aws-services-privatelink-support.html) dalam [AWS PrivateLink Panduan](https://docs.aws.amazon.com/vpc/latest/privatelink/).
Kami menyarankan Anda [mengaktifkan nama DNS pribadi](https://docs.aws.amazon.com/vpc/latest/privatelink/interface-endpoints.html#enable-private-dns-names) untuk titik akhir VPC Anda, sehingga beban kerja dapat terus menggunakan titik akhir layanan AWS publik tanpa masalah.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/private-clusters.html)
+ Setiap node yang dikelola sendiri harus disebarkan ke subnet yang memiliki titik akhir antarmuka VPC yang Anda butuhkan. Jika Anda membuat grup node terkelola, grup keamanan titik akhir antarmuka VPC harus mengizinkan CIDR untuk subnet, atau Anda harus menambahkan grup keamanan node yang dibuat ke grup keamanan titik akhir antarmuka VPC.
+ **EFS storage** - Jika Pod Anda menggunakan volume Amazon EFS, maka sebelum menerapkan [sistem file elastis Store dengan Amazon EFS](efs-csi.md), file [kustomization.yaml](https://github.com/kubernetes-sigs/aws-efs-csi-driver/blob/master/deploy/kubernetes/overlays/stable/kustomization.yaml) driver harus diubah untuk mengatur image container agar menggunakan Region AWS yang sama dengan cluster Amazon EKS.
+ Route53 tidak mendukung. AWS PrivateLink Anda tidak dapat mengelola catatan DNS Route53 dari kluster Amazon EKS pribadi. [Ini berdampak pada Kubernetes external-dns.](https://github.com/kubernetes-sigs/external-dns)
+ Jika Anda menggunakan AMI EKS Optimized, Anda harus mengaktifkan `ec2` endpoint pada tabel di atas. Atau, Anda dapat secara manual mengatur nama DNS Node. AMI yang dioptimalkan digunakan EC2 APIs untuk mengatur nama DNS node secara otomatis.
+ Anda dapat menggunakan [AWS Load Balancer Controller](aws-load-balancer-controller.md) untuk menyebarkan AWS Application Load Balancers (ALB) dan Network Load Balancer ke cluster pribadi Anda. Saat menerapkannya, Anda harus menggunakan [flag baris perintah](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/deploy/configurations/#controller-command-line-flags) untuk mengatur`enable-shield`,`enable-waf`, dan `enable-wafv2` ke false. [Penemuan sertifikat](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/cert_discovery/#discover-via-ingress-rule-host) dengan nama host dari objek Ingress tidak didukung. Ini karena pengontrol perlu mencapai AWS Certificate Manager, yang tidak memiliki titik akhir antarmuka VPC.
Pengendali yang didukung pada penyeimbang beban jaringan dengan target IP, yang diperlukan untuk penggunaan pada Fargate. Untuk informasi selengkapnya, lihat [Rute aplikasi dan lalu lintas HTTP dengan Application Load Balancers](alb-ingress.md) dan [Buat penyeimbang beban jaringan](network-load-balancing.md#network-load-balancer).
+ [Cluster Autoscaler didukung.](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md) Saat menerapkan Cluster Autoscaler Pod, pastikan bahwa baris perintah termasuk. `--aws-use-static-instance-list=true` Untuk informasi selengkapnya, lihat [Menggunakan Daftar Instans Statis](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/aws/README.md#use-static-instance-list) pada GitHub. VPC node pekerja juga harus menyertakan titik akhir VPC STS dan titik akhir AWS VPC penskalaan otomatis.
+ Beberapa produk perangkat lunak kontainer menggunakan panggilan API yang mengakses AWS Marketplace Metering Service untuk memantau penggunaan. Cluster pribadi tidak mengizinkan panggilan ini, jadi Anda tidak dapat menggunakan jenis penampung ini di kluster pribadi.