Menyiapkan Pod Google Kubernetes Engine menggunakan injeksi Envoy manual

Panduan ini menunjukkan cara mengonfigurasi host Google Kubernetes Engine atau Kubernetes Pod dan komponen load balancing yang diperlukan Cloud Service Mesh.

Catatan: Contoh konfigurasi ini hanya untuk tujuan demonstrasi. Anda mungkin perlu men-deploy komponen tambahan berdasarkan lingkungan dan persyaratan Anda.

Sebelum Anda mengikuti petunjuk dalam panduan ini, selesaikan tugas prasyarat yang dijelaskan dalam Bersiap untuk menyiapkan API perutean layanan dengan Envoy dan beban kerja tanpa proxy.

Anda dapat mengonfigurasi Cloud Service Mesh menggunakan SDK load balancing Compute Engine atau REST API. Lihat referensi load balancing API dan gcloud.

Catatan: Panduan ini hanya mendukung Cloud Service Mesh dengan Google Cloud API dan tidak mendukung Istio API. Untuk informasi selengkapnya, lihat ringkasan Cloud Service Mesh.

Mengonfigurasi cluster GKE/Kubernetes untuk Cloud Service Mesh

Bagian ini menjelaskan langkah-langkah yang diperlukan untuk mengaktifkan cluster GKE/Kubernetes agar berfungsi dengan Cloud Service Mesh.

Membuat cluster GKE

Cluster GKE harus memenuhi persyaratan berikut:

• Dukungan grup endpoint jaringan harus diaktifkan. Untuk informasi dan contoh selengkapnya, lihat Grup endpoint jaringan mandiri. Fitur NEG mandiri tersedia dalam Ketersediaan Umum untuk Cloud Service Mesh.
• Akun layanan instance node cluster harus memiliki izin untuk mengakses Cloud Service Mesh API.
  • Untuk mengetahui informasi tentang izin yang diperlukan, lihat Mengaktifkan akun layanan untuk mengakses Traffic Director API.
  • Untuk mengetahui informasi tentang cara mengaktifkan Cloud Service Mesh API, lihat Mengaktifkan Cloud Service Mesh API.
• Penampung harus memiliki akses ke Cloud Service Mesh API, yang dilindungi oleh autentikasi OAuth. Untuk informasi selengkapnya, lihat konfigurasi host.

Contoh berikut menunjukkan cara membuat cluster GKE yang disebut traffic-director-cluster di zona us-central1-a.

Konsol

Untuk membuat cluster menggunakan Konsol Google Cloud, lakukan langkah-langkah berikut:

1. Buka menu Kubernetes Engine di Konsol Google Cloud.

   Buka menu Google Kubernetes Engine

2. Klik Buat kluster.

3. Lengkapi kolom berikut:

   • Nama: Masukkan traffic-director-cluster.
   • Jenis lokasi: Zonal.
   • Zona: us-central1-a.

4. Dari panel navigasi, di bagian Node Pools, klik default-pool.

5. Kolom Size menunjukkan jumlah node yang akan dibuat di cluster. Anda harus memiliki kuota resource yang tersedia untuk node dan resource-nya (seperti rute firewall).

6. Dari panel navigasi, di bagian default-pool, klik Nodes.

7. Kolom Jenis mesin menunjukkan jenis mesin Compute Engine yang akan digunakan untuk instance. Setiap jenis mesin ditagih secara berbeda. Untuk mengetahui informasi harga jenis mesin, lihat halaman harga Compute Engine.

8. Dari panel navigasi, di bagian default-pool, klik Security.

9. Di bagian Access scopes, klik Allow full access to all Cloud APIs.

10. Sesuaikan cluster Anda sesuai kebutuhan.

11. Klik Create.

Setelah membuat cluster di konsol Google Cloud, Anda perlu mengonfigurasi kubectl untuk berinteraksi dengan cluster. Untuk mempelajari lebih lanjut, lihat Membuat entri kubeconfig.

gcloud

gcloud container clusters create traffic-director-cluster \
  --zone us-central1-a \
  --scopes=https://www.googleapis.com/auth/cloud-platform \
  --enable-ip-alias

Mendapatkan hak istimewa cluster GKE yang diperlukan

Untuk GKE, beralihlah ke cluster(2) yang baru saja Anda buat dengan mengeluarkan perintah berikut. Tindakan ini akan mengarahkan kubectl ke cluster yang benar.

gcloud container clusters get-credentials traffic-director-cluster \
    --zone us-central1-a

Mengonfigurasi layanan GKE/Kubernetes

Bagian ini menunjukkan cara menyiapkan spesifikasi deployment Kubernetes agar dapat berfungsi dengan Cloud Service Mesh. Hal ini terdiri dari mengonfigurasi layanan dengan NEG serta memasukkan proxy sidecar ke dalam Pod yang memerlukan akses ke layanan yang dikelola oleh Cloud Service Mesh.

Konfigurasikan aturan firewall

Untuk memverifikasi bahwa Pod backend sedang berjalan, Anda harus mengonfigurasi aturan firewall yang mengizinkan rentang alamat IP health checker.

Konsol

1. Buka halaman Firewall policies di Konsol Google Cloud.
   Buka halaman Kebijakan firewall
2. Klik Create firewall rules.
3. Di halaman Buat aturan firewall, berikan informasi berikut:
   • Nama: Berikan nama untuk aturan. Untuk contoh ini, gunakan fw-allow-health-checks.
   • Network: Pilih jaringan VPC.
   • Prioritas: Masukkan angka untuk prioritas. Angka yang lebih rendah memiliki prioritas yang lebih tinggi. Pastikan aturan firewall memiliki prioritas yang lebih tinggi daripada aturan lain yang mungkin menolak traffic masuk.
   • Direction of traffic: Pilih ingress.
   • Action on match: Pilih allow.
   • Targets: Pilih All instances in the network.
   • Filter sumber: Pilih jenis rentang IP yang benar.
   • Rentang IP sumber: 35.191.0.0/16,130.211.0.0/22
   • Filter tujuan: Pilih jenis IP.
   • Protocols and ports: Klik Specified ports and protocols, lalu centang tcp. TCP adalah protokol dasar untuk semua protokol health check.
   • Klik Create.

gcloud

1. Gunakan perintah gcloud berikut untuk membuat aturan firewall bernama fw-allow-health-checks yang mengizinkan koneksi masuk ke instance di jaringan Anda dengan tag allow-health-checks. Ganti NETWORK_NAME dengan nama jaringan Anda.

   gcloud compute firewall-rules create fw-allow-health-checks \
       --network NETWORK_NAME \
       --action ALLOW \
       --direction INGRESS \
       --source-ranges 35.191.0.0/16,130.211.0.0/22 \
       --rules tcp

Untuk mengetahui informasi selengkapnya, lihat mengonfigurasi aturan firewall untuk health check.

Mengonfigurasi layanan GKE / Kubernetes dengan NEG

Layanan GKE harus diekspos melalui grup endpoint jaringan (NEG) agar Anda dapat mengonfigurasinya sebagai backend layanan backend Cloud Service Mesh. Tambahkan anotasi NEG ke spesifikasi layanan Kubernetes dan pilih nama (dengan mengganti NEG-NAME dalam contoh di bawah) sehingga Anda dapat menemukannya dengan mudah nanti. Anda memerlukan nama tersebut saat melampirkan NEG ke layanan backend Cloud Service Mesh. Untuk mengetahui informasi selengkapnya tentang menganotasi NEG, lihat Penamaan NEG.

Catatan: Paket trafficdirector_service_sample.yaml yang disertakan dengan panduan penyiapan ini menggunakan nama NEG service-test-neg.

...
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports": {"80":{"name": "NEG-NAME"}}}'
spec:
  ports:
  - port: 80
    name: service-test
    protocol: TCP
    targetPort: 8000

Untuk setiap layanan, NEG mandiri dibuat, yang berisi endpoint yang merupakan alamat IP dan port pod. Untuk mengetahui informasi selengkapnya dan contoh, lihat Grup endpoint jaringan mandiri.

Untuk tujuan demonstrasi, Anda dapat men-deploy contoh layanan yang menyalurkan nama host-nya melalui HTTP di port 80:

wget -q -O - \
https://storage.googleapis.com/traffic-director/demo/trafficdirector_service_sample.yaml \
| kubectl apply -f -

Pastikan nama host layanan baru dibuat dan Pod aplikasi berjalan:

kubectl get svc

Tindakan ini akan menampilkan:

NAME             TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
service-test     ClusterIP   10.71.9.71   none          80/TCP    41m
[..skip..]

kubectl get pods

Tindakan ini akan menampilkan:

NAME                        READY     STATUS    RESTARTS   AGE
app1-6db459dcb9-zvfg2       1/1       Running   0          6m
[..skip..]

Menyimpan nama NEG

Temukan NEG yang dibuat dari contoh di atas dan catat nama NEG.

Konsol

Untuk melihat daftar grup endpoint jaringan, buka halaman Network Endpoint Groups di konsol Google Cloud.
Buka halaman Network Endpoint Groups

gcloud

gcloud compute network-endpoint-groups list

Tindakan ini akan menampilkan hal berikut:

NAME                 LOCATION          ENDPOINT_TYPE      SIZE
NEG-NAME           us-central1-a     GCE_VM_IP_PORT      1

Simpan nama NEG dalam variabel NEG_NAME, misalnya:

NEG_NAME=$(gcloud compute network-endpoint-groups list \
| grep service-test | awk '{print $1}')

Catatan: Jika Anda memberi nama NEG, seperti yang telah dibahas dalam Mengonfigurasi layanan GKE dengan NEG, Anda akan melihat bahwa nama NEG cocok dengan nama yang Anda berikan dalam spesifikasi layanan Kubernetes. Jika Anda tidak memberi nama NEG, nama akan dibuat secara otomatis untuk Anda.

Mengonfigurasi komponen load balancing Google Cloud untuk Cloud Service Mesh

Petunjuk di bagian ini memastikan bahwa layanan GKE dapat diakses di VIP layanan yang di-load balancing oleh Cloud Service Mesh, menggunakan konfigurasi load balancing yang mirip dengan produk Google Cloud Load Balancing lainnya.

Anda harus mengonfigurasi komponen berikut:

• Health check. Untuk mengetahui informasi selengkapnya tentang health check, baca Konsep Health Check dan Membuat Health Check.
• Layanan backend. Untuk mengetahui informasi selengkapnya tentang layanan backend, baca Layanan Backend.
• Aturan rute. Hal ini mencakup pembuatan aturan penerusan dan peta URL. Untuk mengetahui informasi selengkapnya, baca Menggunakan aturan penerusan dan Menggunakan peta URL.

Contoh konfigurasi Cloud Service Mesh yang akan dijelaskan berikut ini membuat asumsi berikut:

1. NEG dan semua resource lainnya dibuat di jaringan default, dengan mode otomatis, di zona us-central1-a.
2. Nama NEG untuk cluster disimpan dalam variabel ${NEG_NAME}.

Membuat health check

Buat health check.

Konsol

1. Buka halaman Health checks di konsol Google Cloud.
   Buka halaman Health checks
2. Klik Create Health Check.
3. Untuk nama, masukkan td-gke-health-check.
4. Untuk protokol, pilih HTTP.
5. Klik Create.

gcloud

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

Membuat layanan backend

Buat layanan backend global dengan skema load balancing INTERNAL_SELF_MANAGED. Di konsol Google Cloud, skema load balancing ditetapkan secara implisit. Tambahkan pemeriksaan status ke layanan backend.

Konsol

1. Buka halaman Cloud Service Mesh di konsol Google Cloud.

   Buka halaman Cloud Service Mesh

2. Di tab Services, klik Create Service.

3. Klik Lanjutkan.

4. Untuk nama layanan, masukkan td-gke-service.

5. Di bagian Backend type, pilih Network endpoint groups.

6. Pilih grup endpoint jaringan yang Anda buat.

7. Tetapkan Maximum RPS ke 5.

8. Klik Done.

9. Di bagian Health check, pilih td-gke-health-check, yang merupakan health check yang Anda buat.

10. Klik Lanjutkan.

gcloud

1. Buat layanan backend dan kaitkan health check dengan layanan backend.

   gcloud compute backend-services create td-gke-service \
    --global \
    --health-checks td-gke-health-check \
    --load-balancing-scheme INTERNAL_SELF_MANAGED
   

2. Tambahkan NEG backend ke layanan backend.

   gcloud compute backend-services add-backend td-gke-service \
    --global \
    --network-endpoint-group ${NEG_NAME} \
    --network-endpoint-group-zone us-central1-a \
    --balancing-mode RATE \
    --max-rate-per-endpoint 5
   

Membuat peta aturan perutean

Gunakan petunjuk ini untuk membuat aturan rute, aturan penerusan, dan alamat IP internal untuk konfigurasi Cloud Service Mesh Anda.

Traffic yang dikirim ke alamat IP internal dicegat oleh proxy Envoy dan dikirim ke layanan yang sesuai menurut aturan host dan jalur.

Aturan penerusan dibuat sebagai aturan penerusan global dengan load-balancing-scheme ditetapkan ke INTERNAL_SELF_MANAGED.

Anda dapat menetapkan alamat aturan penerusan ke 0.0.0.0. Jika Anda melakukannya, traffic akan dirutekan berdasarkan nama host HTTP dan informasi jalur yang dikonfigurasi di peta URL, terlepas dari alamat IP sebenarnya yang di-resolve oleh nama host. Dalam hal ini, URL (nama host plus jalur URL) layanan Anda, seperti yang dikonfigurasi dalam aturan host, harus unik dalam konfigurasi mesh layanan Anda. Artinya, Anda tidak dapat memiliki dua layanan yang berbeda, dengan kumpulan backend yang berbeda, yang keduanya menggunakan kombinasi nama host dan jalur yang sama.

Atau, Anda dapat mengaktifkan pemilihan rute berdasarkan VIP tujuan sebenarnya dari layanan. Jika Anda mengonfigurasi VIP layanan sebagai parameter address dari aturan penerusan, hanya permintaan yang ditujukan ke alamat IP ini yang dirutekan berdasarkan parameter HTTP yang ditentukan dalam peta URL.

Catatan: Terlepas dari metode yang dipilih, traffic ke alamat VIP yang di-resolve oleh nama host layanan Anda harus dicegat oleh proxy sidecar di host klien yang perlu mengakses layanan Anda. Lihat artikel Mengonfigurasi satu VM Compute Engine untuk Cloud Service Mesh untuk mengetahui detail konfigurasi host lengkap.

Catatan: Setiap aturan penerusan di jaringan VPC harus memiliki kombinasi alamat IP dan port yang unik per jaringan VPC, termasuk alamat 0.0.0.0. Jika Anda membuat lebih dari satu aturan penerusan dengan alamat IP dan port yang sama di jaringan VPC tertentu, hanya aturan penerusan pertama yang valid. Yang lainnya akan diabaikan.

Konsol

Di konsol, proxy target digabungkan dengan aturan penerusan. Saat Anda membuat aturan penerusan, Google Cloud akan otomatis membuat proxy HTTP target dan melampirkan proxy tersebut ke peta URL.

Aturan rute terdiri dari aturan penerusan serta aturan host dan jalur (juga dikenal sebagai peta URL).

1. Buka halaman Cloud Service Mesh di konsol Google Cloud.

   Buka halaman Cloud Service Mesh

2. Klik Routing rule maps

3. Klik Buat Aturan Pemilihan Rute.

4. Masukkan td-gke-url-map sebagai Nama peta URL.

5. Klik Tambahkan aturan penerusan.

6. Untuk nama aturan penerusan, masukkan td-gke-forwarding-rule.

7. Pilih jaringan Anda.

8. Pilih Internal IP Anda.

9. Klik Simpan.

10. Secara opsional, tambahkan aturan host dan jalur kustom atau biarkan aturan jalur sebagai default.

11. Tetapkan host ke service-test.

12. Klik Simpan.

gcloud

1. Buat peta URL yang menggunakan layanan backend.

   gcloud compute url-maps create td-gke-url-map \
      --default-service td-gke-service
   

2. Buat pencocok jalur peta URL dan aturan host untuk merutekan traffic untuk layanan Anda berdasarkan nama host dan jalur. Contoh ini menggunakan service-test sebagai nama layanan dan pencocok jalur default yang cocok dengan semua permintaan jalur untuk host ini (/*). service-test juga merupakan nama yang dikonfigurasi dari layanan Kubernetes yang digunakan dalam contoh konfigurasi di atas.

   gcloud compute url-maps add-path-matcher td-gke-url-map \
      --default-service td-gke-service \
      --path-matcher-name td-gke-path-matcher
   

   gcloud compute url-maps add-host-rule td-gke-url-map \
      --hosts service-test \
      --path-matcher-name td-gke-path-matcher
   

3. Buat proxy HTTP target.

   gcloud compute target-http-proxies create td-gke-proxy \
      --url-map td-gke-url-map
   

4. Membuat aturan penerusan.

   gcloud compute forwarding-rules create td-gke-forwarding-rule \
     --global \
     --load-balancing-scheme=INTERNAL_SELF_MANAGED \
     --address=0.0.0.0 \
     --target-http-proxy=td-gke-proxy \
     --ports 80 --network default
   

Pada tahap ini, Cloud Service Mesh dikonfigurasi untuk melakukan load balancing traffic untuk layanan yang ditentukan dalam peta URL di seluruh backend dalam grup endpoint jaringan.

Bergantung pada cara microservice didistribusikan di jaringan, Anda mungkin perlu menambahkan lebih banyak aturan penerusan atau lebih banyak aturan host dan jalur ke peta URL.

Memverifikasi konfigurasi dengan men-deploy klien contoh untuk pengujian

Bagian ini menunjukkan cara menjangkau backend Cloud Service Mesh dari aplikasi klien.

Untuk menunjukkan fungsinya, Anda dapat men-deploy contoh Pod yang menjalankan Busybox. Pod memiliki akses ke service-test, yang dibuat di bagian sebelumnya dan menerima traffic yang di-load balance oleh Cloud Service Mesh.

Memasukkan proxy sidecar ke dalam Pod GKE / Kubernetes

Untuk mengakses layanan yang dikelola oleh Cloud Service Mesh, Pod harus menginstal proxy sidecar yang kompatibel dengan xDS API.

Dalam contoh ini, Anda men-deploy klien Busybox dengan sidecar Istio-proxy dan penampung init yang ditambahkan ke deployment menggunakan spesifikasi referensi.

Jika Anda menggunakan API lama, ganti variabel PROJECT_NUMBER dan NETWORK_NAME dengan nomor project dan nama jaringan Anda:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_sample_xdsv3.yaml
sed -i "s/NETWORK_NAME/NETWORK_NAME/g" trafficdirector_client_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_sample_xdsv3.yaml

Jika Anda menggunakan API pemilihan rute layanan baru, yang saat ini dalam pratinjau, ganti variabel PROJECT_NUMBER dan MESH_NAME dengan nomor project dan nama Mesh:

wget -q -O - https://storage.googleapis.com/traffic-director/demo/trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/PROJECT_NUMBER/PROJECT_NUMBER/g" trafficdirector_client_new_api_sample_xdsv3.yaml
sed -i "s/MESH_NAME/MESH_NAME/g" trafficdirector_client_new_api_sample_xdsv3.yaml
kubectl apply -f trafficdirector_client_new_api_sample_xdsv3.yaml

Pod Busybox memiliki dua container yang berjalan. Penampung pertama adalah klien berdasarkan image Busybox dan penampung kedua adalah proxy Envoy yang dimasukkan sebagai sidecar. Anda bisa mendapatkan informasi selengkapnya tentang Pod dengan menjalankan perintah berikut:

kubectl describe pods -l run=client

Menjangkau layanan backend

Setelah dikonfigurasi, aplikasi di Pod yang telah memasukkan proxy sidecar dapat mengakses layanan yang dikelola oleh layanan Cloud Service Mesh. Untuk memverifikasi konfigurasi, Anda dapat mengakses shell di salah satu penampung.

Jika menggunakan konfigurasi demo yang disediakan dalam panduan ini, Anda dapat menjalankan perintah verifikasi berikut untuk memastikan bahwa nama host Pod yang ditayangkan ditampilkan.

# Get name of the Pod  with busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to execute that tests connectivity to the service service-test.
TEST_CMD="wget -q -O - service-test; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Memahami intersepsi traffic oleh proxy sidecar

Perhatikan bahwa, dalam contoh ini, saat klien Busybox membuat permintaan ke layanan backend, setiap permintaan akan di-proxy oleh proxy sidecar.

Aplikasi demonstrasi ini menggunakan proxy Envoy. Oleh karena itu, klien melihat 'server: envoy' di header respons server.

Untuk mengonfirmasinya, gunakan perintah berikut:

# Get the name of the Pod  with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test and output server response headers.
TEST_CMD="wget -S --spider service-test; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Dalam contoh ini, Anda membuat aturan penerusan menggunakan alamat VIP 0.0.0.0. Artinya, Cloud Service Mesh meneruskan permintaan ke backend hanya berdasarkan header Host. Dalam hal ini, alamat IP tujuan dapat berupa alamat apa pun selama header host permintaan cocok dengan host yang ditentukan dalam peta URL service-test.

Untuk mengonfirmasinya, jalankan perintah pengujian berikut:

# Get name of the Pod  with Busybox.
BUSYBOX_POD=$(kubectl get po -l run=client -o=jsonpath='{.items[0].metadata.name}')

# Command to send a request to service-test setting the Host header and using a random IP address.
TEST_CMD="wget -q --header 'Host: service-test' -O - 1.2.3.4; echo"

# Execute the test command on the Pod .
kubectl exec -it $BUSYBOX_POD -c busybox -- /bin/sh -c "$TEST_CMD"

Langkah selanjutnya

• Pelajari pengelolaan traffic lanjutan.
• Pelajari cara memecahkan masalah deployment Cloud Service Mesh.
• Pelajari cara menyiapkan kemampuan observasi dengan Envoy.