Halaman ini menyediakan strategi pemecahan masalah serta solusi untuk yang sering terjadi.
Saat memecahkan masalah penyaluran Knative, pertama-tama pastikan Anda juga dapat menjalankan image container secara lokal.
Jika aplikasi Anda tidak berjalan secara lokal, Anda perlu mendiagnosis dan memperbaikinya. Anda harus menggunakan Cloud Logging untuk membantu melakukan debug project yang telah diterapkan.
Saat memecahkan masalah penayangan Knative, lihat bagian berikut untuk solusi yang memungkinkan untuk suatu masalah.
Memeriksa output command line
Jika Anda menggunakan Google Cloud CLI, periksa output perintah Anda untuk melihat apakah berhasil atau tidak. Misalnya, jika deployment Anda tidak berhasil dihentikan, harus ada pesan error yang menjelaskan alasan kegagalan tersebut.
Kegagalan deployment kemungkinan besar disebabkan oleh konfigurasi manifes yang salah atau perintah yang salah. Misalnya, {i>output<i} berikut mengatakan bahwa Anda harus mengonfigurasi persentase lalu lintas rute menjadi 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 Konsol Google Cloud untuk memeriksa log permintaan dan log container. Untuk penyelesaian baca Logging dan melihat log.
Jika Anda menggunakan Cloud Logging, resource yang perlu difilter adalah Container Kubernetes.
Memeriksa status Layanan
Jalankan perintah berikut untuk mendapatkan status layanan penayangan Knative yang di-deploy:
gcloud run services describe SERVICE
Anda dapat menambahkan --format yaml(status)
atau --format json(status)
untuk mendapatkan yang lengkap
status, 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 telah dikonfigurasi dan siap untuk menerima traffic. - ConfigurationReady:
True
menunjukkan bahwa komponen utama Konfigurasi sudah siap. UntukFalse
atauUnknown
, Anda harus lihat status revisi terbaru. - RoutesReady:
True
menunjukkan komponen dasar Rute sudah siap. UntukFalse
atauUnknown
, Anda harus melihat status rute.
Untuk detail tambahan tentang kondisi status, lihat Sinyal Error Knative.
Memeriksa status Rute
Setiap Layanan penayangan Knative mengelola Rute yang mewakili status {i>routing<i} 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 status Rute lebih lanjut dengan menjalankan perintah berikut:
kubectl get route SERVICE -o yaml
Kondisi dalam status
memberikan alasan kegagalan. Yaitu:
Ready menunjukkan apakah layanan dikonfigurasi dan memiliki backend yang tersedia. Jika ini adalah
true
, rute akan dikonfigurasi dengan benar.AllTrafficAssigned menunjukkan apakah layanan dikonfigurasi dengan benar dan memiliki backend yang tersedia. Jika
status
kondisi ini bukanTrue
:Coba periksa apakah pemisahan traffic di antara revisi untuk layanan Anda bertambah hingga 100%:
gcloud run services describe SERVICE
Jika belum, sesuaikan pemisahan 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 bukanTrue
, coba periksa status masuknya.CertificateProvisioned menunjukkan apakah sertifikat Knative telah disediakan. Jika
status
kondisi ini bukanTrue
, coba pemecahan masalah TLS terkelola.
Untuk detail tambahan tentang kondisi status, lihat Pelaporan dan Kondisi Error Knative.
Memeriksa status Ingress
Penyajian Knative menggunakan layanan load balancer yang disebut
istio-ingressgateway
, yang bertanggung jawab untuk menangani traffic masuk
dari luar cluster.
Untuk mendapatkan IP eksternal untuk 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 ditemukan. Tentukan istio-system
jika Anda
menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.
Output yang dihasilkan 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 Anda Penyeimbang.
Jika EXTERNAL-IP adalah pending
, lihat
EXTERNAL-IP adalah pending
untuk waktu yang lama di bawah.
Memeriksa status Revisi
Untuk mendapatkan revisi terbaru bagi layanan penayangan Knative Anda, jalankan perintah berikut:
gcloud run services describe SERVICE --format='value(status.latestCreatedRevisionName)'
Jalankan perintah berikut untuk mendapatkan status revisi inferensi 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 di status
memberikan alasan kegagalan. Yaitu:
- Ready menunjukkan apakah resource runtime sudah siap. Jika yang ditampilkan adalah
true
, berarti revisi akan dikonfigurasi dengan benar. - ResourcesAvailable menunjukkan apakah resource Kubernetes dasar telah disediakan.
Jika
status
kondisi ini bukanTrue
, coba periksa status Pod. - ContainerHealthy menunjukkan apakah pemeriksaan kesiapan revisi telah selesai.
Jika
status
kondisi ini bukanTrue
, coba periksa status Pod. - Aktif menunjukkan apakah revisi menerima traffic.
Jika salah satu dari kondisi ini status
bukan True
, coba periksa status Pod.
Memeriksa status Pod
Guna mendapatkan Pod untuk semua deployment Anda:
kubectl get pods
Tindakan ini akan menampilkan 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 satu dan gunakan perintah berikut untuk melihat informasi rinci tentang {i>cloud<i}
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 justru melihat IP eksternal sebagai pending
. Misalnya, Anda dapat
melihatnya dengan memanggil perintah:
Untuk mendapatkan IP eksternal untuk 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 ditemukan. Tentukan istio-system
jika Anda
menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.
Output yang dihasilkan 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 Anda Penyeimbang.
Hal ini dapat berarti bahwa 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
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
IAM & Admin page 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 TLS terkelola
Gunakan langkah pemecahan masalah yang tercantum di bawah ini 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 penayangan Knative
dalam
jaringan internal pribadi,
Anda harus
nonaktifkan sertifikat TLS terkelola
jika tidak, konfigurasi domain Anda akan gagal mencapai status ready
. Menurut
secara default, load balancer internal tidak
dapat berkomunikasi secara eksternal
otoritas sertifikat, {i>certificate authority<i}.
Memeriksa status pemetaan domain tertentu
Untuk memeriksa status pemetaan domain tertentu:
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.
Dalam hasil
yaml
dari perintah ini, periksa kondisi kolomCertificateProvisioned
untuk menentukan sifat error.Jika ada kesalahan yang ditampilkan, maka itu seharusnya cocok dengan salah satu kesalahan di tabel di bawah ini. Ikuti saran di tabel untuk menyelesaikan masalah tersebut.
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 | Pesan:
acme: urn:ietf:params:acme:error:rateLimited: Terjadi error saat membuat pesanan baru
:: terlalu banyak sertifikat yang telah diterbitkan untuk kumpulan domain yang pasti: test.domain-anda.com: lihat https://letsencrypt.org/docs/rate-limits/ Kuota Let's Encrypt telah terlampaui. Anda harus meningkatkan Mari Enkripsi kuota sertifikat untuk {i>host<i} tersebut. |
InvalidDomainMappingName | Pesan:
Nama DomainMapping %s tidak boleh sama dengan host URL Rute %s.
Nama DomainMapping tidak boleh sama persis dengan host Rutekan ke peta. Gunakan domain yang berbeda untuk nama DomainMapping Anda. |
ChallengeServingErrored | Pesan: Sistem gagal menayangkan permintaan HTTP01.
Error ini dapat terjadi jika layanan
|
Error sistem
Kode error | Detail |
---|---|
OrderErrored
AuthzErrored ChallengeErrored |
Ketiga jenis kesalahan ini terjadi jika
verifikasi kepemilikan domain menggunakan
Gagal Mengenkripsi.
Error ini biasanya bersifat sementara, dan akan dicoba ulang dengan Penyajian Knative. Penundaan percobaan ulang bersifat eksponensial dengan minimum 8 detik dan maksimum 8 jam. Jika ingin mencoba lagi error tersebut secara manual, Anda dapat menghapus Pesanan yang gagal secara manual.
|
ACMEAPIFailed | Jenis error ini terjadi ketika penyaluran Knative gagal memanggil
Mari Enkripsi. Hal ini biasanya merupakan {i>error <i}yang bersifat sementara, dan akan dicoba lagi dengan
Penyajian Knative.
Jika Anda ingin mencoba lagi error tersebut secara manual, hapus Pesanan yang gagal secara manual.
|
UnknownErrored | Error ini menunjukkan error sistem yang tidak dikenal, yang seharusnya terjadi sangat jarang terjadi di cluster GKE. Jika Anda melihat ini, hubungi dukungan Cloud untuk mendapatkan bantuan proses debug. |
Periksa Status pesanan
Status Pesanan mencatat proses berinteraksi dengan {i>Let's Encrypt<i}, dan oleh karena itu dapat digunakan untuk men-debug masalah yang terkait dengan {i>Let's Encrypt<i}. Jika ya diperlukan, 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 diterbitkan dan informasi lainnya jika pesanan berhasil.
Waktu Tunggu Pesanan
Waktu objek Pesanan akan habis setelah 20 menit jika masih tidak bisa mendapatkannya CA {i>root<i}.
Periksa status pemetaan domain. Untuk waktu tunggu, cari pesan error seperti ini dalam output status:
order (test.your-domain.com) timed out (20.0 minutes)
Penyebab umum masalah waktu tunggu adalah data DNS Anda tidak dikonfigurasi dengan benar untuk memetakan domain yang Anda gunakan ke alamat IP layanan traffic masuk. Jalankan perintah berikut untuk periksa catatan DNS:
host DOMAIN
Periksa alamat IP eksternal load balancer masuk Anda:
Untuk mendapatkan IP eksternal untuk 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 ditemukan. Tentukan
istio-system
jika Anda menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.Output yang dihasilkan 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 Anda Penyeimbang.
Jika alamat IP eksternal domain tidak cocok dengan IP masuk alamat IP, kemudian mengonfigurasi ulang catatan DNS untuk memetakan ke alamat IP yang benar.
Setelah data DNS (yang diperbarui) efektif, 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 ketika pencatatan DNS tidak disebarkan secara global di baik. Akibatnya, Let's Encrypt gagal memverifikasi kepemilikan domain.
Periksa Status pesanan. Cari link authz di bagian kolom
acmeAuthorizations
status Anda. URL-nya akan terlihat seperti ini:https://acme-v02.api.letsencrypt.org/acme/authz-v3/1717011827
Buka link. Jika Anda melihat pesan yang mirip dengan:
urn:ietf:params:acme:error:dns
maka masalahnya adalah karena propagasi DNS tidak lengkap.
Untuk mengatasi error penerapan DNS:
Periksa alamat IP eksternal load balancer masuk Anda:
Untuk mendapatkan IP eksternal untuk 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 ditemukan. Tentukan
istio-system
jika Anda menginstal Cloud Service Mesh menggunakan konfigurasi defaultnya.Output yang dihasilkan 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 Anda Penyeimbang.
Periksa data DNS Anda untuk domain dengan menjalankan perintah berikut:
host DOMAIN
Jika alamat IP catatan DNS tidak cocok dengan IP eksternal load balancer masuk, konfigurasi data DNS agar memetakan domain pengguna ke IP eksternal.
Setelah data DNS (diperbarui) menjadi efektif, jalankan perintah berikut perintah untuk menghapus objek Order untuk 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: Gagal memanggil error webhook
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 informasi tentang perubahan firewall yang diperlukan guna mendukung deployment ke cluster, lihat mengaktifkan deployment pada cluster pribadi.
Status laporan layanan IngressNotConfigured
Jika IngressNotConfigured
muncul dalam status layanan, Anda mungkin perlu
mulai ulang deployment istiod
di namespace istio-system
jika Anda menggunakan Cloud Service Mesh bidang kontrol dalam cluster. Pada {i>error<i} tersebut,
yang telah diamati lebih sering di Kubernetes 1.14
, dapat terjadi jika
layanan dibuat sebelum istiod
siap memulai tugas
merekonsiliasi VirtualServices
dan mendorong konfigurasi envoy ke
gateway masuknya.
Untuk memperbaiki masalah ini, skalakan deployment, lalu turunkan skalanya lagi menggunakan perintah yang serupa dengan berikut ini:
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 jumlah permintaan revisi dan meminta metrik latensi jika Anda memiliki Workload Identity Federation untuk GKE mengaktifkan dan belum memberikan izin tertentu ke akun layanan yang digunakan oleh layanan Anda.
Anda dapat memperbaikinya dengan mengikuti langkah-langkah di Mengaktifkan metrik pada cluster dengan bagian Workload Identity Federation untuk GKE.