Praktik terbaik untuk fitur penjadwal dasar di Azure Kubernetes Service (AKS)
Saat Anda mengelola kluster di Azure Kubernetes Service (AKS), Anda seringkali perlu mengisolasi tim dan beban kerja. Penjadwal Kubernetes memungkinkan Anda mengontrol distribusi sumber daya komputasi, atau membatasi dampak kegiatan pemeliharaan.
Artikel praktik terbaik ini berfokus pada fitur penjadwalan Kubernetes dasar untuk operator kluster. Dalam artikel ini, Anda akan mempelajari cara:
- Menggunakan kuota sumber daya untuk menyediakan sumber daya dalam jumlah tetap kepada tim atau beban kerja
- Membatasi dampak pemeliharaan terjadwal menggunakan anggaran gangguan Pod
Menerapkan kuota sumber daya
Panduan praktik terbaik
Rencanakan dan terapkan kuota sumber daya di tingkat namespace. Jika Pod tidak menentukan permintaan dan batasan sumber daya, maka tolak penyebaran. Pantau penggunaan sumber daya dan sesuaikan kuota sesuai kebutuhan.
Permintaan dan batasan resource ditempatkan pada spesifikasi Pod. Permintaan digunakan oleh penjadwal Kubernetes pada waktu penyebaran untuk menemukan simpul yang tersedia di kluster. Membatasi dan meminta pekerjaan di level Pod individu. Untuk informasi selengkapnya tentang cara menentukan nilai-nilai ini, lihat Menentukan permintaan dan batasan sumber daya pod.
Untuk menyediakan cara untuk mencadangkan dan membatasi sumber daya di seluruh tim atau proyek pengembangan, Anda harus menggunakan kuota sumber daya. Kuota ini ditentukan pada namespace, dan dapat digunakan untuk menetapkan kuota atas dasar sebagai berikut:
- Menghitung sumber daya , seperti CPU dan memori, atau GPU.
- Sumber daya penyimpanan, termasuk jumlah total volume atau jumlah ruang disk untuk kelas penyimpanan tertentu.
- Jumlah objek, seperti jumlah maksimum rahasia, layanan, atau pekerjaan yang dapat dibuat.
Kubernetes tidak melebihi sumber daya. Setelah total permintaan sumber daya kumulatif Anda melewati kuota yang ditetapkan, semua penyebaran lebih lanjut tidak akan berhasil.
Ketika Anda menentukan kuota sumber daya, semua Pod yang dibuat di namespace harus memberikan batasan atau permintaan dalam spesifikasi Pod-nya. Jika mereka tidak memberikan nilai-nilai ini, Anda dapat menolak penyebaran. Sebagai gantinya, Anda dapat mengonfigurasi permintaan dan batasan default untuk namespace.
Contoh berikut adalah manifes YAML bernama dev-app-team-quotas.yaml menetapkan batas keras dari total 10 CPU,20Gi memori, dan 10 Pod:
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-app-team
spec:
hard:
cpu: "10"
memory: 20Gi
pods: "10"
Sumber daya kuota ini dapat diterapkan dengan menentukan namespace, seperti dev-apps:
kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps
Bekerja sama dengan pengembang dan pemilik aplikasi Anda untuk memahami kebutuhan mereka dan menerapkan kuota sumber daya yang sesuai.
Untuk informasi lebih lanjut tentang objek sumber daya, cakupan, dan prioritas yang tersedia, lihat Kuota sumber daya di Kubernetes.
Rencanakan ketersediaan menggunakan anggaran gangguan Pod
Panduan praktik terbaik
Untuk menjaga ketersediaan aplikasi, tentukan Anggaran Gangguan Pod (PDBs) untuk memastikan bahwa jumlah minimum Pod tersedia di kluster.
Ada dua kejadian mengganggu yang menyebabkan Pod dihapus:
Gangguan yang tidak disengaja
Gangguan yang tidak disengaja adalah peristiwa di luar kontrol umum operator kluster atau pemilik aplikasi. Sertakan:
- Kegagalan perangkat keras pada peralatan fisik
- Kernel panik
- Penghapusan VM simpul
Gangguan yang tidak disengaja dapat dimitigasi dengan:
- Menggunakan beberapa replika Pod dalam suatu penyebaran.
- Menjalankan beberapa simpul di kluster AKS.
Gangguan yang tidak disengaja
Gangguan yang tidak disengaja merupakan peristiwa yang diminta oleh operator kluster atau pemilik aplikasi. Sertakan:
- Peningkatan kluster
- Templat penyebaran yang diperbarui
- Secara tidak sengaja menghapus sebuah Pod
Kubernetes menyediakan anggaran gangguan pod untuk gangguan sukarela, memungkinkan Anda merencanakan bagaimana penyebaran atau set replika merespons ketika peristiwa gangguan sukarela terjadi. Dengan menggunakan anggaran gangguan Pod, operator kluster dapat menentukan jumlah sumber daya minimum yang tersedia atau jumlah sumber daya maksimum yang tidak tersedia.
Jika Anda memutakhirkan kluster atau memperbarui templat penyebaran, penjadwal Kubernetes akan menjadwalkan Pod tambahan pada simpul lain sebelum memungkinkan kejadian tidak disengaja berlanjut. Penjadwal menunggu untuk me-reboot sebuah simpul node sampai jumlah Pod yang ditentukan berhasil dijadwalkan pada simpul lain di kluster.
Mari kita lihat contoh set replika dengan lima Pod yang menjalankan NGINX. Pod dalam replika set diberi labelapp: nginx-frontend
. Selama peristiwa gangguan yang tidak disengaja, seperti peningkatan kluster, Anda ingin memastikan setidaknya ada tiga Pod yang terus berjalan. Manifes YAML berikut untuk objek PodDisruptionBudget menentukan persyaratan berikut:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 3
selector:
matchLabels:
app: nginx-frontend
Anda juga dapat menentukan persentase, seperti 60%, yang memungkinkan Anda untuk secara otomatis mengkompensasi set replika guna meningkatkan jumlah Pod.
Anda dapat menentukan jumlah maksimum instans yang tidak tersedia dalam set replika. Sekali lagi, persentase untuk Pod maksimum yang tidak tersedia juga dapat ditentukan. Manifes YAML anggaran gangguan Pod berikut menentukan bahwa tidak lebih dari dua Pod dalam replica set tidak tersedia:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
maxUnavailable: 2
selector:
matchLabels:
app: nginx-frontend
Setelah anggaran disrupsi Pod ditentukan, Anda membuatnya di kluster AKS seperti halnya objek Kubernetes lainnya:
kubectl apply -f nginx-pdb.yaml
Bekerja sama dengan pengembang dan pemilik aplikasi Anda untuk memahami kebutuhan mereka dan menerapkan anggaran gangguan Pod yang sesuai.
Untuk informasi lebih lanjut tentang penggunaan anggaran gangguan, lihat, Tentukan anggaran gangguan untuk aplikasi Anda.
Langkah berikutnya
Artikel ini berfokus pada fitur penjadwal Kubernetes dasar. Untuk informasi selengkapnya tentang operasi kluster di AKS, lihat praktik terbaik berikut:
Azure Kubernetes Service