Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Karpenter

Karpenter adalah proyek open-source yang menyediakan manajemen siklus hidup node untuk klaster Kubernetes. Ini mengotomatiskan penyediaan dan deprovisioning node berdasarkan kebutuhan penjadwalan pod, memungkinkan penskalaan yang efisien dan pengoptimalan biaya. Fungsi utamanya adalah:

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 batasan 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 untuk pod tersebut.

Alasan menggunakan Karpenter

Sebelum peluncuran Karpenter, pengguna Kubernetes mengandalkan terutama pada grup Auto Scaling EC2 Amazon dan Kubernetes Cluster Autoscaler () untuk secara dinamis menyesuaikan kapasitas komputasi klaster mereka. CAS Dengan Karpenter, Anda tidak perlu membuat lusinan grup simpul untuk mencapai fleksibilitas dan keragaman yang Anda dapatkan dengan Karpenter. Selain itu, Karpenter tidak digabungkan erat dengan versi Kubernetes (sebagaimana adanya) dan tidak mengharuskan Anda untuk CAS melompat antara dan Kubernetes. AWS 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:

Untuk informasi dan dokumentasi tentang penggunaan Karpenter, kunjungi situs 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.

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 (). ASGs MNGs ASGsdan MNGs merupakan abstraksi AWS -native di mana penskalaan dipicu berdasarkan metrik AWS level, seperti load. EC2 CPU Cluster Autoscaler menjembatani abstraksi Kubernetes menjadi AWS abstraksi, tetapi kehilangan beberapa fleksibilitas karena itu, seperti penjadwalan untuk zona ketersediaan tertentu.

Karpenter menghapus lapisan AWS abstraksi 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. MNGsdan 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. 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 Fargate. EKS Jangan menjalankan Karpenter pada node yang dikelola oleh Karpenter.

Tidak ada dukungan template peluncuran khusus dengan Karpenter

Tidak ada dukungan template peluncuran khusus dengan v1beta1 (v0.32 +)APIs. Anda dapat menggunakan data pengguna khusus dan/atau secara langsung menentukan kustom AMIs di. EC2NodeClass Informasi lebih lanjut tentang cara melakukan ini tersedia di 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 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 --interruption-queue CLI argumen dengan nama SQS antrian yang disediakan untuk tujuan ini. Tidak disarankan untuk menggunakan penanganan interupsi Karpenter bersama Node Termination Handler seperti yang dijelaskan di sini.

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 EKS pribadi Amazon tanpa akses internet keluar

Saat menyediakan EKS Cluster ke dalam VPC tanpa rute ke internet, Anda harus memastikan bahwa Anda telah mengonfigurasi lingkungan Anda sesuai dengan persyaratan klaster pribadi yang muncul dalam EKS dokumentasi. Selain itu, Anda perlu memastikan bahwa Anda telah membuat titik akhir STS VPC regional di AndaVPC. 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.<region>.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 kredensil dengan memanggil AWS Security Token Service () AWSSTS. API Jika tidak ada akses internet keluar, Anda harus membuat dan menggunakan AWSSTSVPCtitik akhir di situs Anda. VPC

Cluster pribadi juga mengharuskan Anda untuk membuat VPCtitik akhir untuk. SSM Ketika Karpenter mencoba menyediakan node baru, ia menanyakan konfigurasi template Launch dan parameter. SSM Jika Anda tidak memiliki SSM VPC titik akhir di AndaVPC, 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.<region>.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 VPCtitik akhir untuk Kueri API Daftar Harga. 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.<region>.amazonaws.com/\": dial tcp 18.196.224.8:443: i/o timeout; RequestError: send request failed\ncaused by: Post \"https://api.pricing.<region>.amazonaws.com/\": dial tcp 18.185.143.117:443: i/o timeout","commit":"596ea97"}

Lihat dokumentasi ini untuk menggunakan Karpenter dalam EKS Cluster Pribadi sepenuhnya dan untuk mengetahui VPC titik akhir 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 instance 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 GPU perangkat keras 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 untuk berjalan pada node (mahal) ini:

# NodePool for GPU Instances with Taints
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: gpu
spec:
  disruption:
    consolidateAfter: 1m0s
    consolidationPolicy: WhenEmpty
    expireAfter: Never
  template:
    metadata: {}
    spec:
      nodeClassRef:
        name: default
      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 disertakan. nodeAffinity Deployment kemudian dapat digunakan nodeSelectorTerms untuk mencocokkanbilling-team.

# NodePool for regular EC2 instances
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: generalcompute
spec:
  disruption:
    expireAfter: Never
  template:
    metadata:
      labels:
        billing-team: my-team
    spec:
      nodeClassRef:
        name: default
      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 menggunakannodeAffinity:

# 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 dalam dokumentasi Karpenter untuk informasi tentang penggunaan untuk mengonfigurasi spec.disruption.expireAfter 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 untuk menyediakan instance. EC2 Strategi ini menginstruksikan EC2 untuk menyediakan contoh dari kumpulan terdalam untuk jumlah contoh yang Anda luncurkan dan memiliki risiko gangguan terendah. EC2Fleet 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 EC2 penawaran Jenis Instance di wilayah dan zona ketersediaan yang digunakan klaster Anda. 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 aGPU, Karpenter tidak akan menjadwalkan pod Anda ke tipe EC2 instance yang mendukung a. GPU Jika tidak yakin jenis instans mana yang akan digunakan, Anda dapat menjalankan 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 EC2 instance 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. AZs 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 EKS terbaik untuk ketersediaan tinggi

Jika Anda perlu menjalankan aplikasi yang sangat tersedia, ikuti rekomendasi praktik EKS terbaik umum. Lihat Topologi Spread di dokumentasi Karpenter untuk detail tentang cara menyebarkan pod di seluruh node dan zona. Gunakan Anggaran Gangguan 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:

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 AWS penskalaan otomatis karena mewakili jumlah maksimum sumber daya komputasi yang dapat dipakai oleh Karpenter. NodePool

Cuplikan di bawah ini memberi tahu Karpenter untuk hanya menyediakan maksimum 1000 CPU core 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 untuk mencari pola atau istilah tertentu dalam log Anda dan kemudian membuat CloudWatchalarm untuk mengingatkan Anda ketika ambang metrik yang dikonfigurasi dilanggar.

Untuk informasi lebih lanjut menggunakan limit dengan Karpenter, lihat Menetapkan Batas Sumber Daya dalam dokumentasi 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 untuk informasi tambahan.

Anda mungkin juga ingin mengaktifkan Deteksi Anomali Biaya yang merupakan fitur Manajemen AWS Biaya 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 AWS Biaya. Jika Anda telah melangkah lebih jauh untuk membuat AWS anggaran di Anggaran, 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 SNS topik, atau mengirim pesan ke chatbot seperti Slack. Untuk informasi lebih lanjut, lihat Mengonfigurasi tindakan AWS Anggaran.

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 node TTL 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 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 CPU non-resource 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, hal 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 yang mendasarinya,CPU, dan memori 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 Mengonfigurasi Permintaan dan Batas Memori Default untuk 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 Permintaan/Batas Sumber Daya untuk semua Beban Kerja

DNSRekomendasi inti

Perbarui konfigurasi Core DNS untuk menjaga keandalan

Saat menerapkan DNS pod Core pada node yang dikelola oleh Karpenter, mengingat sifat dinamis Karpenter dalam menghentikan/membuat node baru dengan cepat agar selaras dengan permintaan, disarankan untuk mematuhi praktik terbaik berikut:

Durasi DNS lameduck inti

Probe DNS kesiapan inti

Ini akan memastikan bahwa DNS kueri tidak diarahkan ke Core DNS Pod 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 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 EKS cluster dengan Karpenter 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

📝 Edit halaman ini di GitHub