Mengonfigurasi load balancer internal

Load balancer internal (ILB) mengekspos layanan dalam organisasi dari kumpulan IP internal yang ditetapkan ke organisasi. Layanan ILB tidak pernah dapat diakses dari endpoint di luar organisasi.

Secara default, Anda dapat mengakses layanan ILB dalam project yang sama dari cluster mana pun dalam organisasi. Kebijakan jaringan project default tidak memungkinkan Anda mengakses resource project apa pun dari luar project, dan batasan ini juga berlaku untuk layanan ILB. Jika Administrator Platform (PA) mengonfigurasi kebijakan jaringan project yang mengizinkan akses ke project Anda dari project lain, maka layanan ILB juga dapat diakses dari project lain tersebut dalam organisasi yang sama.

Sebelum memulai

Untuk mengonfigurasi ILB, Anda harus memiliki hal berikut:

  • Memiliki project yang Anda konfigurasi load balancernya. Untuk mengetahui informasi selengkapnya, lihat Membuat project.

  • Peran akses dan identitas yang diperlukan:

    • Minta Admin IAM Organisasi Anda untuk memberi Anda peran Load Balancer Admin (load-balancer-admin).
    • Untuk ILB global, minta Admin IAM Organisasi Anda untuk memberi Anda peran Global Load Balancer Admin (global-load-balancer-admin). Untuk mengetahui informasi selengkapnya, lihat Deskripsi peran standar.

Membuat internal load balancer

Anda dapat membuat ILB global atau zonal. Cakupan ILB global mencakup seluruh semesta GDC. Cakupan ILB zonal terbatas pada zona yang ditentukan pada saat pembuatan. Untuk mengetahui informasi selengkapnya, lihat Load balancer global dan per zona.

Buat ILB menggunakan tiga metode berbeda di GDC:

Anda dapat menargetkan workload pod atau VM menggunakan KRM API dan gdcloud CLI. Anda hanya dapat menargetkan workload di cluster tempat objek Service dibuat saat menggunakan Layanan Kubernetes langsung dari cluster Kubernetes.

Membuat ILB zona

Buat ILB zonal menggunakan gcloud CLI, KRM API, atau Kubernetes Service di cluster Kubernetes:

gdcloud

Buat ILB yang menargetkan beban kerja pod atau VM menggunakan gcloud CLI.

ILB ini menargetkan semua workload dalam project yang cocok dengan label yang ditentukan dalam objek Backend.

Untuk membuat ILB menggunakan gdcloud CLI, ikuti langkah-langkah berikut:

  1. Buat resource Backend untuk menentukan endpoint bagi ILB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --zone=ZONE \
  --cluster=CLUSTER_NAME

    Ganti kode berikut:

    • BACKEND_NAME: nama yang Anda pilih untuk resource backend, seperti my-backend.
    • LABELS: Pemilih yang menentukan endpoint antara pod dan VM yang akan digunakan untuk resource backend ini. Contoh, app=web.
    • PROJECT_NAME: nama project Anda.
    • ZONE: zona yang akan digunakan untuk pemanggilan ini. Untuk menyetel flag zona untuk semua perintah yang memerlukannya, jalankan: gdcloud config set core/zone ZONE. Flag zona hanya tersedia di lingkungan multi-zona. Kolom ini bersifat opsional.
    • CLUSTER_NAME: cluster yang menjadi batas cakupan selektor yang ditentukan. Jika kolom ini tidak ditentukan, semua endpoint dengan label tertentu akan dipilih. Kolom ini bersifat opsional.

  2. Lewati langkah ini jika ILB ini ditujukan untuk workload pod. Jika Anda mengonfigurasi ILB untuk workload VM, tentukan health check untuk ILB:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --zone=ZONE

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama yang Anda pilih untuk resource pemeriksaan kondisi, seperti my-health-check.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • HEALTHY_THRESHOLD: waktu yang harus ditunggu sebelum mengklaim kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum menyatakan kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2. Kolom ini bersifat opsional.
    • PORT: port tempat health check dilakukan. Nilai defaultnya adalah 80. Kolom ini bersifat opsional.
    • ZONE: zona tempat Anda membuat ILB ini.

  3. Buat resource BackendService dan tambahkan resource Backend yang dibuat sebelumnya ke resource tersebut:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --zone=ZONE \
  --health-check=HEALTH_CHECK_NAME

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama yang dipilih untuk layanan backend ini.
    • TARGET_PORTS: daftar port target yang dipisahkan koma yang diterjemahkan oleh layanan backend ini, dengan setiap port target menentukan protokol, port pada aturan penerusan, dan port pada instance backend. Anda dapat menentukan beberapa port target. Kolom ini harus dalam format protocol:port:targetport, seperti TCP:80:8080. Kolom ini bersifat opsional.
    • HEALTH_CHECK_NAME: nama resource pemeriksaan kesehatan. Kolom ini bersifat opsional. Sertakan kolom ini hanya jika Anda mengonfigurasi ILB untuk workload VM.

  4. Tambahkan resource BackendService ke resource Backend yang dibuat sebelumnya:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --zone=ZONE

  5. Buat resource ForwardingRule internal yang menentukan VIP tempat layanan tersedia:

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=INTERNAL \
  --zone=ZONE \
  --project=PROJECT_NAME

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama Service backend Anda.
    • FORWARDING_RULE_INTERNAL_NAME dengan nama yang Anda pilih untuk aturan penerusan.
    • CIDR: kolom ini bersifat opsional. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan IP zona. Tentukan nama resource Subnet dalam namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet zonal. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Contoh resource kustom.
    • PROTOCOL_PORT: protokol dan port yang akan diekspos pada aturan penerusan. Kolom ini harus dalam format ip-protocol=TCP:80. Port yang diekspos harus sama dengan yang diekspos oleh aplikasi sebenarnya di dalam container.

  6. Untuk memvalidasi ILB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Untuk mendapatkan VIP yang ditetapkan, jelaskan aturan penerusan:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME

    2. Verifikasi traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom PROTOCOL_PORT dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti kode berikut:

      • FORWARDING_RULE_VIP: VIP aturan penerusan.
      • PORT: nomor port dari kolom PROTOCOL_PORT dalam aturan penerusan.

API

Buat ILB yang menargetkan beban kerja pod atau VM menggunakan KRM API. ILB ini menargetkan semua workload dalam project yang cocok dengan label yang ditentukan dalam objek Backend.

Untuk membuat ILB zona menggunakan KRM API, ikuti langkah-langkah berikut:

  1. Buat resource Backend untuk menentukan endpoint ILB. Buat resource Backend untuk setiap zona tempat workload ditempatkan:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: jalur kubeconfig server Management API zonal. Untuk mengetahui informasi selengkapnya, lihat Beralih ke konteks zonal.
    • PROJECT_NAME: nama project Anda.
    • BACKEND_NAME: nama resource Backend.
    • CLUSTER_NAME: Ini adalah kolom opsional. Kolom ini menentukan cluster yang menjadi batas cakupan pemilih yang ditentukan. Kolom ini tidak berlaku untuk beban kerja VM. Jika resource Backend tidak menyertakan kolom clusterName, label yang ditentukan akan berlaku untuk semua workload dalam project.

    Anda dapat menggunakan resource Backend yang sama untuk setiap zona, atau membuat resource Backend dengan kumpulan label yang berbeda untuk setiap zona.

  2. Lewati langkah ini jika ILB ini ditujukan untuk workload pod. Jika Anda mengonfigurasi ILB untuk workload VM, tentukan health check untuk ILB:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD
EOF

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama yang Anda pilih untuk resource pemeriksaan kondisi, seperti my-health-check.
    • PORT: port tempat health check dilakukan. Nilai defaultnya adalah 80.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum menyatakan kegagalan. Nilai defaultnya adalah 5.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5.
    • HEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus berhasil agar endpoint dianggap responsif. Nilai defaultnya adalah 2.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2.

  3. Buat objek BackendService menggunakan resource Backend yang dibuat sebelumnya. Jika Anda mengonfigurasi ILB untuk workload VM, sertakan resource HealthCheck.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
  healthCheckName: HEALTH_CHECK_NAME
EOF

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama yang dipilih untuk resource BackendService.
    • HEALTH_CHECK_NAME: nama resource HealthCheck yang Anda buat sebelumnya. Jangan sertakan kolom ini jika Anda mengonfigurasi ILB untuk workload pod.

  4. Buat resource ForwardingRule internal yang menentukan VIP tempat layanan tersedia.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Ganti kode berikut:

    • FORWARDING_RULE_INTERNAL_NAME: nama yang dipilih untuk resource ForwardingRuleInternal.
    • CIDR: kolom ini bersifat opsional. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan IP zona. Tentukan nama resource Subnet dalam namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet zonal. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Contoh resource kustom.
    • PORT: Gunakan kolom ports untuk menentukan array port L4 yang paketnya diteruskan ke backend yang dikonfigurasi dengan aturan penerusan ini. Setidaknya satu port harus ditentukan. Gunakan kolom port untuk menentukan nomor port. Port yang diekspos harus sama dengan yang diekspos oleh aplikasi sebenarnya di dalam container.

    • PROTOCOL: protokol yang akan digunakan untuk aturan penerusan, seperti TCP. Entri dalam array ports harus terlihat seperti berikut:

      ports:
- port: 80
  protocol: TCP

  5. Untuk memvalidasi ILB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Untuk mendapatkan VIP, gunakan kubectl get:

      kubectl get forwardingruleinternal -n PROJECT_NAME

      Outputnya akan terlihat seperti berikut:

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. Verifikasi traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom PORT dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti FORWARDING_RULE_VIP dengan VIP aturan penerusan.

Layanan Kubernetes

Anda dapat membuat ILB di GDC dengan membuat objek Service Kubernetes berjenis LoadBalancer di cluster Kubernetes. ILB ini hanya menargetkan workload di cluster tempat objek Service dibuat.

Untuk membuat ILB dengan objek Service, ikuti langkah-langkah berikut:

  1. Buat file YAML untuk definisi Service dari jenis LoadBalancer. Anda harus mendesain layanan ILB sebagai internal menggunakan anotasi networking.gke.io/load-balancer-type: internal.

    Objek Service berikut adalah contoh layanan ILB:

    apiVersion: v1
kind: Service
metadata:
  annotations:
    networking.gke.io/load-balancer-type: internal
  name: ILB_SERVICE_NAME
  namespace: PROJECT_NAME
spec:
  ports:
  - port: 1234
    protocol: TCP
    targetPort: 1234
  selector:
    k8s-app: my-app
  type: LoadBalancer

    Ganti kode berikut:

    • ILB_SERVICE_NAME: nama layanan ILB.
    • PROJECT_NAME: namespace project Anda yang berisi backend workload.

    Kolom port mengonfigurasi port frontend yang Anda ekspos pada alamat VIP. Konfigurasi kolom targetPort port backend yang ingin Anda teruskan traffic-nya pada beban kerja backend. Load balancer mendukung Network Address Translation (NAT). Port frontend dan backend dapat berbeda.

  2. Di kolom selector pada definisi Service, tentukan pod atau mesin virtual sebagai beban kerja backend.

    Pemilih menentukan workload mana yang akan diambil sebagai workload backend untuk layanan ini, berdasarkan pencocokan label yang Anda tentukan dengan label pada workload. Service hanya dapat memilih workload backend di project dan cluster yang sama tempat Anda menentukan Service.

    Untuk mengetahui informasi selengkapnya tentang pemilihan layanan, lihat https://kubernetes.io/docs/concepts/services-networking/service/.

  3. Simpan file definisi Service di project yang sama dengan beban kerja backend. Layanan ILB hanya dapat memilih workload yang berada di cluster yang sama dengan definisi Service.

  4. Terapkan file definisi Service ke cluster:

    kubectl apply -f ILB_FILE

    Ganti ILB_FILE dengan nama file definisi Service untuk layanan ILB.

    Saat Anda membuat layanan ILB, layanan akan mendapatkan alamat IP. Anda dapat memperoleh alamat IP layanan ILB dengan melihat status layanan:

    kubectl -n PROJECT_NAME get svc ILB_SERVICE_NAME

    Ganti kode berikut:

    • PROJECT_NAME: namespace project Anda yang berisi backend workload.
    • ILB_SERVICE_NAME: nama layanan ILB.

    Anda harus mendapatkan output yang mirip dengan contoh berikut:

    NAME                    TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)          AGE
ilb-service             LoadBalancer   10.0.0.1      10.0.0.1        1234:31930/TCP   22h

    Kolom CLUSTER-IP dan EXTERNAL-IP harus menampilkan nilai yang sama, yaitu alamat IP layanan ILB. Alamat IP ini kini dapat diakses dari cluster lain dalam organisasi, sesuai dengan kebijakan jaringan project yang dimiliki project tersebut.

    Jika Anda tidak mendapatkan output, pastikan Anda telah berhasil membuat layanan ILB.

    GDC mendukung nama Domain Name System (DNS) untuk layanan. Namun, nama tersebut hanya berfungsi di cluster yang sama untuk layanan ILB. Dari cluster lain, Anda harus menggunakan alamat IP untuk mengakses layanan ILB.

Membuat ILB global

Buat ILB global menggunakan gcloud CLI atau KRM API.

gdcloud

Buat ILB yang menargetkan beban kerja pod atau VM menggunakan gcloud CLI.

ILB ini menargetkan semua workload dalam project yang cocok dengan label yang ditentukan dalam objek Backend. Resource kustom Backend harus memiliki cakupan zona.

Untuk membuat ILB menggunakan gdcloud CLI, ikuti langkah-langkah berikut:

  1. Buat resource Backend untuk menentukan endpoint bagi ILB:

    gdcloud compute backends create BACKEND_NAME \
  --labels=LABELS \
  --project=PROJECT_NAME \
  --cluster=CLUSTER_NAME \
  --zone=ZONE

    Ganti kode berikut:

    • BACKEND_NAME: nama yang Anda pilih untuk resource backend, seperti my-backend.
    • LABELS: Pemilih yang menentukan endpoint antara pod dan VM yang akan digunakan untuk resource backend ini. Contoh, app=web.
    • PROJECT_NAME: nama project Anda.
    • CLUSTER_NAME: cluster yang menjadi batas cakupan selektor yang ditentukan. Jika kolom ini tidak ditentukan, semua endpoint dengan label tertentu akan dipilih. Kolom ini bersifat opsional.
    • ZONE: zona yang akan digunakan untuk pemanggilan ini. Untuk menyetel flag zona untuk semua perintah yang memerlukannya, jalankan: gdcloud config set core/zone ZONE. Flag zona hanya tersedia di lingkungan multi-zona. Kolom ini bersifat opsional.

  2. Lewati langkah ini jika ILB ini ditujukan untuk workload pod. Jika Anda mengonfigurasi ILB untuk workload VM, tentukan health check untuk ILB:

    gdcloud compute health-checks create tcp HEALTH_CHECK_NAME \
  --check-interval=CHECK_INTERVAL \
  --healthy-threshold=HEALTHY_THRESHOLD \
  --timeout=TIMEOUT \
  --unhealthy-threshold=UNHEALTHY_THRESHOLD \
  --port=PORT \
  --global

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama yang Anda pilih untuk resource pemeriksaan kondisi, seperti my-health-check.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • HEALTHY_THRESHOLD: waktu yang harus ditunggu sebelum mengklaim kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum menyatakan kegagalan. Nilai defaultnya adalah 5. Kolom ini bersifat opsional.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2. Kolom ini bersifat opsional.
    • PORT: port tempat health check dilakukan. Nilai defaultnya adalah 80. Kolom ini bersifat opsional.

  3. Buat resource BackendService dan tambahkan resource Backend yang dibuat sebelumnya ke resource tersebut:

    gdcloud compute backend-services create BACKEND_SERVICE_NAME \
  --project=PROJECT_NAME \
  --target-ports=TARGET_PORTS \
  --health-check=HEALTH_CHECK_NAME \
  --global

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama yang dipilih untuk layanan backend ini.
    • TARGET_PORTS: daftar port target yang dipisahkan koma yang diterjemahkan oleh layanan backend ini, dengan setiap port target menentukan protokol, port pada aturan penerusan, dan port pada instance backend. Anda dapat menentukan beberapa port target. Kolom ini harus dalam format protocol:port:targetport, seperti TCP:80:8080. Kolom ini bersifat opsional.
    • HEALTH_CHECK_NAME: nama resource pemeriksaan kesehatan. Kolom ini bersifat opsional. Sertakan kolom ini hanya jika Anda mengonfigurasi ILB untuk workload VM.

  4. Tambahkan resource BackendService ke resource Backend yang dibuat sebelumnya:

    gdcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --backend-zone BACKEND_ZONE \
  --backend=BACKEND_NAME \
  --project=PROJECT_NAME \
  --global

  5. Buat resource ForwardingRule internal yang menentukan VIP tempat layanan tersedia:

    gdcloud compute forwarding-rules create FORWARDING_RULE_INTERNAL_NAME \
  --backend-service=BACKEND_SERVICE_NAME \
  --cidr=CIDR \
  --ip-protocol-port=PROTOCOL_PORT \
  --load-balancing-scheme=INTERNAL \
  --project=PROJECT_NAME \
  --global

    Ganti kode berikut:

    • FORWARDING_RULE_INTERNAL_NAME: nama yang Anda pilih untuk aturan penerusan.
    • CIDR: nama resource Subnet di namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet global. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Contoh resource kustom. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan IP global. Kolom ini bersifat opsional.
    • PROTOCOL_PORT: protokol dan port yang akan diekspos pada aturan penerusan. Kolom ini harus dalam format ip-protocol=TCP:80. Port yang diekspos harus sama dengan yang diekspos aplikasi sebenarnya di dalam container.

  6. Untuk memvalidasi ILB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Untuk mendapatkan VIP yang ditetapkan, jelaskan aturan penerusan:

      gdcloud compute forwarding-rules describe FORWARDING_RULE_INTERNAL_NAME --global

    2. Verifikasi traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom PROTOCOL_PORT dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti kode berikut:

      • FORWARDING_RULE_VIP: VIP aturan penerusan.
      • PORT: nomor port dari kolom PROTOCOL_PORT dalam aturan penerusan.

API

Buat ILB yang menargetkan beban kerja pod atau VM menggunakan KRM API. ILB ini menargetkan semua workload dalam project yang cocok dengan label yang ditentukan dalam objek Backend. Untuk membuat ILB zona menggunakan KRM API, ikuti langkah-langkah berikut:

  1. Buat resource Backend untuk menentukan endpoint ILB. Buat resource Backend untuk setiap zona tempat workload ditempatkan:

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.gdc.goog/v1
kind: Backend
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_NAME
spec:
  clusterName: CLUSTER_NAME
  endpointsLabels:
    matchLabels:
      app: server
EOF

    Ganti kode berikut:

    • MANAGEMENT_API_SERVER: jalur kubeconfig jalur kubeconfig server Management API global. Untuk mengetahui informasi selengkapnya, lihat Beralih ke konteks global.
    • PROJECT_NAME: nama project Anda.
    • BACKEND_NAME: nama resource Backend.
    • CLUSTER_NAME: Ini adalah kolom opsional. Kolom ini menentukan cluster yang menjadi batas cakupan pemilih yang ditentukan. Kolom ini tidak berlaku untuk beban kerja VM. Jika resource Backend tidak menyertakan kolom clusterName, label yang ditentukan akan berlaku untuk semua workload dalam project.

    Anda dapat menggunakan resource Backend yang sama untuk setiap zona, atau membuat resource Backend dengan kumpulan label yang berbeda untuk setiap zona.

  2. Lewati langkah ini jika ILB ini ditujukan untuk workload pod. Jika Anda mengonfigurasi ILB untuk workload VM, tentukan health check untuk ILB:

    apiVersion: networking.global.gdc.goog/v1
kind: HealthCheck
metadata:
  namespace: PROJECT_NAME
  name: HEALTH_CHECK_NAME
spec:
  tcpHealthCheck:
    port: PORT
  timeoutSec: TIMEOUT
  checkIntervalSec: CHECK_INTERVAL
  healthyThreshold: HEALTHY_THRESHOLD
  unhealthyThreshold: UNHEALTHY_THRESHOLD

    Ganti kode berikut:

    • HEALTH_CHECK_NAME: nama yang Anda pilih untuk resource pemeriksaan kondisi, seperti my-health-check.
    • PORT: port tempat health check dilakukan. Nilai defaultnya adalah 80.
    • TIMEOUT: jumlah waktu dalam detik untuk menunggu sebelum menyatakan kegagalan. Nilai defaultnya adalah 5.
    • CHECK_INTERVAL: jumlah waktu dalam detik dari awal satu pemeriksaan hingga awal pemeriksaan berikutnya. Nilai defaultnya adalah 5.
    • HEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus berhasil agar endpoint dianggap responsif. Nilai defaultnya adalah 2.
    • UNHEALTHY_THRESHOLD: jumlah pemeriksaan berurutan yang harus gagal agar endpoint dianggap tidak responsif. Nilai defaultnya adalah 2.

    Karena ini adalah ILB global, buat health check di API global.

  3. Buat objek BackendService menggunakan resource Backend yang dibuat sebelumnya. Jika Anda mengonfigurasi ILB untuk workload VM, sertakan resource HealthCheck.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: BackendService
metadata:
  namespace: PROJECT_NAME
  name: BACKEND_SERVICE_NAME
spec:
  backendRefs:
  - name: BACKEND_NAME
    zone: ZONE
  healthCheckName: HEALTH_CHECK_NAME
  targetPorts:
  - port: PORT
    protocol: PROTOCOL
    targetPort: TARGET_PORT
EOF

    Ganti kode berikut:

    • BACKEND_SERVICE_NAME: nama yang dipilih untuk resource BackendService.
    • HEALTH_CHECK_NAME: nama resource HealthCheck yang Anda buat sebelumnya. Jangan sertakan kolom ini jika Anda mengonfigurasi ILB untuk workload pod.

    • ZONE: zona tempat resource Backend dibuat. Anda dapat menentukan beberapa backend di kolom backendRefs. Contoh:

      - name: my-be
  zone: Zone-A
- name: my-be
  zone: Zone-B

    • Kolom targetPorts bersifat opsional. Resource ini mencantumkan port yang diterjemahkan oleh resource BackendService ini. Jika Anda menggunakan objek ini, berikan nilai untuk berikut ini:

      • PORT: port yang diekspos oleh layanan.
      • PROTOCOL: protokol Layer-4 yang harus cocok dengan traffic. Hanya TCP dan UDP yang didukung.

      • TARGET_PORT: port yang nilai PORT-nya diterjemahkan, seperti 8080. Nilai TARGET_PORT tidak dapat diulang dalam objek tertentu. Contoh untuk targetPorts mungkin terlihat seperti berikut:

        targetPorts:
- port: 80
  protocol: TCP
  targetPort: 8080

  4. Buat resource ForwardingRule internal yang menentukan VIP tempat layanan tersedia.

    kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f - <<EOF
apiVersion: networking.global.gdc.goog/v1
kind: ForwardingRuleInternal
metadata:
  namespace: PROJECT_NAME
  Name: FORWARDING_RULE_INTERNAL_NAME
spec:
  cidrRef: CIDR
  ports:
  - port: PORT
    Protocol: PROTOCOL
  backendServiceRef:
    name: BACKEND_SERVICE_NAME
EOF

    Ganti kode berikut:

    • FORWARDING_RULE_INTERNAL_NAME: nama yang dipilih untuk resource ForwardingRuleInternal.
    • CIDR: nama resource Subnet di namespace yang sama dengan aturan penerusan ini. Resource Subnet merepresentasikan informasi permintaan dan alokasi subnet global. Untuk mengetahui informasi selengkapnya tentang resource Subnet, lihat Contoh resource kustom. Jika tidak ditentukan, CIDR IPv4/32 akan otomatis dicadangkan dari kumpulan IP global. Kolom ini bersifat opsional.
    • PORT: Gunakan kolom ports untuk menentukan array port L4 yang paketnya diteruskan ke backend yang dikonfigurasi dengan aturan penerusan ini. Setidaknya satu port harus ditentukan. Gunakan kolom port untuk menentukan nomor port. Port yang diekspos harus sama dengan port yang diekspos oleh aplikasi sebenarnya di dalam container.

    • PROTOCOL: protokol yang akan digunakan untuk aturan penerusan, seperti TCP. Entri dalam array ports harus terlihat seperti berikut:

      ports:
- port: 80
  protocol: TCP

  5. Untuk memvalidasi ILB yang dikonfigurasi, konfirmasi kondisi Ready pada setiap objek yang dibuat. Verifikasi traffic dengan permintaan curl ke VIP:

    1. Untuk mendapatkan VIP, gunakan kubectl get:

      kubectl get forwardingruleinternal -n PROJECT_NAME

      Outputnya akan terlihat seperti berikut:

      NAME           BACKENDSERVICE                               CIDR              READY
ilb-name       BACKEND_SERVICE_NAME        10.200.32.59/32   True

    2. Uji traffic dengan permintaan curl ke VIP di port yang ditentukan di kolom PORT dalam aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT

      Ganti FORWARDING_RULE_VIP dengan VIP aturan penerusan.