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 dirancang untuk meningkatkan manajemen siklus hidup node dalam cluster Kubernetes. Ini mengotomatiskan penyediaan dan deprovisioning node berdasarkan kebutuhan penjadwalan spesifik pod, memungkinkan penskalaan yang efisien dan pengoptimalan biaya. Fungsi utamanya adalah:

Dengan Karpenter, Anda dapat menentukan NodePools dengan batasan pada penyediaan node seperti noda, label, persyaratan (jenis instans, zona, dll.), dan batasan pada total sumber daya yang disediakan. Saat menerapkan beban kerja, Anda dapat menentukan berbagai batasan penjadwalan dalam spesifikasi pod seperti resource requests/limits, pemilih node, afinitas, toleransi, node/pod dan batasan penyebaran topologi. Karpenter kemudian akan menyediakan node berukuran tepat berdasarkan spesifikasi ini.

Alasan menggunakan Karpenter

Sebelum peluncuran Karpenter, pengguna Kubernetes terutama mengandalkan grup Amazon EC2 Auto Scaling dan Kubernetes Cluster Autoscaler (CAS) untuk secara dinamis menyesuaikan kapasitas komputasi cluster mereka. Dengan Karpenter, Anda tidak perlu membuat puluhan grup node untuk mencapai fleksibilitas dan keragaman yang Anda dapatkan dengan Karpenter. Tidak seperti CAS, Karpenter tidak digabungkan dengan versi Kubernetes dan tidak mengharuskan Anda untuk melompat antara AWS dan API Kubernetes.

Karpenter mengkonsolidasikan tanggung jawab orkestrasi instans 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 pada Karpenter itu sendiri, NodePools, dan penjadwalan pod.

Praktik terbaik Karpenter

Praktik terbaik berikut mencakup topik yang terkait dengan Karpenter itu sendiri.

Mengunci AMI di cluster produksi

Kami sangat menyarankan Anda menyematkan Gambar Mesin Amazon (AMI) terkenal yang digunakan oleh Karpenter untuk cluster produksi. Menggunakan amiSelector dengan alias yang diset @latest el ke, atau menggunakan beberapa metode lain yang menghasilkan penerapan AMI yang belum teruji saat dirilis, menawarkan risiko kegagalan beban kerja dan downtime di cluster produksi Anda. Oleh karena itu, kami sangat menyarankan untuk menyematkan versi kerja AMI yang telah diuji untuk cluster produksi Anda saat Anda menguji versi yang lebih baru di cluster non-produksi. Misalnya, Anda dapat mengatur alias di Anda NodeClass sebagai berikut:

amiSelectorTerms
  - alias: al2023@v20240807

Untuk informasi tentang mengelola dan menyematkan AMI di Karpenter, lihat Mengelola AMI di dokument asi Karpenter.

Gunakan Karpenter untuk beban kerja dengan kebutuhan kapasitas yang berubah

Karpenter membawa manajemen penskalaan lebih dekat ke API asli Kubernetes daripada Autoscaling Groups (ASGs) dan Managed Node Groups (MNG). ASG dan MNG adalah AWS-native abstraksi di mana penskalaan dipicu berdasarkan metrik tingkat AWS, seperti beban CPU EC2. Cluster Autoscaler men jembatani abstraksi Kubernetes ke 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. MNG dan ASG baik 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 saat...

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 pada 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 pengontrol dapat digunakan untuk menskalakan 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 digunakan 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 API v1. Anda dapat menggunakan data pengguna khusus and/or secara langsung menentukan AMI khusus 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 cluster Anda.

Contoh berikut menunjukkan cara menghindari penyediaan instans Graviton besar.

- key: node.kubernetes.io/instance-type
  operator: NotIn
  values:
  - m6g.16xlarge
  - m6gd.16xlarge
  - r6g.16xlarge
  - r6gd.16xlarge
  - c6g.16xlarge

Aktifkan Penanganan Interupsi saat menggunakan Spot

Karpenter mendukung penanganan interup si asli dan dapat menangani peristiwa interupsi yang tidak disengaja seperti interupsi Instance Spot, peristiwa pemeliharaan terjadwal, termination/stopping peristiwa instans yang dapat mengganggu beban kerja Anda. Ketika Karpenter mendeteksi peristiwa semacam itu untuk node, secara otomatis menodai, menguras, dan mengakhiri node yang terkena dampak sebelumnya untuk memulai pembersihan beban kerja dengan 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 gangguan Karpenter bersama Node Termination Handler seperti yang dijelaskan di sini.

Pod yang memerlukan checkpointing atau bentuk pengeringan anggun lainnya, yang membutuhkan waktu 2 menit sebelum shutdown harus memungkinkan penanganan interupsi Karpenter di klusternya.

Cluster pribadi Amazon EKS tanpa akses internet keluar

Saat menyediakan Cluster EKS ke VPC tanpa rute ke internet, Anda harus memastikan Anda telah mengonfigurasi lingkungan Anda sesuai dengan persyaratan cluster 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.<region>.amazonaws.com/\": dial tcp 54.239.32.126:443: i/o timeout","commit":"596ea97"}

Perubahan ini diperlukan dalam klaster pribadi karena Pengontrol Karpenter menggunakan Peran IAM untuk Akun Layanan (IRSA). Pod yang dikonfigurasi dengan IRSA memperoleh kredenSIAL 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 membuat titik akhir VPC untuk SS M. Ketika Karpenter mencoba menyediakan node baru, ia menanyakan konfigurasi template Launch dan parameter SSM. Jika Anda tidak memiliki titik akhir SSM VPC 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.<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 titik akhir VPC untuk API Kueri Daftar Harga. Akibatnya, data harga akan menjadi basi seiring waktu. Karpenter mengatasi hal ini dengan memasukkan data harga sesuai permintaan dalam binernya, tetapi hanya memperbarui data itu ketika Karpenter ditingkatkan. Permintaan data harga yang gagal akan menghasilkan pesan kesalahan 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 Cluster 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 di node pekerja yang berbeda, atau memiliki persyaratan jenis OS atau 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 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 tertimbang

Disarankan untuk membuat NodePools yang saling eksklusif atau tertimbang untuk memberikan perilaku penjadwalan yang konsisten. Jika tidak dan beberapa NodePools cocok, Karpenter akan secara acak memilih mana yang akan digunakan, menyebabkan hasil yang tidak terduga. Contoh 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 mencakup NodeAffinity. Deployment kemudian dapat menggunakan node SelectorTerms untuk mencocokkanbilling-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 secara otomatis menghapus node 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 peningkatan, sehingga node dihentikan dan diganti dengan versi yang diperbarui. Lihat Ked aluwar sa dalam dokumentasi Karpenter untuk informasi tentang penggunaan untuk mengonfigurasi ked spec.template.spec aluwarsa node.

Hindari terlalu membatasi Jenis Instans yang dapat disediakan Karpenter, terutama saat menggunakan Spot

Saat menggunakan Spot, Karpenter menggunakan strategi alokasi Pr ice Capacity Optimized untuk menyediakan instans EC2. Strategi ini menginstruksikan EC2 untuk menyediakan instans dari kumpulan terdalam untuk jumlah instans yang Anda luncurkan dan memiliki risiko gangguan terendah. EC2 Fleet kemudian meminta instans Spot dari kumpulan ini dengan harga terendah. Semakin banyak jenis instans yang Anda izinkan untuk digunakan Karpenter, 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 tempat cluster Anda digunakan. Karpenter dengan cerdas memilih dari kumpulan semua jenis instans berdasarkan pod yang tertunda untuk memastikan pod Anda dijadwalkan ke instans berukuran dan dilengkapi yang sesuai. Misalnya, jika pod Anda tidak memerlukan GPU, Karpenter tidak akan menjadwalkan pod Anda ke jenis instance EC2 yang mendukung GPU. Jika Anda tidak yakin jenis instans mana yang akan digunakan, Anda dapat menjalankan pem ilih instansi Amazon ec2 untuk menghasilkan daftar jenis instans yang sesuai dengan persyaratan komputasi Anda. Misalnya, CLI mengambil memori vCPU, arsitektur, dan wilayah sebagai parameter input dan memberi Anda daftar instance 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 batasan 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 untuk menggantikannya. Pod Anda akan tetap dalam status tertunda hingga kapasitas spot untuk jenis instans yang dikonfigurasi diisi ulang. Anda dapat mengurangi risiko kesalahan kapasitas yang tidak mencukupi dengan menyebarkan instans di zona ketersediaan yang berbeda, karena kumpulan spot berbeda di seluruh AZ. Konon, praktik terbaik umum adalah mengizinkan Karpenter menggunakan beragam jenis instance saat menggunakan Spot.

Pod Penjadwalan

Praktik terbaik berikut terkait dengan penerapan pod Dalam cluster menggunakan Karpenter untuk penyediaan node.

Ikuti praktik terbaik EKS untuk ketersediaan tinggi

Jika Anda perlu menjalankan aplikasi yang sangat tersedia, ikuti rekomendasi praktik terbaik EKS umum. Lihat S pread Topologi di dokumentasi Karpenter untuk detail tentang cara menyebarkan pod di seluruh node dan zona. Gunakan Anggaran Gangguan untuk menetapkan pod minimum yang tersedia yang perlu dipertahankan, jika ada upaya untuk mengusir atau menghapus pod.

Gunakan Batasan berlapis untuk membatasi fitur komputasi yang tersedia dari penyedia cloud Anda

Model batasan berlapis Karpenter memungkinkan Anda membuat kumpulan kompleks NodePool dan batasan penerapan pod untuk mendapatkan kecocokan terbaik untuk penjadwalan pod. Contoh kendala yang dapat diminta oleh spesifikasi pod meliputi:

Buat alarm penagihan untuk memantau pengeluaran komputasi Anda

Saat Anda mengonfigurasi cluster untuk menskalakan secara 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 dibuat instansiasi oleh Karpenter. NodePool

Cuplikan di bawah ini memberitahu 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 tampak serupa ke log pengontrol. Jika Anda merutekan log kontainer ke CloudWatch log, Anda dapat membuat filter metrik untuk mencari pola atau istilah tertentu di log, lalu membuat CloudWatch alarm untuk memberi tahu Anda saat ambang metrik yang dikonfigurasi dilanggar.

Untuk informasi lebih lanjut menggunakan batas dengan Karpenter, lihat Menetapkan Batas Sumber Daya dalam dokumentasi Karpenter.

spec:
  limits:
    cpu: 1000
    memory: 1000Gi

Jika Anda tidak menggunakan batasan atau membatasi jenis instans yang dapat disediakan Karpenter, Karpenter akan terus menambahkan kapasitas komputasi ke cluster sesuai kebutuhan. Sementara mengkonfigurasi Karpenter dengan cara ini memungkinkan cluster Anda untuk menskalakan secara bebas, hal itu juga dapat memiliki implikasi biaya yang signifikan. Karena alasan inilah kami merekomendasikan untuk mengonfigurasi alarm penagihan. Alarm penagihan memungkinkan Anda untuk diberi tahu dan diberi tahu secara proaktif ketika taksiran biaya yang dihitung di akun Anda melebihi ambang batas yang ditentukan. Lihat Men yiapkan Alarm Pen CloudWatch agihan Amazon untuk Memantau Perkiraan Biaya secara Proaktif untuk informasi tambahan.

Anda mungkin juga ingin mengaktifkan Deteksi Anomali Biaya yang merupakan fitur Manajemen Biaya AWS yang menggunakan pembelajaran mesin untuk terus memantau biaya dan penggunaan Anda untuk mendeteksi pengeluaran yang tidak biasa. Informasi lebih lanjut dapat ditemukan di panduan Mem ulai Deteksi Anomali Biaya AWS. Jika Anda telah membuat anggaran di Anggaran AWS, 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 Meng onfigurasi tindakan Anggaran AWS.

Gunakan karpenter. sh/do-not-anotasi untuk mencegah Karpenter mendeprovisioning node

Jika Anda menjalankan aplikasi penting pada Karpenter-provisioned node, seperti pekerjaan batch yang berjalan lama atau aplikasi stateful, dan TTL node telah kedaluwarsa, aplikasi akan terganggu ketika instance dihentikan. Dengan menambahkan karpenter.sh/do-not-disrupt anotasi ke pod, Anda menginstruksikan Karpenter untuk mempertahankan node sampai Pod dihentikan atau karpenter.sh/do-not-disrupt anotasi dihapus. Lihat dokumentasi Distruption untuk informasi lebih lanjut.

Jika satu-satunya pod non-daemonset yang tersisa pada node adalah yang terkait dengan pekerjaan, Karpenter dapat menargetkan dan menghentikan node tersebut selama status pekerjaan berhasil atau gagal.

Konfigurasikan requests=limit 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 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 kehabisan memori (OOM). Konsolidasi dapat membuat ini lebih mungkin terjadi karena berfungsi untuk mengemas pod ke node hanya dengan mempertimbangkan permintaan mereka.

Gunakan LimitRanges untuk mengonfigurasi default untuk permintaan dan batasan sumber daya

Karena Kubernetes tidak menetapkan permintaan atau batasan default, konsumsi sumber daya wadah dari host, CPU, dan memori yang mendasarinya tidak terikat. Penjadwal Kubernetes melihat total permintaan pod (semakin tinggi dari total permintaan dari wadah pod atau total sumber daya dari wadah Init pod) untuk menentukan node pekerja mana yang akan menjadwalkan pod. Demikian pula, Karpenter mempertimbangkan permintaan pod untuk menentukan jenis instance yang disediakan. Anda dapat menggunakan rentang batas untuk menerapkan default yang masuk akal untuk namespace, jika permintaan sumber daya tidak ditentukan oleh beberapa pod.

Lihat Meng onfigurasi Permintaan dan Batas Memori Default untuk Namespace

Menerapkan permintaan sumber daya yang akurat ke semua beban kerja

Karpenter dapat meluncurkan node yang paling sesuai dengan beban kerja Anda ketika informasinya tentang persyaratan beban kerja Anda akurat. Hal ini sangat penting jika menggunakan fitur konsolidasi Karpenter.

Lihat Konfigurasi dan Ukuran Sumber Daya Requests/Limits untuk semua Beban Kerja

Rekomendasi CoreDNS

Perbarui konfigurasi CoreDNS untuk menjaga keandalan

Saat menerapkan pod CoreDNS pada node yang dikelola oleh Karpenter, mengingat sifat dinamis Karpenter di node terminating/creating baru yang cepat untuk menyelaraskan dengan permintaan, disarankan untuk mematuhi praktik terbaik berikut:

Durasi lameduck CoreDNS

Pemeriksaan kesiapan CoreDNS

Ini akan memastikan bahwa kueri 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 Anda bertanya-tanya bagaimana mengkonfigurasinya 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 bahkan untuk membuat cluster EKS 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