Memecahkan masalah deployment Envoy

Panduan ini memberikan informasi untuk membantu Anda menyelesaikan masalah konfigurasi Traffic Director. Untuk informasi tentang cara menggunakan Client Status Discovery Service (CSDS) API guna membantu Anda menyelidiki masalah Traffic Director, lihat Memahami status klien Traffic Director.

Menentukan versi Envoy yang diinstal pada VM

Gunakan petunjuk ini untuk memverifikasi versi Envoy mana yang berjalan di instance virtual machine (VM).

Menentukan versi dengan deployment Envoy otomatis

Untuk memverifikasi atau memeriksa versi Envoy dengan deployment otomatis, Anda dapat melakukan hal berikut:

Periksa atribut tamu VM pada jalur gce-service-proxy/proxy-version:

gcloud compute --project cloud-vm-mesh-monitoring instances get-guest-attributes INSTANCE_NAME \
  --zone ZONE --query-path=gce-service-proxy/proxy-version

NAMESPACE          KEY            VALUE
gce-service-proxy  proxy-version  dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Periksa log instance Cloud Logging dari halaman Logging detail instance VM di Google Cloud Console dengan kueri seperti ini:

resource.type="gce_instance"
resource.labels.instance_id="3633122484352464042"
jsonPayload.message:"Envoy version"

Anda akan menerima respons seperti ini:

{
"insertId": "9zy0btf94961a",
"jsonPayload": {
  "message": "Envoy Version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
  "localTimestamp": "2021-01-12T11:39:14.3991Z"
},
"resource": {
  "type": "gce_instance",
  "labels": {
    "zone": "asia-southeast1-b",
    "instance_id": "3633122484352464042",
    "project_id": "cloud-vm-mesh-monitoring"
  }
},
"timestamp": "2021-01-12T11:39:14.399200504Z",
"severity": "INFO",
"logName": "projects/cloud-vm-mesh-monitoring/logs/service-proxy-agent",
"receiveTimestamp": "2021-01-12T11:39:15.407023427Z"
}

Gunakan SSH untuk terhubung ke VM dan periksa versi binernya:

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Gunakan SSH untuk terhubung ke VM dan antarmuka admin sebagai root:

root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
{
"version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
"state": "LIVE",
"hot_restart_version": "disabled",
...
}

Menentukan versi dengan deployment Envoy manual

Untuk memverifikasi atau memeriksa versi Envoy dengan deployment manual, Anda dapat melakukan hal berikut:

Gunakan SSH untuk terhubung ke VM dan periksa versi binernya:

YOUR_USER_NAME@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~$ /usr/local/bin/envoy --version

/usr/local/bin/envoy  version: dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL

Gunakan SSH untuk terhubung ke VM dan antarmuka admin sebagai root:

root@backend-mig-5f5651e1-517a-4269-b457-f6bdcf3d98bc-m3wt:~# curl localhost:15000/server_info
{
"version": "dc78069b10cc94fa07bb974b7101dd1b42e2e7bf/1.15.1-dev/Clean/RELEASE/BoringSSL",
"state": "LIVE",
"hot_restart_version": "disabled",
...
}

Lokasi log Envoy

Untuk memecahkan beberapa masalah, Anda perlu memeriksa log proxy Envoy.

Di Google Kubernetes Engine (GKE), proxy Envoy berjalan dengan Pod aplikasi. Anda melihat setiap error dalam log Pod aplikasi yang difilter oleh penampung envoy.

Jika cluster mengaktifkan logging workload, Anda dapat melihat error di Cloud Logging. Berikut ini adalah kemungkinan filter:

resource.type="K8S_CONTAINER"
resource.labels.project_id="PROJECT_NAME"
resource.labels.location="CLUSTER_ZONE"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.namespace_name="WORKLOAD_NAMESPACE"
labels.k8s-pod/app="WORKLOAD_NAME"
resource.labels.container_name="envoy"

Jika logging workload tidak diaktifkan di cluster, Anda dapat melihat error dengan menggunakan perintah seperti berikut:

kubectl logs $(kubectl get po -l app=WORKLOAD_NAME -o=jsonpath='{.items[0].metadata.name}') -c envoy --tail 50 #NOTE: This assumes the default namespace.

Anda juga dapat melihat log untuk semua Envoy yang berjalan di semua cluster dan beban kerja apa pun menggunakan filter berikut:
```
resource.type="K8S_CONTAINER"
resource.labels.container_name="envoy"
```

Dengan Compute Engine dan deployment manual, tentukan LOG_DIR sebelum menjalankan skrip run.sh di panduan penyiapan.

Contoh:
```
LOG_DIR='/var/log/envoy/'
```
Secara default, error ditampilkan di log berikut:
```
/var/log/envoy/envoy.err.log
```

Jika pengguna tidak melakukan konfigurasi tambahan untuk mengekspor ini ke Logging, error hanya akan terlihat jika Anda menggunakan SSH untuk terhubung ke instance dan mendapatkan file ini.

Jika menggunakan deployment Envoy otomatis, Anda dapat menggunakan SSH untuk terhubung ke instance guna mendapatkan file log. Jalur tersebut mungkin sama dengan jalur yang disebutkan sebelumnya.

Proxy tidak terhubung ke Traffic Director

Jika proxy Anda tidak terhubung ke Traffic Director, lakukan hal berikut:

Periksa log proxy Envoy untuk menemukan error saat menghubungkan ke trafficdirector.googleapis.com.
Jika Anda menyiapkan netfilter (dengan menggunakan iptables) untuk mengalihkan semua traffic ke proxy Envoy, pastikan pengguna (UID) yang Anda gunakan untuk menjalankan proxy dikecualikan dari pengalihan. Jika tidak, traffic akan terus-menerus melakukan loop kembali ke proxy.
Pastikan Anda mengaktifkan Traffic Director API untuk project. Di bagian APIs & services untuk project Anda, cari error untuk Traffic Director API.
Pastikan cakupan akses API VM disetel untuk mengizinkan akses penuh ke Google Cloud API dengan menentukan hal berikut saat Anda membuat VM:
```
--scopes=https://www.googleapis.com/auth/cloud-platform
```
Pastikan akun layanan memiliki izin yang benar. Untuk informasi selengkapnya, lihat Mengaktifkan akun layanan untuk mengakses Traffic Director API.
Konfirmasi bahwa Anda dapat mengakses trafficdirector.googleapis.com:443 dari VM. Jika ada masalah dengan akses ini, kemungkinan penyebabnya adalah firewall yang mencegah akses ke trafficdirector.googleapis.com melalui port TCP 443, atau masalah resolusi DNS untuk nama host trafficdirector.googleapis.com.
Jika Anda menggunakan Envoy untuk proxy file bantuan, pastikan versi Envoy dirilis 1.9.1 atau yang lebih baru.

Layanan yang dikonfigurasi dengan Traffic Director tidak dapat dijangkau

Jika layanan yang dikonfigurasi dengan Traffic Director tidak dapat dijangkau, pastikan proxy sespan berjalan dan dapat terhubung ke Traffic Director.

Jika menggunakan Envoy sebagai proxy file bantuan, Anda dapat mengonfirmasinya dengan menjalankan perintah berikut:

Dari command line, pastikan proses Envoy sedang berjalan:
```
ps aux | grep envoy
```
Periksa konfigurasi runtime Envoy untuk mengonfirmasi bahwa Traffic Director mengonfigurasi resource dinamis. Untuk melihat konfigurasi, jalankan perintah ini:
```
curl http://localhost:15000/config_dump
```
Pastikan intersepsi traffic untuk proxy file bantuan disiapkan dengan benar. Untuk penyiapan pengalihan dengan iptables, jalankan perintah iptables lalu grep output untuk memastikan aturan Anda ada di sana:
```
sudo iptables -t nat -S | grep ISTIO
```
Berikut adalah contoh output untuk iptables yang mencegat alamat IP virtual (VIP) 10.0.0.1/32 dan meneruskannya ke proxy Envoy yang berjalan pada port 15001 sebagai UID 1006:
```
-N ISTIO_IN_REDIRECT
-N ISTIO_OUTPUT
-N ISTIO_REDIRECT
-A OUTPUT -p tcp -j ISTIO_OUTPUT
-A ISTIO_IN_REDIRECT -p tcp -j REDIRECT --to-ports 15001
-A ISTIO_OUTPUT -m owner --uid-owner 1006 -j RETURN
-A ISTIO_OUTPUT -d 127.0.0.1/32 -j RETURN
-A ISTIO_OUTPUT -d 10.0.0.1/32 -j ISTIO_REDIRECT
-A ISTIO_OUTPUT -j RETURN
```

Jika instance VM dibuat melalui Google Cloud Console, beberapa modul yang terkait dengan IPv6 tidak akan diinstal dan tersedia sebelum mulai ulang. Hal ini menyebabkan iptables gagal karena tidak adanya dependensi. Dalam kasus ini, mulai ulang VM dan jalankan kembali proses penyiapan, yang akan menyelesaikan masalah. VM Compute Engine yang Anda buat menggunakan Google Cloud CLI diperkirakan tidak mengalami masalah ini.

Layanan berhenti dapat dijangkau saat logging akses Envoy dikonfigurasi

Jika Anda menggunakan TRAFFICDIRECTOR_ACCESS_LOG_PATH untuk mengonfigurasi log akses Envoy seperti yang dijelaskan dalam Mengonfigurasi atribut bootstrap Envoy untuk Traffic Director, pastikan bahwa pengguna sistem yang menjalankan proxy Envoy memiliki izin untuk menulis ke lokasi log akses yang ditentukan.

Kegagalan dalam memberikan izin yang diperlukan akan menyebabkan pemroses tidak diprogram pada proxy dan dapat dideteksi dengan memeriksa pesan error berikut di log proxy Envoy:

gRPC config for type.googleapis.com/envoy.api.v2.Listener rejected:
Error adding/updating listener(s) TRAFFICDIRECTOR_INTERCEPTION_PORT:
unable to open file '/var/log/envoy.log': Permission denied

Untuk mengatasi masalah ini, ubah izin file yang dipilih untuk log akses agar dapat ditulis oleh pengguna Envoy.

Aplikasi tidak dapat tersambung ke layanan yang tidak dikonfigurasi di Traffic Director

Pastikan Anda menyiapkan intersepsi traffic hanya untuk alamat IP layanan yang dikonfigurasi di Traffic Director. Jika semua traffic dicegat, proxy file bantuan akan diam-diam menghapus koneksi ke layanan yang tidak dikonfigurasi di Traffic Director.

Traffic berulang di dalam node atau node mengalami error

Jika netfilter (iptables) disiapkan untuk mengintersep semua traffic, pastikan pengguna (UID) yang digunakan untuk menjalankan proxy file bantuan dikecualikan dari intersepsi traffic. Jika tidak, traffic yang dikirim oleh proxy file bantuan akan di-loop kembali ke proxy tanpa batas waktu. Akibatnya, proses proxy file bantuan mungkin tidak bekerja. Dalam konfigurasi referensi, aturan netfilter tidak menangkap traffic dari pengguna proxy.

Pesan error di log Envoy menunjukkan masalah konfigurasi

Jika mengalami masalah dengan konfigurasi Traffic Director, Anda mungkin melihat salah satu pesan error berikut di log Envoy:

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Traffic Director configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Traffic Director configuration was not found for network "VPC_NAME" in
project "PROJECT_NUMBER".

warning envoy config    StreamAggregatedResources gRPC config stream closed:
5, Requested entity was not found.

warning envoy upstream  StreamLoadStats gRPC config stream closed:
5, Requested entity was not found.

Traffic Director configuration was not found.

Pesan error terakhir (Traffic Director configuration was not found) umumnya menunjukkan bahwa Envoy meminta konfigurasi dari Traffic Director, tetapi tidak ada konfigurasi yang cocok yang dapat ditemukan. Saat terhubung ke Traffic Director, Envoy akan menampilkan nama jaringan VPC (misalnya, my-network). Traffic Director kemudian mencari aturan penerusan yang memiliki skema load balancing INTERNAL_SELF_MANAGED dan mereferensikan nama jaringan VPC yang sama.

Untuk memperbaiki error ini, lakukan hal berikut:

Pastikan ada aturan penerusan di jaringan Anda yang memiliki skema load balancing INTERNAL_SELF_MANAGED. Perhatikan nama jaringan VPC aturan penerusan.
Jika Anda menggunakan Traffic Director dengan deployment Envoy otomatis di Compute Engine, pastikan nilai yang diberikan ke flag --service-proxy:network cocok dengan nama jaringan VPC aturan penerusan.
Jika Anda menggunakan Traffic Director dengan deployment Envoy manual di Compute Engine, periksa file bootstrap Envoy untuk mengetahui hal berikut:
1. Pastikan nilai untuk variabel TRAFFICDIRECTOR_NETWORK_NAME cocok dengan nama jaringan VPC aturan penerusan.
2. Pastikan nomor project ditetapkan dalam variabel TRAFFICDIRECTOR_GCP_PROJECT_NUMBER.
Jika Anda melakukan deployment di GKE, dan menggunakan injektor otomatis, pastikan nomor project dan nama jaringan VPC dikonfigurasi dengan benar, sesuai dengan petunjuk dalam Penyiapan Traffic Director untuk Pod GKE dengan injeksi Envoy otomatis.

Memecahkan masalah deployment otomatis untuk Compute Engine

Bagian ini berisi petunjuk pemecahan masalah deployment Envoy otomatis untuk Compute Engine.

Proses bootstrap Envoy dan VM serta operasi pengelolaan siklus proses lebih lanjut dapat gagal karena berbagai alasan, termasuk masalah konektivitas sementara, repositori yang rusak, bug dalam skrip bootstrap dan agen di VM, serta tindakan pengguna yang tidak terduga.

Saluran komunikasi untuk pemecahan masalah

Google Cloud menyediakan saluran komunikasi yang dapat Anda gunakan untuk membantu memahami proses bootstrap dan status saat ini dari komponen yang berada di VM Anda.

Logging output port serial virtual

Sistem operasi VM, BIOS, dan entitas level sistem lainnya biasanya menulis output ke port serial. Output ini berguna untuk memecahkan masalah error sistem, booting yang gagal, masalah startup, dan masalah penonaktifan.

Agen bootstrap Compute Engine mencatat semua tindakan yang dilakukan ke port serial 1. Hal ini termasuk peristiwa sistem, dimulai dengan penginstalan paket dasar hingga mendapatkan data dari server metadata instance, konfigurasi iptables, dan status penginstalan Envoy.

Agen di VM mencatat status kondisi proses Envoy, layanan Traffic Director yang baru ditemukan, dan informasi lainnya yang mungkin berguna saat Anda menyelidiki masalah pada VM.

Logging Cloud Monitoring

Data yang diekspos dalam output port serial juga akan dicatat ke Monitoring, yang menggunakan library Golang dan mengekspor log ke log terpisah untuk mengurangi derau. Karena log ini adalah log level instance, Anda mungkin menemukan log proxy layanan di halaman yang sama dengan log instance lainnya.

Atribut tamu VM

Atribut tamu adalah jenis metadata kustom tertentu yang dapat menjadi tujuan penulisan aplikasi Anda saat dijalankan pada instance Anda. Setiap aplikasi atau pengguna di instance Anda dapat membaca dan menulis data ke nilai metadata atribut tamu ini.

Skrip bootstrap Compute Engine Envoy dan agen di VM menampilkan atribut dengan informasi tentang proses bootstrap dan status Envoy saat ini. Semua atribut tamu ditampilkan dalam namespace gce-service-proxy:

gcloud compute instances get-guest-attributes INSTANCE_NAME  \
    --query-path=gce-service-proxy/ \
    --zone=ZONE

Jika Anda menemukan masalah, sebaiknya periksa nilai atribut tamu bootstrap-status dan bootstrap-last-failure. Nilai bootstrap-status selain FINISHED menunjukkan bahwa lingkungan Envoy belum dikonfigurasi. Nilai bookstrap-last-failure mungkin menunjukkan masalahnya.

Tidak dapat menjangkau layanan Traffic Director dari VM yang dibuat menggunakan template instance yang mendukung service-proxy

Untuk memperbaiki masalah ini, ikuti langkah-langkah berikut:

Penginstalan komponen proxy layanan pada VM mungkin belum selesai atau gagal. Gunakan perintah berikut untuk menentukan apakah semua komponen telah diinstal dengan benar:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
Atribut tamu bootstrap-status disetel ke salah satu nilai berikut:
- [none] menunjukkan bahwa penginstalan belum dimulai. VM mungkin masih sedang {i>booting<i}. Periksa kembali statusnya dalam beberapa menit.
- IN PROGRESS menunjukkan bahwa penginstalan dan konfigurasi komponen proxy layanan belum selesai. Ulangi pemeriksaan status untuk mengetahui informasi terbaru tentang prosesnya.
- FAILED menunjukkan bahwa penginstalan atau konfigurasi komponen gagal. Periksa pesan error dengan membuat kueri atribut gce-service-proxy/bootstrap-last-failure.
- FINISHED menunjukkan bahwa proses penginstalan dan konfigurasi selesai tanpa error apa pun. Gunakan petunjuk berikut untuk memverifikasi bahwa intersepsi traffic dan proxy Envoy dikonfigurasi dengan benar.
Intersepsi traffic pada VM tidak dikonfigurasi dengan benar untuk layanan berbasis Traffic Director. Login ke VM dan periksa konfigurasi iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Periksa rantai SERVICE_PROXY_SERVICE_CIDRS untuk entri SERVICE_PROXY_REDIRECT seperti berikut:
```
Chain SERVICE_PROXY_SERVICE_CIDRS (1 references)
target                   prot opt source         destination ...
SERVICE_PROXY_REDIRECT   all  --  anywhere       10.7.240.0/20
```
Untuk setiap layanan, harus ada alamat IP atau CIDR yang cocok di kolom destination. Jika tidak ada entri untuk alamat IP virtual (VIP), berarti ada masalah dengan mengisi konfigurasi proxy Envoy dari Traffic Director, atau agen di VM gagal.
Proxy Envoy belum menerima konfigurasinya dari Traffic Director. Login ke VM untuk memeriksa konfigurasi proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Periksa konfigurasi pemroses yang diterima dari Traffic Director. Misalnya:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.7.240.20",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "URL_MAP/PROJECT_NUMBER.td-routing-rule-1"
  ...
]
```
address_prefix adalah alamat IP virtual (VIP) dari layanan Traffic Director. Kolom ini mengarah ke peta URL bernama td-routing-rule-1. Periksa apakah layanan yang ingin Anda hubungkan sudah disertakan dalam konfigurasi pemroses.
Agen di VM tidak berjalan. Agen di VM secara otomatis mengonfigurasi intersepsi traffic saat layanan Traffic Director baru dibuat. Jika agen tidak berjalan, semua traffic ke layanan baru akan langsung menuju VIP, mengabaikan proxy Envoy, dan akan kehabisan waktu.
1. Verifikasi status agen di VM dengan menjalankan perintah berikut:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
   --query-path=gce-service-proxy/ \
   --zone=ZONE
```
2. Periksa atribut agen di VM. Nilai atribut agent-heartbeat memiliki waktu saat agen terakhir kali melakukan tindakan atau pemeriksaan. Jika nilainya lebih dari lima menit, agen macet, dan Anda harus membuat ulang VM dengan menggunakan perintah berikut:
```
gcloud compute instance-groups managed recreate-instance
```
3. Atribut agent-last-failure mengekspos error terakhir yang terjadi dalam agen. Ini mungkin masalah sementara yang akan diselesaikan saat berikutnya agen memeriksa—misalnya, jika error-nya adalah Cannot reach the Traffic Director API server—atau mungkin merupakan error permanen. Tunggu beberapa menit, lalu periksa kembali error-nya.

Intersepsi traffic masuk dikonfigurasi ke port workload, tetapi Anda tidak dapat terhubung ke port dari luar VM

Untuk memperbaiki masalah ini, ikuti langkah-langkah berikut:

Penginstalan komponen proxy layanan pada VM mungkin belum selesai atau gagal. Gunakan perintah berikut untuk menentukan apakah semua komponen telah diinstal dengan benar:
```
gcloud compute instances get-guest-attributes INSTANCE_NAME \
    --query-path=gce-service-proxy/ \
    --zone=ZONE
```
Atribut tamu bootstrap-status disetel ke salah satu nilai berikut:
- [none] menunjukkan bahwa penginstalan belum dimulai. VM mungkin masih sedang {i>booting<i}. Periksa kembali statusnya dalam beberapa menit.
- IN PROGRESS menunjukkan bahwa penginstalan dan konfigurasi komponen proxy layanan belum selesai. Ulangi pemeriksaan status untuk mengetahui informasi terbaru tentang prosesnya.
- FAILED menunjukkan bahwa penginstalan atau konfigurasi komponen gagal. Periksa pesan error dengan membuat kueri atribut gce-service-proxy/bootstrap-last-failure.
- FINISHED menunjukkan bahwa proses penginstalan dan konfigurasi selesai tanpa error apa pun. Gunakan petunjuk berikut untuk memverifikasi bahwa intersepsi traffic dan proxy Envoy dikonfigurasi dengan benar.
Intersepsi traffic pada VM tidak dikonfigurasi dengan benar untuk traffic masuk. Login ke VM dan periksa konfigurasi iptables:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo iptables -L -t nat
```
Periksa rantai SERVICE_PROXY_INBOUND untuk entri SERVICE_PROXY_IN_REDIRECT seperti berikut:
```
Chain SERVICE_PROXY_INBOUND (1 references)
target                      prot opt source       destination ...
SERVICE_PROXY_IN_REDIRECT   tcp  --  anywhere     anywhere  tcp dpt:mysql
```
Untuk setiap port yang ditentukan dalam service-proxy:serving-ports, harus ada port yang cocok di kolom destination. Jika tidak ada entri untuk port, semua traffic masuk akan langsung menuju ke port ini, dengan mengabaikan proxy Envoy.

Pastikan tidak ada aturan lain yang mengalihkan traffic ke port ini atau semua port kecuali satu port tertentu.
Proxy Envoy belum menerima konfigurasinya untuk port masuk dari Traffic Director. Login ke VM untuk memeriksa konfigurasi proxy Envoy:
```
gcloud compute ssh INSTANCE_NAME \
    --zone=ZONE \
    sudo curl localhost:15000/config_dump
```
Cari konfigurasi pemroses inbound yang diterima dari Traffic Director:
```
"dynamic_active_listeners": [
  ...
  "filter_chains": [{
    "filter_chain_match": {
      "prefix_ranges": [{
        "address_prefix": "10.0.0.1",
        "prefix_len": 32
      }],
      "destination_port": 80
    },
  ...
    "route_config_name": "inbound|default_inbound_config-80"
  ...
]
```
route_config_name, dimulai dengan inbound, menunjukkan layanan khusus yang dibuat untuk tujuan intersepsi traffic masuk. Periksa apakah port yang ingin Anda hubungkan sudah disertakan dalam konfigurasi pemroses di bagian destination_port.

Memecahkan masalah deployment otomatis untuk Pod GKE

Bagian ini berisi petunjuk cara memecahkan masalah deployment Envoy otomatis untuk Pod GKE.

Pod tidak dimulai setelah Anda mengaktifkan injeksi Envoy otomatis

Dalam beberapa situasi, Pod aplikasi mungkin tidak dimulai dengan benar. Hal ini mungkin terjadi saat Anda menggunakan cluster GKE pribadi dengan aturan firewall yang ketat.

Jika ingin menggunakan Traffic Director dengan cluster GKE pribadi, Anda harus membuat aturan firewall tambahan untuk webhook injektor file bantuan. Untuk membuat aturan firewall yang memungkinkan bidang kontrol GKE menjangkau Pod pada port TCP 9443, baca artikel Menambahkan aturan firewall untuk kasus penggunaan tertentu.

Anda mungkin melihat masalah ini saat membuat Pod mandiri atau saat deployment mencoba membuat Pod.

Saat membuat Pod mandiri (misalnya, dengan menggunakan kubectl apply atau kubectl run), command line kubectl mungkin menampilkan pesan error seperti berikut:

Error from server (InternalError): Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Saat membuat Pod dari deployment, Anda mungkin mengalami gejala berikut:

kubectl get pods tidak menampilkan Pod yang terkait dengan deployment.

kubectl get events --all-namespaces menampilkan pesan error seperti berikut:

Warning  FailedCreate  15s   replicaset-controller  Error creating: Internal error occurred: failed calling webhook "sidecar-injector.istio.io": Post https://istio-sidecar-injector.istio-control.svc:443/inject?timeout=30s: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

Saat mengikuti panduan penyiapan, Anda mungkin pertama kali mengalami masalah ini selama langkah Men-deploy klien contoh dan memverifikasi injeksi. Setelah menjalankan kubectl create -f demo/client_sample.yaml, jalankan kubectl get deploy busybox untuk melihat 0/1 Pod SIAP. Anda juga dapat menemukan error tersebut dengan menjelaskan replicaset yang terkait dengan deployment dengan mengeluarkan perintah kubectl describe rs -l run=client.

Koneksi ditolak setelah Anda memverifikasi konfigurasi

Saat menyiapkan Traffic Director dengan injeksi Envoy otomatis, Anda mungkin menerima error koneksi ditolak saat mencoba memverifikasi konfigurasi. Penyebabnya bisa salah satu hal berikut:

Nilai discoveryAddress dalam file specs/01-configmap.yaml salah. Nilainya harus trafficdirector.googleapis.com:443.
Nilai untuk jaringan VPC dalam file specs/01-configmap.yaml salah.
Nilai untuk project Traffic Director dalam file specs/01-configmap.yaml salah.
Nilai discoveryAddress di Pod salah.
Injektor file bantuan Istio yang sedang berjalan, bukan injektor sidecar Traffic Director.

Anda dapat melihat contoh file specs/01-configmap.yaml di Mengonfigurasi injektor file bantuan. Jika file specs/01-configmap.yaml tidak berisi nilai yang benar, Envoy tidak bisa mendapatkan konfigurasi koreksi dari Traffic Director. Untuk memperbaikinya, periksa file specs/01-configmap.yaml dan pastikan nilainya sudah benar, lalu buat ulang injektor otomatis.

Pastikan untuk memeriksa nilai discoveryAddress dalam file specs/01-configmap.yaml dan di Pod. Di Pod, injektor file bantuan menetapkan nilainya. Untuk memeriksa nilai discoveryAddress di Pod, jalankan perintah ini:

kubectl get po $BUSYBOX_POD -o yaml|grep -Po '\"discoveryAddress\":\"[^,]*\"'

Anda akan melihat output yang serupa dengan ini:

"discoveryAddress":"trafficdirector.googleapis.com:443"

Koneksi ditolak dengan injeksi Envoy manual dan Pod GKE

Jika Anda menerima pesan penolakan koneksi, lihat log sibuk untuk mengetahui informasi apakah Traffic Director API diaktifkan atau izin salah di log Envoy.

Waktu tunggu koneksi dengan injeksi Envoy manual dan Pod GKE

Jika Anda menerima pesan waktu tunggu koneksi, masalahnya kemungkinan besar adalah konfigurasi peta URL, aturan penerusan, atau layanan backend yang salah dalam deployment Anda. Periksa resource tersebut untuk mengonfirmasi apakah resource tersebut sudah dikonfigurasi dengan benar.

Masalah saat koneksi menggunakan protokol yang mengutamakan server

Beberapa aplikasi, seperti MySQL, menggunakan protokol di mana server mengirim paket pertama. Artinya, pada saat koneksi awal, server mengirim byte pertama. Protokol dan aplikasi ini tidak didukung oleh Traffic Director.

Memecahkan masalah kondisi mesh layanan

Panduan ini memberikan informasi untuk membantu Anda menyelesaikan masalah konfigurasi Traffic Director.

Perilaku Traffic Director saat sebagian besar endpoint tidak responsif

Untuk keandalan yang lebih baik, saat 99% endpoint tidak responsif, Traffic Director akan mengonfigurasi bidang data untuk mengabaikan status respons endpoint. Sebagai gantinya, bidang data akan menyeimbangkan traffic di antara semua endpoint karena ada kemungkinan port penyaluran masih berfungsi.

Backend yang tidak responsif menyebabkan distribusi traffic yang kurang optimal

Traffic Director menggunakan informasi dalam resource HealthCheck yang dilampirkan ke layanan backend untuk mengevaluasi kondisi backend Anda. Traffic Director menggunakan status kondisi ini untuk mengarahkan traffic ke backend responsif yang terdekat. Jika beberapa backend Anda tidak responsif, traffic mungkin akan terus diproses, tetapi dengan distribusi yang kurang optimal. Misalnya, traffic mungkin mengalir ke region tempat backend yang sehat masih ada, tetapi jauh lebih jauh dari klien sehingga menyebabkan latensi. Untuk mengidentifikasi dan memantau status respons backend Anda, coba langkah-langkah berikut:

Memeriksa status respons layanan backend Anda di Konsol Google Cloud.
Buka layanan Traffic Director
Pastikan logging diaktifkan untuk resource HealthCheck.
Jika health check mulai gagal baru-baru ini, periksa Cloud Audit Logs untuk mengetahui apakah konfigurasi HealthCheck Anda baru-baru ini berubah.

Backend secara tiba-tiba menolak traffic

Jika mengonfigurasi keamanan layanan Traffic Director, Anda akan menggunakan resource EndpointPolicy untuk menerapkan kebijakan keamanan ke backend. Kesalahan konfigurasi EndpointPolicy dapat menyebabkan backend Anda menolak traffic. Gunakan log berikut untuk memecahkan masalah skenario ini:

Periksa apakah ada konflik kebijakan endpoint yang dilaporkan oleh Traffic Director.
Periksa Cloud Audit Logs untuk memeriksa apakah konfigurasi pengguna (khususnya, EndpointPolicy, ServerTlsPolicy, atau AuthorizationPolicy) baru-baru ini diubah.

Langkah selanjutnya

Untuk mempelajari cara kerja Traffic Director, lihat ringkasan Traffic Director.
Untuk mengatasi masalah konfigurasi saat men-deploy layanan gRPC tanpa proxy, lihat Memecahkan masalah deployment yang menggunakan gRPC tanpa proxy.
Untuk menemukan dukungan tambahan dalam menggunakan Traffic Director, lihat Mendapatkan dukungan.