Secara default, sistem secara otomatis mencoba membuat ulang pod berbasis Elastic Container Instance setelah pembuatan pod gagal. Jika Anda ingin segera mendapatkan hasil pembuatan dan menangani kesalahan pada kesempatan pertama, Anda dapat memodifikasi kebijakan penanganan kesalahan pod tersebut.
Deskripsi konfigurasi
Pembuatan pod pada node virtual mungkin gagal karena sumber daya yang tidak mencukupi. Secara default, sistem secara otomatis menjadwalkan ulang sumber daya dan mencoba membuat ulang pod. Anda dapat menambahkan anotasi k8s.aliyun.com/eci-fail-strategy untuk mengonfigurasi kebijakan penanganan kesalahan pod dan menentukan apakah akan membuat ulang pod setelah pembuatan pod gagal.
Anotasi harus ditambahkan ke metadata dalam file konfigurasi pod. Sebagai contoh, ketika membuat Deployment, tambahkan anotasi di bagian spec.template.metadata.
Untuk menggunakan fitur Elastic Container Instance, Anda hanya dapat menambahkan anotasi saat membuat pod berbasis Elastic Container Instance. Jika Anda menambahkan atau memodifikasi anotasi saat memperbarui pod, anotasi tersebut tidak akan berlaku.
Tabel berikut menjelaskan nilai-nilai valid dari anotasi k8s.aliyun.com/eci-fail-strategy.
Nilai | Deskripsi | Skenario |
fail-back | Setelah pod gagal dibuat, sistem secara otomatis mencoba membuat ulang pod. Pod tetap dalam status Pending hingga berhasil dibuat ulang. Setelah pod dibuat ulang, status pod berubah menjadi Running. | Anda memerlukan tingkat keberhasilan yang tinggi dan dapat menerima pengiriman pod yang tertunda. |
fail-over | Efek fail-over dan fail-back sama. | |
fail-fast | Setelah pod gagal dibuat, sistem langsung melaporkan kesalahan. Pod berada dalam status ProviderFailed. Orkestrasi lapisan atas menentukan apakah sistem mencoba membuat ulang pod atau menjadwalkan pod ke node nyata. | Anda memerlukan efisiensi tinggi dan ingin segera mengirimkan pod. Sistem menyediakan logika penanganan kesalahan yang dioptimalkan. |
Jika anotasi
k8s.aliyun.com/eci-fail-strategy: "fail-fast"ditambahkan ke metadata dalam file konfigurasi pod berbasis Elastic Container Instance, provisioner tidak mendukung StorageClassWaitForFirstConsumerketika volume disk yang diprovision secara dinamis dipasang ke pod.Kami menyarankan agar Anda tidak menggunakan anotasi
k8s.aliyun.com/eci-reschedule-enableuntuk mengonfigurasi penjadwalan ulang.
Contoh konfigurasi
apiVersion: apps/v1
kind: Deployment
metadata:
name: test
labels:
app: test
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
name: nginx-test
labels:
app: nginx
alibabacloud.com/eci: "true"
annotations:
k8s.aliyun.com/eci-fail-strategy: "fail-fast" # Jika pod gagal dibuat, sistem langsung melaporkan kesalahan tanpa mencoba membuat ulang pod.
k8s.aliyun.com/eci-use-specs: "ecs.c6.large"
spec:
containers:
- name: nginx
image: registry.cn-shanghai.aliyuncs.com/eci_open/nginx:1.14.2
ports:
- containerPort: 80Dalam file YAML sampel di atas, kebijakan penanganan kesalahan pod adalah fail-fast. Jika pod tetap dalam status Pending untuk waktu yang lama, Anda dapat melihat pod status.reason.
Jika pod status.reason adalah ContainerInstanceScheduleFailed, pod gagal dijadwalkan. Dalam hal ini, Anda dapat melihat kondisi ContainerInstanceCreated dan mengidentifikasi penyebabnya berdasarkan reason dan message dari kondisi tersebut. Kemudian, Anda dapat mengambil tindakan yang sesuai, seperti memodifikasi spesifikasi pod dan mengonfigurasi beberapa zona untuk membuat pod. Untuk informasi lebih lanjut, lihat ContainerInstanceCreated.
Jika pod status.reason kosong, Anda dapat melihat kondisi ContainerInstanceCreated dan memeriksa status penjadwalan berdasarkan nilai kondisi tersebut. Dalam banyak kasus, jika kebijakan penanganan kesalahan adalah fail-fast, pod status.reason tidak kosong.
Jika nilai ContainerInstanceCreated adalah True, pod berhasil dijadwalkan dan terjadi pengecualian selama pembuatan sandbox.
Jika nilai ContainerInstanceCreated adalah False dan nilai reason bukan Creating, pod gagal dijadwalkan dan Anda harus menunggu pod dijadwalkan.
Sebagai contoh, pod gagal dibuat karena sumber daya yang tidak mencukupi. Kode sampel berikut memberikan contoh kondisi ContainerInstanceCreated ketika kebijakan penanganan kesalahan pod adalah fail-fast.
Jika kebijakan penanganan kesalahan pod adalah fail-back, sistem secara otomatis menjadwalkan ulang pod setelah pembuatan pod gagal. Dalam hal ini, pod status.reason bukan ContainerInstanceScheduleFailed. Anda dapat melihat kondisi ContainerInstanceCreated dan mengidentifikasi penyebab kegagalan penjadwalan dalam siklus penjadwalan saat ini berdasarkan reason dan message dari kondisi tersebut.
{
"conditions": [
{
"lastProbeTime": "2023-03-30T18:11:31Z",
"lastTransitionTime": "2023-03-30T18:11:31Z",
"message": "Create ECI failed because the specified instance is out of stock. %s",
"reason": "ContainerGroup.NoStock",
"status": "False",
"type": "ContainerInstanceCreated"
}
],
"Reason":"ContainerInstanceScheduleFailed",
"phase": "Pending"
}