Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
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:
-
Beban kerja ukuran kanan
-
Kurangi kapasitas yang tidak terpakai
-
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
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
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 skalanya secara dinamis. Ini akan membutuhkan metrik dari aplikasi Anda dan pengaturan konfigurasi seperti PodDisruptionBudgets
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.
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 menskalakan 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
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:
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:
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
Tag node dengan Cluster Autoscaler dan Karpenter
Tag sumber daya AWS digunakan untuk mengatur sumber daya Anda, dan untuk melacak biaya AWS Anda pada tingkat terperinci. Mereka tidak berkorelasi langsung dengan label Kubernetes untuk pelacakan biaya. Disarankan untuk memulai dengan pelabelan sumber daya Kubernetes dan menggunakan alat seperti Kubecost untuk mendapatkan pelaporan biaya infrastruktur berdasarkan label Kubernetes
Node pekerja harus memiliki tag untuk menampilkan informasi penagihan di AWS Cost Explorer. Dengan Cluster Autoscaler, beri tag node pekerja Anda di dalam grup node terkelola menggunakan template peluncuran. Untuk grup node yang dikelola sendiri, beri tag instance Anda menggunakan grup penskalaan EC2 otomatis. Untuk instance yang disediakan oleh Karpenter, beri tag menggunakan spec.tags
Cluster multi-penyewa
Saat mengerjakan cluster yang dibagikan oleh tim yang berbeda, Anda mungkin tidak memiliki visibilitas ke beban kerja lain yang berjalan pada node yang sama. Sementara permintaan sumber daya dapat membantu mengisolasi beberapa masalah “tetangga yang bising”, seperti berbagi CPU, mereka mungkin tidak mengisolasi semua batas sumber daya seperti kelelahan disk. I/O Tidak setiap sumber daya habis pakai oleh beban kerja dapat diisolasi atau dibatasi. Beban kerja yang mengkonsumsi sumber daya bersama pada tingkat yang lebih tinggi daripada beban kerja lainnya harus diisolasi melalui noda
Mengisolasi beban kerja pada tingkat node bisa lebih mahal, tetapi dimungkinkan untuk menjadwalkan BestEffort
Cluster bersama mungkin juga memiliki batasan sumber daya tingkat klaster seperti kehabisan IP, batas layanan Kubernetes, atau permintaan penskalaan API. Anda harus meninjau panduan praktik terbaik skalabilitas untuk memastikan klaster Anda menghindari batasan ini.
Anda dapat mengisolasi sumber daya di namespace atau tingkat penyedia Karpenter. Resource Quotas
Penyedia Karpenter dapat menetapkan batasan pada beberapa sumber daya habis pakai
Penskalaan Otomatis Terjadwal
Anda mungkin perlu menurunkan cluster Anda pada akhir pekan dan jam kerja. Ini sangat relevan untuk cluster pengujian dan non-produksi di mana Anda ingin menurunkan skala ke nol ketika mereka tidak digunakan. Solusi seperti cluster-turndown dapat menurunkan
Optimalkan jenis kapasitas komputasi
Setelah mengoptimalkan total kapasitas komputasi di cluster Anda dan menggunakan kemasan bin, Anda harus melihat jenis komputasi apa yang telah Anda sediakan di cluster Anda dan bagaimana Anda membayar sumber daya tersebut. AWS memiliki paket Tabungan Komputasi
-
Spot
-
Savings Plans
-
Sesuai Permintaan
-
Fargate
Setiap jenis kapasitas memiliki trade-off yang berbeda untuk overhead manajemen, ketersediaan, dan komitmen jangka panjang dan Anda perlu memutuskan mana yang tepat untuk lingkungan Anda. Tidak ada lingkungan yang harus bergantung pada satu jenis kapasitas dan Anda dapat mencampur beberapa jenis run dalam satu cluster untuk mengoptimalkan persyaratan dan biaya beban kerja tertentu.
Spot
Jenis kapasitas spot
Komputasi spot harus menggunakan berbagai jenis instans untuk mengurangi kemungkinan tidak memiliki kapasitas spot yang tersedia. Interupsi instance perlu ditangani untuk mematikan node dengan aman. Node yang disediakan dengan Karpenter atau bagian dari Grup Node Terkelola secara otomatis mendukung notifikasi interupsi instans. Jika Anda menggunakan node yang dikelola sendiri, Anda harus menjalankan penangan terminasi node
Dimungkinkan untuk menyeimbangkan instans spot dan on-demand dalam satu cluster. Dengan Karpenter Anda dapat membuat penyedia tertimbang
Berikut adalah contoh penggunaan Karpenter untuk memprioritaskan instans Spot sebelum instans On-Demand. Saat membuat penyedia, Anda dapat menentukan Spot, Sesuai Permintaan, atau keduanya (seperti yang ditunjukkan di bawah). Ketika Anda menentukan keduanya, dan jika pod tidak secara eksplisit menentukan apakah perlu menggunakan Spot atau On-Demand, maka Karpenter memprioritaskan Spot saat menyediakan node dengan strategi alokasi. price-capacity-optimization
apiVersion: karpenter.sh/v1
kind: Provisioner
metadata:
name: spot-prioritized
spec:
requirements:
- key: "karpenter.sh/capacity-type"
operator: In
values: ["spot", "on-demand"]
Savings Plans, Instans Cadangan, dan AWS EDP
Anda dapat mengurangi pengeluaran komputasi Anda dengan menggunakan rencana tabungan komputasi
Paket penghematan komputasi dapat mengurangi EC2 biaya Anda hingga 66% tanpa memerlukan komitmen pada jenis instans, keluarga, atau wilayah yang ingin Anda gunakan. Tabungan secara otomatis diterapkan ke instans saat Anda menggunakannya.
EC2 Instance Savings Plans menyediakan penghematan hingga 72% pada komputasi dengan komitmen penggunaan di wilayah dan EC2 keluarga tertentu, misalnya instans dari keluarga C. Anda dapat mengalihkan penggunaan ke AZ mana pun di dalam wilayah, menggunakan generasi keluarga instans apa pun, misalnya c5 atau c6, dan menggunakan ukuran instance apa pun dalam keluarga. Diskon akan secara otomatis diterapkan untuk setiap contoh di akun Anda yang sesuai dengan kriteria paket tabungan.
Instans Cadangan
Pelanggan juga memiliki opsi untuk mendaftar dalam Perjanjian Perusahaan dengan AWS. Perjanjian Perusahaan memberi pelanggan pilihan untuk menyesuaikan perjanjian yang paling sesuai dengan kebutuhan mereka. Pelanggan dapat menikmati diskon harga berdasarkan AWS EDP (Enterprise Discount Program). Untuk informasi tambahan tentang Perjanjian Perusahaan, silakan hubungi perwakilan penjualan AWS Anda.
Sesuai Permintaan
EC2 Instans On-Demand memiliki manfaat ketersediaan tanpa gangguan — dibandingkan dengan spot — dan tidak ada komitmen jangka panjang — dibandingkan dengan rencana tabungan. Jika Anda ingin mengurangi biaya dalam klaster, Anda harus mengurangi penggunaan EC2 instans sesuai permintaan.
Setelah mengoptimalkan persyaratan beban kerja Anda, Anda harus dapat menghitung kapasitas minimum dan maksimum untuk cluster Anda. Jumlah ini dapat berubah dari waktu ke waktu tetapi jarang turun. Pertimbangkan untuk menggunakan Savings Plan untuk segala sesuatu di bawah minimum, dan temukan kapasitas yang tidak akan memengaruhi ketersediaan aplikasi Anda. Hal lain yang mungkin tidak terus digunakan atau diperlukan untuk ketersediaan dapat digunakan sesuai permintaan.
Seperti disebutkan di bagian ini, cara terbaik untuk mengurangi penggunaan Anda adalah dengan mengkonsumsi lebih sedikit sumber daya dan memanfaatkan sumber daya yang Anda berikan semaksimal mungkin. Dengan Cluster Autoscaler Anda dapat menghapus node yang kurang dimanfaatkan dengan pengaturan. scale-down-utilization-threshold Dengan Karpenter disarankan untuk mengaktifkan konsolidasi.
Untuk mengidentifikasi jenis EC2 instance secara manual yang dapat digunakan dengan beban kerja Anda, Anda harus menggunakan ec2-instance-selector
ec2-instance-selector --memory 4 --vcpus 2 --cpu-architecture x86_64 \ -r us-east-1 --service eks c5.large c5a.large c5ad.large c5d.large c6a.large c6i.large t2.medium t3.medium t3a.medium
Untuk lingkungan non-produksi, Anda dapat secara otomatis memiliki klaster yang diperkecil selama jam yang tidak digunakan seperti malam dan akhir pekan. Proyek kubecost cluster-turndown
Fargate menghitung
Fargate compute adalah opsi komputasi yang dikelola sepenuhnya untuk kluster EKS. Ini menyediakan isolasi pod dengan menjadwalkan satu pod per node dalam cluster Kubernetes. Ini memungkinkan Anda untuk mengukur node komputasi Anda ke persyaratan CPU dan RAM dari beban kerja Anda untuk mengontrol penggunaan beban kerja secara ketat dalam sebuah cluster.
Fargate dapat menskalakan beban kerja sekecil 0,25 vCPU dengan memori 0,5 GB dan sebesar 16 vCPU dengan memori 120 GB. Ada batasan berapa banyak variasi ukuran pod yang tersedia dan Anda perlu memahami bagaimana beban kerja Anda paling sesuai dengan konfigurasi Fargate. Misalnya, jika beban kerja Anda membutuhkan 1 vCPU dengan memori 0,5 GB, pod Fargate terkecil adalah 1 vCPU dengan memori 2 GB.
Sementara Fargate memiliki banyak manfaat seperti tidak ada EC2 instance atau manajemen sistem operasi, mungkin memerlukan kapasitas komputasi yang lebih besar daripada EC2 instance tradisional karena fakta bahwa setiap pod yang di-deploy diisolasi sebagai node terpisah di cluster. Ini membutuhkan lebih banyak duplikasi untuk hal-hal seperti Kubelet, agen logging, dan apa pun yang biasanya DaemonSets Anda terapkan ke node. DaemonSets tidak didukung di Fargate dan mereka perlu diubah menjadi pod “`sidecars"` dan dijalankan di samping aplikasi.
Fargate tidak dapat mengambil manfaat dari pengepakan bin atau CPU melalui penyediaan karena batas untuk beban kerja adalah simpul yang tidak dapat dibobol atau dibagikan di antara beban kerja. Fargate akan menghemat waktu manajemen EC2 instans yang memiliki biaya, tetapi biaya CPU dan memori mungkin lebih mahal daripada jenis EC2 kapasitas lainnya. Pod Fargate dapat memanfaatkan rencana penghematan komputasi untuk mengurangi biaya sesuai permintaan.
Optimalkan Penggunaan Komputasi
Cara lain untuk menghemat uang pada infrastruktur komputasi Anda adalah dengan menggunakan komputasi yang lebih efisien untuk beban kerja. Ini bisa berasal dari komputasi tujuan umum yang lebih berkinerja seperti prosesor Graviton
EKS memiliki kemampuan untuk menjalankan cluster dengan arsitektur campuran (misalnya amd64 dan arm64) dan jika kontainer Anda dikompilasi untuk beberapa arsitektur, Anda dapat memanfaatkan prosesor Graviton dengan Karpenter dengan mengizinkan kedua arsitektur di penyedia Anda. Namun, untuk menjaga kinerja yang konsisten, Anda disarankan untuk menyimpan setiap beban kerja pada arsitektur komputasi tunggal dan hanya menggunakan arsitektur yang berbeda jika tidak ada kapasitas tambahan yang tersedia.
Penyedia dapat dikonfigurasi dengan beberapa arsitektur dan beban kerja juga dapat meminta arsitektur tertentu dalam spesifikasi beban kerja mereka.
apiVersion: karpenter.sh/v1 kind: Provisioner metadata: name: default spec: requirements: - key: "kubernetes.io/arch" operator: In values: ["arm64", "amd64"]
Dengan Cluster Autoscaler Anda perlu membuat grup node untuk instance Graviton dan mengatur toleransi node pada beban kerja Anda untuk memanfaatkan kapasitas baru
GPUs dan FPGAs dapat sangat meningkatkan kinerja untuk beban kerja Anda, tetapi beban kerja perlu dioptimalkan untuk menggunakan akselerator. Banyak jenis beban kerja untuk pembelajaran mesin dan kecerdasan buatan dapat digunakan GPUs untuk komputasi dan instance dapat ditambahkan ke cluster dan dipasang ke beban kerja menggunakan permintaan sumber daya.
spec: template: spec: - containers: ... resources: limits: nvidia.com/gpu: "1"
Beberapa perangkat keras GPU dapat dibagi di beberapa beban kerja sehingga satu GPU dapat disediakan dan digunakan. Untuk melihat cara mengonfigurasi berbagi GPU beban kerja, lihat plugin perangkat GPU virtual
