Membuat internal load balancer

Halaman ini menunjukkan cara men-deploy Service LoadBalancer internal yang membangun Load Balancer Jaringan passthrough internal. Sebelum membaca halaman ini, pastikan Anda memahami hal berikut:

Untuk mempelajari lebih lanjut Load Balancer Jaringan passthrough internal secara umum, lihat Ringkasan Load Balancer Jaringan passthrough internal.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
    • Aktifkan Google Kubernetes Engine API
  • Untuk 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. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.

Persyaratan

  • Tutorial ini menggunakan spec.loadBalancerClass untuk membuat Load Balancer Jaringan passthrough internal dengan backend NEG GCE_VM_IP. Tutorial ini memerlukan GKE versi 1.33.1-gke.1779000 atau yang lebih baru karena spec.loadBalancerClass memerlukan GKE versi 1.33.1-gke.1779000 atau yang lebih baru.

  • Afinitas zona memerlukan GKE versi 1.33.3-gke.1392000 dan yang lebih baru.

  • Cluster Anda harus mengaktifkan subsetelan GKE:

    • Subsetting GKE diaktifkan secara default di cluster yang menjalankan versi 1.36 dan yang lebih baru. Untuk versi ini, subsetting aktif terlepas dari nilai flag subsetting cluster.

    • Di versi GKE yang didukung sebelum versi 1.36, Anda harus mengaktifkan subsetelan GKE secara eksplisit. Anda dapat mengaktifkan subsetelan GKE saat membuat cluster baru atau dengan mengupdate cluster yang sudah ada. Setelah diaktifkan, subsetelan GKE tidak dapat dinonaktifkan. Untuk mengetahui informasi selengkapnya, lihat Memverifikasi dan mengaktifkan subsetelan GKE.

  • Jika cluster Anda menggunakan versi yang lebih lama dari 1.36, add-on HttpLoadBalancing harus diaktifkan di cluster Anda. Add-on ini diaktifkan secara default.

  • Untuk mengaktifkan Cloud Logging untuk Layanan LoadBalancer internal, cluster GKE Anda harus menggunakan versi 1.36.0-gke.2459000 atau yang lebih baru.

Memverifikasi dan mengaktifkan subsetelan GKE

Pastikan subsetelan GKE diaktifkan:

  • Subsetelan GKE selalu diaktifkan di GKE versi 1.36 dan yang lebih baru.

  • Anda dapat mengaktifkan subsetelan GKE secara manual di cluster Standard dan Autopilot baru dan yang sudah ada yang menjalankan GKE versi 1.18.19-gke.1400 dan yang lebih baru, tetapi sebelum GKE versi 1.36. Anda tidak dapat menonaktifkan subsetelan GKE setelah mengaktifkannya.

Untuk mengetahui informasi tentang alasan pentingnya subsetelan GKE, lihat Pertimbangan khusus untuk Service LoadBalancer internal.

Untuk menentukan apakah subsetting GKE diaktifkan, jalankan perintah berikut:

gcloud container clusters describe CLUSTER_NAME \
    --location=LOCATION \
    --format="get(currentMasterVersion, networkConfig.enableL4ilbSubsetting)"

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster.
  • LOCATION : zona atau region cluster.

Output perintah menunjukkan versi bidang kontrol cluster yang diikuti dengan True atau False untuk atribut networkConfig.enableL4ilbSubsetting. Tafsirkan output dengan cara berikut:

  • Jika versi bidang kontrol adalah 1.36 atau yang lebih baru, subsetting GKE diaktifkan terlepas dari apakah atribut networkConfig.enableL4ilbSubsetting adalah True atau False.
  • Jika versi bidang kontrol sebelum 1.36:
    • True berarti subsetelan GKE diaktifkan.
    • False berarti subsetelan GKE dinonaktifkan.

Untuk mengaktifkan subsetelan GKE di cluster yang menjalankan GKE versi 1.18.19-gke.1400 dan yang lebih baru, tetapi sebelum GKE versi 1.36, gunakan gcloud CLI atau konsol Google Cloud .

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 \
    --location=LOCATION
    --enable-l4-ilb-subsetting

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster.
  • LOCATION : zona atau region cluster.

Mengaktifkan subsetelan GKE—dengan menggunakan gcloud CLI, konsolGoogle Cloud , atau dengan mengupgrade cluster Anda ke versi 1.36 atau yang lebih baru—tidak akan mengubah Service LoadBalancer internal yang sudah ada. Jika ingin memigrasikan Service LoadBalancer internal yang sudah ada agar menggunakan backend NEG GCE_VM_IP, Anda harus men-deploy manifes Service pengganti.

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

  1. (Opsional) Nonaktifkan pembuatan aturan firewall VPC otomatis:

    Meskipun GKE otomatis membuat aturan firewall VPC untuk mengizinkan traffic ke load balancer internal, Anda memiliki opsi untuk menonaktifkan pembuatan aturan firewall VPC otomatis dan mengelola aturan firewall sendiri. Anda dapat menonaktifkan aturan firewall VPC hanya jika telah mengaktifkan subsetelan GKE untuk Service LoadBalancer internal. Namun, mengelola aturan firewall VPC bersifat opsional dan Anda dapat mengandalkan aturan otomatis.

    Sebelum menonaktifkan pembuatan aturan firewall VPC otomatis, pastikan Anda menentukan aturan izin yang mengizinkan traffic menjangkau load balancer dan Pod aplikasi.

    Untuk mengetahui informasi selengkapnya tentang cara mengelola aturan firewall VPC, lihat mengelola pembuatan aturan firewall otomatis dan cara menonaktifkan pembuatan aturan firewall otomatis, lihat Aturan firewall yang dikelola pengguna untuk Service LoadBalancer GKE.

  2. 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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Evenly route external traffic to all endpoints.
  externalTrafficPolicy: Cluster
  # Prioritize routing traffic to endpoints that are in the same zone.
  trafficDistribution: PreferSameZone
  selector:
    app: ilb-deployment
  # Forward traffic from TCP port 80 to port 8080 in backend Pods.
  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.
      • Kolom spec.loadBalancerClass ditetapkan ke nilai networking.gke.io/l4-regional-internal untuk menentukan Service LoadBalancer internal, seperti yang ditunjukkan dalam contoh manifes.
      • 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 stack ganda GKE tersedia di versi 1.29 atau yang lebih baru. Untuk membuat Service IPv6 stack tunggal di cluster stack ganda, tetapkan nilai kolom spec.ipFamilyPolicy ke SingleStack dan tetapkan nilai kolom spec.ipFamilies ke IPv6. Dalam cluster IPv6 stack tunggal, ini adalah nilai default dan Anda dapat menghilangkannya. Untuk mengetahui informasi selengkapnya, lihat Service dual-stack IPv4/IPv6.

      • spec.trafficDistribution untuk menentukan cara GKE merutekan traffic masuk. Untuk mengaktifkan afinitas zona, tetapkan nilai kolom ini ke PreferSameZone. Afinitas zona berarti GKE memprioritaskan perutean traffic yang berasal dari suatu zona ke node dan Pod dalam zona yang sama. Jika tidak ada Pod responsif yang tersedia di zona tersebut, traffic akan dirutekan ke zona lain. Untuk versi cluster sebelum 1.35.0-gke.1811000, gunakan PreferClose sebagai nilainya. Afinitas zona mengharuskan subsetelan GKE diaktifkan.

        Untuk pertimbangan penting dan solusi untuk menskalakan workload dengan afinitas zona, lihat Menskalakan workload dengan afinitas zona.

      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
    # Kubernetes automatically allocates a port on the node during the
    # process of implementing a Service of type LoadBalancer.
    nodePort: 30521
    port: 80
    protocol: TCP
    targetPort: 8080
  selector:
    app: ilb-deployment
  sessionAffinity: None
  trafficDistribution: PreferSameZone
  type: LoadBalancer
status:
  # IP address of the load balancer forwarding rule.
  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.

Membuat Service LoadBalancer internal di cluster IPv6 stack tunggal

Saat Anda men-deploy Service LoadBalancer internal IPv6 stack tunggal di cluster IPv6 stack tunggal atau cluster stack ganda, subnetwork yang digunakan oleh load balancer bergantung pada apakah subnetwork node cluster Anda menggunakan jenis akses IPv6 INTERNAL atau EXTERNAL. Pada cluster dual-stack, Anda harus menetapkan nilai kolom spec.ipFamilyPolicy ke SingleStack dan menetapkan nilai kolom spec.ipFamilies ke IPv6 (pada cluster IPv6 stack tunggal, ini adalah nilai default dan Anda dapat menghilangkannya). Untuk membuat Service stack ganda, tetapkan nilai kolom spec.ipFamilyPolicy ke RequireDualStack dan cantumkan kedua kelompok alamat di kolom spec.ipFamilies:

  • Cluster dengan node internal (jenis akses ULA INTERNAL): jika node cluster Anda berjalan di subnetwork internal dengan Alamat Unicast Lokal Unik (ULA), load balancer internal akan otomatis menggunakan subnetwork node yang ada. Buat Service Anda tanpa anotasi subnetwork kustom:

    apiVersion: v1
kind: Service
metadata:
  name: ilb-ipv6-svc
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: my-app
  ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080

  • Cluster dengan node eksternal (jenis akses GUA EXTERNAL): jika node cluster Anda berjalan di subnetwork eksternal dengan Global Unicast Address (GUA), load balancer internal tidak dapat menggunakan subnetwork tersebut secara langsung. Anda harus menyediakan subnetwork IPv6 internal (INTERNAL) khusus dan mereferensikan subnet menggunakan anotasi networking.gke.io/load-balancer-subnet di Service Anda:

    1. Buat subnetwork IPv6 internal khusus:

      gcloud compute networks subnets create SUBNET_NAME \
    --stack-type=ipv6_only \
    --ipv6-access-type=INTERNAL \
    --network=NETWORK_NAME \
    --region=COMPUTE_REGION

      Ganti kode berikut:

      • SUBNET_NAME: nama subnet yang akan dibuat.
      • NETWORK_NAME: nama jaringan VPC tempat Anda membuat subnet ini.
      • COMPUTE_REGION: region Compute Engine untuk subnet.

    2. Buat Service dan referensikan nama subnetwork dari langkah sebelumnya dalam anotasi networking.gke.io/load-balancer-subnet:

      apiVersion: v1
kind: Service
metadata:
  name: ilb-ipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: SUBNET_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: my-app
  ports:
    - name: tcp-port
      protocol: TCP
      port: 80
      targetPort: 8080

  1. Verifikasi alamat IP Service yang ditetapkan:

    kubectl get svc ilb-ipv6-svc

    Output mengonfirmasi bahwa kolom CLUSTER-IP dan EXTERNAL-IP (alamat ULA internal) diisi:

    NAME           TYPE           CLUSTER-IP                          EXTERNAL-IP               PORT(S)        AGE
ilb-ipv6-svc   LoadBalancer   2600:2d00:0:4:1a1e:d3b3:de4d:c549   fd20:f5d:a91f:3:0:9:0:0   80:30234/TCP   3m

Untuk mengetahui informasi selengkapnya, lihat Layanan LoadBalancer IPv6.

Menggunakan bawa alamat IPv6 Anda sendiri (BYOIPv6)

Untuk mengonfigurasi Service LoadBalancer internal IPv6 dengan bawa alamat IPv6 Anda sendiri (BYOIPv6), buat subnet dengan rentang alamat BYOIPv6 internal dan referensikan subnet tersebut di Service Anda. Rentang alamat IPv6 subnet harus berasal dari sub-awalan IPv6 regional dari awalan yang didelegasikan secara publik (PDP) dalam mode INTERNAL_IPV6_SUBNETWORK_CREATION.

Sebelum membuat Service, pastikan Anda memiliki sub-prefix IPv6 regional dalam mode INTERNAL_IPV6_SUBNETWORK_CREATION di region yang sama dengan cluster Anda. Untuk mengetahui informasi selengkapnya, lihat Membuat sub-awalan IPv6 dan Membuat subnet dengan rentang BYOIP IPv6.

  1. Di region dan jaringan VPC yang sama dengan cluster Anda, buat subnet dengan rentang BYOIPv6 internal dari sub-awalan Anda:

    gcloud compute networks subnets create BYOIP_SUBNET_NAME \
    --network=NETWORK_NAME \
    --region=REGION \
    --stack-type=IPV6_ONLY \
    --ipv6-access-type=INTERNAL \
    --ip-collection=projects/PROJECT_ID/regions/REGION/publicDelegatedPrefixes/SUB_PREFIX_NAME

    Ganti kode berikut:

    • BYOIP_SUBNET_NAME: nama subnet baru.
    • NETWORK_NAME: nama jaringan VPC cluster Anda.
    • REGION: region cluster Anda.
    • PROJECT_ID: ID project yang berisi sub-awalan.
    • SUB_PREFIX_NAME: nama sub-awalan regional dalam mode INTERNAL_IPV6_SUBNETWORK_CREATION.

  2. Opsional: Cadangkan rentang alamat IPv6 /96 internal statis dari subnet BYOIPv6. Jika Anda melewati langkah ini, GKE akan otomatis mengalokasikan rentang alamat BYOIPv6 internal sementara dari subnet yang Anda tentukan dalam anotasi networking.gke.io/load-balancer-subnet:

    gcloud compute addresses create STATIC_IPV6_NAME \
    --region=REGION \
    --subnet=BYOIP_SUBNET_NAME \
    --ip-version=IPV6

    Ganti STATIC_IPV6_NAME dengan nama untuk resource alamat IPv6 statis.

  3. Simpan manifes berikut sebagai ilb-byoipv6-svc.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: ilb-byoipv6-svc
  annotations:
    networking.gke.io/load-balancer-subnet: BYOIP_SUBNET_NAME
    # Optional: To use a static address, uncomment the following line
    # networking.gke.io/load-balancer-ip-addresses: STATIC_IPV6_NAME
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  ipFamilyPolicy: SingleStack
  ipFamilies:
  - IPv6
  selector:
    app: ilb-deployment
  ports:
  - name: tcp-port
    protocol: TCP
    port: 80
    targetPort: 8080

    Ganti BYOIP_SUBNET_NAME dengan nama subnet BYOIPv6 yang Anda buat. Secara default, GKE mengalokasikan rentang alamat BYOIPv6 internal efemeral dari subnet ini.

    Opsional: Jika Anda mencadangkan alamat BYOIPv6 internal statis pada langkah sebelumnya, hapus tanda komentar pada anotasi networking.gke.io/load-balancer-ip-addresses dan ganti STATIC_IPV6_NAME dengan nama resource alamat IPv6 statis.

  4. Terapkan manifes ke cluster Anda:

    kubectl apply -f ilb-byoipv6-svc.yaml

Untuk mengetahui informasi selengkapnya, lihat Membawa alamat IPv6 Anda sendiri (BYOIPv6).

Mengaktifkan logging untuk layanan backend

Anda dapat mengaktifkan, menonaktifkan, dan melihat log untuk Load Balancer Jaringan passthrough internal. Untuk mengaktifkan logging bagi layanan backend, Anda harus mengaktifkan subsetelan GKE.

Anda mengonfigurasi Cloud Logging dengan membuat resource kustom L4LBConfig yang menentukan setelan logging Anda. Resource L4LBConfig ditautkan ke Service Kubernetes dalam manifes Service. Setelah Anda menerapkan manifes, pengontrol GKE akan mengonfigurasi logging untuk layanan backend. Jika Anda tidak menautkan resource L4LBConfig ke Service, pengontrol akan berhenti mengelola konfigurasi logging dan membiarkan layanan backend dalam status terakhir yang diketahui. Untuk mengetahui informasi selengkapnya, lihat Memahami perilaku coast.

Anda dapat mengonfigurasi kolom berikut:

  • enabled: jika ditetapkan ke true, mengaktifkan logging untuk Service ini dan log tersedia di Cloud Logging. Jika tidak, logging akan dinonaktifkan untuk Service ini.
  • sampleRate: menentukan nilai dari 0 hingga 1,000,000 (default). 0 berarti tidak ada paket yang dicatat ke dalam log, dan 1,000,000 berarti 100% paket dicatat ke dalam log. Kolom sampleRate bersifat opsional, dan hanya relevan jika nilai kolom enable ditetapkan ke true.
  • optionalMode: mengontrol kolom metadata opsional mana yang disertakan dalam log yang dihasilkan untuk load balancer. Kolom ini menerima salah satu nilai string berikut:
    • EXCLUDE_ALL_OPTIONAL: setelan default jika optionalMode tidak ditentukan. Jika ditetapkan, tidak ada bidang opsional yang disertakan dalam log, sehingga memberikan format log yang paling ringkas.
    • INCLUDE_ALL_OPTIONAL: mengaktifkan logging untuk semua kolom opsional yang tersedia, sehingga memberikan entri log yang paling mendetail.
    • CUSTOM: menentukan daftar kustom bidang opsional yang disertakan dalam log. Dengan mode CUSTOM, Anda juga harus menggunakan parameter optionalFields untuk memberikan daftar kolom yang dipisahkan koma yang Anda inginkan.
  • optionalFields: string nama kolom yang dipisahkan koma. Menentukan kolom metadata opsional yang tepat yang ingin Anda sertakan dalam log yang dihasilkan. Kolom ini hanya digunakan jika optionalMode ditetapkan ke CUSTOM, jika tidak, nilai apa pun akan diabaikan.

Untuk mengonfigurasi Cloud Logging, buat resource L4LBConfig di namespace yang sama dengan resource Service Anda. Contoh manifes L4LBConfig berikut mengaktifkan Cloud Logging dan menetapkan frekuensi sampel ke 50% dari permintaan untuk Service load balancer tertentu.

  1. Simpan manifes berikut sebagai svc-l4lb-config.yaml:

    apiVersion: networking.gke.io/v1
kind: L4LBConfig
metadata:
  name: svc-l4lb-config
  namespace: default
spec:
  logging:
    enabled: true # must be included
    sampleRate: 500000
    optionalMode: "INCLUDE_ALL_OPTIONAL"

  2. Terapkan manifes L4LBConfig ke cluster Anda:

    kubectl apply -f svc-l4lb-config.yaml

  3. Tambahkan anotasi networking.gke.io/l4lb-config ke manifes Service ilb-svc.yaml:

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

  4. Terapkan manifes Service ke cluster Anda:

    kubectl apply -f ilb-svc.yaml

Menskalakan workload dengan afinitas zona

Karena HorizontalPodAutoscaler (HPA) menskalakan Pod berdasarkan metrik cluster gabungan, bukan beban per zona, pisahkan workload Anda berdasarkan zona untuk mencegah kelebihan beban zona. Alih-alih satu Deployment dan HPA di seluruh cluster, buat Deployment dan HPA terpisah untuk setiap zona tempat cluster Anda beroperasi. Satu Service LoadBalancer internal dapat merutekan traffic ke semua workload zona independen ini secara bersamaan.

Ringkasan arsitektur

  • Satu workload per zona: buat Deployment terpisah untuk setiap zona (misalnya, zone-a, zone-b).
  • Node selector: mengikat setiap Deployment ke zona spesifiknya menggunakan node selector topology.kubernetes.io/zone.
  • Satu HPA per zona: lampirkan HPA ke setiap Deployment tertentu sehingga Pod-nya diskalakan secara independen berdasarkan metrik yang dilokalkan.
  • Satu Service bersama: mengekspos semua Deployment ini di balik satu Service LoadBalancer internal yang dikonfigurasi dengan afinitas zona (menggunakan pemilih yang sama).

Mengonfigurasi workload zona independen

Contoh berikut menunjukkan cara menerapkan arsitektur ini di dua zona.

  1. Buat Deployment terpisah untuk setiap zona. Deployment memiliki label app yang sama, tetapi memiliki nodeSelector ketat yang mengikatnya ke zona tertentu.

    Simpan manifes berikut sebagai zonal-deployments.yaml:

    apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-zone-a
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
      zone: zone-a
  template:
    metadata:
      labels:
        app: my-app
        zone: zone-a
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "COMPUTE_ZONE_A"
      containers:
      - name: echoserver
        image: gcr.io/google_containers/echoserver:1.10
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-zone-b
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
      zone: zone-b
  template:
    metadata:
      labels:
        app: my-app
        zone: zone-b
    spec:
      nodeSelector:
        topology.kubernetes.io/zone: "COMPUTE_ZONE_B"
      containers:
      - name: echoserver
        image: gcr.io/google_containers/echoserver:1.10
        ports:
        - containerPort: 8080
        resources:
          requests:
            cpu: "100m"

    Ganti COMPUTE_ZONE_A dan COMPUTE_ZONE_B dengan zona Anda yang sebenarnya (misalnya, us-central1-a dan us-central1-b).

  2. Terapkan manifes:

    kubectl apply -f zonal-deployments.yaml

  3. Buat HPA independen untuk setiap deployment zona.

    Simpan manifes berikut sebagai zonal-hpas.yaml:

    apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-zone-a
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-zone-a
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
---
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-zone-b
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app-zone-b
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

  4. Terapkan manifes:

    kubectl apply -f zonal-hpas.yaml

  5. Pastikan Service Anda menargetkan label bersama (app: my-app) dan mengaktifkan afinitas zona.

    Simpan manifes berikut sebagai zonal-service.yaml:

    apiVersion: v1
kind: Service
metadata:
  name: my-app-service-internal
spec:
  type: LoadBalancer
  loadBalancerClass: networking.gke.io/l4-regional-internal
  trafficDistribution: PreferSameZone
  selector:
    app: my-app
  ports:
  - name: tcp-port
    protocol: TCP
    port: 8080
    targetPort: 8080

  6. Terapkan manifes:

    kubectl apply -f zonal-service.yaml

Memverifikasi komponen Load Balancer Jaringan passthrough internal

Bagian ini menunjukkan cara memverifikasi komponen utama Load Balancer Jaringan passthrough internal Anda.

  • Pastikan Service Anda berjalan:

    kubectl get service SERVICE_NAME --output yaml

    Ganti SERVICE_NAME dengan nama manifes Service.

    Jika Anda mengaktifkan afinitas zona, output akan menyertakan parameter spec.trafficDistribution. Nilai kolom ini ditetapkan ke PreferSameZone, atau PreferClose jika versi cluster lebih lama dari 1.35.0-gke.1811000.

  • Verifikasi alamat IP aturan penerusan Load Balancer Jaringan passthrough internal. Alamat IP aturan penerusan Load Balancer Jaringan passthrough internal adalah 10.128.15.245 dalam contoh yang disertakan di bagian Membuat Service LoadBalancer internal. Pastikan 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

  • Deskripsikan layanan backend load balancer menggunakan Google Cloud CLI:

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

    Ganti COMPUTE_REGION dengan region komputasi layanan backend.

    Jika Anda mengaktifkan afinitas zona:

    • Kolom networkPassThroughLbTrafficPolicy.zonalAffinity.spillover harus ditetapkan ke nilai ZONAL_AFFINITY_SPILL_CROSS_ZONE.
    • Kolom networkPassThroughLbTrafficPolicy.zonalAffinity.spilloverRatio harus ditetapkan ke 0 atau tidak disertakan.

    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
networkPassThroughLbTrafficPolicy:
  zonalAffinity:
    spillover: ZONAL_AFFINITY_SPILL_CROSS_ZONE
protocol: TCP
...

    Jika Anda menonaktifkan afinitas zona, kolom networkPassThroughLbTrafficPolicy.zonalAffinity.spillover harus ditetapkan ke ZONAL_AFFINITY_DISABLED atau tidak disertakan. Perhatikan bahwa afinitas zona akan otomatis dinonaktifkan jika cluster Anda menggunakan versi yang lebih lama dari 1.33.3-gke.1392000.

  • Tentukan daftar node dalam subset untuk layanan:

    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.

  • Tentukan daftar node responsif untuk Load Balancer Jaringan passthrough internal:

    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.

  • Pastikan Cloud Logging telah diaktifkan untuk Service:

    kubectl get svc SERVICE_NAME --output yaml

    Ganti kode berikut:

    • SERVICE_NAME: nama Layanan.

    Pada output, pastikan kolom Status.Conditions memiliki Type: LoggingConfigManaged dan Reason: Reconciled.

Menguji konektivitas ke Load Balancer Jaringan passthrough internal

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.

Jalankan perintah berikut di region yang sama dengan cluster:

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

Menghapus resource load balancer dan Service LoadBalancer internal

Anda dapat menghapus Deployment dan Service menggunakan kubectl delete atau konsolGoogle 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 Workloads

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

  3. Jika diminta untuk mengonfirmasi, pilih kotak centang Delete HorizontalPodAutoscaler associated with selected Deployment, lalu klik Delete.

Menghapus Service

Untuk menghapus Service, lakukan langkah-langkah berikut:

  1. Buka halaman Services & Ingress di konsol Google Cloud .

    Buka Services & 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 (berdekatan atau tidak berdekatan), 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 untuk mencocokkan 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.
  • IP bersama hanya didukung untuk alamat IPv4 internal. Anda tidak dapat berbagi rentang alamat IPv6 internal statis di beberapa Service LoadBalancer internal.

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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use an IP address that you create.
  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
spec:
  type: LoadBalancer
  # Request an internal load balancer.
  loadBalancerClass: networking.gke.io/l4-regional-internal
  # Use the same IP address that you used for the TCP Service.
  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

Masalah umum

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.

Error saat menggunakan anotasi networking.gke.io/ip-collection-v6 pada Service LoadBalancer internal

Saat Anda menambahkan anotasi networking.gke.io/ip-collection-v6 ke Service LoadBalancer internal, GKE akan memunculkan peristiwa peringatan IPCollectionV6Error dengan pesan berikut:

networking.gke.io/ip-collection-v6 is not supported for Internal LoadBalancers. To use BYOIPv6 with ILB, specify a BYOIP subnet using the "networking.gke.io/load-balancer-subnet" annotation

Anotasi networking.gke.io/ip-collection-v6 hanya berlaku untuk Layanan LoadBalancer eksternal IPv6 stack tunggal. Untuk menggunakan alamat BYOIPv6 dengan Service LoadBalancer internal, buat subnet dengan rentang alamat IPv6 internal dari awalan yang didelegasikan secara publik dalam mode INTERNAL_IPV6_SUBNETWORK_CREATION. Tentukan subnet tersebut menggunakan anotasi networking.gke.io/load-balancer-subnet. Untuk mengetahui informasi selengkapnya, lihat Menggunakan fitur bawa alamat IPv6 Anda sendiri (BYOIPv6).

Langkah berikutnya