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:

  1. 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 ECONNREFUSED
    
  2. Telusuri kemunculan masalah. Jika Anda menggunakan Stackdriver versi lama, gunakan resource.type="container".

    resource.type="k8s_container"
    textPayload:"$ERROR_MESSAGE$"
    
  3. Luaskan kemunculan terbaru untuk mendapatkan nama pod, lalu catat pod_name di bagian resource.labels.

  4. 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
    
  5. Catatlah stempel waktu dari kesalahan pertama untuk pod ini.

  6. 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}
    
  7. Gunakan stempel waktu kesalahan dan peristiwa startup istio-proxy untuk memastikan kesalahan terjadi ketika 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 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.

  8. Anotasikan konfigurasi di tingkat pod. Fitur ini hanya tersedia di tingkat pod dan tidak di tingkat global.

    annotations:
    proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
    
  9. Ubah kode aplikasi sehingga memeriksa apakah Envoy sudah 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-distroless di dalam tag atau sufiks, ia menggunakandefault gambar.
  • Jika jalur gambar berisi -distroless dalam tag atau akhiran, gambar tersebut menggunakan gambar distroless.

Verifikasi Maksud Konfigurasi

Jenis gambar dapat dikonfigurasi dengan dua cara (Anotasi lebih diutamakan daripada MeshConfig):

  1. 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"]}'
    
  2. MeshConfig: Periksa setelan defaultConfig.image.imageType di ConfigMap istio-RELEASE_CHANNEL Anda dalam namespace istio-system.

Catatan: Untuk cluster dengan bidang kontrol TRAFFIC_DIRECTOR terkelola:

  • Untuk cluster yang disediakan langsung dengan bidang kontrol TRAFFIC_DIRECTOR terkelola, hanya image distroless yang 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 image default, tetapi Anda dapat memilih untuk menggunakan distroless menggunakan MeshConfig atau anotasi pod. Penggantian jenis gambar lainnya (seperti debug) tidak didukung.