Menyelesaikan masalah pengelolaan traffic di Anthos Service Mesh

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

Error koneksi server API dalam log Istiod

Istiod tidak dapat menghubungi apiserver jika Anda melihat error yang mirip dengan hal 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 mencapai log proxy menggunakan kubectl, masalah ini mungkin sudah teratasi. Error ini biasanya disebabkan oleh peristiwa yang membuat server API tidak tersedia untuk sementara, seperti saat server API yang tidak berada dalam konfigurasi ketersediaan tinggi melakukan reboot untuk melakukan upgrade atau perubahan penskalaan otomatis.

Penampung istio-init mengalami error

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

  • Kebijakan Keamanan Pod (PSP) yang terlalu ketat
  • Instalasi istio-cni yang tidak lengkap
  • Izin pod beban kerja tidak memadai (izin CAP_NET_ADMIN tidak ada)

Jika Anda menggunakan Kebijakan Keamanan Pod yang membatasi izin CAP_NET_ADMIN, beralihlah untuk menggunakan plugin Istio CNI.

Jika menggunakan plugin Istio CNI, pastikan Anda mengikuti petunjuk sepenuhnya. Verifikasi bahwa penampung istio-cni-node sudah siap, lalu periksa log. Jika masalah berlanjut, buat shell aman (SSH) ke dalam node host dan telusuri perintah nsenter di log node, dan lihat apakah ada error.

Jika tidak menggunakan plugin Istio CNI atau Kebijakan Keamanan Pod, pastikan pod workload memiliki izin CAP_NET_ADMIN, yang otomatis disetel oleh injektor file bantuan.

Koneksi ditolak setelah pod dimulai

Saat Pod dimulai dan connection refused mencoba terhubung ke endpoint, masalahnya mungkin penampung aplikasi dimulai sebelum penampung isto-proxy. Dalam hal ini, penampung 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 kondisi istio-proxy adalah:

    http://localhost:15020/healthz/ready

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

Gateway listingan tidak menampilkan nilai apa pun

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

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

  1. Periksa apakah ada beberapa resource kustom gateway dalam 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 dicantumkan.

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