Menyiapkan Pod Google Kubernetes Engine menggunakan injeksi Envoy manual

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

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

Sebelum mengikuti petunjuk dalam panduan ini, selesaikan prasyarat tugas yang dijelaskan dalam Bersiaplah untuk menyiapkan API pemilihan rute layanan dengan Envoy dan workload tanpa proxy.

Anda dapat mengonfigurasi Cloud Service Mesh menggunakan load balancing Compute Engine SDK 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 untuk berfungsi dengan Cloud Service Mesh.

Membuat cluster GKE

Cluster GKE harus memenuhi persyaratan berikut:

• Dukungan grup endpoint jaringan harus diaktifkan. Untuk informasi lebih lanjut dan contoh, lihat Endpoint jaringan mandiri grup. Fitur NEG mandiri tersedia di Ketersediaan Umum untuk dan Cloud Service Mesh.
• Instance node cluster akun layanan harus memiliki izin untuk mengakses Cloud Service Mesh API.
  • Untuk informasi tentang persyaratan izin, lihat Aktifkan akun layanan untuk mengakses Traffic Director API.
  • Untuk mengetahui informasi tentang cara mengaktifkan Cloud Service Mesh API, lihat Mengaktifkan Cloud Service Mesh API.
• Container 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 hal berikut langkah:

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 . 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 Machine type menunjukkan machine type Compute Engine yang akan digunakan untuk instance. Setiap jenis mesin ditagih secara berbeda. Untuk informasi harga jenis mesin, lihat halaman harga Compute Engine.

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

9. Di bagian Cakupan akses, klik Izinkan akses penuh ke semua Cloud API.

10. Sesuaikan cluster Anda seperlunya.

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 juga mencakup mengonfigurasi layanan dengan NEG seperti memasukkan proxy file bantuan ke dalam Pod yang memerlukan akses ke service 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. Pada halaman Create a firewall rule, 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 bahwa aturan firewall memiliki prioritas dibandingkan aturan lain yang dapat menolak traffic masuk.
   • Direction of traffic: Pilih ingress.
   • Tindakan saat kecocokan: Pilih izinkan.
   • 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 yang mendasari semua layanan kesehatan memeriksa protokol.
   • Klik Create.

gcloud

1. Gunakan perintah gcloud berikut untuk membuat aturan firewall bernama fw-allow-health-checks yang memungkinkan 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 informasi selengkapnya, lihat mengonfigurasi aturan firewal untuk health check.

Mengonfigurasi layanan GKE / Kubernetes dengan NEG

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

Catatan: Paket trafficdirector_service_sample.yaml yang disertakan dengan panduan penyiapan 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 akan dibuat, yang berisi endpoint yang alamat IP dan port pod. Untuk informasi lebih lanjut dan contoh, lihat Grup endpoint jaringan mandiri.

Untuk tujuan demonstrasi, Anda bisa men-deploy layanan contoh yang memberikan nama host melalui HTTP pada port 80:

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

Pastikan bahwa nama host layanan yang baru telah dibuat dan Pod aplikasi telah berlari:

kubectl get svc

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

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 Grup Endpoint Jaringan di Konsol Google Cloud.
Buka halaman Grup Endpoint Jaringan

gcloud

gcloud compute network-endpoint-groups list

Hasil dari kueri tersebut adalah sebagai berikut:

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

Simpan nama NEG di variabel NEG_NAME, misalnya:

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

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

Mengonfigurasi komponen Google Cloud load balancing untuk Cloud Service Mesh

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

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 informasi selengkapnya tentang layanan backend, baca Layanan Backend.
• Aturan rute. Termasuk di antaranya membuat aturan penerusan dan peta URL. Untuk informasi selengkapnya, baca Menggunakan aturan penerusan dan Menggunakan peta URL.

Contoh konfigurasi Cloud Service Mesh yang mengikutinya membuat asumsi:

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

Membuat health check

Membuat health check.

Konsol

1. Buka halaman Health check di Konsol Google Cloud.
   Buka halaman Health check
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

Membuat global layanan backend dengan skema load balancing INTERNAL_SELF_MANAGED. Di Konsol Google Cloud, skema load balancing diatur secara implisit. Menambahkan respons memeriksa 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. Setel RPS Maksimum 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. Membuat layanan backend dan mengaitkan 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 untuk konfigurasi Cloud Service Mesh Anda.

Traffic yang dikirim ke alamat IP internal dicegat oleh proxy Envoy dan dikirim ke layanan yang sesuai sesuai dengan aturan {i>host<i} 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, lalu lintas dirutekan berdasarkan nama {i>host<i} HTTP dan informasi jalur yang dikonfigurasi di peta URL, terlepas dari alamat IP aktual yang di-resolve nama host. Dalam hal ini, URL (nama host dan jalur URL) layanan Anda, seperti yang telah dikonfigurasi dalam aturan host, harus unik dalam konfigurasi mesh layanan Anda. Bahwa adalah, Anda tidak dapat memiliki dua layanan yang berbeda, dengan set backend yang berbeda, keduanya menggunakan kombinasi nama {i>host<i} dan jalur yang sama.

Atau, Anda dapat mengaktifkan perutean berdasarkan VIP tujuan aktual dari layanan. Jika Anda mengonfigurasi VIP layanan sebagai parameter address 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 nama host layanan yang di-resolve harus dicegat oleh file bantuan pada {i>host<i} klien yang perlu mengakses layanan Anda. Rujuk ke Mengonfigurasi satu VM Compute Engine untuk Cloud Service Mesh untuk detail konfigurasi host selengkapnya.

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

Konsol

Di konsol, proxy target digabungkan dengan aturan penerusan. Saat Anda membuat aturan penerusan, Google Cloud akan otomatis membuat {i>proxy<i} HTTP target dan melampirkannya 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 Peta aturan pemilihan rute

3. Klik Create Routing Rule.

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. Opsional, tambahkan aturan host dan jalur khusus atau biarkan aturan jalur sebagai secara default.

11. Setel 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 mengarahkan traffic untuk berdasarkan nama {i>host<i} dan jalur. Contoh ini menggunakan service-test sebagai nama layanan dan pencocok jalur default yang cocok dengan semua jalur untuk host ini (/*). service-test juga dikonfigurasi nama 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. Membuat 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 pada traffic layanan yang ditentukan dalam peta URL di seluruh backend di grup endpoint jaringan.

Bergantung pada cara microservice Anda didistribusikan di jaringan, Anda mungkin 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 klien aplikasi.

Untuk mendemonstrasikan fungsionalitas, Anda dapat men-deploy contoh Pod yang menjalankan sibuk. Tujuan pod memiliki akses ke service-test, yang dibuat di bagian sebelumnya dan menerima traffic yang di-load balanced oleh Cloud Service Mesh.

Memasukkan proxy file bantuan ke Pod GKE / Kubernetes

Untuk mengakses layanan yang dikelola oleh Cloud Service Mesh, Pod harus memiliki Proxy file bantuan yang kompatibel dengan xDS API diinstal.

Dalam contoh ini, Anda men-deploy klien sibuk dengan file bantuan Istio-proxy dan container 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 versi pratinjau, ganti atribut Variabel PROJECT_NUMBER dan MESH_NAME dengan project nomor 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 sibuk memiliki dua container yang sedang berjalan. Container pertama adalah berdasarkan image Computebox, dan container kedua adalah proxy Envoy. yang diinjeksikan sebagai file bantuan. Anda bisa mendapatkan informasi selengkapnya tentang Pod dengan menjalankan perintah berikut:

kubectl describe pods -l run=client

Menjangkau layanan backend

Setelah dikonfigurasi, aplikasi pada Pod yang memiliki proxy file bantuan yang diinjeksikan dapat mengakses layanan yang dikelola oleh layanan Cloud Service Mesh. Untuk memverifikasi , Anda dapat mengakses shell di salah satu container.

Jika menggunakan konfigurasi demo yang disediakan dalam panduan ini, Anda dapat menjalankan mengikuti perintah verifikasi untuk memastikan bahwa nama host Pod yang aktif akan dikembalikan.

# 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 file bantuan

Perhatikan bahwa, dalam contoh ini, ketika klien berupaya untuk membuat permintaan ke layanan backend, setiap permintaan di-proxy-kan oleh proxy file bantuan.

Aplikasi demonstrasi ini menggunakan proxy Envoy. Karena itu, klien melihat 'server: envoy' pada 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 berdasarkan header Host saja. Dalam hal ini, alamat IP tujuan bisa alamat mana saja selama header {i>host<i} permintaan cocok dengan {i>host<i} yang ditentukan di 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.