Memastikan stabilitas bidang kontrol saat menggunakan webhook

Webhook penerimaan, atau webhook di Kubernetes, adalah jenis pengontrol penerimaan yang dapat digunakan di cluster Kubernetes untuk memvalidasi atau mengubah permintaan ke bidang kontrol sebelum permintaan dipertahankan. Umumnya aplikasi pihak ketiga menggunakan webhook yang beroperasi di resource dan namespace yang penting bagi sistem. Webhook yang tidak dikonfigurasi dengan benar dapat memengaruhi performa dan keandalan bidang kontrol. Misalnya, webhook yang tidak dikonfigurasi dengan benar yang dibuat oleh aplikasi pihak ketiga dapat mencegah GKE membuat dan mengubah resource di namespace kube-system terkelola, yang dapat menurunkan fungsi cluster.

Google Kubernetes Engine (GKE) memantau cluster Anda dan menggunakan Layanan pemberi rekomendasi untuk memberikan panduan tentang cara mengoptimalkan penggunaan platform. Untuk membantu memastikan cluster Anda tetap stabil dan memiliki performa tinggi, lihat rekomendasi dari GKE untuk skenario berikut:

  • Webhook yang beroperasi tetapi tidak memiliki endpoint yang tersedia.
  • Webhook yang dianggap tidak aman karena beroperasi pada resource dan namespace yang penting bagi sistem.

Dengan panduan ini, Anda dapat melihat petunjuk cara memeriksa webhook yang berpotensi salah dikonfigurasi dan memperbaruinya jika perlu.

Untuk mempelajari lebih lanjut cara mengelola insight dan rekomendasi dari Pemberi Rekomendasi, lihat Mengoptimalkan penggunaan GKE dengan insight dan rekomendasi.

Mengidentifikasi webhook yang salah dikonfigurasi yang dapat memengaruhi cluster Anda

Untuk mendapatkan insight yang mengidentifikasi webhook dan dapat memengaruhi performa dan stabilitas cluster Anda, ikuti petunjuk untuk melihat insight dan rekomendasi. Anda bisa mendapatkan insight dengan cara berikut:

  • Menggunakan konsol Google Cloud
  • Menggunakan pemfilteran Google Cloud CLI atau Recommender API, dengan subjenis K8S_ADMISSION_WEBHOOK_UNSAFE dan K8S_ADMISSION_WEBHOOK_UNAVAILABLE.

Setelah Anda mengidentifikasi webhook melalui insight, ikuti petunjuk untuk memecahkan masalah webhook yang terdeteksi.

Kapan GKE mendeteksi webhook yang salah dikonfigurasi

GKE menghasilkan insight dan rekomendasi jika salah satu kriteria berikut berlaku untuk sebuah cluster:

Memecahkan masalah webhook yang terdeteksi

Bagian berikut berisi petunjuk bagi Anda untuk memecahkan masalah webhook yang dideteksi berpotensi salah dikonfigurasi oleh GKE.

Setelah Anda menerapkan petunjuk dan webhook yang dikonfigurasi dengan benar, rekomendasi akan diselesaikan dalam waktu 24 jam dan tidak lagi muncul di konsol. Jika belum 24 jam sejak Anda menerapkan panduan rekomendasi, Anda dapat menandai rekomendasi sebagai diselesaikan. Jika tidak ingin menerapkan rekomendasi, Anda dapat menolaknya.

Webhook melaporkan endpoint tidak tersedia

Jika webhook melaporkan tidak memiliki endpoint yang tersedia, Service yang mendukung endpoint webhook memiliki satu atau beberapa Pod yang tidak berjalan. Agar endpoint webhook tersedia, ikuti petunjuk untuk menemukan dan memecahkan masalah Pod Service yang mendukung endpoint webhook ini:

  1. Lihat insight dan rekomendasi, pilih insight satu per satu untuk memecahkan masalah. GKE menghasilkan satu insight per cluster, dan insight ini mencantumkan satu atau beberapa webhook dengan endpoint rusak yang harus diselidiki. Untuk setiap webhook, insight juga mencantumkan nama Service, endpoint yang rusak, dan terakhir kali endpoint dipanggil.

  2. Cari Pod aktif untuk Service yang terkait dengan webhook:

    Konsol

    Dari panel sidebar insight, lihat tabel webhook yang salah dikonfigurasi. Klik nama Service.

    kubectl

    Jalankan perintah berikut untuk menjelaskan Service:

    kubectl describe svc SERVICE_NAME -n SERVICE_NAMESPACE

    Ganti SERVICE_NAME dan SERVICE_NAMESPACE dengan nama dan namespace layanan masing-masing.

    Jika Anda tidak dapat menemukan nama Service yang tercantum di webhook, endpoint yang tidak tersedia mungkin disebabkan oleh ketidakcocokan antara nama yang tercantum dalam konfigurasi dan nama Service yang sebenarnya. Untuk memperbaiki ketersediaan endpoint, perbarui nama Service di konfigurasi webhook agar cocok dengan objek Service yang benar.

  3. Periksa Pod aktif untuk Service ini:

    Konsol

    Di bagian Pod Aktif di Detail Service, lihat daftar Pod yang mendukung Service ini.

    kubectl

    Identifikasi Pod mana yang tidak berjalan dengan mencantumkan Deployment atau Pod:

    kubectl get deployment -n SERVICE_NAMESPACE

    Atau, jalankan perintah ini:

    kubectl get pods -n SERVICE_NAMESPACE -o wide

    Untuk setiap Pod yang tidak berjalan, periksa log Pod untuk mengetahui alasan Pod tidak berjalan. Untuk mengetahui petunjuk tentang masalah umum terkait Pod, lihat Memecahkan masalah terkait workload yang di-deploy.

Webhook yang dianggap tidak aman

Jika webhook menangkap resource di namespace yang dikelola sistem, atau jenis resource tertentu, GKE menganggapnya tidak aman dan sebaiknya Anda memperbarui webhook agar tidak menangkap resource ini.

  1. Ikuti petunjuk untuk melihat insight dan rekomendasi dengan memilih insight satu per satu untuk memecahkan masalah. GKE hanya menghasilkan satu insight per cluster, dan insight ini mencantumkan satu atau beberapa konfigurasi webhook, yang masing-masing mencantumkan satu webhook atau lebih. Untuk setiap konfigurasi webhook yang tercantum, insight menyatakan alasan konfigurasi ditandai.

  2. Periksa konfigurasi webhook:

    Konsol

    Dari panel sidebar insight, lihat tabel. Di setiap baris terdapat nama konfigurasi webhook, dan alasan konfigurasi ini ditandai.

    Untuk memeriksa setiap konfigurasi, klik nama untuk membuka konfigurasi ini di dasbor Browser Objek GKE.

    kubectl

    Jalankan perintah kubectl berikut untuk mendapatkan konfigurasi webhook, dengan mengganti CONFIGURATION_NAME dengan nama konfigurasi webhook:

    kubectl get validatingwebhookconfigurations CONFIGURATION_NAME -o yaml

    Jika perintah ini tidak menampilkan apa pun, jalankan kembali perintah tersebut, dengan mengganti validatingwebhookconfigurations dengan mutatingwebhookconfigurations.

    Di bagian webhooks, ada satu atau beberapa webhook yang tercantum.

  3. Edit konfigurasi, tergantung pada alasan webhook ditandai:

    Mengecualikan namespace kube-system dan kube-node-lease

    Webhook ditandai jika scope adalah *. Atau, webhook ditandai jika cakupannya adalah Namespaced dan salah satu kondisi berikut terpenuhi:

    • Kondisi operator adalah NotIn dan values menghilangkan kube-system dan kube-node-lease, seperti dalam contoh berikut:

      webhooks:
- admissionReviewVersions:
  ...
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - blue-system
  objectSelector: {}
  rules:
  - apiGroups:
    ...
    scope: '*'
  sideEffects: None
  timeoutSeconds: 3

      Pastikan Anda menetapkan scope ke Namespaced, bukan *, sehingga webhook hanya beroperasi di namespace tertentu. Pastikan juga bahwa jika operator adalah NotIn, Anda menyertakan kube-system dan kube-node-lease dalam values (dalam contoh ini, dengan blue-system).

    • Kondisi operator adalah In dan values menyertakan kube-system dan kube-node-lease, seperti dalam contoh berikut:

      namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - blue-system
      - kube-system
      - kube-node-lease

      Pastikan Anda menetapkan scope ke Namespaced, bukan *, sehingga webhook hanya beroperasi di namespace tertentu. Pastikan jika operator adalah In, Anda tidak menyertakan kube-system dan kube-node-lease di values. Dalam contoh ini, hanya blue-system yang harus ada dalam values karena operator adalah In.

    Mengecualikan resource yang cocok

    Webhook juga ditandai jika nodes, tokenreviews, subjectaccessreviews, atau certificatesigningrequests tercantum dalam resource, seperti dalam contoh berikut:

    - admissionReviewVersions:
...
  resources:
  - 'pods'
  - 'nodes'
  - 'tokenreviews'
  - 'subjectacessreviews'
  - 'certificatesigningrequests'
  scope: '*'
sideEffects: None
timeoutSeconds: 3

    Hapus nodes, tokenreviews, subjectaccessreviews, dan certificatesigningrequests dari bagian resource. Anda dapat mempertahankan pods di resources.

Langkah selanjutnya