Waktu startup pod
Bagian ini menjelaskan masalah umum Cloud Service Mesh terkait waktu startup pod dan cara mengatasinya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.
Sinkronisasi konfigurasi Envoy dan pengaktifan pod
Masalah umum yang diamati selama startup pod di beberapa lingkungan Cloud Service Mesh dan Istio melibatkan sinkronisasi antara kesiapan aplikasi dan konfigurasi proxy Envoy. Masalah ini muncul dari startup serentak penampung aplikasi dan sidecar Envoy. Aplikasi dapat memberikan sinyal kesiapan sebelum proxy Envoy menyelesaikan inisialisasi dan menerima konfigurasinya dari bidang kontrol. Hal ini akan menciptakan kondisi perlombaan saat permintaan masuk diarahkan ke proxy Envoy yang tidak dikonfigurasi dan belum siap untuk menerima traffic apa pun. Hal ini dapat menyebabkan permintaan dihapus, salah dirutekan, atau ditangani dengan tidak benar selama fase awal startup aplikasi, karena tidak ada sidecar untuk meneruskan traffic apa pun.
Strategi mitigasi
Bagian berikut menjelaskan metode yang dapat mengurangi masalah ini.
Konfigurasi mesh global: holdApplicationUntilProxyStarts
Opsi pertama adalah menetapkan holdApplicationUntilProxyStarts: true dalam konfigurasi mesh
Istio. Perhatikan bahwa setelan ini nonaktif secara default. Flag ini menambahkan hook untuk menunda
startup aplikasi hingga proxy pod siap menerima traffic.
Menambahkan konfigurasi akan menghilangkan perlombaan ini, tetapi dapat menyebabkan penundaan waktu kesiapan aplikasi untuk pod baru jika sebelumnya tidak diaktifkan.
Pemeriksaan kesiapan
Solusi lainnya adalah menerapkan pemeriksaan kesiapan yang menggabungkan health check aplikasi dan Envoy. Pemeriksaan kesiapan memberi tahu Kubernetes saat pod siap menerima traffic. Secara kritis, logika probe kesiapan tidak hanya harus memverifikasi kesiapan aplikasi, tetapi juga status proxy Envoy. Hal ini dapat dilakukan dengan mengkueri port administrator Envoy untuk status kesehatannya. Dengan menggabungkan kedua pemeriksaan tersebut, Kubernetes mencegah traffic diarahkan ke pod hingga aplikasi dan Envoy diinisialisasi dan dikonfigurasi sepenuhnya.
Pendekatan ini lebih fleksibel dan memungkinkan logika startup dan kesiapan yang lebih rumit, tetapi dengan mengorbankan kompleksitas yang lebih tinggi.
Buat file healthcheck.sh dari kode berikut:
#!/bin/sh
APP_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:8080/health)
ENVOY_HEALTH=$(curl -s -o /dev/null -w "%{http_code}" \
http://localhost:9901/ready)
if [[ "$APP_HEALTH" -eq 200 && "$ENVOY_HEALTH" -eq 200 ]]; then
exit 0
else
exit 1
fi
Ganti IP/port dengan penampung aplikasi dan Envoy Anda.
File YAML berikut menentukan pemeriksaan kesiapan yang menggunakan skrip yang sebelumnya Anda buat:
apiVersion: v1
kind: Pod
metadata:
name: my-app-with-envoy
spec:
containers:
- name: application
<…>
readinessProbe:
initialDelaySeconds: 15
periodSeconds: 10
failureThreshold: 3
exec:
command:
- /healthcheck.sh # using the script
- name: envoy
<…>