Komputasi dan Penskalaan Otomatis

Sebagai pengembang, Anda akan membuat perkiraan tentang kebutuhan sumber daya aplikasi Anda, misalnya CPU dan memori, tetapi jika Anda tidak terus-menerus menyesuaikannya, mereka mungkin menjadi usang yang dapat meningkatkan biaya dan memperburuk kinerja dan keandalan. Menyesuaikan kebutuhan sumber daya aplikasi secara terus-menerus lebih penting daripada memperbaikinya pertama kali.

Praktik terbaik yang disebutkan di bawah ini akan membantu Anda membangun dan mengoperasikan beban kerja sadar biaya yang mencapai hasil bisnis sambil meminimalkan biaya dan memungkinkan organisasi Anda memaksimalkan laba atas investasinya. Urutan tingkat tinggi yang penting untuk mengoptimalkan biaya komputasi cluster Anda adalah:

1. Beban kerja ukuran kanan

2. Kurangi kapasitas yang tidak terpakai

3. Optimalkan jenis kapasitas komputasi (misalnya Spot) dan akselerator (mis.) GPUs

Ukuran beban kerja Anda dengan benar

Di sebagian besar kluster EKS, sebagian besar biaya berasal dari EC2 instance yang digunakan untuk menjalankan beban kerja kontainer Anda. Anda tidak akan dapat mengukur sumber daya komputasi Anda dengan benar tanpa memahami persyaratan beban kerja Anda. Inilah sebabnya mengapa penting bagi Anda untuk menggunakan permintaan dan batasan yang sesuai dan membuat penyesuaian pada pengaturan tersebut seperlunya. Selain itu, dependensi, seperti ukuran instans dan pemilihan penyimpanan, dapat mempengaruhi kinerja beban kerja yang dapat memiliki berbagai konsekuensi yang tidak diinginkan pada biaya dan keandalan.

Permintaan harus selaras dengan pemanfaatan yang sebenarnya. Jika permintaan kontainer terlalu tinggi akan ada kapasitas yang tidak terpakai yang merupakan faktor besar dalam total biaya cluster. Setiap kontainer dalam sebuah pod, misalnya application dan sidecars, harus memiliki permintaan dan batasannya sendiri yang ditetapkan untuk memastikan batas agregat pod seakurat mungkin.

Gunakan alat seperti Goldilocks, KRR, dan Kubecost yang memperkirakan permintaan sumber daya dan batasan untuk kontainer Anda. Bergantung pada sifat aplikasi, persyaratan kinerja/biaya, dan kompleksitas, Anda perlu mengevaluasi metrik mana yang terbaik untuk diskalakan, pada titik mana kinerja aplikasi Anda menurun (titik saturasi), dan cara mengubah permintaan dan batasan yang sesuai. Silakan merujuk ke Ukuran aplikasi yang tepat untuk panduan lebih lanjut tentang topik ini.

Sebaiknya gunakan Horizontal Pod Autoscaler (HPA) untuk mengontrol berapa banyak replika aplikasi Anda yang harus dijalankan, Vertical Pod Autoscaler (VPA) untuk menyesuaikan berapa banyak permintaan dan membatasi kebutuhan aplikasi Anda per replika, dan autoscaler node seperti Karpenter atau Cluster Autoscaler untuk terus menyesuaikan jumlah total node di cluster Anda. Teknik pengoptimalan biaya menggunakan Karpenter dan Cluster Autoscaler didokumentasikan di bagian selanjutnya dari dokumen ini.

Vertical Pod Autoscaler dapat menyesuaikan permintaan dan batasan yang ditetapkan ke kontainer sehingga beban kerja berjalan secara optimal. Anda harus menjalankan VPA dalam mode audit sehingga tidak secara otomatis membuat perubahan dan memulai ulang pod Anda. Ini akan menyarankan perubahan berdasarkan metrik yang diamati. Dengan perubahan apa pun yang memengaruhi beban kerja produksi, Anda harus meninjau dan menguji perubahan tersebut terlebih dahulu di lingkungan non-produksi karena hal ini dapat berdampak pada keandalan dan kinerja aplikasi Anda.

Kurangi konsumsi

Cara terbaik untuk menghemat uang adalah dengan menyediakan lebih sedikit sumber daya. Salah satu cara untuk melakukannya adalah dengan menyesuaikan beban kerja berdasarkan kebutuhan mereka saat ini. Anda harus memulai upaya pengoptimalan biaya dengan memastikan beban kerja Anda menentukan persyaratan dan skala mereka secara dinamis. Ini akan membutuhkan metrik dari aplikasi Anda dan pengaturan konfigurasi seperti PodDisruptionBudgetsdan Pod Readiness Gates untuk memastikan aplikasi Anda dapat dengan aman naik dan turun secara dinamis. Penting untuk dipertimbangkan bahwa restriktif PodDisruptionBudgets dapat mencegah Cluster Autoscaler dan Karpenter mengurangi Node, karena keduanya menghormati Cluster Autoscaler dan Karpenter. PodDisruptionBudgets Nilai 'minAvailable' dalam PodDisruptionBudget harus selalu lebih rendah dari jumlah pod dalam penerapan dan Anda harus menyimpan buffer yang baik di antara keduanya misalnya Dalam penerapan 6 pod di mana Anda ingin minimal 4 pod berjalan setiap saat, atur 'minAvailable' di Anda ke 4. PodDisruptionBidget Ini akan memungkinkan Cluster Autoscaler dan Karpenter untuk dengan aman mengalirkan dan mengusir pod dari node yang kurang dimanfaatkan selama acara scale-down Node. Silakan merujuk ke dokumen FAQ Cluster Autoscaler.

Horizontal Pod Autoscaler adalah autoscaler beban kerja fleksibel yang dapat menyesuaikan berapa banyak replika yang diperlukan untuk memenuhi persyaratan kinerja dan keandalan aplikasi Anda. Ini memiliki model yang fleksibel untuk menentukan kapan harus naik dan turun berdasarkan berbagai metrik seperti CPU, memori, atau metrik khusus misalnya kedalaman antrian, jumlah koneksi ke pod, dll.

Kubernetes Metrics Server memungkinkan penskalaan sebagai respons terhadap metrik bawaan seperti penggunaan CPU dan memori, tetapi jika Anda ingin menskalakan berdasarkan metrik lain, seperti kedalaman antrian Amazon CloudWatch atau SQS, Anda harus mempertimbangkan proyek penskalaan otomatis berbasis peristiwa seperti KEDA. Silakan lihat posting blog ini tentang cara menggunakan KEDA dengan CloudWatch metrik. Jika Anda tidak yakin, metrik mana yang akan dipantau dan diskalakan berdasarkan, lihat praktik terbaik tentang metrik pemantauan yang penting.

Mengurangi konsumsi beban kerja menciptakan kelebihan kapasitas dalam sebuah cluster dan dengan konfigurasi penskalaan otomatis yang tepat memungkinkan Anda untuk menurunkan skala node secara otomatis dan mengurangi total pengeluaran Anda. Kami menyarankan Anda untuk tidak mencoba mengoptimalkan kapasitas komputasi secara manual. Penjadwal Kubernetes dan autoscaler node dirancang untuk menangani proses ini untuk Anda.

Kurangi kapasitas yang tidak terpakai

Setelah Anda menentukan ukuran yang benar untuk aplikasi, mengurangi permintaan berlebih, Anda dapat mulai mengurangi kapasitas komputasi yang disediakan. Anda harus dapat melakukan ini secara dinamis jika Anda telah meluangkan waktu untuk mengukur beban kerja Anda dengan benar dari bagian di atas. Ada dua autoscaler node utama yang digunakan dengan Kubernetes di AWS.

Karpenter dan Cluster Autoscaler

Baik Karpenter dan Kubernetes Cluster Autoscaler akan menskalakan jumlah node di klaster Anda saat pod dibuat atau dihapus dan persyaratan komputasi berubah. Tujuan utama keduanya adalah sama, tetapi Karpenter mengambil pendekatan yang berbeda untuk penyediaan manajemen node dan de-provisioning yang dapat membantu mengurangi biaya dan mengoptimalkan penggunaan luas cluster.

Ketika cluster bertambah besar dan variasi beban kerja meningkat, menjadi lebih sulit untuk melakukan pra-konfigurasi grup dan instance node. Sama seperti permintaan beban kerja, penting untuk menetapkan garis dasar awal dan terus menyesuaikan sesuai kebutuhan.

Jika Anda menggunakan Cluster Autoscaler, itu akan menghormati nilai “minimum” dan “maksimum” dari setiap grup Auto Scaling (ASG) dan hanya menyesuaikan nilai “yang diinginkan”. Penting untuk memperhatikan saat menyetel nilai-nilai ini untuk ASG yang mendasarinya karena Cluster Autoscaler tidak akan dapat menurunkan ASG di luar jumlah “minimum”. Tetapkan jumlah “yang diinginkan” sebagai jumlah node yang Anda butuhkan selama jam kerja normal dan “minimum” sebagai jumlah node yang Anda butuhkan selama jam kerja di luar bisnis. Silakan merujuk ke dokumen FAQ Cluster Autoscaler.

Expander Prioritas Cluster Autoscaler

Kubernetes Cluster Autoscaler bekerja dengan menskalakan kelompok node — disebut grup node — naik dan turun saat aplikasi naik dan turun. Jika Anda tidak menskalakan beban kerja secara dinamis maka Cluster Autoscaler tidak akan membantu Anda menghemat uang. Cluster Autoscaler memerlukan admin cluster untuk membuat grup node sebelumnya agar beban kerja dapat dikonsumsi. Grup node perlu dikonfigurasi untuk menggunakan instance yang memiliki “profil” yang sama, yaitu kira-kira jumlah CPU dan memori yang sama.

Anda dapat memiliki beberapa grup node dan Cluster Autoscaler dapat dikonfigurasi untuk menetapkan tingkat penskalaan prioritas dan setiap grup node dapat berisi node berukuran berbeda. Grup node dapat memiliki tipe kapasitas yang berbeda dan expander prioritas dapat digunakan untuk menskalakan grup yang lebih murah terlebih dahulu.

Di bawah ini adalah contoh cuplikan konfigurasi klaster yang menggunakan a ConfigMap` untuk memprioritaskan kapasitas cadangan sebelum menggunakan instance sesuai permintaan. Anda dapat menggunakan teknik yang sama untuk memprioritaskan Graviton atau Spot Instances di atas jenis lainnya.

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
  name: my-cluster
managedNodeGroups:
  - name: managed-ondemand
    minSize: 1
    maxSize: 7
    instanceType: m5.xlarge
  - name: managed-reserved
    minSize: 2
    maxSize: 10
    instanceType: c5.2xlarge

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-priority-expander
  namespace: kube-system
data:
  priorities: |-
    10:
      - .*ondemand.*
    50:
      - .*reserved.*

Menggunakan grup node dapat membantu sumber daya komputasi yang mendasarinya melakukan hal yang diharapkan secara default, misalnya menyebarkan node AZs, tetapi tidak semua beban kerja memiliki persyaratan atau harapan yang sama dan lebih baik membiarkan aplikasi mendeklarasikan persyaratannya secara eksplisit. Untuk informasi selengkapnya tentang Cluster Autoscaler, silakan lihat bagian praktik terbaik.

Descheduler

Cluster Autoscaler dapat menambah dan menghapus kapasitas node dari cluster berdasarkan pod baru yang perlu dijadwalkan atau node yang kurang dimanfaatkan. Itu tidak mengambil tampilan menyeluruh dari penempatan pod setelah dijadwalkan ke sebuah node. Jika Anda menggunakan Cluster Autoscaler, Anda juga harus melihat descheduler Kubernetes untuk menghindari pemborosan kapasitas di cluster Anda.

Jika Anda memiliki 10 node dalam sebuah cluster dan setiap node 60% digunakan, Anda tidak menggunakan 40% dari kapasitas yang disediakan di cluster. Dengan Cluster Autoscaler Anda dapat mengatur ambang batas pemanfaatan per node menjadi 60%, tetapi itu hanya akan mencoba menurunkan satu node setelah pemanfaatan turun di bawah 60%.

Dengan descheduler dapat melihat kapasitas dan pemanfaatan cluster setelah pod dijadwalkan atau node telah ditambahkan ke cluster. Ini mencoba untuk menjaga kapasitas total cluster di atas ambang batas yang ditentukan. Hal ini juga dapat menghapus pod berdasarkan node taints atau node baru yang bergabung dengan cluster untuk memastikan pod berjalan di lingkungan komputasi optimal mereka. Perhatikan bahwa, descheduler tidak menjadwalkan penggantian pod yang diusir tetapi bergantung pada penjadwal default untuk itu.

Konsolidasi Karpenter

Karpenter mengambil pendekatan “tanpa kelompok” untuk manajemen simpul. Pendekatan ini lebih fleksibel untuk jenis beban kerja yang berbeda dan membutuhkan konfigurasi awal yang lebih sedikit untuk administrator klaster. Alih-alih menentukan grup sebelumnya dan menskalakan setiap grup sesuai kebutuhan beban kerja, Karpenter menggunakan penyedia dan templat simpul untuk menentukan secara luas jenis instance apa yang dapat dibuat dan EC2 pengaturan tentang instance saat dibuat.

Bin packing adalah praktik memanfaatkan lebih banyak sumber daya instans dengan mengemas lebih banyak beban kerja ke instance yang lebih sedikit dan berukuran optimal. Meskipun ini membantu mengurangi biaya komputasi Anda dengan hanya menyediakan sumber daya yang digunakan beban kerja Anda, ini memiliki trade-off. Diperlukan waktu lebih lama untuk memulai beban kerja baru karena kapasitas harus ditambahkan ke cluster, terutama selama peristiwa penskalaan besar. Pertimbangkan keseimbangan antara optimalisasi biaya, kinerja, dan ketersediaan saat menyiapkan pengepakan tempat sampah.

Karpenter dapat terus memantau dan binpack untuk meningkatkan pemanfaatan sumber daya instans dan menurunkan biaya komputasi Anda. Karpenter juga dapat memilih node pekerja yang lebih hemat biaya untuk beban kerja Anda. Ini dapat dicapai dengan mengaktifkan flag “konsolidasi” ke true di penyedia (contoh cuplikan kode di bawah). Contoh di bawah ini menunjukkan contoh penyedia yang memungkinkan konsolidasi. Pada saat menulis panduan ini, Karpenter tidak akan mengganti instance Spot yang sedang berjalan dengan instans Spot yang lebih murah. Untuk detail lebih lanjut tentang konsolidasi Karpenter, lihat blog ini.

apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
  name: enable-binpacking
spec:
  consolidation:
    enabled: true

Untuk beban kerja yang mungkin tidak dapat diinterupsi, misalnya pekerjaan batch yang berjalan lama tanpa checkpointing, pertimbangkan untuk membuat anotasi pod dengan anotasi. do-not-evict Dengan memilih pod keluar dari penggusuran, Anda memberi tahu Karpenter bahwa itu tidak boleh secara sukarela menghapus node yang berisi pod ini. Namun, jika sebuah do-not-evict pod ditambahkan ke node saat node terkuras, pod yang tersisa akan tetap mengusir, tetapi pod itu akan memblokir penghentian sampai dihapus. Dalam kedua kasus tersebut, node akan ditutup untuk mencegah pekerjaan tambahan dijadwalkan pada node. Di bawah ini adalah contoh yang menunjukkan cara mengatur anotasi:

8"" linenumbering="unnumbered">apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "karpenter.sh/do-not-evict": "true" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80

Hapus node yang kurang dimanfaatkan dengan menyesuaikan parameter Cluster Autoscaler

Pemanfaatan node didefinisikan sebagai jumlah sumber daya yang diminta dibagi dengan kapasitas. Secara default scale-down-utilization-threshold diatur ke 50%. Parameter ini dapat digunakan bersama dengan danscale-down-unneeded-time, yang menentukan berapa lama node tidak diperlukan sebelum memenuhi syarat untuk menurunkan skala - defaultnya adalah 10 menit. Pod yang masih berjalan pada node yang diperkecil akan dijadwalkan pada node lain oleh kube-scheduler. Menyesuaikan pengaturan ini dapat membantu menghapus node yang kurang dimanfaatkan, tetapi penting Anda menguji nilai-nilai ini terlebih dahulu sehingga Anda tidak memaksa cluster untuk menurunkan skala sebelum waktunya.

Anda dapat mencegah terjadinya penurunan skala dengan memastikan bahwa pod yang mahal untuk diusir dilindungi oleh label yang dikenali oleh Cluster Autoscaler. Untuk melakukan ini, pastikan bahwa pod yang mahal untuk diusir memiliki anotasi. cluster-autoscaler.kubernetes.io/safe-to-evict=false Di bawah ini adalah contoh yaml untuk mengatur anotasi:

8"" linenumbering="unnumbered">apiVersion: v1 kind: Pod metadata: name: label-demo labels: environment: production annotations: + "cluster-autoscaler.kubernetes.io/safe-to-evict": "false" spec: containers: * name: nginx image: nginx ports: ** containerPort: 80