Halaman ini menunjukkan cara menjalankan workload fault-tolerant dengan biaya lebih rendah menggunakan Pod Spot di cluster Google Kubernetes Engine (GKE) Autopilot Anda.
Ringkasan
Di cluster GKE Autopilot, Spot Pod adalah Pod yang berjalan pada node yang didukung oleh Spot VM Compute Engine. Pod Spot dihargai lebih rendah daripada Pod Autopilot standar, tetapi dapat ditiadakan oleh GKE setiap kali resource komputasi diperlukan untuk menjalankan Pod standar.
Pod Spot ideal untuk menjalankan beban kerja stateless, batch, atau fault-tolerant dengan biaya lebih rendah daripada menjalankan beban kerja tersebut sebagai Pod standar. Untuk menggunakan Pod Spot di cluster Autopilot, ubah manifes dengan spesifikasi Pod untuk meminta Pod Spot.
Anda dapat menjalankan Pod Spot di class komputasi Autopilot umum default serta di class komputasi khusus yang memenuhi persyaratan hardware tertentu. Untuk mengetahui informasi tentang class komputasi ini, lihat Class komputasi di Autopilot.
Untuk mempelajari lebih lanjut harga Pod Spot di cluster Autopilot, lihat Harga Google Kubernetes Engine.
Pod Spot dikecualikan dari Perjanjian Tingkat Layanan Autopilot.
Manfaat
Menggunakan Pod Spot di cluster Autopilot akan memberi Anda manfaat berikut:
- Harga lebih rendah daripada menjalankan beban kerja yang sama pada Pod Autopilot standar.
- GKE mengelola penskalaan otomatis dan penjadwalan secara otomatis.
- GKE secara otomatis taint node yang menjalankan Pod Spot untuk memastikan bahwa Pod standar, seperti beban kerja penting, tidak dijadwalkan pada node tersebut. Deployment Anda yang menggunakan Pod Spot akan otomatis diupdate dengan tolerasi yang sesuai.
Sebelum memulai
Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:
- Aktifkan Google Kubernetes Engine API. Aktifkan Google Kubernetes Engine API
- Jika ingin menggunakan Google Cloud CLI untuk tugas ini,
instal lalu
lakukan inisialisasi
gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan
gcloud components update
.
Meminta Pod Spot di beban kerja Autopilot Anda
Untuk meminta agar Pod Anda berjalan sebagai Pod Spot, gunakan
label cloud.google.com/gke-spot=true
di
nodeSelector
atau afinitas
node
dalam spesifikasi Pod Anda. GKE secara otomatis menyediakan node
yang dapat menjalankan Pod Spor.
Pod Spot dapat dikeluarkan dan dihentikan kapan saja, misalnya jika resource komputasi diperlukan di tempat lain di Google Cloud. Saat penghentian
terjadi, Pod Spot di node penghentian dapat meminta masa tenggang
hingga 15 detik sebelum penghentian, yang diberikan berdasarkan upaya terbaik, dengan
menentukan kolom terminationGracePeriodSeconds
.
Masa tenggang maksimum yang diberikan untuk Pod Spot selama preemption adalah 15
detik. Meminta lebih dari 15 detik dalam terminationGracePeriodSeconds
tidak berarti mendapatkan lebih dari 15 detik selama preemption. Saat dikeluarkan, Pod Anda akan
dikirimi sinyal
SIGTERM,
dan harus mengambil langkah untuk mematikan selama masa tenggang.
Untuk Autopilot, GKE juga secara otomatis melakukan taint pada node yang dibuat untuk menjalankan Pod Spot dan mengubah beban kerja tersebut dengan toleransi yang sesuai. Taint ini mencegah Pod standar dijadwalkan pada node yang menjalankan Pod Spot.
Menggunakan PemilihNode untuk mengharuskan Pod Spot
Anda dapat menggunakan Pemilihnode untuk mewajibkan Pod Spot dalam Deployment. Tambahkan
label cloud.google.com/gke-spot=true
ke Deployment Anda, seperti dalam contoh
berikut:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
labels:
app: pi
spec:
nodeSelector:
cloud.google.com/gke-spot: "true"
terminationGracePeriodSeconds: 15
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
Menggunakan afinitas node untuk meminta Pod Spot
Atau, Anda dapat menggunakan afinitas node untuk meminta Pod Spot. Afinitas node memberi Anda cara yang lebih luas dalam memilih node yang akan menjalankan beban kerja. Misalnya, Anda dapat menggabungkan beberapa kriteria pemilihan untuk mendapatkan kontrol yang lebih baik atas lokasi di mana Pod Anda berjalan. Saat menggunakan afinitas node untuk meminta Pod Spot, Anda dapat menentukan jenis afinitas node yang akan digunakan, sebagai berikut:
requiredDuringSchedulingIgnoredDuringExecution
: Harus menggunakan Pod Spot.preferredDuringSchedulingIgnoredDuringExecution
: Gunakan Pod Spot atas dasar upaya terbaik.
Untuk menggunakan afinitas node guna mengharuskan Pod Spot dalam Deployment, tambahkan
aturan nodeAffinity
berikut ke manifes Deployment Anda:
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
labels:
app: pi
spec:
terminationGracePeriodSeconds: 15
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: cloud.google.com/gke-spot
operator: In
values:
- "true"
containers:
- name: pi
image: perl:5.34.0
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
backoffLimit: 4
Meminta Pod Spot atas dasar upaya terbaik
Untuk menggunakan afinitas node guna meminta Pod Spot dengan upaya terbaik, gunakan
preferredDuringSchedulingIgnoredDuringExecution
.
Saat Anda meminta Pod Spot berdasarkan pilihan, GKE
akan menjadwalkan Pod berdasarkan urutan berikut:
- Node yang ada yang dapat menjalankan Pod Spot yang memiliki ketersediaan kapasitas yang dapat dialokasikan.
- Node standar yang ada dan memiliki kapasitas alokasi yang tersedia.
- Node baru yang dapat menjalankan Pod Spot, jika resource komputasi tersedia.
- Node standar baru.
Karena GKE lebih memilih node standar yang ada dan memiliki kapasitas yang dapat dialokasikan daripada membuat node baru untuk Pod Spot, Anda mungkin melihat lebih banyak Pod yang berjalan sebagai Pod standar daripada Pod Spot, sehingga Anda tidak bisa memanfaatkan sepenuhnya harga Pod Spot yang lebih rendah.
Permintaan untuk Pod yang dapat dihentikan
Cluster Autopilot mendukung permintaan untuk Pod yang dapat dihentikan menggunakan pemilih cloud.google.com/gke-preemptible
. Pod yang menggunakan pemilih ini
otomatis dimigrasikan ke Pod Spot, dan pemilih diubah menjadi
cloud.google.com/gke-spot
.
Menemukan dan menghapus Pod yang dihentikan
Selama penghentian Pod setelah selesai, kubelet menetapkan status Failed
dan
alasan Shutdown
ke Pod yang dihentikan. Saat jumlah Pod yang dihentikan
mencapai batas 1.000, pembersihan
sampah memori
akan membersihkan Pod. Anda juga dapat menghapus Pod shutdown secara manual menggunakan perintah berikut:
kubectl get pods --all-namespaces | grep -i shutdown | awk '{print $1, $2}' | xargs -n2 kubectl delete pod -n
Menghentikan workload agar tidak menggunakan Pod Spot
Jika sudah memiliki Pod Spot yang ingin diupdate agar berjalan sebagai Pod standar, Anda dapat menggunakan salah satu metode berikut:
- Buat ulang beban kerja: Hapus Deployment, hapus baris dalam manifes yang memilih Pod Spot, lalu terapkan manifes Deployment yang diperbarui ke cluster.
- Mengedit workload: Mengedit spesifikasi Deployment saat Pod berjalan di cluster.
Dengan kedua metode ini, Anda mungkin mengalami gangguan beban kerja kecil.
Membuat ulang workload
Langkah-langkah berikut menunjukkan cara menghapus Deployment yang ada dan menerapkan manifes yang diperbarui ke cluster. Anda juga dapat menggunakan langkah-langkah ini untuk jenis workload Kubernetes lainnya, seperti Tugas.
Untuk memastikan GKE menempatkan Pod yang diperbarui pada jenis node yang benar, Anda harus mengekspor status workload yang ada dari server Kubernetes API ke file dan mengedit file tersebut.
Tulis spesifikasi beban kerja ke file YAML:
kubectl get deployment DEPLOYMENT_NAME -o yaml > DEPLOYMENT_NAME-on-demand.yaml
Ganti
DEPLOYMENT_NAME
dengan nama deployment Anda. Untuk jenis workload lainnya, seperti Tugas atau Pod, gunakan nama resource yang sesuai dalam perintahkubectl get
, sepertikubectl get pod
.Buka file YAML di editor teks:
vi DEPLOYMENT_NAME-on-demand.yaml
Hapus nodeSelector untuk Pod Spot dan toleransi yang ditambahkan GKE untuk Pod Spot dari file:
apiVersion: apps/v1 kind: Deployment metadata: annotations: # lines omitted for clarity spec: progressDeadlineSeconds: 600 replicas: 6 revisionHistoryLimit: 10 selector: matchLabels: pod: nginx-pod strategy: rollingUpdate: maxSurge: 25% maxUnavailable: 25% type: RollingUpdate template: metadata: # lines omitted for clarity spec: containers: - image: nginx imagePullPolicy: Always name: web-server resources: limits: ephemeral-storage: 1Gi requests: cpu: 500m ephemeral-storage: 1Gi memory: 2Gi securityContext: capabilities: drop: - NET_RAW terminationMessagePath: /dev/termination-log terminationMessagePolicy: File dnsPolicy: ClusterFirst nodeSelector: cloud.google.com/gke-spot: "true" restartPolicy: Always schedulerName: default-scheduler securityContext: seccompProfile: type: RuntimeDefault terminationGracePeriodSeconds: 15 tolerations: - effect: NoSchedule key: kubernetes.io/arch operator: Equal value: amd64 - effect: NoSchedule key: cloud.google.com/gke-spot operator: Equal value: "true" status: #lines omitted for clarity
Anda harus menghapus toleransi dan nodeSelector untuk menunjukkan kepada GKE bahwa Pod harus berjalan di node on-demand, bukan di node Spot.
Simpan manifes yang diperbarui.
Hapus dan terapkan ulang manifes Deployment ke cluster:
kubectl replace -f DEPLOYMENT_NAME-on-demand.yaml
Durasi operasi ini bergantung pada jumlah Pod yang perlu dihentikan dan dibersihkan oleh GKE.
Mengedit beban kerja di tempat
Langkah-langkah berikut menunjukkan cara mengedit Deployment yang sedang berjalan di tempat untuk menunjukkan kepada GKE bahwa Pod harus berjalan di node on-demand. Anda juga dapat menggunakan langkah-langkah ini untuk jenis workload Kubernetes lainnya, seperti Tugas.
Anda harus mengedit objek workload di Kubernetes API karena GKE secara otomatis menambahkan toleransi untuk Pod Spot ke spesifikasi workload selama penerimaan workload.
Buka manifes beban kerja Anda untuk diedit di editor teks:
kubectl edit deployment/DEPLOYMENT_NAME
Ganti
DEPLOYMENT_NAME
dengan nama Deployment. Untuk jenis workload lainnya, seperti Tugas atau Pod, gunakan nama resource yang sesuai dalam perintahkubectl edit
, sepertikubectl edit pod/POD_NAME
.Di editor teks, hapus pemilih node atau aturan afinitas node untuk Pod Spot dan toleransi yang ditambahkan GKE ke manifes, seperti dalam contoh berikut:
apiVersion: apps/v1 kind: Deployment metadata: name: example-deployment namespace: default spec: replicas: 1 selector: matchLabels: type: dev template: metadata: labels: type: dev spec: nodeSelector: cloud.google.com/gke-spot: "true" tolerations: - effect: NoSchedule key: cloud.google.com/gke-spot operator: Equal value: "true" containers: - name: nginx image: nginx ports: - containerPort: 80
Simpan manifes yang diperbarui dan tutup editor teks. Konfigurasi objek yang diperbarui menunjukkan kepada GKE bahwa Pod harus berjalan di node on demand. GKE membuat ulang Pod untuk menempatkannya di node on-demand baru.
Memverifikasi bahwa workload berjalan di node on-demand
Untuk memverifikasi bahwa workload yang diperbarui tidak lagi berjalan di Spot Pod, periksa workload dan cari toleransi untuk Spot Pod:
Periksa workload:
kubectl describe deployment DEPLOYMENT_NAME
Output tidak menampilkan entri untuk cloud.google.com/gke-spot
di kolom spec.tolerations
.
Langkah selanjutnya
- Pelajari arsitektur cluster Autopilot lebih lanjut.
- Pelajari siklus proses Pod.
- Baca tentang VM Spot di cluster GKE Standard.