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 project yang Anda konfigurasi load balancernya. Untuk mengetahui informasi selengkapnya, lihat Membuat project.

• Memiliki peran identitas dan akses 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.

• Mengetahui jenis cluster yang menghosting workload Anda. Ada petunjuk berbeda untuk menyiapkan ILB bagi cluster bersama dan standar.

Membuat load balancer internal untuk cluster bersama

Anda dapat membuat ILB global atau zona untuk cluster bersama. 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:

• Gunakan gdcloud CLI untuk membuat ILB global atau zonal.
• Gunakan Networking Kubernetes Resource Model (KRM) API untuk membuat ILB global atau zonal.
• Gunakan Layanan Kubernetes secara langsung di cluster Kubernetes. Metode ini hanya tersedia untuk ILB zona.

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 zona 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-name=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 cakupan selektor yang ditentukan dibatasi. 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 jenis health check untuk ILB. Misalnya, untuk membuat TCP Health Check, tentukan sebagai berikut:

   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: jumlah pemeriksaan berurutan yang harus berhasil agar endpoint dianggap responsif. 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 zonal. 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 penampung.

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 workload 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 zonal. 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 berjenis LoadBalancer. Anda harus mendesain layanan ILB sebagai internal menggunakan anotasi networking.gke.io/load-balancer-type: internal.

   Catatan: Nilai internal peka huruf besar/kecil dan harus berupa huruf kecil.

   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. Kolom targetPort mengonfigurasi port backend yang ingin Anda teruskan traffic-nya di 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 tersebut 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.

   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.

   Penting: Jika nilai CLUSTER-IP dan EXTERNAL-IP tidak sama, berarti Anda mengonfigurasi layanan sebagai layanan load balancer eksternal (ELB). Pastikan anotasi networking.gke.io/load-balancer-type: internal sudah benar pada definisi Service. Kunci dan nilai anotasi peka huruf besar/kecil.

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-name=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 kolom PROTOCOL_PORT dalam aturan penerusan.

API

Buat ILB yang menargetkan workload 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.global.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 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 dalam kolom PORT di aturan penerusan:

      curl http://FORWARDING_RULE_VIP:PORT
      

      Ganti FORWARDING_RULE_VIP dengan VIP aturan penerusan.

Membuat load balancer internal untuk cluster standar

Anda dapat membuat ILB zonal untuk cluster standar; ILB global tidak didukung. Cakupan ILB zonal terbatas pada zona yang ditentukan pada saat pembuatan. Untuk mengetahui informasi selengkapnya, lihat Load balancer global dan per zona.

Buat ILB zonal untuk cluster standar menggunakan Layanan Kubernetes secara langsung di cluster Kubernetes. Anda hanya dapat menargetkan beban kerja di cluster tempat objek Service dibuat saat menggunakan Layanan Kubernetes secara langsung dari cluster Kubernetes.

Membuat ILB zonal untuk cluster standar

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 berjenis LoadBalancer. Anda harus mendesain layanan ILB sebagai internal menggunakan anotasi networking.gke.io/load-balancer-type: internal.

   Catatan: Nilai internal peka huruf besar/kecil dan harus huruf kecil.

   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: ILB_SERVICE_NAMESPACE
   spec:
     ports:
     - port: 1234
       protocol: TCP
       targetPort: 1234
     selector:
       k8s-app: my-app
     type: LoadBalancer
   

   Ganti kode berikut:

   • ILB_SERVICE_NAME: nama layanan ILB.
   • ILB_SERVICE_NAMESPACE: namespace yang berisi beban kerja backend.

   Kolom port mengonfigurasi port frontend yang Anda ekspos pada alamat VIP. Kolom targetPort mengonfigurasi port backend yang ingin Anda teruskan traffic-nya di 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 yang akan berfungsi 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 spesifikasi Service dalam file YAML. Ganti nama file untuk ILB_FILE dalam perintah berikut. Layanan ILB hanya dapat memilih workload yang berada di cluster yang sama dengan definisi Service.

4. Terapkan file definisi Service ke cluster:

   export KUBECONFIG=KUBECONFIG_PATH
   kubectl apply -f ILB_FILE
   

   Ganti kode berikut:

   • ILB_FILE:nama file definisi Service untuk layanan ILB.
   • KUBECONFIG_PATH: jalur ke file kubeconfig untuk cluster standar.

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

   kubectl -n ILB_SERVICE_NAMESPACE get svc ILB_SERVICE_NAME
   

   Ganti kode berikut:

   • ILB_SERVICE_NAMESPACE: namespace yang berisi beban kerja backend.
   • ILB_SERVICE_NAME: nama layanan ILB.
   • KUBECONFIG_PATH: jalur ke file kubeconfig untuk cluster standar.

   Anda akan mendapatkan output yang mirip dengan contoh berikut:

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

   Alamat IP ini kini dapat diakses dari cluster lain dalam organisasi, sesuai dengan kebijakan jaringan project yang dimiliki project tersebut.

Memilih VM sebagai backend untuk load balancer

Untuk menautkan VM ke load balancer:

1. Pastikan VM memiliki label yang cocok dengan pemilih label yang digunakan dalam konfigurasi load balancer.

   Misalnya, jika VM Anda tidak memiliki label yang sesuai, Anda dapat menambahkan label yang ditentukan dari objek backend zona yang sesuai ke VM:

   kubectl --kubeconfig MANAGEMENT_API_SERVER label virtualmachine VM_NAME -n PROJECT_NAMELABEL
   

   Ganti kode berikut:

   • LABEL: label yang cocok dengan LabelSelector dalam konfigurasi load balancer, seperti app=server.
   • VM_NAME: nama mesin virtual yang ditautkan.
   • PROJECT_NAME: nama project Anda.

2. Pastikan server memproses port yang sama seperti yang ditentukan dalam objek HealthCheck.