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.

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.

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.

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.

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.

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

gcloud compute network-endpoint-groups list

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

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

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.

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.

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.

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.