Menyelesaikan masalah startup 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 dimulai dengan proxy tanpa distro saat port dengan hak istimewa diekspos
Secara default, proxy distroless dimulai dengan izin non-root yang dalam beberapa kasus dapat menyebabkan kegagalan pengikatan pada port dengan 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 beban kerja aplikasi Anda.
Hal ini dapat terjadi saat beban kerja aplikasi Anda dimulai lebih cepat daripada
penampung istio-proxy (Envoy
) dan mencoba menjangkau endpoint 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 ini adalah error yang Anda alami:
Periksa log stackdriver dengan Filter berikut untuk mengidentifikasi pod mana yang mengalami masalah.
Contoh berikut menunjukkan pesan error standar:
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 ECONNREFUSED
Telusuri kemunculan masalah. Jika Anda menggunakan Stackdriver lama, gunakan
resource.type="container"
.resource.type="k8s_container" textPayload:"$ERROR_MESSAGE$"
Luaskan kemunculan terbaru untuk mendapatkan nama pod, lalu catat
pod_name
di 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-g7fvb
Catat stempel waktu error 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 error dan peristiwa startup istio-proxy untuk mengonfirmasi bahwa error terjadi saat
Envoy
belum 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.552128897Z
, tetapi pada2020-03-31T10:41:58Z
, istio-proxy masih gagal dalam pemeriksaan kesiapan.Meskipun container istio-proxy dimulai terlebih dahulu, ada kemungkinan bahwa container tersebut tidak siap dengan cukup cepat sebelum aplikasi mencoba terhubung ke endpoint eksternal.
Jika ini adalah masalah yang Anda alami, lanjutkan dengan langkah-langkah pemecahan masalah berikut.
Anotasikan konfigurasi di tingkat pod. Fitur ini hanya tersedia di tingkat pod, bukan di tingkat global.
annotations: proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
Ubah kode aplikasi agar memeriksa apakah
Envoy
sudah siap sebelum mencoba membuat permintaan lain ke layanan eksternal. Misalnya, saat aplikasi dimulai, mulai loop yang membuat permintaan ke endpoint kesehatan istio-proxy dan hanya dilanjutkan setelah 200 diperoleh. Endpoint status istio-proxy adalah sebagai berikut:http://localhost:15020/healthz/ready
Kondisi perlombaan selama injeksi sidecar antara Vault dan Cloud Service Mesh
Saat menggunakan vault
untuk pengelolaan secret, terkadang vault
memasukkan sidecar
sebelum istio
, sehingga Pod macet dalam status Init
. Jika hal ini terjadi, Pod yang dibuat akan terjebak dalam status Init setelah memulai ulang deployment atau men-deploy deployment 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 perlombaan, Istio dan vault
memasukkan
sidecar dan Istio harus menjadi yang terakhir melakukannya, proxy istio
tidak berjalan
selama penampung init. Penampung init istio
menyiapkan aturan iptables untuk
mengarahkan semua traffic ke proxy. Karena belum berjalan, aturan tersebut
akan mengalihkan ke mana pun, sehingga memblokir semua traffic. Inilah sebabnya container init harus
menjadi yang terakhir, sehingga proxy langsung aktif dan berjalan setelah aturan iptables
disiapkan. Sayangnya, urutan ini tidak deterministik, sehingga jika Istio dimasukkan
terlebih dahulu, Istio akan rusak.
Untuk memecahkan masalah kondisi ini, izinkan alamat IP vault
sehingga traffic
yang menuju ke IP Vault tidak dialihkan ke Envoy Proxy yang belum
siap sehingga memblokir komunikasi. Untuk mendapatkannya, anotasi baru
yang 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 bagian spec.values.global.proxy.excludeIPRanges
, misalnya:
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
values:
global:
proxy:
excludeIPRanges: ""
Setelah menambahkan anotasi, mulai ulang beban kerja Anda.