Pemecahan masalah

Halaman ini menyediakan strategi pemecahan masalah serta solusi untuk beberapa error umum.

Saat memecahkan masalah penayangan Knative, pertama-tama pastikan Anda dapat menjalankan image container secara lokal.

Jika aplikasi Anda tidak berjalan secara lokal, Anda harus mendiagnosis dan memperbaikinya. Anda harus menggunakan Cloud Logging untuk membantu men-debug project yang di-deploy.

Saat memecahkan masalah penayangan Knative, lihat bagian berikut untuk mengetahui kemungkinan solusi masalah.

Memeriksa output command line

Jika Anda menggunakan Google Cloud CLI, periksa output perintah untuk melihat apakah perintah berhasil atau tidak. Misalnya, jika deployment Anda dihentikan dan tidak berhasil, akan ada pesan error yang menjelaskan alasan kegagalan tersebut.

Kegagalan deployment kemungkinan besar disebabkan oleh kesalahan konfigurasi manifes atau perintah yang salah. Misalnya, output berikut menyatakan bahwa Anda harus mengonfigurasi persentase traffic rute agar berjumlah 100.

Error from server (InternalError): error when applying patch:</p><pre>{"metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{\"apiVersion\":\"serving.knative.dev/v11\",\"kind\":\"Route\",\"metadata\":{\"annotations\":{},\"name\":\"route-example\",\"namespace\":\"default\"},\"spec\":{\"traffic\":[{\"configurationName\":\"configuration-example\",\"percent\":50}]}}\n"}},"spec":{"traffic":[{"configurationName":"configuration-example","percent":50}]}}
to:
&{0xc421d98240 0xc421e77490 default route-example STDIN 0xc421db0488 264682 false}
for: "STDIN": Internal error occurred: admission webhook "webhook.knative.dev" denied the request: mutation failed: The route must have traffic percent sum equal to 100.
ERROR: Non-zero return code '1' from command: Process exited with status 1

Memeriksa log untuk layanan Anda

Anda dapat menggunakan Cloud Logging atau halaman penayangan Knative di Google Cloud konsol untuk memeriksa log permintaan dan log penampung. Untuk mengetahui detail selengkapnya, baca Logging dan melihat log.

Jika Anda menggunakan Cloud Logging, resource yang perlu difilter adalah Kubernetes Container.

Memeriksa status Layanan

Jalankan perintah berikut untuk mendapatkan status layanan Knative yang di-deploy:

gcloud run services describe SERVICE

Anda dapat menambahkan --format yaml(status) atau --format json(status) untuk mendapatkan status lengkap, misalnya:

gcloud run services describe SERVICE --format 'yaml(status)'

Kondisi di status dapat membantu Anda menemukan penyebab kegagalan. Kondisi dapat mencakup True, False, atau Unknown:

  • Siap: True menunjukkan bahwa layanan dikonfigurasi dan siap menerima traffic.
  • ConfigurationReady: True menunjukkan bahwa Konfigurasi yang mendasarinya sudah siap. Untuk False atau Unknown, Anda harus melihat status revisi terbaru.
  • RoutesReady: True menunjukkan bahwa Route yang mendasarinya sudah siap. Untuk False atau Unknown, Anda harus melihat status rute.

Untuk mengetahui detail tambahan tentang kondisi status, lihat Sinyal Error Knative.

Memeriksa status Rute

Setiap Layanan penayangan Knative mengelola Route yang merepresentasikan status perutean saat ini terhadap revisi layanan.

Anda dapat memeriksa status keseluruhan Rute dengan melihat status layanan:

gcloud run services describe SERVICE --format 'yaml(status)'

Kondisi RoutesReady di status memberikan status Rute.

Anda dapat mendiagnosis lebih lanjut status Rute dengan menjalankan perintah berikut:

kubectl get route SERVICE -o yaml

Kondisi dalam status memberikan alasan kegagalan. Yaitu:

  • Siap menunjukkan apakah layanan dikonfigurasi dan memiliki backend yang tersedia. Jika ini adalah true, rute dikonfigurasi dengan benar.

  • AllTrafficAssigned menunjukkan apakah layanan dikonfigurasi dengan benar dan memiliki backend yang tersedia. Jika status kondisi ini bukan True:

    • Coba periksa apakah pembagian traffic antara revisi untuk layanan Anda berjumlah total 100%:

      gcloud run services describe SERVICE

      Jika tidak, sesuaikan pembagian traffic menggunakan perintah gcloud run services update-traffic.

    • Coba periksa status revisi untuk revisi yang menerima traffic.

  • IngressReady menunjukkan apakah Ingress sudah siap. Jika status kondisi ini bukan True, coba periksa status ingress.

  • CertificateProvisioned menunjukkan apakah sertifikat Knative telah disediakan. Jika status kondisi ini bukan True, coba pecahkan masalah TLS terkelola.

Untuk mengetahui detail tambahan tentang kondisi status, lihat Kondisi dan Pelaporan Error Knative.

Memeriksa status Ingress

Layanan Knative menggunakan layanan load balancer yang disebut istio-ingressgateway, yang bertanggung jawab untuk menangani traffic masuk dari luar cluster.

Untuk mendapatkan IP eksternal Load Balancer, jalankan perintah berikut:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Ganti ASM-INGRESS-NAMESPACE dengan namespace tempat ingress Cloud Service Mesh Anda berada. Tentukan istio-system jika Anda menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.

Output yang dihasilkan akan terlihat mirip dengan berikut ini:

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

dengan nilai EXTERNAL-IP adalah alamat IP eksternal Load Balancer Anda.

Jika EXTERNAL-IP adalah pending, lihat EXTERNAL-IP adalah pending dalam waktu lama di bawah.

Memeriksa status Revisi

Untuk mendapatkan revisi terbaru untuk layanan penayangan Knative, jalankan perintah berikut:

gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'

Jalankan perintah berikut untuk mendapatkan status revisi layanan Knative tertentu:

gcloud run revisions describe REVISION

Anda dapat menambahkan --format yaml(status) atau --format json(status) untuk mendapatkan status lengkap:

gcloud run revisions describe REVISION --format yaml(status)

Kondisi dalam status memberikan alasan kegagalan. Yaitu:

  • Siap menunjukkan apakah resource runtime sudah siap. Jika ini adalah true, revisi dikonfigurasi dengan benar.
  • ResourcesAvailable menunjukkan apakah resource Kubernetes yang mendasarinya telah disediakan. Jika status kondisi ini bukan True, coba periksa status Pod.
  • ContainerHealthy menunjukkan apakah pemeriksaan kesiapan revisi telah selesai. Jika status kondisi ini bukan True, coba periksa status Pod.
  • Aktif menunjukkan apakah revisi menerima traffic.

Jika salah satu kondisi status tidak True, coba periksa status Pod.

Memeriksa status Pod

Untuk mendapatkan Pod untuk semua deployment Anda:

kubectl get pods

Perintah ini akan mencantumkan semua Pod dengan status singkat. Contoh:

NAME                                                      READY     STATUS             RESTARTS   AGE
configuration-example-00001-deployment-659747ff99-9bvr4   2/2       Running            0          3h
configuration-example-00002-deployment-5f475b7849-gxcht   1/2       CrashLoopBackOff   2          36s

Pilih salah satu dan gunakan perintah berikut untuk melihat informasi mendetail tentang status. Beberapa kolom yang berguna adalah conditions dan containerStatuses:

kubectl get pod POD-NAME -o yaml

EXTERNAL-IP adalah <pending> untuk waktu yang lama

Terkadang, Anda mungkin tidak mendapatkan alamat IP eksternal segera setelah membuat cluster, tetapi melihat IP eksternal sebagai pending. Misalnya, Anda dapat melihatnya dengan memanggil perintah:

Untuk mendapatkan IP eksternal Load Balancer, jalankan perintah berikut:

kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

Ganti ASM-INGRESS-NAMESPACE dengan namespace tempat ingress Cloud Service Mesh Anda berada. Tentukan istio-system jika Anda menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.

Output yang dihasilkan akan terlihat mirip dengan berikut ini:

NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

dengan nilai EXTERNAL-IP adalah alamat IP eksternal Load Balancer Anda.

Hal ini mungkin berarti Anda telah kehabisan kuota alamat IP eksternal di Google Cloud. Anda dapat memeriksa kemungkinan penyebabnya dengan memanggil:

kubectl describe svc istio-ingressgateway -n INGRESS_NAMESPACE
 dengan INGRESS_NAMESPACE adalah namespace ingress ASM yang secara default adalah `istio-system`. Hal ini akan menghasilkan output yang mirip dengan berikut ini: 
Name:                     istio-ingressgateway
Namespace:                INGRESS_NAMESPACE
Labels:                   app=istio-ingressgateway
                          istio=ingressgateway
                          istio.io/rev=asm-1102-3
                          operator.istio.io/component=IngressGateways
                          operator.istio.io/managed=Reconcile
                          operator.istio.io/version=1.10.2-asm.3
                          release=istio
Annotations:              kubectl.kubernetes.io/last-applied-configuration={"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"addonmanager.kubernetes.io/mode":"Reconcile","app":"istio-ingressgateway","...
Selector:                 app=istio-ingressgateway,istio=ingressgateway
Type:                     LoadBalancer
IP:                       10.XX.XXX.XXX
LoadBalancer Ingress:     35.XXX.XXX.188
Port:                     http2  80/TCP
TargetPort:               80/TCP
NodePort:                 http2  31380/TCP
Endpoints:                XX.XX.1.6:80
Port:                     https  443/TCP
TargetPort:               443/TCP
NodePort:                 https  3XXX0/TCP
Endpoints:                XX.XX.1.6:XXX
Port:                     tcp  31400/TCP
TargetPort:               3XX00/TCP
NodePort:                 tcp  3XX00/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-pilot-grpc-tls  15011/TCP
TargetPort:               15011/TCP
NodePort:                 tcp-pilot-grpc-tls  32201/TCP
Endpoints:                XX.XX.1.6:XXXXX
Port:                     tcp-citadel-grpc-tls  8060/TCP
TargetPort:               8060/TCP
NodePort:                 tcp-citadel-grpc-tls  31187/TCP
Endpoints:                XX.XX.1.6:XXXX
Port:                     tcp-dns-tls  853/TCP
TargetPort:               XXX/TCP
NodePort:                 tcp-dns-tls  31219/TCP
Endpoints:                10.52.1.6:853
Port:                     http2-prometheus  15030/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-prometheus  30944/TCP
Endpoints:                10.52.1.6:15030
Port:                     http2-grafana  15031/TCP
TargetPort:               XXXXX/TCP
NodePort:                 http2-grafana  31497/TCP
Endpoints:                XX.XX.1.6:XXXXX
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason                Age                  From                Message
  ----    ------                ----                 ----                -------
  Normal  EnsuringLoadBalancer  7s (x4318 over 15d)  service-controller  Ensuring load balancer

Jika output Anda berisi indikasi bahwa IN_USE_ADDRESSES kuota terlampaui, Anda dapat meminta kuota tambahan dengan membuka halaman IAM & Admin di konsol Google Cloud untuk meminta kuota tambahan.

Gateway akan terus mencoba lagi hingga alamat IP eksternal ditetapkan. Proses ini mungkin memerlukan waktu beberapa menit.

Memecahkan masalah domain kustom dan masalah TLS terkelola

Gunakan langkah-langkah pemecahan masalah yang tercantum di bawah untuk menyelesaikan masalah umum terkait domain kustom dan fitur sertifikat TLS terkelola.

Domain kustom untuk jaringan internal pribadi

Jika Anda memetakan domain kustom ke cluster atau layanan Knative serving dalam jaringan internal pribadi, Anda harus menonaktifkan sertifikat TLS terkelola atau konfigurasi domain Anda akan gagal mencapai status ready. Secara default, load balancer internal tidak dapat berkomunikasi secara eksternal dengan otoritas sertifikat.

Memeriksa status pemetaan domain tertentu

Untuk memeriksa status pemetaan domain tertentu:

  1. Jalankan perintah:

    gcloud run domain-mappings describe --domain DOMAIN --namespace NAMESPACE

    Ganti

    • DOMAIN dengan nama domain yang Anda gunakan.
    • NAMESPACE dengan namespace yang Anda gunakan untuk pemetaan domain.

  2. Dalam hasil yaml dari perintah ini, periksa kondisi kolom CertificateProvisioned untuk menentukan sifat error.

  3. Jika ada error yang ditampilkan, error tersebut harus cocok dengan salah satu error dalam tabel di bawah. Ikuti saran dalam tabel untuk menyelesaikan masalah.

Error konfigurasi pengguna

Kode error Detail
DNSErrored Pesan: Data DNS tidak dikonfigurasi dengan benar. Perlu memetakan domain [XXX] ke IP XX.XX.XX.XX

Ikuti petunjuk yang diberikan untuk mengonfigurasi data DNS Anda dengan benar.

RateLimitExceeded Message: acme: urn:ietf:params:acme:error:rateLimited: Error creating new order
:: too many certificates already issued for exact set of domains:
test.your-domain.com:
see https://letsencrypt.org/docs/rate-limits/

Kuota Let's Encrypt telah terlampaui. Anda harus meningkatkan kuota sertifikat Let's Encrypt untuk host tersebut.

InvalidDomainMappingName Pesan: Nama DomainMapping %s tidak boleh sama dengan host URL Rute %s.

Nama DomainMapping tidak boleh sama persis dengan host Rute yang dipetakannya. Gunakan domain lain untuk nama DomainMapping Anda.

ChallengeServingErrored Pesan: Sistem gagal melayani permintaan HTTP01.

Error ini dapat terjadi jika layanan istio-ingressgateway tidak dapat menayangkan permintaan dari Let's Encrypt untuk memvalidasi kepemilikan domain.

  1. Pastikan layanan istio-ingressgateway Anda dapat diakses dari internet publik tanpa menggunakan Virtual Private Cloud.
  2. Pastikan layanan istio-ingressgateway Anda menerima permintaan dari URL http://DOMAIN/.well-known/acme-challenge/... dengan DOMAIN adalah domain yang divalidasi.

Error sistem

Kode error Detail
OrderErrored

AuthzErrored

ChallengeErrored

Ketiga jenis error ini terjadi jika verifikasi kepemilikan domain oleh Let's Encrypt gagal.

Error ini biasanya merupakan error sementara, dan akan dicoba lagi oleh layanan Knative.

Penundaan percobaan ulang bersifat eksponensial dengan minimum 8 detik dan maksimum 8 jam.

Jika ingin mencoba ulang error secara manual, Anda dapat menghapus Pesanan yang gagal secara manual.

kubectl delete order DOMAIN -n NAMESPACE

ACMEAPIFailed Jenis error ini terjadi saat layanan Knative gagal memanggil Let's Encrypt. Error ini biasanya bersifat sementara, dan akan dicoba lagi oleh Knative Serving.

Jika Anda ingin mencoba ulang error secara manual, hapus Pesanan yang gagal secara manual.

kubectl delete order DOMAIN -n NAMESPACE

UnknownErrored Error ini menunjukkan error sistem yang tidak diketahui, yang seharusnya sangat jarang terjadi di cluster GKE. Jika Anda melihat pesan ini, hubungi dukungan Cloud untuk mendapatkan bantuan dalam men-debug.

Memeriksa status Pesanan

Status Pesanan mencatat proses interaksi dengan Let's Encrypt, dan oleh karena itu dapat digunakan untuk men-debug masalah terkait Let's Encrypt. Jika perlu, periksa status Pesanan dengan menjalankan perintah ini:

kubectl get order DOMAIN -n NAMESPACE -oyaml

Ganti

  • DOMAIN dengan nama domain yang Anda gunakan.
  • NAMESPACE dengan namespace yang Anda gunakan untuk pemetaan domain.

Hasilnya akan berisi sertifikat yang dikeluarkan dan informasi lainnya jika pesanan berhasil.

Waktu Tunggu Pesanan

Objek Pesanan akan kehabisan waktu setelah 20 menit jika masih tidak dapat memperoleh sertifikat.

  1. Periksa status pemetaan domain. Untuk waktu tunggu, cari pesan error seperti ini di output status:

    order (test.your-domain.com) timed out (20.0 minutes)

  2. Penyebab umum masalah waktu tunggu adalah data DNS Anda tidak dikonfigurasi dengan benar untuk memetakan domain yang Anda gunakan ke alamat IP layanan ingress. Jalankan perintah berikut untuk memeriksa catatan DNS:

    host DOMAIN

  3. Periksa alamat IP eksternal load balancer ingress Anda:

    Untuk mendapatkan IP eksternal Load Balancer, jalankan perintah berikut:

    kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

    Ganti ASM-INGRESS-NAMESPACE dengan namespace tempat ingress Cloud Service Mesh Anda berada. Tentukan istio-system jika Anda menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.

    Output yang dihasilkan akan terlihat mirip dengan berikut ini:

    NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

    dengan nilai EXTERNAL-IP adalah alamat IP eksternal Load Balancer Anda.

    Jika alamat IP eksternal domain Anda tidak cocok dengan alamat IP ingress, konfigurasikan ulang data DNS Anda agar dipetakan ke alamat IP yang benar.

  4. Setelah data DNS (yang diperbarui) berlaku, jalankan perintah berikut untuk menghapus objek Pesanan guna memicu kembali proses permintaan sertifikat TLS:

    kubectl delete order DOMAIN -n NAMESPACE

    Ganti

    • DOMAIN dengan nama domain yang Anda gunakan.
    • NAMESPACE dengan namespace yang Anda gunakan.

Kegagalan Otorisasi

Kegagalan otorisasi dapat terjadi saat data DNS tidak diterapkan secara global tepat waktu. Akibatnya, Let's Encrypt gagal memverifikasi kepemilikan domain.

  1. Periksa status Pesanan. Temukan link authz di kolom acmeAuthorizations status. URL-nya akan terlihat seperti ini:

    https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827

  2. Buka link. Jika Anda melihat pesan yang mirip dengan: 

    urn:ietf:params:acme:error:dns

    maka masalahnya disebabkan oleh penerapan DNS yang tidak lengkap.

  3. Untuk mengatasi error propagasi DNS:

    1. Periksa alamat IP eksternal load balancer ingress Anda:

      Untuk mendapatkan IP eksternal Load Balancer, jalankan perintah berikut:

      kubectl get svc istio-ingressgateway -n ASM-INGRESS-NAMESPACE

      Ganti ASM-INGRESS-NAMESPACE dengan namespace tempat ingress Cloud Service Mesh Anda berada. Tentukan istio-system jika Anda menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.

      Output yang dihasilkan akan terlihat mirip dengan berikut ini:

      NAME                   TYPE           CLUSTER-IP     EXTERNAL-IP  PORT(S)
istio-ingressgateway   LoadBalancer   XX.XX.XXX.XX   pending      80:32380/TCP,443:32390/TCP,32400:32400/TCP

      dengan nilai EXTERNAL-IP adalah alamat IP eksternal Load Balancer Anda.

    2. Periksa data DNS Anda untuk domain dengan menjalankan perintah berikut: 

      host DOMAIN

      Jika alamat IP data DNS tidak cocok dengan IP eksternal load balancer ingress, konfigurasi data DNS Anda untuk memetakan domain pengguna ke IP eksternal.

    3. Setelah data DNS (yang diperbarui) berlaku, jalankan perintah berikut untuk menghapus objek Pesanan guna memicu kembali proses permintaan sertifikat TLS:

      kubectl delete order DOMAIN -n NAMESPACE

    Ganti

    • DOMAIN dengan nama domain yang Anda gunakan.
    • NAMESPACE dengan namespace yang Anda gunakan untuk pemetaan domain.

Kegagalan deployment ke cluster pribadi: Error panggilan webhook gagal

Firewall Anda mungkin tidak disiapkan dengan benar jika deployment ke cluster pribadi gagal dengan pesan:

Error: failed calling webhook "webhook.serving.knative.dev": Post
https://webhook.knative-serving.svc:443/?timeout=30s: context deadline exceeded (Client.Timeout
exceeded while awaiting headers)

Untuk mengetahui informasi tentang perubahan firewall yang diperlukan untuk mendukung deployment ke cluster pribadi, lihat mengaktifkan deployment di cluster pribadi.

Layanan melaporkan status IngressNotConfigured

Jika IngressNotConfigured muncul di status layanan Anda, Anda mungkin perlu memulai ulang deployment istiod di namespace istio-system jika Anda menggunakan Cloud Service Mesh dengan bidang kontrol dalam cluster. Error ini, yang lebih sering diamati di kubernetes 1.14, dapat terjadi jika layanan dibuat sebelum istiod siap memulai tugasnya untuk merekonsiliasi VirtualServices dan mengirim konfigurasi Envoy ke gateway ingress.

Untuk memperbaiki masalah ini, lakukan penskalaan deployment, lalu batalkan penskalaan lagi menggunakan perintah yang mirip dengan berikut:

kubectl scale deployment istiod -n istio-system --replicas=0
kubectl scale deployment istiod -n istio-system --replicas=1

Metrik jumlah permintaan dan latensi permintaan tidak ada

Layanan Anda mungkin tidak melaporkan metrik jumlah permintaan revisi dan latensi permintaan jika Anda mengaktifkan Workload Identity Federation untuk GKE dan belum memberikan izin tertentu ke akun layanan yang digunakan oleh layanan Anda.

Anda dapat memperbaikinya dengan mengikuti langkah-langkah di bagian Mengaktifkan metrik di cluster dengan Workload Identity Federation untuk GKE.