Mengonfigurasi load balancing berbasis health check

Standard

Dokumen ini menunjukkan cara menerapkan ketersediaan tinggi untuk alamat IP persisten di Google Kubernetes Engine (GKE) dengan menggunakan load balancing berbasis pemeriksaan kesehatan. Meskipun konfigurasi IP persisten standar memetakan satu alamat IP persisten ke satu Pod, load balancing berbasis health check memungkinkan Anda mendistribusikan traffic dari satu atau beberapa alamat IP persisten di seluruh kumpulan Pod yang sehat.

Untuk mengklaim alamat IP persisten tertentu dan mengidentifikasi Pod mana yang menerima traffic, Anda membuat resource kustom GKEIPRoute. Dengan mengintegrasikan resource GKEIPRoute dengan health check regional, GKE memantau workload Anda di lapisan jaringan dan merutekan traffic hanya ke Pod yang siap menerimanya. Anda juga dapat menetapkan Pod cadangan opsional menggunakan objek GKEIPRoute. GKE hanya merutekan traffic ke Pod standby ini jika setiap Pod aktif utama gagal dalam health check-nya.

Persyaratan dan batasan

Untuk menggunakan load balancing berbasis pemeriksaan kesehatan, cluster Anda harus menggunakan GKE versi 1.32.3-gke.1440000 atau yang lebih baru. GKE mendukung pemilihan Pod cadangan hanya pada versi 1.35.0-gke.1403000 atau yang lebih baru.
Cluster Anda harus mengaktifkan GKE Dataplane V2 dan Gateway API.
Satu objek GKEIPRoute hanya mendukung satu Pod yang cocok per node. Jika beberapa Pod di sebuah node cocok dengan pemilih Pod GKEIPRoute, GKE akan memilih Pod yang baru saja dibuat di node tersebut. untuk memastikan distribusi Pod yang tepat.
Anda tidak dapat mengubah class Gateway setelah membuat objek GKEIPRoute.
Load balancing berbasis health check hanya mendukung traffic yang dimulai dari luar workload. Traffic yang dimulai dari dalam beban kerja ke alamat IP persisten tidak didukung.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

Aktifkan Google Kubernetes Engine API.

Aktifkan Google Kubernetes Engine API

Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. gcloud CLI versi sebelumnya mungkin tidak mendukung menjalankan perintah dalam dokumen ini.
Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region. Jika Anda terutama menggunakan cluster zona, tetapkan compute/zone. Dengan menyetel lokasi default, Anda dapat menghindari error di gcloud CLI yang seperti ini: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster Anda berbeda dengan lokasi default yang Anda tetapkan.

Baca tentang alamat IP.

Menerapkan load balancing berbasis health check

Bagian ini merangkum alur kerja untuk menerapkan load balancing berbasis health check:

Buat health check regional: tentukan parameter yang digunakan GKE untuk memantau status Pod Anda. Objek ini memberi tahu lapisan jaringan tentang endpoint mana yang berfungsi dengan baik dan memenuhi syarat untuk menerima traffic dari alamat IP persisten.
Buat cluster: siapkan cluster GKE dengan GKE Dataplane V2 dan Gateway API yang diaktifkan. Komponen ini menyediakan infrastruktur dasar yang diperlukan untuk mengelola perutean IP persisten dan load balancing berbasis health check.
Cadangkan alamat IP: pilih dan cadangkan alamat IP internal atau eksternal statis di region yang sama dengan cluster Anda. Alamat ini berfungsi sebagai titik entri persisten yang akan didistribusikan GKE di seluruh kumpulan Pod aktif atau cadangan Anda.
Buat Gateway: konfigurasi objek Gateway untuk mengelola alamat IP persisten yang dipesan. Objek GKEIPRoute mengklaim dan menggunakan alamat IP tertentu dari Gateway untuk beban kerja Anda.
Buat objek GKEIPRoute: tentukan aturan perutean yang memetakan alamat IP persisten Anda ke grup Pod dengan menggunakan pemilih label. Dalam objek ini, Anda mereferensikan health check regional dan secara opsional menetapkan Pod cadangan untuk skenario failover.
Lihat endpoint yang cocok: verifikasi bahwa GKE telah mengidentifikasi Pod aktif dan cadangan Anda dengan benar dengan memeriksa EndpointSlice yang dibuat secara otomatis. Langkah ini mengonfirmasi bahwa label Anda cocok dengan Pod yang diharapkan dan bahwa lapisan jaringan siap merutekan traffic.

Langkah 1: Buat health check regional dan aturan firewall

Untuk membuat health check regional, ikuti langkah-langkah di Membuat health check. Nama yang Anda berikan di sini akan digunakan dalam konfigurasi GKEIPRoute Anda. Contoh:

gcloud compute health-checks create http reg-lb-hc \
    --region=us-central1 \
    --check-interval=5s \
    --timeout=5s \
    --healthy-threshold=2 \
    --unhealthy-threshold=2

Untuk mengizinkan pemeriksaan health check dari Google Cloud menjangkau node Anda, Anda juga harus membuat aturan firewall.

Langkah 2: Buat cluster GKE

Buat cluster dengan Gateway API dan GKE Dataplane V2 yang diaktifkan. Contoh:

gcloud container clusters create cluster-1 \
    --enable-dataplane-v2 \
    --gateway-api=standard \
    --region=us-central1

Jika Anda mengonfigurasi objek GKEIPRoute pada jaringan VPC yang berbeda dari jaringan VPC default cluster, Anda harus membuat cluster GKE dengan kemampuan multi-jaringan. Untuk informasi selengkapnya, lihat Menyiapkan dukungan multi-jaringan untuk Pod.

Langkah 3: Mencadangkan alamat IP

Cadangkan alamat IP yang ingin Anda gunakan untuk workload Anda. Anda dapat memilih antara mencadangkan alamat IP yang disediakan Google atau menggunakan alamat IP Anda sendiri (BYOIP).

Langkah 3a: Mencadangkan alamat IP yang disediakan Google

Untuk mencadangkan alamat IP eksternal, jalankan perintah berikut:

gcloud compute addresses create ADDRESS_NAME \
   --region=REGION

Ganti kode berikut:

ADDRESS_NAME: nama yang ingin Anda kaitkan dengan alamat ini.
REGION: region tempat Anda ingin mencadangkan alamat ini. Region ini harus berupa region yang sama dengan Pod tempat Anda ingin melampirkan alamat IP.

Catatan: Anda harus menentukan region saat mencadangkan alamat IP karena aturan penerusan, yang menangani perutean traffic untuk alamat IP persisten, bersifat regional. Alamat IP dan cluster GKE Anda harus berada di region yang sama agar perutean berfungsi dengan benar.

Untuk mencadangkan alamat IP internal, jalankan perintah berikut:

gcloud compute addresses create ADDRESS_NAME \
    --region REGION
    --subnet SUBNETWORK \
    --addresses IP_ADDRESS

Ganti kode berikut:

ADDRESS_NAME: nama satu atau beberapa alamat yang ingin Anda cadangkan. Jika terdapat beberapa alamat, tentukan semua alamat sebagai daftar, yang dipisahkan dengan spasi. Misalnya, example-address-1 example-address-2 example-address-3.
REGION: region untuk permintaan ini.
SUBNETWORK: subnet untuk alamat IPv4 internal ini.
IP_ADDRESS: alamat IP internal yang tidak digunakan dari rentang alamat IP utama subnet yang dipilih.

Untuk memastikan traffic dirutekan dengan benar dalam jaringan pribadi Anda, alamat IP internal harus termasuk dalam subnet default cluster atau subnet jaringan tambahan.

Untuk mengetahui informasi selengkapnya tentang alamat IP eksternal dan internal atau untuk melihat cara mencadangkan alamat menggunakan konsol Google Cloud , lihat Mencadangkan alamat IP eksternal statis dan Mencadangkan alamat IP internal statis.

Langkah 3b: Bawa alamat IP Anda sendiri (BYOIP)

Anda dapat membawa alamat IP Anda sendiri (BYOIP), alih-alih mengandalkan alamat IP yang disediakan Google. BYOIP berguna jika Anda memerlukan alamat IP tertentu untuk aplikasi Anda atau memindahkan sistem yang ada ke Google Cloud. Untuk menggunakan BYOIP, Google akan memvalidasi bahwa Anda adalah pemilik rentang alamat IP tersebut, dan setelah alamat IP diimpor ke Google Cloud, Anda dapat menetapkannya sebagai alamat IP untuk Pod GKE. Untuk mengetahui informasi selengkapnya, lihat Membawa alamat IP Anda sendiri.

Langkah 4: Buat objek Gateway

Anda membuat Gateway menggunakan salah satu class Gateway berikut yang hanya mendukung jenis jaringan L3:

gke-passthrough-lb-external-managed atau
gke-passthrough-lb-internal-managed.

Contoh berikut menentukan Gateway yang mengelola kumpulan alamat IP eksternal:

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
  name: lb-gateway
spec:
  gatewayClassName: gke-passthrough-lb-external-managed

  listeners:
    - name: default
      port: 443
      protocol: none
      allowedRoutes:
        namespaces:
          from: All

  addresses:
    - value: "34.123.10.1/32"
      type: "gke.networking.io/cidr"
    - value: "34.123.10.2/32"
      type: "gke.networking.io/cidr"

Pada contoh sebelumnya, perhatikan kolom berikut:

addresses: mencantumkan semua rentang alamat IP yang izinnya dikelola oleh Gateway tertentu.
listener: mengidentifikasi namespace tempat objek GKEIPRoute dapat mereferensikan Gateway ini.

Untuk mengetahui detail tentang penggunaan Listener, lihat Membuat objek Gateway.

Langkah 5: Buat objek GKEIPRoute dengan konfigurasi load balancing dan health check

Buat objek GKEIPRoute tempat Anda menentukan pemilih Pod utama dan cadangan, serta kaitkan health check yang Anda buat pada langkah 1.

kind: GKEIPRoute
apiVersion: networking.gke.io/v1
metadata:
  namespace: default
  name: my-ip-route
spec:
  parentRefs:
  - name: lb-gateway
  addresses:
  - value: "34.123.10.1/32"
    type: "gke.networking.io/cidr"
  - value: "34.123.10.2/32"
    type: "gke.networking.io/cidr"
  network: default
  podSelector:
    matchLabels:
      component: activePodSelector

  loadBalancing:
    healthCheckName: "reg-lb-hc"
    backupPodSelector:
      namespaceSelector:
        matchLabels:
          environment: test
          dc: us-central
      podSelector:
        matchLabels:
          component: backupPodSelector
---
apiVersion: apps/v1
kind: Deployment
metadata:
  namespace: default
  name: proxy-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      component: proxy
  template:
    metadata:
      # annotations:  <- Include these lines if the pods are multi-nic pods
      #   networking.gke.io/default-interface: 'eth0'
      #   networking.gke.io/interfaces: '[{"interfaceName":"eth0","network":"default"}, {"interfaceName":"eth1","network":"blue-network"}]'
      labels:
        component: proxy
    spec:
      containers:
      - name: hello-app
        image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0

Perhatikan hal berikut:

podSelector: mengidentifikasi Pod aktif utama yang menerima traffic dari alamat IP persisten yang ditentukan. Kolom ini menggunakan label untuk mencocokkan Pod dalam namespace yang sama dengan resource GKEIPRoute. GKE mendistribusikan traffic ke semua Pod yang sehat dan cocok dengan pemilih ini. Jika beberapa Pod yang cocok berada di node yang sama, GKE hanya akan memilih Pod yang baru dibuat untuk menerima traffic. Label yang ditentukan di sini tidak boleh tumpang-tindih dengan label di kolom backupPodSelector. Kolom ini dapat diubah.
backupPodSelector: menentukan Pod standby yang menerima traffic hanya jika semua Pod utama yang cocok dengan objek podSelector gagal dalam health check. Pemilih ini mencakup hal berikut:
- namespaceSelector: menentukan namespace mana yang dicari GKE untuk menemukan Pod cadangan ini. Anda dapat membatasi penelusuran ke namespace tertentu menggunakan pemilih label. Jika kolom ini tidak ada atau kosong, GKE akan mencari Pod cadangan di semua namespace dalam cluster.
- podSelector: mencocokkan Pod cadangan berdasarkan labelnya. Label ini harus berbeda dari yang digunakan dalam objek podSelector utama.

Untuk mengetahui detail selengkapnya tentang kolom lain dalam manifes ini, lihat Membuat objek GKEIPRoute.

Langkah 6: Menggunakan alamat IP yang ditetapkan di dalam Pod

Menetapkan alamat IP ke Pod GKE menggunakan objek GKEIPRoute tidak secara otomatis membuat alamat IP dapat digunakan oleh aplikasi Anda. Alamat IP ditangani di tingkat perutean jaringan, tetapi konfigurasi default Pod Anda tidak akan mengetahuinya. Anda harus mengonfigurasi spesifikasi Pod untuk mengenali dan menggunakan alamat dalam Pod. Untuk melakukannya, Pod Anda memerlukan izin hak istimewa.

Anda dapat mengonfigurasi spesifikasi Pod menggunakan salah satu opsi berikut:

Ubah net.ipv4.ip_nonlocal_bind sysctl

Anda dapat mengubah setelan sistem untuk mengizinkan aplikasi Anda menggunakan alamat IP yang tidak ditetapkan langsung ke antarmukanya dengan menyetel net.ipv4.ip_nonlocal_bind sysctl di Pod securityContext. Opsi ini berguna jika aplikasi Anda dapat mengikat ke alamat IP yang tidak ada di antarmuka.

Tambahkan hal berikut ke spesifikasi YAML Deployment atau StatefulSet Anda di bagian spec.template.spec:
```
securityContext:
  sysctls:
  - name: net.ipv4.ip_nonlocal_bind
    value: "1"
```
Tambahkan alamat IP yang ditetapkan ke antarmuka Pod

Anda dapat menambahkan alamat IP yang diklaim oleh objek GKEIPRoute secara manual ke salah satu antarmuka Pod menggunakan init container. Tindakan ini membuat alamat IP terlihat oleh Pod seolah-olah ditetapkan secara langsung. Hal ini memerlukan kemampuan NET_ADMIN.

Tambahkan hal berikut ke spesifikasi YAML Deployment atau StatefulSet Anda di bagian spec.template.spec:
```
initContainers:
- name: configure-ips
  image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
  command: ['sh', '-c', 'ip address add ASSIGNED_IP/32 dev eth0']
  securityContext:
    capabilities:
      add:
      - NET_ADMIN
```
Ganti ASSIGNED_IP dengan salah satu alamat IP yang ditetapkan ke objek GKEIPRoute.
Socket mentah: untuk kontrol lebih lanjut, aplikasi Anda dapat berinteraksi langsung dengan stack jaringan (lanjutan).
Stack alamat IP ruang pengguna: dalam kasus khusus, aplikasi terpisah dapat berjalan dalam Pod untuk mengelola alamat IP (sangat canggih).

Langkah 7: Aktifkan ARP untuk alamat IP yang ditetapkan (khusus jaringan default)

Untuk membuat permintaan dan respons Address Resolution Protocol (ARP) yang valid, dan untuk membuat koneksi baru ke Pod menggunakan alamat IP yang ditetapkan oleh objek GKEIPRoute di jaringan default, Anda harus mengonfigurasi variabel arp_announce.

Untuk menetapkan variabel arp_announce, jalankan perintah berikut di Pod Anda:

echo "2" > /proc/sys/net/ipv4/conf/eth0/arp_announce

dengan variabel arp_announce mengontrol cara penanganan pengumuman ARP. Menyetelnya ke '2' memastikan bahwa pengumuman ARP dilakukan untuk alamat IP persisten, sehingga perangkat lain di jaringan dapat mempelajari asosiasi baru.

Langkah 8: Lihat Endpoint yang cocok

Untuk mengelola distribusi traffic, GKE membuat EndpointSlice untuk setiap objek GKEIPRoute. Slice ini berfungsi sebagai registri semua Pod yang ditetapkan sebagai tujuan perutean untuk rute tertentu tersebut.

GKE membuat EndpointSlice terpisah untuk endpoint aktif dan cadangan. Sistem akan otomatis menskalakan jumlah EndpointSlice berdasarkan workload Anda. Meskipun satu EndpointSlice mendukung hingga 1.000 endpoint, GKE akan membuat slice tambahan jika jumlah Pod yang cocok melebihi batas ini.

Untuk melihat semua EndpointSlice untuk objek GKEIPRoute tertentu, jalankan perintah berikut:

kubectl get endpointslices --all-namespaces -l \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,\
  networking.gke.io/gkeiproute-namespace=GKEIPROUTE_NAMESPACE

Ganti kode berikut:

GKEIPROUTE_NAME: nama manifes GKEIPRoute.
GKEIPROUTE_NAMESPACE: namespace manifes GKEIPRoute.

Output berikut menunjukkan contoh EndpointSlice:

apiVersion: discovery.k8s.io/v1
kind: EndpointSlice
metadata:
 name: {gkeiproute_name-truncated}-{gkeiproute_namespace-truncated}-backup-{unique_hash}
 namespace: {gkeiproute_namespace}
 labels:
  endpointslice.kubernetes.io/managed-by: gkeiproute-controller
  networking.gke.io/gkeiproute-name: {gkeiproute_name}
  networking.gke.io/gkeiproute-namespace: {gkeiproute_namespace}
  networking.gke.io/pip-es-role: backup
 ownerReferences:
  - kind: GKEIPRoute
    name: {gkeiproute_name}
    apiVersion: networking.gke.io/v1
    uid: {uid}
    controller: true
addressType: IPv4
endpoints:
 - addresses:
     - "{pod_ip_address}"
   targetRef:
     Name: {pod_name}
   nodeName: {node_name}

Untuk melihat EndpointSlice secara khusus untuk endpoint aktif atau cadangan, filter hasilnya menggunakan label pip-eps-role. Contoh:

kubectl get endpointslices --all-namespaces -l \
   networking.gke.io/pip-eps-role=ROLE \
  networking.gke.io/gkeiproute-name=GKEIPROUTE_NAME,

Ganti kode berikut:

ROLE: jenis endpoint yang ingin Anda lihat, active atau backup.
GKEIPROUTE_NAME: nama objek GKEIPRoute tertentu Anda.

Memecahkan masalah load balancing berbasis health check

Bagian ini menunjukkan cara menyelesaikan masalah terkait load balancing berbasis pemeriksaan kesehatan.

Beberapa Pod aktif tidak sehat, tetapi Pod cadangan tidak menerima traffic

Gejala

Status GKEIPRoute menunjukkan Ready, yang menunjukkan bahwa konfigurasi alamat IP untuk Pod yang cocok telah selesai. Pemeriksaan kondisi atau diagnostik lainnya menunjukkan bahwa beberapa Pod aktif tidak responsif. Namun, pod cadangan tidak menerima traffic.

Penyebab

Pod cadangan tidak menerima traffic hingga semua Pod aktif tidak responsif. Hingga saat itu, semua traffic didistribusikan ke Pod yang responsif dan aktif yang tersisa.

Resolusi

Jika perlu, perbarui label kolom podSelector sehingga tidak lagi cocok dengan Pod aktif mana pun. GKE secara otomatis merutekan traffic ke grup backend.

GKEIPRoute dikonfigurasi, tetapi tidak semua Pod menerima traffic

Gejala

Status GKEIPRoute menampilkan Ready, yang menunjukkan bahwa konfigurasi alamat IP untuk Pod yang cocok telah selesai, tetapi beberapa Pod yang cocok tidak menerima traffic.

Penyebab

Pod yang tidak menerima traffic mungkin tidak responsif, atau mungkin tidak merespons health check dengan benar. Perhatikan bahwa jika semua Pod yang cocok tidak responsif, GKE akan mendistribusikan traffic ke semua Pod, terlepas dari status responsifnya.

Resolusi

Verifikasi bahwa Pod dalam kondisi baik: gunakan Google Cloud CLI atau konsolGoogle Cloud untuk memverifikasi bahwa Pod merespons pemeriksaan kondisi dengan benar.
Lakukan penyelidikan lebih lanjut jika perlu: jika Pod tidak sehat, pastikan Anda telah menyiapkan firewall untuk health check dengan benar, dan Pod Anda merespons.

Error Konfigurasi load balancer tidak valid

Bagian ini membantu Anda memecahkan masalah error status GKEIPRoute.

`Backup pod and active pod are on the same node`

Gejala

Status GKEIPRoute melaporkan error berikut:

invalid LB configuration: Backup pod %s and active pod %s are on the same node %s. Active and backup pods must reside on different nodes.

Penyebab

Pod aktif dan Pod cadangan yang cocok dengan objek GKEIPRoute yang sama dijadwalkan ke node yang sama. Dengan kata lain, ada Pod yang cocok dengan objek podSelector aktif dan cadangan di node yang sama.

Resolusi

Pastikan Pod aktif dan cadangan berada di node yang berbeda. Perbarui konfigurasi GKEIPRoute dan sesuaikan label podSelector atau backupPodSelector agar tidak ada dua Pod pada node yang sama yang cocok dengan objek GKEIPRoute yang sama.

`Pod cannot be selected as both an active and a backup pod`

Gejala

Status GKEIPRoute melaporkan error berikut:

invalid LB configuration: pod %s cannot be selected as both an active and a backup pod. Active and backup pod sets must be mutually exclusive

Penyebab

Satu atau beberapa Pod cocok dengan pemilih label untuk kolom podSelector (aktif) dan kolom backupPodSelector (siaga). GKE mewajibkan kedua grup ini tidak saling terikat. Satu Pod tidak dapat berfungsi sebagai cadangannya sendiri.

Resolusi

Pastikan Pod aktif dan cadangan Anda unik. Ubah kolom podSelector atau kolom backupPodSelector dalam manifes GKEIPRoute Anda untuk menggunakan kunci dan nilai label yang lebih spesifik atau berbeda.

Status `NoPodsFound`

Gejala

Manifes GKEIPRoute menampilkan status NoPodsFound yang menunjukkan bahwa tidak ada Pod dalam namespace yang memiliki label yang cocok.

Kemungkinan penyebab

Label salah: Pod yang ingin Anda gunakan dengan alamat IP yang dikonfigurasi mungkin memiliki label yang salah, atau tidak memiliki label sama sekali.
Tidak ada Pod: jika reactionMode == Exists, periksa apakah Pod ditetapkan ke node dengan memeriksa kolom pod.Spec.nodeName. Mungkin tidak ada Pod yang berjalan di namespace GKEIPRoute yang cocok dengan pemilih.
Pod tidak Siap: jika reactionMode == ReadyCondition, periksa apakah status Pod adalah READY. Jika ada Pod yang cocok, tetapi tidak dalam status READY, Pod tidak dapat melayani traffic dan tidak dipilih.

Resolusi

Periksa label: pastikan label di kolom podSelector objek GKEIPRoute Anda cocok dengan label yang telah Anda terapkan ke Pod yang dimaksud.
Verifikasi keberadaan Pod: pastikan Pod dengan label yang benar benar-benar ada di namespace objek GKEIPRoute yang ditentukan oleh Listener Gateway Anda. Jika reactionMode == Exists, periksa apakah Pod ditetapkan ke node dengan memeriksa kolom pod.Spec.nodeName.
Konfirmasi kesiapan Pod: jika reactionMode == ReadyCondition, periksa apakah status Pod adalah READY. Pastikan Pod dalam status Ready menggunakan perintah berikut:
```
kubectl get pods -n NAMESPACE
```
Pod dalam status lain (misalnya, Pending, Error) tidak dipilih.

Status `Mutated` saat Pod yang cocok ditemukan dan pemrograman alamat IP GKEIPRoute sedang berlangsung

Gejala

Status GKEIPRoute menampilkan Mutated, yang menunjukkan bahwa konfigurasi alamat IP untuk Pod yang cocok sedang berlangsung.

Kemungkinan penyebab

Anda dapat mengharapkan status Mutated selama konfigurasi saat sistem sedang menyiapkan jalur data GKE dan Google Cloud resource untuk alamat IP yang dikonfigurasi.

Resolusi

Tunggu dan coba lagi: dalam sebagian besar kasus, proses konfigurasi akan selesai secara otomatis dalam waktu singkat. Periksa status setelah menunggu. Statusnya akan berubah menjadi Ready jika berhasil.
Lakukan penyelidikan lebih lanjut (jika perlu): jika status Mutated tetap ada selama jangka waktu yang lama, hal ini mungkin menunjukkan adanya error konfigurasi. Periksa kondisi status lainnya pada objek GKEIPRoute Anda:
- Diterima: menunjukkan apakah penyiapan GKEIPRoute Anda valid.
- GCPReady: menunjukkan apakah resource Google Cloud disiapkan seperti yang diharapkan.

Cari pesan error dalam kondisi ini untuk membantu memecahkan masalah.

Langkah berikutnya

Pelajari lebih lanjut Alamat IP persisten untuk Pod GKE

Mengonfigurasi load balancing berbasis health check Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Persyaratan dan batasan

Sebelum memulai

Menerapkan load balancing berbasis health check

Langkah 1: Buat health check regional dan aturan firewall

Langkah 2: Buat cluster GKE

Langkah 3: Mencadangkan alamat IP

Langkah 3a: Mencadangkan alamat IP yang disediakan Google

Langkah 3b: Bawa alamat IP Anda sendiri (BYOIP)

Langkah 4: Buat objek Gateway

Langkah 5: Buat objek GKEIPRoute dengan konfigurasi load balancing dan health check

Langkah 6: Menggunakan alamat IP yang ditetapkan di dalam Pod

Langkah 7: Aktifkan ARP untuk alamat IP yang ditetapkan (khusus jaringan default)

Langkah 8: Lihat Endpoint yang cocok

Memecahkan masalah load balancing berbasis health check

Beberapa Pod aktif tidak sehat, tetapi Pod cadangan tidak menerima traffic

GKEIPRoute dikonfigurasi, tetapi tidak semua Pod menerima traffic

Error Konfigurasi load balancer tidak valid

Backup pod and active pod are on the same node

Pod cannot be selected as both an active and a backup pod

Status NoPodsFound

Status Mutated saat Pod yang cocok ditemukan dan pemrograman alamat IP GKEIPRoute sedang berlangsung

Langkah berikutnya

Mengonfigurasi load balancing berbasis health check

`Backup pod and active pod are on the same node`

`Pod cannot be selected as both an active and a backup pod`

Status `NoPodsFound`

Status `Mutated` saat Pod yang cocok ditemukan dan pemrograman alamat IP GKEIPRoute sedang berlangsung