Mengatasi masalah saat memulai beban kerja di Cloud Service Mesh
Dokumen ini menjelaskan masalah umum Cloud Service Mesh dan cara mengatasinya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.
Gateway gagal memulai dengan proxy tanpa distribusi ketika port istimewa terekspos.
Secara default, proxy tanpa distro dimulai dengan izin non-root yang dalam beberapa kasus dapat menyebabkan kegagalan pengikatan pada port yang memiliki hak istimewa. Jika Anda melihat error yang mirip dengan berikut selama startup proxy, securityContext tambahan perlu diterapkan untuk deployment gateway.
Error adding/updating listener(s) 0.0.0.0_80: cannot bind '0.0.0.0:80': Permission denied
Contoh berikut adalah yaml untuk deployment gateway keluar:
apiVersion: apps/v1
kind: Deployment
metadata:
name: istio-egressgateway
spec:
selector:
matchLabels:
app: istio-egressgateway
istio: egressgateway
template:
metadata:
annotations:
# This is required to tell Anthos Service Mesh to inject the gateway with the
# required configuration.
inject.istio.io/templates: gateway
labels:
app: istio-egressgateway
istio: egressgateway
spec:
containers:
- name: istio-proxy
image: auto # The image will automatically update each time the pod starts.
resources:
limits:
cpu: 2000m
memory: 1024Mi
requests:
cpu: 100m
memory: 128Mi
# Allow binding to all ports (such as 80 and 443)
securityContext:
sysctls:
- name: net.ipv4.ip_unprivileged_port_start
value: "0"
serviceAccountName: istio-egressgateway
Koneksi Ditolak saat mencapai endpoint Cloud Service Mesh
Anda mungkin mengalami error koneksi ditolak (ECONNREFUSED) secara berkala
dengan komunikasi dari cluster ke endpoint, misalnya
Memorystore Redis, Cloud SQL, atau layanan eksternal apa pun yang perlu dijangkau oleh beban kerja
aplikasi Anda.
Hal ini dapat terjadi ketika beban kerja aplikasi Anda dimulai lebih cepat daripada kontainer istio-proxy (Envoy) dan mencoba mencapai titik akhir eksternal. Karena
pada tahap ini istio-init (initContainer) telah dijalankan, ada
aturan iptables yang mengalihkan semua traffic keluar ke Envoy. Karena
istio-proxy belum siap, aturan iptables akan mengalihkan traffic ke
proxy sidecar yang belum dimulai, sehingga aplikasi mendapatkan error
ECONNREFUSED.
Langkah-langkah berikut menjelaskan cara memeriksa apakah error ini adalah error yang Anda alami:
Periksa log stackdriver dengan Filter berikut untuk mengidentifikasi pod mana yang mengalami masalah.
Contoh berikut menunjukkan pesan error umum:
Error: failed to create connection to feature-store redis, err=dial tcp 192.168.9.16:19209: connect: connection refused [ioredis] Unhandled error event: Error: connect ECONNREFUSEDTelusuri kemunculan masalah. Jika Anda menggunakan Stackdriver versi lama, gunakan
resource.type="container".resource.type="k8s_container" textPayload:"$ERROR_MESSAGE$"Luaskan kemunculan terbaru untuk mendapatkan nama pod, lalu catat
pod_namedi bagianresource.labels.Dapatkan kemunculan pertama masalah untuk pod tersebut:
resource.type="k8s_container" resource.labels.pod_name="$POD_NAME$"Contoh output:
E 2020-03-31T10:41:15.552128897Z post-feature-service post-feature-service-v1-67d56cdd-g7fvb failed to create connection to feature-store redis, err=dial tcp 192.168.9.16:19209: connect: connection refused post-feature-service post-feature-service-v1-67d56cdd-g7fvbCatatlah stempel waktu dari kesalahan pertama untuk pod ini.
Gunakan filter berikut untuk melihat peristiwa startup pod.
resource.type="k8s_container" resource.labels.pod_name="$POD_NAME$"Contoh output:
I 2020-03-31T10:41:15Z spec.containers{istio-proxy} Container image "docker.io/istio/proxyv2:1.3.3" already present on machine spec.containers{istio-proxy} I 2020-03-31T10:41:15Z spec.containers{istio-proxy} Created container spec.containers{istio-proxy} I 2020-03-31T10:41:15Z spec.containers{istio-proxy} Started container spec.containers{istio-proxy} I 2020-03-31T10:41:15Z spec.containers{APP-CONTAINER-NAME} Created container spec.containers{APP-CONTAINER-NAME} W 2020-03-31T10:41:17Z spec.containers{istio-proxy} Readiness probe failed: HTTP probe failed with statuscode: 503 spec.containers{istio-proxy} W 2020-03-31T10:41:26Z spec.containers{istio-proxy} Readiness probe failed: HTTP probe failed with statuscode: 503 spec.containers{istio-proxy} W 2020-03-31T10:41:28Z spec.containers{istio-proxy} Readiness probe failed: HTTP probe failed with statuscode: 503 spec.containers{istio-proxy} W 2020-03-31T10:41:31Z spec.containers{istio-proxy} Readiness probe failed: HTTP probe failed with statuscode: 503 spec.containers{istio-proxy} W 2020-03-31T10:41:58Z spec.containers{istio-proxy} Readiness probe failed: HTTP probe failed with statuscode: 503 spec.containers{istio-proxy}Gunakan stempel waktu kesalahan dan peristiwa startup istio-proxy untuk memastikan kesalahan terjadi ketika
Envoybelum siap.Jika error terjadi saat penampung istio-proxy belum siap, error koneksi ditolak adalah hal yang normal. Pada contoh sebelumnya, pod mencoba terhubung ke Redis segera setelah
2020-03-31T10:41:15.552128897Ztetapi pada2020-03-31T10:41:58Z, istio-proxy masih gagal melakukan pemeriksaan kesiapan.Meskipun container istio-proxy dimulai terlebih dahulu, ada kemungkinan container tersebut tidak siap cukup cepat sebelum aplikasi mencoba terhubung ke endpoint eksternal.
Jika ini adalah masalah yang Anda alami, lanjutkan ke langkah-langkah pemecahan masalah berikut.
Anotasikan konfigurasi di tingkat pod. Fitur ini hanya tersedia di tingkat pod dan tidak di tingkat global.
annotations: proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'Ubah kode aplikasi sehingga memeriksa apakah
Envoysudah siap sebelum mencoba membuat permintaan lain ke layanan eksternal. Misalnya, saat aplikasi dimulai, inisiasi loop yang membuat permintaan ke endpoint kesehatan istio-proxy dan hanya berlanjut setelah respons 200 diperoleh. Endpoint istio-proxy health adalah sebagai berikut:http://localhost:15020/healthz/ready
Kondisi persaingan selama penyisipan container bantuan antara Vault dan Cloud Service Mesh
Saat menggunakan vault untuk pengelolaan rahasia, terkadang vault menyuntikkan sidecar
sebelum istio, sehingga menyebabkan Pod tersebut macet dalam status Init. Jika hal ini terjadi, Pod yang dibuat akan macet dalam status Init setelah memulai ulang deployment apa pun atau men-deploy yang baru. Contoh:
E 2020-03-31T10:41:15.552128897Z
post-feature-service post-feature-service-v1-67d56cdd-g7fvb failed to create
connection to feature-store redis, err=dial tcp 192.168.9.16:19209: connect:
connection refused post-feature-service post-feature-service-v1-67d56cdd-g7fvb
Masalah ini disebabkan oleh kondisi race, Istio dan vault menyuntikkan sidecar dan Istio harus menjadi yang terakhir melakukannya, proxy istio tidak berjalan selama init container. Kontainer init istio menyiapkan aturan iptables untuk
mengarahkan semua traffic ke proxy. Karena belum berjalan, aturan tersebut tidak mengalihkan ke mana pun, sehingga memblokir semua traffic. Itulah sebabnya container init harus
menjadi yang terakhir, sehingga proxy dapat langsung berjalan setelah aturan iptables
disiapkan. Sayangnya, urutannya tidak deterministik, jadi jika Istio disuntikkan terlebih dahulu, hal ini akan merusak.
Untuk memecahkan masalah kondisi ini, izinkan alamat IP vault sehingga traffic yang menuju IP Vault tidak dialihkan ke Proxy Envoy yang belum siap dan oleh karena itu memblokir komunikasi. Untuk mencapai hal ini, anotasi baru bernama excludeOutboundIPRanges harus ditambahkan.
Untuk Cloud Service Mesh terkelola, hal ini hanya dapat dilakukan di tingkat Deployment atau Pod
di bagian spec.template.metadata.annotations, misalnya:
apiVersion: apps/v1
kind: Deployment
...
...
...
spec:
template:
metadata:
annotations:
traffic.sidecar.istio.io/excludeOutboundIPRanges:
Untuk Cloud Service Mesh dalam cluster, ada opsi untuk menyetelnya sebagai global dengan IstioOperator di spec.values.global.proxy.excludeIPRanges, misalnya:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
global:
proxy:
excludeIPRanges: ""
Setelah menambahkan anotasi, mulai ulang workload Anda.
Mengidentifikasi jenis gambar proxy yang digunakan dalam cluster
Untuk mengidentifikasi jenis gambar proxy (default atau distroless) yang digunakan pod tertentu, Anda dapat memeriksa spesifikasi pod.
Jalankan perintah berikut untuk memeriksa citra yang digunakan oleh kontainer istio-proxy:
kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.spec.containers[?(@.name=="istio-proxy")].image}'
- Jika jalur gambar tidak berisi
-distrolessdi dalam tag atau sufiks, ia menggunakandefaultgambar. - Jika jalur gambar berisi
-distrolessdalam tag atau akhiran, gambar tersebut menggunakan gambardistroless.
Verifikasi Maksud Konfigurasi
Jenis gambar dapat dikonfigurasi dengan dua cara (Anotasi lebih diutamakan daripada MeshConfig):
Anotasi Pod: Periksa apakah pod memiliki anotasi
sidecar.istio.io/proxyImageType.kubectl get pod POD_NAME -n NAMESPACE -o jsonpath='{.metadata.annotations["sidecar.istio.io/proxyImageType"]}'MeshConfig: Periksa setelan
defaultConfig.image.imageTypedi ConfigMapistio-RELEASE_CHANNELAnda dalam namespaceistio-system.
Catatan: Untuk cluster dengan bidang kontrol TRAFFIC_DIRECTOR terkelola:
- Untuk cluster yang disediakan langsung dengan bidang kontrol
TRAFFIC_DIRECTORterkelola, hanya imagedistrolessyang didukung. Penggantian jenis gambar lainnya akan diabaikan. - Untuk cluster yang dimigrasikan ke bidang kontrol
TRAFFIC_DIRECTOR(seperti yang dimigrasikan dari CSM-ISTIOD), jenis image secara default adalah imagedefault, tetapi Anda dapat memilih untuk menggunakandistrolessmenggunakanMeshConfigatau anotasi pod. Penggantian jenis gambar lainnya (sepertidebug) tidak didukung.