**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.
# Konfigurasikan pengaturan Mode Otomatis EKS
Bab ini menjelaskan cara mengonfigurasi aspek-aspek tertentu dari kluster Mode Otomatis Amazon Elastic Kubernetes Service (EKS) Anda. Sementara Mode Otomatis EKS mengelola sebagian besar komponen infrastruktur secara otomatis, Anda dapat menyesuaikan fitur tertentu untuk memenuhi persyaratan beban kerja Anda.
Dengan menggunakan opsi konfigurasi yang dijelaskan dalam topik ini, Anda dapat mengubah pengaturan jaringan, menghitung sumber daya, dan perilaku penyeimbangan beban sambil mempertahankan manfaat manajemen infrastruktur otomatis. Sebelum membuat perubahan konfigurasi, tinjau opsi yang tersedia di bagian berikut untuk menentukan pendekatan mana yang paling sesuai dengan kebutuhan Anda.
| Fitur apa yang ingin Anda konfigurasikan? | Opsi Konfigurasi |
| --- | --- |
| **Jaringan dan penyimpanan node** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat Kelas Node untuk Amazon EKS](create-node-class.md) |
| **Sumber daya komputasi node** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md) |
| **Kolam simpul berkapasitas statis** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Kolam Node Kapasitas Statis dalam Mode Otomatis EKS](auto-static-capacity.md) |
| **Pengaturan Application Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat IngressClass untuk mengkonfigurasi Application Load Balancer](auto-configure-alb.md) |
| **Pengaturan Network Load Balancer** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Gunakan Anotasi Layanan untuk mengonfigurasi Network Load Balancers](auto-configure-nlb.md) |
| **Pengaturan Kelas Penyimpanan** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Buat kelas penyimpanan](create-storage-class.md) |
| **Kontrol Penggunaan ODCR** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS](auto-odcr.md) |
| **Node keamanan tingkat lanjut** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/settings-auto.html) | [Konfigurasikan pengaturan keamanan lanjutan untuk node](auto-advanced-security.md) |
# Buat Kelas Node untuk Amazon EKS
Amazon EKS Node Classes adalah template yang menawarkan kontrol granular atas konfigurasi node terkelola Mode Otomatis EKS Anda. Kelas Node mendefinisikan pengaturan tingkat infrastruktur yang berlaku untuk grup node di kluster EKS Anda, termasuk konfigurasi jaringan, pengaturan penyimpanan, dan penandaan sumber daya. Topik ini menjelaskan cara membuat dan mengkonfigurasi Kelas Node untuk memenuhi persyaratan operasional spesifik Anda.
Saat Anda perlu menyesuaikan cara Mode Otomatis EKS menyediakan dan mengonfigurasi instans EC2 di luar pengaturan default, membuat Kelas Node memberi Anda kontrol yang tepat atas parameter infrastruktur penting. Misalnya, Anda dapat menentukan penempatan subnet pribadi untuk keamanan yang ditingkatkan, mengonfigurasi penyimpanan sementara instance untuk beban kerja yang sensitif terhadap kinerja, atau menerapkan penandaan khusus untuk alokasi biaya.
## Buat Kelas Node
Untuk membuat`NodeClass`, ikuti langkah-langkah ini:
1. Buat file YAMM (misalnya,`nodeclass.yaml`) dengan konfigurasi Kelas Node Anda
1. Terapkan konfigurasi ke cluster Anda menggunakan `kubectl`
1. Referensi Kelas Node dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
Anda perlu `kubectl` diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
### Contoh Kelas Node Dasar
Berikut adalah contoh Kelas Node:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: private-compute
spec:
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
ephemeralStorage:
size: "160Gi"
```
Ini NodeClass meningkatkan jumlah penyimpanan fana pada node.
Terapkan konfigurasi ini dengan menggunakan:
```
kubectl apply -f nodeclass.yaml
```
Selanjutnya, referensi Kelas Node dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Buat entri akses kelas node
Jika Anda membuat kelas node kustom, Anda perlu membuat Entri Akses EKS untuk mengizinkan node bergabung dengan cluster. EKS secara otomatis membuat entri akses saat Anda menggunakan kelas node dan kumpulan node bawaan.
Untuk informasi tentang cara kerja Entri Akses, lihat[Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md).
Saat membuat entri akses untuk kelas node Mode Otomatis EKS, Anda perlu menggunakan jenis entri `EC2` akses.
### Buat entri akses dengan CLI
**Untuk membuat entri akses untuk node EC2 dan mengaitkan Kebijakan Node Otomatis EKS:**
Perbarui perintah CLI berikut dengan nama cluster Anda, dan peran node ARN. Peran node ARN ditentukan dalam kelas node YAMM.
```
# Create the access entry for EC2 nodes
aws eks create-access-entry \
--cluster-name \
--principal-arn \
--type EC2
# Associate the auto node policy
aws eks associate-access-policy \
--cluster-name \
--principal-arn \
--policy-arn arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy \
--access-scope type=cluster
```
### Buat entri akses dengan CloudFormation
**Untuk membuat entri akses untuk node EC2 dan mengaitkan Kebijakan Node Otomatis EKS:**
Perbarui yang berikut ini CloudFormation dengan nama cluster Anda, dan peran node ARN. Peran node ARN ditentukan dalam kelas node YAMM.
```
EKSAutoNodeRoleAccessEntry:
Type: AWS::EKS::AccessEntry
Properties:
ClusterName:
PrincipalArn:
Type: "EC2"
AccessPolicies:
- AccessScope:
Type: cluster
PolicyArn: arn:aws: eks::aws:cluster-access-policy/AmazonEKSAutoNodePolicy
DependsOn: [ ] # previously defined in CloudFormation
```
Untuk informasi tentang menerapkan CloudFormation tumpukan, lihat [Memulai CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/GettingStarted.html)
## Spesifikasi Kelas Node
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Required fields
# role and instanceProfile are mutually exclusive fields.
role: MyNodeRole # IAM role for EC2 instances
# instanceProfile: eks-MyNodeInstanceProfile # IAM instance-profile for EC2 instances
subnetSelectorTerms:
- tags:
Name: "private-subnet"
kubernetes.io/role/internal-elb: "1"
# Alternative using direct subnet ID
# - id: "subnet-0123456789abcdef0"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Alternative approaches:
# - id: "sg-0123456789abcdef0"
# - name: "eks-cluster-security-group"
# Optional: Pod subnet selector for advanced networking
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
# Alternative using direct subnet ID
# - id: "subnet-0987654321fedcba0"
# must include Pod security group selector also
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
# Alternative using direct security group ID
# - id: "sg-0123456789abcdef0"
# Optional: Selects on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
Name: "targeted-odcr"
# Optional owning account ID filter
owner: "012345678901"
# Optional fields
snatPolicy: Random # or Disabled
networkPolicy: DefaultAllow # or DefaultDeny
networkPolicyEventLogs: Disabled # or Enabled
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# Optional KMS key for encryption
kmsKeyID: "arn:aws: kms:region:account:key/key-id"
# Accepted formats:
# KMS Key ID
# KMS Key ARN
# Key Alias Name
# Key Alias ARN
advancedNetworking:
# Optional: Controls whether public IP addresses are assigned to instances that are launched with the nodeclass.
# If not set, defaults to the MapPublicIpOnLaunch setting on the subnet.
associatePublicIPAddress: false
# Optional: Forward proxy, commonly requires certificateBundles as well
# for EC2, see https://repost.aws/knowledge-center/eks-http-proxy-containerd-automation
httpsProxy: http://192.0.2.4:3128 #commonly port 3128 (Squid) or 8080 (NGINX) #Max 255 characters
#httpsProxy: http://[2001:db8::4]:3128 # IPv6 address with port, use []
noProxy: #Max 50 entries
- localhost #Max 255 characters each
- 127.0.0.1
#- ::1 # IPv6 localhost
#- 0:0:0:0:0:0:0:1 # IPv6 localhost
- 169.254.169.254 # EC2 Instance Metadata Service
#- [fd00:ec2::254] # IPv6 EC2 Instance Metadata Service
# Domains to exclude, put all VPC endpoints here
- .internal
- .eks.amazonaws.com
# ipv4PrefixSize is default to Auto which is prefix and fallback to secondary IP. "32" is the secondary IP mode.
ipv4PrefixSize: Auto # or "32"
# enableV4Egress is default to true. Setting it to false when using network policy or blocking IPv4 traffic in IPv6 clusters
enableV4Egress: false
advancedSecurity:
# Optional, US regions only: Specifying `fips: true` will cause nodes in the nodeclass to run FIPS compatible AMIs.
fips: false
# Optional: Custom certificate bundles.
certificateBundles:
- name: "custom-cert"
data: "base64-encoded-cert-data"
# Optional: Additional EC2 tags (with restrictions)
tags:
Environment: "production"
Team: "platform"
# Note: Cannot use restricted tags like:
# - kubernetes.io/cluster/*
# - karpenter.sh/provisioner-name
# - karpenter.sh/nodepool
# - karpenter.sh/nodeclaim
# - karpenter.sh/managed-by
# - eks.amazonaws.com/nodeclass
```
## Pertimbangan-pertimbangan
+ Jika Anda ingin memverifikasi berapa banyak penyimpanan lokal yang dimiliki sebuah instans, Anda dapat menjelaskan node untuk melihat sumber daya penyimpanan sementara.
+ **Enkripsi Volume** - EKS menggunakan kunci KMS kustom yang dikonfigurasi untuk mengenkripsi volume root read-only dari instance dan volume data. read/write
+ **Ganti peran IAM node** - Jika Anda mengubah peran IAM node yang terkait dengan a`NodeClass`, Anda harus membuat Entri Akses baru. EKS secara otomatis membuat Entri Akses untuk peran IAM node selama pembuatan cluster. Peran IAM node memerlukan Kebijakan Akses `AmazonEKSAutoNodePolicy` EKS. Untuk informasi selengkapnya, lihat [Berikan akses kepada pengguna IAM ke Kubernetes dengan entri akses EKS](access-entries.md).
+ **Kepadatan Pod maksimum** - EKS membatasi jumlah maksimum Pod pada sebuah node menjadi 110. Batas ini diterapkan setelah perhitungan Max Pod yang ada. Untuk informasi selengkapnya, lihat [Pilih jenis instans node Amazon EC2 yang optimal](choosing-instance-type.md).
+ **Tag** - Jika Anda ingin menyebarkan tag dari Kubernetes ke EC2, Anda perlu mengonfigurasi izin IAM tambahan. Untuk informasi selengkapnya, lihat [Pelajari tentang identitas dan akses dalam Mode Otomatis EKS](auto-learn-iam.md).
+ **Kelas node default** - Jangan beri nama kelas node kustom Anda`default`. Ini karena Mode Otomatis EKS menyertakan `NodeClass` panggilan `default` yang secara otomatis disediakan ketika Anda mengaktifkan setidaknya satu built-in. `NodePool` Untuk informasi tentang mengaktifkan bawaan`NodePools`, lihat[Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
+ **`subnetSelectorTerms`perilaku dengan beberapa subnet** - Jika ada beberapa subnet yang cocok dengan `subnetSelectorTerms` kondisi atau yang Anda berikan oleh ID, Mode Otomatis EKS membuat node yang didistribusikan di seluruh subnet.
+ Jika subnet berada di Availability Zones (AZs) yang berbeda, Anda dapat menggunakan fitur Kubernetes seperti [kendala penyebaran topologi Pod dan Topology Aware Routing untuk menyebarkan](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#pod-topology-spread-constraints) [Pod](https://kubernetes.io/docs/concepts/services-networking/topology-aware-routing/) dan lalu lintas di seluruh zona.
+ Jika ada beberapa subnet *dalam AZ yang sama yang* cocok dengan`subnetSelectorTerms`, Mode Otomatis EKS membuat Pod pada setiap node yang didistribusikan di seluruh subnet di AZ tersebut. Mode Otomatis EKS membuat antarmuka jaringan sekunder pada setiap node di subnet lain di AZ yang sama. Ini memilih berdasarkan jumlah alamat IP yang tersedia di setiap subnet, untuk menggunakan subnet lebih efisien. Namun, Anda tidak dapat menentukan subnet EKS Auto Mode mana yang digunakan untuk setiap Pod; jika Anda membutuhkan Pod untuk berjalan di subnet tertentu, gunakan [Pisahkan subnet dan grup keamanan untuk Pod](#pod-subnet-selector) saja.
## Pisahkan subnet dan grup keamanan untuk Pod
`podSecurityGroupSelectorTerms`Bidang `podSubnetSelectorTerms` and memungkinkan konfigurasi jaringan tingkat lanjut dengan memungkinkan Pod menggunakan subnet dan grup keamanan yang berbeda dari node mereka. Kedua bidang harus ditentukan bersama. Pemisahan ini memberikan kontrol yang ditingkatkan atas perutean lalu lintas jaringan dan kebijakan keamanan.
**catatan**
Fitur ini berbeda dengan fitur [Security Groups for Pods](security-groups-for-pods.md) (SGPP) yang digunakan dengan AWS VPC CNI untuk komputasi Mode Otomatis non-EKS. SGPP tidak didukung dalam Mode Otomatis EKS. Sebagai gantinya, gunakan `podSecurityGroupSelectorTerms` in `NodeClass` untuk menerapkan grup keamanan terpisah ke lalu lintas Pod. Grup keamanan berlaku pada `NodeClass` level tersebut, artinya semua Pod pada node yang `NodeClass` menggunakan grup keamanan Pod yang sama.
### Cara kerjanya
Saat Anda mengkonfigurasi `podSubnetSelectorTerms` dan`podSecurityGroupSelectorTerms`:
1. ENI primer node menggunakan subnet dan grup keamanan dari `subnetSelectorTerms` dan`securityGroupSelectorTerms`. Hanya alamat IP node sendiri yang ditetapkan ke antarmuka ini.
1. Mode Otomatis EKS menciptakan sekunder ENIs dalam pencocokan subnet`podSubnetSelectorTerms`, dengan grup keamanan dari `podSecurityGroupSelectorTerms` terpasang. Alamat IP Pod dialokasikan dari sekunder ini ENIs menggunakan awalan /28 secara default, dengan fallback otomatis ke sekunder IPs (/32) ketika blok awalan yang berdekatan tidak tersedia. Jika `ipv4PrefixSize` diatur ke `"32"` in`advancedNetworking`, hanya sekunder IPs yang digunakan.
1. Grup keamanan yang ditentukan `podSecurityGroupSelectorTerms` berlaku untuk lalu lintas Pod di dalam VPC. Untuk lalu lintas yang ditujukan di luar VPC, Pod menggunakan ENI primer node (dan grup keamanannya) karena terjemahan alamat jaringan sumber (SNAT) menerjemahkan IP Pod ke IP node. Anda dapat mengubah perilaku ini dengan `snatPolicy` bidang di`NodeClass`.
### Kasus penggunaan
Gunakan `podSubnetSelectorTerms` dan `podSecurityGroupSelectorTerms` kapan Anda perlu:
+ Terapkan grup keamanan yang berbeda untuk mengontrol lalu lintas node dan Pod secara terpisah.
+ Pisahkan lalu lintas infrastruktur (node-to-node komunikasi) dari lalu lintas aplikasi (Pod-to-Pod komunikasi).
+ Menerapkan konfigurasi jaringan yang berbeda ke subnet node daripada subnet Pod.
+ Konfigurasikan proxy terbalik atau pemfilteran jaringan khusus untuk lalu lintas node tanpa memengaruhi lalu lintas Pod. Gunakan `advancedNetworking` dan `certificateBundles` untuk menentukan proxy terbalik Anda dan sertifikat yang ditandatangani sendiri atau pribadi untuk proxy.
### Contoh konfigurasi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
# Subnets and security groups for EC2 instances (nodes)
subnetSelectorTerms:
- tags:
Name: "node-subnet"
kubernetes.io/role/internal-elb: "1"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
# Separate subnets and security groups for Pods
podSubnetSelectorTerms:
- tags:
Name: "pod-subnet"
kubernetes.io/role/pod: "1"
podSecurityGroupSelectorTerms:
- tags:
Name: "eks-pod-sg"
```
### Pertimbangan untuk subnet Pod dan grup keamanan terpisah
+ **Lingkup grup keamanan**: Grup keamanan dari `podSecurityGroupSelectorTerms` dilampirkan ke sekunder ENIs dan berlaku untuk lalu lintas Pod di dalam VPC. Ketika SNAT diaktifkan (default`snatPolicy: Random`), lalu lintas yang meninggalkan VPC diterjemahkan ke alamat IP ENI utama node, sehingga grup `securityGroupSelectorTerms` keamanan node diterapkan ke lalu lintas itu sebagai gantinya. Jika Anda mengatur`snatPolicy: Disabled`, Pod menggunakan alamat IP mereka sendiri untuk semua lalu lintas, dan Anda harus memastikan bahwa routing dan grup keamanan dikonfigurasi sesuai dengan itu.
+ **NodeClass-level granularity**: Grup keamanan Pod berlaku untuk semua Pod yang dijadwalkan pada node menggunakan. `NodeClass` Untuk menerapkan grup keamanan yang berbeda ke beban kerja yang berbeda, buat `NodePool` sumber daya terpisah `NodeClass` dan gunakan taint, toleransi, atau pemilih node untuk menjadwalkan beban kerja ke node yang sesuai.
+ **Mengurangi kepadatan Pod**: Lebih sedikit Pod yang dapat berjalan pada setiap node karena antarmuka jaringan utama node dicadangkan untuk IP node dan tidak dapat digunakan untuk Pod.
+ **Batasan pemilih subnet**: Standar `subnetSelectorTerms` dan `securityGroupSelectorTerms` konfigurasi tidak berlaku untuk subnet Pod atau pemilihan grup keamanan.
+ **Perencanaan jaringan**: Pastikan ruang alamat IP yang memadai di subnet node dan Pod untuk mendukung kebutuhan beban kerja Anda.
+ **Konfigurasi routing**: Verifikasi bahwa tabel rute dan Network Access Control List (ACL) dari subnet Pod dikonfigurasi dengan benar untuk komunikasi antara subnet node dan Pod.
+ **Availability Zones**: Verifikasi bahwa Anda telah membuat subnet Pod di beberapa AZs subnet. Jika Anda menggunakan subnet Pod tertentu, subnet tersebut harus berada di AZ yang sama dengan subnet node AZ.
## Mode IP Sekunder untuk Pod
`ipv4PrefixSize`Bidang ini memungkinkan konfigurasi jaringan lanjutan dengan mengalokasikan hanya alamat IP sekunder ke node. Fitur ini tidak mengalokasikan awalan (/28) ke node dan hanya mempertahankan satu IP sekunder sebagai Minimal. IPTarget
### Kasus penggunaan
Gunakan `ipv4PrefixSize` saat Anda perlu:
+ **Pengurangan pemanfaatan IP**: Hanya satu alamat IP yang akan dihangatkan di setiap node.
+ **Tingkat churning pod yang lebih rendah**: Kecepatan pembuatan pod bukanlah masalah utama.
+ **Tidak ada fragmentasi awalan: Fragmentasi** yang disebabkan oleh awalan adalah perhatian utama atau pemblokir untuk menggunakan Mode Otomatis.
### Contoh konfigurasi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
ipv4PrefixSize: "32"
```
### Pertimbangan untuk mode IP sekunder
+ **Kecepatan pembuatan Pod yang berkurang**: Karena hanya satu IP sekunder yang dihangatkan, layanan IPAM membutuhkan lebih banyak waktu untuk menyediakan IPs ketika lebih banyak pod dibuat.
## IPv4 Nonaktifkan jalan keluar dari IPv6 pod dalam IPv6 cluster.
`enableV4Egress`Bidang ini secara `true` default. Untuk IPv6 kluster Mode Otomatis, fitur ini dapat dinonaktifkan sehingga Mode Otomatis tidak akan membuat antarmuka khusus egres untuk pod IPv4 . IPv6 Ini penting karena antarmuka jalan IPv4 keluar tidak tunduk pada penegakan Kebijakan Jaringan. Kebijakan jaringan hanya diberlakukan pada antarmuka utama Pod (eth0).
### Kasus penggunaan
Gunakan `enableV4Egress` saat Anda perlu:
+ **Gunakan IPv6 Cluster** IPv4 : lalu lintas keluar diizinkan secara default.
+ **Gunakan Kebijakan Jaringan**: Saat ini Kebijakan Jaringan EKS tidak mendukung tumpukan ganda. Menonaktifkan `enableV4Egress` dapat mencegah lalu lintas pod keluar secara tak terduga. IPv4
### Contoh konfigurasi
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: advanced-networking
spec:
role: MyNodeRole
advancedNetworking:
enableV4Egress: false
```
### Pertimbangan untuk menonaktifkan EnableV4eGress
+ **Kebijakan Jaringan di IPv6 Cluster: IPv6 cluster** mengizinkan IPv4 lalu lintas secara default. Pengaturan `enableV4Egress: false` memblokir IPv4 lalu lintas keluar, memberikan keamanan yang ditingkatkan terutama ketika digunakan dengan Kebijakan Jaringan.
# Buat Node Pool untuk Mode Otomatis EKS
Kumpulan node Amazon EKS menawarkan cara yang fleksibel untuk mengelola sumber daya komputasi di klaster Kubernetes Anda. Topik ini menunjukkan cara membuat dan mengkonfigurasi kumpulan node dengan menggunakan Karpenter, alat penyediaan node yang membantu mengoptimalkan penskalaan cluster dan pemanfaatan sumber daya. Dengan NodePool sumber daya Karpenter, Anda dapat menentukan persyaratan spesifik untuk sumber daya komputasi Anda, termasuk jenis instans, zona ketersediaan, arsitektur, dan jenis kapasitas.
Anda tidak dapat memodifikasi kumpulan bawaan `system` dan `general-purpose` node. Anda hanya dapat mengaktifkan atau menonaktifkannya. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
NodePool Spesifikasi ini memungkinkan kontrol halus atas sumber daya komputasi kluster EKS Anda melalui berbagai label dan persyaratan yang didukung. Ini termasuk opsi untuk menentukan kategori EC2 instance, konfigurasi CPU, zona ketersediaan, arsitektur (ARM64/AMD64), dan jenis kapasitas (spot atau on-demand). Anda juga dapat menetapkan batas sumber daya untuk penggunaan CPU dan memori, memastikan klaster Anda tetap berada dalam batas operasional yang diperlukan.
Mode Otomatis EKS memanfaatkan label Kubernetes yang terkenal untuk memberikan cara yang konsisten dan terstandarisasi dalam mengidentifikasi karakteristik node. Label ini, seperti `topology.kubernetes.io/zone` untuk zona ketersediaan dan `kubernetes.io/arch` arsitektur CPU, mengikuti konvensi Kubernetes yang telah ditetapkan. Selain itu, label khusus EKS (diawali dengan`eks.amazonaws.com/`) memperluas fungsionalitas ini dengan atribut AWS-spesifik seperti tipe instance, produsen CPU, kemampuan GPU, dan spesifikasi jaringan. Sistem pelabelan standar ini memungkinkan integrasi tanpa batas dengan alat Kubernetes yang ada sambil menyediakan integrasi infrastruktur yang mendalam. AWS
## Buat NodePool
Ikuti langkah-langkah berikut NodePool untuk membuat klaster Amazon EKS Anda:
1. Buat file YAMB bernama `nodepool.yaml` dengan NodePool konfigurasi yang Anda butuhkan. Anda dapat menggunakan konfigurasi sampel di bawah ini.
1. Terapkan NodePool ke cluster Anda:
```
kubectl apply -f nodepool.yaml
```
1. Verifikasi bahwa NodePool telah berhasil dibuat:
```
kubectl get nodepools
```
1. (Opsional) Pantau NodePool status:
```
kubectl describe nodepool default
```
Pastikan NodePool referensi Anda valid NodeClass yang ada di cluster Anda. NodeClass Mendefinisikan konfigurasi AWS-spesifik untuk sumber daya komputasi Anda. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
## Sampel NodePool
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b"]
- key: "kubernetes.io/arch"
operator: In
values: ["arm64", "amd64"]
limits:
cpu: "1000"
memory: 1000Gi
```
## Label yang Didukung Mode Otomatis EKS
Mode Otomatis EKS mendukung label terkenal berikut ini.
**catatan**
Mode Otomatis EKS menggunakan label yang berbeda dari Karpenter. Label yang terkait dengan instance EC2 terkelola dimulai dengan`eks.amazonaws.com`.
| Label | Contoh | Deskripsi |
| --- | --- | --- |
| topology.kubernetes.io/zone | us-timur-2a | AWS wilayah |
| node.kubernetes.io/instance-type | g4dn.8xlarge | AWS jenis contoh |
| kubernetes.io/lengkungan | amd64 | Arsitektur didefinisikan oleh [nilai-nilai GOARCH](https://github.com/golang/go/blob/master/src/internal/syslist/syslist.go#L58) pada instance |
| karpenter.sh/tipe kapasitas | melihat | Jenis kapasitas meliputi`spot`, `on-demand` |
| eks.amazonaws.com/instance-hypervisor | nitro | Jenis instans yang menggunakan hypervisor tertentu |
| eks.amazonaws.com/compute-type | auto | Mengidentifikasi node terkelola Mode Otomatis EKS |
| eks.amazonaws.com/ -didukung instance-encryption-in-transit | true | Jenis instans yang mendukung (atau tidak) enkripsi dalam transit |
| eks.amazonaws.com/instance-category | g | Jenis instance dari kategori yang sama, biasanya string sebelum nomor generasi |
| eks.amazonaws.com/instance-generation | 4 | Nomor generasi tipe instans dalam kategori instance |
| eks.amazonaws.com/instance-family | g4dn | Jenis instance dari properti serupa tetapi jumlah sumber daya yang berbeda |
| eks.amazonaws.com/instance-size | 8xlarge | Jenis contoh dari jumlah sumber daya yang sama tetapi properti yang berbeda |
| eks.amazonaws.com/instance-cpu | 32 | Jumlah CPUs pada instance |
| eks.amazonaws.com/ instance-cpu-manufacturer | `aws` | Nama produsen CPU |
| eks.amazonaws.com/instance-memory | 131072 | Jumlah mebibytes memori pada instance |
| eks.amazonaws.com/ instance-ebs-bandwidth | 9500 | Jumlah [maksimum megabit](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-optimized.html#ebs-optimization-performance) EBS yang tersedia pada instans |
| eks.amazonaws.com/ instance-network-bandwidth | 131072 | Jumlah [megabit dasar yang tersedia pada instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html) |
| eks.amazonaws.com/ instance-gpu-name | t4 | Nama GPU pada instance, jika tersedia |
| eks.amazonaws.com/ instance-gpu-manufacturer | nvidia | Nama produsen GPU |
| eks.amazonaws.com/ instance-gpu-count | 1 | Jumlah GPUs pada instance |
| eks.amazonaws.com/ instance-gpu-memory | 16384 | Jumlah mebibytes memori pada GPU |
| eks.amazonaws.com/ instance-local-nvme | 900 | Jumlah gibibyte penyimpanan nvme lokal pada instance |
**catatan**
Mode Otomatis EKS hanya mendukung instance tertentu, dan memiliki persyaratan ukuran minimum. Untuk informasi selengkapnya, lihat [Referensi instans yang didukung Mode Otomatis EKS](automode-learn-instances.md#auto-supported-instances).
## Mode Otomatis EKS Tidak Didukung Label
Mode Otomatis EKS tidak mendukung label berikut.
+ Mode Otomatis EKS hanya mendukung Linux
+ `node.kubernetes.io/windows-build`
+ `kubernetes.io/os`
## Nonaktifkan kolam node bawaan
Jika Anda membuat kumpulan node kustom, Anda dapat menonaktifkan kumpulan node bawaan. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
## Cluster tanpa kolam node bawaan
Anda dapat membuat cluster tanpa kumpulan node bawaan. Ini sangat membantu ketika organisasi Anda telah membuat kumpulan node yang disesuaikan.
**catatan**
Saat Anda membuat cluster tanpa kumpulan node bawaan, cluster tidak `default` NodeClass disediakan secara otomatis. Anda harus membuat kustom NodeClass. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
**Ikhtisar:**
1. Buat cluster EKS dengan keduanya `nodePools` dan `nodeRoleArn` nilai kosong.
+ Contoh `autoModeConfig` eksctl:
```
autoModeConfig:
enabled: true
nodePools: []
# Do not set a nodeRoleARN
```
Untuk informasi selengkapnya, lihat [Buat Kluster Mode Otomatis EKS dengan CLI eksctl](automode-get-started-eksctl.md)
1. Buat kelas node kustom dengan peran node ARN
+ Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md)
1. Buat entri akses untuk kelas node kustom
+ Untuk informasi selengkapnya, lihat [Buat entri akses kelas node](create-node-class.md#auto-node-access-entry)
1. Buat kumpulan node kustom, seperti dijelaskan di atas.
## Gangguan
Anda dapat mengonfigurasi Mode Otomatis EKS untuk mengganggu Node melalui Anda NodePool dalam berbagai cara. Anda dapat menggunakan`spec.disruption.consolidationPolicy`,`spec.disruption.consolidateAfter`, atau`spec.template.spec.expireAfter`. Anda juga dapat menilai batas gangguan Mode Otomatis EKS melalui NodePool's. `spec.disruption.budgets` Anda juga dapat mengontrol jendela waktu dan jumlah Node simultan yang terganggu. Untuk petunjuk tentang mengonfigurasi perilaku ini, lihat [Gangguan](https://karpenter.sh/docs/concepts/disruption/) dalam Dokumentasi Karpenter.
Anda dapat mengonfigurasi gangguan untuk kumpulan node menjadi:
+ Identifikasi kapan instance kurang dimanfaatkan, dan konsolidasikan beban kerja.
+ Buat anggaran gangguan kumpulan node untuk menilai penghentian node batas karena penyimpangan, kekosongan, dan konsolidasi.
Secara default, Mode Otomatis EKS:
+ Mengkonsolidasikan instance yang kurang dimanfaatkan.
+ Mengakhiri instance setelah 336 jam.
+ Menetapkan anggaran gangguan tunggal 10% dari node.
+ Memungkinkan Node diganti karena drift ketika AMI Mode Otomatis baru dirilis, yang terjadi kira-kira sekali per minggu.
## Masa Tenggang Penghentian
Ketika a tidak `terminationGracePeriod` didefinisikan secara eksplisit pada EKS Auto NodePool, sistem secara otomatis menerapkan masa tenggang penghentian 24 jam default ke yang terkait. NodeClaim Meskipun pelanggan EKS Auto tidak akan melihat `terminationGracePeriod` default dalam NodePool konfigurasi kustom mereka, mereka akan mengamati nilai default ini di. NodeClaim Fungsionalitas tetap konsisten apakah masa tenggang ditetapkan secara eksplisit pada NodePool atau default pada NodeClaim, memastikan perilaku penghentian node yang dapat diprediksi di seluruh cluster.
# Kolam Node Kapasitas Statis dalam Mode Otomatis EKS
Amazon EKS Auto Mode mendukung kumpulan node kapasitas statis yang mempertahankan jumlah node tetap terlepas dari permintaan pod. Kumpulan node kapasitas statis berguna untuk beban kerja yang memerlukan kapasitas yang dapat diprediksi, instance cadangan, atau persyaratan kepatuhan khusus di mana Anda perlu mempertahankan jejak infrastruktur yang konsisten.
Tidak seperti kumpulan node dinamis yang menskalakan berdasarkan permintaan penjadwalan pod, kumpulan node kapasitas statis mempertahankan jumlah node yang telah Anda konfigurasikan.
## Konfigurasikan kumpulan node kapasitas statis
Untuk membuat kumpulan node kapasitas statis, atur `replicas` bidang dalam NodePool spesifikasi Anda. `replicas`Bidang mendefinisikan jumlah pasti node yang akan dipertahankan oleh kumpulan node. Lihat [Contoh](#static-capacity-examples) cara mengkonfigurasi`replicas`.
## Pertimbangan kumpulan node kapasitas statis
Pool node kapasitas statis memiliki beberapa kendala dan perilaku penting:
**Kendala konfigurasi:**
+ **Tidak dapat beralih mode**: Setelah Anda mengatur `replicas` kumpulan node, Anda tidak dapat menghapusnya. Kumpulan node tidak dapat beralih antara mode statis dan dinamis.
+ **Batas sumber daya terbatas**: Hanya `limits.nodes` bidang yang didukung di bagian batas. Batas CPU dan memori tidak berlaku.
+ **Tidak ada bidang berat**: `weight` Bidang tidak dapat diatur pada kumpulan node kapasitas statis karena pemilihan node tidak didasarkan pada prioritas.
**Perilaku operasional:**
+ **Tidak ada konsolidasi**: Node dalam kumpulan kapasitas statis tidak dipertimbangkan untuk konsolidasi.
+ **Operasi penskalaan**: Operasi skala melewati anggaran gangguan node tetapi masih menghormati. PodDisruptionBudgets
+ **Penggantian node**: Node masih diganti untuk drift (seperti pembaruan AMI) dan kedaluwarsa berdasarkan konfigurasi Anda.
## Praktik terbaik
**Perencanaan kapasitas:**
+ Tetapkan `limits.nodes` lebih tinggi daripada `replicas` untuk memungkinkan penskalaan sementara selama operasi penggantian node.
+ Pertimbangkan kapasitas maksimum yang diperlukan selama node drift atau pembaruan AMI saat menetapkan batas.
**Pemilihan instans:**
+ Gunakan jenis instans tertentu ketika Anda memiliki Instans Cadangan atau persyaratan perangkat keras tertentu.
+ Hindari persyaratan yang terlalu ketat yang mungkin membatasi ketersediaan instance selama penskalaan.
**Manajemen gangguan:**
+ Konfigurasikan anggaran gangguan yang sesuai untuk menyeimbangkan ketersediaan dengan operasi pemeliharaan.
+ Pertimbangkan toleransi aplikasi Anda untuk penggantian node saat menetapkan persentase anggaran.
**Pemantauan** :
+ Pantau `status.nodes` lapangan secara teratur untuk memastikan kapasitas yang Anda inginkan tetap terjaga.
+ Siapkan peringatan ketika jumlah node sebenarnya menyimpang dari replika yang diinginkan.
**Distribusi zona:**
+ Untuk ketersediaan tinggi, sebarkan kapasitas statis di beberapa Availability Zone.
+ Saat Anda membuat kumpulan node kapasitas statis yang mencakup beberapa zona ketersediaan, Mode Otomatis EKS mendistribusikan node di seluruh zona yang ditentukan, tetapi distribusinya tidak dijamin genap.
+ Untuk distribusi yang dapat diprediksi dan merata di seluruh zona ketersediaan, buat kumpulan node kapasitas statis terpisah, masing-masing disematkan ke zona ketersediaan tertentu menggunakan `topology.kubernetes.io/zone` persyaratan.
+ Jika Anda membutuhkan 12 node yang didistribusikan secara merata di tiga zona, buat tiga kumpulan node dengan masing-masing 4 replika, bukan satu kumpulan node dengan 12 replika di tiga zona.
## Menskalakan kumpulan node kapasitas statis
Anda dapat mengubah jumlah replika dalam kumpulan node kapasitas statis menggunakan `kubectl scale` perintah:
```
# Scale down to 5 nodes
kubectl scale nodepool static-nodepool --replicas=5
```
Saat menurunkan skala, Mode Otomatis EKS akan menghentikan node dengan anggun, menghormati PodDisruptionBudgets dan memungkinkan pod yang sedang berjalan dijadwalkan ulang ke node yang tersisa.
## Pantau kolam simpul kapasitas statis
Gunakan perintah berikut untuk memantau kumpulan node kapasitas statis Anda:
```
# View node pool status
kubectl get nodepool static-nodepool
# Get detailed information including current node count
kubectl describe nodepool static-nodepool
# Check the current number of nodes
kubectl get nodepool static-nodepool -o jsonpath='{.status.nodes}'
```
`status.nodes`Bidang menunjukkan jumlah node saat ini yang dikelola oleh kumpulan node, yang harus sesuai dengan `replicas` jumlah yang Anda inginkan dalam kondisi normal.
## Pemecahan masalah
**Node tidak mencapai replika yang diinginkan:**
+ Periksa apakah `limits.nodes` nilainya cukup
+ Verifikasi bahwa persyaratan Anda tidak terlalu membatasi pemilihan instans
+ Tinjau kuota AWS layanan untuk jenis dan wilayah instans yang Anda gunakan
**Penggantian node terlalu lama:**
+ Sesuaikan anggaran gangguan untuk memungkinkan penggantian lebih bersamaan
+ Periksa PodDisruptionBudgets apakah mencegah penghentian simpul
**Penghentian simpul yang tidak terduga:**
+ Tinjau `expireAfter` dan `terminationGracePeriod` pengaturan
+ Periksa penghentian node manual atau acara AWS pemeliharaan
## Contoh
### Kolam simpul kapasitas statis dasar
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: basic-static
spec:
replicas: 5
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["m"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a"]
limits:
nodes: 8 # Allow scaling up to 8 during operations
```
### Kapasitas statis dengan tipe instans tertentu
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: reserved-instances
spec:
replicas: 20
template:
metadata:
labels:
instance-type: reserved
cost-center: production
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "node.kubernetes.io/instance-type"
operator: In
values: ["m5.2xlarge"] # Specific instance type
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
limits:
nodes: 25
disruption:
# Conservative disruption for production workloads
budgets:
- nodes: 10%
```
### Kolam simpul kapasitas statis multi-zona
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: multi-zone-static
spec:
replicas: 12 # Will be distributed across specified zones
template:
metadata:
labels:
availability: high
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: default
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["8", "16"]
- key: "topology.kubernetes.io/zone"
operator: In
values: ["us-west-2a", "us-west-2b", "us-west-2c"]
- key: "karpenter.sh/capacity-type"
operator: In
values: ["on-demand"]
limits:
nodes: 15
disruption:
budgets:
- nodes: 25%
```
### Kapasitas statis dengan reservasi kapasitas
Contoh berikut menunjukkan cara menggunakan kolam node kapasitas statis dengan Reservasi Kapasitas EC2. Untuk informasi selengkapnya tentang penggunaan Reservasi Kapasitas EC2 dengan Mode Otomatis EKS, lihat. [Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS](auto-odcr.md)
`NodeClass`mendefinisikan `capacityReservationSelectorTerms`
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: capacity-reservation-nodeclass
spec:
role: AmazonEKSNodeRole
securityGroupSelectorTerms:
- id: sg-0123456789abcdef0
subnetSelectorTerms:
- id: subnet-0123456789abcdef0
capacityReservationSelectorTerms:
- id: cr-0123456789abcdef0
```
`NodePool`mereferensikan hal di atas `NodeClass` dan menggunakan`karpenter.sh/capacity-type: reserved`.
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: static-capacity-reservation-nodepool
spec:
replicas: 5
limits:
nodes: 8 # Allow scaling up to 8 during operations
template:
metadata: {}
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: capacity-reservation-nodeclass
requirements:
- key: karpenter.sh/capacity-type
operator: In
values: ['reserved']
```
# Buat IngressClass untuk mengkonfigurasi Application Load Balancer
Mode Otomatis EKS mengotomatiskan tugas rutin untuk penyeimbangan beban, termasuk mengekspos aplikasi cluster ke internet.
AWS menyarankan menggunakan Application Load Balancers (ALB) untuk melayani lalu lintas HTTP dan HTTPS. Application Load Balancers dapat merutekan permintaan berdasarkan konten permintaan. Untuk informasi selengkapnya tentang Application Load Balancer, lihat [Apa itu Elastic](https://docs.aws.amazon.com/elasticloadbalancing/latest/userguide/what-is-load-balancing.html) Load Balancing?
EKS Auto Mode membuat dan mengkonfigurasi Application Load Balancers (). ALBs Misalnya, Mode Otomatis EKS membuat penyeimbang beban saat Anda membuat objek `Ingress` Kubernetes dan mengonfigurasinya untuk merutekan lalu lintas ke beban kerja klaster Anda.
**Ikhtisar**
1. Buat beban kerja yang ingin Anda ekspos ke internet.
1. Buat `IngressClassParams` sumber daya, tentukan nilai konfigurasi AWS tertentu seperti sertifikat yang akan digunakan untuk SSL/TLS dan Subnet VPC.
1. Buat `IngressClass` sumber daya, tentukan bahwa Mode Otomatis EKS akan menjadi pengontrol untuk sumber daya.
1. Buat `Ingress` sumber daya yang mengaitkan jalur HTTP dan port dengan beban kerja cluster.
Mode Otomatis EKS akan membuat Application Load Balancer yang menunjuk ke beban kerja yang ditentukan dalam `Ingress` sumber daya, menggunakan konfigurasi penyeimbang beban yang ditentukan dalam sumber daya. `IngressClassParams`
## Prasyarat
+ Mode Otomatis EKS Diaktifkan di Amazon EKS Cluster
+ Kubectl dikonfigurasi untuk terhubung ke klaster Anda
+ Anda dapat menggunakan `kubectl apply -f ` untuk menerapkan konfigurasi sampel file YAMAL di bawah ini ke cluster Anda.
**catatan**
Mode Otomatis EKS memerlukan tag subnet untuk mengidentifikasi subnet publik dan pribadi.
Jika Anda membuat cluster Anda dengan`eksctl`, Anda sudah memiliki tag ini.
Pelajari cara [Tag subnet untuk Mode Otomatis EKS](tag-subnets-auto.md).
## Langkah 1: Buat beban kerja
Untuk memulai, buat beban kerja yang ingin Anda ekspos ke internet. Ini bisa berupa sumber daya Kubernetes yang melayani lalu lintas HTTP, seperti Deployment atau Service.
Contoh ini menggunakan layanan HTTP sederhana `service-2048` yang disebut yang mendengarkan pada port`80`. Buat layanan ini dan penyebarannya dengan menerapkan manifes berikut,`2048-deployment-service.yaml`:
```
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment-2048
spec:
selector:
matchLabels:
app.kubernetes.io/name: app-2048
replicas: 2
template:
metadata:
labels:
app.kubernetes.io/name: app-2048
spec:
containers:
- image: public.ecr.aws/l6m2t8p7/docker-2048:latest
imagePullPolicy: Always
name: app-2048
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
name: service-2048
spec:
ports:
- port: 80
targetPort: 80
protocol: TCP
type: NodePort
selector:
app.kubernetes.io/name: app-2048
```
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f 2048-deployment-service.yaml
```
Sumber daya yang tercantum di atas akan dibuat di namespace default. Anda dapat memverifikasi ini dengan menjalankan perintah berikut:
```
kubectl get all -n default
```
## Langkah 2: Buat IngressClassParams
Buat `IngressClassParams` objek untuk menentukan opsi konfigurasi AWS tertentu untuk Application Load Balancer. Dalam contoh ini, kami membuat `IngressClassParams` sumber daya bernama `alb` (yang akan Anda gunakan pada langkah berikutnya) yang menentukan skema penyeimbang beban seperti `internet-facing` dalam file bernama. `alb-ingressclassparams.yaml`
```
apiVersion: eks.amazonaws.com/v1
kind: IngressClassParams
metadata:
name: alb
spec:
scheme: internet-facing
```
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f alb-ingressclassparams.yaml
```
## Langkah 3: Buat IngressClass
Buat `IngressClass` yang mereferensikan nilai konfigurasi AWS tertentu yang ditetapkan dalam `IngressClassParams` sumber daya dalam file bernama`alb-ingressclass.yaml`. Perhatikan nama`IngressClass`. Dalam contoh ini, keduanya `IngressClass` dan `IngressClassParams` diberi nama`alb`.
Gunakan `is-default-class` anotasi untuk mengontrol apakah `Ingress` sumber daya harus menggunakan kelas ini secara default.
```
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
name: alb
annotations:
# Use this annotation to set an IngressClass as Default
# If an Ingress doesn't specify a class, it will use the Default
ingressclass.kubernetes.io/is-default-class: "true"
spec:
# Configures the IngressClass to use EKS Auto Mode
controller: eks.amazonaws.com/alb
parameters:
apiGroup: eks.amazonaws.com
kind: IngressClassParams
# Use the name of the IngressClassParams set in the previous step
name: alb
```
Untuk informasi selengkapnya tentang opsi konfigurasi, lihat[IngressClassParams Referensi](#ingress-reference).
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f alb-ingressclass.yaml
```
## Langkah 4: Buat Ingress
Buat `Ingress` sumber daya dalam file bernama`alb-ingress.yaml`. Tujuan dari sumber daya ini adalah untuk mengaitkan path dan port pada Application Load Balancer dengan beban kerja di cluster Anda. Untuk contoh ini, kami membuat `Ingress` sumber daya bernama `2048-ingress` yang merutekan lalu lintas ke layanan bernama `service-2048` pada port 80.
Untuk informasi selengkapnya tentang mengonfigurasi resource ini, lihat [Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/) di Dokumentasi Kubernetes.
```
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: 2048-ingress
spec:
# this matches the name of IngressClass.
# this can be omitted if you have a default ingressClass in cluster: the one with ingressclass.kubernetes.io/is-default-class: "true" annotation
ingressClassName: alb
rules:
- http:
paths:
- path: /*
pathType: ImplementationSpecific
backend:
service:
name: service-2048
port:
number: 80
```
Terapkan konfigurasi ke cluster Anda:
```
kubectl apply -f alb-ingress.yaml
```
## Langkah 5: Periksa Status
Gunakan `kubectl` untuk menemukan status`Ingress`. Diperlukan beberapa menit agar penyeimbang beban tersedia.
Gunakan nama `Ingress` sumber daya yang Anda tetapkan pada langkah sebelumnya. Contoh:
```
kubectl get ingress 2048-ingress
```
Setelah sumber daya siap, ambil nama domain penyeimbang beban.
```
kubectl get ingress 2048-ingress -o jsonpath='{.status.loadBalancer.ingress[0].hostname}'
```
Untuk melihat layanan di browser web, tinjau port dan jalur yang ditentukan dalam `Ingress` penyelamatan.
## Langkah 6: Pembersihan
Untuk membersihkan penyeimbang beban, gunakan perintah berikut:
```
kubectl delete ingress 2048-ingress
kubectl delete ingressclass alb
kubectl delete ingressclassparams alb
```
Mode Otomatis EKS akan secara otomatis menghapus penyeimbang beban terkait di AWS akun Anda.
## IngressClassParams Referensi
Tabel di bawah ini adalah referensi cepat untuk opsi konfigurasi yang umum digunakan.
| Bidang | Deskripsi | Nilai contoh |
| --- | --- | --- |
| `scheme` | Mendefinisikan apakah ALB bersifat internal atau berhadapan dengan internet | `internet-facing` |
| `namespaceSelector` | Membatasi ruang nama mana yang dapat menggunakan ini IngressClass | `environment: prod` |
| `group.name` | Kelompokkan beberapa Ingress untuk berbagi satu ALB | `retail-apps` |
| `ipAddressType` | Menetapkan jenis alamat IP untuk ALB | `dualstack` |
| `subnets.ids` | Daftar subnet IDs untuk penyebaran ALB | `subnet-xxxx, subnet-yyyy` |
| `subnets.tags` | Tag filter untuk memilih subnet untuk ALB | `Environment: prod` |
| `certificateARNs` | ARNs Sertifikat SSL untuk digunakan | ` arn:aws: acm:region:account:certificate/id` |
| `tags` | Tag khusus untuk AWS sumber daya | `Environment: prod, Team: platform` |
| `loadBalancerAttributes` | Atribut khusus penyeimbang beban | `idle_timeout.timeout_seconds: 60` |
## Pertimbangan-pertimbangan
+ Anda tidak dapat menggunakan Anotasi pada IngressClass untuk mengonfigurasi penyeimbang beban dengan Mode Otomatis EKS. IngressClass konfigurasi harus dilakukan melalui IngressClassParams. Namun, Anda dapat menggunakan anotasi pada sumber daya Ingress individual untuk mengonfigurasi perilaku penyeimbang beban (seperti `alb.ingress.kubernetes.io/security-group-prefix-lists` atau). `alb.ingress.kubernetes.io/conditions.*`
+ Anda tidak dapat mengatur [ListenerAttribute](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/API_ListenerAttribute.html)dengan Mode Otomatis EKS.
+ Anda harus memperbarui Peran IAM Cluster untuk mengaktifkan propagasi tag dari Kubernetes ke sumber daya Load AWS Balancer. Untuk informasi selengkapnya, lihat [AWS Tag khusus untuk sumber daya EKS Auto](auto-learn-iam.md#tag-prop).
+ Untuk informasi tentang mengaitkan sumber daya dengan Mode Otomatis EKS atau Pengontrol Load AWS Balancer yang dikelola sendiri, lihat. [Referensi migrasi](migrate-auto.md#migration-reference)
+ Untuk informasi tentang memperbaiki masalah dengan penyeimbang beban, lihat. [Memecahkan Masalah Mode Otomatis EKS](auto-troubleshoot.md)
+ Untuk pertimbangan lebih lanjut tentang penggunaan kemampuan load balancing dari Mode Otomatis EKS, lihat. [Penyeimbangan beban](auto-networking.md#auto-lb-consider)
Tabel berikut memberikan perbandingan rinci perubahan, anotasi Ingress IngressClassParams, dan TargetGroupBinding konfigurasi untuk Mode Otomatis EKS. Tabel ini menyoroti perbedaan utama antara kemampuan penyeimbangan beban Mode Otomatis EKS dan pengontrol penyeimbang beban sumber terbuka, termasuk perubahan versi API, fitur yang tidak digunakan lagi, dan nama parameter yang diperbarui.
### IngressClassParams
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Perubahan versi API |
| `spec.certificateArn` | `spec.certificateARNs` | Support untuk beberapa sertifikat ARNs |
| `spec.subnets.tags` | `spec.subnets.matchTags` | Skema pencocokan subnet yang diubah |
| `spec.listeners.listenerAttributes` | Tidak didukung | Belum didukung oleh Mode Otomatis EKS |
### Anotasi masuk
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `kubernetes.io/ingress.class` | Tidak didukung | Gunakan `spec.ingressClassName` pada objek Ingress |
| `alb.ingress.kubernetes.io/group.name` | Tidak didukung | Tentukan grup IngressClass hanya |
| `alb.ingress.kubernetes.io/waf-acl-id` | Tidak didukung | Gunakan WAF v2 sebagai gantinya |
| `alb.ingress.kubernetes.io/web-acl-id` | Tidak didukung | Gunakan WAF v2 sebagai gantinya |
| `alb.ingress.kubernetes.io/shield-advanced-protection` | Tidak didukung | Integrasi Shield dinonaktifkan |
| `alb.ingress.kubernetes.io/auth-type: oidc` | Tidak didukung | Jenis Auth OIDC saat ini tidak didukung |
### TargetGroupBinding
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Perubahan versi API |
| `spec.targetType`opsional | `spec.targetType`diperlukan | Spesifikasi tipe target eksplisit |
| `spec.networking.ingress.from` | Tidak didukung | Tidak lagi mendukung NLB tanpa grup keamanan |
Untuk menggunakan TargetGroupBinding fitur kustom, Anda harus menandai grup target dengan eks-cluster-name tag eks: dengan nama cluster untuk memberikan pengontrol izin IAM yang diperlukan. Ketahuilah bahwa pengontrol akan menghapus grup target saat TargetGroupBinding sumber daya atau cluster dihapus.
# Gunakan Anotasi Layanan untuk mengonfigurasi Network Load Balancers
Pelajari cara mengonfigurasi Network Load Balancers (NLB) di Amazon EKS menggunakan anotasi layanan Kubernetes. Topik ini menjelaskan anotasi yang didukung oleh Mode Otomatis EKS untuk menyesuaikan perilaku NLB, termasuk aksesibilitas internet, pemeriksaan kesehatan, SSL/TLS penghentian, dan mode penargetan IP.
Ketika Anda membuat layanan Kubernetes dari tipe `LoadBalancer` dalam Mode Otomatis EKS, EKS secara otomatis menyediakan dan mengonfigurasi AWS Network Load Balancer berdasarkan anotasi yang Anda tentukan. Pendekatan deklaratif ini memungkinkan Anda untuk mengelola konfigurasi penyeimbang beban secara langsung melalui manifes Kubernetes Anda, mempertahankan infrastruktur sebagai praktik kode.
Mode Otomatis EKS menangani penyediaan Network Load Balancer secara default untuk semua jenis layanan LoadBalancer - tidak diperlukan instalasi atau konfigurasi pengontrol tambahan. `loadBalancerClass: eks.amazonaws.com/nlb`Spesifikasi secara otomatis ditetapkan sebagai default cluster, merampingkan proses penerapan sambil mempertahankan kompatibilitas dengan beban kerja Kubernetes yang ada.
**catatan**
Mode Otomatis EKS memerlukan tag subnet untuk mengidentifikasi subnet publik dan pribadi.
Jika Anda membuat cluster Anda dengan`eksctl`, Anda sudah memiliki tag ini.
Pelajari cara [Tag subnet untuk Mode Otomatis EKS](tag-subnets-auto.md).
## Layanan Sampel
Untuk informasi selengkapnya tentang `Service` sumber daya Kubernetes, lihat Dokumentasi Kubernetes[.](https://kubernetes.io/docs/concepts/services-networking/service/)
Tinjau `Service` sumber daya sampel di bawah ini:
```
apiVersion: v1
kind: Service
metadata:
name: echoserver
annotations:
# Specify the load balancer scheme as internet-facing to create a public-facing Network Load Balancer (NLB)
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
spec:
selector:
app: echoserver
ports:
- port: 80
targetPort: 8080
protocol: TCP
type: LoadBalancer
# Specify the new load balancer class for NLB as part of EKS Auto Mode feature
# For clusters with Auto Mode enabled, this field can be omitted as it's the default
loadBalancerClass: eks.amazonaws.com/nlb
```
## Anotasi yang umum digunakan
Tabel berikut mencantumkan anotasi yang umum digunakan yang didukung oleh Mode Otomatis EKS. Perhatikan bahwa Mode Otomatis EKS mungkin tidak mendukung semua anotasi.
**Tip**
Semua anotasi berikut harus diawali dengan `service.beta.kubernetes.io/`
| Bidang | Deskripsi | Contoh |
| --- | --- | --- |
| `aws-load-balancer-type` | Menentukan jenis penyeimbang beban. Gunakan `external` untuk penerapan baru. | `external` |
| `aws-load-balancer-nlb-target-type` | Menentukan apakah akan merutekan lalu lintas ke instance node atau langsung ke pod. IPs Gunakan `instance` untuk penerapan standar atau `ip` untuk routing pod langsung. | `instance` |
| `aws-load-balancer-scheme` | Mengontrol apakah penyeimbang beban internal atau menghadap ke internet. | `internet-facing` |
| `aws-load-balancer-healthcheck-protocol` | Protokol pemeriksaan kesehatan untuk kelompok sasaran. Opsi umum adalah `TCP` (default) atau`HTTP`. | `HTTP` |
| `aws-load-balancer-healthcheck-path` | Jalur HTTP untuk pemeriksaan kesehatan saat menggunakan HTTP/HTTPS protokol. | `/healthz` |
| `aws-load-balancer-healthcheck-port` | Pelabuhan yang digunakan untuk pemeriksaan kesehatan. Bisa berupa nomor port tertentu atau`traffic-port`. | `traffic-port` |
| `aws-load-balancer-subnets` | Menentukan subnet mana untuk membuat penyeimbang beban di. Dapat menggunakan subnet IDs atau nama. | `subnet-xxxx, subnet-yyyy` |
| `aws-load-balancer-ssl-cert` | ARN sertifikat SSL dari Certificate Manager untuk AWS HTTPS/TLS. | ` arn:aws: acm:region:account:certificate/cert-id` |
| `aws-load-balancer-ssl-ports` | Menentukan port mana yang harus menggunakan SSL/TLS. | `443, 8443` |
| `load-balancer-source-ranges` | Rentang CIDR diizinkan untuk mengakses penyeimbang beban. | `10.0.0.0/24, 192.168.1.0/24` |
| `aws-load-balancer-additional-resource-tags` | AWS Tag tambahan untuk diterapkan ke penyeimbang beban dan sumber daya terkait. | `Environment=prod,Team=platform` |
| `aws-load-balancer-ip-address-type` | Menentukan apakah penyeimbang beban menggunakan IPv4 atau dual-stack (\$1). IPv4 IPv6 | `ipv4` atau `dualstack` |
## Pertimbangan-pertimbangan
+ Anda harus memperbarui Peran IAM Cluster untuk mengaktifkan propagasi tag dari Kubernetes ke sumber daya Load AWS Balancer. Untuk informasi selengkapnya, lihat [AWS Tag khusus untuk sumber daya EKS Auto](auto-learn-iam.md#tag-prop).
+ Untuk informasi tentang mengaitkan sumber daya dengan Mode Otomatis EKS atau Pengontrol Load AWS Balancer yang dikelola sendiri, lihat. [Referensi migrasi](migrate-auto.md#migration-reference)
+ Untuk informasi tentang memperbaiki masalah dengan penyeimbang beban, lihat. [Memecahkan Masalah Mode Otomatis EKS](auto-troubleshoot.md)
+ Untuk pertimbangan lebih lanjut tentang penggunaan kemampuan load balancing dari Mode Otomatis EKS, lihat. [Penyeimbangan beban](auto-networking.md#auto-lb-consider)
Saat bermigrasi ke Mode Otomatis EKS untuk penyeimbangan beban, beberapa perubahan dalam anotasi layanan dan konfigurasi sumber daya diperlukan. Tabel berikut menguraikan perbedaan utama antara implementasi sebelumnya dan baru, termasuk opsi yang tidak didukung dan alternatif yang direkomendasikan.
### Anotasi layanan
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `service.beta.kubernetes.io/load-balancer-source-ranges` | Tidak didukung | Gunakan `spec.loadBalancerSourceRanges` pada Layanan |
| `service.beta.kubernetes.io/aws-load-balancer-type` | Tidak didukung | Gunakan `spec.loadBalancerClass` pada Layanan |
| `service.beta.kubernetes.io/aws-load-balancer-internal` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-scheme` |
| `service.beta.kubernetes.io/aws-load-balancer-proxy-protocol` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-target-group-attributes` sebagai gantinya |
| Berbagai atribut penyeimbang beban | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-enabled` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-name` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
| `service.beta.kubernetes.io/aws-load-balancer-access-log-s3-bucket-prefix` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
| `service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled` | Tidak didukung | Gunakan `service.beta.kubernetes.io/aws-load-balancer-attributes` sebagai gantinya |
Untuk bermigrasi dari anotasi atribut load balancer yang tidak digunakan lagi, konsolidasikan setelan ini ke dalam anotasi. `service.beta.kubernetes.io/aws-load-balancer-attributes` Anotasi ini menerima daftar pasangan kunci-nilai yang dipisahkan koma untuk berbagai atribut penyeimbang beban. Misalnya, untuk menentukan pencatatan akses, dan penyeimbangan beban lintas zona, gunakan format berikut:
```
service.beta.kubernetes.io/aws-load-balancer-attributes: access_logs.s3.enabled=true,access_logs.s3.bucket=my-bucket,access_logs.s3.prefix=my-prefix,load_balancing.cross_zone.enabled=true
```
Format konsolidasi ini menyediakan cara yang lebih konsisten dan fleksibel untuk mengonfigurasi atribut penyeimbang beban sekaligus mengurangi jumlah anotasi individual yang diperlukan. Tinjau konfigurasi Layanan yang ada dan perbarui untuk menggunakan format gabungan ini.
### TargetGroupBinding
| Sebelumnya | Baru | Deskripsi |
| --- | --- | --- |
| `elbv2.k8s.aws/v1beta1` | `eks.amazonaws.com/v1` | Perubahan versi API |
| `spec.targetType`opsional | `spec.targetType`diperlukan | Spesifikasi tipe target eksplisit |
| `spec.networking.ingress.from` | Tidak didukung | Tidak lagi mendukung NLB tanpa grup keamanan |
Catatan: Untuk menggunakan TargetGroupBinding fitur kustom, Anda harus menandai grup target dengan `eks:eks-cluster-name` tag dengan nama cluster untuk memberikan pengontrol izin IAM yang diperlukan. Ketahuilah bahwa pengontrol akan menghapus grup target saat TargetGroupBinding sumber daya atau cluster dihapus.
# Buat kelas penyimpanan
A `StorageClass` di Amazon EKS Auto Mode mendefinisikan bagaimana volume Amazon EBS secara otomatis disediakan ketika aplikasi meminta penyimpanan persisten. Halaman ini menjelaskan cara membuat dan mengonfigurasi `StorageClass` yang berfungsi dengan Mode Otomatis Amazon EKS untuk menyediakan volume EBS.
Dengan mengonfigurasi a`StorageClass`, Anda dapat menentukan pengaturan default untuk volume EBS Anda termasuk jenis volume, enkripsi, IOPS, dan parameter penyimpanan lainnya. Anda juga dapat mengkonfigurasi `StorageClass` untuk menggunakan kunci AWS KMS untuk manajemen enkripsi.
Mode Otomatis EKS tidak membuat `StorageClass` untuk Anda. Anda harus membuat `StorageClass` referensi `ebs.csi.eks.amazonaws.com` untuk menggunakan kemampuan penyimpanan Mode Otomatis EKS.
Pertama, buat file bernama`storage-class.yaml`:
```
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: auto-ebs-sc
annotations:
storageclass.kubernetes.io/is-default-class: "true"
allowedTopologies:
- matchLabelExpressions:
- key: eks.amazonaws.com/compute-type
values:
- auto
provisioner: ebs.csi.eks.amazonaws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
type: gp3
encrypted: "true"
```
Kedua, terapkan kelas penyimpanan ke cluster Anda.
```
kubectl apply -f storage-class.yaml
```
**Komponen kunci:**
+ `provisioner: ebs.csi.eks.amazonaws.com`- Menggunakan Mode Otomatis EKS
+ `allowedTopologies`- Menentukan `matchLabelExpressions` untuk mencocokkan `eks.amazonaws.com/compute-type:auto` akan memastikan bahwa jika pod Anda membutuhkan volume untuk secara otomatis disediakan menggunakan Mode Otomatis maka pod tidak akan dijadwalkan pada node non-Otomatis.
+ `volumeBindingMode: WaitForFirstConsumer`- Menunda pembuatan volume hingga pod membutuhkannya
+ `type: gp3`- Menentukan jenis volume EBS
+ `encrypted: "true"`- EBS akan mengenkripsi volume apa pun yang dibuat menggunakan file. `StorageClass` EBS akan menggunakan alias `aws/ebs` kunci default. Untuk informasi selengkapnya, lihat [Cara kerja enkripsi Amazon EBS](https://docs.aws.amazon.com/ebs/latest/userguide/how-ebs-encryption-works.html) di Panduan Pengguna Amazon EBS. Nilai ini opsional tetapi disarankan.
+ `storageclass.kubernetes.io/is-default-class: "true"`- Kubernetes akan menggunakan kelas penyimpanan ini secara default, kecuali jika Anda menentukan kelas volume yang berbeda pada klaim volume persisten. Nilai ini bersifat opsional. Berhati-hatilah saat menyetel nilai ini jika Anda bermigrasi dari pengontrol penyimpanan yang berbeda.
## Gunakan kunci KMS yang dikelola sendiri untuk mengenkripsi volume EBS
Untuk menggunakan kunci KMS yang dikelola sendiri untuk mengenkripsi volume EBS yang diotomatisasi oleh Mode Otomatis EKS, Anda perlu:
1. Buat kunci KMS yang dikelola sendiri.
+ Untuk informasi selengkapnya, lihat [Membuat kunci KMS enkripsi simetris atau Cara](https://docs.aws.amazon.com/kms/latest/developerguide/create-symmetric-cmk.html) [Amazon Elastic Block Store (Amazon EBS) menggunakan](https://docs.aws.amazon.com/kms/latest/developerguide/services-ebs.html) KMS di Panduan Pengguna KMS.
1. Buat kebijakan baru yang mengizinkan akses ke kunci KMS.
+ Gunakan contoh kebijakan IAM di bawah ini untuk membuat kebijakan. Masukkan ARN dari kunci KMS yang dikelola sendiri yang baru. Untuk informasi selengkapnya, lihat [Membuat peran dan melampirkan kebijakan (konsol)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions_create-policies.html) di Panduan Pengguna AWS IAM.
1. Lampirkan kebijakan ke Peran Kluster EKS.
+ Gunakan AWS konsol untuk menemukan ARN dari EKS Cluster Role. Informasi peran terlihat di bagian **Ikhtisar**. Untuk informasi selengkapnya, lihat [IAM role klaster Amazon EKS](cluster-iam-role.md).
1. Perbarui `StorageClass` untuk mereferensikan ID Kunci KMS di `parameters.kmsKeyId` lapangan.
### Contoh Kebijakan IAM KMS yang dikelola sendiri
Perbarui nilai-nilai berikut dalam kebijakan di bawah ini:
+ ``ID AWS akun Anda, seperti `111122223333`
+ ``— AWS Wilayah cluster Anda, seperti `us-west-2`
```
{
"Version":"2012-10-17",
"Id": "key-auto-policy-3",
"Statement": [
{
"Sid": "Enable IAM User Permissions",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::123456789012:root"
},
"Action": "kms:*",
"Resource": "*"
},
{
"Sid": "Allow access through EBS for all principals in the account that are authorized to use EBS",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"kms:CallerAccount": "123456789012",
"kms:ViaService": "ec2.us-east-1.amazonaws.com"
}
}
}
]
}
```
### Contoh KMS yang dikelola sendiri `StorageClass`
```
parameters:
type: gp3
encrypted: "true"
kmsKeyId:
```
## `StorageClass`Parameter Referensi
Untuk informasi umum tentang `StorageClass` sumber daya Kubernetes, lihat [Kelas Penyimpanan](https://kubernetes.io/docs/concepts/storage/storage-classes/) di Dokumentasi Kubernetes.
THe `parameters`bagian dari `StorageClass` sumber daya khusus untuk AWS. Gunakan tabel berikut untuk meninjau opsi yang tersedia.
| Parameter | Nilai | Default | Deskripsi |
| --- | --- | --- | --- |
| “csi.storage.k8s.io/fstype” | xfs, ext2, ext3, ext4 | ext4 | Jenis sistem file yang akan diformat selama pembuatan volume. Parameter ini peka huruf besar/kecil\$1 |
| “ketik” | io1, io2, gp2, gp3, sc1, st1, standar, sbp1, sbg1 | gp3 | Jenis volume EBS. |
| “iOpsPerGB” | | | Operasi I/O per detik per GiB. Dapat ditentukan untuk IO1, IO2, dan GP3 volume. |
| “AllowAuto IOPSPerGBIncrease” | benar, salah | false | Ketika`"true"`, driver CSI meningkatkan IOPS untuk volume ketika `iopsPerGB * ` terlalu rendah untuk masuk ke dalam rentang IOPS yang didukung oleh. AWS Hal ini memungkinkan penyediaan dinamis untuk selalu berhasil, bahkan ketika pengguna menentukan kapasitas atau nilai PVC yang terlalu kecil. `iopsPerGB` Di sisi lain, ini mungkin menimbulkan biaya tambahan, karena volume tersebut memiliki IOPS yang lebih tinggi daripada yang diminta. `iopsPerGB` |
| “iops” | | | Operasi I/O per detik. Dapat ditentukan untuk IO1, IO2, dan GP3 volume. |
| “throughput” | | 125 | Throughput dalam MIB/s. Hanya efektif ketika tipe volume gp3 ditentukan. |
| “dienkripsi” | benar, salah | false | Apakah volume harus dienkripsi atau tidak. Nilai yang valid adalah “benar” atau “salah”. |
| “BlockExpress” | benar, salah | false | Memungkinkan pembuatan volume Blok Ekspres io2. |
| "kmsKeyId" | | | ARN penuh dari kunci untuk digunakan saat mengenkripsi volume. Jika tidak ditentukan, AWS akan menggunakan kunci KMS default untuk wilayah volume berada. Ini akan menjadi kunci yang dibuat secara otomatis yang disebut `/aws/ebs` jika tidak diubah. |
| “BlockSize” | | | Ukuran blok yang akan digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,, `ext3``ext4`, atau. `xfs` |
| “InodeSize” | | | Ukuran inode yang digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,, `ext3``ext4`, atau. `xfs` |
| "bytesPerInode" | | | Yang `bytes-per-inode` digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,,`ext3`. `ext4` |
| "numberOfInodes" | | | Yang `number-of-inodes` digunakan saat memformat sistem file yang mendasarinya. Hanya didukung pada node linux dan dengan fstype`ext2`,,`ext3`. `ext4` |
| “BigAllocext4" | benar, salah | false | Mengubah sistem `ext4` file untuk menggunakan alokasi blok berkerumun dengan mengaktifkan opsi pemformatan. `bigalloc` Peringatan: `bigalloc` mungkin tidak sepenuhnya didukung dengan kernel Linux node Anda. |
| “ClusterSizeext4" | | | Ukuran cluster yang akan digunakan saat memformat sistem `ext4` file saat fitur diaktifkan. `bigalloc` Catatan: `ext4BigAlloc` Parameter harus diatur ke true. |
Untuk informasi selengkapnya, lihat [Driver AWS EBS CSI](https://github.com/kubernetes-sigs/aws-ebs-csi-driver/blob/master/docs/parameters.md) di. GitHub
## Pertimbangan-pertimbangan
**catatan**
Anda hanya dapat menerapkan beban kerja tergantung pada Mode Otomatis EKS StorageClasses pada node Mode Otomatis EKS. Jika Anda memiliki cluster dengan tipe node campuran, Anda perlu mengonfigurasi beban kerja Anda agar berjalan hanya pada node Mode Otomatis EKS. Untuk informasi selengkapnya, lihat [Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS](associate-workload.md).
Kemampuan penyimpanan blok EKS Auto Mode berbeda dari EBS CSI Driver.
+ Penyediaan Statis
+ Jika Anda ingin menggunakan volume EBS yang dibuat secara eksternal dengan Mode Otomatis EKS, Anda perlu menambahkan AWS tag secara manual dengan kunci `eks:eks-cluster-name` dan nilai nama cluster.
+ Noda Startup Node
+ Anda tidak dapat menggunakan fitur taint startup node untuk mencegah penjadwalan pod sebelum kesiapan kemampuan penyimpanan
+ Tag Kustom pada Volume yang Disediakan Secara Dinamis
+ Anda tidak dapat menggunakan flag CLI tag ekstra untuk mengonfigurasi tag khusus pada volume EBS yang disediakan secara dinamis
+ Anda dapat menggunakan `StorageClass` penandaan untuk menambahkan tag khusus. Mode Otomatis EKS akan menambahkan tag ke AWS sumber daya terkait. Anda perlu memperbarui Peran IAM Cluster untuk tag khusus. Untuk informasi selengkapnya, lihat [AWS Tag khusus untuk sumber daya EKS Auto](auto-learn-iam.md#tag-prop).
+ Metrik Kinerja Terperinci EBS
+ Anda tidak dapat mengakses metrik Prometheus untuk performa rinci EBS
## Instal add-on CSI Snapshot Controller
Mode Otomatis EKS kompatibel dengan add-on CSI Snapshot Controller Amazon EKS.
AWS menyarankan Anda mengonfigurasi add-on ini untuk berjalan di kumpulan `system` node bawaan.
Untuk informasi lebih lanjut, lihat:
+ [Jalankan add-on penting pada instance khusus](critical-workload.md)
+ [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md)
+ [Aktifkan fungsionalitas snapshot untuk volume CSI](csi-snapshot-controller.md)
### Untuk menginstal pengontrol snapshot di kumpulan node sistem
1. Buka kluster EKS Anda di AWS konsol
1. Dari tab **Add-ons**, pilih **Dapatkan lebih banyak** add-on
1. **Pilih **CSI Snapshot Controller** dan kemudian Berikutnya**
1. Pada halaman **Konfigurasi pengaturan add-on yang dipilih, pilih Pengaturan** **konfigurasi opsional** untuk melihat skema konfigurasi **Add-on**
1. Masukkan yaml berikut untuk mengaitkan pengontrol snapshot dengan kumpulan `system` node. Pengontrol snapshot mencakup toleransi terhadap noda. `CriticalAddonsOnly`
```
{
"nodeSelector": {
"karpenter.sh/nodepool": "system"
}
}
```
1. Pilih **Berikutnya**
1. **Tinjau konfigurasi add-on dan kemudian pilih Buat**
# Nonaktifkan Mode Otomatis EKS
Anda dapat menonaktifkan Mode Otomatis EKS pada Kluster EKS yang ada. Ini adalah operasi yang merusak.
+ EKS akan menghentikan semua EC2 instans yang dioperasikan oleh Mode Otomatis EKS.
+ EKS akan menghapus semua Load Balancer yang dioperasikan oleh EKS Auto Mode.
+ EKS **tidak** akan menghapus volume EBS yang disediakan oleh Mode Otomatis EKS.
Mode Otomatis EKS dirancang untuk sepenuhnya mengelola sumber daya yang dibuatnya. Intervensi manual dapat mengakibatkan Mode Otomatis EKS gagal membersihkan sumber daya tersebut sepenuhnya saat dinonaktifkan. Misalnya, jika Anda merujuk ke Grup Keamanan terkelola dari aturan Grup Keamanan eksternal, dan lupa untuk menghapus referensi tersebut sebelum Anda menonaktifkan Mode Otomatis EKS untuk klaster, Grup Keamanan terkelola akan bocor (tidak dihapus). Langkah-langkah di bawah ini menjelaskan cara menghapus Grup Keamanan yang bocor jika itu terjadi.
## Nonaktifkan Mode Otomatis EKS (AWS Konsol)
1. Buka halaman ikhtisar cluster Anda di Konsol Manajemen AWS.
1. Di bawah **Mode Otomatis EKS** pilih **Kelola**
1. Alihkan **Mode Otomatis EKS** ke. `off`
Jika ada Grup Keamanan terkelola yang tidak dihapus pada akhir proses ini, Anda dapat menghapusnya secara manual menggunakan deskripsi dari [Hapus grup keamanan](https://docs.aws.amazon.com/vpc/latest/userguide/deleting-security-groups.html).
## Nonaktifkan Mode Otomatis EKS (AWS CLI)
Gunakan perintah berikut untuk menonaktifkan Mode Otomatis EKS pada cluster yang ada.
Anda harus menginstal `aws` CLI, dan masuk dengan izin yang cukup untuk mengelola kluster EKS. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
**catatan**
Kemampuan komputasi, penyimpanan blok, dan penyeimbangan beban semuanya harus diaktifkan atau dinonaktifkan dalam permintaan yang sama.
```
aws eks update-cluster-config \
--name $CLUSTER_NAME \
--compute-config enabled=false \
--kubernetes-network-config '{"elasticLoadBalancing":{"enabled": false}}' \
--storage-config '{"blockStorage":{"enabled": false}}'
```
Anda dapat memeriksa apakah Grup Keamanan Mode Otomatis EKS yang bocor gagal dihapus setelah menonaktifkan Mode Otomatis EKS sebagai berikut:
```
aws ec2 describe-security-groups \
--filters Name=tag:eks:eks-cluster-name,Values= Name=tag-key,Values=ingress.eks.amazonaws.com/resource,service.eks.amazonaws.com/resource --query "SecurityGroups[*].[GroupName]"
```
Untuk kemudian menghapus Grup Keamanan:
```
aws ec2 delete-security-group --group-name=
```
# Memperbarui versi Kubernetes dari kluster Mode Otomatis EKS
Topik ini menjelaskan cara memperbarui versi Kubernetes dari kluster Mode Otomatis Anda. Mode Otomatis menyederhanakan proses pembaruan versi dengan menangani koordinasi pembaruan bidang kontrol dengan penggantian node, sambil mempertahankan ketersediaan beban kerja melalui anggaran gangguan pod.
Saat memutakhirkan kluster Mode Otomatis, banyak komponen yang secara tradisional memerlukan pembaruan manual sekarang dikelola sebagai bagian dari layanan. Memahami aspek otomatis dari proses peningkatan dan tanggung jawab Anda membantu memastikan transisi versi yang lancar untuk klaster Anda.
## Pelajari tentang pembaruan dengan Mode Otomatis EKS
Setelah Anda memulai upgrade control plane, EKS Auto Mode akan meng-upgrade node di cluster Anda. Saat node kedaluwarsa, Mode Otomatis EKS akan menggantinya dengan node baru. Node baru memiliki versi Kubernetes baru yang sesuai. Mode Otomatis EKS mengamati anggaran gangguan pod saat memutakhirkan node.
Selain itu, Anda tidak perlu lagi memperbarui komponen seperti:
+ Amazon VPC CNI
+ AWS Pengontrol Load Balancer
+ CoreDNS
+ `kube-proxy`
+ Karpenter
+ AWS Pengemudi EBS CSI
Mode Otomatis EKS menggantikan komponen ini dengan fungsionalitas layanan.
Anda masih bertanggung jawab untuk memperbarui:
+ Aplikasi dan beban kerja yang diterapkan ke kluster Anda
+ Pengaya dan pengontrol yang dikelola sendiri
+ Pengaya Amazon EKS
+ Pelajari cara [Perbarui add-on Amazon EKS](updating-an-add-on.md)
Pelajari [Praktik Terbaik untuk Upgrade Cluster](https://docs.aws.amazon.com/eks/latest/best-practices/cluster-upgrades.html)
## Mulai Pembaruan Cluster
Untuk memulai pembaruan cluster, lihat[Perbarui klaster yang ada ke versi Kubernetes baru](update-cluster.md).
# Aktifkan atau Nonaktifkan Built-in NodePools
Mode Otomatis EKS memiliki dua built-in NodePools. Anda dapat mengaktifkan atau menonaktifkannya NodePools menggunakan AWS konsol, CLI, atau API.
## NodePool Referensi bawaan
+ `system`
+ Ini NodePool memiliki `CriticalAddonsOnly` noda. Banyak add-on EKS, seperti CoreDNS, mentolerir noda ini. Gunakan kumpulan node sistem ini untuk memisahkan aplikasi kluster-kritis.
+ Mendukung keduanya `amd64` dan `arm64` arsitektur.
+ `general-purpose`
+ Ini NodePool memberikan dukungan untuk meluncurkan node untuk beban kerja tujuan umum di klaster Anda.
+ Hanya menggunakan `amd64` arsitektur.
Keduanya built-in NodePools:
+ Gunakan EKS default NodeClass
+ Gunakan hanya kapasitas sesuai permintaan EC2
+ Gunakan keluarga EC2 instance C, M, dan R
+ Memerlukan generasi 5 atau instance yang lebih baru EC2
**catatan**
Mengaktifkan setidaknya satu built-in NodePool diperlukan untuk EKS untuk menyediakan “default”. NodeClass Jika Anda menonaktifkan semua bawaan NodePools, Anda harus membuat kustom NodeClass dan mengonfigurasi a NodePool untuk menggunakannya. Untuk informasi lebih lanjut tentang NodeClasses, lihat[Buat Kelas Node untuk Amazon EKS](create-node-class.md).
## Prosedur
### Prasyarat
+ Versi terbaru dari AWS Command Line Interface (AWS CLI) diinstal dan dikonfigurasi pada perangkat Anda. Untuk memeriksa versi Anda saat ini, gunakan`aws --version`. Untuk menginstal versi terbaru, lihat [Menginstal](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html) dan [Konfigurasi cepat](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html#cli-configure-quickstart-config) dengan aws configure di Panduan Pengguna Antarmuka Baris AWS Perintah.
+ Masuk ke CLI dengan izin IAM yang cukup untuk membuat AWS sumber daya termasuk Kebijakan IAM, Peran IAM, dan Kluster EKS.
### Aktifkan dengan AWS CLI
Gunakan perintah berikut untuk mengaktifkan keduanya bawaan NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"nodeRoleArn": "",
"nodePools": ["general-purpose", "system"],
"enabled": true
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}
}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
Anda dapat memodifikasi perintah untuk mengaktifkan secara selektif. NodePools
### Nonaktifkan dengan AWS CLI
Gunakan perintah berikut untuk menonaktifkan keduanya bawaan NodePools:
```
aws eks update-cluster-config \
--name \
--compute-config '{
"enabled": true,
"nodePools": []
}' \
--kubernetes-network-config '{
"elasticLoadBalancing":{"enabled": true}}' \
--storage-config '{
"blockStorage":{"enabled": true}
}'
```
# Kontrol jika beban kerja diterapkan pada node Mode Otomatis EKS
Saat menjalankan beban kerja di klaster EKS dengan Mode Otomatis EKS, Anda mungkin perlu mengontrol apakah beban kerja tertentu berjalan pada node Mode Otomatis EKS atau jenis komputasi lainnya. Topik ini menjelaskan cara menggunakan pemilih node dan aturan afinitas untuk memastikan beban kerja Anda dijadwalkan pada infrastruktur komputasi yang dimaksud.
Contoh dalam topik ini menunjukkan cara menggunakan `eks.amazonaws.com/compute-type` label untuk meminta atau mencegah penyebaran beban kerja pada node Mode Otomatis EKS. Ini sangat berguna dalam cluster mode campuran tempat Anda menjalankan Mode Otomatis EKS dan jenis komputasi lainnya, seperti penyedia Karpenter yang dikelola sendiri atau Grup Node Terkelola EKS.
Node Mode Otomatis EKS telah menetapkan nilai label `eks.amazonaws.com/compute-type` ke`auto`. Anda dapat menggunakan label ini untuk mengontrol jika beban kerja diterapkan ke node yang dikelola oleh Mode Otomatis EKS.
## Memerlukan beban kerja diterapkan ke node Mode Otomatis EKS
**catatan**
`nodeSelector`Nilai ini tidak diperlukan untuk Mode Otomatis EKS. `nodeSelector`Nilai ini hanya relevan jika Anda menjalankan cluster dalam mode campuran, tipe node tidak dikelola oleh Mode Otomatis EKS. Misalnya, Anda mungkin memiliki kapasitas komputasi statis yang diterapkan ke klaster Anda dengan Grup Node Terkelola EKS, dan memiliki kapasitas komputasi dinamis yang dikelola oleh Mode Otomatis EKS.
Anda dapat menambahkan ini `nodeSelector` ke Deployment atau beban kerja lainnya agar Kubernetes menjadwalkannya ke node Mode Otomatis EKS.
```
apiVersion: apps/v1
kind: Deployment
spec:
template:
nodeSelector:
eks.amazonaws.com/compute-type: auto
```
## Memerlukan beban kerja tidak diterapkan ke node Mode Otomatis EKS
Anda dapat menambahkan ini `nodeAffinity` ke Deployment atau beban kerja lainnya agar Kubernetes **tidak** menjadwalkannya ke node Mode Otomatis EKS.
```
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: eks.amazonaws.com/compute-type
operator: NotIn
values:
- auto
```
# Jalankan add-on penting pada instance khusus
Dalam topik ini, Anda akan belajar bagaimana menerapkan beban kerja dengan `CriticalAddonsOnly` toleransi sehingga Mode Otomatis EKS akan menjadwalkannya ke kumpulan node. `system`
Kumpulan `system` node bawaan EKS Auto Mode dirancang untuk menjalankan add-on penting pada instance khusus. Pemisahan ini memastikan komponen penting memiliki sumber daya khusus dan terisolasi dari beban kerja umum, meningkatkan stabilitas dan kinerja klaster secara keseluruhan.
Panduan ini menunjukkan cara menerapkan add-on ke kumpulan `system` node dengan memanfaatkan `CriticalAddonsOnly` toleransi dan pemilih node yang sesuai. Dengan mengikuti langkah-langkah ini, Anda dapat memastikan bahwa aplikasi penting Anda dijadwalkan ke `system` node khusus, memanfaatkan manfaat isolasi dan alokasi sumber daya yang disediakan oleh struktur kumpulan node khusus EKS Auto Mode.
Mode Otomatis EKS memiliki dua kumpulan node bawaan: `general-purpose` dan`system`. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
Tujuan dari kumpulan `system` node adalah untuk memisahkan add-on kritis ke node yang berbeda. Node yang disediakan oleh kumpulan `system` node memiliki taint `CriticalAddonsOnly` Kubernetes. Kubernetes hanya akan menjadwalkan pod ke node ini jika mereka memiliki toleransi yang sesuai. Untuk informasi selengkapnya, lihat [Taints and Tolerations dalam dokumentasi](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) Kubernetes.
## Prasyarat
+ EKS Auto Mode Cluster dengan kumpulan `system` node bawaan diaktifkan. Untuk informasi selengkapnya, silakan lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md)
+ `kubectl`diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
## Prosedur
Tinjau contoh yaml di bawah ini. Perhatikan konfigurasi berikut:
+ `nodeSelector`— Ini mengaitkan beban kerja dengan kumpulan `system` node bawaan. Kumpulan node ini harus diaktifkan dengan AWS API. Untuk informasi selengkapnya, lihat [Aktifkan atau Nonaktifkan Built-in NodePools](set-builtin-node-pools.md).
+ `tolerations`— Toleransi ini mengatasi `CriticalAddonsOnly` noda pada node di kumpulan node. `system`
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: sample-app
spec:
replicas: 3
selector:
matchLabels:
app: sample-app
template:
metadata:
labels:
app: sample-app
spec:
nodeSelector:
karpenter.sh/nodepool: system
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
containers:
- name: app
image: nginx:latest
resources:
requests:
cpu: "500m"
memory: "512Mi"
```
Untuk memperbarui beban kerja agar berjalan di kumpulan `system` node, Anda perlu:
1. Perbarui beban kerja yang ada untuk menambahkan konfigurasi berikut yang dijelaskan di atas:
+ `nodeSelector`
+ `tolerations`
1. Terapkan beban kerja yang diperbarui ke cluster Anda dengan `kubectl apply`
Setelah memperbarui beban kerja, itu akan berjalan pada node khusus.
# Gunakan Kebijakan Jaringan dengan Mode Otomatis EKS
## Ikhtisar
Ketika pelanggan menskalakan lingkungan aplikasi mereka menggunakan EKS, isolasi lalu lintas jaringan menjadi semakin mendasar untuk mencegah akses tidak sah ke sumber daya di dalam dan di luar cluster. Ini sangat penting dalam lingkungan multi-penyewa dengan beberapa beban kerja yang tidak terkait berjalan berdampingan di cluster. Kebijakan jaringan Kubernetes memungkinkan Anda untuk meningkatkan postur keamanan jaringan untuk beban kerja Kubernetes Anda, dan integrasinya dengan endpoint cluster-eksternal. Mode Otomatis EKS mendukung berbagai jenis kebijakan jaringan.
### Isolasi lapisan 3 dan 4
Kebijakan jaringan Kubernetes standar beroperasi pada lapisan 3 dan 4 dari model jaringan OSI dan memungkinkan Anda untuk mengontrol arus lalu lintas di alamat IP atau tingkat port dalam cluster Amazon EKS Anda.
#### Kasus penggunaan
+ Segmentasikan lalu lintas jaringan antar beban kerja untuk memastikan bahwa hanya aplikasi terkait yang dapat berbicara satu sama lain.
+ Mengisolasi penyewa di tingkat namespace menggunakan kebijakan untuk menegakkan pemisahan jaringan.
### Penegakan berbasis DNS
Pelanggan biasanya menyebarkan beban kerja di EKS yang merupakan bagian dari lingkungan terdistribusi yang lebih luas, beberapa di antaranya harus berkomunikasi dengan sistem dan layanan di luar cluster (lalu lintas utara). Sistem dan layanan ini dapat berada di AWS cloud atau di luar AWS sama sekali. Kebijakan berbasis Domain Name System (DNS) memungkinkan Anda untuk memperkuat postur keamanan Anda dengan mengadopsi pendekatan yang lebih stabil dan dapat diprediksi untuk mencegah akses tidak sah dari Pod ke sumber daya eksternal cluster atau endpoint. Mekanisme ini menghilangkan kebutuhan untuk melacak dan mengizinkan daftar alamat IP tertentu secara manual. Dengan mengamankan sumber daya dengan pendekatan berbasis DNS, Anda juga memiliki lebih banyak fleksibilitas untuk memperbarui infrastruktur eksternal tanpa harus melonggarkan postur keamanan Anda atau memodifikasi kebijakan jaringan di tengah perubahan pada server dan host hulu. Anda dapat memfilter lalu lintas keluar ke titik akhir eksternal menggunakan Nama Domain Berkualitas Penuh (FQDN), atau pola yang cocok untuk nama domain DNS. Ini memberi Anda fleksibilitas tambahan untuk memperluas akses ke beberapa subdomain yang terkait dengan titik akhir cluster-eksternal tertentu.
#### Kasus penggunaan
+ Standarisasi pada pendekatan berbasis DNS untuk memfilter akses dari lingkungan Kubernetes ke endpoint cluster-eksternal.
+ Akses aman ke AWS layanan di lingkungan multi-penyewa.
+ Kelola akses jaringan dari pod ke beban kerja on-prem di lingkungan cloud Hybrid Anda.
### Aturan admin (atau cakupan cluster)
Dalam beberapa kasus, seperti skenario multi-tenant, pelanggan mungkin memiliki persyaratan untuk menegakkan standar keamanan jaringan yang berlaku untuk seluruh cluster. Alih-alih mendefinisikan dan mempertahankan kebijakan yang berbeda secara berulang untuk setiap namespace, Anda dapat menggunakan satu kebijakan untuk mengelola kontrol akses jaringan secara terpusat untuk beban kerja yang berbeda di klaster, terlepas dari namespace mereka. Jenis kebijakan ini memungkinkan Anda memperluas cakupan penegakan aturan pemfilteran jaringan yang diterapkan pada lapisan 3, lapisan 4, dan saat menggunakan aturan DNS.
#### Kasus penggunaan
+ Kelola kontrol akses jaringan secara terpusat untuk semua (atau sebagian dari) beban kerja di kluster EKS Anda.
+ Tentukan postur keamanan jaringan default di seluruh cluster.
+ Memperluas standar keamanan organisasi ke ruang lingkup cluster dengan cara yang lebih efisien secara operasional.
## Memulai
### Prasyarat
+ Cluster Amazon EKS dengan Mode Otomatis EKS diaktifkan
+ kubectl dikonfigurasi untuk terhubung ke klaster Anda
### Langkah 1: Aktifkan Pengontrol Kebijakan Jaringan
Untuk menggunakan kebijakan jaringan dengan Mode Otomatis EKS, pertama-tama Anda harus mengaktifkan Network Policy Controller dengan menerapkan a ConfigMap ke cluster Anda.
1. Buat file bernama `enable-network-policy.yaml` dengan konten berikut:
```
apiVersion: v1
kind: ConfigMap
metadata:
name: amazon-vpc-cni
namespace: kube-system
data:
enable-network-policy-controller: "true"
```
1. Terapkan ConfigMap ke cluster Anda:
```
kubectl apply -f enable-network-policy.yaml
```
### Langkah 2: Buat dan uji kebijakan jaringan
Kluster Mode Otomatis EKS Anda sekarang dikonfigurasi untuk mendukung kebijakan jaringan Kubernetes. Anda dapat menguji ini dengan[Bintang demo kebijakan jaringan untuk Amazon EKS](network-policy-stars-demo.md).
### Langkah 3: Sesuaikan konfigurasi Agen Kebijakan Jaringan di Kelas Node (Opsional)
Anda dapat membuat Kelas Node baru secara opsional untuk mengubah perilaku default Agen Kebijakan Jaringan pada node atau mengaktifkan pencatatan peristiwa Kebijakan Jaringan. Untuk melakukannya, ikuti langkah-langkah berikut:
1. Membuat atau mengedit file YAMM Kelas Node (misalnya,`nodeclass-network-policy.yaml`) dengan konten berikut:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: network-policy-config
spec:
# Optional: Changes default network policy behavior
networkPolicy: DefaultAllow
# Optional: Enables logging for network policy events
networkPolicyEventLogs: Enabled
# Include other Node Class configurations as needed
```
1. Terapkan konfigurasi Node Class ke cluster Anda:
```
kubectl apply -f nodeclass-network-policy.yaml
```
1. Verifikasi bahwa Kelas Node telah dibuat:
```
kubectl get nodeclass network-policy-config
```
1. Perbarui Node Pool Anda untuk menggunakan Kelas Node ini. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Bagaimana cara kerjanya?
### Kebijakan jaringan berbasis DNS
![\[Ilustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/apply-dns-policy-1.png)
![\[llustrasi alur kerja saat kebijakan berbasis DNS diterapkan di EKS Auto\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/apply-dns-policy-2.png)
1. Tim platform menerapkan kebijakan berbasis DNS ke cluster EKS.
1. Network Policy Controller bertanggung jawab untuk memantau pembuatan kebijakan dalam klaster dan kemudian merekonsiliasi titik akhir kebijakan. Dalam kasus penggunaan ini, pengontrol kebijakan jaringan menginstruksikan agen node untuk memfilter permintaan DNS berdasarkan domain yang terdaftar izinkan dalam kebijakan yang dibuat. Nama domain diijinkan menggunakan FQDN atau nama domain yang cocok dengan pola yang ditentukan dalam konfigurasi sumber daya Kubernetes.
1. Workload Sebuah upaya untuk menyelesaikan IP untuk titik akhir cluster-eksternal. Permintaan DNS pertama kali melalui proxy yang memfilter permintaan tersebut berdasarkan daftar izinkan yang diterapkan melalui kebijakan jaringan.
1. Setelah permintaan DNS melewati daftar izinkan filter DNS, itu diproksi ke CoreDNS,
1. CoreDNS pada gilirannya mengirimkan permintaan ke Resolver DNS Eksternal (Amazon Route 53 Resolver) untuk mendapatkan daftar alamat IP di belakang nama domain.
1. Yang diselesaikan IPs dengan TTL dikembalikan sebagai respons terhadap permintaan DNS. Ini kemudian IPs ditulis dalam peta eBPF yang digunakan pada langkah berikutnya untuk penegakan lapisan IP.
1. Probe eBPF yang terpasang pada antarmuka Pod veth kemudian akan memfilter lalu lintas keluar dari Workload A ke endpoint cluster-eksternal berdasarkan aturan yang berlaku. Ini memastikan pod hanya dapat mengirim lalu lintas cluster-eksternal ke domain yang diizinkan IPs yang terdaftar. Validitas ini IPs didasarkan pada TTL yang diambil dari Resolver DNS Eksternal (Amazon Route 53 Resolver).
#### Menggunakan Kebijakan Jaringan Aplikasi
`ApplicationNetworkPolicy`Ini menggabungkan kemampuan kebijakan jaringan Kubernetes standar dengan pemfilteran berbasis DNS pada tingkat namespace menggunakan Custom Resource Definition (CRD) tunggal. Oleh karena itu, `ApplicationNetworkPolicy` dapat digunakan untuk:
1. Mendefinisikan pembatasan pada lapisan 3 dan 4 dari tumpukan jaringan menggunakan blok IP dan nomor port.
1. Mendefinisikan aturan yang beroperasi pada lapisan 7 dari tumpukan jaringan dan memungkinkan Anda memfilter lalu lintas berdasarkan FQDNs.
**penting**
Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja `ApplicationNetworkPolicy` yang berjalan di instans EC2 yang diluncurkan Mode Otomatis EKS. `ApplicationNetworkPolicy`mendukung semua bidang Kubernetes standar`NetworkPolicy`, dengan filter FQDN tambahan untuk aturan jalan keluar.
**Awas**
Jangan gunakan nama yang sama untuk `ApplicationNetworkPolicy` dan a `NetworkPolicy` dalam namespace yang sama. Jika nama bertabrakan, `PolicyEndpoints` objek yang dihasilkan mungkin tidak mencerminkan salah satu kebijakan dengan benar. Kedua sumber daya diterima tanpa kesalahan, membuat masalah ini sulit didiagnosis.
Untuk mengatasi konflik penamaan, ganti nama `ApplicationNetworkPolicy` atau `NetworkPolicy` jadi mereka unik dalam namespace, lalu verifikasi bahwa `PolicyEndpoints` objek yang sesuai diperbarui dengan benar.
#### Contoh
Anda memiliki beban kerja di kluster Mode Otomatis EKS Anda yang perlu berkomunikasi dengan aplikasi on-prem yang berada di belakang penyeimbang beban dengan nama DNS. Anda dapat mencapai ini menggunakan kebijakan jaringan berikut:
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ApplicationNetworkPolicy
metadata:
name: my-onprem-app-egress
namespace: galaxy
spec:
podSelector:
matchLabels:
role: backend
policyTypes:
- Egress
egress:
- to:
- domainNames:
- "myapp.mydomain.com"
ports:
- protocol: TCP
port: 8080
```
**Pada tingkat jaringan Kubernetes, ini akan memungkinkan jalan keluar dari setiap pod di namespace “galaksi” yang diberi label `role: backend` untuk terhubung ke nama domain myapp.mydomain.com pada port TCP 8080.** Selain itu, Anda perlu mengatur konektivitas jaringan untuk lalu lintas keluar dari VPC Anda ke pusat data perusahaan Anda.
![\[llustrasi beban kerja di EKS Auto berkomunikasi dengan aplikasi di prem\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/eks-auto-to-on-prem.png)
### Kebijakan jaringan admin (atau cluster)
![\[llustrasi urutan evaluasi untuk kebijakan jaringan di EKS\]](http://docs.aws.amazon.com/id_id/eks/latest/userguide/images/evaluation-order.png)
#### Menggunakan Kebijakan Jaringan Cluster
Saat menggunakan`ClusterNetworkPolicy`, kebijakan tingkat Admin dievaluasi terlebih dahulu dan tidak dapat diganti. Ketika kebijakan tingkat Admin telah dievaluasi, kebijakan cakupan namespace standar digunakan untuk menjalankan aturan segmentasi jaringan yang diterapkan. Hal ini dapat dicapai dengan menggunakan salah satu `ApplicationNetworkPolicy` atau`NetworkPolicy`. Terakhir, aturan tingkat dasar yang menentukan batasan jaringan default untuk beban kerja klaster akan diberlakukan. Aturan tingkat dasar ini **dapat** diganti dengan kebijakan cakupan namespace jika diperlukan.
#### Contoh
Anda memiliki aplikasi di cluster Anda yang ingin Anda isolasi dari beban kerja penyewa lainnya. Anda dapat secara eksplisit memblokir lalu lintas klaster dari ruang nama lain untuk mencegah akses jaringan ke namespace beban kerja yang sensitif.
```
apiVersion: networking.k8s.aws/v1alpha1
kind: ClusterNetworkPolicy
metadata:
name: protect-sensitive-workload
spec:
tier: Admin
priority: 10
subject:
namespaces:
matchLabels:
kubernetes.io/metadata.name: earth
ingress:
- action: Deny
from:
- namespaces:
matchLabels: {} # Match all namespaces.
name: select-all-deny-all
```
## Pertimbangan-pertimbangan
### Memahami urutan evaluasi kebijakan
Kemampuan kebijakan jaringan yang didukung di EKS dievaluasi dalam urutan tertentu untuk memastikan manajemen lalu lintas yang dapat diprediksi dan aman. Oleh karena itu, penting untuk memahami alur evaluasi untuk merancang postur keamanan jaringan yang efektif untuk lingkungan Anda.
1. **Kebijakan tingkat admin (dievaluasi terlebih dahulu)**: Semua tingkat Admin ClusterNetworkPolicies dievaluasi sebelum kebijakan lainnya. Dalam tingkat Admin, kebijakan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Jenis tindakan menentukan apa yang terjadi selanjutnya.
+ **Tindakan tolak (prioritas tertinggi)**: Ketika kebijakan Admin dengan tindakan Tolak cocok dengan lalu lintas, lalu lintas tersebut segera diblokir terlepas dari kebijakan lainnya. Tidak ada lebih lanjut ClusterNetworkPolicy atau NetworkPolicy aturan yang diproses. Ini memastikan bahwa kontrol keamanan di seluruh organisasi tidak dapat diganti oleh kebijakan tingkat ruang nama.
+ **Izinkan tindakan**: Setelah aturan Tolak dievaluasi, kebijakan Admin dengan tindakan Izinkan diproses dalam urutan prioritas (nomor prioritas terendah terlebih dahulu). Ketika tindakan Izinkan cocok, lalu lintas diterima dan tidak ada evaluasi kebijakan lebih lanjut yang terjadi. Kebijakan ini dapat memberikan akses di beberapa ruang nama berdasarkan pemilih label, memberikan kontrol terpusat atas beban kerja mana yang dapat mengakses sumber daya tertentu.
+ **Lulus tindakan**: Melewati tindakan dalam kebijakan tingkat Admin mendelegasikan pengambilan keputusan ke tingkat yang lebih rendah. Ketika lalu lintas cocok dengan aturan Pass, evaluasi melewatkan semua aturan tingkat Admin yang tersisa untuk lalu lintas tersebut dan melanjutkan langsung ke tingkat. NetworkPolicy Hal ini memungkinkan administrator untuk secara eksplisit mendelegasikan kontrol untuk pola lalu lintas tertentu ke tim aplikasi. Misalnya, Anda dapat menggunakan aturan Pass untuk mendelegasikan manajemen lalu lintas intra-namespace ke administrator namespace sambil mempertahankan kontrol ketat atas akses eksternal.
1. **Tingkat kebijakan jaringan**: Jika tidak ada kebijakan tingkat Admin yang cocok dengan Tolak atau Izinkan, atau jika tindakan Pass dicocokkan, sumber daya cakupan nama dan sumber daya tradisional akan dievaluasi berikutnya ApplicationNetworkPolicy . NetworkPolicy Kebijakan ini memberikan kontrol halus dalam ruang nama individu dan dikelola oleh tim aplikasi. Kebijakan dengan cakupan ruang nama hanya bisa lebih ketat daripada kebijakan Admin. Mereka tidak dapat mengesampingkan keputusan Tolak kebijakan Admin, tetapi mereka dapat membatasi lalu lintas yang diizinkan atau disahkan oleh kebijakan Admin.
1. **Kebijakan Admin tingkat dasar: Jika tidak ada kebijakan** dengan cakupan Admin atau ruang nama yang cocok dengan lalu lintas, tingkat dasar akan dievaluasi. ClusterNetworkPolicies Ini memberikan postur keamanan default yang dapat diganti dengan kebijakan cakupan ruang nama, memungkinkan administrator untuk menetapkan default di seluruh organisasi sambil memberi tim fleksibilitas untuk menyesuaikan sesuai kebutuhan. Kebijakan dasar dievaluasi dalam urutan prioritas (nomor prioritas terendah terlebih dahulu).
1. **Penyangkalan default (jika tidak ada kebijakan yang cocok)**: deny-by-default Perilaku ini memastikan bahwa hanya koneksi yang diizinkan secara eksplisit yang diizinkan, mempertahankan postur keamanan yang kuat.
### Menerapkan prinsip hak istimewa paling sedikit
+ **Mulailah dengan kebijakan restriktif dan tambahkan izin secara bertahap sesuai kebutuhan** - Mulailah dengan menerapkan deny-by-default kebijakan di tingkat klaster, lalu tambahkan aturan izin secara bertahap saat Anda memvalidasi persyaratan konektivitas yang sah. Pendekatan ini memaksa tim untuk secara eksplisit membenarkan setiap koneksi eksternal, menciptakan lingkungan yang lebih aman dan dapat diaudit.
+ **Secara teratur mengaudit dan menghapus aturan kebijakan yang tidak digunakan** - Kebijakan jaringan dapat terakumulasi dari waktu ke waktu seiring berkembangnya aplikasi, meninggalkan aturan usang yang tidak perlu memperluas permukaan serangan Anda. Terapkan proses peninjauan rutin untuk mengidentifikasi dan menghapus aturan kebijakan yang tidak lagi diperlukan, memastikan postur keamanan Anda tetap ketat dan dapat dipelihara.
+ **Gunakan nama domain tertentu daripada pola luas bila memungkinkan** - Meskipun pola wildcard seperti `*.amazonaws.com` memberikan kenyamanan, mereka juga memberikan akses ke berbagai layanan. Bila memungkinkan, tentukan nama domain yang tepat seperti `s3.us-west-2.amazonaws.com` membatasi akses hanya ke layanan spesifik yang dibutuhkan aplikasi Anda, mengurangi risiko pergerakan lateral jika beban kerja terganggu.
### Menggunakan kebijakan berbasis DNS di EKS
+ Aturan berbasis DNS yang ditentukan menggunakan hanya berlaku untuk beban kerja `ApplicationNetworkPolicy` yang berjalan di instans EC2 yang diluncurkan Mode Otomatis EKS. Jika Anda menjalankan cluster mode campuran (terdiri dari node pekerja EKS Auto dan non EKS Auto), aturan berbasis DNS Anda hanya efektif di node pekerja mode EKS Auto (instans terkelola EC2).
### Memvalidasi kebijakan DNS Anda
+ **Gunakan klaster pementasan yang mencerminkan topologi jaringan produksi untuk pengujian** - Lingkungan pementasan Anda harus mereplikasi arsitektur jaringan, dependensi eksternal, dan pola konektivitas produksi untuk memastikan pengujian kebijakan yang akurat. Ini termasuk pencocokan konfigurasi VPC, perilaku resolusi DNS, dan akses ke layanan eksternal yang sama yang dibutuhkan oleh beban kerja produksi Anda.
+ **Terapkan pengujian otomatis untuk jalur jaringan kritis** - Buat pengujian otomatis yang memvalidasi konektivitas ke layanan eksternal penting sebagai bagian dari CI/CD pipeline Anda. Tes ini harus memverifikasi bahwa arus lalu lintas yang sah diizinkan sementara koneksi yang tidak sah diblokir, memberikan validasi berkelanjutan bahwa kebijakan jaringan Anda mempertahankan postur keamanan yang benar saat infrastruktur Anda berkembang.
+ **Pantau perilaku aplikasi setelah perubahan kebijakan** - Setelah menerapkan kebijakan jaringan baru atau yang dimodifikasi ke produksi, pantau log aplikasi, tingkat kesalahan, dan metrik kinerja dengan cermat untuk mengidentifikasi masalah konektivitas apa pun dengan cepat. Tetapkan prosedur rollback yang jelas sehingga Anda dapat dengan cepat mengembalikan perubahan kebijakan jika menyebabkan perilaku aplikasi atau gangguan layanan yang tidak terduga.
### Interaksi dengan Amazon Route 53 DNS firewall
Kebijakan Admin dan Jaringan EKS dievaluasi terlebih dahulu pada tingkat pod saat lalu lintas dimulai. Jika kebijakan jaringan EKS mengizinkan jalan keluar ke domain tertentu, pod akan melakukan query DNS yang mencapai Route 53 Resolver. Pada titik ini, aturan Route 53 DNS Firewall dievaluasi. Jika DNS Firewall memblokir kueri domain, resolusi DNS gagal dan koneksi tidak dapat dibuat, meskipun kebijakan jaringan EKS mengizinkannya. Ini menciptakan lapisan keamanan yang saling melengkapi: Kebijakan jaringan berbasis DNS EKS memberikan kontrol jalan keluar tingkat pop untuk persyaratan akses khusus aplikasi dan batas keamanan multi-penyewa, sementara DNS Firewall memberikan perlindungan luas VPC terhadap domain berbahaya yang diketahui dan memberlakukan blokir di seluruh organisasi.
# Tag subnet untuk Mode Otomatis EKS
Jika Anda menggunakan kemampuan load balancing dari Mode Otomatis EKS, Anda perlu menambahkan AWS tag ke subnet VPC Anda.
## Latar Belakang
Tag ini mengidentifikasi subnet yang terkait dengan cluster, dan yang lebih penting jika subnet bersifat publik atau pribadi.
Subnet publik memiliki akses internet langsung melalui gateway internet. Mereka digunakan untuk sumber daya yang perlu diakses publik seperti penyeimbang beban.
Subnet pribadi tidak memiliki akses internet langsung dan menggunakan gateway NAT untuk lalu lintas keluar. Mereka digunakan untuk sumber daya internal seperti node EKS yang tidak membutuhkan publik IPs.
Untuk mempelajari selengkapnya tentang gateway NAT dan gateway Internet, lihat [Menyambungkan VPC ke jaringan lain](https://docs.aws.amazon.com/vpc/latest/userguide/extend-intro.html) di Panduan Pengguna Amazon Virtual Private Cloud (VPC).
## Persyaratan
Pada saat ini, subnet yang digunakan untuk penyeimbangan beban oleh Mode Otomatis EKS diharuskan memiliki salah satu tag berikut.
### Subnet publik
Subnet publik digunakan untuk penyeimbang beban yang menghadap ke internet. Subnet ini harus memiliki tag berikut:
| Key | Nilai |
| --- | --- |
| `kubernetes.io/role/elb` | `1`atau `` |
### Subnet privat
Subnet pribadi digunakan untuk penyeimbang beban internal. Subnet ini harus memiliki tag berikut:
| Key | Nilai |
| --- | --- |
| `kubernetes.io/role/internal-elb` | `1`atau `` |
## Prosedur
Sebelum Anda mulai, identifikasi subnet mana yang bersifat publik (dengan akses Internet Gateway) dan mana yang pribadi (menggunakan NAT Gateway). Anda memerlukan izin untuk memodifikasi sumber daya VPC.
### Konsol Manajemen AWS
1. **Buka konsol Amazon VPC dan navigasikan ke Subnet.**
1. Pilih subnet yang akan diberi tag.
1. Pilih tab **Tag** dan pilih **Tambahkan tag**.
1. Tambahkan tag yang sesuai:
+ Untuk subnet publik: Key= `kubernetes.io/role/elb`
+ Untuk subnet pribadi: Key= `kubernetes.io/role/internal-elb`
1. Tetapkan **Nilai** ke `1` atau biarkan kosong.
1. Simpan dan ulangi untuk subnet yang tersisa.
### AWS CLI
Untuk subnet publik:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/elb,Value=1
```
Untuk subnet pribadi:
```
aws ec2 create-tags \
--resources subnet-ID \
--tags Key=kubernetes.io/role/internal-elb,Value=1
```
Ganti `subnet-ID` dengan subnet ID Anda yang sebenarnya.
# Buat laporan kepatuhan CIS dari node Kubernetes menggunakan debug kubectl
Topik ini menjelaskan cara membuat laporan kepatuhan CIS (Center for Internet Security) untuk node Amazon EKS menggunakan `kubectl debug` perintah. Perintah ini memungkinkan Anda untuk membuat kontainer debugging sementara pada node Kubernetes dan menjalankan pemeriksaan kepatuhan CIS menggunakan alat ini. `apiclient` `apiclient`Alat ini adalah bagian dari Bottlerocket OS, OS yang digunakan oleh node Mode Otomatis EKS.
## Prasyarat
Sebelum Anda mulai, pastikan Anda memiliki:
+ Akses ke kluster Amazon EKS dengan `kubectl` konfigurasi (versi minimal harus v1.32.0; ketik `kubectl version` untuk memeriksa).
+ Izin IAM yang sesuai untuk men-debug node.
+ Profil valid yang memungkinkan operasi debug (misalnya,`sysadmin`).
Untuk informasi selengkapnya tentang menggunakan profil debugging`kubectl`, lihat [Debugging Pod atau Node saat menerapkan profil dalam dokumentasi](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/#debugging-profiles) Kubernetes.
## Prosedur
1. Tentukan ID AWS Instance dari node yang ingin Anda jalankan laporannya. Gunakan perintah berikut untuk daftar node dalam cluster. ID instance ditemukan di kolom nama, dan dimulai dengan`i-`:
```
kubectl get nodes
```
```
NAME STATUS ROLES AGE VERSION
i-0ea0ba0f8ef9ad609 Ready 62s v1.30.10-eks-1a9dacd
```
1. Jalankan perintah berikut, ganti `` dengan ID instance dari node yang ingin Anda kueri:
```
kubectl debug node/ -it --profile=sysadmin --image=public.ecr.aws/amazonlinux/amazonlinux:2023 -- bash -c "yum install -q -y util-linux-core; nsenter -t 1 -m apiclient report cis --level 1 --format text"
```
Komponen perintah ini meliputi:
+ `kubectl debug node/`— Membuat sesi debugging pada ID instans EC2 yang ditentukan.
+ `-it`— Mengalokasikan TTY (shell baris perintah) dan membuat stdin tetap terbuka untuk penggunaan interaktif.
+ `--profile=sysadmin`— Menggunakan `kubectl` profil yang ditentukan dengan izin yang sesuai.
+ `--image=public.ecr.aws/amazonlinux/amazonlinux:2023`- Digunakan `amazonlinux:2023` sebagai gambar kontainer untuk debugging.
+ `bash -c "…"`— Mengeksekusi perintah berikut dalam bash shell:
+ `yum install -q -y util-linux-core`— Diam-diam menginstal paket utilitas yang diperlukan.
+ `nsenter -t 1 -m`— Berjalan `nsenter` untuk memasuki namespace dari proses host (PID 1).
+ `apiclient report cis --level 1 --format text`— Menjalankan laporan kepatuhan CIS di level 1 dengan output teks.
1. Tinjau keluaran teks laporan.
## Menafsirkan output
Perintah menghasilkan laporan berbasis teks yang menunjukkan status kepatuhan berbagai kontrol CIS. Outputnya meliputi:
+ Kontrol CIS individu IDs
+ Deskripsi setiap kontrol
+ Status Lulus, Gagal, atau Lewati untuk setiap pemeriksaan
+ Detail yang menjelaskan masalah kepatuhan apa pun
Berikut adalah contoh output dari laporan yang dijalankan pada instance Bottlerocket:
```
Benchmark name: CIS Bottlerocket Benchmark
Version: v1.0.0
Reference: https://www.cisecurity.org/benchmark/bottlerocket
Benchmark level: 1
Start time: 2025-04-11T01:40:39.055623436Z
[SKIP] 1.2.1 Ensure software update repositories are configured (Manual)
[PASS] 1.3.1 Ensure dm-verity is configured (Automatic)[PASS] 1.4.1 Ensure setuid programs do not create core dumps (Automatic)
[PASS] 1.4.2 Ensure address space layout randomization (ASLR) is enabled (Automatic)
[PASS] 1.4.3 Ensure unprivileged eBPF is disabled (Automatic)
[PASS] 1.5.1 Ensure SELinux is configured (Automatic)
[SKIP] 1.6 Ensure updates, patches, and additional security software are installed (Manual)
[PASS] 2.1.1.1 Ensure chrony is configured (Automatic)
[PASS] 3.2.5 Ensure broadcast ICMP requests are ignored (Automatic)
[PASS] 3.2.6 Ensure bogus ICMP responses are ignored (Automatic)
[PASS] 3.2.7 Ensure TCP SYN Cookies is enabled (Automatic)
[SKIP] 3.4.1.3 Ensure IPv4 outbound and established connections are configured (Manual)
[SKIP] 3.4.2.3 Ensure IPv6 outbound and established connections are configured (Manual)
[PASS] 4.1.1.1 Ensure journald is configured to write logs to persistent disk (Automatic)
[PASS] 4.1.2 Ensure permissions on journal files are configured (Automatic)
Passed: 11
Failed: 0
Skipped: 4
Total checks: 15
```
Untuk informasi tentang benchmark, lihat [Kubernetes Benchmark](https://www.cisecurity.org/benchmark/kubernetes/) dari Center for Internet Security (CIS).
## Sumber daya terkait
+ [Tolok Ukur CIS Bottlerocket](https://bottlerocket.dev/en/os/1.34.x/api/reporting/cis/) dalam Dokumentasi OS Bottlerocket.
+ [Debug Running Pod dalam Dokumentasi](https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/) Kubernetes.
+ [Benchmark Kubernetes](https://www.cisecurity.org/benchmark/kubernetes/) dari Pusat Keamanan Internet (CIS)
# Aktifkan Enkripsi Volume EBS dengan Kunci KMS yang Dikelola Pelanggan untuk Mode Otomatis EKS
Anda dapat mengenkripsi volume root sementara untuk instans Mode Otomatis EKS dengan kunci KMS yang dikelola pelanggan.
Amazon EKS Auto Mode menggunakan peran terkait layanan untuk mendelegasikan izin ke AWS layanan lain saat mengelola volume EBS terenkripsi untuk klaster Kubernetes Anda. Topik ini menjelaskan cara menyiapkan kebijakan kunci yang Anda perlukan saat menentukan kunci terkelola pelanggan untuk enkripsi Amazon EBS dengan Mode Otomatis EKS.
Pertimbangan:
+ Mode Otomatis EKS tidak memerlukan otorisasi tambahan untuk menggunakan kunci AWS terkelola default untuk melindungi volume terenkripsi di akun Anda.
+ Topik ini mencakup mengenkripsi volume fana, volume root untuk instance. EC2 Untuk informasi selengkapnya tentang mengenkripsi volume data yang digunakan untuk beban kerja, lihat. [Buat kelas penyimpanan](create-storage-class.md)
## Gambaran umum
Kunci AWS KMS berikut dapat digunakan untuk enkripsi volume root Amazon EBS saat Mode Otomatis EKS meluncurkan instance:
+ ** AWS kunci terkelola** — Kunci enkripsi di akun Anda yang dibuat, dimiliki, dan dikelola Amazon EBS. Ini adalah kunci enkripsi default untuk akun baru.
+ **Kunci terkelola pelanggan** — Kunci enkripsi khusus yang Anda buat, miliki, dan kelola.
**catatan**
Kuncinya harus simetris. Amazon EBS tidak mendukung kunci yang dikelola pelanggan asimetris.
## Langkah 1: Konfigurasikan kebijakan kunci
Kunci KMS Anda harus memiliki kebijakan kunci yang memungkinkan Mode Otomatis EKS meluncurkan instans dengan volume Amazon EBS yang dienkripsi dengan kunci yang dikelola pelanggan.
Konfigurasikan kebijakan kunci Anda dengan struktur berikut:
**catatan**
Kebijakan ini hanya mencakup izin untuk Mode Otomatis EKS. Kebijakan kunci mungkin memerlukan izin tambahan jika identitas lain perlu menggunakan kunci atau mengelola hibah.
```
{
"Version":"2012-10-17",
"Id": "MyKeyPolicy",
"Statement": [
{
"Sid": "Allow use of the key",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow attachment of persistent resources",
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::123456789012:role/ClusterServiceRole"
]
},
"Action": [
"kms:CreateGrant",
"kms:ListGrants",
"kms:RevokeGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
]
}
```
Pastikan untuk mengganti `` dengan ID AWS akun Anda yang sebenarnya.
Saat mengonfigurasi kebijakan kunci:
+ `ClusterServiceRole`Harus memiliki izin IAM yang diperlukan untuk menggunakan kunci KMS untuk operasi enkripsi
+ `kms:GrantIsForAWSResource`Kondisi ini memastikan bahwa hibah hanya dapat dibuat untuk layanan AWS
## Langkah 2: Konfigurasikan NodeClass dengan kunci yang dikelola pelanggan Anda
Setelah mengonfigurasi kebijakan kunci, rujuk kunci KMS dalam konfigurasi Mode NodeClass Otomatis EKS Anda:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: my-node-class
spec:
# Insert existing configuration
ephemeralStorage:
size: "80Gi" # Range: 1-59000Gi or 1-64000G or 1-58Ti or 1-64T
iops: 3000 # Range: 3000-16000
throughput: 125 # Range: 125-1000
# KMS key for encryption
kmsKeyID: "arn:aws: kms:::key/"
```
Ganti nilai placeholder dengan nilai aktual Anda:
+ ``dengan AWS wilayah Anda
+ ``dengan ID AWS akun Anda
+ ``dengan ID kunci KMS Anda
Anda dapat menentukan kunci KMS menggunakan salah satu format berikut:
+ ID Kunci KMS: `1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ ARN Kunci KMS: ` arn:aws: kms:us-west-2:111122223333:key/1a2b3c4d-5e6f-1a2b-3c4d-5e6f1a2b3c4d`
+ Nama Alias Kunci: `alias/eks-auto-mode-key`
+ Kunci Alias ARN: ` arn:aws: kms:us-west-2:111122223333:alias/eks-auto-mode-key`
Terapkan NodeClass konfigurasi menggunakan kubectl:
```
kubectl apply -f nodeclass.yaml
```
## Sumber Daya Terkait
+ [Buat Kelas Node untuk Amazon EKS](create-node-class.md)
+ Lihat informasi selengkapnya di Panduan Pengembang Layanan Manajemen AWS Utama
+ [Izin untuk AWS layanan dalam kebijakan utama](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-services.html)
+ [Mengubah kebijakan utama](https://docs.aws.amazon.com/kms/latest/developerguide/key-policy-modifying.html)
+ [Hibah di AWS KMS](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html)
# Perbarui kontrol organisasi untuk Mode Otomatis EKS
Beberapa kontrol organisasi dapat mencegah Mode Otomatis EKS berfungsi dengan benar. Jika demikian, Anda harus memperbarui kontrol ini agar Mode Otomatis EKS memiliki izin yang diperlukan untuk mengelola instans EC2 atas nama Anda.
Mode Otomatis EKS menggunakan peran layanan untuk meluncurkan Instans EC2 yang mendukung Node Mode Otomatis EKS. Peran layanan adalah peran [IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) yang dibuat di akun Anda yang diasumsikan oleh layanan untuk melakukan tindakan atas nama Anda. [Kebijakan Kontrol Layanan](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) selalu berlaku untuk tindakan yang dilakukan dengan peran layanan. Hal ini memungkinkan SCP untuk menghambat operasi Mode Otomatis. Kejadian yang paling umum adalah ketika SCP digunakan untuk membatasi Amazon Machine Images (AMIs) yang dapat diluncurkan. Untuk memungkinkan Mode Otomatis EKS berfungsi, ubah SCP untuk mengizinkan peluncuran AMIs dari akun Mode Otomatis EKS.
Anda juga dapat menggunakan AMIs fitur [EC2 Allowed](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-allowed-amis.html) untuk membatasi visibilitas AMIs di akun lain. Jika Anda menggunakan fitur ini, Anda harus memperluas kriteria gambar untuk juga menyertakan akun AMI Mode Otomatis EKS di wilayah yang diminati.
## Contoh SCP untuk memblokir semua AMIs kecuali untuk Mode Otomatis EKS AMIs
SCP di bawah ini mencegah panggilan `ec2:RunInstances` kecuali AMI milik akun AMI Mode Otomatis EKS untuk us-west-2 atau us-east-1.
**catatan**
Penting untuk **tidak** menggunakan kunci `ec2:Owner` konteks. Amazon memiliki akun AMI Mode Otomatis EKS dan nilai untuk kunci ini akan `amazon` selalu ada. Membangun SCP yang memungkinkan peluncuran AMIs jika `ec2:Owner` is `amazon` akan memungkinkan peluncuran AMI milik Amazon, bukan hanya untuk Mode Otomatis EKS. \$1
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyAMI",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:*:ec2:*::image/ami-*",
"Condition": {
"StringNotEquals": {
"aws:ResourceAccount": [
"767397842682",
"992382739861"
]
}
}
}
]
}
```
## Akun AMI Mode Otomatis EKS
AWS akun yang bervariasi menurut wilayah host EKS Auto Mode publik AMIs.
| | |
| --- |--- |
| AWS Wilayah | Akun |
| af-south-1 | 471112993317 |
| ap-east-1 | 590183728416 |
| ap-timur-2 | 381492200852 |
| ap-northeast-1 | 851725346105 |
| ap-northeast-2 | 992382805010 |
| ap-northeast-3 | 891377407544 |
| ap-south-1 | 975049899075 |
| ap-south-2 | 590183737426 |
| ap-southeast-1 | 339712723301 |
| ap-southeast-2 | 058264376476 |
| ap-southeast-3 | 471112941769 |
| ap-southeast-4 | 590183863144 |
| ap-southeast-5 | 654654202513 |
| ap-tenggara 6 | 905418310314 |
| ap-tenggara 7 | 533267217478 |
| ca-central-1 | 992382439851 |
| ca-west-1 | 767397959864 |
| eu-central-1 | 891376953411 |
| eu-central-2 | 381492036002 |
| eu-north-1 | 339712696471 |
| eu-south-1 | 975049955519 |
| eu-south-2 | 471112620929 |
| eu-west-1 | 381492008532 |
| eu-west-2 | 590184142468 |
| eu-west-3 | 891376969258 |
| il-central-1 | 590183797093 |
| me-central-1 | 637423494195 |
| me-south-1 | 905418070398 |
| mx-pusat-1 | 211125506622 |
| sa-east-1 | 339712709251 |
| us-east-1 | 992382739861 |
| us-east-2 | 975050179949 |
| us-west-1 | 975050035094 |
| us-west-2 | 767397842682 |
| us-gov-east-1 | 446077414359 |
| us-gov-west-1 | 446098668741 |
## Alamat IP Publik Asosiasi
Kapan `ec2:RunInstances` dipanggil `AssociatePublicIpAddress` bidang untuk peluncuran instance ditentukan secara otomatis oleh jenis subnet tempat instance diluncurkan. SCP dapat digunakan untuk menegakkan bahwa nilai ini secara eksplisit disetel ke false, terlepas dari jenis subnet yang diluncurkan. Dalam hal ini NodeClass bidang juga `spec.advancedNetworking.associatePublicIPAddress` dapat diatur ke false untuk memenuhi persyaratan SCP.
```
{
"Sid": "DenyPublicEC2IPAddesses",
"Effect": "Deny",
"Action": "ec2:RunInstances",
"Resource": "arn:aws:ec2:*:*:network-interface/*",
"Condition": {
"BoolIfExists": {
"ec2:AssociatePublicIpAddress": "true"
}
}
}
```
# Kontrol penyebaran beban kerja ke Reservasi Kapasitas dengan Mode Otomatis EKS
Anda dapat mengontrol penyebaran beban kerja ke Reservasi [Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-reservation-overview.html). Mode Otomatis EKS mendukung EC2 On-Demand Capacity Reservations (ODCR), dan Blok Kapasitas EC2 untuk ML.
**Tip**
Secara default, Mode Otomatis EKS dapat diluncurkan ke open ODCRs melalui pencocokan terbuka, tetapi tidak memprioritaskannya. Instans yang diluncurkan melalui pencocokan terbuka diberi label`karpenter.sh/capacity-type: on-demand`, bukan. `reserved` Untuk memprioritaskan penggunaan ODCR dan memiliki instance berlabel`karpenter.sh/capacity-type: reserved`, konfigurasikan dalam definisi. `capacityReservationSelectorTerms` NodeClass Blok Kapasitas untuk ML selalu membutuhkan `capacityReservationSelectorTerms` dan tidak digunakan secara otomatis.
## Reservasi Kapasitas Sesuai Permintaan EC2 () ODCRs
EC2 On-Demand Capacity Reservations (ODCR) memungkinkan Anda untuk memesan kapasitas komputasi untuk instans Amazon EC2 Anda di Availability Zone tertentu untuk durasi berapa pun. Saat menggunakan Mode Otomatis EKS, Anda mungkin ingin mengontrol apakah beban kerja Kubernetes Anda diterapkan ke instans cadangan ini untuk memaksimalkan pemanfaatan kapasitas yang telah dibeli sebelumnya atau untuk memastikan beban kerja kritis memiliki akses ke sumber daya yang terjamin.
Secara default, Mode Otomatis EKS secara otomatis diluncurkan ke terbuka ODCRs. Namun, dengan mengonfigurasi `capacityReservationSelectorTerms` pada a NodeClass, Anda dapat secara eksplisit mengontrol beban kerja yang ODCRs Anda gunakan. Node yang disediakan menggunakan konfigurasi ODCRs akan memiliki `karpenter.sh/capacity-type: reserved` dan akan diprioritaskan daripada on-demand dan spot. Setelah fitur ini diaktifkan, Mode Otomatis EKS tidak akan lagi secara otomatis menggunakan open ODCRs —mereka harus dipilih secara eksplisit oleh a NodeClass, memberi Anda kontrol yang tepat atas penggunaan reservasi kapasitas di seluruh cluster Anda.
**Awas**
Jika Anda mengonfigurasi `capacityReservationSelectorTerms` di NodeClass dalam cluster, Mode Otomatis EKS tidak akan lagi secara otomatis menggunakan open ODCRs untuk *apa pun* NodeClass di cluster.
### Contoh NodeClass
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
spec:
# Optional: Selects upon on-demand capacity reservations and capacity blocks
# for EKS Auto Mode to prioritize.
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
# Alternative Approaches
- tags:
app: "my-app"
# Optional owning account ID filter
owner: "012345678901"
```
Contoh ini NodeClass menunjukkan dua pendekatan untuk memilih ODCRs. Metode pertama secara langsung mereferensikan ODCR tertentu dengan ID ()`cr-56fac701cc1951b03`. Metode kedua menggunakan pemilihan berbasis tag, menargetkan ODCRs dengan tag. `Name: "targeted-odcr"` Anda juga dapat memfilter secara opsional berdasarkan AWS akun yang memiliki reservasi, yang sangat berguna dalam skenario lintas akun atau saat bekerja dengan reservasi kapasitas bersama.
## Blok Kapasitas EC2 untuk ML
Blok Kapasitas untuk MS mencadangkan instans komputasi akselerasi berbasis GPU di masa mendatang untuk mendukung beban kerja machine learning (ML) berdurasi pendek Anda. Instans yang berjalan di dalam Blok Kapasitas secara otomatis ditempatkan berdekatan di dalam Amazon UltraClusters EC2, untuk jaringan latensi rendah, skala petabit, dan non-pemblokiran.
Untuk informasi selengkapnya tentang platform dan jenis instans yang didukung, lihat [Blok Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) di Panduan Pengguna EC2.
Anda dapat membuat Mode Otomatis EKS NodeClass yang menggunakan Blok Kapasitas untuk ML, mirip dengan ODCR (dijelaskan sebelumnya).
Contoh definisi berikut membuat tiga sumber daya:
1. A NodeClass yang mereferensikan reservasi Blok Kapasitas Anda
1. A NodePool yang menggunakan NodeClass dan menerapkan noda
1. Spesifikasi Pod yang mentolerir taint dan meminta sumber daya GPU
### Contoh NodeClass
Ini NodeClass mereferensikan Blok Kapasitas tertentu untuk ML dengan ID reservasi. Anda dapat memperoleh ID ini dari konsol EC2.
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: gpu
spec:
# Specify your Capacity Block reservation ID
capacityReservationSelectorTerms:
- id: cr-56fac701cc1951b03
```
Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
### Contoh NodePool
Ini NodePool mereferensikan `gpu` NodeClass dan menentukan konfigurasi penting:
+ Ini **hanya** menggunakan kapasitas cadangan dengan pengaturan `karpenter.sh/capacity-type: reserved`
+ Ini meminta keluarga instance GPU tertentu yang sesuai untuk beban kerja ML
+ Ini menerapkan `nvidia.com/gpu` noda untuk memastikan hanya beban kerja GPU yang dijadwalkan pada node ini
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
template:
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: gpu
requirements:
- key: eks.amazonaws.com/instance-family
operator: In
values:
- g6
- p4d
- p4de
- p5
- p5e
- p5en
- p6
- p6-b200
- key: karpenter.sh/capacity-type
operator: In
values:
- reserved
# Enable other capacity types
# - on-demand
# - spot
taints:
- effect: NoSchedule
key: nvidia.com/gpu
```
Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
### Contoh Pod
Contoh pod ini menunjukkan cara mengonfigurasi beban kerja untuk dijalankan pada node Blok Kapasitas Anda:
+ Ini menggunakan **NodeSelector** untuk menargetkan jenis GPU tertentu (dalam hal ini, H200) GPUs
+ Ini termasuk **toleransi** untuk `nvidia.com/gpu` noda yang diterapkan oleh NodePool
+ Ini secara eksplisit **meminta sumber daya GPU menggunakan tipe sumber daya** `nvidia.com/gpu`
```
apiVersion: v1
kind: Pod
metadata:
name: nvidia-smi
spec:
nodeSelector:
# Select specific GPU type - uncomment as needed
# eks.amazonaws.com/instance-gpu-name: l4
# eks.amazonaws.com/instance-gpu-name: a100
eks.amazonaws.com/instance-gpu-name: h200
# eks.amazonaws.com/instance-gpu-name: b200
eks.amazonaws.com/compute-type: auto
restartPolicy: OnFailure
containers:
- name: nvidia-smi
image: public.ecr.aws/amazonlinux/amazonlinux:2023-minimal
args:
- "nvidia-smi"
resources:
requests:
# Uncomment if needed
# memory: "30Gi"
# cpu: "3500m"
nvidia.com/gpu: 1
limits:
# Uncomment if needed
# memory: "30Gi"
nvidia.com/gpu: 1
tolerations:
- key: nvidia.com/gpu
effect: NoSchedule
operator: Exists
```
Untuk informasi selengkapnya, lihat [Pods](https://kubernetes.io/docs/concepts/workloads/pods/) dalam dokumentasi Kubernetes.
### Sumber Daya Terkait
+ [Blok Kapasitas untuk ML](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-capacity-blocks.html) di Panduan Pengguna Amazon EC2
+ [Temukan dan beli Blok Kapasitas](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/capacity-blocks-purchase.html) di Panduan Pengguna Amazon EC2
+ [Mengelola sumber daya komputasi untuk AI/ML beban kerja di Amazon EKS](https://docs.aws.amazon.com/eks/latest/userguide/ml-compute-management.html)
+ [Optimalisasi Sumber Daya GPU dan Manajemen Biaya](https://docs.aws.amazon.com/eks/latest/best-practices/aiml-compute.html#_gpu_resource_optimization_and_cost_management) dalam Panduan Praktik Terbaik EKS
# Menerapkan node Mode Otomatis EKS ke Local Zones
Mode Otomatis EKS menyediakan manajemen cluster yang disederhanakan dengan penyediaan node otomatis. AWS Local Zones memperluas AWS infrastruktur ke lokasi geografis yang lebih dekat dengan pengguna akhir Anda, mengurangi latensi untuk aplikasi yang sensitif terhadap latensi. Panduan ini memandu Anda melalui proses penerapan node Mode Otomatis EKS ke AWS Local Zones, memungkinkan Anda menjalankan aplikasi kontainer dengan latensi yang lebih rendah untuk pengguna di area geografis tertentu.
Panduan ini juga menunjukkan cara menggunakan taint dan toleransi Kubernetes untuk memastikan bahwa hanya beban kerja tertentu yang berjalan di node Zona Lokal Anda, membantu Anda mengontrol biaya dan mengoptimalkan penggunaan sumber daya.
## Prasyarat
Sebelum Anda mulai menerapkan node Mode Otomatis EKS ke Local Zones, pastikan Anda memiliki prasyarat berikut:
+ [Kluster Mode Otomatis EKS yang ada](create-auto.md)
+ [Memilih untuk masuk ke zona lokal di akun Anda AWS](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-find-local-zone)
## Langkah 1: Buat Subnet Zona Lokal
Langkah pertama dalam menerapkan node Mode Otomatis EKS ke Zona Lokal adalah membuat subnet di Zona Lokal itu. Subnet ini menyediakan infrastruktur jaringan untuk node Anda dan memungkinkan mereka untuk berkomunikasi dengan seluruh VPC Anda. Ikuti instruksi [subnet Buat Zona Lokal](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html#getting-started-create-local-zone-subnet) (dalam Panduan Pengguna AWS Local Zones) untuk membuat subnet di Zona Lokal pilihan Anda.
**Tip**
Catat nama subnet zona lokal Anda.
## Langkah 2: Buat NodeClass untuk Subnet Zona Lokal
Setelah membuat subnet Zona Lokal Anda, Anda perlu menentukan NodeClass yang mereferensikan subnet ini. NodeClass Ini adalah sumber daya kustom Kubernetes yang menentukan atribut infrastruktur untuk node Anda, termasuk subnet, grup keamanan, dan konfigurasi penyimpanan mana yang akan digunakan. Dalam contoh di bawah ini, kita membuat NodeClass disebut “local-zone” yang menargetkan subnet zona lokal berdasarkan namanya. Anda juga dapat menggunakan subnet ID. Anda harus menyesuaikan konfigurasi ini untuk menargetkan subnet Zona Lokal Anda.
Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: local-zone
spec:
subnetSelectorTerms:
- id:
```
## Langkah 3: Buat NodePool dengan NodeClass dan Taint
Dengan NodeClass konfigurasi Anda, Anda sekarang perlu membuat NodePool yang menggunakan ini NodeClass. A NodePool mendefinisikan karakteristik komputasi node Anda, termasuk tipe instance. NodePool Menggunakan NodeClass sebagai referensi untuk menentukan di mana untuk meluncurkan instance.
Dalam contoh di bawah ini, kami membuat referensi NodePool yang merujuk “zona lokal” kami. NodeClass Kami juga menambahkan taint ke node untuk memastikan bahwa hanya pod dengan toleransi yang cocok yang dapat dijadwalkan pada node Local Zone ini. Ini sangat penting untuk node Zona Lokal, yang biasanya memiliki biaya lebih tinggi dan hanya boleh digunakan oleh beban kerja yang secara khusus mendapat manfaat dari pengurangan latensi.
Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
```
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: my-node-pool
spec:
template:
metadata:
labels:
node-type: local-zone
spec:
nodeClassRef:
group: eks.amazonaws.com
kind: NodeClass
name: local-zone
taints:
- key: "aws.amazon.com/local-zone"
value: "true"
effect: NoSchedule
requirements:
- key: "eks.amazonaws.com/instance-category"
operator: In
values: ["c", "m", "r"]
- key: "eks.amazonaws.com/instance-cpu"
operator: In
values: ["4", "8", "16", "32"]
```
Taint dengan kunci `aws.amazon.com/local-zone` dan efek `NoSchedule` memastikan bahwa pod tanpa toleransi yang cocok tidak akan dijadwalkan pada node ini. Ini mencegah beban kerja reguler berjalan secara tidak sengaja di Zona Lokal, yang dapat menyebabkan biaya yang tidak terduga.
## Langkah 4: Terapkan Beban Kerja dengan Tolerasi dan Afinitas Node
Untuk kontrol optimal atas penempatan beban kerja pada node Local Zone, gunakan keduanya taints/tolerations dan afinitas node bersama-sama. Pendekatan gabungan ini memberikan manfaat sebagai berikut:
1. **Pengendalian Biaya**: Taint memastikan bahwa hanya pod dengan toleransi eksplisit yang dapat menggunakan sumber daya Zona Lokal yang berpotensi mahal.
1. **Penempatan Terjamin**: Afinitas node memastikan bahwa aplikasi sensitif latensi Anda berjalan secara eksklusif di Zona Lokal, bukan pada node cluster biasa.
Berikut adalah contoh Deployment yang dikonfigurasi untuk dijalankan secara khusus pada node Local Zone:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: low-latency-app
namespace: default
spec:
replicas: 2
selector:
matchLabels:
app: low-latency-app
template:
metadata:
labels:
app: low-latency-app
spec:
tolerations:
- key: "aws.amazon.com/local-zone"
operator: "Equal"
value: "true"
effect: "NoSchedule"
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "node-type"
operator: "In"
values: ["local-zone"]
containers:
- name: application
image: my-low-latency-app:latest
resources:
limits:
cpu: "1"
memory: "1Gi"
requests:
cpu: "500m"
memory: "512Mi"
```
Deployment ini memiliki dua konfigurasi penjadwalan utama:
1. **Toleransi** memungkinkan pod dijadwalkan pada node dengan `aws.amazon.com/local-zone` taint.
1. Persyaratan **afinitas node** memastikan pod ini hanya akan berjalan pada node dengan label`node-type: local-zone`.
Bersama-sama, ini memastikan bahwa aplikasi sensitif latensi Anda hanya berjalan pada node Zona Lokal, dan aplikasi reguler tidak menggunakan sumber daya Zona Lokal kecuali secara eksplisit dikonfigurasi untuk melakukannya.
## Langkah 5: Verifikasi dengan AWS Konsol
Setelah menyiapkan NodeClass, NodePool, dan Deployment, Anda harus memverifikasi bahwa node sedang disediakan di Zona Lokal Anda seperti yang diharapkan dan bahwa beban kerja Anda berjalan pada mereka. Anda dapat menggunakan AWS Management Console untuk memverifikasi bahwa EC2 instance sedang diluncurkan di subnet Zona Lokal yang benar.
Selain itu, Anda dapat memeriksa daftar node Kubernetes menggunakan `kubectl get nodes -o wide` untuk mengonfirmasi bahwa node bergabung dengan cluster Anda dengan label dan taint yang benar:
```
kubectl get nodes -o wide
kubectl describe node | grep -A 5 Taints
```
Anda juga dapat memverifikasi bahwa Pod beban kerja Anda dijadwalkan pada node Zona Lokal:
```
kubectl get pods -o wide
```
Pendekatan ini memastikan bahwa hanya beban kerja yang secara khusus mentolerir noda Zona Lokal yang akan dijadwalkan pada node ini, membantu Anda mengontrol biaya dan memanfaatkan sumber daya Zona Lokal Anda dengan seefisien mungkin.
# Konfigurasikan pengaturan keamanan lanjutan untuk node
Topik ini menjelaskan cara mengonfigurasi pengaturan keamanan lanjutan untuk node Mode Otomatis Amazon EKS menggunakan `advancedSecurity` spesifikasi di Kelas Node Anda.
## Prasyarat
Sebelum Anda mulai, pastikan Anda memiliki:
+ Cluster Mode Otomatis Amazon EKS. Untuk informasi selengkapnya, lihat [Buat cluster dengan Amazon EKS Auto Mode](create-auto.md).
+ `kubectl`diinstal dan dikonfigurasi. Untuk informasi selengkapnya, lihat [Siapkan untuk menggunakan Amazon EKS](setting-up.md).
+ Memahami konfigurasi Kelas Node. Untuk informasi selengkapnya, lihat [Buat Kelas Node untuk Amazon EKS](create-node-class.md).
## Konfigurasikan pengaturan keamanan lanjutan
Untuk mengonfigurasi pengaturan keamanan lanjutan untuk node Anda, atur `advancedSecurity` bidang dalam spesifikasi Kelas Node Anda:
```
apiVersion: eks.amazonaws.com/v1
kind: NodeClass
metadata:
name: security-hardened
spec:
role: MyNodeRole
subnetSelectorTerms:
- tags:
Name: "private-subnet"
securityGroupSelectorTerms:
- tags:
Name: "eks-cluster-sg"
advancedSecurity:
# Enable FIPS-compliant AMIs (US regions only)
fips: true
# Configure kernel lockdown mode
kernelLockdown: "integrity"
```
Terapkan konfigurasi ini:
```
kubectl apply -f nodeclass.yaml
```
Referensi Kelas Node ini dalam konfigurasi Node Pool Anda. Untuk informasi selengkapnya, lihat [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md).
## Deskripsi bidang
+ `fips`(boolean, opsional): Ketika diatur ke`true`, ketentuan node menggunakan AMIs dengan modul kriptografi yang divalidasi FIPS 140-2. Pengaturan ini memilih FIPS-compliant AMIs; pelanggan bertanggung jawab untuk mengelola persyaratan kepatuhan mereka. Untuk informasi selengkapnya, lihat [kepatuhan AWS FIPS](https://aws.amazon.com/compliance/fips/). Default: `false`.
+ `kernelLockdown`(string, opsional): Mengontrol mode modul keamanan penguncian kernel. Nilai yang diterima:
+ `integrity`: Memblokir metode untuk menimpa memori kernel atau memodifikasi kode kernel. Mencegah pemuatan modul kernel yang tidak ditandatangani.
+ `none`: Menonaktifkan perlindungan penguncian kernel.
Untuk informasi selengkapnya, lihat [dokumentasi penguncian kernel Linux](https://man7.org/linux/man-pages/man7/kernel_lockdown.7.html).
## Pertimbangan-pertimbangan
+ Sesuai FIPS AMIs tersedia di Wilayah Timur/Barat AWS AS, ( AWS GovCloud AS), dan Kanada AWS (Tengah/Barat). Untuk informasi selengkapnya, lihat [kepatuhan AWS FIPS](https://aws.amazon.com/compliance/fips/).
+ Saat menggunakan`kernelLockdown: "integrity"`, pastikan beban kerja Anda tidak memerlukan pemuatan modul kernel yang tidak ditandatangani atau memodifikasi memori kernel.
## Sumber daya terkait
+ [Buat Kelas Node untuk Amazon EKS](create-node-class.md)- Panduan konfigurasi Kelas Node Lengkap
+ [Buat Node Pool untuk Mode Otomatis EKS](create-node-pool.md)- Konfigurasi Node Pool