Menyelesaikan masalah pengelolaan traffic di Cloud Service Mesh

Bagian ini menjelaskan masalah umum Cloud Service Mesh dan cara menyelesaikannya. Jika Anda memerlukan bantuan tambahan, lihat Mendapatkan dukungan.

Error koneksi server API di log istiod

Istiod tidak dapat menghubungi apiserver jika Anda melihat error yang serupa dengan berikut:

error k8s.io/client-go@v0.18.0/tools/cache/reflector.go:125: Failed to watch *crd.IstioSomeCustomResource`…dial tcp 10.43.240.1:443: connect: connection refused

Anda dapat menggunakan string ekspresi reguler /error.*cannot list resource/ untuk menemukan error ini dalam log.

Error ini biasanya bersifat sementara dan jika Anda mengakses log proxy menggunakan kubectl, masalahnya mungkin sudah teratasi. Error ini biasanya disebabkan oleh peristiwa yang membuat server API tidak tersedia untuk sementara, seperti saat server API yang tidak dalam konfigurasi ketersediaan tinggi melakukan booting ulang untuk upgrade atau perubahan penskalaan otomatis.

Container istio-init mengalami error

Masalah ini dapat terjadi saat aturan iptables pod tidak diterapkan ke namespace jaringan pod. Hal ini dapat disebabkan oleh:

  • Penginstalan istio-cni yang tidak lengkap
  • Izin pod beban kerja tidak memadai (izin CAP_NET_ADMIN tidak ada)

Jika Anda menggunakan plugin CNI Istio, pastikan Anda telah mengikuti petunjuknya secara lengkap. Pastikan container istio-cni-node sudah siap, dan periksa log. Jika masalah berlanjut, buat secure shell (SSH) ke node host dan cari perintah nsenter di log node, lalu periksa apakah ada error.

Jika Anda tidak menggunakan plugin CNI Istio, pastikan pod workload memiliki izin CAP_NET_ADMIN, yang ditetapkan secara otomatis oleh injector sidecar.

Koneksi ditolak setelah pod dimulai

Saat Pod dimulai dan mendapatkan connection refused yang mencoba terhubung ke endpoint, masalahnya mungkin karena container aplikasi dimulai sebelum container isto-proxy. Dalam hal ini, container aplikasi mengirimkan permintaan ke istio-proxy, tetapi koneksi ditolak karena istio-proxy belum memproses port.

Dalam hal ini, Anda dapat:

  • Ubah kode startup aplikasi Anda untuk membuat permintaan berkelanjutan ke endpoint health istio-proxy hingga aplikasi menerima kode 200. Endpoint health istio-proxy adalah:

    http://localhost:15020/healthz/ready

  • Tambahkan mekanisme permintaan percobaan ulang ke beban kerja aplikasi Anda.

Listing gateways menampilkan hasil kosong

Gejala: Saat Anda mencantumkan Gateway menggunakan kubectl get gateway --all-namespaces setelah berhasil membuat Gateway Cloud Service Mesh, perintah akan menampilkan No resources found.

Masalah ini dapat terjadi di GKE 1.20 dan yang lebih baru karena pengontrol GKE Gateway otomatis menginstal resource Gateway.networking.x-k8s.io/v1alpha1 GKE di cluster. Untuk mengatasi masalah ini:

  1. Periksa apakah ada beberapa resource kustom gateway di cluster:

    kubectl api-resources | grep gateway

    Contoh output: 

    gateways                          gw           networking.istio.io/v1beta1            true         Gateway
gatewayclasses                    gc           networking.x-k8s.io/v1alpha1           false        GatewayClass
gateways                          gtw          networking.x-k8s.io/v1alpha1           true         Gateway

  2. Jika daftar menampilkan entri selain Gateway dengan apiVersion networking.istio.io/v1beta1, gunakan nama resource lengkap atau nama pendek yang dapat dibedakan dalam perintah kubectl. Misalnya, jalankan kubectl get gw atau kubectl get gateways.networking.istio.io, bukan kubectl get gateway untuk memastikan Gateway istio tercantum.

Untuk mengetahui informasi selengkapnya tentang masalah ini, lihat Gateway Kubernetes dan Gateway Istio.

Proxy Envoy mengalami hang saat inisialisasi

Jika log debug menunjukkan bahwa proxy Envoy mengalami error saat inisialisasi, Anda dapat menggunakan perintah berikut untuk mengidentifikasi apa yang memblokir proses:

kubectl -n <ns> -c istio-proxy exec -it POD_NAME -- /usr/local/bin/pilot-agent request POST /init_dump

Memecahkan masalah error respons HTTP 5xx

Anda mungkin mengalami error respons HTTP 5xx saat mengakses aplikasi melalui Istio Ingress Gateway. Ikuti langkah-langkah berikut untuk mendiagnosis dan menyelesaikan masalah.

  1. Mengidentifikasi bidang kontrol
  2. Memverifikasi potensi kesalahan konfigurasi
  3. Memverifikasi penemuan pod
  4. Menganalisis log akses

Mengidentifikasi bidang kontrol

Tentukan versi dan konfigurasi panel kontrol karena versi yang berbeda dapat memengaruhi proses diagnostik. Untuk memverifikasi status panel kontrol terkelola, jalankan perintah berikut:

gcloud container fleet mesh describe --project PROJECT_ID

Status ACTIVE menunjukkan bahwa bidang kontrol terkelola berjalan normal.

Memverifikasi potensi kesalahan konfigurasi

Kesalahan konfigurasi umum dapat menyebabkan kegagalan perutean:

  • Ketidakcocokan Namespace: VirtualService harus berada di namespace yang sama dengan layanan GKE backend.
  • Ketidakcocokan Referensi Gateway: VirtualService harus secara eksplisit mereferensikan Gateway yang benar. Misalnya, jika VirtualService mereferensikan istio-system/istio-ingressgateway, tetapi gateway berada di namespace default, traffic tidak akan dirutekan dengan benar.

Memverifikasi penemuan pod

Pastikan pod aplikasi ditemukan dengan benar oleh mesh:

istioctl proxy-config endpoints POD_NAME

Menganalisis log akses

Aktifkan log akses untuk menentukan apakah error berasal dari aplikasi backend atau proxy. Kolom utama mencakup RESPONSE_FLAGS, UPSTREAM_LOCAL_ADDRESS, dan RESPONSE_CODE.

Jika log menunjukkan error upstream, lakukan pengujian curl langsung ke layanan GKE dari pod di namespace yang sama. Jika permintaan curl menampilkan error 5xx yang sama, masalahnya berasal dari aplikasi backend itu sendiri.

Memecahkan masalah sertifikat SSL

Error sertifikat SSL di Istio Ingress Gateway dapat disebabkan oleh sertifikat yang masa berlakunya telah habis, ketidakcocokan protokol, atau konfigurasi rahasia yang salah.

Mengidentifikasi error SSL

Tinjau log dari pod Istio Ingress Gateway:

kubectl logs -l app=istio-ingressgateway -n GATEWAY_NAMESPACE

Verifikasi sertifikat dan kunci

Pastikan sertifikat dan kunci pribadi valid dan cocok menggunakan hash MD5:

openssl x509 -noout -modulus -in CERTIFICATE.CRT | openssl md5
openssl rsa -noout -modulus -in PRIVATE_KEY | openssl md5

Pastikan masa berlaku sertifikat belum habis dan Nama Umum (CN) atau Nama Alternatif Subjek (SAN) cocok dengan domain.

Memeriksa konfigurasi rahasia dan protokol TLS

Verifikasi versi TLS dan cipher suite di CRD Gateway. Pastikan secret Kubernetes yang berisi sertifikat dan kunci berada di namespace yang sama dengan Ingress Gateway dan credentialName cocok dengan nama secret.

Memecahkan masalah waktu tunggu terputus-putus ke endpoint eksternal

Waktu tunggu habis yang terjadi sesekali dapat terjadi saat permintaan dibuat ke endpoint eksternal (seperti NLB Pihak ketiga) yang di-resolve ke beberapa alamat IP.

Kemungkinan penyebab: Resolusi ServiceEntry

Jika spec.resolution disetel ke DNS, Istio akan menggunakan "DNS ketat", yang menyeimbangkan beban di semua alamat IP yang di-resolve. Beberapa NLB tidak mendukung hal ini.

Resolusi

Untuk mengatasinya, setel resolusi di ServiceEntry ke DNS_ROUND_ROBIN.

Memecahkan masalah distribusi traffic yang tidak merata

Jika traffic tidak didistribusikan secara merata di seluruh pod aplikasi, periksa hal berikut:

  • Kondisi Pod: Pastikan semua pod aplikasi berfungsi dengan baik selama ketidakseimbangan.
  • Algoritma Load Balancing: Tinjau konfigurasi DestinationRule untuk setelan loadBalancer (misalnya, consistentHash atau ROUND_ROBIN).
  • Penyeimbangan Beban Lokalitas: Verifikasi apakah localityLbSetting diaktifkan. Perhatikan bahwa ini tidak didukung dengan bidang kontrol TRAFFIC_DIRECTOR.

Memecahkan masalah propagasi layanan dan masalah kuota

Jika layanan atau konfigurasi jaringan baru tidak tercermin dalam mesh, hal ini mungkin disebabkan oleh kuota resource yang telah tercapai dalam project armada.

Gejala

  • Konfigurasi jaringan (seperti VirtualService atau DestinationRule) tidak didorong ke proxy sidecar.
  • Layanan baru tampak "tidak terlihat" oleh mesh meskipun telah ditentukan dengan benar.

Langkah-langkah untuk mengidentifikasi dan menyelesaikan masalah

  1. Periksa kuota resource: Verifikasi apakah project armada telah mencapai kuotanya untuk resource BackendService dengan memeriksa kuota layanan backend pengarah traffic internal global di project armada. Cloud Service Mesh biasanya membuat satu BackendService per port layanan Kubernetes.
  2. Tinjau batasan penskalaan: Pastikan konfigurasi Anda tetap berada dalam batasan penskalaan yang didukung untuk Cloud Service Mesh.
  3. Menambah kuota: Jika kuota telah tercapai, minta penambahan untuk resource yang terpengaruh di project armada untuk memulihkan propagasi layanan normal.

Memecahkan masalah evaluasi VirtualService

Jika VirtualService tidak berfungsi seperti yang diharapkan, ingatlah bahwa rute dievaluasi dalam urutan yang tercantum. Jika Anda memiliki beberapa Layanan Virtual untuk host yang sama, rutenya akan digabungkan. Rute dari Virtual Service "lama" diprioritaskan, sehingga ditempatkan sebelum rute dari Virtual Service "baru" dalam daftar gabungan. Hal ini memperkuat aturan "kecocokan pertama".

Memecahkan masalah load balancing lokalitas

Secara default, load balancing lokalitas mengarahkan traffic klien ke endpoint di zona yang sama (zona utama, atau Prioritas 0). Envoy hanya merutekan traffic ke zona failover (Prioritas 1 atau lebih tinggi) saat endpoint di zona utama tidak responsif atau tidak tersedia.

Jika Anda tidak menskalakan endpoint untuk menangani seluruh beban zona atau jika Anda lebih memilih untuk membagi traffic di seluruh zona, lakukan salah satu tindakan berikut:

  • Menskalakan pod di zona masing-masing untuk menangani beban traffic lokal.
  • Nonaktifkan setelan load balancing lokalitas.

Mengidentifikasi setelan load balancing lokalitas

Load balancing lokalitas mengandalkan label topologi node untuk mengelompokkan endpoint. Untuk memverifikasi label node dan memeriksa setelan, gunakan perintah berikut:

  • Verifikasi label topologi node:

    kubectl get nodes -o custom-columns=NAME:.metadata.name,\
    REGION:.metadata.labels."topology\\.kubernetes\\.io/region",\
    ZONE:.metadata.labels."topology\\.kubernetes\\.io/zone"

  • Untuk DestinationRule GKE, periksa setelan lokalitas:

    kubectl get destinationrule DESTINATION_RULE_NAME -o yaml

    Cari localityLbSetting: enabled: true di output.

  • Untuk memeriksa endpoint, prioritas, dan kondisi proxy Envoy:

    istioctl proxy-config endpoints POD_NAME.NAMESPACE \
    --cluster "outbound|PORT||SERVICE_FQDN" -o json

    Cari kolom priority di konfigurasi endpoint.

  • Untuk melihat konfigurasi cluster aktif yang mendetail:

    istioctl proxy-config cluster POD_NAME.NAMESPACE \
    --fqdn SERVICE_FQDN -o json