Membuat load balancer internal


Halaman ini menjelaskan cara membuat Load Balancer Jaringan passthrough internal atau load balancer internal di Google Kubernetes Engine (GKE). Untuk membuat Load Balancer Jaringan passthrough eksternal, Buat Service jenis LoadBalancer.

Sebelum membaca halaman ini, pastikan Anda memahami konsep berikut:

Menggunakan subsetelan Load Balancer Jaringan passthrough internal

Load Balancer Jaringan passthrough internal membuat Service cluster Anda dapat diakses oleh klien dalam jaringan VPC cluster Anda dan oleh klien dalam jaringan yang terhubung ke jaringan VPC cluster Anda. Klien tidak harus berada di dalam cluster Anda. Misalnya, Service LoadBalancer internal dapat diakses oleh instance virtual machine (VM) yang terletak di jaringan VPC cluster.

Menggunakan subsetelan GKE

Subsetelan GKE meningkatkan skalabilitas Service LoadBalancer internal karena menggunakan grup endpoint jaringan (NEG) GCE_VM_IP sebagai backend, bukan grup instance. Saat subsetelan GKE diaktifkan, GKE akan membuat satu NEG per zona komputasi per Service LoadBalancer internal. Endpoint anggota dalam NEG adalah alamat IP node yang memiliki setidaknya salah satu dari Pod penyaluran Service. Untuk mengetahui informasi selengkapnya tentang subsetelan GKE, baca Pengelompokan node.

Persyaratan dan batasan

Subsetelan GKE memiliki persyaratan dan batasan berikut:

  • Anda dapat mengaktifkan subsetelan GKE di cluster Standard baru dan cluster yang sudah ada di GKE versi 1.18.19-gke.1400 dan yang lebih baru. Setelah diaktifkan, subsetelan GKE tidak akan dapat dinonaktifkan.
  • Subsetelan GKE dinonaktifkan secara default di cluster Autopilot. Namun, Anda dapat mengaktifkannya saat membuat cluster atau nanti.
  • Subsetelan GKE mengharuskan add-on HttpLoadBalancing diaktifkan. Add-on ini diaktifkan secara default. Di cluster Autopilot, Anda tidak dapat menonaktifkan add-on yang diperlukan ini.
  • Berlaku Kuota untuk Grup Endpoint Jaringan. Google Cloud membuat satu NEG GCE_VM_IP per Service LoadBalancer internal per zona.
  • Berlaku kuota untuk aturan penerusan, layanan backend, dan health check. Untuk mengetahui informasi selengkapnya, lihat Kuota dan batas.
  • Subsetelan GKE tidak dapat digunakan dengan anotasi untuk membagikan layanan backend di antara beberapa load balancer, alpha.cloud.google.com/load-balancer-backend-share.
  • Anda harus memiliki Google Cloud CLI versi 345.0.0 atau yang lebih baru.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan 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 gcloud components update.

Mengaktifkan subsetelan GKE di cluster Standard baru

Anda dapat membuat cluster Standard dengan subsetelan GKE yang diaktifkan menggunakan Google Cloud CLI, Konsol Google Cloud, atau Terraform. Cluster yang dibuat dengan subsetelan GKE selalu diaktifkan menggunakan subsetelan GKE.

Konsol

  1. Buka halaman Google Kubernetes Engine di konsol Google Cloud.

    Buka Google Kubernetes Engine

  2. Klik Create.

  3. Konfigurasi cluster Anda sesuai keinginan.

  4. Dari panel navigasi, pada Cluster, klik Networking.

  5. Centang kotak Aktifkan subsetelan untuk load balancer internal L4.

  6. Klik Buat.

gcloud

gcloud container clusters create CLUSTER_NAME \
    --cluster-version=VERSION \
    --enable-l4-ilb-subsetting \
    --location=COMPUTE_LOCATION

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster baru.
  • VERSION: versi GKE, harus versi 1.18.19-gke.1400 atau yang lebih baru. Anda juga dapat menggunakan opsi --release-channel untuk memilih saluran rilis. Saluran rilis harus memiliki versi default 1.18.19-gke.1400 atau yang lebih baru.
  • COMPUTE_LOCATION: Lokasi Compute Engine untuk cluster.

Jika Anda ingin menggunakan jaringan atau subjaringan non-default, jalankan perintah berikut:

  gcloud container clusters create CLUSTER_NAME \
      --cluster-version=VERSION \
      --network NETWORK_NAME \
      --subnetwork SUBNETWORK_NAME \
      --enable-l4-ilb-subsetting \
      --location=COMPUTE_LOCATION

Ganti kode berikut:

  • SUBNET_NAME: nama subnet baru. Pada GKE versi 1.22.4-gke.100 dan yang lebih baru, Anda dapat menentukan subnet dalam project yang berbeda menggunakan URL referensi yang sepenuhnya memenuhi syarat untuk kolom ini. Anda bisa mendapatkan URL referensi yang sepenuhnya memenuhi syarat menggunakan perintah gcloud compute networks subnets describe.
  • NETWORK_NAME: nama jaringan VPC untuk subnet.

Terraform

Untuk membuat cluster Standard dengan subsetelan GKE yang diaktifkan menggunakan Terraform, lihat contoh berikut:

resource "google_container_cluster" "default" {
  name               = "gke-standard-regional-cluster"
  location           = "us-central1"
  initial_node_count = 1

  enable_l4_ilb_subsetting = true

  # Set `deletion_protection` to `true` will ensure that one cannot
  # accidentally delete this instance by use of Terraform.
  deletion_protection = false
}

Untuk mempelajari lebih lanjut cara menggunakan Terraform, lihat Dukungan Terraform untuk GKE.

Mengaktifkan subsetelan GKE di cluster Standard yang sudah ada

Anda dapat mengaktifkan subsetelan GKE untuk cluster Standard yang sudah ada menggunakan gcloud CLI atau Konsol Google Cloud. Anda tidak dapat menonaktifkan subsetelan GKE setelah mengaktifkannya.

Konsol

  1. Di Konsol Google Cloud, buka halaman Google Kubernetes Engine.

    Buka Google Kubernetes Engine

  2. Di daftar cluster, klik nama cluster yang ingin diubah.

  3. Di bagian Networking, di samping kolom Subsetelan untuk Load Balancer Internal L4, klik Aktifkan subsetelan untuk load balancer internal L4.

  4. Centang kotak Aktifkan subsetelan untuk load balancer internal L4.

  5. Klik Simpan Perubahan.

gcloud

gcloud container clusters update CLUSTER_NAME \
    --enable-l4-ilb-subsetting

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster.

Mengaktifkan subsetelan GKE tidak akan mengganggu Service LoadBalancer internal yang sudah ada. Jika ingin memigrasikan Service LoadBalancer internal yang sudah ada agar menggunakan layanan backend dengan NEG GCE_VM_IP sebagai backend, Anda harus men-deploy manifes Service pengganti. Untuk mengetahui detail selengkapnya, lihat Pengelompokan node dalam dokumentasi konsep Service LoadBalancer.

Men-deploy workload

Manifes berikut menjelaskan Deployment yang menjalankan image container aplikasi web contoh.

  1. Simpan manifes sebagai ilb-deployment.yaml:

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: ilb-deployment
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: ilb-deployment
      template:
        metadata:
          labels:
            app: ilb-deployment
        spec:
          containers:
          - name: hello-app
            image: us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0
    
  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f ilb-deployment.yaml
    

Membuat Service LoadBalancer internal

Contoh berikut membuat Service LoadBalancer internal menggunakan 80 port TCP. GKE men-deploy Load Balancer Jaringan passthrough internal dengan aturan penerusan yang menggunakan port 80, tetapi kemudian meneruskan traffic ke pod backend di port 8080:

  1. Simpan manifes sebagai ilb-svc.yaml:

    apiVersion: v1
    kind: Service
    metadata:
      name: ilb-svc
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      externalTrafficPolicy: Cluster
      selector:
        app: ilb-deployment
      ports:
      - name: tcp-port
        protocol: TCP
        port: 80
        targetPort: 8080
    

    Manifes Anda harus berisi elemen berikut:

    • name untuk Service LoadBalancer internal, dalam hal ini ilb-svc.
    • Anotasi yang menentukan bahwa Anda memerlukan Service LoadBalancer internal. Untuk GKE versi 1.17 dan yang lebih baru, gunakan anotasi networking.gke.io/load-balancer-type: "Internal" seperti yang ditunjukkan dalam contoh manifes. Untuk versi sebelumnya, gunakan cloud.google.com/load-balancer-type: "Internal".
    • type: LoadBalancer.
    • Kolom spec: selector untuk menentukan Pod yang harus ditargetkan oleh Service, misalnya, app: hello.
    • Informasi port:
      • port menunjukkan port tujuan tempat aturan penerusan Load Balancer Jaringan passthrough internal menerima paket.
      • targetPort harus cocok dengan containerPort yang ditentukan di setiap Pod penayangan.
      • Nilai port dan targetPort tidak harus sama. Node selalu menjalankan NAT tujuan, mengubah alamat IP aturan penerusan load balancer tujuan serta port menjadi alamat IP Pod tujuan dan targetPort. Untuk detail selengkapnya, lihat Terjemahan Alamat Jaringan Tujuan pada node dalam dokumentasi konsep Service LoadBalancer.

    Manifes Anda dapat berisi hal berikut:

    • spec.ipFamilyPolicy dan ipFamilies untuk menentukan cara GKE mengalokasikan alamat IP ke Service. GKE mendukung single stack (khusus IPv4 atau khusus IPv6), atau Service LoadBalancer IP dual-stack. Service LoadBalancer dual-stack diimplementasikan dengan dua aturan penerusan Load Balancer Jaringan internal yang terpisah, yaitu satu untuk traffic IPv4 dan satu untuk traffic IPv6. Layanan LoadBalancer dual-stack GKE tersedia dalam versi 1.29 atau yang lebih baru. Untuk mempelajari lebih lanjut, lihat Layanan stack ganda IPv4/IPv6.

    Untuk mengetahui informasi selengkapnya, lihat Parameter Service LoadBalancer

  2. Terapkan manifes ke cluster Anda:

    kubectl apply -f ilb-svc.yaml
    
  3. Dapatkan informasi detail Service:

    kubectl get service ilb-svc --output yaml
    

    Output-nya mirip dengan yang berikut ini:

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        cloud.google.com/neg: '{"ingress":true}'
        cloud.google.com/neg-status: '{"network_endpoint_groups":{"0":"k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r"},"zones":["ZONE_NAME","ZONE_NAME","ZONE_NAME"]}'
        kubectl.kubernetes.io/last-applied-configuration: |
          {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"networking.gke.io/load-balancer-type":"Internal"},"name":"ilb-svc","namespace":"default"},"spec":{"externalTrafficPolicy":"Cluster","ports":[{"name":"tcp-port","port":80,"protocol":"TCP","targetPort":8080}],"selector":{"app":"ilb-deployment"},"type":"LoadBalancer"}}
        networking.gke.io/load-balancer-type: Internal
        service.kubernetes.io/backend-service: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
        service.kubernetes.io/firewall-rule: k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
        service.kubernetes.io/firewall-rule-for-hc: k8s2-pn2h9n5f-l4-shared-hc-fw
        service.kubernetes.io/healthcheck: k8s2-pn2h9n5f-l4-shared-hc
        service.kubernetes.io/tcp-forwarding-rule: k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r
      creationTimestamp: "2022-07-22T17:26:04Z"
      finalizers:
      - gke.networking.io/l4-ilb-v2
      - service.kubernetes.io/load-balancer-cleanup
      name: ilb-svc
      namespace: default
      resourceVersion: "51666"
      uid: d7a1a865-7972-44e1-aa9e-db5be23d6567
    spec:
      allocateLoadBalancerNodePorts: true
      clusterIP: 10.88.2.141
      clusterIPs:
      - 10.88.2.141
      externalTrafficPolicy: Cluster
      internalTrafficPolicy: Cluster
      ipFamilies:
      - IPv4
      ipFamilyPolicy: SingleStack
      ports:
      - name: tcp-port
        nodePort: 30521
        port: 80
        protocol: TCP
        targetPort: 8080
      selector:
        app: ilb-deployment
      sessionAffinity: None
      type: LoadBalancer
    status:
      loadBalancer:
        ingress:
        - ip: 10.128.15.245
    

    Output memiliki atribut berikut:

    • Alamat IP dari aturan penerusan Load Balancer Jaringan passthrough internal disertakan dalam status.loadBalancer.ingress. Alamat IP ini berbeda dengan nilai clusterIP. Dalam contoh ini, alamat IP aturan penerusan load balancer adalah 10.128.15.245.
    • Setiap Pod yang memiliki label app: ilb-deployment merupakan Pod penayangan untuk Service ini. Pod tersebut adalah Pod yang menerima paket yang dirutekan oleh Load Balancer Jaringan passthrough internal.
    • Klien memanggil Service menggunakan alamat IP loadBalancer ini dan port tujuan TCP yang ditentukan di kolom port manifes Service. Untuk mengetahui detail lengkap tentang cara paket diarahkan setelah diterima oleh node, lihat Pemrosesan paket.
    • GKE menetapkan nodePort ke Service; dalam contoh ini, port 30521 ditetapkan. nodePort tidak relevan dengan Load Balancer Jaringan passthrough internal.
  4. Periksa grup endpoint Jaringan Service:

    kubectl get svc ilb-svc -o=jsonpath="{.metadata.annotations.cloud\.google\.com/neg-status}"
    

    Output-nya mirip dengan yang berikut ini:

    {"network_endpoint_groups":{"0":"k8s2-knlc4c77-default-ilb-svc-ua5ugas0"},"zones":["ZONE_NAME"]}
    

    Respons tersebut menunjukkan bahwa GKE telah membuat grup endpoint jaringan bernama k8s2-knlc4c77-default-ilb-svc-ua5ugas0. Anotasi ini muncul di layanan jenis LoadBalancer yang menggunakan subsetelan GKE dan tidak ada di Service yang tidak menggunakan subsetelan GKE.

Memverifikasi komponen Load Balancer Jaringan passthrough internal

Alamat IP aturan penerusan Network Load Balancer internal passthrough adalah 10.128.15.245 dalam contoh yang disertakan di bagian Membuat Service LoadBalancer internal. Anda dapat melihat aturan penerusan ini disertakan dalam daftar aturan penerusan di project cluster menggunakan Google Cloud CLI:

gcloud compute forwarding-rules list --filter="loadBalancingScheme=INTERNAL"

Output-nya mencakup aturan penerusan Load Balancer Jaringan passthrough yang relevan, alamat IP-nya, dan layanan backend yang dirujuk oleh aturan penerusan (dalam contoh ini k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r).

NAME                          ... IP_ADDRESS  ... TARGET
...
k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r   10.128.15.245   ZONE_NAME/backendServices/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r

Anda dapat mendeskripsikan layanan backend load balancer menggunakan Google Cloud CLI:

gcloud compute backend-services describe k8s2-tcp-pn2h9n5f-default-ilb-svc-3bei4n1r --region=COMPUTE_REGION

Ganti COMPUTE_REGION dengan region komputasi layanan backend.

Output-nya mencakup NEG atau NEG GCE_VM_IP backend untuk Service (dalam contoh ini k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r):

backends:
- balancingMode: CONNECTION
  group: .../ZONE_NAME/networkEndpointGroups/k8s2-pn2h9n5f-default-ilb-svc-3bei4n1r
...
kind: compute#backendService
loadBalancingScheme: INTERNAL
name: aae3e263abe0911e9b32a42010a80008
...

Untuk menentukan daftar node dalam subset untuk layanan, gunakan perintah berikut:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME \
    --zone=COMPUTE_ZONE

Ganti kode berikut:

  • NEG_NAME: nama grup endpoint jaringan yang dibuat oleh pengontrol GKE.
  • COMPUTE_ZONE: zona komputasi grup endpoint jaringan yang akan digunakan.

Untuk menentukan daftar node responsif untuk Load Balancer Jaringan passthrough internal, gunakan perintah berikut:

gcloud compute backend-services get-health SERVICE_NAME \
    --region=COMPUTE_REGION

Ganti kode berikut:

  • SERVICE_NAME: nama layanan backend. Nilai ini sama dengan nama grup endpoint jaringan yang dibuat oleh pengontrol GKE.
  • COMPUTE_REGION: region komputasi dari layanan backend yang akan digunakan.

Menguji konektivitas ke Load Balancer Jaringan passthrough internal

Jalankan SSH ke instance VM dalam jaringan VPC yang sama dan di region yang sama dengan cluster, lalu jalankan perintah berikut:

curl LOAD_BALANCER_IP:80

Ganti LOAD_BALANCER_IP dengan alamat IP aturan penerusan load balancer.

Responsnya akan menunjukkan output ilb-deployment:

Hello, world!
Version: 1.0.0
Hostname: ilb-deployment-77b45987f7-pw54n

Load Balancer Jaringan passthrough internal hanya dapat diakses dalam jaringan VPC yang sama (atau jaringan yang terhubung). Secara default, aturan penerusan load balancer menonaktifkan akses global sehingga VM klien, tunnel Cloud VPN, atau lampiran Cloud Interconnect (VLAN) harus berada di region yang sama dengan Load Balancer Jaringan passthrough internal. Untuk mendukung klien di semua region, Anda dapat mengaktifkan akses global di aturan penerusan load balancer dengan menyertakan anotasi akses global dalam manifes Service.

Menghapus resource load balancer dan Service LoadBalancer internal

Anda dapat menghapus Deployment dan Service menggunakan kubectl delete atau Konsol Google Cloud.

kubectl

Menghapus Deployment

Untuk menghapus Deployment, jalankan perintah berikut:

kubectl delete deployment ilb-deployment

Menghapus Service

Untuk menghapus Service, jalankan perintah berikut:

kubectl delete service ilb-svc

Konsol

Menghapus Deployment

Untuk menghapus Deployment, lakukan langkah-langkah berikut:

  1. Buka halaman Workloads di Konsol Google Cloud.

    Buka Workload

  2. Pilih Deployment yang ingin dihapus, lalu klik Hapus.

  3. Jika diminta untuk mengonfirmasi, pilih kotak centang Hapus Autoscaler Pod Horizontal yang tertaut dengan Deployment yang dipilih, lalu klik Hapus.

Menghapus Service

Untuk menghapus Service, lakukan langkah-langkah berikut:

  1. Buka halaman Service & Ingress di Konsol Google Cloud.

    Buka Service & Ingress

  2. Pilih Service yang ingin Anda hapus, lalu klik Hapus.

  3. Saat diminta mengonfirmasi, klik Hapus.

IP bersama

Load Balancer Jaringan passthrough internal memungkinkan berbagi alamat IP Virtual di antara beberapa aturan penerusan. Kemampuan ini berguna untuk menambah jumlah port simultan di IP yang sama, atau untuk menerima traffic UDP dan TCP di IP yang sama. Dengan ini, maksimum 50 port dapat diekspos per alamat IP. IP bersama didukung secara native di cluster GKE dengan Service LoadBalancer internal. Saat melakukan deployment, kolom loadBalancerIP Service digunakan untuk menunjukkan IP mana yang harus dibagikan di seluruh Service.

Batasan

IP bersama untuk beberapa load balancer memiliki batasan dan kemampuan berikut:

  • Setiap aturan penerusan dapat memiliki hingga lima port (berurutan atau tidak berurutan), atau dapat dikonfigurasi untuk mencocokkan dan meneruskan traffic di semua port. Jika Service LoadBalancer Internal menentukan lebih dari lima port, aturan penerusan akan otomatis ditetapkan agar cocok dengan semua port.
  • Maksimum sepuluh Service (aturan penerusan) dapat berbagi alamat IP. Dengan demikian, maksimum 50 port per IP bersama diperbolehkan.
  • Setiap aturan penerusan yang memiliki alamat IP yang sama harus menggunakan kombinasi protokol dan port yang unik. Oleh karena itu, setiap Service LoadBalancer internal harus menggunakan serangkaian protokol dan port yang unik.
  • Kombinasi Service khusus TCP dan khusus UDP didukung di IP bersama yang sama, tetapi Anda tidak dapat mengekspos port TCP dan UDP di Service yang sama.

Mengaktifkan IP Bersama

Untuk mengaktifkan Service LoadBalancer internal agar berbagi IP umum, ikuti langkah-langkah berikut:

  1. Buat IP internal statis dengan --purpose SHARED_LOADBALANCER_VIP. Alamat IP harus dibuat dengan tujuan ini agar dapat dibagikan. Jika membuat alamat IP internal statis di VPC Bersama, Anda harus membuat alamat IP di project layanan yang sama dengan instance yang akan menggunakan alamat IP tersebut meskipun nilai alamat IP akan diperoleh dari rentang IP yang tersedia di subnet bersama yang dipilih dari jaringan VPC Bersama. Lihat mencadangkan IP internal statis di halaman Menyediakan VPC Bersama untuk mengetahui informasi selengkapnya.

  2. Deploy hingga sepuluh Service LoadBalancer internal menggunakan IP statis ini di kolom loadBalancerIP. Load Balancer Jaringan passthrough internal direkonsiliasi oleh pengontrol layanan GKE dan di-deploy menggunakan IP frontend yang sama.

Contoh berikut menunjukkan cara melakukannya untuk mendukung beberapa port TCP dan UDP di IP load balancer internal yang sama.

  1. Buat IP statis di region yang sama dengan cluster GKE Anda. Subnet harus berupa subnet yang sama dengan yang digunakan load balancer, yang secara default merupakan subnet yang sama dengan yang digunakan oleh IP node cluster GKE.

    Jika cluster dan jaringan VPC berada dalam project yang sama:

    gcloud compute addresses create IP_ADDR_NAME \
        --project=PROJECT_ID \
        --subnet=SUBNET \
        --addresses=IP_ADDRESS \
        --region=COMPUTE_REGION \
        --purpose=SHARED_LOADBALANCER_VIP
    

    Jika cluster Anda berada dalam project layanan VPC Bersama, tetapi menggunakan jaringan VPC Bersama dalam project host:

    gcloud compute addresses create IP_ADDR_NAME \
        --project=SERVICE_PROJECT_ID \
        --subnet=projects/HOST_PROJECT_ID/regions/COMPUTE_REGION/subnetworks/SUBNET \
        --addresses=IP_ADDRESS \
        --region=COMPUTE_REGION \
        --purpose=SHARED_LOADBALANCER_VIP
    

    Ganti kode berikut:

    • IP_ADDR_NAME: nama untuk objek alamat IP.
    • SERVICE_PROJECT_ID: ID project layanan.
    • PROJECT_ID: ID project Anda (satu project).
    • HOST_PROJECT_ID: ID project host VPC Bersama.
    • COMPUTE_REGION: region komputasi yang berisi subnet bersama.
    • IP_ADDRESS: alamat IP internal yang tidak digunakan dari rentang alamat IP utama subnet yang dipilih. Jika Anda tidak menentukan alamat IP, Google Cloud akan memilih alamat IP internal yang tidak digunakan dari rentang alamat IP utama subnet yang dipilih. Untuk menentukan alamat yang dipilih secara otomatis, Anda harus menjalankan gcloud compute addresses describe.
    • SUBNET: nama subnet bersama.
  2. Simpan konfigurasi Service TCP berikut ke file bernama tcp-service.yaml, lalu deploy ke cluster Anda. Ganti IP_ADDRESS dengan alamat IP yang telah Anda pilih di langkah sebelumnya.

    apiVersion: v1
    kind: Service
    metadata:
      name: tcp-service
      namespace: default
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: IP_ADDRESS
      selector:
        app: myapp
      ports:
      - name: 8001-to-8001
        protocol: TCP
        port: 8001
        targetPort: 8001
      - name: 8002-to-8002
        protocol: TCP
        port: 8002
        targetPort: 8002
      - name: 8003-to-8003
        protocol: TCP
        port: 8003
        targetPort: 8003
      - name: 8004-to-8004
        protocol: TCP
        port: 8004
        targetPort: 8004
      - name: 8005-to-8005
        protocol: TCP
        port: 8005
        targetPort: 8005
    
  3. Terapkan definisi Service ini di cluster Anda:

    kubectl apply -f tcp-service.yaml
    
  4. Simpan konfigurasi Service UDP berikut ke file bernama udp-service.yaml, lalu deploy. Kode ini juga menggunakan IP_ADDRESS yang telah Anda tentukan di langkah sebelumnya.

    apiVersion: v1
    kind: Service
    metadata:
      name: udp-service
      namespace: default
      annotations:
        networking.gke.io/load-balancer-type: "Internal"
    spec:
      type: LoadBalancer
      loadBalancerIP: IP_ADDRESS
      selector:
        app: my-udp-app
      ports:
      - name: 9001-to-9001
        protocol: UDP
        port: 9001
        targetPort: 9001
      - name: 9002-to-9002
        protocol: UDP
        port: 9002
        targetPort: 9002
    
  5. Terapkan file ini di cluster Anda:

    kubectl apply -f udp-service.yaml
    
  6. Validasi bahwa VIP dibagikan di antara aturan penerusan load balancer dengan mencantumkannya dan memfilter IP statis. Tindakan ini menunjukkan bahwa ada aturan penerusan TCP dan UDP yang keduanya diproses di tujuh port berbeda di IP_ADDRESS bersama, yang dalam contoh ini adalah 10.128.2.98.

    gcloud compute forwarding-rules list | grep 10.128.2.98
    ab4d8205d655f4353a5cff5b224a0dde                         us-west1   10.128.2.98     UDP          us-west1/backendServices/ab4d8205d655f4353a5cff5b224a0dde
    acd6eeaa00a35419c9530caeb6540435                         us-west1   10.128.2.98     TCP          us-west1/backendServices/acd6eeaa00a35419c9530caeb6540435
    

Pembatasan dan batas

Batasan untuk Load Balancer Jaringan passthrough internal

  • Untuk cluster yang menjalankan Kubernetes versi 1.7.4 dan yang lebih baru, Anda dapat menggunakan load balancer internal dengan subnet mode kustom, selain subnet mode otomatis.
  • Cluster yang menjalankan Kubernetes versi 1.7.X dan yang lebih baru mendukung penggunaan alamat IP yang dicadangkan untuk Load Balancer Jaringan passthrough internal jika Anda membuat alamat IP yang dicadangkan dengan --purpose flag disetel ke SHARED_LOADBALANCER_VIP. Lihat Mengaktifkan IP Bersama untuk mengetahui petunjuk langkah demi langkah. GKE hanya menyimpan alamat IP Load Balancer Jaringan passthrough internal jika Service merujuk ke alamat IP internal dengan tujuan tersebut. Jika tidak, GKE dapat mengubah alamat IP load balancer (spec.loadBalancerIP) jika Service diperbarui (misalnya, jika port diubah).
  • Meskipun alamat IP load balancer berubah (lihat poin sebelumnya), spec.clusterIP akan tetap konstan.

Batasan untuk load balancer UDP internal

  • Load balancer UDP internal tidak mendukung penggunaan sessionAffinity: ClientIP.

Masalah umum

Waktu tunggu koneksi habis setiap 10 menit

Service LoadBalancer Internal yang dibuat dengan Subsetelan mungkin mengamati gangguan traffic kira-kira setiap 10 menit. Bug ini telah diperbaiki di versi:

  • 1.18.19-gke.1700 dan yang lebih baru
  • 1.19.10-gke.1000 dan yang lebih baru
  • 1.20.6-gke.1000 dan yang lebih baru

Terjadi error saat membuat load balancer di tingkat Standard

Saat Anda membuat Load Balancer Jaringan passthrough internal dalam project dengan tingkat jaringan default project ditetapkan ke Standard, pesan error berikut akan muncul:

Error syncing load balancer: failed to ensure load balancer: googleapi: Error 400: STANDARD network tier (the project's default network tier) is not supported: Network tier other than PREMIUM is not supported for loadBalancingScheme=INTERNAL., badRequest

Untuk mengatasi masalah ini di GKE versi yang lebih lama dari 1.23.3-gke.900, konfigurasikan tingkat jaringan default project ke Premium.

Masalah ini diselesaikan di GKE versi 1.23.3-gke.900 dan yang lebih baru jika subsetelan GKE diaktifkan.

Pengontrol GKE membuat Load Balancer Jaringan passthrough internal di tingkat jaringan Premium meskipun tingkat jaringan default project ditetapkan ke Standard.

Langkah berikutnya