Menyiapkan Pod Google Kubernetes Engine menggunakan injeksi Envoy manual

Panduan ini menunjukkan cara mengonfigurasi host Google Kubernetes Engine atau Pod Kubernetes, serta komponen load balancing yang diperlukan Traffic Director.

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

Sebelum mengikuti petunjuk dalam panduan ini, tinjau Menyiapkan penyiapan Traffic Director dan pastikan Anda telah menyelesaikan prasyaratnya.

Anda dapat mengonfigurasi Traffic Director menggunakan SDK load balancing Compute Engine atau REST API. Lihat API load balancing dan referensi gcloud.

Mengonfigurasi cluster GKE/Kubernetes untuk Traffic Director

Bagian ini menjelaskan langkah-langkah yang diperlukan untuk mengaktifkan cluster GKE/Kubernetes agar dapat digunakan dengan Traffic Director.

Membuat cluster GKE

Cluster GKE harus memenuhi persyaratan berikut:

• Dukungan grup endpoint jaringan harus diaktifkan. Untuk mengetahui informasi dan contoh selengkapnya, lihat Grup endpoint jaringan mandiri. Fitur NEG mandiri tersedia di Ketersediaan Umum untuk Traffic Director.
• Akun layanan instance node cluster harus memiliki izin untuk mengakses Traffic Director API.
  • Untuk informasi tentang izin yang diperlukan, lihat Mengaktifkan akun layanan untuk mengakses Traffic Director API.
  • Untuk mengetahui informasi tentang cara mengaktifkan Traffic Director API, lihat Mengaktifkan Traffic Director API.
• Penampung harus memiliki akses ke Traffic Director API, yang dilindungi oleh autentikasi OAuth. Untuk mengetahui 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 Google Cloud Console, 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 Node.

7. Kolom Machine type menunjukkan jenis mesin 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, di bagian default-pool, klik Security.

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

10. Sesuaikan cluster Anda seperlunya.

11. Klik Create.

Setelah membuat cluster di Konsol Google Cloud, Anda perlu mengonfigurasi kubectl agar dapat 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

Memperoleh hak istimewa cluster GKE yang diperlukan

Untuk GKE, beralihlah ke cluster(2) yang baru saja dibuat dengan menjalankan 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 digunakan dengan Traffic Director. Hal ini terdiri dari mengonfigurasi layanan dengan NEG serta memasukkan proxy file bantuan ke dalam Pod yang memerlukan akses ke layanan yang dikelola oleh Traffic Director.

Konfigurasikan aturan firewall

Untuk memastikan Pod backend 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 Create a firewall rule, berikan informasi berikut:
   • Nama: Berikan nama untuk aturan. Untuk contoh ini, gunakan fw-allow-health-checks.
   • Network: Pilih sebuah jaringan VPC.
   • Priority: 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.
   • Arah traffic: Pilih ingress.
   • Tindakan pada kecocokan: Pilih izinkan.
   • Targets: Pilih All instances in the network.
   • Source filter: 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 protocol, lalu centang tcp. TCP adalah protokol dasar dari semua protokol health check.
   • 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 mengetahui 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 layanan backend Traffic Director. Tambahkan anotasi NEG ke spesifikasi layanan Kubernetes, lalu pilih nama (dengan mengganti NEG-NAME pada contoh di bawah) sehingga Anda dapat menemukannya dengan mudah nanti. Anda memerlukan nama tersebut saat melampirkan NEG ke layanan backend Traffic Director. Untuk informasi lebih lanjut tentang anotasi NEG, lihat Penamaan NEG.

Catatan: Paket trafficdirector_service_sample.yaml yang disediakan 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 akan dibuat, yang berisi endpoint yang merupakan port dan alamat IP pod. Untuk mengetahui informasi dan contoh selengkapnya, lihat Grup endpoint jaringan mandiri.

Untuk tujuan demonstrasi, Anda dapat men-deploy layanan contoh yang melayani host-nya melalui HTTP pada port 80:

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

Pastikan nama host layanan baru telah dibuat dan Pod aplikasi sedang berjalan:

kubectl get svc

Hasil 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

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

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 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 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 Traffic Director

Petunjuk di bagian ini memastikan bahwa layanan GKE dapat diakses di layanan VIP dengan load balancing oleh Traffic Director, 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 termasuk membuat aturan penerusan dan peta URL. Untuk mengetahui informasi selengkapnya, baca Menggunakan aturan penerusan dan Menggunakan peta URL.

Contoh konfigurasi Traffic Director di bawah ini menghasilkan asumsi ini:

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 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

Buat layanan backend global dengan skema load balancing INTERNAL_SELF_MANAGED. Di Konsol Google Cloud, skema load balancing ditetapkan secara implisit. Tambahkan health check ke layanan backend.

Konsol

1. Buka halaman Traffic Director di konsol Google Cloud.

   Buka halaman Traffic Director

2. Pada 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 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 Traffic Director Anda.

Traffic yang dikirim ke alamat IP internal dicegat oleh proxy Envoy dan dikirim ke layanan yang sesuai sesuai dengan 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 dirutekan berdasarkan nama host HTTP dan informasi jalur yang dikonfigurasi di peta URL, terlepas dari alamat IP sebenarnya yang ditetapkan oleh nama host. Dalam hal ini, URL (nama host dan jalur URL) layanan, 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 berbeda, yang menggunakan kombinasi nama host dan jalur yang sama.

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

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

Catatan: Setiap aturan penerusan dalam 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 di jaringan VPC tertentu, hanya aturan penerusan pertama yang valid. Fungsi 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 melampirkannya ke peta URL.

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

1. Buka halaman Traffic Director di konsol Google Cloud.

   Buka halaman Traffic Director

2. Klik Peta aturan pemilihan rute

3. Klik Create Routing Rule.

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

5. Klik Add forwarding rule.

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

7. Pilih jaringan Anda.

8. Pilih Internal IP.

9. Klik Simpan.

10. Jika ingin, tambahkan aturan host dan jalur kustom, atau biarkan aturan jalur sebagai default.

11. Tetapkan host ke service-test.

12. Klik Simpan.

gcloud

1. Membuat 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 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. 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, Traffic Director dikonfigurasi untuk melakukan load balancing terhadap traffic layanan yang ditentukan dalam peta URL di seluruh backend dalam grup endpoint jaringan.

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

Memverifikasi konfigurasi dengan men-deploy klien sampel untuk pengujian

Bagian ini menunjukkan cara menjangkau backend Traffic Director dari aplikasi klien.

Untuk mendemonstrasikan fungsi, Anda dapat men-deploy contoh Pod yang menjalankan Livelybox. Pod memiliki akses ke service-test, yang telah dibuat di bagian sebelumnya dan menerima traffic yang di-load balanced oleh Traffic Director.

Memasukkan proxy sidecar ke Pod GKE / Kubernetes

Untuk mengakses layanan yang dikelola oleh Traffic Director, Pod harus menginstal proxy file bantuan yang kompatibel dengan xDS API.

Dalam contoh ini, Anda men-deploy klien ramai dengan sidecar 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 sedang 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 Spanners memiliki dua container yang berjalan. Penampung pertama adalah klien yang didasarkan pada image Spanner dan penampung kedua adalah proxy Envoy yang dimasukkan sebagai file bantuan. Anda bisa mendapatkan informasi lebih lanjut tentang Pod dengan menjalankan perintah berikut:

kubectl describe pods -l run=client

Menjangkau layanan backend

Setelah dikonfigurasi, aplikasi di Pod yang memiliki proxy file bantuan yang dimasukkan dapat mengakses layanan yang dikelola oleh layanan Traffic Director. Untuk memverifikasi konfigurasi, Anda dapat mengakses shell di salah satu container.

Jika menggunakan konfigurasi demo yang diberikan dalam panduan ini, Anda dapat menjalankan perintah verifikasi berikut untuk memastikan bahwa nama host Pod yang melakukan penayangan 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 file bantuan

Perhatikan bahwa, dalam contoh ini, saat klien Livelybox membuat permintaan ke layanan backend, setiap permintaan akan di-proxy-kan oleh proxy file bantuan.

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

Untuk mengonfirmasi hal ini, 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 Traffic Director 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 memastikannya, 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 Traffic Director.
• Pelajari cara menyiapkan kemampuan observasi dengan Envoy.