Halaman ini menunjukkan cara menyelesaikan masalah dengan server Kubernetes API
(kube-apiserver
) untuk Google Distributed Cloud.
Halaman ini ditujukan untuk administrator IT dan Operator yang mengelola siklus proses infrastruktur teknologi yang mendasarinya, serta merespons pemberitahuan dan halaman saat tujuan tingkat layanan (SLO) tidak terpenuhi atau aplikasi gagal. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.
Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.Waktu tunggu webhook habis dan panggilan webhook gagal
Error ini mungkin terlihat dalam beberapa cara. Jika Anda mengalami salah satu gejala berikut, panggilan webhook mungkin gagal:
Koneksi ditolak: Jika
kube-apiserver
melaporkan error waktu tunggu untuk memanggil webhook, error berikut akan dilaporkan dalam log:failed calling webhook "server.system.private.gdc.goog": failed to call webhook: Post "https://root-admin-webhook.gpc-system.svc:443/mutate-system-private-gdc-goog-v1alpha1-server?timeout=10s": dial tcp 10.202.1.18:443: connect: connection refused
Batas waktu konteks terlampaui: Anda mungkin juga melihat error berikut dilaporkan dalam log:
failed calling webhook "namespaces.hnc.x-k8s.io": failed to call webhook: Post "https://hnc-webhook-service.hnc-system.svc:443/validate-v1-namespace?timeout=10s\": context deadline exceeded"
Jika Anda merasa mengalami waktu tunggu webhook habis atau panggilan webhook gagal, gunakan salah satu metode berikut untuk mengonfirmasi masalahnya:
Periksa log server API untuk melihat apakah ada masalah jaringan.
- Periksa log untuk menemukan error terkait jaringan seperti
TLS handshake error
. - Periksa apakah IP/Port cocok dengan server API yang dikonfigurasi untuk merespons.
- Periksa log untuk menemukan error terkait jaringan seperti
Pantau latensi webhook dengan langkah-langkah berikut:
Di konsol, buka halaman Cloud Monitoring.
Pilih Metrics Explorer.
Pilih metrik
apiserver_admission_webhook_admission_duration_seconds
.
Untuk mengatasi masalah ini, tinjau saran berikut:
Aturan firewall tambahan mungkin diperlukan untuk webhook. Untuk mengetahui informasi selengkapnya, lihat cara menambahkan aturan firewall untuk kasus penggunaan tertentu.
Jika webhook memerlukan lebih banyak waktu untuk diselesaikan, Anda dapat mengonfigurasi nilai waktu tunggu kustom. Latensi webhook menambah latensi permintaan API, sehingga harus dievaluasi secepat mungkin.
Jika error webhook memblokir ketersediaan cluster atau webhook tidak berbahaya untuk dihapus dan mengurangi situasi, periksa apakah mungkin untuk sementara menetapkan
failurePolicy
keIgnore
atau menghapus webhook yang melanggar.
Kegagalan atau latensi panggilan server API
Error ini mungkin terlihat dalam beberapa cara:
Error resolusi nama eksternal: Klien eksternal mungkin menampilkan error yang berisi
lookup
dalam pesan, seperti:dial tcp: lookup kubernetes.example.com on 127.0.0.1:53: no such host
Error ini tidak berlaku untuk klien yang berjalan dalam cluster. IP Layanan Kubernetes dimasukkan, sehingga tidak diperlukan resolusi.
Error jaringan: Klien mungkin mencetak error jaringan umum saat mencoba melakukan panggilan ke server API, seperti contoh berikut:
dial tcp 10.96.0.1:443: connect: no route to host dial tcp 10.96.0.1:443: connect: connection refused dial tcp 10.96.0.1:443: connect: i/o timeout
Koneksi latensi tinggi ke server API: Koneksi ke server API mungkin berhasil, tetapi permintaan kehabisan waktu tunggu di sisi klien. Dalam skenario ini, klien biasanya mencetak pesan error yang berisi
context deadline exceeded
.
Jika koneksi ke server API gagal sepenuhnya, coba koneksi dalam lingkungan yang sama tempat klien melaporkan error. Container sementara Kubernetes dapat digunakan untuk memasukkan container proses debug ke namespace yang ada sebagai berikut:
Dari tempat klien bermasalah berjalan, gunakan
kubectl
untuk melakukan permintaan dengan tingkat perincian tinggi. Misalnya, permintaanGET
ke/healthz
biasanya tidak memerlukan autentikasi:kubectl get -v999 --raw /healthz
Jika permintaan gagal atau
kubectl
tidak tersedia, Anda bisa mendapatkan URL dari output dan menjalankan permintaan secara manual dengancurl
. Misalnya, jika host layanan yang diperoleh dari output sebelumnya adalahhttps://192.0.2.1:36917/
, Anda dapat mengirim permintaan serupa sebagai berikut:# Replace "--ca-cert /path/to/ca.pem" to "--insecure" if you are accessing # a local cluster and you trust the connection cannot be tampered. # The output is always "ok" and thus contains no sensentive information. curl -v --cacert /path/to/ca.pem https://192.0.2.1:36917/healthz
Output dari perintah ini biasanya menunjukkan akar masalah koneksi yang gagal.
Jika koneksi berhasil, tetapi lambat atau habis waktunya, hal ini menunjukkan server API yang kelebihan beban. Untuk mengonfirmasi, di konsol, lihat
API Server Request Rate
dan metrik latensi permintaan diCloud Kubernetes > Anthos > Cluster > K8s Control Plane
.
Untuk mengatasi kegagalan koneksi atau masalah latensi ini, tinjau opsi perbaikan berikut:
Jika error jaringan terjadi dalam cluster, mungkin ada masalah dengan plugin Container Network Interface (CNI). Masalah ini biasanya bersifat sementara dan teratasi dengan sendirinya setelah pembuatan ulang atau penjadwalan ulang Pod.
Jika error jaringan berasal dari luar cluster, periksa apakah klien dikonfigurasi dengan benar untuk mengakses cluster, atau buat konfigurasi klien lagi. Jika koneksi melalui proxy atau gateway, periksa apakah koneksi lain yang melalui mekanisme yang sama berfungsi.
Jika server API kelebihan beban, biasanya berarti banyak klien mengakses server API secara bersamaan. Satu klien tidak dapat membebani server API karena throttle dan fitur Prioritas dan Keadilan. Tinjau beban kerja untuk area berikut:
- Berfungsi di tingkat Pod. Kesalahan membuat dan melupakan Pod lebih sering terjadi daripada resource tingkat yang lebih tinggi.
- Menyesuaikan jumlah replika melalui penghitungan yang salah.
- Webhook yang memutar kembali permintaan ke dirinya sendiri atau memperkuat beban dengan membuat lebih banyak permintaan daripada yang ditanganinya.