Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Karpenter
**Tip**
[Jelajahi](https://aws-experience.com/emea/smb/events/series/get-hands-on-with-amazon-eks?trk=4a9b4147-2490-4c63-bc9f-f8a84b122c8c&sc_channel=el) praktik terbaik melalui lokakarya Amazon EKS.
[Karpenter](https://karpenter.sh/) adalah proyek sumber terbuka yang dirancang untuk meningkatkan manajemen siklus hidup node dalam klaster Kubernetes. Ini mengotomatiskan penyediaan dan deprovisioning node berdasarkan kebutuhan penjadwalan spesifik pod, memungkinkan penskalaan yang efisien dan pengoptimalan biaya. Fungsi utamanya adalah:
+ Pantau pod yang tidak dapat dijadwalkan oleh penjadwal Kubernetes karena kendala sumber daya.
+ Evaluasi persyaratan penjadwalan (permintaan sumber daya, pemilih node, afinitas, toleransi, dll.) dari Pod yang tidak dapat dijadwalkan.
+ Menyediakan node baru yang memenuhi persyaratan pod tersebut.
+ Hapus node saat tidak lagi dibutuhkan.
Dengan Karpenter, Anda dapat menentukan NodePools dengan batasan pada penyediaan node seperti taints, label, persyaratan (tipe instance, zona, dll.), Dan batasan total sumber daya yang disediakan. Saat menerapkan beban kerja, Anda dapat menentukan berbagai kendala penjadwalan dalam spesifikasi pod seperti requests/limits, node selectors, node/pod afinitas sumber daya, toleransi, dan batasan penyebaran topologi. Karpenter kemudian akan menyediakan node berukuran tepat berdasarkan spesifikasi ini.
**Alasan menggunakan Karpenter**
Sebelum peluncuran Karpenter, pengguna Kubernetes mengandalkan terutama pada grup [Amazon EC2 Auto Scaling dan Kubernetes Cluster Autoscaler (CAS](https://docs.aws.amazon.com/autoscaling/ec2/userguide/AutoScalingGroup.html)[) untuk secara dinamis menyesuaikan kapasitas komputasi klaster](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler) mereka. Dengan Karpenter, Anda tidak perlu membuat lusinan grup simpul untuk mencapai fleksibilitas dan keragaman yang Anda dapatkan dengan Karpenter. Tidak seperti CAS, Karpenter tidak digabungkan erat dengan versi Kubernetes dan tidak mengharuskan Anda untuk melompat antara AWS dan Kubernetes. APIs
Karpenter mengkonsolidasikan tanggung jawab orkestrasi instance dalam satu sistem, yang lebih sederhana, lebih stabil, dan sadar cluster. Karpenter dirancang untuk mengatasi beberapa tantangan yang disajikan oleh Cluster Autoscaler dengan menyediakan cara yang disederhanakan untuk:
+ Node penyediaan berdasarkan persyaratan beban kerja.
+ Buat konfigurasi node yang beragam berdasarkan jenis instance, menggunakan NodePool opsi fleksibel. Alih-alih mengelola banyak grup node khusus tertentu, Karpenter dapat membiarkan Anda mengelola kapasitas beban kerja yang beragam dengan satu, fleksibel. NodePool
+ Raih penjadwalan pod yang ditingkatkan dalam skala besar dengan meluncurkan node dan menjadwalkan pod dengan cepat.
Untuk informasi dan dokumentasi tentang penggunaan Karpenter, kunjungi situs [karpenter.sh](https://karpenter.sh/).
## Rekomendasi
Praktik terbaik dibagi menjadi beberapa bagian tentang Karpenter itu sendiri, NodePools, dan penjadwalan pod.
## Praktik terbaik Karpenter
Praktik terbaik berikut mencakup topik yang berkaitan dengan Karpenter itu sendiri.
### Kunci AMIs di cluster produksi
Kami sangat menyarankan Anda menyematkan Gambar Mesin Amazon (AMIs) yang terkenal yang digunakan oleh Karpenter untuk kluster produksi. Menggunakan `amiSelector` dengan alias yang disetel ke`@latest`, atau menggunakan beberapa metode lain yang menghasilkan penerapan yang belum teruji AMIs saat dirilis, menawarkan risiko kegagalan beban kerja dan waktu henti di kluster produksi Anda. Sebagai hasilnya, kami sangat menyarankan untuk menyematkan versi kerja yang telah diuji AMIs untuk kluster produksi Anda saat Anda menguji versi yang lebih baru di kluster non-produksi. Misalnya, Anda dapat menetapkan alias di Anda NodeClass sebagai berikut:
```
amiSelectorTerms
- alias: al2023@v20240807
```
Untuk informasi tentang mengelola dan menyematkan AMIs di Karpenter, lihat [Mengelola AMIs](https://karpenter.sh/docs/tasks/managing-amis/) dalam dokumentasi Karpenter.
### Gunakan Karpenter untuk beban kerja dengan kebutuhan kapasitas yang berubah
[Karpenter membawa manajemen penskalaan lebih dekat ke Kubernetes native APIs daripada [Autoscaling Groups () dan Managed Node Groups](https://aws.amazon.com/blogs/containers/amazon-eks-cluster-multi-zone-auto-scaling-groups/) (ASGsMNG).](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html) ASG dan MNG adalah abstraksi asli AWS di mana penskalaan dipicu berdasarkan metrik level AWS, seperti beban CPU EC2. [Cluster Autoscaler](https://docs.aws.amazon.com/eks/latest/userguide/autoscaling.html#cluster-autoscaler) menjembatani abstraksi Kubernetes ke dalam abstraksi AWS, tetapi kehilangan beberapa fleksibilitas karena itu, seperti penjadwalan untuk zona ketersediaan tertentu.
Karpenter menghapus lapisan abstraksi AWS untuk membawa beberapa fleksibilitas langsung ke Kubernetes. Karpenter paling baik digunakan untuk cluster dengan beban kerja yang menghadapi periode permintaan tinggi dan runcing atau memiliki persyaratan komputasi yang beragam. MNGs dan ASGs bagus untuk cluster yang menjalankan beban kerja yang cenderung lebih statis dan konsisten. Anda dapat menggunakan campuran node yang dikelola secara dinamis dan statis, tergantung pada kebutuhan Anda.
### Pertimbangkan proyek penskalaan otomatis lainnya ketika...
Anda membutuhkan fitur yang masih dikembangkan di Karpenter. Karena Karpenter adalah proyek yang relatif baru, pertimbangkan proyek penskalaan otomatis lainnya untuk saat ini jika Anda membutuhkan fitur yang belum menjadi bagian dari Karpenter.
### Jalankan pengontrol Karpenter di EKS Fargate atau pada node pekerja yang termasuk dalam grup node
Karpenter diinstal menggunakan bagan [Helm](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#4-install-karpenter). Bagan Helm menginstal pengontrol Karpenter dan pod webhook sebagai Deployment yang perlu dijalankan sebelum controller dapat digunakan untuk penskalaan cluster Anda. Kami merekomendasikan minimal satu grup node kecil dengan setidaknya satu node pekerja. Sebagai alternatif, Anda dapat menjalankan pod ini di EKS Fargate dengan membuat profil Fargate untuk namespace. `karpenter` Melakukannya akan menyebabkan semua pod yang diterapkan ke namespace ini berjalan di EKS Fargate. Jangan menjalankan Karpenter pada node yang dikelola oleh Karpenter.
### Tidak ada dukungan template peluncuran khusus dengan Karpenter
Tidak ada dukungan template peluncuran khusus dengan v1 APIs. Anda dapat menggunakan data pengguna kustom and/or secara langsung menentukan kustom AMIs di. EC2 NodeClass Informasi lebih lanjut tentang cara melakukan ini tersedia di [NodeClasses](https://karpenter.sh/docs/concepts/nodeclasses/).
### Kecualikan jenis instans yang tidak sesuai dengan beban kerja Anda
Pertimbangkan untuk mengecualikan jenis instance tertentu dengan `node.kubernetes.io/instance-type` kunci jika tidak diperlukan oleh beban kerja yang berjalan di klaster Anda.
Contoh berikut menunjukkan bagaimana menghindari penyediaan instance Graviton besar.
```
- key: node.kubernetes.io/instance-type
operator: NotIn
values:
- m6g.16xlarge
- m6gd.16xlarge
- r6g.16xlarge
- r6gd.16xlarge
- c6g.16xlarge
```
### Aktifkan Penanganan Gangguan saat menggunakan Spot
Karpenter mendukung [penanganan interupsi asli](https://karpenter.sh/docs/concepts/disruption/#interruption) dan dapat menangani peristiwa interupsi yang tidak disengaja seperti interupsi Instans Spot, peristiwa pemeliharaan terjadwal, penghentian/penghentian instance peristiwa yang dapat mengganggu beban kerja Anda. Ketika Karpenter mendeteksi peristiwa semacam itu untuk node, ia secara otomatis menodai, menguras, dan menghentikan node yang terpengaruh sebelumnya untuk memulai pembersihan beban kerja yang anggun sebelum gangguan. Untuk interupsi Spot dengan pemberitahuan 2 menit, Karpenter dengan cepat memulai node baru sehingga pod dapat dipindahkan sebelum instance direklamasi. Untuk mengaktifkan penanganan interupsi, Anda mengonfigurasi argumen `--interruption-queue` CLI dengan nama antrian SQS yang disediakan untuk tujuan ini. [Tidak disarankan untuk menggunakan penanganan interupsi Karpenter bersama Node Termination Handler seperti yang dijelaskan di sini.](https://karpenter.sh/docs/faq/#interruption-handling)
Pod yang memerlukan checkpointing atau bentuk lain dari pengeringan yang anggun, membutuhkan waktu 2 menit sebelum shutdown harus memungkinkan penanganan interupsi Karpenter di klaster mereka.
### **Cluster pribadi Amazon EKS tanpa akses internet keluar**
Saat menyediakan Kluster EKS ke dalam VPC tanpa rute ke internet, Anda harus memastikan bahwa Anda telah mengonfigurasi lingkungan Anda sesuai dengan [persyaratan](https://docs.aws.amazon.com/eks/latest/userguide/private-clusters.html#private-cluster-requirements) klaster pribadi yang muncul dalam dokumentasi EKS. Selain itu, Anda perlu memastikan bahwa Anda telah membuat titik akhir regional STS VPC di VPC Anda. Jika tidak, Anda akan melihat kesalahan yang mirip dengan yang muncul di bawah ini.
```
{"level":"FATAL","time":"2024-02-29T14:28:34.392Z","logger":"controller","message":"Checking EC2 API connectivity, WebIdentityErr: failed to retrieve credentials\ncaused by: RequestError: send request failed\ncaused by: Post \"https://sts..amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}
```
Perubahan ini diperlukan dalam cluster pribadi karena Karpenter Controller menggunakan IAM Roles for Service Accounts (IRSA). Pod yang dikonfigurasi dengan IRSA memperoleh kredensyal dengan memanggil AWS Security Token Service (AWS STS) API. Jika tidak ada akses internet keluar, Anda harus membuat dan menggunakan titik ***akhir AWS STS VPC di VPC*** Anda.
Cluster pribadi juga mengharuskan Anda untuk membuat titik ***akhir VPC*** untuk SSM. Ketika Karpenter mencoba menyediakan node baru, ia menanyakan konfigurasi template Launch dan parameter SSM. Jika Anda tidak memiliki titik akhir VPC SSM di VPC Anda, itu akan menyebabkan kesalahan berikut:
```
{"level":"ERROR","time":"2024-02-29T14:28:12.889Z","logger":"controller","message":"Unable to hydrate the AWS launch template cache, RequestCanceled: request context canceled\ncaused by: context canceled","commit":"596ea97","tag-key":"karpenter.k8s.aws/cluster","tag-value":"eks-workshop"}
...
{"level":"ERROR","time":"2024-02-29T15:08:58.869Z","logger":"controller.nodeclass","message":"discovering amis from ssm, getting ssm parameter \"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id\", RequestError: send request failed\ncaused by: Post \"https://ssm..amazonaws.com/\": dial tcp 67.220.228.252:443: i/o timeout","commit":"596ea97","ec2nodeclass":"default","query":"/aws/service/eks/optimized-ami/1.27/amazon-linux-2/recommended/image_id"}
```
Tidak ada ***titik akhir VPC untuk API Kueri [Daftar Harga](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/using-pelong.html)***. Akibatnya, data harga akan basi seiring waktu. Karpenter menyiasatinya dengan memasukkan data harga sesuai permintaan dalam binernya, tetapi hanya memperbarui data itu ketika Karpenter ditingkatkan. Permintaan data harga yang gagal akan menghasilkan pesan galat berikut:
```
{"level":"ERROR","time":"2024-02-29T15:08:58.522Z","logger":"controller.pricing","message":"retreiving on-demand pricing data, RequestError: send request failed\ncaused by: Post \"https://api.pricing..amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing..amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}
```
Lihat [dokumentasi](https://karpenter.sh/docs/getting-started/getting-started-with-karpenter/#private-clusters) ini untuk menggunakan Karpenter dalam Kluster EKS yang sepenuhnya Pribadi dan untuk mengetahui titik akhir VPC mana yang akan dibuat.
## Menciptakan NodePools
Praktik terbaik berikut mencakup topik yang terkait dengan pembuatan NodePools.
### Buat beberapa NodePools saat...
Ketika tim yang berbeda berbagi cluster dan perlu menjalankan beban kerja mereka pada node pekerja yang berbeda, atau memiliki persyaratan OS atau tipe instans yang berbeda, buat beberapa NodePools. Misalnya, satu tim mungkin ingin menggunakan Bottlerocket, sementara yang lain mungkin ingin menggunakan Amazon Linux. Demikian juga, satu tim mungkin memiliki akses ke perangkat keras GPU mahal yang tidak akan dibutuhkan oleh tim lain. Menggunakan beberapa NodePools memastikan bahwa aset yang paling tepat tersedia untuk setiap tim.
### Buat NodePools yang saling eksklusif atau berbobot
Disarankan untuk membuat NodePools yang saling eksklusif atau berbobot untuk memberikan perilaku penjadwalan yang konsisten. Jika tidak dan beberapa NodePools dicocokkan, Karpenter akan secara acak memilih mana yang akan digunakan, menyebabkan hasil yang tidak terduga. Contoh yang berguna untuk membuat beberapa NodePools termasuk yang berikut:
Membuat NodePool dengan GPU dan hanya mengizinkan beban kerja khusus berjalan pada node (mahal) ini:
```
# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: gpu
spec:
disruption:
consolidateAfter: 1m
consolidationPolicy: WhenEmptyOrUnderutilized
template:
metadata: {}
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
expireAfter: Never
requirements:
- key: node.kubernetes.io/instance-type
operator: In
values:
- p3.8xlarge
- p3.16xlarge
- key: kubernetes.io/os
operator: In
values:
- linux
- key: kubernetes.io/arch
operator: In
values:
- amd64
- key: karpenter.sh/capacity-type
operator: In
values:
- on-demand
taints:
- effect: NoSchedule
key: nvidia.com/gpu
value: "true"
```
Penerapan dengan toleransi untuk noda:
```
# Deployment of GPU Workload will have tolerations defined
apiVersion: apps/v1
kind: Deployment
metadata:
name: inflate-gpu
spec:
spec:
tolerations:
- key: "nvidia.com/gpu"
operator: "Exists"
effect: "NoSchedule"
```
Untuk penerapan umum untuk tim lain, NodePool spesifikasi dapat menyertakan NodeAffinity. Deployment kemudian dapat digunakan nodeSelectorTerms untuk mencocokkan`billing-team`.
```
# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1
kind: NodePool
metadata:
name: generalcompute
spec:
template:
metadata:
labels:
billing-team: my-team
spec:
nodeClassRef:
group: karpenter.k8s.aws
kind: EC2NodeClass
name: default
expireAfter: Never
requirements:
- key: node.kubernetes.io/instance-type
operator: In
values:
- m5.large
- m5.xlarge
- m5.2xlarge
- c5.large
- c5.xlarge
- c5a.large
- c5a.xlarge
- r5.large
- r5.xlarge
- key: kubernetes.io/os
operator: In
values:
- linux
- key: kubernetes.io/arch
operator: In
values:
- amd64
- key: karpenter.sh/capacity-type
operator: In
values:
- on-demand
```
Penerapan menggunakan NodeAffinity:
```
# Deployment will have spec.affinity.nodeAffinity defined
kind: Deployment
metadata:
name: workload-my-team
spec:
replicas: 200
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: "billing-team"
operator: "In"
values: ["my-team"]
```
### Gunakan timer (TTL) untuk menghapus node secara otomatis dari cluster
Anda dapat menggunakan timer pada node yang disediakan untuk mengatur kapan harus menghapus node yang tidak memiliki pod beban kerja atau telah mencapai waktu kedaluwarsa. Kedaluwarsa node dapat digunakan sebagai sarana upgrade, sehingga node dihentikan dan diganti dengan versi yang diperbarui. Lihat [Kedaluwarsa](https://karpenter.sh/docs/concepts/disruption/) dalam dokumentasi Karpenter untuk informasi tentang penggunaan untuk mengonfigurasi `spec.template.spec` kedaluwarsa node.
### Hindari terlalu membatasi Jenis Instance yang dapat disediakan Karpenter, terutama saat menggunakan Spot
Saat menggunakan Spot, Karpenter menggunakan strategi alokasi [Price Capacity Optimized](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-fleet-allocation-strategy.html) untuk menyediakan instans EC2. Strategi ini menginstruksikan EC2 untuk menyediakan instance dari kumpulan terdalam untuk jumlah instance yang Anda luncurkan dan memiliki risiko gangguan terendah. Armada EC2 kemudian meminta instans Spot dari harga terendah dari kumpulan ini. Semakin banyak jenis instans yang Anda izinkan Karpenter gunakan, semakin baik EC2 dapat mengoptimalkan runtime instans spot Anda. Secara default, Karpenter akan menggunakan semua jenis instans yang ditawarkan EC2 di wilayah dan zona ketersediaan kluster Anda digunakan. Karpenter secara cerdas memilih dari kumpulan semua jenis instance berdasarkan pod yang tertunda untuk memastikan pod Anda dijadwalkan ke instance yang berukuran dan dilengkapi dengan tepat. Misalnya, jika pod Anda tidak memerlukan GPU, Karpenter tidak akan menjadwalkan pod Anda ke jenis instans EC2 yang mendukung GPU. Jika tidak yakin jenis instans mana yang akan digunakan, Anda dapat menjalankan Amazon [ec2-instance-selector](https://github.com/aws/amazon-ec2-instance-selector) untuk membuat daftar jenis instance yang sesuai dengan persyaratan komputasi Anda. Misalnya, CLI mengambil memori vCPU, arsitektur, dan wilayah sebagai parameter input dan memberi Anda daftar instans EC2 yang memenuhi batasan tersebut.
```
$ ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 -r ap-southeast-1
c5.large
c5a.large
c5ad.large
c5d.large
c6i.large
t2.medium
t3.medium
t3a.medium
```
Anda tidak boleh menempatkan terlalu banyak kendala pada Karpenter saat menggunakan instance Spot karena hal itu dapat memengaruhi ketersediaan aplikasi Anda. Katakanlah, misalnya, semua contoh dari jenis tertentu direklamasi dan tidak ada alternatif yang cocok yang tersedia untuk menggantikannya. Pod Anda akan tetap dalam status tertunda hingga kapasitas spot untuk tipe instance yang dikonfigurasi diisi ulang. Anda dapat mengurangi risiko kesalahan kapasitas yang tidak mencukupi dengan menyebarkan instans Anda di berbagai zona ketersediaan, karena kumpulan spot berbeda di seluruh AZs area. Meskipun demikian, praktik terbaik umum adalah mengizinkan Karpenter menggunakan beragam jenis instance saat menggunakan Spot.
## Penjadwalan Pod
Praktik terbaik berikut ini berkaitan dengan penerapan Pod Dalam klaster yang menggunakan Karpenter untuk penyediaan node.
### Ikuti praktik terbaik EKS untuk ketersediaan tinggi
Jika Anda perlu menjalankan aplikasi yang sangat tersedia, ikuti [rekomendasi](https://docs.aws.amazon.com/eks/latest/best-practices/application.html#_recommendations) praktik terbaik EKS umum. Lihat [Topologi Spread](https://karpenter.sh/docs/concepts/scheduling/#topology-spread) di dokumentasi Karpenter untuk detail tentang cara menyebarkan pod di seluruh node dan zona. Gunakan [Anggaran Gangguan](https://karpenter.sh/docs/troubleshooting/#disruption-budgets) untuk mengatur minimum pod yang tersedia yang perlu dipertahankan, jika ada upaya untuk mengusir atau menghapus pod.
### Gunakan Kendala berlapis untuk membatasi fitur komputasi yang tersedia dari penyedia cloud Anda
Model kendala berlapis Karpenter memungkinkan Anda membuat serangkaian kendala penerapan NodePool dan pod yang kompleks untuk mendapatkan kecocokan terbaik untuk penjadwalan pod. Contoh kendala yang dapat diminta oleh spesifikasi pod meliputi:
+ Perlu berjalan di zona ketersediaan di mana hanya aplikasi tertentu yang tersedia. Misalnya, Anda memiliki pod yang harus berkomunikasi dengan aplikasi lain yang berjalan pada instans EC2 yang berada di zona ketersediaan tertentu. Jika tujuan Anda adalah untuk mengurangi lalu lintas lintas lintas AZ di VPC Anda, Anda mungkin ingin menempatkan pod bersama di AZ tempat instans EC2 berada. Penargetan semacam ini sering dilakukan dengan menggunakan pemilih node. Untuk informasi tambahan tentang [pemilih Node](https://karpenter.sh/docs/concepts/scheduling/#selecting-nodes), silakan merujuk ke dokumentasi Kubernetes.
+ Membutuhkan beberapa jenis prosesor atau perangkat keras lainnya. Lihat bagian [Accelerators](https://karpenter.sh/docs/concepts/scheduling/#acceleratorsgpu-resources) dari dokumen Karpenter untuk contoh spesifikasi pod yang mengharuskan pod berjalan pada GPU.
### Buat alarm penagihan untuk memantau pengeluaran komputasi Anda
Ketika Anda mengonfigurasi klaster Anda untuk skala otomatis, Anda harus membuat alarm penagihan untuk memperingatkan Anda ketika pengeluaran Anda telah melampaui ambang batas dan menambahkan batas sumber daya ke konfigurasi Karpenter Anda. Menetapkan batas sumber daya dengan Karpenter mirip dengan menetapkan kapasitas maksimum grup penskalaan otomatis AWS karena mewakili jumlah maksimum sumber daya komputasi yang dapat digunakan oleh Karpenter. NodePool
**catatan**
Tidak mungkin menetapkan batas global untuk seluruh cluster. Batas berlaku untuk spesifik NodePools.
Cuplikan di bawah ini memberi tahu Karpenter untuk hanya menyediakan maksimum 1000 core CPU dan 1000Gi memori. Karpenter akan berhenti menambah kapasitas hanya ketika batas terpenuhi atau terlampaui. Ketika batas terlampaui, pengontrol Karpenter akan menulis `memory resource usage of 1001 exceeds limit of 1000` atau pesan yang mirip dengan log pengontrol. Jika Anda merutekan log kontainer Anda ke CloudWatch log, Anda dapat membuat [filter metrik](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/MonitoringLogData.html) untuk mencari pola atau istilah tertentu dalam log Anda dan kemudian membuat [CloudWatchalarm](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html) untuk mengingatkan Anda ketika ambang metrik yang dikonfigurasi dilanggar.
Untuk informasi lebih lanjut menggunakan limit dengan Karpenter, lihat [Menetapkan Batas Sumber Daya dalam dokumentasi](https://karpenter.sh/docs/concepts/nodepools/#speclimits) Karpenter.
```
spec:
limits:
cpu: 1000
memory: 1000Gi
```
Jika Anda tidak menggunakan batas atau membatasi jenis instance yang dapat disediakan Karpenter, Karpenter akan terus menambahkan kapasitas komputasi ke cluster Anda sesuai kebutuhan. Meskipun mengonfigurasi Karpenter dengan cara ini memungkinkan klaster Anda untuk menskalakan secara bebas, itu juga dapat memiliki implikasi biaya yang signifikan. Karena alasan inilah kami merekomendasikan untuk mengonfigurasi alarm penagihan. Alarm penagihan memungkinkan Anda untuk diperingatkan dan diberitahukan secara proaktif ketika perkiraan biaya yang dihitung di akun Anda melebihi ambang batas yang ditentukan. Lihat [Menyiapkan Alarm CloudWatch Penagihan Amazon untuk Memantau Perkiraan Biaya Secara Proaktif](https://aws.amazon.com/blogs/mt/setting-up-an-amazon-cloudwatch-billing-alarm-to-proactively-monitor-estimated-charges/) untuk informasi tambahan.
Anda mungkin juga ingin mengaktifkan Deteksi Anomali Biaya yang merupakan fitur AWS Cost Management yang menggunakan pembelajaran mesin untuk terus memantau biaya dan penggunaan Anda untuk mendeteksi pengeluaran yang tidak biasa. Informasi lebih lanjut dapat ditemukan di panduan [Memulai Deteksi Anomali Biaya AWS](https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html). Jika Anda telah membuat anggaran di AWS Budgets, Anda juga dapat mengonfigurasi tindakan untuk memberi tahu Anda ketika ambang batas tertentu telah dilanggar. Dengan tindakan anggaran, Anda dapat mengirim email, mengirim pesan ke topik SNS, atau mengirim pesan ke chatbot seperti Slack. Untuk informasi lebih lanjut, lihat [Mengonfigurasi tindakan AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-controls.html).
### Gunakan do-not-disrupt anotasi karpenter.sh/ untuk mencegah Karpenter dari deprovisioning node
Jika Anda menjalankan aplikasi penting pada node yang disediakan Karpenter, seperti pekerjaan batch yang *berjalan lama* atau aplikasi stateful, *dan* TTL node telah kedaluwarsa, aplikasi akan terganggu saat instance dihentikan. Dengan menambahkan `karpenter.sh/do-not-disrupt` anotasi ke pod, Anda menginstruksikan Karpenter untuk mempertahankan node sampai Pod dihentikan atau anotasi dihapus. `karpenter.sh/do-not-disrupt` Lihat dokumentasi [Distruption](https://karpenter.sh/docs/concepts/disruption/#node-level-controls) untuk informasi lebih lanjut.
Jika satu-satunya pod non-daemonset yang tersisa di node adalah yang terkait dengan pekerjaan, Karpenter dapat menargetkan dan menghentikan node tersebut selama status pekerjaan berhasil atau gagal.
### Konfigurasikan requests=limits untuk semua sumber daya non-CPU saat menggunakan konsolidasi
Konsolidasi dan penjadwalan secara umum bekerja dengan membandingkan permintaan sumber daya pod vs jumlah sumber daya yang dapat dialokasikan pada sebuah node. Batas sumber daya tidak dipertimbangkan. Sebagai contoh, pod yang memiliki batas memori yang lebih besar dari permintaan memori dapat meledak di atas permintaan. Jika beberapa pod pada node yang sama meledak pada saat yang sama, ini dapat menyebabkan beberapa pod dihentikan karena kondisi out of memory (OOM). Konsolidasi dapat membuat ini lebih mungkin terjadi karena berfungsi untuk mengemas pod ke node hanya dengan mempertimbangkan permintaannya.
### Gunakan LimitRanges untuk mengonfigurasi default untuk permintaan dan batasan sumber daya
Karena Kubernetes tidak menetapkan permintaan atau batasan default, konsumsi sumber daya kontainer dari host, CPU, dan memori yang mendasarinya tidak terikat. Penjadwal Kubernetes melihat total permintaan sebuah pod (jumlah permintaan yang lebih tinggi dari kontainer pod atau total sumber daya dari kontainer Init pod) untuk menentukan node pekerja mana yang akan menjadwalkan pod tersebut. Demikian pula, Karpenter mempertimbangkan permintaan pod untuk menentukan jenis instance yang disediakannya. Anda dapat menggunakan rentang batas untuk menerapkan default yang masuk akal untuk namespace, jika permintaan sumber daya tidak ditentukan oleh beberapa pod.
Lihat [Mengkonfigurasi Permintaan dan Batas Memori Default untuk Namespace](https://kubernetes.io/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)
### Terapkan permintaan sumber daya yang akurat ke semua beban kerja
Karpenter dapat meluncurkan node yang paling sesuai dengan beban kerja Anda ketika informasi tentang persyaratan beban kerja Anda akurat. Ini sangat penting jika menggunakan fitur konsolidasi Karpenter.
Lihat [Mengkonfigurasi dan Mengukur Sumber Daya Requests/Limits untuk semua Beban Kerja](https://docs.aws.amazon.com/eks/latest/best-practices/data-plane.html#_recommendations)
## Rekomendasi CoreDNS
### Perbarui konfigurasi CoreDNS untuk menjaga keandalan
Saat menerapkan pod CoreDNS pada node yang dikelola oleh Karpenter, mengingat sifat dinamis Karpenter dalam node baru yang terminating/creating cepat agar selaras dengan permintaan, disarankan untuk mematuhi praktik terbaik berikut:
[Durasi lameduck CoreDNS](https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_lameduck_duration)
[Penyelidikan kesiapan CoreDNS](https://docs.aws.amazon.com/eks/latest/best-practices/scale-cluster-services.html#_coredns_readiness_probe)
Ini akan memastikan bahwa query DNS tidak diarahkan ke Pod CoreDNS yang belum siap atau telah dihentikan.
## Cetak Biru Karpenter
Karena Karpenter mengambil pendekatan aplikasi-pertama untuk menyediakan kapasitas komputasi untuk bidang data Kubernetes, ada skenario beban kerja umum yang mungkin membuat Anda bertanya-tanya bagaimana mengonfigurasinya dengan benar. [Karpenter Blueprints](https://github.com/aws-ia/terraform-aws-eks-blueprints-addons) adalah repositori yang mencakup daftar skenario beban kerja umum mengikuti praktik terbaik yang dijelaskan di sini. Anda akan memiliki semua sumber daya yang Anda butuhkan untuk membuat cluster EKS dengan Karpenter yang dikonfigurasi, dan menguji setiap cetak biru yang disertakan dalam repositori. Anda dapat menggabungkan cetak biru yang berbeda untuk akhirnya membuat yang Anda butuhkan untuk beban kerja Anda.
## Sumber Daya Tambahan
+ [Lokakarya Hari Perendaman Karpenter](https://catalog.workshops.aws/karpenter/en-US)
+ [Lokakarya Optimalisasi Biaya Karpenter](https://ec2spotworkshops.com/karpenter.html)
+ [Lokakarya EKS - Karpenter](https://www.eksworkshop.com/docs/autoscaling/compute/karpenter/)
+ [Karpenter vs Cluster Autoscaler](https://youtu.be/FIBc8GkjFU0)
+ [Sesi Karpenter di re:Invent 2023](https://youtu.be/lkg_9ETHeks)
+ [Tutorial: Jalankan Kubernetes Clusters dengan Harga Lebih Murah dengan Amazon EC2 Spot dan Karpenter](https://community.aws/tutorials/run-kubernetes-clusters-for-less-with-amazon-ec2-spot-and-karpenter#step-6-optional-simulate-spot-interruption)