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.

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 bagian resource.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 pada 2020-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.