Memecahkan masalah server Kubernetes API

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.
  • Pantau latensi webhook dengan langkah-langkah berikut:

    1. Di konsol, buka halaman Cloud Monitoring.

      Buka halaman Cloud Monitoring

    2. Pilih Metrics Explorer.

    3. 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 ke Ignore 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. Penampung sementara Kubernetes dapat digunakan untuk memasukkan penampung proses debug ke namespace yang ada sebagai berikut:

  1. Dari tempat klien bermasalah berjalan, gunakan kubectl untuk melakukan permintaan dengan tingkat perincian tinggi. Misalnya, permintaan GET ke /healthz biasanya tidak memerlukan autentikasi:

    kubectl get -v999 --raw /healthz
    
  2. Jika permintaan gagal atau kubectl tidak tersedia, Anda bisa mendapatkan URL dari output dan menjalankan permintaan secara manual dengan curl. Misalnya, jika host layanan yang diperoleh dari output sebelumnya adalah https://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 di Cloud 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.

Langkah berikutnya

Jika Anda memerlukan bantuan tambahan, hubungi Cloud Customer Care.