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).
Lihat Load balancing berbasis container untuk informasi tentang manfaat, persyaratan, dan batasan 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 adalah sebuah opsi jika NEG yang dikelola oleh Ingress tidak melayani 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 mengaktifkan 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, NEG yang terkait tidak akan menjadi sampah yang dikumpulkan 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 pasti 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 Traffic Director dengan GKE
Anda dapat menggunakan Traffic Director dengan GKE. Traffic Director 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
initialize
gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan
gcloud components update
.
Menggunakan NEG mandiri
Petunjuk berikut menunjukkan cara menggunakan NEG mandiri dengan load balancer HTTP eksternal di GKE.
Anda harus membuat objek berikut:
- Deployment 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. Kolomname
opsional menentukan bahwa NEG akan diberi namaNEG_NAME
. Jika kolomname
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:
- Bersifat unik bagi region cluster untuk cluster regional.
- Tidak boleh sama dengan nama NEG yang sudah ada dan tidak dibuat oleh pengontrol NEG GKE.
- Tidak boleh mengandung garis bawah.
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 terekspos 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.
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 kolomINSTANCE
untuk node GKE. Untuk cluster Standar, Anda juga dapat menjalankangcloud compute instances list
untuk menampilkan daftar semua instance dalam project Anda.Buat alamat IP virtual global untuk load balancer:
gcloud compute addresses create hostname-server-vip \ --ip-version=IPV4 \ --global
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
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
Buat peta URL dan proxy target untuk load balancer. Contoh ini sangat mudah karena aplikasi
serve_hostname
yang digunakan untuk panduan ini memiliki endpoint tunggal 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
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 menghapus--address
, GKE akan otomatis menetapkan alamat IP sementara.
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
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.
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 ditujukan untuk semua Load Balancer Aplikasi internal regional di region load balancer.
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 targetallow-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 (dalam130.211.0.0/22
dan35.191.0.0/16
). Contoh ini menggunakan tag targetload-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 port9376
dari proxy terkelola load balancer HTTP(S) internal. Contoh ini menggunakan tag targetload-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
Buka halaman Firewall policies di Konsol Google Cloud.
Klik Create firewall rule
untuk membuat aturan yang mengizinkan koneksi SSH yang masuk:- Nama:
fw-allow-ssh
- Jaringan:
lb-network
- Arah 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 Specified protocols and ports.
- Pilih kotak centang
tcp
dan tentukan port22
.
- Nama:
Klik Create.
Klik Create firewall rule
lagi untuk membuat aturan yang mengizinkan health check Google Cloud:- Nama:
fw-allow-health-check
- Jaringan:
lb-network
- Arah 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
dan35.191.0.0/16
- Protokol dan port:
- Pilih Protokol dan port yang ditentukan
- Pilih kotak centang
tcp
dan tentukan port80
. Sebagai praktik terbaik, batasi aturan ini hanya pada protokol dan port yang cocok dengan yang digunakan oleh health check Anda. Jika Anda menggunakantcp: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.
- Nama:
Klik Create.
Klik Create firewall rule
lagi untuk membuat aturan yang mengizinkan server proxy load balancer menghubungkan backend:- Nama:
fw-allow-proxies
- Jaringan:
lb-network
- Arah 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 Specified protocols and ports.
- Pilih kotak centang
tcp
dan tentukan port9376
.
- Nama:
Klik Create.
gcloud
Buat aturan firewall
fw-allow-ssh
untuk mengizinkan konektivitas SSH ke VM dengan tag jaringanallow-ssh
. Saat Anda menghapussource-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
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
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
- Buka halaman Create a load balancer di Konsol Google Cloud. Buka Create a load balancer
- Pada HTTP(S) Load Balancing, klik Start configuration.
- Pilih Only between my VMs. Pengaturan ini berarti load balancer bersifat internal.
- Klik Lanjutkan.
Menyiapkan load balancer
- Untuk Name load balancer, masukkan
l7-ilb-gke-map
. - Untuk Region, pilih region tempat Anda membuat subnet.
- Untuk Network, pilih
lb-network
.
Mereservasi subnet khusus proxy
Mereservasi subnet khusus proxy:
- Klik Reserve a Subnet.
- Untuk Name, masukkan
proxy-only-subnet
. - Untuk IP address range, masukkan
10.129.0.0/23
. - Klik Tambahkan.
Mengonfigurasi layanan backend
- Klik Backend configuration.
- Dari menu Create or select backend services, pilih Create a backend service.
- Setel Name layanan backend ke
l7-ilb-gke-backend-service
. - Untuk Backend type, pilih Network endpoint groups.
- Di kartu New backend pada bagian Backends:
- Tetapkan Network endpoint group ke NEG yang dibuat oleh GKE. Untuk mendapatkan nama NEG, lihat Memvalidasi pembuatan NEG.
- Untuk Maximum RPS, tentukan laju maksimum
5
RPS per endpoint. Google Cloud akan melampaui batas maksimum ini jika diperlukan. - Klik Done.
- Dari menu drop-down Health check, pilih
Create a health check, lalu tentukan parameter berikut:
- Nama:
l7-ilb-gke-basic-check
- Protokol: HTTP
- Spesifikasi port: Port aktif
- Klik Save and Continue.
- Nama:
- Klik Create.
Mengonfigurasi peta URL
- 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:
- Klik Frontend configuration.
- Klik Add frontend IP and port.
- Tetapkan Name ke l7-ilb-gke-forwarding-rule.
- Tetapkan Protocol ke HTTP.
- Tetapkan Subnetwork ke backend-subnet.
- Di bagian Internal IP, pilih Reserve a static internal IP address.
- Di panel yang muncul, berikan detail berikut:
- Name:
l7-ilb-gke-ip
- Di bagian Static IP address, pilih Let me choose.
- Di bagian Custom IP address, masukkan
10.1.2.199
. - Klik Reserve.
- Name:
- Tetapkan Port ke
80
. - 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.
- Klik Frontend configuration.
- Klik Add frontend IP and port.
- Di kolom Name, masukkan
l7-ilb-gke-forwarding-rule
. - Pada kolom Protocol, pilih
HTTPS (includes HTTP/2)
. - Tetapkan Subnet ke backend-subnet.
- Di bagian Internal IP, pilih Reserve a static internal IP address.
- Di panel yang muncul, berikan detail berikut:
- Name:
l7-ilb-gke-ip
- Di bagian Static IP address, pilih Let me choose.
- Di bagian Custom IP address, masukkan
10.1.2.199
. - Klik Reserve.
- Name:
- Pastikan Port ditetapkan ke
443
untuk mengizinkan traffic HTTPS. - Klik menu drop-down Certificate.
- Jika Anda sudah memiliki resource sertifikat SSL yang dikelola sendiri yang ingin digunakan sebagai sertifikat SSL utama, pilih sertifikat tersebut dari menu drop-down.
- Jika tidak, pilih Create a new certificate.
- Isi Name
l7-ilb-cert
. - Di kolom yang sesuai, upload file berformat PEM:
- Sertifikat kunci publik
- Rantai sertifikat
- Kunci pribadi
- Klik Create.
- Isi Name
- Untuk menambahkan resource sertifikat selain
resource sertifikat SSL utama:
- Klik Add certificate.
- Pilih sertifikat dari daftar Sertifikat atau klik Buat sertifikat baru dan ikuti petunjuknya.
- Klik Done.
Menyelesaikan konfigurasi
Klik Create.
gcloud
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
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
Tetapkan variabel
DEPLOYMENT_NAME
:export DEPLOYMENT_NAME=NEG_NAME
Ganti
NEG_NAME
dengan nama NEG.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
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
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
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 mengalami load balancing 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, host atau pencocokan 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.
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.
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.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
.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
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.Pastikan NEG memiliki endpoint VM:
gcloud compute network-endpoint-groups list-network-endpoints vm-neg \ --zone COMPUTE_ZONE
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
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
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:
Buat layanan backend baru untuk VM:
gcloud compute backend-services create my-vm-bes \ --protocol HTTP \ --health-checks http-basic-check \ --global
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
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
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
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 hanya dapat digunakan dengan layanan jaringan yang kompatibel, termasuk Traffic Director 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 memberikan 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 kondisiInitialized
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 itu traffic masih tidak dapat mencapai endpoint yang menyebabkan kode error 502 untuk HTTP(S) atau koneksi ditolak untuk load balancing TCP/SSL, periksa hal berikut:
- Pastikan aturan firewall mengizinkan traffic TCP masuk ke endpoint Anda dari
rentang berikut:
130.211.0.0/22
dan35.191.0.0/16
. - Pastikan endpoint Anda responsif menggunakan Google Cloud CLI atau dengan memanggil
getHealth
API dibackendService
atau listEndpoints API di NEG dengan parameter showHealth ditetapkan keSHOW
.
- Pastikan aturan firewall mengizinkan traffic TCP masuk ke endpoint Anda dari
rentang berikut:
Peluncuran terhenti
Gejala: Meluncurkan update Deployment yang 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 pengecualian 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