Load balancing berbasis container melalui NEG zona mandiri

Autopilot Standard

---

Halaman ini menunjukkan cara membuat Service Kubernetes yang didukung oleh grup endpoint jaringan (NEG) GCE_VM_IP_PORT zona di cluster berbasis VPC Google Kubernetes Engine (GKE).

Untuk informasi tentang manfaat, persyaratan, dan batasan load balancing berbasis container, lihat Load balancing berbasis container.

Ringkasan

NEG mewakili sekumpulan endpoint. GKE mendukung NEG mandiri dari jenis GCE_VM_IP_PORT. GCE_VM_IP_PORT NEG mendukung endpoint menggunakan alamat IP internal utama VM atau alamat IP dari salah satu rentang IP aliasnya.

Dalam konteks cluster native VPC GKE menggunakan NEG mandiri, setiap endpoint adalah alamat IP Pod dan port target. Alamat IP pod diambil dari rentang IP alias node untuk Pod, yang berasal dari rentang alamat IP sekunder subnet untuk Pod milik cluster.

GKE menyediakan pengontrol NEG untuk mengelola keanggotaan NEG GCE_VM_IP_PORT. Anda dapat menambahkan NEG yang dibuat sebagai backend ke layanan backend untuk load balancer yang Anda konfigurasi di luar GKE API.

Diagram berikut menjelaskan hubungan objek Kubernetes API dengan objek Compute Engine.

Ingress dengan NEG

Saat NEG digunakan dengan Ingress GKE, pengontrol Ingress akan memfasilitasi pembuatan semua aspek load balancer. Hal ini termasuk pembuatan alamat IP virtual, aturan penerusan, health check, aturan firewall, dan lainnya.

Ingress adalah cara yang direkomendasikan untuk menggunakan load balancing berbasis container karena memiliki banyak fitur yang menyederhanakan pengelolaan NEG. NEG mandiri dapat menjadi opsi jika NEG yang dikelola oleh Ingress tidak membantu kasus penggunaan Anda.

NEG Mandiri

Jika NEG di-deploy dengan load balancer yang disediakan oleh apa pun selain Ingress, NEG akan dianggap sebagai NEG mandiri. NEG mandiri di-deploy dan dikelola melalui pengontrol NEG, tetapi aturan penerusan, health check, dan objek load balancing lainnya di-deploy secara manual.

NEG mandiri tidak bertentangan dengan load balancing berbasis container yang didukung oleh Ingress.

Ilustrasi berikut menunjukkan perbedaan cara deployment objek load balancing di setiap skenario:

Mencegah kebocoran NEG

Dengan NEG mandiri, Anda bertanggung jawab untuk mengelola siklus NEG dan resource yang membentuk load balancer. NEG dapat bocor jika hal ini terjadi:

• Saat layanan GKE dihapus, pembersihan sampah memori tidak akan terjadi pada NEG terkait jika NEG masih direferensikan oleh layanan backend. Hapus referensi NEG dari layanan backend untuk memungkinkan penghapusan NEG.
• Saat cluster dihapus, NEG mandiri tidak akan dihapus.

Kasus penggunaan NEG mandiri

NEG mandiri memiliki beberapa kegunaan penting. NEG mandiri sangat fleksibel. Hal ini berbeda dengan Ingress (digunakan dengan atau tanpa NEG) yang menentukan kumpulan objek load balancing tertentu yang dipilih dengan cara tertentu agar mudah digunakan.

Kasus penggunaan untuk NEG mandiri meliputi:

Layanan heterogen container dan VM

NEG dapat berisi alamat IP VM dan container. Artinya, satu alamat IP virtual dapat mengarah ke backend yang terdiri dari workload Kubernetes dan non-Kubernetes. Layanan ini juga dapat digunakan untuk memigrasikan workload yang ada ke cluster GKE.

NEG mandiri dapat mengarah ke IP VM yang memungkinkan konfigurasi manual load balancer mengarah ke backend yang terdiri dari VM dan container untuk VIP layanan yang sama.

Pengontrol Ingress yang disesuaikan

Anda dapat menggunakan pengontrol Ingress yang disesuaikan (atau tanpa pengontrol Ingress) untuk mengonfigurasi load balancer yang menargetkan NEG mandiri.

Menggunakan Cloud Service Mesh dengan GKE

Anda dapat menggunakan Cloud Service Mesh dengan GKE. Cloud Service Mesh menggunakan NEG mandiri guna menyediakan load balancing berbasis container untuk mesh layanan terkelola.

Menggunakan Load Balancer Jaringan proxy eksternal dengan GKE

Anda dapat menggunakan NEG mandiri untuk melakukan load balancing langsung ke container dengan Load Balancer Jaringan proxy eksternal yang tidak didukung secara native oleh Kubernetes/GKE.

Kesiapan pod

Gate kesiapan adalah fitur ekstensibilitas Kubernetes yang memungkinkan injeksi masukan atau sinyal tambahan ke dalam PodStatus agar Pod dapat bertransisi ke status Ready. Pengontrol NEG mengelola gate kesiapan kustom untuk memastikan jalur jaringan lengkap dari load balancer Compute Engine ke pod dapat berfungsi. Gate kesiapan pod di GKE dijelaskan dalam load balancing berbasis container.

Ingress dengan NEG men-deploy dan mengelola health check Compute Engine atas nama load balancer. Namun, NEG mandiri tidak membuat asumsi tentang health check Compute Engine karena diharapkan akan di-deploy dan dikelola secara terpisah. Health check Compute Engine harus selalu dikonfigurasi bersama dengan load balancer untuk mencegah traffic dikirim ke backend yang belum siap menerima. Jika tidak ada status health check yang terkait dengan NEG (biasanya karena tidak ada health check yang dikonfigurasi), pengontrol NEG akan menandai nilai gate kesiapan Pod ke True jika endpoint terkaitnya diprogram di NEG.

Persyaratan

Cluster Anda harus berbasis VPC. Untuk mempelajari lebih lanjut, lihat Membuat cluster VPC native.

Cluster Anda harus mengaktifkan add-on HttpLoadBalancing. Add-on HttpLoadBalancing diaktifkan secara default di Cluster GKE.

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.
  Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region dan compute/zone. Dengan menyetel lokasi default, Anda dapat menghindari error di gcloud CLI yang seperti ini: One of [--zone, --region] must be supplied: Please specify location.

Menggunakan NEG mandiri

Petunjuk berikut menunjukkan cara menggunakan NEG mandiri dengan load balancer HTTP eksternal di GKE.

Anda harus membuat objek berikut:

• Deployment{track-name="k8sLink" track-type="concept"} yang membuat dan mengelola Pod.
• Service yang membuat NEG.
• Load balancer yang dibuat dengan Compute Engine API. Cara ini berbeda dari penggunaan NEG dengan Ingress. Dalam hal ini, Ingress akan membuat dan mengonfigurasi load balancer untuk Anda. Dengan NEG mandiri, Anda bertanggung jawab untuk mengaitkan NEG dan layanan backend guna menghubungkan Pod ke load balancer. Load balancer terdiri dari beberapa komponen yang ditampilkan dalam diagram berikut:

Membuat cluster VPC native

Cluster Autopilot berbasis VPC secara default, sehingga Anda dapat langsung menuju ke bagian Men-deploy workload.

Untuk cluster Standard, buat cluster VPC native di zona us-central1-a:

gcloud container clusters create neg-demo-cluster \
    --create-subnetwork="" \
    --network=default \
    --zone=us-central1-a

Membuat Deployment

Contoh manifes berikut menentukan Deployment yang menjalankan tiga instance server HTTP dalam container. Server HTTP merespons permintaan dengan nama host server aplikasi, nama Pod tempat server berjalan.

Sebaiknya gunakan workload yang menggunakan masukan kesiapan Pod.

Menggunakan masukan kesiapan Pod

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Menggunakan penundaan hardcode

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: neg-demo-app # Label for the Deployment
  name: neg-demo-app # Name of Deployment
spec:
  minReadySeconds: 60 # Number of seconds to wait after a Pod is created and its status is Ready
  replicas: 3
  selector:
    matchLabels:
      run: neg-demo-app
  template: # Pod template
    metadata:
      labels:
        run: neg-demo-app # Labels Pods from this Deployment
    spec: # Pod specification; each Pod created by this Deployment has this specification
      containers:
      - image: registry.k8s.io/serve_hostname:v1.4 # Application to run in Deployment's Pods
        name: hostname
  

Simpan manifes ini sebagai neg-demo-app.yaml, lalu buat Deployment dengan menjalankan perintah berikut:

kubectl apply -f neg-demo-app.yaml

Membuat Service

Manifes berikut menentukan Service jika:

• Setiap Pod dengan label run: neg-demo-app adalah anggota Service ini.
• Service memiliki satu kolom ServicePort dengan port 80.
• Anotasi cloud.google.com/neg menentukan bahwa port 80 akan dikaitkan dengan NEG. Kolom name opsional menentukan bahwa NEG akan diberi nama NEG_NAME. Jika kolom name dihilangkan, nama unik akan dibuat secara otomatis. Lihat penamaan NEG untuk mengetahui detailnya.
• Setiap Pod anggota harus memiliki container yang memproses port TCP 9376.

apiVersion: v1
kind: Service
metadata:
  name: neg-demo-svc
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'
spec:
  type: ClusterIP
  selector:
    run: neg-demo-app # Selects Pods labelled run: neg-demo-app
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376

Ganti NEG_NAME dengan nama untuk NEG. Nama NEG harus unik di region-nya.

Simpan manifes ini sebagai neg-demo-svc.yaml, lalu buat Service dengan menjalankan perintah berikut:

kubectl apply -f neg-demo-svc.yaml

NEG dibuat dalam beberapa menit setelah pembuatan Service.

Jenis Service

Meskipun contoh ini menggunakan layanan ClusterIP, kelima jenis Service mendukung NEG mandiri. Sebaiknya gunakan jenis default, ClusterIP.

Penamaan NEG

Pada GKE versi 1.18.18-gke.1200 dan yang lebih baru, Anda dapat menentukan nama kustom untuk NEG, atau GKE dapat membuat nama secara otomatis. GKE versi sebelumnya hanya mendukung nama NEG yang dibuat secara otomatis.

GKE membuat satu NEG di setiap zona yang digunakan oleh cluster. Semua NEG menggunakan nama yang sama.

Menentukan nama

Menentukan nama NEG kustom akan menyederhanakan proses mengonfigurasi load balancer karena Anda telah mengetahui nama dan zona NEG. Nama NEG kustom harus memenuhi persyaratan berikut:

• Unik sesuai zona cluster untuk cluster zona, atau unik sesuai region untuk cluster regional.

• Tidak boleh sama dengan nama NEG yang sudah ada dan tidak dibuat oleh pengontrol NEG GKE.
• Tidak boleh mengandung garis bawah.

Catatan: Jika ada konflik nama, pembuatan atau sinkronisasi NEG akan gagal. Untuk langkah pemecahan masalah, lihat NEG tidak disinkronkan dengan Service.

Gunakan kolom name dalam anotasi cloud.google.com/neg Service untuk menentukan nama NEG:

cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG_NAME"}}}'

Ganti NEG_NAME dengan nama untuk NEG. Nama NEG harus unik di region-nya.

Menggunakan nama yang dibuat secara otomatis

Nama NEG yang dibuat secara otomatis dijamin unik. Untuk menggunakan nama yang dibuat secara otomatis, hapus kolom name:

cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'

Nama yang dibuat secara otomatis memiliki format berikut:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Memetakan port ke beberapa NEG

Satu Service dapat memproses lebih dari satu port. Menurut definisi, NEG hanya memiliki satu alamat IP dan port. Artinya, jika Anda menentukan Service dengan beberapa port, NEG akan dibuat untuk setiap port.

Format anotasi cloud.google.com/neg adalah:

cloud.google.com/neg: '{
   "exposed_ports":{
      "SERVICE_PORT_1":{},
      "SERVICE_PORT_2":{},
      "SERVICE_PORT_3":{},
      ...
   }
 }'

Dalam contoh ini, setiap instance SERVICE_PORT_N adalah nomor port berbeda yang mengacu pada port layanan yang sudah ada pada Service. Untuk setiap port layanan yang tercantum, pengontrol NEG akan membuat satu NEG di setiap zona yang ditempati cluster.

Mengambil status NEG

Gunakan perintah berikut untuk mengambil status Service cluster:

kubectl get service neg-demo-svc -o yaml

Outputnya mirip dengan hal berikut ini:

cloud.google.com/neg-status: '{
   "network-endpoint-groups":{
      "SERVICE_PORT_1": "NEG_NAME_1",
      "SERVICE_PORT_2": "NEG_NAME_2",
      ...
   },
   "zones":["ZONE_1", "ZONE_2", ...]
}

Dalam output ini, setiap elemen dalam pemetaan network-endpoint-groups adalah port layanan (seperti SERVICE_PORT_1) dan nama NEG terkelola terkait (seperti NEG_NAME_1). Daftar zones berisi setiap zona (seperti ZONE_1) yang memiliki NEG di dalamnya.

Outputnya mirip dengan hal berikut ini:

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"80":"k8s1-cca197ad-default-neg-demo-app-80-4db81e02"},"zones":["ZONE_1", "ZONE_2"]}'
  labels:
    run: neg-demo-app
  name: neg-demo-app
  namespace: default
  selfLink: /api/v1/namespaces/default/services/neg-demo-app
  ...
spec:
  clusterIP: 10.0.14.252
  ports:
  - port: 80
    protocol: TCP
    targetPort: 9376
  selector:
    run: neg-demo-app
  sessionAffinity: None
status:
  loadBalancer: {}

Dalam contoh ini, anotasi menunjukkan bahwa port layanan 80 diekspos ke NEG bernama k8s1-cca197ad-default-neg-demo-app-80-4db81e02.

Memvalidasi pembuatan NEG

NEG dibuat dalam beberapa menit setelah pembuatan Service. Jika ada Pod yang cocok dengan label yang ditentukan dalam manifes Service, NEG akan berisi IP Pod.

Ada dua cara untuk memverifikasi bahwa NEG dibuat dan dikonfigurasi dengan benar. Di GKE 1.18.6-gke.6400 dan yang lebih baru, resource kustom ServiceNetworkEndpointGroup menyimpan informasi status tentang NEG yang dibuat oleh pengontrol Service. Pada versi sebelumnya, Anda harus memeriksa NEG secara langsung.

Resource ServiceNetworkEndpointGroup

Cantumkan NEG dalam cluster dengan mendapatkan semua resource ServiceNetworkEndpointGroup:

kubectl get svcneg

Amati status NEG dengan memeriksa status resource ServiceNetworkEndpointGroup:

kubectl get svcneg NEG_NAME -o yaml

Ganti NEG_NAME dengan nama individu NEG yang ingin Anda periksa.

Output perintah ini mencakup bagian status yang mungkin berisi pesan error. Beberapa error dilaporkan sebagai peristiwa Service. Anda dapat menemukan detail lebih lanjut dengan membuat kueri objek Service:

kubectl describe service SERVICE_NAME

Ganti SERVICE_NAME dengan nama Service yang relevan.

Untuk memverifikasi bahwa pengontrol NEG berhasil menyinkronkan NEG, periksa kolom status resource ServiceNetworkEndpointGroup untuk menemukan kondisi dengan type:Synced. Waktu sinkronisasi terbaru berada di kolom status.lastSyncTime.

Resource ServiceNetworkEndpointGroup hanya ada di GKE versi 1.18 dan yang lebih baru.

Memeriksa NEG secara langsung

Pastikan bahwa NEG ada dengan mencantumkan NEG di project Google Cloud Anda dan memeriksa NEG yang cocok dengan Service yang Anda buat. Nama NEG memiliki format berikut:

k8s1-CLUSTER_UID-NAMESPACE-SERVICE-PORT-RANDOM_HASH

Gunakan perintah berikut untuk mencantumkan NEG:

gcloud compute network-endpoint-groups list

Outputnya mirip dengan hal berikut ini:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Output ini menunjukkan bahwa SIZE NEG adalah 3, yang berarti memiliki tiga endpoint yang sesuai dengan tiga Pod dalam Deployment.

Identifikasi setiap endpoint dengan perintah berikut:

gcloud compute network-endpoint-groups list-network-endpoints NEG_NAME

Ganti NEG_NAME dengan nama NEG yang ingin Anda tampilkan masing-masing endpoint.

Output menunjukkan tiga endpoint, yang masing-masing memiliki alamat IP dan port Pod:

INSTANCE                                           IP_ADDRESS  PORT
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.43  9376
gke-cluster-3-default-pool-4cc71a15-qlpf  10.12.1.44  9376
gke-cluster-3-default-pool-4cc71a15-w9nk  10.12.2.26  9376

Memasang Load Balancer Aplikasi eksternal ke NEG mandiri

Anda dapat menggunakan NEG sebagai backend untuk Load Balancer Aplikasi eksternal menggunakan Compute Engine API.

1. Membuat aturan firewall. Load balancer perlu mengakses endpoint cluster untuk melakukan health check. Perintah ini membuat aturan firewall untuk mengizinkan akses:

   gcloud compute firewall-rules create fw-allow-health-check-and-proxy \
      --network=NETWORK_NAME \
      --action=allow \
      --direction=ingress \
      --target-tags=GKE_NODE_NETWORK_TAGS \
      --source-ranges=130.211.0.0/22,35.191.0.0/16 \
      --rules=tcp:9376
   

   Ganti kode berikut:

   • NETWORK_NAME: jaringan tempat cluster berjalan.
   • GKE_NODE_NETWORK_TAGS: tag jaringan pada node GKE.

   Jika Anda tidak membuat tag jaringan kustom untuk node, GKE akan otomatis membuat tag untuk Anda. Anda dapat mencari tag yang dihasilkan ini dengan menjalankan perintah berikut:

   gcloud compute instances describe INSTANCE_NAME
   

   Ganti INSTANCE_NAME dengan nama instance VM Compute Engine host yang menjalankan node GKE. Misalnya, output di bagian sebelumnya menampilkan nama instance di kolom INSTANCE untuk node GKE. Untuk cluster Standard, Anda juga dapat menjalankan gcloud compute instances list untuk mencantumkan semua instance dalam project Anda.

2. Buat alamat IP virtual global untuk load balancer:

   gcloud compute addresses create hostname-server-vip \
       --ip-version=IPV4 \
       --global
   

3. Membuat health check. Atribut ini digunakan oleh load balancer untuk mendeteksi keaktifan setiap endpoint dalam NEG.

   gcloud compute health-checks create http http-basic-check \
       --use-serving-port
   

4. Buat layanan backend yang menentukan bahwa ini adalah Load Balancer Aplikasi eksternal global:

   gcloud compute backend-services create my-bes \
       --protocol HTTP \
       --health-checks http-basic-check \
       --global
   

5. Buat peta URL dan proxy target untuk load balancer. Contoh ini sangat mudah karena aplikasi serve_hostname yang digunakan untuk panduan ini memiliki satu endpoint dan tidak menampilkan URL.

   gcloud compute url-maps create web-map \
       --default-service my-bes
   

   gcloud compute target-http-proxies create http-lb-proxy \
       --url-map web-map
   

6. Membuat aturan penerusan. Inilah yang membuat load balancer.

   gcloud compute forwarding-rules create http-forwarding-rule \
       --address=HOSTNAME_SERVER_VIP \
       --global \
       --target-http-proxy=http-lb-proxy \
       --ports=80
   

   Ganti HOSTNAME_SERVER_VIP dengan alamat IP yang akan digunakan untuk load balancer. Jika Anda menghilangkan --address, GKE akan otomatis menetapkan alamat IP efemeral. Anda juga dapat mencadangkan alamat IP eksternal statis baru.

Checkpoint

Berikut adalah resource yang telah Anda buat sejauh ini:

• Alamat IP virtual eksternal
• Aturan penerusan
• Aturan firewall
• Proxy HTTP target
• Peta URL health check Compute Engine
• Layanan backend
• Health check Compute Engine

Hubungan antara resource ini ditampilkan dalam diagram berikut:

Semua resource ini adalah load balancer. Pada langkah berikutnya, Anda akan menambahkan backend ke load balancer.

Salah satu manfaat NEG mandiri yang ditunjukkan di sini adalah bahwa siklus proses load balancer dan backend dapat sepenuhnya independen. Load balancer dapat terus berjalan setelah aplikasi, layanannya, atau cluster GKE dihapus. Anda dapat menambahkan dan menghapus NEG baru atau beberapa NEG dari load balancer tanpa mengubah objek load balancer frontend apa pun.

Menambahkan backend ke load balancer

Gunakan gcloud compute backend-services add-backend untuk menghubungkan NEG ke load balancer dengan menambahkannya sebagai backend layanan backend my-bes:

gcloud compute backend-services add-backend my-bes \
    --global \
    --network-endpoint-group=NEG_NAME \
    --network-endpoint-group-zone=NEG_ZONE \
    --balancing-mode RATE --max-rate-per-endpoint 5

Ganti kode berikut:

• NEG_NAME: nama grup endpoint jaringan Anda. Nama dapat berupa nama yang Anda tentukan saat membuat NEG atau nama yang dibuat secara otomatis. Jika Anda tidak menentukan nama untuk NEG, lihat petunjuk berikut guna menemukan nama yang dibuat secara otomatis.
• NEG_ZONE: zona tempat grup endpoint jaringan Anda berada. Lihat petunjuk berikut untuk menemukan nilai ini.

Gunakan perintah ini untuk mendapatkan nama dan lokasi NEG:

gcloud compute network-endpoint-groups list

Outputnya mirip dengan hal berikut ini:

NAME                                          LOCATION       ENDPOINT_TYPE   SIZE
k8s1-70aa83a6-default-my-service-80-c9710a6f  ZONE_NAME      GCE_VM_IP_PORT  3

Dalam contoh output ini, nama NEG adalah k8s1-70aa83a6-default-my-service-80-c9710a6f.

Beberapa NEG dapat ditambahkan ke layanan backend yang sama. Layanan backend global seperti my-bes dapat memiliki backend NEG di berbagai region, sedangkan layanan backend regional harus memiliki backend di satu region.

Memastikan bahwa load balancer berfungsi

Catatan: Mungkin perlu waktu beberapa menit bagi load balancer untuk menyediakan dan menstabilkan.

Ada dua cara untuk memvalidasi bahwa load balancer yang Anda siapkan berfungsi:

• Pastikan health check dikonfigurasi dengan benar dan pelaporan responsif.
• Akses aplikasi dan verifikasi responsnya.

Memverifikasi health check

Periksa apakah layanan backend dikaitkan dengan health check dan grup endpoint jaringan, serta setiap endpoint tersebut responsif.

Gunakan perintah ini untuk memeriksa bahwa layanan backend dikaitkan dengan health check dan grup endpoint jaringan Anda:

gcloud compute backend-services describe my-bes --global

Outputnya mirip dengan hal berikut ini:

backends:
- balancingMode: RATE
  capacityScaler: 1.0
  group: ... /networkEndpointGroups/k8s1-70aa83a6-default-my-service-80-c9710a6f
...
healthChecks:
- ... /healthChecks/http-basic-check
...
name: my-bes
...

Selanjutnya, periksa kondisi setiap endpoint:

gcloud compute backend-services get-health my-bes --global

Bagian status: output mirip dengan berikut ini:

status:
  healthStatus:
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.43
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-qlpf
    ipAddress: 10.12.1.44
    port: 50000
  - healthState: HEALTHY
    instance: ... gke-cluster-3-default-pool-4cc71a15-w9nk
    ipAddress: 10.12.2.26
    port: 50000

Mengakses aplikasi

Akses aplikasi melalui alamat IP load balancer untuk mengonfirmasi bahwa semuanya berfungsi.

Catatan: Perlu waktu beberapa menit hingga load balancer diprogram sepenuhnya.

Pertama, dapatkan alamat IP virtual load balancer:

gcloud compute addresses describe hostname-server-vip --global | grep "address:"

Output-nya akan menyertakan alamat IP. Selanjutnya, kirim permintaan ke alamat IP tersebut (dalam contoh ini 34.98.102.37):

curl 34.98.102.37

Respons dari aplikasi serve_hostname harus neg-demo-app.

Memasang Load Balancer Aplikasi internal ke NEG mandiri

Anda dapat menggunakan NEG untuk mengonfigurasi Load Balancer Aplikasi internal untuk layanan yang berjalan di Pod GKE mandiri.

Mengonfigurasi subnet khusus proxy

Subnet khusus proxy digunakan untuk semua Load Balancer Aplikasi internal regional di region load balancer.

Penting: Jangan mencoba menetapkan alamat dari subnet khusus proxy ke aturan penerusan atau backend load balancer Anda. Anda menetapkan alamat IP aturan penerusan dan alamat IP instance backend dari satu rentang (atau beberapa rentang) subnet yang berbeda dari subnet khusus proxy. Google Cloud mereservasi rentang subnet untuk proxy yang dikelola Google Cloud.

Konsol

Jika menggunakan konsol Google Cloud, Anda dapat menunggu dan membuat subnet khusus proxy nanti.

gcloud

Buat subnet khusus proxy dengan perintah gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
    --purpose=REGIONAL_MANAGED_PROXY \
    --role=ACTIVE \
    --region=COMPUTE_REGION \
    --network=lb-network \
    --range=10.129.0.0/23

Ganti COMPUTE_REGION dengan Compute Engine untuk subnet.

API

Buat subnet khusus proxy dengan metode subnetworks.insert.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "region": "projects/PROJECT_ID/regions/COMPUTE_REGION",
  "purpose": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Ganti kode berikut:

• PROJECT_ID: project ID Anda.
• COMPUTE_REGION: Compute Engine untuk subnet.

Mengonfigurasi aturan firewall

Contoh ini menggunakan aturan firewall berikut:

• fw-allow-ssh: Aturan ingress, yang berlaku untuk instance yang di-load balanced, yang memungkinkan konektivitas SSH yang masuk pada TCP port 22 dari alamat mana pun. Anda dapat memilih rentang IP sumber yang lebih ketat untuk aturan ini. Misalnya, Anda dapat menentukan hanya rentang IP sistem tempat Anda memulai sesi SSH. Contoh ini menggunakan tag target allow-ssh untuk mengidentifikasi VM yang menerapkan aturan firewall.

• fw-allow-health-check: Aturan ingress, yang berlaku untuk instance yang di-load balance, yang mengizinkan semua traffic TCP dari sistem health check Google Cloud (dalam 130.211.0.0/22 dan 35.191.0.0/16). Contoh ini menggunakan tag target load-balanced-backend untuk mengidentifikasi instance yang harus diterapkan dengan tag tersebut.

• fw-allow-proxies: Aturan ingress, yang berlaku untuk instance yang di-load balance, yang mengizinkan traffic TCP pada port 9376 dari proxy terkelola load balancer HTTP(S) internal. Contoh ini menggunakan tag target load-balanced-backend untuk mengidentifikasi instance tempat tag harus diterapkan.

Tanpa aturan firewall ini, aturan tolak ingress default akan memblokir traffic masuk ke instance backend.

Konsol

1. Buka halaman Firewall policies di Konsol Google Cloud.

   Buka Firewall policies

2. Klik Create firewall rule untuk membuat aturan yang mengizinkan koneksi SSH yang masuk:

   • Nama: fw-allow-ssh
   • Jaringan: lb-network
   • Direction of traffic: masuk
   • Tindakan terhadap kecocokan: izinkan
   • Targets: Tag target yang ditentukan
   • Tag target: allow-ssh
   • Filter sumber: IPv4 ranges
   • Rentang IPv4 sumber: 0.0.0.0/0
   • Protokol dan port:
     • Pilih Protokol dan port yang ditentukan.
     • Pilih kotak centang tcp dan tentukan port 22.

3. Klik Create.

4. Klik Create firewall rule lagi untuk membuat aturan yang mengizinkan health check Google Cloud:

   • Nama: fw-allow-health-check
   • Jaringan: lb-network
   • Direction of traffic: masuk
   • Tindakan terhadap kecocokan: izinkan
   • Targets: Tag target yang ditentukan
   • Tag target: load-balanced-backend
   • Filter sumber: IPv4 ranges
   • Rentang IPv4 sumber: 130.211.0.0/22 dan 35.191.0.0/16
   • Protokol dan port:
     • Pilih Protokol dan port yang ditentukan
     • Pilih kotak centang tcp dan tentukan port 80. Sebagai praktik terbaik, batasi aturan ini hanya pada protokol dan port yang cocok dengan yang digunakan oleh health check Anda. Jika Anda menggunakan tcp:80 untuk protokol dan port, Google Cloud dapat menghubungi VM menggunakan HTTP pada port 80, tetapi tidak dapat menghubungi VM menggunakan HTTPS di port 443.

5. Klik Create.

6. Klik Create firewall rule lagi untuk membuat aturan yang mengizinkan server proxy load balancer menghubungkan backend:

   • Nama: fw-allow-proxies
   • Jaringan: lb-network
   • Direction of traffic: masuk
   • Tindakan terhadap kecocokan: izinkan
   • Targets: Tag target yang ditentukan
   • Tag target: load-balanced-backend
   • Filter sumber: IPv4 ranges
   • Rentang IPv4 sumber: 10.129.0.0/23
   • Protokol dan port:
     • Pilih Protokol dan port yang ditentukan.
     • Pilih kotak centang tcp dan tentukan port 9376.

7. Klik Create.

gcloud

1. Buat aturan firewall fw-allow-ssh untuk mengizinkan konektivitas SSH ke VM dengan tag jaringan allow-ssh. Saat Anda menghapus source-ranges, Google Cloud akan menafsirkan aturan sebagai sumber apa pun.

   gcloud compute firewall-rules create fw-allow-ssh \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --target-tags=allow-ssh \
       --rules=tcp:22
   

2. Buat aturan fw-allow-health-check untuk mengizinkan health check Google Cloud. Contoh ini mengizinkan semua traffic TCP dari penguji health check; namun, Anda juga dapat mengonfigurasi kumpulan port yang lebih sempit untuk memenuhi kebutuhan Anda.

   gcloud compute firewall-rules create fw-allow-health-check \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --target-tags=load-balanced-backend \
       --rules=tcp
   

3. Buat aturan fw-allow-proxies untuk mengizinkan proxy load balancer HTTP(S) internal terhubung ke backend Anda.

   gcloud compute firewall-rules create fw-allow-proxies \
       --network=lb-network \
       --action=allow \
       --direction=ingress \
       --source-ranges=10.129.0.0/23 \
       --target-tags=load-balanced-backend \
       --rules=tcp:9376
   

API

Buat aturan firewall fw-allow-ssh dengan membuat permintaan POST ke metode firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Ganti PROJECT_ID dengan project ID Anda.

Buat aturan firewall fw-allow-health-check dengan membuat permintaan POST ke metode firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Buat aturan firewall fw-allow-proxies untuk mengizinkan traffic TCP dalam subnet proxy dan metode firewalls.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "9376"
      ]
    }
  ],
  "direction": "INGRESS"
}

Ganti PROJECT_ID dengan project ID Anda.

Mengonfigurasi load balancer

Untuk alamat IP aturan penerusan, gunakan subnet backend. Jika Anda mencoba menggunakan subnet khusus proxy, pembuatan aturan penerusan akan gagal.

Konsol

Pilih jenis load balancer

1. Buka halaman Create a load balancer di Konsol Google Cloud. Buka Create a load balancer
2. Pada HTTP(S) Load Balancing, klik Start configuration.
3. Pilih Only between my VMs. Pengaturan ini berarti load balancer bersifat internal.
4. Klik Continue.

Menyiapkan load balancer

1. Untuk Name load balancer, masukkan l7-ilb-gke-map.
2. Untuk Region, pilih region tempat Anda membuat subnet.
3. Untuk Network, pilih lb-network.

Mereservasi subnet khusus proxy

Catatan: Jika Anda sudah mereservasi subnet khusus proxy, seperti yang diperintahkan, tombol Reserve a Subnet tidak ditampilkan, jadi lewatkan bagian ini dan lanjutkan dengan langkah-langkah di Mengonfigurasi layanan backend.

Mereservasi subnet khusus proxy:

1. Klik Reserve a Subnet.
2. Untuk Name, masukkan proxy-only-subnet.
3. Untuk IP address range, masukkan 10.129.0.0/23.
4. Klik Add.

Mengonfigurasi layanan backend

1. Klik Backend configuration.
2. Dari menu Create or select backend services, pilih Create a backend service.
3. Setel Name layanan backend ke l7-ilb-gke-backend-service.
4. Untuk Backend type, pilih Network endpoint groups.
5. Di kartu New backend pada bagian Backends:
   1. Tetapkan Network endpoint group ke NEG yang dibuat oleh GKE. Untuk mendapatkan nama NEG, lihat Memvalidasi pembuatan NEG.
   2. Untuk Maximum RPS, tentukan laju maksimum 5 RPS per endpoint. Google Cloud akan melampaui batas maksimum ini jika diperlukan.
   3. Klik Done.
6. Dari menu drop-down Health check, pilih Create a health check, lalu tentukan parameter berikut:
   1. Nama: l7-ilb-gke-basic-check
   2. Protokol: HTTP
   3. Spesifikasi port: Port aktif
   4. Klik Save and Continue.
7. Klik Create.

Mengonfigurasi peta URL

1. Klik Routing rules. Pastikan l7-ilb-gke-backend-service adalah satu-satunya layanan backend untuk semua host dan jalur yang tidak cocok.

Mengonfigurasi frontend

Klik Frontend configuration dan lakukan langkah-langkah berikut:

Untuk HTTP:

1. Klik Frontend configuration.
2. Klik Add frontend IP and port.
3. Tetapkan Name ke l7-ilb-gke-forwarding-rule.
4. Tetapkan Protocol ke HTTP.
5. Tetapkan Subnetwork ke backend-subnet.
6. Di bagian Internal IP, pilih Reserve a static internal IP address.
7. Di panel yang muncul, berikan detail berikut:
   1. Name: l7-ilb-gke-ip
   2. Di bagian Static IP address, pilih Let me choose.
   3. Di bagian Custom IP address, masukkan 10.1.2.199.
   4. Klik Reserve.
8. Tetapkan Port ke 80.
9. Klik Done.

Untuk HTTPS:

Jika menggunakan HTTPS antara klien dan load balancer, Anda memerlukan satu atau beberapa resource sertifikat SSL untuk mengonfigurasi proxy. Lihat Sertifikat SSL untuk informasi tentang cara membuat resource sertifikat SSL. Sertifikat yang dikelola Google tidak didukung dengan load balancer HTTP(S) internal.

1. Klik Frontend configuration.
2. Klik Add frontend IP and port.
3. Di kolom Name, masukkan l7-ilb-gke-forwarding-rule.
4. Pada kolom Protocol, pilih HTTPS (includes HTTP/2).
5. Tetapkan Subnet ke backend-subnet.
6. Di bagian Internal IP, pilih Reserve a static internal IP address.
7. Di panel yang muncul, berikan detail berikut:
   1. Name: l7-ilb-gke-ip
   2. Di bagian Static IP address, pilih Let me choose.
   3. Di bagian Custom IP address, masukkan 10.1.2.199.
   4. Klik Reserve.
8. Pastikan Port ditetapkan ke 443 untuk mengizinkan traffic HTTPS.
9. Klik menu drop-down Certificate.
   1. Jika Anda sudah memiliki resource sertifikat SSL yang dikelola sendiri yang ingin digunakan sebagai sertifikat SSL utama, pilih sertifikat tersebut dari menu drop-down.
   2. Jika tidak, pilih Create a new certificate.
      1. Isi Name l7-ilb-cert.
      2. Di kolom yang sesuai, upload file berformat PEM:
         • Sertifikat kunci publik
         • Rantai sertifikat
         • Kunci pribadi
      3. Klik Create.
10. Untuk menambahkan resource sertifikat selain resource sertifikat SSL utama:
    1. Klik Add certificate.
    2. Pilih sertifikat dari daftar Certificates atau klik Create a new certificate, lalu ikuti petunjuknya.
11. Klik Done.

Menyelesaikan konfigurasi

Klik Create.

gcloud

1. Tentukan health check HTTP dengan perintah gcloud compute health-checks create http.

   gcloud compute health-checks create http l7-ilb-gke-basic-check \
       --region=COMPUTE_REGION \
       --use-serving-port
   

2. Tentukan layanan backend dengan perintah gcloud compute backend-services create.

   gcloud compute backend-services create l7-ilb-gke-backend-service \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --protocol=HTTP \
       --health-checks=l7-ilb-gke-basic-check \
       --health-checks-region=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

3. Tetapkan variabel DEPLOYMENT_NAME:

   export DEPLOYMENT_NAME=NEG_NAME
   

   Ganti NEG_NAME dengan nama NEG.

4. Tambahkan backend NEG ke layanan backend dengan perintah gcloud compute backend-services add-backend.

   gcloud compute backend-services add-backend l7-ilb-gke-backend-service \
       --network-endpoint-group=$DEPLOYMENT_NAME \
       --network-endpoint-group-zone=COMPUTE_ZONE-b \
       --region=COMPUTE_REGION \
       --balancing-mode=RATE \
       --max-rate-per-endpoint=5
   

5. Buat peta URL dengan perintah gcloud compute url-maps create.

   gcloud compute url-maps create l7-ilb-gke-map \
       --default-service=l7-ilb-gke-backend-service \
       --region=COMPUTE_REGION
   

6. Buat proxy target.

   Untuk HTTP:

   Gunakan perintah gcloud compute target-http-proxies create.

   gcloud compute target-http-proxies create l7-ilb-gke-proxy \
       --url-map=l7-ilb-gke-map \
       --url-map-region=COMPUTE_REGION \
       --region=COMPUTE_REGION
   

   Untuk HTTPS:

   Lihat Sertifikat SSL untuk informasi tentang cara membuat resource sertifikat SSL. Sertifikat yang dikelola Google tidak didukung dengan load balancer HTTP(S) internal.

   Menetapkan jalur file ke nama variabel.

   export LB_CERT=PATH_TO_PEM_FORMATTED_FILE
   

   export LB_PRIVATE_KEY=PATH_TO_PEM_FORMATTED_FILE
   

   Buat sertifikat SSL regional menggunakan perintah gcloud compute ssl-certificates create.

   gcloud compute ssl-certificates create

   gcloud compute ssl-certificates create l7-ilb-cert \
       --certificate=$LB_CERT \
       --private-key=$LB_PRIVATE_KEY \
       --region=COMPUTE_REGION
   

   Gunakan sertifikat SSL regional untuk membuat proxy target dengan perintah gcloud compute target-https-proxies create.

   gcloud compute target-https-proxies create l7-ilb-gke-proxy \
       --url-map=l7-ilb-gke-map \
       --region=COMPUTE_REGION \
       --ssl-certificates=l7-ilb-cert
   

7. Membuat aturan penerusan.

   Untuk jaringan kustom, Anda harus mereferensikan subnet dalam aturan penerusan. Perhatikan bahwa ini adalah subnet VM, bukan subnet proxy.

   Untuk HTTP:

   Gunakan perintah gcloud compute forwarding-rules create dengan flag yang benar.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=10.1.2.199 \
       --ports=80 \
       --region=COMPUTE_REGION \
       --target-http-proxy=l7-ilb-gke-proxy \
       --target-http-proxy-region=COMPUTE_REGION
   

   Untuk HTTPS:

   Gunakan perintah gcloud compute forwarding-rules create dengan flag yang benar.

   gcloud compute forwarding-rules create l7-ilb-gke-forwarding-rule \
       --load-balancing-scheme=INTERNAL_MANAGED \
       --network=lb-network \
       --subnet=backend-subnet \
       --address=10.1.2.199 \
       --ports=443 \
       --region=COMPUTE_REGION \
       --target-https-proxy=l7-ilb-gke-proxy \
       --target-https-proxy-region=COMPUTE_REGION
   

API

Buat health check dengan membuat permintaan POST ke metode regionHealthChecks.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks

{
   "name": "l7-ilb-gke-basic-check",
   "type": "HTTP",
   "httpHealthCheck": {
     "portSpecification": "USE_SERVING_PORT"
   }
}

Ganti PROJECT_ID dengan project ID.

Buat layanan backend regional dengan membuat permintaan POST ke metode regionBackendServices.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices

{
  "name": "l7-ilb-gke-backend-service",
  "backends": [
    {
      "group": "https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/COMPUTE_ZONE/networkEndpointGroups/NEG_NAME",
      "balancingMode": "RATE",
      "maxRatePerEndpoint": 5
    }
  ],
  "healthChecks": [
    "projects/PROJECT_ID/regions/COMPUTE_REGION/healthChecks/l7-ilb-gke-basic-check"
  ],
  "loadBalancingScheme": "INTERNAL_MANAGED"
}

Ganti kode berikut:

• PROJECT_ID: project ID.
• NEG_NAME: nama NEG.

Buat peta URL dengan membuat permintaan POST ke metode regionUrlMaps.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/urlMaps

{
  "name": "l7-ilb-gke-map",
  "defaultService": "projects/PROJECT_ID/regions/COMPUTE_REGION/backendServices/l7-ilb-gke-backend-service"
}

Ganti PROJECT_ID dengan project ID.

Buat proxy HTTP target dengan membuat permintaan POST ke metode regionTargetHttpProxies.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxy

{
  "name": "l7-ilb-gke-proxy",
  "urlMap": "projects/PROJECT_ID/global/urlMaps/l7-ilb-gke-map",
  "region": "COMPUTE_REGION"
}

Ganti PROJECT_ID dengan project ID.

Buat aturan penerusan dengan membuat permintaan POST ke metode forwardingRules.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/COMPUTE_REGION/forwardingRules

{
  "name": "l7-ilb-gke-forwarding-rule",
  "IPAddress": "10.1.2.199",
  "IPProtocol": "TCP",
  "portRange": "80-80",
  "target": "projects/PROJECT_ID/regions/COMPUTE_REGION/targetHttpProxies/l7-ilb-gke-proxy",
  "loadBalancingScheme": "INTERNAL_MANAGED",
  "subnetwork": "projects/PROJECT_ID/regions/COMPUTE_REGION/subnetworks/backend-subnet",
  "network": "projects/PROJECT_ID/global/networks/lb-network",
  "networkTier": "PREMIUM",
}

Ganti PROJECT_ID dengan project ID.

Pengujian

Buat instance VM di zona untuk menguji konektivitas:

gcloud compute instances create l7-ilb-client \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --zone=COMPUTE_ZONE \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=l7-ilb-client,allow-ssh

Login ke instance klien untuk memeriksa apakah layanan HTTP(S) di backend dapat dijangkau menggunakan alamat IP aturan penerusan Load Balancer Aplikasi internal, dan traffic di-load balance di antara endpoint di NEG.

Hubungkan ke setiap instance klien menggunakan SSH:

gcloud compute ssh l7-ilb-client \
    --zone=COMPUTE_ZONE-b

Verifikasi bahwa IP menyalurkan nama host-nya:

curl 10.1.2.199

Untuk pengujian HTTPS, jalankan perintah berikut:

curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443

Flag -k menyebabkan curl melewatkan validasi sertifikat.

Jalankan 100 permintaan dan pastikan semuanya di-load balance.

Untuk HTTP:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl --silent 10.1.2.199)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Untuk HTTPS:

{
RESULTS=
for i in {1..100}
do
    RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.199:443
)"
done
echo "***"
echo "*** Results of load-balancing to 10.1.2.199: "
echo "***"
echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
echo
}

Menerapkan layanan heterogen (VM dan container)

Load balancer dapat berupa frontend ke campuran workload Kubernetes dan non-Kubernetes. Hal ini dapat berupa bagian migrasi dari VM ke container atau arsitektur permanen yang memanfaatkan load balancer bersama. Hal ini dapat dicapai dengan membuat load balancer yang menarget berbagai jenis backend, termasuk NEG mandiri.

VM dan container dalam layanan backend yang sama

Contoh ini menunjukkan cara membuat NEG yang mengarah ke VM yang ada yang dan menjalankan workload, serta cara menambahkan NEG ini sebagai backend lain dari backendService yang ada. Dengan begitu, satu load balancer menyeimbangkan VM dan container GKE.

Contoh ini merupakan pengembangan dari contoh sebelumnya yang menggunakan load balancer HTTP eksternal.

Karena semua endpoint dikelompokkan oleh backendService yang sama, endpoint VM dan penampung dianggap sebagai layanan yang sama. Artinya, pencocokan host atau jalur akan memperlakukan semua backend secara identik berdasarkan aturan peta URL.

Saat Anda menggunakan NEG sebagai backend untuk layanan backend, semua backend lain di layanan backend tersebut juga harus berupa NEG. Anda tidak dapat menggunakan grup instance dan NEG sebagai backend di layanan backend yang sama. Selain itu, container dan VM tidak dapat ada sebagai endpoint dalam NEG yang sama, sehingga harus selalu dikonfigurasi dengan NEG terpisah.

1. Deploy VM ke Compute Engine dengan perintah ini:

   gcloud compute instances create vm1 \
       --zone=COMPUTE_ZONE \
       --network=NETWORK \
       --subnet=SUBNET \
       --image-project=cos-cloud \
       --image-family=cos-stable --tags=vm-neg-tag
   

   Ganti kode berikut:

   • COMPUTE_ZONE: nama zona.
   • NETWORK: nama jaringan.
   • SUBNET: nama subnet yang terkait dengan jaringan.

2. Deploy aplikasi ke VM:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="docker run -d --rm --network=host registry.k8s.io/serve_hostname:v1.4 && sudo iptables -P INPUT ACCEPT"
   

   Perintah ini men-deploy ke VM dengan aplikasi contoh yang sama dengan yang digunakan dalam contoh sebelumnya. Demi kemudahan, aplikasi dijalankan sebagai container Docker, tetapi hal ini tidak penting. Perintah iptables diperlukan untuk mengizinkan akses firewall ke container yang sedang berjalan.

3. Periksa apakah aplikasi berfungsi di port 9376 dan melaporkan bahwa aplikasi dijalankan di vm1:

   gcloud compute ssh vm1 \
       --zone=COMPUTE_ZONE \
       --command="curl -s localhost:9376"
   

   Server akan merespons dengan vm1.

4. Buat NEG untuk digunakan dengan endpoint VM. Container dan VM dapat berupa endpoint NEG, tetapi satu NEG tidak dapat memiliki endpoint VM dan container.

   gcloud compute network-endpoint-groups create vm-neg \
       --subnet=SUBNET \
       --zone=COMPUTE_ZONE
   

5. Lampirkan endpoint VM ke NEG:

   gcloud compute network-endpoint-groups update vm-neg \
       --zone=COMPUTE_ZONE \
       --add-endpoint="instance=vm1,ip=VM_PRIMARY_IP,port=9376"
   

   Ganti VM_PRIMARY_IP dengan alamat IP utama VM.

6. Pastikan NEG memiliki endpoint VM:

   gcloud compute network-endpoint-groups list-network-endpoints vm-neg \
       --zone COMPUTE_ZONE
   

7. Tambahkan NEG ke layanan backend menggunakan perintah yang sama dengan yang Anda gunakan untuk menambahkan backend container:

   gcloud compute backend-services add-backend my-bes
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

8. Buka firewall untuk mengizinkan health check VM:

   gcloud compute firewall-rules create fw-allow-health-check-to-vm1 \
       --network=NETWORK \
       --action=allow \
       --direction=ingress \
       --target-tags=vm-neg-tag \
       --source-ranges=130.211.0.0/22,35.191.0.0/16 \
       --rules=tcp:9376
   

9. Validasikan bahwa load balancer meneruskan traffic ke backend vm1 baru dan backend container yang ada dengan mengirimkan traffic pengujian:

   for i in `seq 1 100`; do curl ${VIP};echo; done
   

   Anda akan melihat respons dari endpoint container (neg-demo-app) dan VM (vm1).

VM dan container untuk berbagai layanan backend

Contoh ini menunjukkan cara membuat NEG yang mengarah ke VM yang ada yang menjalankan workload, dan cara menambahkan NEG ini sebagai backend ke backendService baru. Hal ini berguna untuk kasus ketika container dan VM adalah layanan yang berbeda, tetapi perlu memiliki load balancer L7 yang sama, seperti jika layanan tersebut memiliki alamat IP atau nama domain yang sama.

Contoh ini memperluas contoh sebelumnya yang memiliki backend VM di layanan backend yang sama dengan backend container. Contoh ini menggunakan kembali VM tersebut.

Karena endpoint VM dan container dikelompokkan dalam layanan backend yang terpisah, keduanya dianggap sebagai layanan yang berbeda. Artinya, peta URL akan cocok dengan backend dan mengarahkan traffic ke VM atau container berdasarkan nama host.

Diagram berikut menunjukkan bagaimana satu alamat IP virtual berkaitan dengan dua nama host, yang kemudian berkaitan dengan layanan backend berbasis container dan layanan backend berbasis VM.

Diagram berikut menampilkan arsitektur yang dijelaskan di bagian sebelumnya:

1. Buat layanan backend baru untuk VM:

   gcloud compute backend-services create my-vm-bes \
      --protocol HTTP \
      --health-checks http-basic-check \
      --global
   

2. Tambahkan NEG untuk VM, vm-neg, ke layanan backend:

   gcloud compute backend-services add-backend my-vm-bes \
       --global \
       --network-endpoint-group vm-neg \
       --network-endpoint-group-zone COMPUTE_ZONE \
       --balancing-mode RATE --max-rate-per-endpoint 10
   

3. Tambahkan aturan host ke peta URL ke permintaan langsung untuk host container.example.com ke layanan backend container:

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=container-path --default-service=my-bes \
       --new-hosts=container.example.com --global
   

4. Tambahkan aturan host lain yang dipetakan URL untuk mengarahkan permintaan host vm.example.com ke layanan backend VM:

   gcloud compute url-maps add-path-matcher web-map \
       --path-matcher-name=vm-path --default-service=my-vm-bes \
       --new-hosts=vm.example.com --global
   

   Catatan: Perlu waktu beberapa menit agar load balancer diprogram sepenuhnya.

5. Validasikan bahwa load balancer mengirimkan traffic ke backend VM berdasarkan jalur yang diminta:

   curl -H "HOST:vm.example.com" VIRTUAL_IP
   

   Ganti VIRTUAL_IP dengan alamat IP virtual.

Batasan NEG mandiri

• Error validasi anotasi ditampilkan kepada pengguna melalui peristiwa Kubernetes.
• Batasan NEG juga berlaku untuk NEG mandiri.

• NEG mandiri tidak berfungsi dengan jaringan lama.

• NEG mandiri hanya dapat digunakan dengan layanan jaringan yang kompatibel, termasuk Cloud Service Mesh dan jenis load balancer yang kompatibel.

Harga

Lihat bagian load balancing di halaman harga untuk mengetahui detail harga load balancer. Tidak ada biaya tambahan untuk NEG.

Pemecahan masalah

Bagian ini berisi langkah-langkah pemecahan masalah untuk masalah umum yang mungkin Anda alami dengan NEG mandiri.

Tidak ada NEG mandiri yang dikonfigurasi

Gejala: Tidak ada NEG yang dibuat.

Potensi Penyelesaian:

• Periksa peristiwa yang terkait dengan Service dan cari pesan error.
• Pastikan anotasi NEG mandiri memiliki format JSON yang baik, dan port yang terekspos cocok dengan Port yang ada di spesifikasi Service.
• Verifikasi anotasi status NEG dan lihat apakah port layanan yang diharapkan memiliki NEG yang sesuai.
• Pastikan NEG telah dibuat di zona yang diharapkan, dengan perintah gcloud compute network-endpoint-groups list.
• Jika menggunakan GKE versi 1.18 atau yang lebih baru, periksa apakah resource svcneg untuk Service ada. Jika ya, periksa kondisi Initialized untuk melihat informasi error.
• Jika Anda menggunakan nama NEG kustom, pastikan setiap nama NEG unik di region-nya.

Traffic tidak mencapai endpoint

Gejala: Error 502 atau koneksi ditolak.

Potensi Penyelesaian:

• Setelah layanan dikonfigurasi, endpoint baru umumnya akan dapat dijangkau setelah melampirkannya ke NEG, asalkan endpoint tersebut merespons health check.
• Jika setelah waktu ini traffic masih tidak dapat menjangkau endpoint yang menyebabkan kode error 502 untuk HTTP(S) atau koneksi ditolak untuk load balancer TCP/SSL, periksa hal berikut:
  • Pastikan aturan firewall mengizinkan traffic TCP masuk ke endpoint Anda dari rentang berikut: 130.211.0.0/22 dan 35.191.0.0/16.
  • Pastikan endpoint Anda responsif menggunakan Google Cloud CLI atau dengan memanggil getHealth API di backendService atau listEndpoints API di NEG dengan parameter showHealth ditetapkan ke SHOW.

Peluncuran terhenti

Gejala: Peluncuran Deployment yang telah diupdate terhenti, dan jumlah replika terbaru tidak sesuai dengan jumlah replika yang dipilih.

Potensi Penyelesaian:

Health check deployment gagal. Image container mungkin buruk atau health check mungkin salah dikonfigurasi. Penggantian peluncuran Pod menunggu hingga Pod yang baru dimulai lulus gate Kesiapan Pod. Ini hanya terjadi jika Pod merespons health check load balancer. Jika Pod tidak merespons, atau jika health check salah dikonfigurasi, kondisi gate readiness tidak dapat dipenuhi dan peluncuran tidak dapat dilanjutkan.

• Jika menggunakan kubectl 1.13 atau yang lebih baru, Anda dapat memeriksa status gate kesiapan Pod dengan perintah berikut:

  kubectl get my-Pod -o wide
  

  Periksa kolom READINESS GATE.

  Kolom ini tidak ada di kubectl 1.12 dan yang lebih rendah. Pod yang ditandai sebagai berada dalam status READY mungkin memiliki gate kesiapan yang gagal. Untuk memastikannya, gunakan perintah berikut:

  kubectl get my-pod -o yaml
  

  Gate kesiapan dan statusnya tercantum di output.

• Verifikasi bahwa image container di spesifikasi Pod Deployment Anda berfungsi dengan benar dan dapat merespons health check.

• Pastikan health check dikonfigurasi dengan benar.

Pembersihan sampah memori NEG gagal

Gejala: NEG yang seharusnya sudah dihapus masih ada.

Potensi Penyelesaian:

• Pembersihan sampah memori NEG akan gagal jika NEG direferensikan oleh layanan backend. Lihat Mencegah kebocoran NEG untuk mengetahui detailnya.
• Jika menggunakan versi 1.18 atau yang lebih baru, Anda dapat memeriksa peristiwa di resource ServiceNetworkEndpointGroup menggunakan prosedur negosiasi layanan.
• Periksa apakah NEG masih diperlukan oleh layanan. Periksa resource svcneg untuk layanan yang sesuai dengan NEG dan periksa apakah ada anotasi Service.

NEG tidak disinkronkan dengan Service

Gejala: Endpoint yang diharapkan (IP Pod) tidak ada di NEG, NEG tidak disinkronkan, atau error Failed to sync NEG_NAME (will not retry): neg name NEG_NAME is already in use, found a custom named neg with an empty description

Potensi Penyelesaian:

Jika Anda menggunakan GKE 1.18 atau yang lebih baru, periksa resource svcneg untuk mengetahui informasinya:

• Periksa nilai status.lastSyncTime untuk memverifikasi apakah NEG telah disinkronkan baru-baru ini.
• Periksa kondisi Synced untuk setiap error yang terjadi dalam sinkronisasi terbaru.

Jika Anda menggunakan GKE 1.19.9 atau yang lebih baru, periksa apakah ada NEG yang nama dan zonanya cocok dengan nama dan zona NEG yang perlu dibuat oleh pengontrol NEG GKE. Misalnya, NEG dengan nama yang perlu digunakan oleh pengontrol NEG mungkin telah dibuat menggunakan gcloud CLI atau Google Cloud Console di zona cluster (atau salah satu zona cluster). Dalam hal ini, Anda harus menghapus NEG yang ada sebelum pengontrol NEG dapat menyinkronkan endpoint-nya. Pembuatan dan keanggotaan NEG mandiri dirancang untuk dikelola oleh pengontrol NEG.

Langkah selanjutnya

• Ringkasan grup endpoint jaringan zona
• Layanan Backend
• Membuat Health Check
• Menggunakan Proxy Target
• Menggunakan Aturan Penerusan