Workshop Anthos Service Mesh: Panduan Lab

1. WORKSHOP ALPHA

CATATAN PENTING: WORKSHOP INI ADALAH WORKSHOP ALFA DAN SANGAT DIMAKSUDKAN UNTUK MENJADI PELATIHAN DI KELAS YANG DIPANDU INSTRUKTUR.

Link ke codelab workshop bit.ly/asm-workshop

2. Ringkasan

Diagram Arsitektur

Workshop ini adalah pengalaman imersif langsung yang membahas cara menyiapkan layanan yang didistribusikan secara global di GCP dalam produksi. Teknologi utama yang digunakan adalah Google Kubernetes Engine (GKE) untuk komputasi dan Istio service mesh untuk membuat konektivitas yang aman, kemampuan observasi, dan pembentukan traffic lanjutan. Semua praktik dan alat yang digunakan dalam workshop ini adalah yang akan Anda gunakan dalam produksi.

Agenda

• Modul 0 - Pengantar dan Penyiapan Platform
• Pengantar dan arsitektur
• Pengantar Service Mesh dan Istio/ASM
• Lab: Penyiapan Infrastruktur: Alur kerja pengguna
• Istirahat
• QnA
• Modul 1 - Menginstal, mengamankan, dan memantau aplikasi dengan ASM
• Model repo: Penjelasan repo Infrastruktur dan Kubernetes
• Lab: Men-deploy aplikasi contoh
• Layanan Terdistribusi dan Kemampuan Observasi
• Makan Siang
• Lab: Observabilitas dengan Stackdriver
• QNA
• Modul 2 - DevOps - Peluncuran canary, kebijakan/RBAC
• Penemuan layanan multi-cluster dan keamanan/kebijakan
• Lab: TLS Bersama
• Deployment Canary
• Lab: Canary Deployments
• Load balancing global multi-cluster yang aman
• Istirahat
• Lab: Kebijakan Otorisasi
• QNA
• Modul 3 - Infra Ops - Upgrade platform
• Elemen penyusun Distributed Service
• Lab: Penskalaan Infrastruktur
• Langkah berikutnya

Slide

Slide untuk workshop ini dapat ditemukan di link berikut:

Slide Workshop ASM

Prasyarat

Berikut adalah hal-hal yang diperlukan sebelum Anda melanjutkan workshop ini:

1. Node Organisasi GCP
2. ID akun penagihan (pengguna Anda harus menjadi Admin Penagihan di akun penagihan ini)
3. Peran IAM Administrator Organisasi di tingkat Organisasi untuk pengguna Anda

3. Penyiapan Infrastruktur - Alur Kerja Admin

Langkah-langkah di bagian ini dilakukan oleh administrator yang membuat workshop.

Jika Anda adalah pengguna yang mengikuti workshop, lanjutkan ke bagian berikutnya yang diberi label Infrastructure Setup - User Workflow

Penjelasan skrip workshop Bootstrap

Skrip bernama bootstrap_workshop.sh digunakan untuk menyiapkan lingkungan awal untuk workshop. Anda dapat menggunakan skrip ini untuk menyiapkan satu lingkungan untuk diri sendiri atau beberapa lingkungan untuk beberapa pengguna jika Anda memberikan workshop ini sebagai pelatihan kepada beberapa pengguna.

Skrip workshop bootstrap memerlukan input berikut:

• Nama organisasi (misalnya yourcompany.com)- Ini adalah organisasi tempat Anda membuat lingkungan untuk workshop.
• ID Penagihan (misalnya 12345-12345-12345) - ID penagihan ini digunakan untuk menagih semua resource yang digunakan selama workshop.
• Nomor bengkel (misalnya 01) - Nomor dua digit. Bagian ini digunakan jika Anda mengadakan beberapa workshop dalam satu hari dan ingin melacaknya secara terpisah. Nomor workshop juga digunakan untuk mendapatkan ID project. Dengan memiliki nomor workshop yang terpisah, Anda dapat memastikan bahwa Anda mendapatkan project ID yang unik setiap kali. Selain nomor workshop, tanggal saat ini (diformat sebagai YYMMDD) juga digunakan untuk ID project. Kombinasi tanggal dan nomor workshop memberikan project ID yang unik.
• Nomor pengguna awal (misalnya 1) - Nomor ini menandakan pengguna pertama dalam workshop. Misalnya, jika Anda ingin membuat workshop untuk 10 pengguna, Anda dapat memiliki nomor pengguna awal 1 dan nomor pengguna akhir 10.
• Nomor pengguna akhir (misalnya 10) - Nomor ini menandakan pengguna terakhir dalam workshop. Misalnya, jika Anda ingin membuat workshop untuk 10 pengguna, Anda dapat memiliki nomor pengguna awal 1 dan nomor pengguna akhir 10. Jika Anda menyiapkan satu lingkungan (misalnya, untuk diri Anda sendiri), buat jumlah pengguna awal dan akhir sama. Tindakan ini akan membuat satu lingkungan.

Selain tanggal dan nomor workshop, nomor pengguna awal dan akhir juga disertakan dalam ID project. ID pengguna (untuk pengguna yang mengikuti workshop) berasal dari nomor pengguna awal dan akhir. ID pengguna dijelaskan di bagian yang bernama User schema and permissions performing the workshop.

• Bucket GCS admin (misalnya my-gcs-bucket-name) - Bucket GCS digunakan untuk menyimpan info terkait workshop. Informasi ini digunakan oleh skrip cleanup_workshop.sh untuk menghapus semua resource yang dibuat selama skrip workshop bootstrap dengan benar. Admin yang membuat workshop harus memiliki izin baca/tulis ke bucket ini.

Skrip bootstrap workshop menggunakan nilai yang diberikan di atas dan bertindak sebagai skrip wrapper yang memanggil skrip setup-terraform-admin-project.sh. Skrip setup-terraform-admin-project.sh membuat lingkungan workshop untuk satu pengguna.

Izin admin diperlukan untuk mem-bootstrap workshop

Ada dua jenis pengguna dalam workshop ini. ADMIN_USER, yang membuat dan menghapus resource untuk workshop ini. Yang kedua adalah MY_USER, yang melakukan langkah-langkah dalam workshop. MY_USER hanya memiliki akses ke resource miliknya sendiri. ADMIN_USER memiliki akses ke semua penyiapan pengguna. Jika Anda membuat penyiapan ini untuk diri sendiri, ADMIN_USER dan MY_USER akan sama. Jika Anda adalah instruktur yang membuat workshop ini untuk beberapa siswa, maka ADMIN_USER dan MY_USER Anda akan berbeda.

Izin tingkat organisasi berikut diperlukan untuk ADMIN_USER:

• Pemilik - Izin Pemilik Project untuk semua project di Organisasi.
• Admin Folder - Kemampuan untuk membuat dan menghapus folder di Organisasi. Setiap pengguna mendapatkan satu folder dengan semua resource mereka di dalam project.
• Organization Administrator
• Project Creator - Kemampuan untuk membuat project di Organisasi.
• Project Deleter - Kemampuan untuk menghapus project dalam Organisasi.
• Admin IAM Project - Kemampuan untuk membuat aturan IAM di semua project dalam Organisasi.

Selain itu, ADMIN_USER juga harus menjadi Administrator Penagihan untuk ID Penagihan yang digunakan untuk workshop.

Skema pengguna dan izin yang menjalankan workshop

Jika Anda berencana membuat workshop ini untuk pengguna (selain diri Anda sendiri) di organisasi Anda, Anda harus mengikuti skema penamaan pengguna tertentu untuk MY_USERs. Selama skrip bootstrap_workshop.sh, Anda memberikan nomor pengguna awal dan akhir. Angka-angka ini digunakan untuk membuat nama pengguna berikut:

• user<3 digit user number>@<organization_name>

Misalnya, jika Anda menjalankan skrip workshop bootstrap dengan nomor pengguna awal 1 dan nomor pengguna akhir 3, di organisasi Anda yang bernama perusahaananda.com, lingkungan workshop untuk pengguna berikut akan dibuat:

• [e-mail]
• [e-mail]
• [e-mail]

Nama pengguna ini diberi peran Pemilik project untuk project tertentu yang dibuat selama menjalankan skrip setup_terraform_admin_project.sh. Anda harus mematuhi skema penamaan pengguna ini saat menggunakan skrip bootstrap. Lihat cara menambahkan beberapa pengguna sekaligus di GSuite.

Alat yang diperlukan untuk workshop

Workshop ini dimaksudkan untuk di-bootstrap dari Cloud Shell. Alat berikut diperlukan untuk workshop ini.

• gcloud (ver >= 270)
• kubectl
• sed (berfungsi dengan sed di Cloud Shell/Linux, bukan Mac OS)
• git (pastikan Anda menggunakan versi terbaru)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

Semua alat kecuali kustomize sudah diinstal secara default di Cloud Shell. Jika kustomize belum diinstal, instal menggunakan skrip bash yang disediakan di link di atas dan pastikan biner kustomize ada di PATH Anda, lalu konfirmasi dengan menjalankan perintah kustomize di Cloud Shell.

Menyiapkan workshop untuk diri sendiri (penyiapan pengguna tunggal)

1. Buka Cloud Shell, lakukan semua tindakan di bawah di Cloud Shell. Klik link di bawah.

CLOUD SHELL

2. Pastikan Anda login ke gcloud dengan pengguna Admin yang dimaksud.

gcloud config list
 

3. Buat WORKDIR dan clone repositori workshop.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

4. Tentukan Nama organisasi, ID Penagihan, nomor workshop, dan bucket GCS admin yang akan digunakan untuk workshop. Tinjau izin yang diperlukan untuk menyiapkan workshop di bagian di atas.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<ADMIN_BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

5. Jalankan skrip bootstrap_workshop.sh. Proses skrip ini dapat memerlukan waktu beberapa menit.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --set-up-for-admin 
 

Perhatikan bahwa Anda tidak perlu menentukan jumlah pengguna awal dan akhir karena Anda menyiapkan ini untuk diri Anda sendiri.

Setelah skrip bootstrap_workshop.sh selesai, folder GCP akan dibuat untuk setiap pengguna dalam organisasi. Di dalam folder, project admin terraform dibuat. Project admin terraform digunakan untuk membuat resource GCP lainnya yang diperlukan untuk workshop ini. Anda mengaktifkan API yang diperlukan di project admin terraform. Anda menggunakan Cloud Build untuk menerapkan rencana Terraform. Anda memberikan peran IAM yang tepat kepada akun layanan Cloud Build agar dapat membuat resource di GCP. Terakhir, Anda mengonfigurasi backend jarak jauh di bucket Google Cloud Storage (GCS) untuk menyimpan status Terraform untuk semua resource GCP.

Untuk melihat tugas Cloud Build di project admin terraform, Anda memerlukan ID project admin terraform. Nilai ini disimpan dalam file vars/vars.sh di direktori asm Anda. Direktori ini hanya dipertahankan jika Anda menyiapkan workshop untuk diri sendiri sebagai administrator.

6. Gunakan file variabel untuk menetapkan variabel lingkungan

echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
source $WORKDIR/asm/vars/vars.sh 
 

Menyiapkan workshop untuk beberapa pengguna (penyiapan multi-pengguna)

7. Buka Cloud Shell, lakukan semua tindakan di bawah di Cloud Shell. Klik link di bawah.

CLOUD SHELL

8. Pastikan Anda login ke gcloud dengan pengguna Admin yang dimaksud.

gcloud config list
 

9. Buat WORKDIR dan clone repositori workshop.

mkdir asm-workshop
cd asm-workshop
export WORKDIR=`pwd`
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git asm
 

10. Tentukan Nama organisasi, ID penagihan, nomor workshop, jumlah pengguna awal dan akhir, serta bucket GCS admin yang akan digunakan untuk workshop. Tinjau izin yang diperlukan untuk menyiapkan workshop di bagian di atas.

gcloud organizations list
export ORGANIZATION_NAME=<ORGANIZATION NAME>

gcloud beta billing accounts list
export ADMIN_BILLING_ID=<BILLING ID>

export WORKSHOP_NUMBER=<two digit number for example 01>

export START_USER_NUMBER=<number for example 1>

export END_USER_NUMBER=<number greater or equal to START_USER_NUM>

export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

11. Jalankan skrip bootstrap_workshop.sh. Proses skrip ini dapat memerlukan waktu beberapa menit.

cd asm
./scripts/bootstrap_workshop.sh --org-name ${ORGANIZATION_NAME} --billing-id ${ADMIN_BILLING_ID} --workshop-num ${WORKSHOP_NUMBER} --start-user-num ${START_USER_NUMBER} --end-user-num ${END_USER_NUMBER} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET}
 

12. Dapatkan file workshop.txt dari bucket GCS admin untuk mengambil project ID terraform.

export WORKSHOP_ID="$(date '+%y%m%d')-${WORKSHOP_NUMBER}"
gsutil cp gs://${ADMIN_STORAGE_BUCKET}/${ORGANIZATION_NAME}/${WORKSHOP_ID}/workshop.txt .
 

4. Penyiapan dan Persiapan Lab

Pengguna yang mengikuti workshop dimulai di sini. Lakukan semua langkah dari jendela INCOGNITO di Chrome atau Firefox.

Pilih jalur lab Anda

Lab dalam workshop ini dapat dilakukan dengan salah satu dari dua cara berikut:

• Cara "skrip interaktif jalur cepat yang mudah"
• Cara "menyalin dan menempelkan setiap petunjuk secara manual"

Metode skrip jalur cepat memungkinkan Anda menjalankan satu skrip interaktif untuk setiap lab yang memandu Anda melalui lab dengan menjalankan perintah untuk lab tersebut secara otomatis. Perintah dijalankan dalam batch dengan penjelasan singkat tentang setiap langkah dan apa yang dicapai. Setelah setiap batch, Anda akan diminta untuk melanjutkan ke batch perintah berikutnya. Dengan begitu, Anda dapat menjalankan lab sesuai kecepatan Anda. Skrip jalur cepat bersifat idempoten, yang berarti Anda dapat menjalankan skrip ini beberapa kali dan menghasilkan hasil yang sama.

Skrip jalur cepat akan muncul di bagian atas setiap lab dalam kotak hijau seperti yang ditunjukkan di bawah.

SKRIP JALUR CEPAT

${WORKDIR}/asm/fasttrack_scripts/<name_of_script>.sh

Metode salin dan tempel adalah cara tradisional untuk menyalin dan menempelkan setiap blok perintah dengan penjelasan perintah. Metode ini hanya dimaksudkan untuk dijalankan sekali. Tidak ada jaminan bahwa menjalankan kembali perintah dengan metode ini akan memberikan hasil yang sama.

Saat melakukan lab, pilih salah satu dari dua metode.

Setelah Anda memilih metode dan melakukan langkah-langkah dalam metode tersebut, jangan lakukan langkah-langkah dalam metode lainnya.

Penyiapan Skrip Jalur Cepat

Setelah menyelesaikan skrip jalur cepat, Anda telah menyelesaikan lab tersebut. Jangan lakukan langkah-langkah dalam Petunjuk Lab Salin dan Tempel.

Mendapatkan info Pengguna

Workshop ini dilakukan menggunakan akun pengguna sementara (atau akun lab) yang dibuat oleh administrator workshop. Akun lab memiliki semua project dalam workshop. Administrator workshop memberikan kredensial akun lab (nama pengguna dan sandi) kepada pengguna yang mengikuti workshop. Semua project pengguna diberi awalan nama pengguna akun lab. Misalnya, untuk akun lab [e-mail], ID project admin terraform adalah user001-200131-01-tf-abcde, dan seterusnya untuk project lainnya. Setiap pengguna harus login dengan akun lab yang disediakan oleh administrator workshop dan melakukan workshop menggunakan akun lab tersebut.

Periksa email perusahaan Anda (email yang sama dengan yang Anda gunakan untuk mendaftar ke workshop). Anda seharusnya sudah menerima email dari admin workshop yang berisi kredensial akun lab Anda (yaitu nama pengguna dan sandi). Emailnya akan terlihat seperti ini.

1. Buka Cloud Shell dengan mengklik link di bawah.

CLOUD SHELL

2. Login dengan kredensial akun lab (jangan login dengan akun perusahaan atau pribadi Anda). Akun lab akan terlihat seperti userXYZ@<workshop_domain>.com.
3. Karena ini adalah akun baru, Anda akan diminta untuk menyetujui Persyaratan Layanan Google. Klik Setuju.

4. Di layar berikutnya, centang kotak untuk menyetujui Persyaratan Layanan Google, lalu klik Start Cloud Shell.

Langkah ini menyediakan VM Linux Debian kecil yang dapat Anda gunakan untuk mengakses resource GCP. Setiap akun mendapatkan VM Cloud Shell. Login dengan akun lab akan menyediakan dan membuat Anda login menggunakan kredensial akun lab. Selain Cloud Shell, Code Editor juga disediakan sehingga memudahkan pengeditan file konfigurasi (terraform, YAML, dll.). Secara default, layar Cloud Shell dibagi menjadi lingkungan shell Cloud Shell (di bagian bawah) dan Cloud Code Editor (di bagian atas). Ikon pensil dan perintah shell di pojok kanan atas memungkinkan Anda beralih di antara keduanya (shell dan editor kode). Anda juga dapat menarik panel pemisah tengah (ke atas atau ke bawah) dan mengubah ukuran setiap jendela secara manual. 5. Buat WORKDIR untuk workshop ini. WORKDIR adalah folder tempat Anda melakukan semua lab untuk workshop ini. Jalankan perintah berikut di Cloud Shell untuk membuat WORKDIR.

mkdir -p ${HOME}/asm-workshop
cd ${HOME}/asm-workshop
export WORKDIR=`pwd` 
 

6. Ekspor pengguna akun lab sebagai variabel yang akan digunakan untuk workshop ini. Akun ini sama dengan akun yang Anda gunakan untuk login ke Cloud Shell.

export MY_USER=<LAB ACCOUNT EMAIL PROVIDED BY THE WORKSHOP ADMIN>
# For example export MY_USER=[e-mail] 
 

Catatan: Jika Anda adalah admin dan menyiapkan workshop untuk diri sendiri menggunakan flag "-sufa" atau "–setup-for-admin", tetapkan MY_USER ke email untuk akun GCP yang Anda gunakan untuk membuat project workshop.

7. Tampilkan variabel WORKDIR dan MY_USER untuk memastikan keduanya ditetapkan dengan benar dengan menjalankan perintah berikut.

echo "WORKDIR set to ${WORKDIR}" && echo "MY_USER set to ${MY_USER}"
 

8. Buat clone repo workshop.

git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git ${WORKDIR}/asm
 

5. Penyiapan Infrastruktur - Alur Kerja Pengguna

Tujuan: Memverifikasi penginstalan infrastruktur dan Istio

• Menginstal alat workshop
• Meng-clone repo workshop
• Verifikasi penginstalan Infrastructure
• Verifikasi penginstalan k8s-repo
• Memverifikasi penginstalan Istio

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-setup-user-workflow.sh

Setelah skrip selesai, jalankan bashrc untuk memperbarui variabel di sesi Cloud Shell Anda.

source ${HOME}/.bashrc

Petunjuk Lab Metode Salin dan Tempel

PENTING: Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Mendapatkan info Pengguna

Administrator yang menyiapkan workshop harus memberikan informasi nama pengguna dan sandi kepada pengguna. Semua project pengguna akan diberi awalan nama pengguna, misalnya untuk pengguna [e-mail], ID project admin terraform adalah user001-200131-01-tf-abcde, dan seterusnya untuk project lainnya. Setiap pengguna hanya memiliki akses ke lingkungan workshopnya sendiri.

Alat yang diperlukan untuk workshop

Workshop ini dimaksudkan untuk di-bootstrap dari Cloud Shell. Alat berikut diperlukan untuk workshop ini.

Semua alat kecuali kustomize dan pv sudah diinstal secara default di Cloud Shell. Anda akan menemukan petunjuk untuk menginstal keduanya di bawah.

• gcloud (ver >= 270)
• kubectl
• sed (berfungsi dengan sed di Cloud Shell/Linux, bukan Mac OS)
• git (pastikan Anda menggunakan versi terbaru)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Mengakses project admin terraform

Setelah skrip bootstrap_workshop.sh selesai, folder GCP akan dibuat untuk setiap pengguna dalam organisasi. Di dalam folder, project admin terraform dibuat. Project admin terraform digunakan untuk membuat resource GCP lainnya yang diperlukan untuk workshop ini. Skrip setup-terraform-admin-project.sh mengaktifkan API yang diperlukan di project admin terraform. Cloud Build digunakan untuk menerapkan rencana Terraform. Melalui skrip, Anda memberikan peran IAM yang tepat kepada akun layanan Cloud Build agar dapat membuat resource di GCP. Terakhir, backend jarak jauh dikonfigurasi di bucket Google Cloud Storage (GCS) untuk menyimpan status Terraform untuk semua resource GCP.

Untuk melihat tugas Cloud Build di project admin terraform, Anda memerlukan ID project admin terraform. Hal ini disimpan di bucket GCS admin yang ditentukan dalam skrip bootstrap. Jika Anda menjalankan skrip bootstrap untuk beberapa pengguna, semua ID project admin terraform akan berada di bucket GCS.

Workshop ini dimaksudkan untuk dilakukan di Cloud Shell dan Konsol Cloud. Lakukan langkah-langkah berikut di jendela INCOGNITO karena Anda akan login dengan nama pengguna dan sandi yang berbeda.

1. Buka Cloud Shell (jika belum terbuka dari bagian Penyiapan dan Persiapan Lab) dengan mengklik link di bawah.

CLOUD SHELL

2. Instal kustomize (jika belum diinstal) di folder $HOME/bin dan tambahkan folder $HOME/bin ke $PATH.

mkdir -p $HOME/bin
cd $HOME/bin
curl -s "https://raw.githubusercontent.com/\
kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash
cd $HOME
export PATH=$PATH:${HOME}/bin
echo "export PATH=$PATH:$HOME/bin" >> $HOME/.bashrc
 

3. Instal pv dan pindahkan ke $HOME/bin/pv.

sudo apt-get update && sudo apt-get -y install pv
sudo mv /usr/bin/pv ${HOME}/bin/pv
 

4. Perbarui prompt bash Anda.

cp $WORKDIR/asm/scripts/krompt.bash $HOME/.krompt.bash
echo "export PATH=\$PATH:\$HOME/bin" >> $HOME/.asm-workshop.bash
echo "source $HOME/.krompt.bash" >> $HOME/.asm-workshop.bash

alias asm-init='source $HOME/.asm-workshop.bash' >> $HOME/.bashrc
echo "source $HOME/.asm-workshop.bash" >> $HOME/.bashrc
source $HOME/.bashrc
 

5. Pastikan Anda login ke gcloud dengan akun pengguna yang diinginkan.

echo "Check logged in user output from the next command is $MY_USER"
gcloud config list account --format=json | jq -r .core.account
 

6. Dapatkan ID project admin Terraform Anda dengan menjalankan perintah berikut:

export TF_ADMIN=$(gcloud projects list | grep tf- | awk '{ print $1 }')
echo $TF_ADMIN
 

7. Semua resource yang terkait dengan workshop disimpan sebagai variabel dalam file vars.sh yang disimpan di bucket GCS dalam project admin terraform. Dapatkan file vars.sh untuk project admin terraform Anda.

mkdir $WORKDIR/asm/vars
gsutil cp gs://$TF_ADMIN/vars/vars.sh $WORKDIR/asm/vars/vars.sh
echo "export WORKDIR=$WORKDIR" >> $WORKDIR/asm/vars/vars.sh
 

8. Klik link yang ditampilkan untuk membuka halaman Cloud Build project admin Terraform dan pastikan build berhasil diselesaikan.

source $WORKDIR/asm/vars/vars.sh
echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Jika mengakses Konsol Cloud untuk pertama kalinya, setujui Persyaratan Layanan Google.

9. Sekarang setelah Anda melihat halaman Cloud Build, klik link History dari panel navigasi sebelah kiri, lalu klik build terbaru untuk melihat detail penerapan Terraform awal. Resource berikut dibuat sebagai bagian dari skrip Terraform. Anda juga dapat melihat diagram arsitektur di atas.

• 4 Project GCP di Org. Akun Penagihan yang diberikan dikaitkan dengan setiap project.
• Satu project adalah network host project untuk VPC bersama. Tidak ada resource lain yang dibuat dalam project ini.
• Satu project adalah ops project yang digunakan untuk cluster GKE bidang kontrol Istio.
• Dua project mewakili dua tim pengembangan berbeda yang mengerjakan layanan masing-masing.
• Dua cluster GKE dibuat di setiap project ops, dev1, dan dev2.
• Repo CSR bernama k8s-repo dibuat yang berisi enam folder untuk file manifes Kubernetes. Satu folder per cluster GKE. Repo ini digunakan untuk men-deploy manifes Kubernetes ke cluster dengan cara GitOps.
• Pemicu Cloud Build dibuat sehingga setiap kali ada commit ke cabang master k8s-repo, pemicu akan men-deploy manifes Kubernetes ke cluster GKE dari folder masing-masing.

Skrip terraform memerlukan waktu 40-50 menit.

10. Setelah build selesai di terraform admin project, build lain akan dimulai di project ops. Klik link yang ditampilkan untuk membuka halaman Cloud Build untuk ops project dan verifikasi bahwa Cloud Build k8s-repo berhasil diselesaikan.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

Catatan: Build ini harus diselesaikan sebelum Anda dapat memverifikasi Penginstalan Istio.

Verifikasi penginstalan

11. Buat file kubeconfig untuk semua cluster. Jalankan skrip berikut.

$WORKDIR/asm/scripts/setup-gke-vars-kubeconfig.sh
 

Skrip ini akan membuat file kubeconfig baru di folder gke bernama kubemesh.

12. Ubah variabel KUBECONFIG agar mengarah ke file kubeconfig baru.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

13. Tambahkan vars.sh dan KUBECONFIG var ke .bashrc di Cloud Shell agar di-source setiap kali Cloud Shell dimulai ulang.

echo "source ${WORKDIR}/asm/vars/vars.sh" >> $HOME/.bashrc
echo "export KUBECONFIG=${WORKDIR}/asm/gke/kubemesh" >> $HOME/.bashrc
 

14. Cantumkan konteks cluster Anda. Anda akan melihat enam cluster.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_tf05-01-ops_us-central1_gke-asm-2-r2-prod
gke_tf05-01-ops_us-west1_gke-asm-1-r1-prod
gke_tf05-02-dev1_us-west1-a_gke-1-apps-r1a-prod
gke_tf05-02-dev1_us-west1-b_gke-2-apps-r1b-prod
gke_tf05-03-dev2_us-central1-a_gke-3-apps-r2a-prod
gke_tf05-03-dev2_us-central1-b_gke-4-apps-r2b-prod

Memverifikasi Penginstalan Istio

15. Pastikan Istio diinstal di kedua cluster dengan memeriksa apakah semua pod berjalan dan tugas telah selesai.

kubectl --context ${OPS_GKE_1} get pods -n istio-system
kubectl --context ${OPS_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-z9f98                  1/1     Running   0          6m21s
istio-citadel-568747d88-qdw64             1/1     Running   0          6m26s
istio-egressgateway-8f454cf58-ckw7n       1/1     Running   0          6m25s
istio-galley-6b9495645d-m996v             2/2     Running   0          6m25s
istio-ingressgateway-5df799fdbd-8nqhj     1/1     Running   0          2m57s
istio-pilot-67fd786f65-nwmcb              2/2     Running   0          6m24s
istio-policy-74cf89cb66-4wrpl             2/2     Running   1          6m25s
istio-sidecar-injector-759bf6b4bc-mw4vf   1/1     Running   0          6m25s
istio-telemetry-77b6dfb4ff-zqxzz          2/2     Running   1          6m24s
istio-tracing-cd67ddf8-n4d7k              1/1     Running   0          6m25s
istiocoredns-5f7546c6f4-g7b5c             2/2     Running   0          6m39s
kiali-7964898d8c-5twln                    1/1     Running   0          6m23s
prometheus-586d4445c7-xhn8d               1/1     Running   0          6m25s

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-2s8k4                  1/1     Running   0          59m
istio-citadel-568747d88-87kdj             1/1     Running   0          59m
istio-egressgateway-8f454cf58-zj9fs       1/1     Running   0          60m
istio-galley-6b9495645d-qfdr6             2/2     Running   0          59m
istio-ingressgateway-5df799fdbd-2c9rc     1/1     Running   0          60m
istio-pilot-67fd786f65-nzhx4              2/2     Running   0          59m
istio-policy-74cf89cb66-4bc7f             2/2     Running   3          59m
istio-sidecar-injector-759bf6b4bc-grk24   1/1     Running   0          59m
istio-telemetry-77b6dfb4ff-6zr94          2/2     Running   4          60m
istio-tracing-cd67ddf8-grs9g              1/1     Running   0          60m
istiocoredns-5f7546c6f4-gxd66             2/2     Running   0          60m
kiali-7964898d8c-nhn52                    1/1     Running   0          59m
prometheus-586d4445c7-xr44v               1/1     Running   0          59m

16. Pastikan Istio diinstal di kedua cluster dev1. Hanya Citadel, sidecar-injector, dan coredns yang berjalan di cluster dev1. Keduanya berbagi bidang kontrol Istio yang berjalan di cluster ops-1.

kubectl --context ${DEV1_GKE_1} get pods -n istio-system
kubectl --context ${DEV1_GKE_2} get pods -n istio-system
 

17. Pastikan Istio diinstal di kedua cluster dev2. Hanya Citadel, sidecar-injector, dan coredns yang berjalan di cluster dev2. Mereka berbagi bidang kontrol Istio yang berjalan di cluster ops-2.

kubectl --context ${DEV2_GKE_1} get pods -n istio-system
kubectl --context ${DEV2_GKE_2} get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Memverifikasi penemuan layanan untuk bidang kontrol bersama

18. Secara opsional, verifikasi bahwa secret telah di-deploy.

kubectl --context ${OPS_GKE_1} get secrets -l istio/multiCluster=true -n istio-system
kubectl --context ${OPS_GKE_2} get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

For OPS_GKE_1:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      8m7s
gke-2-apps-r1b-prod   Opaque   1      8m7s
gke-3-apps-r2a-prod   Opaque   1      44s
gke-4-apps-r2b-prod   Opaque   1      43s

For OPS_GKE_2:
NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      40s
gke-2-apps-r1b-prod   Opaque   1      40s
gke-3-apps-r2a-prod   Opaque   1      8m4s
gke-4-apps-r2b-prod   Opaque   1      8m4s

Dalam workshop ini, Anda akan menggunakan satu VPC bersama tempat semua cluster GKE dibuat. Untuk menemukan layanan di seluruh cluster, Anda menggunakan file kubeconfig (untuk setiap cluster aplikasi) yang dibuat sebagai secret di cluster ops. Pilot menggunakan secret ini untuk menemukan Layanan dengan membuat kueri ke server API Kube dari cluster aplikasi (diautentikasi melalui secret di atas). Anda melihat bahwa kedua cluster ops dapat melakukan autentikasi ke semua cluster aplikasi menggunakan secret yang dibuat kubeconfig. Cluster Ops dapat menemukan layanan secara otomatis menggunakan file kubeconfig sebagai metode rahasia. Hal ini mengharuskan Pilot di cluster ops memiliki akses ke server API Kube dari semua cluster lainnya. Jika Pilot tidak dapat menjangkau server Kube API, Anda harus menambahkan layanan jarak jauh secara manual sebagai ServiceEntries. Anda dapat menganggap ServiceEntry sebagai entri DNS di pendaftaran layanan Anda. ServiceEntry menentukan layanan menggunakan nama DNS yang sepenuhnya memenuhi syarat ( FQDN) dan alamat IP tempat layanan tersebut dapat dijangkau. Lihat dokumen Multicluster Istio untuk mengetahui informasi selengkapnya.

6. Penjelasan Repo Infrastruktur

Build Cloud Infrastructure

Resource GCP untuk workshop ini dibuat menggunakan Cloud Build dan infrastructure repositori CSR. Anda baru saja menjalankan skrip bootstrap (yang berada di scripts/bootstrap_workshop.sh) dari terminal lokal. Skrip bootstrap membuat folder GCP, project admin terraform, dan izin IAM yang sesuai untuk akun layanan Cloud Build. Project admin Terraform digunakan untuk menyimpan status, log, dan skrip lain-lain Terraform. Repositori ini berisi repositori CSR infrastructure dan k8s_repo. Repositori ini dijelaskan secara mendetail di bagian berikutnya. Tidak ada resource workshop lain yang dibuat di project admin terraform. Akun layanan Cloud Build di project admin terraform digunakan untuk membangun resource untuk workshop.

File cloudbuild.yaml yang ada di folder infrastructure digunakan untuk membangun resource GCP untuk workshop. Hal ini akan membuat image builder kustom dengan semua alat yang diperlukan untuk membuat resource GCP. Alat ini mencakup gcloud SDK, terraform, dan utilitas lainnya seperti python, git, jq, dll. Image builder kustom menjalankan terraform plan dan apply untuk setiap resource. File terraform setiap resource berada di folder terpisah (detail di bagian berikutnya). Resource dibuat satu per satu dan sesuai urutan pembuatannya (misalnya, project GCP dibuat sebelum resource dibuat dalam project). Tinjau file cloudbuild.yaml untuk mengetahui detail selengkapnya.

Cloud Build dipicu setiap kali ada commit ke repo infrastructure. Setiap perubahan yang dilakukan pada infrastruktur disimpan sebagai Infrastructure as code (IaC) dan di-commit ke repo. Status workshop Anda selalu disimpan di repo ini.

Struktur folder - tim, lingkungan, dan resource

Repositori Infrastruktur menyiapkan resource infrastruktur GCP untuk workshop. File diatur ke dalam folder dan subfolder. Folder dasar dalam repo merepresentasikan team yang memiliki resource GCP tertentu. Lapisan folder berikutnya mewakili environment tertentu untuk tim (misalnya dev, stage, prod). Lapisan folder berikutnya dalam lingkungan mewakili resource tertentu (misalnya host_project, gke_clusters, dll.). Skrip dan file terraform yang diperlukan ada di dalam folder resource.

Empat jenis tim berikut diwakili dalam workshop ini:

1. infrastructure - mewakili tim infrastruktur cloud. Mereka bertanggung jawab untuk membuat resource GCP bagi semua tim lainnya. Mereka menggunakan project admin Terraform untuk resource mereka. Repositori infrastruktur itu sendiri berada di project admin Terraform, serta file status Terraform (dijelaskan di bawah). Resource ini dibuat oleh skrip bash selama proses bootstrap (lihat Modul 0 - Alur Kerja Administrator untuk mengetahui detailnya).
2. network - mewakili tim jaringan. Mereka bertanggung jawab atas resource VPC dan jaringan. Mereka memiliki resource GCP berikut.
3. host project - merepresentasikan project host VPC Bersama.
4. shared VPC - mewakili VPC bersama, subnet, rentang IP sekunder, rute, dan aturan firewall.
5. ops - merepresentasikan tim operasi/devops. Mereka memiliki resource berikut.
6. ops project - merepresentasikan project untuk semua resource operasi.
7. gke clusters - cluster GKE ops per region. Bidang kontrol Istio diinstal di setiap cluster GKE ops.
8. k8s-repo - repositori CSR yang berisi manifes GKE untuk semua cluster GKE.
9. apps - mewakili tim aplikasi. Workshop ini mensimulasikan dua tim, yaitu app1 dan app2. Mereka memiliki resource berikut.
10. app projects - setiap tim aplikasi mendapatkan kumpulan projectnya sendiri. Dengan begitu, mereka dapat mengontrol penagihan dan IAM untuk project tertentu.
11. gke clusters - ini adalah cluster aplikasi tempat container/Pod aplikasi berjalan.
12. gce instances - secara opsional, jika mereka memiliki aplikasi yang berjalan di instance GCE. Dalam workshop ini, app1 memiliki beberapa instance GCE tempat sebagian aplikasi berjalan.

Dalam workshop ini, aplikasi yang sama (aplikasi Hipster Shop) merepresentasikan app1 dan app2.

Penyedia, Status, dan Output - Backend dan status bersama

Penyedia google dan google-beta terletak di gcp/[environment]/gcp/provider.tf. File provider.tf di-symlinked di setiap folder resource. Dengan begitu, Anda dapat mengubah penyedia di satu tempat, bukan mengelola penyedia satu per satu untuk setiap resource.

Setiap resource berisi file backend.tf yang menentukan lokasi untuk file tfstate resource. File backend.tf ini dibuat dari template (yang terletak di templates/backend.tf_tmpl) menggunakan skrip (yang terletak di scripts/setup_terraform_admin_project), lalu ditempatkan di folder resource masing-masing. Bucket Google Cloud Storage (GCS) digunakan untuk backend. Nama folder bucket GCS cocok dengan nama resource. Semua backend resource berada di project admin terraform.

Resource dengan nilai yang saling bergantung berisi file output.tf. Nilai output yang diperlukan disimpan dalam file tfstate yang ditentukan di backend untuk resource tertentu tersebut. Misalnya, untuk membuat cluster GKE dalam project, Anda perlu mengetahui project ID. ID Project ditampilkan melalui output.tf ke file tfstate yang dapat digunakan melalui sumber data terraform_remote_state di resource cluster GKE.

File shared_state adalah sumber data terraform_remote_state yang mengarah ke file tfstate resource. File shared_state_[resource_name].tf (atau file) ada di folder resource yang memerlukan output dari resource lain. Misalnya, di folder resource ops_gke, ada file shared_state dari resource ops_project dan shared_vpc, karena Anda memerlukan project ID dan detail VPC untuk membuat cluster GKE di project ops. File shared_state dibuat dari template (berada di templates/shared_state.tf_tmpl) menggunakan skrip (berada di scripts/setup_terraform_admin_project). Semua file shared_state resource ditempatkan di folder gcp/[environment]/shared_states. File shared_state yang diperlukan di-symlink di folder resource masing-masing. Menempatkan semua file shared_state dalam satu folder dan membuat link simbolis ke folder resource yang sesuai akan memudahkan pengelolaan semua file status di satu tempat.

Variabel

Semua nilai resource disimpan sebagai variabel lingkungan. Variabel ini disimpan (sebagai pernyataan ekspor) dalam file bernama vars.sh yang berada di bucket GCS dalam project admin terraform. File ini berisi ID organisasi, akun penagihan, ID project, detail cluster GKE, dll. Anda dapat mendownload dan mengambil vars.sh dari terminal mana pun untuk mendapatkan nilai bagi penyiapan Anda.

Variabel Terraform disimpan di vars.sh sebagai TF_VAR_[variable name]. Variabel ini digunakan untuk menghasilkan file variables.tfvars di folder resource masing-masing. File variables.tfvars berisi semua variabel dengan nilainya. File variables.tfvars dibuat dari file template di folder yang sama menggunakan skrip (terletak di scripts/setup_terraform_admin_project).

Penjelasan Repo K8s

k8s_repo adalah repo CSR (terpisah dari repo infrastruktur) yang berada di project admin Terraform. Digunakan untuk menyimpan dan menerapkan manifes GKE ke semua cluster GKE. k8s_repo dibuat oleh infrastruktur Cloud Build (lihat bagian sebelumnya untuk mengetahui detailnya). Selama proses Cloud Build infrastruktur awal, total enam cluster GKE dibuat. Di k8s_repo, enam folder dibuat. Setiap folder (nama yang cocok dengan nama cluster GKE) sesuai dengan cluster GKE yang berisi file manifes resource masing-masing. Mirip dengan membangun infrastruktur, Cloud Build digunakan untuk menerapkan manifes Kubernetes ke semua cluster GKE menggunakan k8s_repo. Cloud Build dipicu setiap kali ada commit ke repo k8s_repo. Mirip dengan infrastruktur, semua manifes Kubernetes disimpan sebagai kode di repositori k8s_repo dan status setiap cluster GKE selalu disimpan di folder masing-masing.

Sebagai bagian dari pembuatan infrastruktur awal, k8s_repo dibuat dan Istio diinstal di semua cluster.

Project, cluster GKE, dan namespace

Resource dalam workshop ini dibagi ke dalam project GCP yang berbeda. Project harus sesuai dengan struktur organisasi (atau tim) perusahaan Anda. Tim (di organisasi Anda) yang bertanggung jawab atas berbagai project/produk/resource menggunakan project GCP yang berbeda. Dengan memiliki project terpisah, Anda dapat membuat kumpulan izin IAM terpisah dan mengelola penagihan di tingkat project. Selain itu, kuota juga dikelola di tingkat project.

Lima tim diwakili dalam workshop ini, masing-masing dengan projectnya sendiri.

1. Tim infrastruktur yang membangun resource GCP menggunakan Terraform admin project. Mereka mengelola infrastruktur sebagai kode di repo CSR (disebut infrastructure) dan menyimpan semua informasi status Terraform yang berkaitan dengan resource yang dibangun di GCP dalam bucket GCS. Mereka mengontrol akses ke repo CSR dan bucket GCS status Terraform.
2. Tim jaringan yang membangun VPC bersama menggunakan host project. Project ini berisi VPC, subnet, rute, dan aturan firewall. Dengan VPC bersama, mereka dapat mengelola jaringan untuk resource GCP secara terpusat. Semua project menggunakan satu VPC bersama ini untuk jaringan.
3. Tim ops/platform yang membangun cluster GKE dan bidang kontrol ASM/Istio menggunakan ops project. Mereka mengelola siklus proses cluster GKE dan mesh layanan. Mereka bertanggung jawab untuk memperkuat cluster, mengelola ketahanan dan skala platform Kubernetes. Dalam workshop ini, Anda akan menggunakan metode gitops untuk men-deploy resource ke Kubernetes. Repo CSR (disebut k8s_repo) ada di project ops.
4. Terakhir, tim dev1 dan dev2 (mewakili dua tim pengembangan) yang membuat aplikasi menggunakan dev1 dan dev2 projects mereka sendiri. Ini adalah aplikasi dan layanan yang Anda berikan kepada pelanggan. Aplikasi ini dibangun di platform yang dikelola tim operasi. Resource (Deployment, Layanan, dll.) didorong ke k8s_repo dan di-deploy ke cluster yang sesuai. Penting untuk diperhatikan bahwa workshop ini tidak berfokus pada praktik terbaik dan alat CI/CD. Anda menggunakan Cloud Build untuk mengotomatiskan deployment resource Kubernetes ke cluster GKE secara langsung. Dalam skenario produksi di dunia nyata, Anda akan menggunakan solusi CI/CD yang tepat untuk men-deploy aplikasi ke cluster GKE.

Ada dua jenis cluster GKE dalam workshop ini.

1. Cluster operasi - digunakan oleh tim operasi untuk menjalankan alat devops. Dalam workshop ini, mereka menjalankan bidang kontrol ASM/Istio untuk mengelola mesh layanan.
2. Cluster aplikasi (apps) - digunakan oleh tim pengembangan untuk menjalankan aplikasi. Dalam workshop ini, aplikasi Hipster Shop digunakan.

Dengan memisahkan alat ops/admin dari cluster yang menjalankan aplikasi, Anda dapat mengelola siklus proses setiap resource secara independen. Kedua jenis cluster ini juga ada di project yang berbeda yang terkait dengan tim/produk yang menggunakannya, sehingga izin IAM juga lebih mudah dikelola.

Ada total enam cluster GKE. Dua cluster ops regional dibuat di project ops. Bidang kontrol ASM/Istio diinstal di kedua cluster ops. Setiap cluster operasi berada di region yang berbeda. Selain itu, ada empat cluster aplikasi zonal. Ini dibuat di project mereka sendiri. Workshop ini menyimulasikan dua tim pengembangan yang masing-masing memiliki project sendiri. Setiap project berisi dua cluster aplikasi. Cluster aplikasi adalah cluster zonal di zona yang berbeda. Empat cluster aplikasi berada di dua region dan empat zona. Dengan cara ini, Anda mendapatkan redundansi regional dan zona.

Aplikasi yang digunakan dalam workshop ini, aplikasi Hipster Shop, di-deploy di keempat cluster aplikasi. Setiap microservice berada di namespace-nya sendiri di setiap cluster aplikasi. Deployment (Pod) aplikasi toko hipster tidak di-deploy di cluster ops. Namun, namespace dan resource Layanan untuk semua microservice juga dibuat di cluster ops. Bidang kontrol ASM/Istio menggunakan pendaftaran layanan Kubernetes untuk penemuan layanan. Jika tidak ada Layanan (di cluster ops), Anda harus membuat ServiceEntry secara manual untuk setiap layanan yang berjalan di cluster aplikasi.

Anda akan men-deploy aplikasi microservice 10 tingkat dalam workshop ini. Aplikasi ini adalah aplikasi e-commerce berbasis web yang disebut "Hipster Shop", tempat pengguna dapat menjelajahi item, menambahkannya ke keranjang, dan membelinya.

Manifes Kubernetes dan k8s_repo

Anda menggunakan k8s_repo untuk menambahkan resource Kubernetes ke semua cluster GKE. Anda melakukannya dengan menyalin manifes Kubernetes dan melakukan commit ke k8s_repo. Semua commit ke k8s_repo memicu tugas Cloud Build yang men-deploy manifes Kubernetes ke cluster masing-masing. Manifes setiap cluster berada di folder terpisah yang diberi nama sama dengan nama cluster.

Enam nama cluster tersebut adalah:

1. gke-asm-1-r1-prod - cluster operasi regional di region 1
2. gke-asm-2-r2-prod - cluster operasi regional di region 2
3. gke-1-apps-r1a-prod - cluster aplikasi di zona a region 1
4. gke-2-apps-r1b-prod - cluster aplikasi di zona b region 1
5. gke-3-apps-r2a-prod - cluster aplikasi di zona a region 2
6. gke-4-apps-r2b-prod - cluster aplikasi di zona b region 2

k8s_repo memiliki folder yang sesuai dengan cluster ini. Manifes apa pun yang ditempatkan di folder ini akan diterapkan ke cluster GKE yang sesuai. Manifes untuk setiap cluster ditempatkan di subfolder (dalam folder utama cluster) agar mudah dikelola. Dalam workshop ini, Anda akan menggunakan Kustomize untuk melacak resource yang di-deploy. Lihat dokumentasi resmi Kustomize untuk mengetahui detail selengkapnya.

7. Men-deploy Aplikasi Contoh

Tujuan: Men-deploy aplikasi Hipster shop di cluster aplikasi

• Clone k8s-repo
• Salin manifes Hipster Shop ke semua cluster aplikasi
• Buat Layanan untuk aplikasi Hipster shop di cluster ops
• Siapkan loadgenerators di cluster ops untuk menguji konektivitas global
• Memverifikasi konektivitas yang aman ke aplikasi Hipster shop

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/deploy-sample-app.sh

Petunjuk Lab Metode Salin dan Tempel

Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Meng-clone repositori sumber project ops

Sebagai bagian dari build infrastruktur Terraform awal, k8s-repo sudah dibuat di project ops.

1. Buat direktori kosong untuk repositori git:

mkdir $WORKDIR/k8s-repo
 

2. Inisialisasi repositori git, tambahkan repositori jarak jauh, dan tarik master dari repositori jarak jauh:

cd $WORKDIR/k8s-repo
git init && git remote add origin \
https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo
 

3. Menetapkan konfigurasi lokal git lokal.

git config --local user.email $MY_USER
git config --local user.name "K8s repo user"
git config --local \
credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

Menyalin manifes, melakukan commit, dan mengirim

4. Salin namespace dan layanan Hipster Shop ke repositori sumber untuk semua cluster.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/namespaces \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app/services \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/.
 

5. Salin kustomisasi folder aplikasi kustomisasi.yaml ke semua cluster.

cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/
cp $WORKDIR/asm/k8s_manifests/prod/app/kustomization.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/
 

6. Salin Deployment Hipster Shop, RBAC, dan PodSecurityPolicy ke repo sumber untuk cluster aplikasi.

cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/deployments \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/rbac \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/
cp -r $WORKDIR/asm/k8s_manifests/prod/app/podsecuritypolicies \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/

7. Hapus deployment cartservice, rbac, dan podsecuritypolicy dari semua cluster dev kecuali satu. Hipstershop tidak dibuat untuk deployment multi-cluster, jadi untuk menghindari hasil yang tidak konsisten, kita hanya menggunakan satu cartservice.

rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app/rbac/cart-rbac.yaml

rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/deployments/app-cart-service.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/podsecuritypolicies/cart-psp.yaml
rm $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/app/rbac/cart-rbac.yaml
 

8. Tambahkan deployment cartservice, rbac, dan podsecuritypolicy ke kustomization.yaml hanya di cluster dev pertama.

cd ${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app
cd deployments && kustomize edit add resource app-cart-service.yaml
cd ../podsecuritypolicies && kustomize edit add resource cart-psp.yaml
cd ../rbac && kustomize edit add resource cart-rbac.yaml
cd ${WORKDIR}/asm
 

9. Hapus direktori podsecuritypolicies, deployment, dan rbac dari ops clusters kustomization.yaml

sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app/kustomization.yaml
sed -i -e '/- deployments\//d' -e '/- podsecuritypolicies\//d' \
  -e '/- rbac\//d' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app/kustomization.yaml

10. Ganti PROJECT_ID dalam manifes RBAC.

sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev1_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV1_GKE_2_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_1_CLUSTER}/app/rbac/*
sed -i 's/\${PROJECT_ID}/'${TF_VAR_dev2_project_name}'/g' \
${WORKDIR}/k8s-repo/${DEV2_GKE_2_CLUSTER}/app/rbac/*
  

11. Salin manifes IngressGateway dan VirtualService ke repositori sumber untuk cluster ops.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-ingress/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-ingress/* \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-ingress/
 

12. Salin resource Config Connector ke salah satu cluster di setiap project.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/
cp -r $WORKDIR/asm/k8s_manifests/prod/app-cnrm/* \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/
 

13. Ganti PROJECT_ID dalam manifes Config Connector.

sed -i 's/${PROJECT_ID}/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev1_project_name'/g' \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/app-cnrm/*
sed -i 's/${PROJECT_ID}/'$TF_VAR_dev2_project_name'/g' \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/app-cnrm/*
 

14. Salin manifes loadgenerator (Deployment, PodSecurityPolicy, dan RBAC) ke cluster ops. Aplikasi Hipster shop diekspos menggunakan Google Cloud Load Balancer (GCLB) global. GCLB menerima traffic klien (ditujukan ke frontend) dan mengirimkannya ke instance Layanan terdekat. Menempatkan loadgenerator di kedua cluster ops akan memastikan traffic dikirim ke kedua gateway Istio Ingress yang berjalan di cluster ops. Penyeimbangan beban dijelaskan secara mendetail di bagian berikut.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/.
cp -r $WORKDIR/asm/k8s_manifests/prod/app-loadgenerator/. \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/. 
 

15. Ganti ID project ops di manifes loadgenerator untuk kedua cluster ops.

sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g'  \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-deployment.yaml
sed -i 's/OPS_PROJECT_ID/'$TF_VAR_ops_project_name'/g' \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/loadgenerator-rbac.yaml
 

16. Tambahkan resource loadgenerator ke kustomization.yaml untuk kedua cluster operasi.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-loadgenerator/
kustomize edit add resource loadgenerator-psp.yaml
kustomize edit add resource loadgenerator-rbac.yaml
kustomize edit add resource loadgenerator-deployment.yaml
 

17. Lakukan komitmen ke k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "create app namespaces and install hipster shop"
git push --set-upstream origin master 
 

18. Lihat status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
  

Memverifikasi deployment Aplikasi

19. Pastikan pod di semua namespace aplikasi kecuali keranjang dalam status Berjalan di semua cluster dev.

for ns in ad checkout currency email frontend payment product-catalog recommendation shipping; do
  kubectl --context $DEV1_GKE_1 get pods -n $ns;
  kubectl --context $DEV1_GKE_2 get pods -n $ns;
  kubectl --context $DEV2_GKE_1 get pods -n $ns;
  kubectl --context $DEV2_GKE_2 get pods -n $ns;
done;
 

Output (do not copy)

NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-pvc6s   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-xlkl9   2/2     Running   0          13m
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-zdjkg   2/2     Running   0          115s
NAME                               READY   STATUS    RESTARTS   AGE
currencyservice-5c5b8876db-l748q   2/2     Running   0          82s

NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-gk92n   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-rvzk9   2/2     Running   0          13m
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-mt925   2/2     Running   0          117s
NAME                            READY   STATUS    RESTARTS   AGE
emailservice-588467b8c8-klqn7   2/2     Running   0          84s

NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-kkq7d   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-lwskf   2/2     Running   0          13m
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-zz7xs   2/2     Running   0          118s
NAME                        READY   STATUS    RESTARTS   AGE
frontend-64b94cf46f-2vtw5   2/2     Running   0          85s

NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-df8ml   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-bdcvg   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-jqf28   2/2     Running   0          117s
NAME                              READY   STATUS    RESTARTS   AGE
paymentservice-777f6c74f8-95x2m   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-q5g9p   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-n6lp8   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-gf9xl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
productcatalogservice-786dc84f84-v7cbr   2/2     Running   0          86s

NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-2ltrk   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-dqd55   2/2     Running   0          13m
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-jghcl   2/2     Running   0          119s
NAME                                     READY   STATUS    RESTARTS   AGE
recommendationservice-5fdf959f6b-kkspz   2/2     Running   0          87s

NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-qqd9n   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-xczg5   2/2     Running   0          13m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-wfgfr   2/2     Running   0          2m
NAME                              READY   STATUS    RESTARTS   AGE
shippingservice-7bd5f569d-r6t8v   2/2     Running   0          88s

20. Verifikasi bahwa pod di namespace keranjang belanja berada dalam status Berjalan hanya di cluster dev pertama.

kubectl --context $DEV1_GKE_1 get pods -n cart;
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
cartservice-659c9749b4-vqnrd   2/2     Running   0          17m

Mengakses aplikasi Hipster Shop

Load balancing global

Sekarang Anda telah men-deploy aplikasi Hipster Shop ke keempat cluster aplikasi. Cluster ini berada di dua region dan empat zona. Klien dapat mengakses aplikasi Hipster Shop dengan mengakses layanan frontend. Layanan frontend berjalan di keempat cluster aplikasi. Load Balancer Google Cloud ( GCLB) digunakan untuk mengarahkan traffic klien ke keempat instance layanan frontend.

Gateway Istio Ingress hanya berjalan di cluster ops dan bertindak sebagai load balancer regional untuk dua cluster aplikasi zonal dalam region. GCLB menggunakan dua gateway traffic masuk Istio (yang berjalan di dua cluster ops) sebagai backend ke layanan frontend global. Gateway Istio Ingress menerima traffic klien dari GCLB, lalu mengirimkan traffic klien ke Pod frontend yang berjalan di cluster aplikasi.

Atau, Anda dapat menempatkan gateway Istio Ingress langsung di cluster aplikasi dan GCLB dapat menggunakannya sebagai backend.

Pengontrol Autoneg GKE

Layanan Kubernetes gateway Istio Ingress mendaftarkan dirinya sebagai backend ke GCLB menggunakan Grup Endpoint Jaringan (NEG). NEG memungkinkan load balancing berbasis container menggunakan GCLB. NEG dibuat melalui anotasi khusus pada Layanan Kubernetes, sehingga dapat mendaftarkan dirinya ke Pengontrol NEG. Pengontrol Autoneg adalah pengontrol GKE khusus yang mengotomatiskan pembuatan NEG serta menetapkannya sebagai backend ke GCLB menggunakan anotasi Layanan. Bidang kontrol Istio, termasuk gateway ingress Istio, di-deploy selama Build Cloud Terraform infrastruktur awal. Konfigurasi GCLB dan autoneg dilakukan sebagai bagian dari Cloud Build infrastruktur Terraform awal.

Mengamankan Ingress menggunakan Cloud Endpoints dan sertifikat terkelola

Sertifikat yang Dikelola GCP digunakan untuk mengamankan traffic klien ke layanan GCLB frontend. GCLB menggunakan sertifikat terkelola untuk layanan frontend global dan sertifikat dihentikan di GCLB. Dalam workshop ini, Anda akan menggunakan Cloud Endpoints sebagai domain untuk sertifikat terkelola. Atau, Anda dapat menggunakan domain dan nama DNS untuk frontend guna membuat sertifikat terkelola GCP.

21. Untuk mengakses toko Hipster, klik output link dari perintah berikut.

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

22. Anda dapat memeriksa apakah sertifikat valid dengan mengklik simbol gembok di kolom URL tab Chrome Anda.

Memverifikasi load balancing global

Sebagai bagian dari deployment aplikasi, generator beban di-deploy di kedua cluster ops yang menghasilkan traffic pengujian ke link Cloud Endpoints toko Hipster GCLB. Pastikan GCLB menerima traffic dan mengirim ke kedua gateway Istio Ingress.

23. Dapatkan link GCLB > Monitoring untuk project operasi tempat GCLB toko Hipster dibuat.

echo "https://console.cloud.google.com/net-services/loadbalancing/details/http/istio-ingressgateway?project=$TF_VAR_ops_project_name&cloudshell=false&tab=monitoring&duration=PT1H" 
 

24. Ubah dari All backends menjadi istio-ingressgateway dari menu drop-down Backend seperti yang ditunjukkan di bawah.

25. Perhatikan traffic yang menuju ke kedua istio-ingressgateways.

Ada tiga NEG yang dibuat per istio-ingressgateway. Karena cluster ops adalah cluster regional, satu NEG dibuat untuk setiap zona di region. Namun, Pod istio-ingressgateway berjalan di satu zona per region. Traffic ditampilkan menuju ke Pod istio-ingressgateway.

Generator beban berjalan di kedua cluster ops yang menyimulasikan traffic klien dari dua region tempat generator beban berada. Beban yang dihasilkan di region 1 cluster ops dikirim ke istio-ingressgateway di region 2. Demikian juga, beban yang dihasilkan di region 2 cluster ops dikirim ke istio-ingressgateway di region 2.

8. Kemampuan Observasi dengan Stackdriver

Tujuan: Menghubungkan telemetri Istio ke Stackdriver dan memvalidasinya.

• Menginstal resource istio-telemetry
• Membuat/memperbarui dasbor Layanan Istio
• Melihat log container
• Melihat tracing terdistribusi di Stackdriver

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/observability-with-stackdriver.sh

Petunjuk Lab Metode Salin dan Tempel

Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Salah satu fitur utama Istio adalah kemampuan observasi ("o11y") bawaan. Artinya, meskipun dengan container black box yang tidak diinstrumentasi, operator tetap dapat mengamati traffic yang masuk dan keluar dari container ini, sehingga dapat memberikan layanan kepada pelanggan. Pengamatan ini dilakukan dengan beberapa metode yang berbeda: metrik, log, dan rekaman aktivitas.

Kita juga akan memanfaatkan sistem pembuatan beban bawaan di Hipster Shop. Observabilitas tidak berfungsi dengan baik dalam sistem statis tanpa traffic, sehingga pembuatan beban membantu kita melihat cara kerjanya. Pemuatan ini sudah berjalan, sekarang kita hanya akan dapat melihatnya.

1. Instal file konfigurasi istio ke stackdriver.

cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml

cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-telemetry
kustomize edit add resource istio-telemetry.yaml
 

2. Lakukan commit ke k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "Install istio to stackdriver configuration"
git push 
 

3. Lihat status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

4. Verifikasi integrasi Istio → Stackdriver Dapatkan CRD Handler Stackdriver.

kubectl --context $OPS_GKE_1 get handler -n istio-system
 

Output akan menampilkan handler bernama stackdriver:

NAME            AGE
kubernetesenv   12d
prometheus      12d
stackdriver     69s      # <== NEW!

5. Pastikan bahwa Istio mengekspor metrik ke Stackdriver. Klik output link dari perintah ini:

echo "https://console.cloud.google.com/monitoring/metrics-explorer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Anda akan diminta untuk membuat Ruang Kerja baru, yang diberi nama sesuai project Ops, cukup pilih Oke. Jika Anda diminta untuk menggunakan UI baru, tutup saja dialognya.

Di Metrics Explorer, di bagian "Find resource type and metric", masukkan "istio" untuk melihat opsi seperti "Server Request Count" pada jenis resource "Kubernetes Container". Hal ini menunjukkan bahwa metrik mengalir dari mesh ke Stackdriver.

(Anda harus Mengelompokkan Menurut label destination_service_name jika ingin melihat baris di bawah.)

Memvisualisasikan metrik dengan Dasbor:

Sekarang setelah metrik kita berada di sistem Stackdriver APM, kita ingin cara untuk memvisualisasikannya. Di bagian ini, kita akan menginstal dasbor bawaan yang menampilkan tiga dari empat metrik "Sinyal Emas": Traffic (Permintaan per detik), Latensi (dalam hal ini, persentil ke-99 dan ke-50), dan Error (kita tidak menyertakan Kapasitas dalam contoh ini).

Proxy Envoy Istio memberi kita beberapa metrik, tetapi ini adalah kumpulan yang baik untuk memulai. (daftar lengkapnya ada di sini). Perhatikan bahwa setiap metrik memiliki serangkaian label yang dapat digunakan untuk pemfilteran, penggabungan, seperti: destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total, dll.).

6. Sekarang, mari kita tambahkan metrik siap pakai dasbor. Kita akan menggunakan Dashboard API secara langsung. Hal ini biasanya tidak Anda lakukan dengan membuat panggilan API secara manual, tetapi akan menjadi bagian dari sistem otomatisasi, atau Anda akan membuat dasbor secara manual di UI web. Hal ini akan membantu kita memulai dengan cepat:

sed -i 's/OPS_PROJECT/'${TF_VAR_ops_project_name}'/g' \
$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
OAUTH_TOKEN=$(gcloud auth application-default print-access-token)
curl -X POST -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards \
 -d @$WORKDIR/asm/k8s_manifests/prod/app-telemetry/services-dashboard.json
 

7. Buka link output di bawah untuk melihat "Dasbor layanan" yang baru ditambahkan.

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 
 

Kita dapat mengedit dasbor di tempat menggunakan UX, tetapi dalam kasus ini, kita akan menambahkan grafik baru dengan cepat menggunakan API. Untuk melakukannya, Anda harus menarik versi terbaru dasbor, menerapkan pengeditan, lalu mengirimkannya kembali menggunakan metode HTTP PATCH.

8. Anda bisa mendapatkan dasbor yang ada dengan membuat kueri Monitoring API. Dapatkan dasbor yang ada yang baru saja ditambahkan:

curl -X GET -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash > /tmp/services-dashboard.json
 

9. Tambahkan grafik baru: (latensi persentil ke-50): [ Referensi API] Sekarang kita dapat menambahkan widget grafik baru ke dasbor dalam kode. Perubahan ini dapat ditinjau oleh rekan kerja dan diperiksa ke dalam kontrol versi. Berikut adalah widget yang dapat ditambahkan untuk menampilkan latensi persentil ke-50 (latensi median).

Coba edit dasbor yang baru saja Anda dapatkan, dengan menambahkan stanza baru:

NEW_CHART=${WORKDIR}/asm/k8s_manifests/prod/app-telemetry/new-chart.json
jq --argjson newChart "$(<$NEW_CHART)" '.gridLayout.widgets += [$newChart]' /tmp/services-dashboard.json > /tmp/patched-services-dashboard.json
 

10. Perbarui dasbor layanan yang ada:

curl -X PATCH -H "Authorization: Bearer $OAUTH_TOKEN" -H "Content-Type: application/json" \
https://monitoring.googleapis.com/v1/projects/$TF_VAR_ops_project_name/dashboards/servicesdash \
 -d @/tmp/patched-services-dashboard.json
 

11. Lihat dasbor yang diperbarui dengan membuka link output berikut:

echo "https://console.cloud.google.com/monitoring/dashboards/custom/servicesdash?cloudshell=false&project=$TF_VAR_ops_project_name"
 

12. Lakukan Analisis Log sederhana.

Istio menyediakan serangkaian log terstruktur untuk semua traffic jaringan dalam mesh dan menguploadnya ke Stackdriver Logging untuk memungkinkan analisis lintas cluster dalam satu alat yang canggih. Log diberi anotasi dengan metadata tingkat layanan seperti cluster, container, aplikasi, connection_id, dll.

Contoh entri log (dalam hal ini, accesslog proxy Envoy) mungkin terlihat seperti ini (dipangkas):

*** DO NOT PASTE *** 
 logName: "projects/PROJECTNAME-11932-01-ops/logs/server-tcp-accesslog-stackdriver.instance.istio-system" 
labels: {
  connection_id: "fbb46826-96fd-476c-ac98-68a9bd6e585d-1517191"   
  destination_app: "redis-cart"   
  destination_ip: "10.16.1.7"   
  destination_name: "redis-cart-6448dcbdcc-cj52v"   
  destination_namespace: "cart"   
  destination_owner: "kubernetes://apis/apps/v1/namespaces/cart/deployments/redis-cart"   
  destination_workload: "redis-cart"   
  source_ip: "10.16.2.8"   
  total_received_bytes: "539"   
  total_sent_bytes: "569" 
...  
 }

Lihat log Anda di sini:

echo "https://console.cloud.google.com/logs/viewer?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Anda dapat melihat log bidang kontrol Istio dengan memilih Resource > Kubernetes Container, dan menelusuri "pilot" —

Di sini, kita dapat melihat Istio Control Plane mengirimkan konfigurasi proxy ke proxy file bantuan untuk setiap layanan aplikasi contoh. "CDS", "LDS", dan "RDS" mewakili berbagai Envoy API ( informasi selengkapnya).

Selain log Istio, Anda juga dapat menemukan log container serta log infrastruktur atau layanan GCP lainnya dalam antarmuka yang sama. Berikut beberapa contoh kueri log untuk GKE. Penampil log juga memungkinkan Anda membuat metrik dari log (misalnya: "hitung setiap error yang cocok dengan beberapa string") yang dapat digunakan di dasbor atau sebagai bagian dari pemberitahuan. Log juga dapat di-streaming ke alat analisis lain seperti BigQuery.

Beberapa contoh filter untuk toko hipster:

resource.type="k8s_container" labels.destination_app="productcatalogservice"

resource.type="k8s_container" resource.labels.namespace_name="cart"

13. Lihat Distributed Traces.

Sekarang setelah Anda bekerja dengan sistem terdistribusi, proses pen-debug-an memerlukan alat baru: Distributed Tracing. Alat ini memungkinkan Anda menemukan statistik tentang cara layanan Anda berinteraksi (seperti menemukan peristiwa lambat yang tidak biasa pada gambar di bawah), serta mempelajari rekaman aktivitas sampel mentah untuk menyelidiki detail tentang apa yang sebenarnya terjadi.

Tampilan Linimasa menampilkan semua permintaan dari waktu ke waktu, yang digambarkan berdasarkan latensinya, atau waktu yang dihabiskan antara permintaan awal, melalui stack Hipster, hingga akhirnya merespons pengguna akhir. Semakin tinggi posisi titik, semakin lambat (dan kurang menyenangkan!) pengalaman pengguna.

Anda dapat mengklik titik untuk menemukan Tampilan Waterfall mendetail dari permintaan tertentu tersebut. Kemampuan untuk menemukan detail mentah dari permintaan tertentu (bukan hanya statistik gabungan) ini sangat penting untuk memahami interaksi antarlayanan, terutama saat melacak interaksi antarlayanan yang jarang terjadi, tetapi buruk.

Tampilan Waterfall seharusnya sudah tidak asing bagi siapa pun yang pernah menggunakan debugger, tetapi dalam hal ini, alih-alih menampilkan waktu yang dihabiskan dalam berbagai proses satu aplikasi, tampilan ini menampilkan waktu yang dihabiskan untuk melintasi mesh kami, di antara layanan, yang berjalan dalam container terpisah.

Di sini Anda dapat menemukan Rekaman Aktivitas Anda:

echo "https://console.cloud.google.com/traces/overview?cloudshell=false&project=$TF_VAR_ops_project_name"
 

Contoh screenshot alat:

9. Autentikasi TLS Bersama

Tujuan: Mengamankan konektivitas antar-microservice (AuthN).

• Mengaktifkan mTLS lebar mesh
• Memverifikasi mTLS dengan memeriksa log

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/mutual-tls.sh

Petunjuk Lab Metode Salin dan Tempel

Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Setelah aplikasi diinstal dan Observability disiapkan, kita dapat mulai mengamankan koneksi antar-layanan dan memastikan koneksi tersebut tetap berfungsi.

Misalnya, kita dapat melihat di dasbor Kiali bahwa layanan kita tidak menggunakan MTLS (tidak ada ikon "kunci"). Namun, lalu lintas berjalan lancar dan sistem berfungsi dengan baik. Dasbor StackDriver Golden Metrics kami memberi kami ketenangan pikiran bahwa semuanya berjalan dengan baik secara keseluruhan.

1. Periksa MeshPolicy di cluster ops. Perhatikan bahwa mTLS adalah PERMISSIVE yang memungkinkan traffic terenkripsi dan non-mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq '.items[].spec'
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq '.items[].spec'
 

    `Output (do not copy)`

{
  "peers": [
    {
      "mtls": {
        "mode": "PERMISSIVE"
      }
    }
  ]
}

Istio dikonfigurasi di semua cluster menggunakan operator Istio, yang menggunakan resource kustom (CR) IstioControlPlane. Kita akan mengonfigurasi mTLS di semua cluster dengan memperbarui CR IstioControlPlane dan memperbarui k8s-repo. Menetapkan global > mTLS > enabled: true di CR IstioControlPlane akan menghasilkan dua perubahan berikut pada bidang kontrol Istio:

• MeshPolicy disetel untuk mengaktifkan mTLS di seluruh mesh untuk semua Service yang berjalan di semua cluster.
• DestinationRule dibuat untuk mengizinkan traffic ISTIO_MUTUAL antara Layanan yang berjalan di semua cluster.

2. Kita akan menerapkan patch kustomisasi ke CR istioControlPlane untuk mengaktifkan mTLS di seluruh cluster. Salin patch ke direktori yang relevan untuk semua cluster dan tambahkan patch kustomisasi.

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-replicated.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV1_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_1_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml

cp -r $WORKDIR/asm/k8s_manifests/prod/app-mtls/mtls-kustomize-patch-shared.yaml \
$WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane/mtls-kustomize-patch.yaml
cd $WORKDIR/k8s-repo/$DEV2_GKE_2_CLUSTER/istio-controlplane
kustomize edit add patch mtls-kustomize-patch.yaml
 

3. Lakukan commit ke k8s-repo.

cd $WORKDIR/k8s-repo
git add . && git commit -am "turn mTLS on"
git push
 

4. Lihat status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"

 

Verifikasi mTLS

5. Periksa MeshPolicy sekali lagi di cluster ops. Perhatikan bahwa mTLS tidak lagi PERMISSIVE dan hanya akan mengizinkan traffic mTLS.

kubectl --context $OPS_GKE_1 get MeshPolicy -o json | jq .items[].spec
kubectl --context $OPS_GKE_2 get MeshPolicy -o json | jq .items[].spec
 

Output (jangan disalin):

{
  "peers": [
    {
      "mtls": {}
    }
  ]
}

6. Jelaskan DestinationRule yang dibuat oleh pengontrol operator Istio.

kubectl --context $OPS_GKE_1 get DestinationRule default -n istio-system -o json | jq '.spec'
kubectl --context $OPS_GKE_2 get DestinationRule default -n istio-system -o json | jq '.spec'

Output (jangan disalin):

{
    host: '*.local',
    trafficPolicy: {
      tls: {
        mode: ISTIO_MUTUAL
      }
   }
}

Kita juga dapat melihat perpindahan dari HTTP ke HTTPS di log.

Kita dapat mengekspos kolom tertentu ini dari log di UI dengan mengklik satu entri log, lalu mengklik nilai kolom yang ingin ditampilkan. Dalam kasus ini, klik "http" di samping "protocol":

Hal ini menghasilkan cara yang bagus untuk memvisualisasikan peralihan.:

10. Deployment Canary

Tujuan: Meluncurkan versi baru Layanan frontend.

• Peluncuran frontend-v2 (versi produksi berikutnya) Layanan di satu region
• Gunakan DestinationRules dan VirtualServices untuk mengarahkan traffic secara perlahan ke frontend-v2
• Verifikasi pipeline deployment GitOps dengan memeriksa serangkaian commit ke k8s-repo

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/canary-deployments.sh

Petunjuk Lab Metode Salin dan Tempel

Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Deployment canary adalah peluncuran progresif layanan baru. Dalam deployment terbatas, Anda mengirimkan peningkatan jumlah traffic ke versi baru, sambil tetap mengirimkan persentase yang tersisa ke versi saat ini. Pola umum adalah melakukan analisis canary di setiap tahap pemisahan traffic, dan membandingkan "sinyal emas" versi baru (latensi, rasio error, saturasi) dengan dasar pengukuran. Hal ini membantu mencegah gangguan, dan memastikan stabilitas layanan "v2" baru di setiap tahap pembagian traffic.

Di bagian ini, Anda akan mempelajari cara menggunakan kebijakan traffic Cloud Build dan Istio untuk membuat deployment canary dasar untuk versi baru layanan frontend.

Pertama, kita akan menjalankan pipeline Canary di region DEV1 (us-west1), dan meluncurkan frontend v2 di kedua cluster di region tersebut. Kedua, kita akan menjalankan pipeline Canary di region DEV2 (us-central), dan men-deploy v2 ke kedua cluster di region tersebut. Menjalankan pipeline di berbagai region secara berurutan, bukan secara paralel di semua region, akan membantu menghindari pemadaman global yang disebabkan oleh konfigurasi yang buruk, atau oleh bug di aplikasi v2 itu sendiri.

Catatan: kita akan memicu pipeline Canary secara manual di kedua region, tetapi dalam produksi, Anda akan menggunakan pemicu otomatis, misalnya berdasarkan tag image Docker baru yang di-push ke registry.

1. Dari Cloud Shell, tentukan beberapa variabel lingkungan untuk menyederhanakan eksekusi perintah lainnya.

CANARY_DIR="$WORKDIR/asm/k8s_manifests/prod/app-canary/"
K8S_REPO="$WORKDIR/k8s-repo"
 

2. Jalankan skrip repo_setup.sh untuk menyalin manifes dasar ke k8s-repo.

$CANARY_DIR/repo-setup.sh 
 

Manifes berikut disalin:

• Deployment frontend-v2
• Patch frontend-v1 (untuk menyertakan label "v1", dan gambar dengan endpoint "/version")
• respy, pod kecil yang akan mencetak distribusi respons HTTP, dan membantu kita memvisualisasikan deployment canary secara real time.
• DestinationRule Istio frontend - membagi Layanan Kubernetes frontend menjadi dua subset, v1 dan v2, berdasarkan label deployment "version"
• VirtualService Istio frontend - merutekan 100% traffic ke frontend v1. Tindakan ini menggantikan perilaku round-robin default Layanan Kubernetes, yang akan segera mengirim 50% dari semua traffic regional Dev1 ke frontend v2.

3. Lakukan perubahan pada k8s_repo:

cd $K8S_REPO 
git add . && git commit -am "frontend canary setup"
git push
 

4. Lihat status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}" 
 

5. Buka Cloud Build di konsol untuk project OPS1. Tunggu hingga pipeline Cloud Build selesai, lalu dapatkan pod di namespace frontend di kedua cluster DEV1. Anda akan melihat berikut ini:

watch -n 1 kubectl --context $DEV1_GKE_1 get pods -n frontend 
 

Output (do not copy)

NAME                           READY   STATUS    RESTARTS   AGE
frontend-578b5c5db6-h9567      2/2     Running   0          59m
frontend-v2-54b74fc75b-fbxhc   2/2     Running   0          2m26s
respy-5f4664b5f6-ff22r         2/2     Running   0          2m26s

Catatan: Ctrl-C untuk keluar dari perintah watch

Kita akan menggunakan tmux untuk membagi jendela cloudshell menjadi 2 panel:

• Panel bawah akan menjalankan perintah watch untuk mengamati distribusi respons HTTP untuk layanan frontend.
• Panel atas akan menjalankan skrip pipeline canary yang sebenarnya.

6. Jalankan perintah untuk membagi jendela cloud shell dan jalankan perintah watch di panel bawah.

RESPY_POD=$(kubectl --context $DEV1_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV1_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Output (jangan disalin)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Kita dapat melihat bahwa semua traffic akan menuju deployment frontend v1, yang ditentukan dalam VirtualService baru.

7. Jalankan pipeline canary di region Dev1. Kami menyediakan skrip yang memperbarui persentase traffic frontend-v2 di VirtualService (memperbarui bobot menjadi 20%, 50%, 80%, lalu 100%). Di antara update, skrip menunggu hingga pipeline Cloud Build selesai. Jalankan skrip deployment canary untuk region Dev1. Catatan - skrip ini memerlukan waktu sekitar 10 menit untuk diselesaikan.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_1_CLUSTER OPS_CONTEXT=$OPS_GKE_1 \
${CANARY_DIR}/auto-canary.sh
 

Anda dapat melihat pembagian traffic secara real time di jendela bawah tempat Anda menjalankan perintah respy. Misalnya, pada tanda 20%:

Output (jangan disalin)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 79.4%             |
|          |                   |
| v2       | 20.6%             |
|          |                   |
+----------+-------------------+

8. Setelah peluncuran Dev2 selesai untuk frontend-v2, Anda akan melihat pesan berhasil di akhir skrip:

    Output (do not copy) 
   

✅ 100% successfully deployed
🌈 frontend-v2 Canary Complete for gke-asm-1-r1-prod

9. Dan semua traffic frontend dari pod Dev2 harus menuju ke frontend-v2:

    Output (do not copy) 
   

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

10. Tutup panel terpisah.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'
 

11. Buka Cloud Source Repos di link yang dibuat.

echo https://source.developers.google.com/p/$TF_VAR_ops_project_name/r/k8s-repo

Anda akan melihat commit terpisah untuk setiap persentase traffic, dengan commit terbaru di bagian atas daftar:

Sekarang, Anda akan mengulangi proses yang sama untuk region Dev2. Perhatikan bahwa region Dev2 masih "dikunci" di v1. Hal ini karena dalam skrip repo_setup dasar, kita mengirim VirtualService untuk secara eksplisit mengirim semua traffic ke v1. Dengan begitu, kami dapat melakukan canary regional dengan aman di Dev1, dan memastikan canary berjalan dengan sukses sebelum meluncurkan versi baru secara global.

12. Jalankan perintah untuk membagi jendela cloud shell dan jalankan perintah watch di panel bawah.

RESPY_POD=$(kubectl --context $DEV2_GKE_1 get pod \
-n frontend -l app=respy -o jsonpath='{..metadata.name}')
export TMUX_SESSION=$(tmux display-message -p '#S')
tmux split-window -d -t $TMUX_SESSION:0 -p33 \
-v "export KUBECONFIG=$WORKDIR/asm/gke/kubemesh; \
kubectl --context $DEV2_GKE_1 exec -n frontend -it \
$RESPY_POD -c respy /bin/sh -- -c 'watch -n 1 ./respy \
--u http://frontend:80/version --c 10 --n 500'; sleep 2"
 

Output (jangan disalin)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

Kita dapat melihat bahwa semua traffic akan menuju deployment frontend v1, yang ditentukan dalam VirtualService baru.

13. Jalankan pipeline canary di region Dev2. Kami menyediakan skrip yang memperbarui persentase traffic frontend-v2 di VirtualService (memperbarui bobot menjadi 20%, 50%, 80%, lalu 100%). Di antara update, skrip menunggu hingga pipeline Cloud Build selesai. Jalankan skrip deployment canary untuk region Dev1. Catatan - skrip ini memerlukan waktu sekitar 10 menit untuk diselesaikan.

K8S_REPO=$K8S_REPO CANARY_DIR=$CANARY_DIR \
OPS_DIR=$OPS_GKE_2_CLUSTER OPS_CONTEXT=$OPS_GKE_2 \
${CANARY_DIR}/auto-canary.sh
 

Output (jangan disalin)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v1       | 100.0%            |
|          |                   |
+----------+-------------------+

14. Dari pod Respy di Dev2, amati traffic dari pod Dev2 yang bergerak secara progresif dari frontend v1 ke v2. Setelah skrip selesai, Anda akan melihat:

Output (jangan disalin)

500 requests to http://frontend:80/version...
+----------+-------------------+
| RESPONSE | % OF 500 REQUESTS |
+----------+-------------------+
| v2       | 100.0%            |
|          |                   |
+----------+-------------------+

15. Tutup panel terpisah.

tmux respawn-pane -t ${TMUX_SESSION}:0.1 -k 'exit'

Bagian ini memperkenalkan cara menggunakan Istio untuk deployment canary regional. Dalam produksi, alih-alih skrip manual, Anda dapat memicu skrip uji coba ini secara otomatis sebagai pipeline Cloud Build, menggunakan pemicu seperti image baru yang diberi tag dan dikirim ke registry container. Anda juga sebaiknya menambahkan analisis canary di antara setiap langkah, menganalisis latensi dan rasio error v2 terhadap nilai minimum keamanan yang telah ditentukan sebelumnya, sebelum mengirimkan lebih banyak traffic.

11. Kebijakan Otorisasi

Tujuan: Menyiapkan RBAC antar-microservice (AuthZ).

• Membuat AuthorizationPolicy untuk MENOLAK akses ke microservice
• Buat AuthorizationPolicy untuk MENGIZINKAN akses tertentu ke microservice

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/authorization-policy.sh

Petunjuk Lab Metode Salin dan Tempel

Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global melakukan panggilan di seluruh batas jaringan. Artinya, ada lebih banyak titik masuk ke aplikasi Anda, dan lebih banyak peluang untuk serangan berbahaya. Karena pod Kubernetes memiliki IP sementara, aturan firewall berbasis IP tradisional tidak lagi memadai untuk mengamankan akses antar-workload. Dalam arsitektur microservice, diperlukan pendekatan baru untuk keamanan. Dengan memanfaatkan blok penyusun keamanan Kubernetes seperti akun layanan, Istio menyediakan serangkaian kebijakan keamanan yang fleksibel untuk aplikasi Anda.

Kebijakan Istio mencakup autentikasi dan otorisasi. Autentikasi memverifikasi identitas (apakah server ini benar-benar server yang diklaim?), dan otorisasi memverifikasi izin (apakah klien ini diizinkan untuk melakukan tindakan tersebut?). Kita telah membahas autentikasi Istio di bagian TLS bersama dalam Modul 1 (MeshPolicy). Di bagian ini, kita akan mempelajari cara menggunakan kebijakan otorisasi Istio untuk mengontrol akses ke salah satu beban kerja aplikasi kita, currencyservice.

Pertama, kita akan men-deploy AuthorizationPolicy di keempat cluster Dev, menutup semua akses ke currencyservice, dan memicu error di frontend. Kemudian, kita hanya akan mengizinkan layanan frontend mengakses currencyservice.

1. Periksa konten currency-deny-all.yaml. Kebijakan ini menggunakan pemilih label Deployment untuk membatasi akses ke currencyservice. Perhatikan bahwa tidak ada kolom spec - artinya kebijakan ini akan menolak semua akses ke layanan yang dipilih.

cat $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml
 

Output (jangan disalin)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice

2. Salin kebijakan mata uang ke k8s-repo, untuk cluster operasi di kedua region.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-deny-all.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
cd $WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization
kustomize edit add resource currency-policy.yaml

3. Mendorong perubahan.

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: deny all"
git push 

4. Periksa status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name 
 

5. Setelah build berhasil diselesaikan, coba buka frontend hipstershop di browser melalui link berikut:

echo "https://frontend.endpoints.$TF_VAR_ops_project_name.cloud.goog" 
 

Anda akan melihat error Otorisasi dari currencyservice:

6. Mari kita selidiki cara layanan mata uang menerapkan AuthorizationPolicy ini. Pertama, aktifkan log tingkat pelacakan di proxy Envoy untuk salah satu pod mata uang, karena panggilan otorisasi yang diblokir tidak dicatat ke log secara default.

CURRENCY_POD=$(kubectl --context $DEV1_GKE_2 get pod -n currency | grep currency| awk '{ print $1 }')
kubectl --context $DEV1_GKE_2 exec -it $CURRENCY_POD -n \
currency -c istio-proxy -- curl -X POST \
"http://localhost:15000/logging?level=trace"
 

7. Dapatkan log RBAC (otorisasi) dari proxy sidecar layanan mata uang. Anda akan melihat pesan "enforced denied", yang menunjukkan bahwa currencyservice disetel untuk memblokir semua permintaan masuk.

kubectl --context $DEV1_GKE_2 logs -n currency $CURRENCY_POD \
-c istio-proxy | grep -m 3 rbac
 

Output (jangan disalin)

[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:67] checking request: remoteAddress: 10.16.5.15:37310, localAddress: 10.16.3.8:7000, ssl: uriSanPeerCertificate: spiffe://cluster.local/ns/frontend/sa/frontend, subjectPeerCertificate: , headers: ':method', 'POST'
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][rbac] [external/envoy/source/extensions/filters/http/rbac/rbac_filter.cc:118] enforced denied
[Envoy (Epoch 0)] [2020-01-30 00:45:50.815][22][debug][http] [external/envoy/source/common/http/conn_manager_impl.cc:1354] [C115][S17310331589050212978] Sending local reply with details rbac_access_denied

8. Sekarang, mari kita izinkan frontend – tetapi bukan layanan backend lainnya – untuk mengakses currencyservice. Buka currency-allow-frontend.yaml dan periksa isinya. Perhatikan bahwa kami telah menambahkan aturan berikut:

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml

Output (jangan disalin)

rules:
 - from:
   - source:
       principals: ["cluster.local/ns/frontend/sa/frontend"]

Di sini, kita memberikan akses ke source.principal (klien) tertentu untuk mengakses layanan mata uang. source.principal ini ditentukan oleh Akun Layanan Kubernetes. Dalam hal ini, akun layanan yang kami masukkan dalam daftar yang diizinkan adalah akun layanan frontend di namespace frontend.

Catatan: saat menggunakan Akun Layanan Kubernetes di AuthorizationPolicies Istio, Anda harus mengaktifkan TLS bersama di seluruh cluster terlebih dahulu, seperti yang kita lakukan di Modul 1. Hal ini untuk memastikan bahwa kredensial akun layanan dipasang ke dalam permintaan.

9. Menyalin kebijakan mata uang yang diperbarui

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

10. Mendorong perubahan.

cd $WORKDIR/k8s-repo
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend"
git push
 

11. Lihat status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name

12. Setelah build berhasil diselesaikan, buka lagi frontend Hipstershop. Kali ini Anda tidak akan melihat error di halaman beranda - hal ini karena frontend secara eksplisit diizinkan untuk mengakses layanan saat ini.
13. Sekarang, coba lakukan checkout, dengan menambahkan item ke keranjang dan mengklik "lakukan pemesanan". Kali ini, Anda akan melihat error konversi harga dari layanan mata uang - hal ini karena kita hanya memasukkan frontend ke dalam daftar yang diizinkan, sehingga checkoutservice masih tidak dapat mengakses currencyservice.

14. Terakhir, izinkan layanan checkout mengakses mata uang, dengan menambahkan aturan lain ke AuthorizationPolicy currencyservice kami. Perhatikan bahwa kami hanya membuka akses mata uang ke dua layanan yang perlu mengaksesnya - frontend dan checkout. Backend lainnya akan tetap diblokir.
15. Buka currency-allow-frontend-checkout.yaml dan periksa isinya. Perhatikan bahwa daftar aturan berfungsi sebagai OR logis - mata uang hanya akan menerima permintaan dari beban kerja dengan salah satu dari dua akun layanan ini.

cat ${WORKDIR}/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml
 

Output (jangan disalin)

apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: "currency-policy"
  namespace: currency
spec:
  selector:
    matchLabels:
      app: currencyservice
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/frontend/sa/frontend"]
  - from:
    - source:
        principals: ["cluster.local/ns/checkout/sa/checkout"]

16. Salin kebijakan otorisasi akhir ke k8s-repo.

cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_1_CLUSTER/app-authorization/currency-policy.yaml
cp $WORKDIR/asm/k8s_manifests/prod/app-authorization/currency-allow-frontend-checkout.yaml \
$WORKDIR/k8s-repo/$OPS_GKE_2_CLUSTER/app-authorization/currency-policy.yaml
 

17. Mendorong perubahan

cd $WORKDIR/k8s-repo 
git add . && git commit -am "AuthorizationPolicy - currency: allow frontend and checkout"
git push
 

18. Lihat status Cloud Build project Ops di tab yang dibuka sebelumnya atau dengan mengklik link berikut:

echo https://console.cloud.google.com/cloud-build/builds?project=$TF_VAR_ops_project_name
 

19. Setelah build berhasil diselesaikan, coba jalankan checkout - seharusnya berhasil.

Bagian ini membahas cara menggunakan Kebijakan Otorisasi Istio untuk menerapkan kontrol akses terperinci di tingkat per layanan. Dalam produksi, Anda dapat membuat satu AuthorizationPolicy per layanan, dan (misalnya) menggunakan kebijakan izinkan semua untuk mengizinkan semua workload dalam namespace yang sama saling mengakses.

12. Penskalaan Infrastruktur

Tujuan: Menskalakan infrastruktur dengan menambahkan wilayah, project, dan cluster baru.

• Meng-clone repo infrastructure
• Perbarui file terraform untuk membuat resource baru
• 2 subnet di region baru (satu untuk project ops dan satu untuk project baru)
• Cluster ops baru di region baru (di subnet baru)
• Bidang kontrol Istio baru untuk region baru
• 2 cluster aplikasi di project baru di region baru
• Lakukan commit ke repo infrastructure
• Verifikasi penginstalan

SKRIP JALUR CEPAT

Jika Anda memilih metode ini, jalankan skrip berikut untuk menyelesaikan lab ini.

${WORKDIR}/asm/fasttrack_scripts/infrastructure-scaling.sh

Petunjuk Lab Metode Salin dan Tempel

Jika Anda telah menyelesaikan skrip jalur cepat untuk lab ini, jangan lakukan metode salin dan tempel di bawah**.**

Ada beberapa cara untuk menskalakan platform. Anda dapat menambahkan lebih banyak komputasi dengan menambahkan node ke cluster yang ada. Anda dapat menambahkan lebih banyak cluster di suatu region. Atau, Anda dapat menambahkan lebih banyak wilayah ke platform. Keputusan tentang aspek platform yang akan diskalakan bergantung pada persyaratan. Misalnya, jika Anda memiliki cluster di ketiga zona dalam suatu region, mungkin menambahkan lebih banyak node (atau node pool) ke cluster yang ada sudah cukup. Namun, jika Anda memiliki cluster di dua dari tiga zona dalam satu region, menambahkan cluster baru di zona ketiga akan memberi Anda penskalaan dan domain kesalahan tambahan (yaitu zona baru). Alasan lain untuk menambahkan cluster baru di suatu region mungkin adalah kebutuhan untuk membuat cluster tenant tunggal - karena alasan peraturan atau kepatuhan (misalnya PCI, atau cluster database yang menyimpan informasi PII). Seiring berkembangnya bisnis dan layanan Anda, penambahan wilayah baru menjadi tak terhindarkan untuk memberikan layanan yang lebih dekat dengan klien.

Platform saat ini terdiri dari dua region dan cluster di dua zona per region. Anda dapat memikirkan penskalaan platform dengan dua cara:

• Secara vertikal - dalam setiap region dengan menambahkan lebih banyak komputasi. Hal ini dilakukan dengan menambahkan lebih banyak node (atau node pool) ke cluster yang ada atau dengan menambahkan cluster baru dalam region. Tindakan ini dilakukan melalui repo infrastructure. Cara paling sederhana adalah menambahkan node ke cluster yang ada. Tindakan ini tidak memerlukan konfigurasi tambahan. Menambahkan cluster baru mungkin memerlukan subnet tambahan (dan rentang sekunder), menambahkan aturan firewall yang sesuai, menambahkan cluster baru ke bidang kontrol mesh layanan ASM/Istio regional, dan men-deploy resource aplikasi ke cluster baru.
• Secara horizontal - dengan menambahkan lebih banyak wilayah. Platform saat ini memberi Anda template regional. Arsitektur ini terdiri dari cluster operasi regional tempat bidang kontrol ASM/Istio berada dan dua (atau lebih) cluster aplikasi zona tempat resource aplikasi di-deploy.

Dalam workshop ini, Anda akan menskalakan platform secara "horizontal" karena mencakup langkah-langkah kasus penggunaan vertikal juga. Untuk menskalakan platform secara horizontal dengan menambahkan region baru (r3) ke platform, resource berikut perlu ditambahkan:

1. Subnet di VPC bersama project host di region r3 untuk cluster operasi dan aplikasi baru.
2. Cluster operasi regional di region r3 tempat bidang kontrol ASM/Istio berada.
3. Dua cluster aplikasi zonal di dua zona pada region r3.
4. Update ke k8s-repo:
5. Deploy resource bidang kontrol ASM/Istio ke cluster ops di region r3.
6. Deploy resource bidang kontrol bersama ASM/Istio ke cluster aplikasi di region r3.
7. Meskipun Anda tidak perlu membuat project baru, langkah-langkah dalam workshop menunjukkan cara menambahkan project dev3 baru untuk mencakup kasus penggunaan penambahan tim baru ke platform.

Repositori infrastruktur digunakan untuk menambahkan resource baru yang disebutkan di atas.

1. Di Cloud Shell, buka WORKDIR dan clone repo infrastructure.

mkdir -p $WORKDIR/infra-repo
cd $WORKDIR/infra-repo
git init && git remote add origin https://source.developers.google.com/p/${TF_ADMIN}/r/infrastructure
git config --local user.email ${MY_USER}
git config --local user.name "infra repo user"
git config --local credential.'https://source.developers.google.com'.helper gcloud.sh
git pull origin master

2. Buat clone cabang add-proj repositori sumber workshop ke direktori add-proj-repo.

cd $WORKDIR
git clone https://github.com/GoogleCloudPlatform/anthos-service-mesh-workshop.git add-proj-repo -b add-proj

 

3. Salin file dari cabang add-proj di repo workshop sumber. Cabang add-proj berisi perubahan untuk bagian ini.

cp -r $WORKDIR/add-proj-repo/infrastructure/* $WORKDIR/infra-repo/
 

4. Ganti direktori infrastructure di direktori repo add-proj dengan symlink ke direktori infra-repo agar skrip di cabang dapat berjalan.

rm -rf $WORKDIR/add-proj-repo/infrastructure
ln -s $WORKDIR/infra-repo $WORKDIR/add-proj-repo/infrastructure
 

5. Jalankan skrip add-project.sh untuk menyalin status dan var bersama ke struktur direktori project baru.

$WORKDIR/add-proj-repo/scripts/add-project.sh app3 $WORKDIR/asm $WORKDIR/infra-repo

6. Menyimpan data (commit) dan mendorong perubahan untuk membuat project baru

cd $WORKDIR/infra-repo
git add .
git status
git commit -m "add new project" && git push origin master
 

7. Penerapan ini memicu repo infrastructure untuk men-deploy infrastruktur dengan resource baru. Lihat progres Cloud Build dengan mengklik output link berikut dan membuka build terbaru di bagian atas.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_ADMIN}"
 

Langkah ini memerlukan waktu 25 - 30 menit untuk diselesaikan. Waktunya istirahat minum kopi.

Langkah terakhir infrastructure Cloud Build membuat resource Kubernetes baru di infrastructure.k8s-repo Tindakan ini akan memicu Cloud Build di k8s-repo (dalam project ops). Resource Kubernetes baru ditujukan untuk tiga cluster baru yang ditambahkan pada langkah sebelumnya. Bidang kontrol ASM/Istio dan resource bidang kontrol bersama ditambahkan ke cluster baru dengan k8s-repo Cloud Build.

8. Setelah Cloud Build infrastruktur berhasil diselesaikan, buka k8s-repo eksekusi Cloud Build terbaru dengan mengklik link output berikut.

echo "https://console.cloud.google.com/cloud-build/builds?project=${TF_VAR_ops_project_name}"
 

9. Jalankan skrip berikut untuk menambahkan cluster baru ke file vars dan kubeconfig.

$WORKDIR/add-proj-repo/scripts/setup-gke-vars-kubeconfig-add-proj.sh $WORKDIR/asm
 

10. Ubah variabel KUBECONFIG agar mengarah ke file kubeconfig baru.

source $WORKDIR/asm/vars/vars.sh
export KUBECONFIG=$WORKDIR/asm/gke/kubemesh
 

11. Cantumkan konteks cluster Anda. Anda akan melihat delapan cluster.

kubectl config view -ojson | jq -r '.clusters[].name'
 

    `Output (do not copy)`

gke_user001-200204-05-dev1-49tqc4_us-west1-a_gke-1-apps-r1a-prod
gke_user001-200204-05-dev1-49tqc4_us-west1-b_gke-2-apps-r1b-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-a_gke-3-apps-r2a-prod
gke_user001-200204-05-dev2-49tqc4_us-central1-b_gke-4-apps-r2b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-b_gke-5-apps-r3b-prod
gke_user001-200204-05-dev3-49tqc4_us-east1-c_gke-6-apps-r3c-prod
gke_user001-200204-05-ops-49tqc4_us-central1_gke-asm-2-r2-prod
gke_user001-200204-05-ops-49tqc4_us-east1_gke-asm-3-r3-prod
gke_user001-200204-05-ops-49tqc4_us-west1_gke-asm-1-r1-prod

Memverifikasi Penginstalan Istio

12. Pastikan Istio diinstal di cluster ops baru dengan memeriksa apakah semua pod berjalan dan tugas telah selesai.

kubectl --context $OPS_GKE_3 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
grafana-5f798469fd-72g6w                  1/1     Running   0          5h12m
istio-citadel-7d8595845-hmmvj             1/1     Running   0          5h12m
istio-egressgateway-779b87c464-rw8bg      1/1     Running   0          5h12m
istio-galley-844ddfc788-zzpkl             2/2     Running   0          5h12m
istio-ingressgateway-59ccd6574b-xfj98     1/1     Running   0          5h12m
istio-pilot-7c8989f5cf-5plsg              2/2     Running   0          5h12m
istio-policy-6674bc7678-2shrk             2/2     Running   3          5h12m
istio-sidecar-injector-7795bb5888-kbl5p   1/1     Running   0          5h12m
istio-telemetry-5fd7cbbb47-c4q7b          2/2     Running   2          5h12m
istio-tracing-cd67ddf8-2qwkd              1/1     Running   0          5h12m
istiocoredns-5f7546c6f4-qhj9k             2/2     Running   0          5h12m
kiali-7964898d8c-l74ww                    1/1     Running   0          5h12m
prometheus-586d4445c7-x9ln6               1/1     Running   0          5h12m

13. Pastikan Istio diinstal di kedua cluster dev3. Hanya Citadel, sidecar-injector, dan coredns yang berjalan di cluster dev3. Cluster ini berbagi bidang kontrol Istio yang berjalan di cluster ops-3.

kubectl --context $DEV3_GKE_1 get pods -n istio-system
kubectl --context $DEV3_GKE_2 get pods -n istio-system
 

    `Output (do not copy)`

NAME                                      READY   STATUS    RESTARTS   AGE
istio-citadel-568747d88-4lj9b             1/1     Running   0          66s
istio-sidecar-injector-759bf6b4bc-ks5br   1/1     Running   0          66s
istiocoredns-5f7546c6f4-qbsqm             2/2     Running   0          78s

Memverifikasi penemuan layanan untuk bidang kontrol bersama

14. Verifikasi bahwa secret di-deploy di semua cluster operasi untuk keenam cluster aplikasi.

kubectl --context $OPS_GKE_1 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_2 get secrets -l istio/multiCluster=true -n istio-system
kubectl --context $OPS_GKE_3 get secrets -l istio/multiCluster=true -n istio-system
 

    `Output (do not copy)`

NAME                  TYPE     DATA   AGE
gke-1-apps-r1a-prod   Opaque   1      14h
gke-2-apps-r1b-prod   Opaque   1      14h
gke-3-apps-r2a-prod   Opaque   1      14h
gke-4-apps-r2b-prod   Opaque   1      14h
gke-5-apps-r3b-prod   Opaque   1      5h12m
gke-6-apps-r3c-prod   Opaque   1      5h12m

13. Pemutusan Koneksi

Tujuan: Menerapkan Pemutus Sirkuit untuk Layanan pengiriman.

• Buat DestinationRule untuk Layanan shipping guna menerapkan pemutus sirkuit
• Gunakan fortio (utilitas pembuatan beban) untuk memvalidasi pemutus sirkuit untuk Layanan shipping dengan memicu sirkuit secara paksa

Petunjuk Lab Skrip Jalur Cepat

Fast Track Script Lab akan segera hadir!!

Petunjuk Lab Metode Salin dan Tempel

Setelah mempelajari beberapa strategi pemantauan dan pemecahan masalah dasar untuk layanan yang mendukung Istio, mari kita lihat bagaimana Istio membantu Anda meningkatkan ketahanan layanan, sehingga mengurangi jumlah pemecahan masalah yang harus Anda lakukan.

Arsitektur microservice menimbulkan risiko kegagalan berjenjang, di mana kegagalan satu layanan dapat menyebar ke dependensinya, dan dependensi dari dependensi tersebut, sehingga menyebabkan gangguan "efek riak" yang berpotensi memengaruhi pengguna akhir. Istio menyediakan kebijakan traffic Circuit Breaker untuk membantu Anda mengisolasi layanan, melindungi layanan downstream (sisi klien) dari menunggu layanan yang gagal, dan melindungi layanan upstream (sisi server) dari banjir traffic downstream secara tiba-tiba saat layanan tersebut kembali online. Secara keseluruhan, penggunaan Pemutus Sirkuit dapat membantu Anda menghindari kegagalan semua layanan dalam memenuhi SLO karena satu layanan backend yang mengalami masalah.

Pola Pemutus Sirkuit dinamai berdasarkan sakelar listrik yang dapat "trip" saat terlalu banyak listrik mengalir, sehingga melindungi perangkat dari kelebihan beban. Dalam penyiapan Istio, ini berarti Envoy adalah pemutus sirkuit, yang melacak jumlah permintaan yang tertunda untuk suatu layanan. Dalam status tertutup default ini, permintaan mengalir melalui Envoy tanpa terganggu.

Namun, saat jumlah permintaan yang tertunda melebihi nilai minimum yang Anda tetapkan, pemutus arus akan aktif (terbuka), dan Envoy akan segera menampilkan error. Hal ini memungkinkan server gagal dengan cepat untuk klien, dan mencegah kode aplikasi server menerima permintaan klien saat kelebihan beban.

Kemudian, setelah waktu tunggu yang Anda tentukan, Envoy akan berpindah ke status setengah terbuka, tempat server dapat mulai menerima permintaan lagi secara percobaan, dan jika dapat merespons permintaan dengan berhasil, pemutus sirkuit akan ditutup lagi, dan permintaan ke server akan mulai mengalir lagi.

Diagram ini merangkum pola pemutus sirkuit Istio. Persegi panjang biru mewakili Envoy, lingkaran yang diisi biru mewakili klien, dan lingkaran yang diisi putih mewakili penampung server:

Anda dapat menentukan kebijakan Circuit Breaker menggunakan DestinationRules Istio. Di bagian ini, kita akan menerapkan kebijakan berikut untuk menerapkan pemutus sirkuit untuk layanan pengiriman:

Output (do not copy)

apiVersion: "networking.istio.io/v1alpha3"
kind: "DestinationRule"
metadata:
  name: "shippingservice-shipping-destrule"
  namespace: "shipping"
spec:
  host: "shippingservice.shipping.svc.cluster.local"
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutiveErrors: 1
      interval: 1s
      baseEjectionTime: 10s
      maxEjectionPercent: 100

Ada dua kolom DestinationRule yang perlu diperhatikan di sini. connectionPool menentukan jumlah koneksi yang akan diizinkan oleh layanan ini. Kolom outlierDetection adalah tempat kita mengonfigurasi cara Envoy akan menentukan nilai minimum untuk membuka pemutus sirkuit. Di sini, setiap detik (interval), Envoy akan menghitung jumlah error yang diterimanya dari penampung server. Jika melebihi batas consecutiveErrors, pemutus sirkuit Envoy akan terbuka, dan 100% pod productcatalog akan terlindung dari permintaan klien baru selama 10 detik. Setelah pemutus arus Envoy terbuka (yaitu aktif), klien akan menerima error 503 (Layanan Tidak Tersedia). Mari kita lihat bagaimana penerapannya.

1. Tetapkan variabel lingkungan untuk direktori k8s-repo dan asm guna menyederhanakan perintah.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm" 
 

2. Perbarui k8s-repo

cd $WORKDIR/k8s-repo
git pull
cd $WORKDIR

3. Perbarui DestinationRule layanan pengiriman di kedua cluster Ops.

cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cp $ASM/k8s_manifests/prod/istio-networking/app-shipping-circuit-breaker.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml

cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-shipping-circuit-breaker.yaml
 

4. Salin pod generator beban Fortio ke cluster GKE_1 di region Dev1. Ini adalah pod klien yang akan kita gunakan untuk "memicu" pemutus sirkuit untuk shippingservice.

cp $ASM/k8s_manifests/prod/app/deployments/app-fortio.yaml ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments/
cd ${K8S_REPO}/${DEV1_GKE_1_CLUSTER}/app/deployments; kustomize edit add resource app-fortio.yaml
 

5. Lakukan perubahan.

cd $K8S_REPO 
git add . && git commit -am "Circuit Breaker: shippingservice"
git push
cd $ASM
 

6. Tunggu hingga Cloud Build selesai.
7. Kembali di Cloud Shell, gunakan pod fortio untuk mengirim traffic gRPC ke shippingservice dengan 1 koneksi serentak, total 1.000 permintaan - hal ini tidak akan memicu pemutus sirkuit, karena kita belum melampaui setelan connectionPool.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 1 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Output (jangan disalin)

Health SERVING : 1000
All done 1000 calls (plus 0 warmup) 4.968 ms avg, 201.2 qps

8. Sekarang jalankan fortio lagi, dengan meningkatkan jumlah koneksi serentak menjadi 2, tetapi tetap menjaga jumlah total permintaan tetap konstan. Kita akan melihat hingga dua pertiga permintaan menampilkan error "overflow", karena pemutus arus telah diaktifkan: dalam kebijakan yang kita tetapkan, hanya 1 koneksi serentak yang diizinkan dalam interval 1 detik.

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 2 -n 1000 -qps 0 shippingservice.shipping.svc.cluster.local:50051 
 

Output (jangan disalin)

18:46:16 W grpcrunner.go:107> Error making grpc call: rpc error: code = Unavailable desc = upstream connect error or disconnect/reset before headers. reset reason: overflow
...

Health ERROR : 625
Health SERVING : 375
All done 1000 calls (plus 0 warmup) 12.118 ms avg, 96.1 qps

9. Envoy melacak jumlah koneksi yang dihentikannya saat pemutus sirkuit aktif, dengan metrik upstream_rq_pending_overflow. Mari kita temukan ini di pod fortio:

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c istio-proxy  -- sh -c 'curl localhost:15000/stats' | grep shipping | grep pending
 

Output (jangan disalin)

cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.default.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.circuit_breakers.high.rq_pending_open: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_active: 0
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_failure_eject: 9
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_overflow: 565
cluster.outbound|50051||shippingservice.shipping.svc.cluster.local.upstream_rq_pending_total: 1433

10. Bersihkan dengan menghapus kebijakan pemutus sirkuit dari kedua region.

kubectl --context ${OPS_GKE_1} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
 

kubectl --context ${OPS_GKE_2} delete destinationrule shippingservice-circuit-breaker -n shipping 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-shipping-circuit-breaker.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-shipping-circuit-breaker.yaml
cd $K8S_REPO; git add .; git commit -m "Circuit Breaker: cleanup"; git push origin master
 

Bagian ini menunjukkan cara menyiapkan satu kebijakan pemutus sirkuit untuk layanan. Praktik terbaiknya adalah menyiapkan pemutus sirkuit untuk setiap layanan upstream (backend) yang berpotensi mengalami hang. Dengan menerapkan kebijakan pemutus sirkuit Istio, Anda membantu mengisolasi microservice, membangun toleransi kesalahan ke dalam arsitektur, dan mengurangi risiko kegagalan berjenjang di bawah beban tinggi.

14. Injeksi Kesalahan

Tujuan: Uji ketahanan Layanan rekomendasi dengan memperkenalkan penundaan (sebelum didorong ke produksi).

• Buat VirtualService untuk Layanan recommendation guna memperkenalkan penundaan 5 detik
• Menguji penundaan menggunakan generator beban fortio
• Hapus penundaan di VirtualService dan validasi

Petunjuk Lab Skrip Jalur Cepat

Fast Track Script Lab akan segera hadir!!

Petunjuk Lab Metode Salin dan Tempel

Menambahkan kebijakan pemutus sirkuit ke layanan Anda adalah salah satu cara untuk membangun ketahanan terhadap layanan dalam produksi. Namun, pemutusan sirkuit menyebabkan kesalahan — yang berpotensi merupakan error yang ditampilkan kepada pengguna — yang tidak ideal. Untuk mengatasi kasus error ini dan memprediksi dengan lebih baik cara layanan downstream Anda merespons saat backend menampilkan error, Anda dapat menerapkan pengujian kekacauan di lingkungan penyiapan. Pengujian kekacauan adalah praktik memecah layanan Anda secara sengaja, untuk menganalisis titik lemah dalam sistem dan meningkatkan toleransi kesalahan. Anda juga dapat menggunakan pengujian gangguan untuk mengidentifikasi cara memitigasi error yang dihadapi pengguna saat backend gagal - misalnya, dengan menampilkan hasil yang di-cache di frontend.

Menggunakan Istio untuk injeksi kesalahan sangat membantu karena Anda dapat menggunakan image rilis produksi, dan menambahkan kesalahan di lapisan jaringan, bukan memodifikasi kode sumber. Dalam produksi, Anda dapat menggunakan alat pengujian gangguan yang lengkap untuk menguji ketahanan di lapisan Kubernetes/komputasi selain lapisan jaringan.

Anda dapat menggunakan Istio untuk pengujian gangguan dengan menerapkan VirtualService dengan kolom "fault". Istio mendukung dua jenis kesalahan: kesalahan penundaan (menyuntikkan waktu tunggu) dan kesalahan pembatalan (menyuntikkan error HTTP). Dalam contoh ini, kita akan menyuntikkan kesalahan penundaan 5 detik ke layanan rekomendasi. Namun, kali ini, alih-alih menggunakan pemutus sirkuit untuk "gagal cepat" terhadap layanan yang terhenti ini, kita akan memaksa layanan downstream untuk menahan waktu tunggu habis sepenuhnya.

11. Buka direktori injeksi kesalahan.

export K8S_REPO="${WORKDIR}/k8s-repo"
export ASM="${WORKDIR}/asm/" 
cd $ASM
 

12. Buka k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml untuk memeriksa isinya. Perhatikan bahwa Istio memiliki opsi untuk menyuntikkan kesalahan ke dalam persentase permintaan - di sini, kita akan memperkenalkan waktu tunggu ke semua permintaan recommendationservice.

Output (jangan disalin)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: recommendation-delay-fault
spec:
  hosts:
  - recommendationservice.recommendation.svc.cluster.local
  http:
  - route:
    - destination:
        host: recommendationservice.recommendation.svc.cluster.local
    fault:
      delay:
        percentage:
          value: 100
        fixedDelay: 5s

13. Salin VirtualService ke k8s_repo. Kita akan menyuntikkan kesalahan secara global, di kedua region.

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml

cp $ASM/k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit add resource app-recommendation-vs-fault.yaml
 

14. Mendorong perubahan

cd $K8S_REPO 
git add . && git commit -am "Fault Injection: recommendationservice"
git push
cd $ASM
 

15. Tunggu hingga Cloud Build selesai.
16. Jalankan perintah exec ke pod fortio yang di-deploy di bagian pemutus sirkuit, dan kirim beberapa traffic ke recommendationservice.

FORTIO_POD=$(kubectl --context ${DEV1_GKE_1} get pod -n shipping | grep fortio | awk '{ print $1 }')

kubectl --context ${DEV1_GKE_1} exec -it $FORTIO_POD -n shipping -c fortio /usr/bin/fortio -- load -grpc -c 100 -n 100 -qps 0 recommendationservice.recommendation.svc.cluster.local:8080
 

    Once the fortio command is complete, you should see responses averaging 5s:

Output (jangan disalin)

Ended after 5.181367359s : 100 calls. qps=19.3
Aggregated Function Time : count 100 avg 5.0996506 +/- 0.03831 min 5.040237641 max 5.177559818 sum 509.965055

17. Cara lain untuk melihat kesalahan yang kita masukkan adalah dengan membuka frontend di browser web, lalu mengklik produk apa pun. Halaman produk akan memerlukan waktu pemuatan 5 detik lebih lama, karena halaman tersebut mengambil rekomendasi yang ditampilkan di bagian bawah halaman.
18. Lakukan pembersihan dengan menghapus layanan injeksi kesalahan dari kedua cluster Ops.

kubectl --context ${OPS_GKE_1} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_1_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml

kubectl --context ${OPS_GKE_2} delete virtualservice recommendation-delay-fault -n recommendation 
rm ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/app-recommendation-vs-fault.yaml
cd ${K8S_REPO}/${OPS_GKE_2_CLUSTER}/istio-networking/; kustomize edit remove resource app-recommendation-vs-fault.yaml
 

19. Menerapkan perubahan:

cd $K8S_REPO 
git add . && git commit -am "Fault Injection cleanup / restore"
git push
cd $ASM
 

15. Memantau Bidang Kontrol Istio

ASM menginstal empat komponen bidang kontrol penting: Pilot, Mixer, Galley, dan Citadel. Setiap layanan mengirimkan metrik pemantauan yang relevan ke Prometheus, dan ASM dilengkapi dengan dasbor Grafana yang memungkinkan operator memvisualisasikan data pemantauan ini serta menilai kondisi dan performa bidang kontrol.

Melihat Dasbor

20. Teruskan port layanan Grafana yang diinstal dengan Istio

kubectl --context ${OPS_GKE_1} -n istio-system port-forward svc/grafana 3000:3000 >> /dev/null
 

21. Membuka Grafana di browser
22. Klik ikon "Web Preview" di sudut kanan atas Jendela Cloud Shell Anda
23. Klik Preview on port 3000 (Catatan: jika port bukan 3000, klik change port, lalu pilih port 3000)
24. Tindakan ini akan membuka tab di browser Anda dengan URL yang mirip dengan " BASE_URL/?orgId=1&authuser=0&environment_id=default"
25. Melihat dasbor yang tersedia
26. Ubah URL menjadi " BASE_URL/dashboard"
27. Klik folder "istio" untuk melihat dasbor yang tersedia
28. Klik salah satu dasbor tersebut untuk melihat performa komponen tersebut. Kita akan melihat metrik penting untuk setiap komponen di bagian berikut.

Monitoring Pilot

Pilot adalah komponen bidang kontrol yang mendistribusikan konfigurasi kebijakan dan jaringan ke bidang data (proxy Envoy). Pilot cenderung diskalakan dengan jumlah workload dan deployment, meskipun tidak selalu dengan jumlah traffic ke workload tersebut. Pilot yang tidak sehat dapat:

• menggunakan lebih banyak resource daripada yang diperlukan (CPU dan/atau RAM)
• mengakibatkan penundaan dalam mengirimkan informasi konfigurasi yang diperbarui ke Envoy

Catatan: Jika Pilot tidak berfungsi, atau jika ada penundaan, workload Anda tetap menayangkan traffic.

23. Buka " BASE_URL/dashboard/db/istio-pilot-dashboard" di browser Anda untuk melihat metrik Pilot.

Metrik penting yang dipantau

Penggunaan Resource

Gunakan halaman Performa dan Skalabilitas Istio sebagai panduan Anda untuk angka penggunaan yang dapat diterima. Hubungi dukungan GCP jika Anda melihat penggunaan resource berkelanjutan yang jauh lebih tinggi daripada ini.

Informasi Push Pilot

Bagian ini memantau pengiriman konfigurasi Pilot ke proxy Envoy Anda.

• Pilot Pushes menampilkan jenis konfigurasi yang dikirimkan pada waktu tertentu.
• Pemantauan ADS menampilkan jumlah Layanan Virtual, Layanan, dan Endpoint yang Terhubung dalam sistem.
• Cluster tanpa endpoint yang diketahui menampilkan endpoint yang telah dikonfigurasi tetapi tidak memiliki instance yang berjalan (yang mungkin menunjukkan layanan eksternal, seperti *.googleapis.com).
• Error Percontohan menampilkan jumlah error yang terjadi dari waktu ke waktu.
• Konflik menampilkan jumlah konflik yang merupakan konfigurasi ambigu pada pendengar.

Jika Anda memiliki Error atau Konflik, Anda memiliki konfigurasi yang buruk atau tidak konsisten untuk satu atau beberapa layanan Anda. Lihat Memecahkan masalah bidang data untuk mengetahui informasi selengkapnya.

Informasi Utusan

Bagian ini berisi informasi tentang proxy Envoy yang menghubungi bidang kontrol. Hubungi dukungan GCP jika Anda melihat kegagalan Koneksi XDS berulang.

Monitoring Mixer

Mixer adalah komponen yang menyalurkan telemetri dari proxy Envoy ke backend telemetri (biasanya Prometheus, Stackdriver, dll.). Dalam kapasitas ini, tidak ada di bidang data. Mixer di-deploy sebagai dua Job Kubernetes (disebut Mixer) yang di-deploy dengan dua nama layanan yang berbeda (istio-telemetry dan istio-policy).

Mixer juga dapat digunakan untuk berintegrasi dengan sistem kebijakan. Dalam kapasitas ini, Mixer memengaruhi data plane, karena pemeriksaan kebijakan ke Mixer yang gagal akan memblokir akses ke layanan Anda.

Mixer cenderung diskalakan dengan volume traffic.

24. Buka " BASE_URL/dashboard/db/istio-mixer-dashboard" di browser Anda untuk melihat metrik Mixer.

Metrik pemantauan penting

Penggunaan Resource

Gunakan halaman Performa dan Skalabilitas Istio sebagai panduan Anda untuk angka penggunaan yang dapat diterima. Hubungi dukungan GCP jika Anda melihat penggunaan resource berkelanjutan yang jauh lebih tinggi daripada ini.

Ringkasan Mixer

• Durasi Respons adalah metrik penting. Meskipun laporan ke telemetri Mixer tidak berada di jalur data, jika latensi ini tinggi, performa proxy sidecar pasti akan melambat. Anda dapat mengharapkan persentil ke-90 berada dalam milidetik satu digit, dan persentil ke-99 berada di bawah 100 md.

• Durasi Pengiriman Adaptor menunjukkan latensi yang dialami Mixer saat memanggil adaptor (yang digunakan untuk mengirim informasi ke sistem telemetri dan logging). Latensi tinggi di sini pasti akan memengaruhi performa di mesh. Sekali lagi, latensi p90 harus di bawah 10 md.

Memantau Galeri

Galley adalah komponen validasi, penyerapan, pemrosesan, dan distribusi konfigurasi Istio. Komponen ini menyampaikan konfigurasi dari server Kubernetes API ke Pilot. Seperti Pilot, komponen ini cenderung diskalakan dengan jumlah layanan dan endpoint dalam sistem.

25. Buka " BASE_URL/dashboard/db/istio-galley-dashboard" di browser Anda untuk melihat metrik Galley.

Metrik pemantauan penting

Validasi Resource

Metrik terpenting yang harus diikuti yang menunjukkan jumlah resource dari berbagai jenis seperti Aturan tujuan, Gateway, dan Entri layanan yang lulus atau gagal validasi.

Klien yang terhubung

Menunjukkan jumlah klien yang terhubung ke Galley; biasanya ada 3 (pilot, istio-telemetry, istio-policy) dan akan diskalakan saat komponen tersebut diskalakan.

16. Memecahkan masalah Istio

Memecahkan masalah bidang data

Jika dasbor Pilot menunjukkan bahwa Anda mengalami masalah konfigurasi, Anda harus memeriksa log Pilot atau menggunakan istioctl untuk menemukan masalah konfigurasi.

Untuk memeriksa log Pilot, jalankan penemuan kubectl -n istio-system logs istio-pilot-69db46c598-45m44, dengan mengganti istio-pilot-... dengan ID pod untuk instance Pilot yang ingin Anda pecahkan masalahnya.

Di log yang dihasilkan, telusuri pesan Push Status. Contoh:

2019-11-07T01:16:20.451967Z        info        ads        Push Status: {
    "ProxyStatus": {
        "pilot_conflict_outbound_listener_tcp_over_current_tcp": {
            "0.0.0.0:443": {
                "proxy": "cartservice-7555f749f-k44dg.hipster",
                "message": "Listener=0.0.0.0:443 AcceptedTCP=accounts.google.com,*.googleapis.com RejectedTCP=edition.cnn.com TCPServices=2"
            }
        },
        "pilot_duplicate_envoy_clusters": {
            "outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|15443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|443|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            },
            "outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local": {
                "proxy": "sleep-6c66c7765d-9r85f.default",
                "message": "Duplicate cluster outbound|80|httpbin|istio-egressgateway.istio-system.svc.cluster.local found while pushing CDS"
            }
        },
        "pilot_eds_no_instances": {
            "outbound_.80_._.frontend-external.hipster.svc.cluster.local": {},
            "outbound|443||*.googleapis.com": {},
            "outbound|443||accounts.google.com": {},
            "outbound|443||metadata.google.internal": {},
            "outbound|80||*.googleapis.com": {},
            "outbound|80||accounts.google.com": {},
            "outbound|80||frontend-external.hipster.svc.cluster.local": {},
            "outbound|80||metadata.google.internal": {}
        },
        "pilot_no_ip": {
            "loadgenerator-778c8489d6-bc65d.hipster": {
                "proxy": "loadgenerator-778c8489d6-bc65d.hipster"
            }
        }
    },
    "Version": "o1HFhx32U4s="
}

Status Push akan menunjukkan masalah yang terjadi saat mencoba mengirim konfigurasi ke proxy Envoy – dalam hal ini, kita melihat beberapa pesan "Duplicate cluster", yang menunjukkan tujuan upstream duplikat.

Untuk mendapatkan bantuan dalam mendiagnosis masalah, hubungi dukungan Google Cloud jika ada masalah.

Menemukan error konfigurasi

Untuk menggunakan istioctl guna menganalisis konfigurasi Anda, jalankan istioctl experimental analyze -k --context $OPS_GKE_1. Tindakan ini akan melakukan analisis konfigurasi di sistem Anda, menunjukkan masalah apa pun beserta saran perubahan. Lihat dokumentasi untuk mengetahui daftar lengkap error konfigurasi yang dapat dideteksi oleh perintah ini.

17. Pembersihan

Langkah-langkah berikut dilakukan oleh administrator setelah workshop selesai.

Administrator menjalankan skrip cleanup_workshop.sh untuk menghapus resource yang dibuat oleh skrip bootstrap_workshop.sh. Anda memerlukan informasi berikut agar skrip pembersihan dapat berjalan.

• Nama organisasi - misalnya yourcompany.com
• ID Workshop - dalam bentuk YYMMDD-NN, misalnya 200131-01
• Bucket GCS admin - ditentukan dalam skrip bootstrap.

13. Buka Cloud Shell, lakukan semua tindakan di bawah di Cloud Shell. Klik link di bawah.

CLOUD SHELL

14. Pastikan Anda login ke gcloud dengan pengguna Admin yang dimaksud.

gcloud config list
 

15. Buka folder asm.

cd ${WORKDIR}/asm
 

16. Tentukan Nama organisasi dan ID workshop yang akan dihapus.

export ORGANIZATION_NAME=<ORGANIZATION NAME>
export ASM_WORKSHOP_ID=<WORKSHOP ID>
export ADMIN_STORAGE_BUCKET=<ADMIN CLOUD STORAGE BUCKET>
 

17. Jalankan skrip pembersihan sebagai berikut.

./scripts/cleanup_workshop.sh --workshop-id ${ASM_WORKSHOP_ID} --admin-gcs-bucket ${ADMIN_STORAGE_BUCKET} --org-name ${ORGANIZATION_NAME}