Workshop Anthos Service Mesh: Panduan Lab

1. WORKSHOP ALFA

CATATAN PENTING: INI ADALAH BEKERJA ALFA DAN SERTA DITUJUKAN UNTUK MENJADI PELATIHAN KELAS YANG DIPANDUKAN INSTRUKTUR.

Link ke codelab workshop bit.ly/asm-workshop

2. Ringkasan

Diagram Arsitektur

Workshop ini merupakan pengalaman imersif langsung yang menjelaskan cara menyiapkan layanan yang didistribusikan secara global di GCP dalam produksi. Teknologi utama yang digunakan adalah Google Kubernetes Engine (GKE) untuk komputasi dan mesh layanan Istio untuk menciptakan konektivitas, kemampuan observasi, dan pembentukan traffic lanjutan yang aman. Semua praktik dan alat yang digunakan dalam workshop ini adalah apa 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 tentang Infrastruktur dan repositori Kubernetes
• Lab: Men-deploy aplikasi contoh
• Layanan Terdistribusi dan Kemampuan Observasi
• Makan Siang
• Lab: Kemampuan observasi dengan Stackdriver
• QNA
• Modul 2 - DevOps - Peluncuran terbatas, kebijakan/RBAC
• Penemuan layanan multi-cluster dan keamanan/kebijakan
• Lab: TLS Bersama
• Deployment Canary
• Lab: Deployment Canary
• Load balancing global multi-cluster yang aman
• Istirahat
• Lab: Kebijakan Otorisasi
• QNA
• Modul 3 - Operasi Infrastruktur - Upgrade platform
• Elemen penyusun Distributed Service
• Lab: Penskalaan Infrastruktur
• Langkah berikutnya

Slide

Slide workshop ini bisa dilihat di link berikut:

Slide Workshop ASM

Prasyarat

Hal berikut 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 melakukan workshop, lanjutkan ke bagian berikutnya yang berlabel Infrastructure Setup - User Workflow

Penjelasan skrip workshop bootstrap

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

Skrip workshop bootstrap memerlukan hal berikut sebagai input:

• 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 workshop (misalnya 01) - Nomor dua digit. Ini digunakan jika Anda mengadakan beberapa workshop dalam satu hari dan ingin melacaknya secara terpisah. Nomor workshop juga digunakan untuk mendapatkan ID project. Memiliki nomor workshop terpisah akan memudahkan untuk memastikan Anda mendapatkan project ID yang unik setiap kali memulai. Selain nomor workshop, tanggal sekarang (dalam format YYMMDD) juga digunakan untuk project ID. Kombinasi tanggal dan nomor workshop memberikan ID proyek yang unik.
• Nomor pengguna awal (misalnya 1) - Angka ini menandakan pengguna pertama di workshop. Misalnya, jika ingin membuat workshop untuk 10 pengguna, Anda dapat memiliki nomor pengguna awal 1 dan pengguna akhir nomor 10.
• Nomor pengguna akhir (misalnya 10) - Angka ini menandakan pengguna terakhir dalam workshop. Misalnya, jika ingin membuat workshop untuk 10 pengguna, Anda dapat memiliki nomor pengguna awal 1 dan pengguna akhir nomor 10. Jika Anda menyiapkan satu lingkungan (misalnya untuk Anda sendiri), buat nomor pengguna awal dan pengguna akhir yang sama. Tindakan ini akan membuat lingkungan tunggal.

Selain tanggal dan nomor workshop, nomor pengguna awal dan akhir juga dimasukkan dalam ID proyek. ID pengguna (untuk pengguna yang mengadakan workshop) berasal dari nomor pengguna awal dan akhir. ID pengguna dijelaskan di bagian 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. Admin yang membuat workshop harus memiliki izin baca/tulis ke bucket ini.

Skrip workshop bootstrap 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 menciptakan 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 materi untuk workshop ini. Yang kedua adalah MY_USER, yang melakukan langkah-langkah dalam workshop. MY_USER hanya memiliki akses ke resource-nya sendiri. ADMIN_USER memiliki akses ke semua penyiapan pengguna. Jika Anda membuat penyiapan ini sendiri, ADMIN_USER dan MY_USER sama. Jika Anda adalah instruktur yang membuat workshop ini untuk beberapa siswa, 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 yang berisi semua resource-nya di dalam project.
• Organization Administrator
• Project Creator - Kemampuan untuk membuat project di Organisasi.
• Project Deleter - Kemampuan untuk menghapus project di Organisasi.
• Admin Project IAM - Kemampuan untuk membuat aturan IAM di semua project di Organisasi.

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

Skema dan izin pengguna menjalankan workshop

Jika berencana membuat workshop ini untuk pengguna (selain Anda sendiri) di organisasi, Anda harus mengikuti skema penamaan pengguna tertentu untuk MY_USERs. Selama skrip bootstrap_workshop.sh, Anda memberikan nomor pengguna awal dan akhir. Nomor 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 pengguna akhir bernomor 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 spesifik yang dibuat selama skrip setup_terraform_admin_project.sh. Anda harus mematuhi skema penamaan pengguna ini saat menggunakan skrip bootstrap. Lihat cara menambahkan beberapa pengguna sekaligus di G Suite.

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 sudah versi terbaru)
• sudo apt update
• sudo apt install git
• jq
• lingkungan
• sesuaikan

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

Menyiapkan workshop untuk Anda sendiri (penyiapan satu pengguna)

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

CLOUD SHELL

2. Pastikan Anda sudah 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 pada 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 menetapkan nomor pengguna awal dan akhir karena Anda menyiapkannya sendiri.

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

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

6. Mendapatkan 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 ini di Cloud Shell. Klik link di bawah.

CLOUD SHELL

8. Pastikan Anda sudah 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, nomor pengguna awal dan akhir, serta bucket GCS admin yang akan digunakan untuk workshop. Tinjau izin yang diperlukan untuk menyiapkan workshop pada 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 melakukan workshop mulai dari sini. Lakukan semua langkah dari jendela INCOGNITO di Chrome atau Firefox.

Memilih jalur lab Anda

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

• "Skrip interaktif jalur cepat yang mudah" jalan
• "Salin dan tempel setiap petunjuk manual" jalan

Metode skrip jalur cepat memungkinkan Anda menjalankan satu skrip interaktif untuk setiap lab yang memandu Anda di lab dengan menjalankan perintah untuk lab tersebut secara otomatis. Perintah dijalankan dalam batch dengan penjelasan ringkas tentang setiap langkah dan apa yang mereka capai. Setelah setiap batch, Anda akan diminta untuk melanjutkan ke batch perintah berikutnya. Dengan cara ini, Anda dapat menjalankan lab sesuai kemampuan Anda. Skrip jalur cepat bersifat idempoten, yang berarti Anda dapat menjalankan skrip ini beberapa kali untuk memberikan hasil yang sama.

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

SKRIP TREK CEPAT

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

Metode salin dan tempel adalah cara tradisional untuk menyalin dan menempel setiap blok perintah dengan penjelasan perintah. Metode ini hanya dimaksudkan untuk dijalankan satu kali. Tidak ada jaminan bahwa menjalankan kembali perintah dalam metode ini akan memberi Anda hasil yang sama.

Saat melakukan lab, harap pilih salah satu dari dua metode berikut.

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

Penyiapan Skrip Jalur Cepat

Setelah menyelesaikan skrip jalur cepat, Anda akan 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 adalah pemilik semua project dalam workshop. Administrator workshop memberikan kredensial akun lab (nama pengguna dan sandi) kepada pengguna yang melakukan workshop. Semua project pengguna diawali dengan nama pengguna akun lab, misalnya untuk akun lab [e-mail], project ID admin terraformnya 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.

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 menggunakan akun perusahaan atau pribadi Anda). Akun lab terlihat seperti userXYZ@<workshop_domain>.com.
3. Karena ini adalah akun baru, Anda diminta untuk menyetujui Persyaratan Layanan Google. Klik Terima.

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

Langkah ini akan menyediakan VM Debian Linux kecil yang dapat Anda gunakan untuk mengakses resource GCP. Setiap akun mendapatkan VM Cloud Shell. Anda akan login menggunakan kredensial akun lab setelah login ke ketentuan akun lab. Selain Cloud Shell, Code Editor juga disediakan sehingga memudahkan Anda mengedit 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 adalah akun yang sama dengan 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 sendiri menggunakan "-sufa" atau "–setup-for-admin" kemudian tetapkan MY_USER ke email untuk akun GCP yang Anda gunakan untuk membuat project workshop.

7. Lakukan echo 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 repositori workshop.

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

5. Penyiapan Infrastruktur - Alur Kerja Pengguna

Tujuan: Memverifikasi infrastruktur dan penginstalan Istio

• Instal alat workshop
• Buat clone repositori workshop
• Verifikasi penginstalan Infrastructure
• Verifikasi penginstalan k8s-repo
• Memverifikasi penginstalan Istio

SKRIP TREK 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, dapatkan bashrc untuk memperbarui variabel dalam sesi Cloud Shell.

source ${HOME}/.bashrc

Petunjuk Lab Metode Salin dan Tempel

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

Mendapatkan info Pengguna

Administrator yang menyiapkan workshop harus memberikan informasi nama pengguna dan sandi kepada pengguna. Semua project pengguna akan diawali dengan nama pengguna, misalnya untuk pengguna [e-mail], project ID admin terraformnya adalah user001-200131-01-tf-abcde, dan seterusnya untuk project lainnya. Setiap pengguna hanya memiliki akses ke lingkungan workshop mereka 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 sudah versi terbaru)
• sudo apt update
• sudo apt install git
• jq
• lingkungan
• sesuaikan
• pv

Mengakses project admin terraform

Setelah skrip bootstrap_workshop.sh selesai, folder GCP dibuat untuk setiap pengguna dalam organisasi. Dalam folder tersebut, project admin terraform akan dibuat. Project admin terraform digunakan untuk membuat sisa resource GCP yang diperlukan untuk workshop ini. Skrip setup-terraform-admin-project.sh mengaktifkan API yang diperlukan dalam project admin terraform. Cloud Build digunakan untuk menerapkan paket Terraform. Melalui skrip, Anda memberi akun layanan Cloud Build peran IAM yang tepat 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 project ID admin terraform. Nama ini disimpan di bucket GCS admin yang ditentukan dalam skrip bootstrap. Jika Anda menjalankan skrip bootstrap untuk beberapa pengguna, semua project ID admin terraform ada di bucket GCS.

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

1. Buka Cloud Shell (jika belum dibuka 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 sudah login ke gcloud dengan akun pengguna yang dimaksud.

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 project ID 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 guna membuka halaman Cloud Build untuk project admin Terraform dan pastikan bahwa 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. Setelah melihat halaman Cloud Build, klik link History dari navigasi sebelah kiri dan 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 Organisasi. Akun penagihan yang disediakan dikaitkan dengan setiap project.
• Satu project adalah network host project untuk VPC bersama. Tidak ada resource lain yang dibuat dalam project ini.
• Salah satu project adalah ops project yang digunakan untuk cluster GKE bidang kontrol Istio.
• Dua project mewakili dua tim pengembangan berbeda yang mengerjakan layanannya masing-masing.
• Dua cluster GKE dibuat di ketiga project ops, dev1, dan dev2.
• Repositori CSR bernama k8s-repo dibuat dan 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 untuk cabang master k8s-repo, manifes Kubernetes akan di-deploy ke cluster GKE dari foldernya masing-masing.

Skrip terraform memerlukan waktu 40-50 menit.

10. Setelah build selesai di terraform admin project, build lain akan dimulai di project operasi. Klik link yang ditampilkan guna membuka halaman Cloud Build untuk ops project dan memastikan 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 membuat file kubeconfig baru di folder gke yang bernama kubemesh.

12. Ubah variabel KUBECONFIG agar mengarah ke file kubeconfig yang 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 sehingga tersedia 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. Buat daftar konteks cluster Anda. Anda akan melihat enam klaster.

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 semua pod yang 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, injektor file bantuan, dan coredn yang berjalan di cluster dev1. Aplikasi ini menggunakan pesawat kontrol Istio yang sama 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, injektor file bantuan, dan coredn yang berjalan di cluster dev2. Aplikasi ini menggunakan pesawat kontrol Istio yang sama 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, pastikan 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 operasi. Uji coba menggunakan rahasia ini untuk menemukan Service dengan membuat kueri ke server Kube API dari cluster aplikasi (diautentikasi melalui secret di atas). Anda melihat bahwa kedua cluster operasi dapat mengautentikasi ke semua cluster aplikasi menggunakan secret yang dibuat oleh kubeconfig. Cluster operasi dapat menemukan layanan secara otomatis menggunakan file kubeconfig sebagai metode rahasia. Hal ini mengharuskan Pilot di cluster operasi memiliki akses ke server Kube API untuk semua cluster lainnya. Jika Pilot tidak dapat menjangkau server Kube API, Anda harus menambahkan layanan jarak jauh secara manual sebagai ServiceEntries. Anda dapat menganggap ServiceEntries sebagai entri DNS di registry layanan Anda. ServiceEntries menentukan layanan menggunakan nama DNS yang sepenuhnya memenuhi syarat ( FQDN) dan alamat IP yang dapat dijangkau. Lihat dokumen Istio Multicluster untuk mengetahui informasi selengkapnya.

6. Penjelasan Repo Infrastruktur

Cloud Build Infrastruktur

Resource GCP untuk workshop dibuat menggunakan Cloud Build dan repo CSR infrastructure. Anda baru saja menjalankan skrip bootstrap (terletak di scripts/bootstrap_workshop.sh) dari terminal lokal Anda. 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 terraform, log, dan skrip lain-lain. Isinya adalah infrastructure dan repositori CSR k8s_repo. Repositori ini dijelaskan secara mendetail di bagian berikutnya. Tidak ada resource workshop lain yang dibangun dalam project admin terraform. Akun layanan Cloud Build dalam project admin terraform digunakan untuk membuat resource workshop.

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

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

Struktur folder - tim, lingkungan, dan resource

Repositori Infrastruktur menyiapkan resource infrastruktur GCP untuk workshop. Hal ini terstruktur ke dalam folder dan subfolder. Folder dasar dalam repo mewakili team yang memiliki resource GCP tertentu. Lapisan folder berikutnya mewakili environment khusus 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 dalam folder resource.

Empat jenis tim berikut diwakili dalam workshop ini:

1. infrastruktur - mewakili tim infrastruktur cloud. Mereka bertanggung jawab untuk membuat resource GCP untuk semua tim lain. Mereka menggunakan project admin Terraform untuk resource mereka. Repositori infrastruktur itu sendiri ada dalam project admin Terraform, serta file status Terraform (dijelaskan di bawah). Sumber daya ini dibuat oleh skrip bash selama proses bootstrap (lihat Modul 0 - Alur Kerja Administrator untuk detailnya).
2. network - mewakili tim jaringan. Mereka bertanggung jawab atas VPC dan resource jaringan. Resource ini memiliki resource GCP berikut.
3. host project - mewakili project host VPC bersama.
4. shared VPC - merepresentasikan VPC bersama, subnet, rentang IP sekunder, rute, dan aturan firewall.
5. ops - mewakili tim operasi/devops. Mereka memiliki resource berikut.
6. ops project - mewakili project untuk semua resource operasi.
7. gke clusters - cluster GKE operasi per region. Bidang kontrol Istio diinstal di setiap cluster GKE operasi.
8. k8s-repo - repositori CSR yang berisi manifes GKE untuk semua cluster GKE.
9. apps - mewakili tim aplikasi. Workshop ini menyimulasikan dua tim, yaitu app1 dan app2. Mereka memiliki resource berikut.
10. app projects - setiap tim aplikasi mendapatkan kumpulan project mereka sendiri. Hal ini memungkinkan mereka mengontrol penagihan dan IAM untuk project spesifik mereka.
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. Di workshop ini, aplikasi1 memiliki beberapa instance GCE yang menjalankan sebagian aplikasi.

Di workshop ini, aplikasi yang sama (aplikasi Hipster Shop) mewakili 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 symlink di setiap folder resource. Hal ini memungkinkan Anda 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 (terletak di templates/backend.tf_tmpl) menggunakan skrip (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 di file tfstate yang ditentukan di backend untuk resource tertentu tersebut. Misalnya, untuk membuat cluster GKE dalam sebuah project, Anda perlu mengetahui project ID-nya. Project ID di-output 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 beberapa file) ada di folder resource yang memerlukan output dari resource lain. Misalnya, dalam 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 dalam project operasi. File shared_state dihasilkan dari template (terletak di templates/shared_state.tf_tmpl) menggunakan skrip (terletak di scripts/setup_terraform_admin_project). Semua sumber daya File shared_state 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 sym menautkan file tersebut dalam 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 terletak di bucket GCS dalam project admin terraform. File ini berisi ID organisasi, akun penagihan, project ID, detail cluster GKE, dll. Anda dapat mendownload dan mendapatkan vars.sh dari terminal mana pun untuk mendapatkan nilai penyiapan Anda.

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

Penjelasan Repo K8s

k8s_repo adalah repositori CSR (terpisah dari repositori infrastruktur) yang terletak di project admin Terraform. Layanan ini digunakan untuk menyimpan dan menerapkan manifes GKE ke semua cluster GKE. k8s_repo dibuat oleh Cloud Build infrastruktur (lihat bagian sebelumnya untuk detailnya). Selama proses awal Cloud Build infrastruktur, total enam cluster GKE dibuat. Di k8s_repo, enam folder dibuat. Setiap folder (nama yang cocok dengan nama cluster GKE) berkaitan 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 untuk repo k8s_repo. Serupa dengan infrastruktur, semua manifes Kubernetes disimpan sebagai kode di repositori k8s_repo dan status setiap cluster GKE selalu disimpan di foldernya masing-masing.

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

Project, cluster GKE, dan namespace

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

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

1. Tim infrastruktur yang membuat resource GCP menggunakan Terraform admin project. Mereka mengelola infrastruktur sebagai kode dalam repo CSR (disebut infrastructure) dan menyimpan semua informasi status Terraform yang berkaitan dengan resource yang dibangun di GCP dalam bucket GCS. Kontrol ini mengontrol akses ke bucket GCS status Terraform dan repo CSR.
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 secara terpusat untuk resource GCP. Semua project menggunakan satu VPC bersama ini untuk membangun jaringan.
3. Tim operasi/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 melakukan hardening 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 dalam project operasi.
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. Semua ini dibangun di atas platform yang dikelola oleh 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 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 (aplikasi) - digunakan oleh tim pengembangan untuk menjalankan aplikasi. Dalam workshop ini, aplikasi toko Hipster akan digunakan.

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

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

Aplikasi yang digunakan dalam workshop ini, yaitu aplikasi Hipster Shop, di-deploy di keempat klaster aplikasi tersebut. Tiap microservice berada di namespace-nya sendiri di setiap cluster aplikasi. Deployment (Pods) aplikasi toko hipster tidak di-deploy di cluster operasi. Namun, namespace dan resource Service untuk semua microservice juga dibuat di cluster operasi. Bidang kontrol ASM/Istio menggunakan registry layanan Kubernetes untuk penemuan layanan. Jika tidak ada Layanan (di cluster operasi), Anda harus membuat ServiceEntri secara manual untuk setiap layanan yang berjalan di cluster aplikasi.

Anda akan men-deploy aplikasi microservice 10 tingkat di workshop ini. Aplikasi ini merupakan aplikasi e-commerce berbasis web bernama " Hipster Shop" tempat pengguna dapat menelusuri item, menambahkannya ke keranjang, dan membelinya.

Manifes Kubernetes dan k8s_repo

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

Keenam 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 region 1 zona a
4. gke-2-apps-r1b-prod - cluster aplikasi di region 1 zona b
5. gke-3-apps-r2a-prod - cluster aplikasi di region 2 zona a
6. gke-4-apps-r2b-prod - cluster aplikasi di region 2 zona b

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) untuk memudahkan pengelolaan. Di workshop ini, Anda akan menggunakan Kustomize untuk melacak resource yang di-deploy. Silakan baca dokumentasi resmi Kustomize untuk mengetahui detail selengkapnya.

7. Men-deploy Aplikasi Contoh

Tujuan: Men-deploy aplikasi belanja Hipster di cluster aplikasi

• Clone k8s-repo
• Salin manifes toko Hipster ke semua cluster aplikasi
• Membuat aplikasi toko Layanan untuk Hipster di cluster operasi
• Siapkan loadgenerators di cluster operasi untuk menguji konektivitas global
• Memverifikasi konektivitas aman ke aplikasi toko Hipster

SKRIP TREK 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-tempel di bawah ini**.**

Meng-clone repositori sumber project operasi

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

1. Buat direktori kosong untuk git repo:

mkdir $WORKDIR/k8s-repo
 

2. Init repo git, tambahkan remote dan pull master dari repo 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. Setel 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 email

4. Salin namespace dan layanan Hipster Shop ke repo 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 folder aplikasi kustomization.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 Hipster Shop Deployments, 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 kecuali satu cluster dev. Hipstershop tidak dibangun untuk deployment multi-cluster, jadi untuk menghindari hasil yang tidak konsisten, kami 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. Menghapus podsecuritypolicies, deployment, dan direktori rbac dari cluster operasi 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 operasi.

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 operasi. Aplikasi toko Hipster diekspos menggunakan Load Balancer Google Cloud (GCLB) global. GCLB menerima traffic klien (yang ditujukan ke frontend) dan mengirimkannya ke instance Layanan terdekat. Menempatkan loadgenerator di kedua cluster operasi akan memastikan traffic dikirim ke kedua gateway Istio Ingress yang berjalan di cluster operasi. Load balancing akan 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 project ID operasi di manifes loadgenerator untuk kedua cluster operasi.

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. Commit 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 project Operasi Cloud Build di tab yang sebelumnya dibuka 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 Running 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. Pastikan pod di namespace keranjang hanya dalam status Berjalan 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

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

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

Atau, Anda dapat menempatkan gateway Istio Ingress di cluster aplikasi secara langsung 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 di Layanan Kubernetes, sehingga dapat mendaftarkan dirinya sendiri ke Pengontrol NEG. Pengontrol Autoneg adalah pengontrol GKE khusus yang mengotomatiskan pembuatan NEG serta menetapkannya sebagai backend ke GCLB menggunakan anotasi Service. Bidang kontrol Istio, termasuk gateway masuk Istio di-deploy selama infrastruktur awal Terraform Cloud Build. Konfigurasi GCLB dan autoneg dilakukan sebagai bagian dari Cloud Build infrastruktur Terraform awal.

Mengamankan Ingress menggunakan Cloud Endpoints dan sertifikat terkelola

Sertifikat Terkelola GCP digunakan untuk mengamankan traffic klien ke layanan GCLB frontend. GCLB menggunakan sertifikat terkelola untuk layanan frontend global dan sertifikat ini 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 bahwa 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 operasi yang menghasilkan traffic pengujian ke link Cloud Endpoints toko GCLB Hipster. Verifikasi bahwa GCLB menerima traffic dan mengirim ke kedua gateway Istio Ingress.

23. Mendapatkan GCLB > Link 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 ke istio-ingressgateway dari menu dropdown Backend seperti yang ditunjukkan di bawah ini.

25. Catat traffic yang menuju ke istio-ingressgateways.

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

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

8. Kemampuan observasi dengan Stackdriver

Tujuan: Menghubungkan telemetri Istio ke Stackdriver dan melakukan validasi.

• Instal resource istio-telemetry
• Membuat/memperbarui dasbor Layanan Istio
• Lihat log container
• Melihat pelacakan terdistribusi di Stackdriver

SKRIP TREK 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-tempel di bawah ini**.**

Salah satu fitur utama Istio adalah kemampuan observasi bawaan ("o11y"). Artinya, meskipun dengan container black-box dan tanpa instrumentasi, operator masih dapat mengamati traffic yang masuk dan keluar dari container ini, untuk memberikan layanan kepada pelanggan. Observasi ini memiliki bentuk beberapa metode berbeda: metrik, log, dan trace.

Kita juga akan memanfaatkan sistem pembuatan beban bawaan di Hipster Shop. Kemampuan observasi tidak berfungsi dengan baik pada sistem statis tanpa traffic, jadi pembuatan beban membantu kita memahami cara kerjanya. Beban ini sudah berjalan, sekarang kita hanya bisa melihatnya.

1. Instal istio ke file konfigurasi 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. Commit ke k8s-repo.

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

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

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

4. Memverifikasi Istio → integrasi Stackdriver Mendapatkan CRD Stackdriver Handler.

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

Output-nya akan menampilkan pengendali bernama stackdriver:

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

5. Memastikan bahwa ekspor metrik Istio ke Stackdriver berfungsi. 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 dengan project Operasi, cukup pilih Oke. Jika diminta untuk memberitahukan UI baru, cukup tutup dialog.

Di Metrics Explorer, di bagian "Find resource type and metric" ketik "istio" untuk melihat opsi seperti "Jumlah Permintaan Server" tentang "Container Kubernetes" jenis resource. Kode ini menunjukkan bahwa metrik mengalir dari mesh ke Stackdriver.

(Anda harus memberi label Kelompokkan Menurut destination_service_name jika ingin melihat baris di bawah ini.)

Memvisualisasikan metrik dengan Dasbor:

Setelah metrik berada di sistem APM Stackdriver, kita menginginkan cara untuk memvisualisasikannya. Di bagian ini, kita akan menginstal dasbor bawaan yang menunjukkan kepada kita tiga dari empat " Sinyal Emas" metrik: Traffic (Permintaan per detik), Latensi (dalam hal ini persentil ke-99 dan ke-50), dan Error (tidak termasuk Saturasi dalam contoh ini).

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

6. Sekarang, mari tambahkan dasbor metrik yang telah disiapkan sebelumnya. Kita akan menggunakan Dashboard API secara langsung. Ini adalah sesuatu yang biasanya tidak akan Anda lakukan dengan membuat panggilan API secara manual, ini akan menjadi bagian dari sistem otomatisasi, atau Anda akan membangun dasbor secara manual di UI web. Langkah 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 secara langsung menggunakan UX, tetapi dalam kasus ini, kita akan dengan cepat menambahkan grafik baru menggunakan API. Untuk melakukannya, Anda harus menarik dasbor ke versi terbaru, menerapkan hasil edit, lalu mendorongnya kembali menggunakan metode PATCH HTTP.

8. Anda bisa mendapatkan dasbor yang ada dengan membuat kueri API pemantauan. 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 %ile ke-50): [ Referensi API] Sekarang kita dapat menambahkan widget grafik baru ke dasbor dalam kode. Perubahan ini dapat ditinjau oleh rekan dan diperiksa ke kontrol versi. Berikut adalah widget yang akan ditambahkan dan menunjukkan latensi median (latensi median).

Coba edit dasbor yang baru saja Anda dapatkan, tambahkan bait 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 telah 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 beberapa Analisis Log sederhana.

Istio menyediakan kumpulan log terstruktur untuk semua traffic jaringan in-mesh dan menguploadnya ke Stackdriver Logging untuk memungkinkan analisis lintas cluster dalam satu alat yang canggih. Log dianotasikan 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 > Container Kubernetes, dan melakukan penelusuran secara "pilot" —

Di sini, kita dapat melihat Bidang Kontrol Istio mendorong konfigurasi proxy ke proxy file bantuan untuk setiap layanan aplikasi contoh. "CDS", "LDS," dan "RDS" mewakili Envoy API yang berbeda ( informasi selengkapnya).

Selain log Istio, Anda juga dapat menemukan log container serta log layanan GCP atau infrastruktur lainnya, semuanya dalam antarmuka yang sama. Berikut adalah beberapa contoh kueri log untuk GKE. Penampil log juga memungkinkan Anda membuat metrik dari log (misalnya: "menghitung 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 lainnya 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. Periksa Distributed Trace.

Kini setelah Anda bekerja dengan sistem terdistribusi, proses debug memerlukan alat baru: Pelacakan Terdistribusi. Alat ini memungkinkan Anda menemukan statistik tentang bagaimana layanan Anda berinteraksi (seperti menemukan peristiwa lambat yang luar biasa pada gambar di bawah), serta menyelami contoh trace mentah untuk menyelidiki detail apa yang sebenarnya terjadi.

Tampilan Linimasa menampilkan semua permintaan seiring waktu, yang dibuat grafik berdasarkan latensinya, atau waktu yang dihabiskan di antara permintaan awal, melalui stack Hipster, untuk akhirnya merespons pengguna akhir. Semakin tinggi titiknya, semakin lambat (dan kurang puas) pengalaman pengguna.

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

Tampilan Waterfall seharusnya familier bagi siapa saja yang pernah menggunakan debugger, tetapi dalam kasus ini, bukannya menampilkan waktu yang dihabiskan dalam berbagai proses dari satu aplikasi, contoh ini menunjukkan waktu yang dihabiskan untuk menjelajahi mesh kita, di antara layanan, yang berjalan dalam container terpisah.

Di sini Anda dapat menemukan Trace:

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

Contoh screenshot alat ini:

9. Autentikasi TLS Bersama

Tujuan: Mengamankan konektivitas antara microservice (AuthN).

• Aktifkan mTLS lebar mesh
• Memverifikasi mTLS dengan memeriksa log

SKRIP TREK 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-tempel di bawah ini**.**

Setelah aplikasi terinstal dan Kemampuan Observasi disiapkan, kita dapat mulai mengamankan koneksi antarlayanan dan memastikannya tetap berfungsi.

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

1. Memeriksa MeshPolicy di cluster operasi. 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. Kami akan mengonfigurasi mTLS di semua cluster dengan memperbarui CR IstioControlPlane dan mengupdate repo k8s. Menyetel global > mTLS > diaktifkan: true di CR IstioControlPlane menghasilkan dua perubahan berikut pada bidang kontrol Istio:

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

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

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. Commit ke k8s-repo.

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

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

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

 

Memverifikasi mTLS

5. Periksa MeshPolicy sekali lagi di cluster operasi. 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. Menjelaskan 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 bisa melihat perpindahan dari HTTP ke HTTPS di log.

Kita dapat mengekspos bidang khusus ini dari log di UI dengan mengeklik satu entri log dan kemudian mengklik nilai bidang yang ingin Anda tampilkan, dalam kasus ini, klik "http" di samping "protokol:

Hasil ini menghasilkan cara yang bagus untuk memvisualisasikan pergantian.:

10. Deployment Canary

Tujuan: Meluncurkan versi baru Layanan frontend.

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

SKRIP TREK 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-tempel di bawah ini**.**

Deployment canary adalah peluncuran bertahap layanan baru. Dalam deployment canary, Anda mengirim traffic yang meningkat ke versi baru, sambil tetap mengirimkan persentase yang tersisa ke versi saat ini. Pola yang umum adalah melakukan analisis canary pada setiap tahap pemisahan traffic, dan membandingkan "sinyal emas" versi baru (latensi, tingkat error, saturasi) terhadap dasar pengukuran. Hal ini membantu mencegah pemadaman layanan, dan memastikan stabilitas "v2" yang baru di setiap tahap pemisahan traffic.

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

Pertama, kita akan menjalankan pipeline Canary di region DEV1 (us-west1), dan meluncurkan frontend v2 pada 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 pada region secara berurutan, dibandingkan 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: kami akan memicu pipeline Canary secara manual di kedua region, tetapi dalam produksi, Anda akan menggunakan pemicu otomatis, misalnya berdasarkan tag image Docker baru yang dikirim ke registry.

1. Dari Cloud Shell, tentukan beberapa variabel env untuk menyederhanakan proses menjalankan 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.
• Istio DestinationRule frontend - membagi Layanan Kubernetes frontend menjadi dua subset, yaitu v1 dan v2, berdasarkan "versi" label deployment
• Istio VirtualService frontend - merutekan 100% traffic ke frontend v1. Ini menggantikan perilaku round-robin default Layanan Kubernetes, yang akan segera mengirim 50% dari semua traffic regional Dev1 ke frontend v2.

3. Lakukan perubahan ke k8s_repo:

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

4. Lihat status project Operasi Cloud Build di tab yang sebelumnya dibuka 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 pada 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 menjalankan 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 menuju ke deployment frontend v1, yang ditentukan di VirtualService baru.

7. Menjalankan 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 akan menunggu 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 untuk frontend-v2 selesai, 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 mengarah 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 dihasilkan.

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. Perlu diketahui bahwa region Dev2 masih "terkunci" pada v1. Hal ini karena pada skrip repo_setup dasar, kami mendorong VirtualService untuk mengirim semua traffic secara eksplisit ke v1. Dengan cara ini, kami dapat melakukan canary regional dengan aman di Dev1, dan memastikannya berjalan dengan sukses sebelum meluncurkan versi baru secara global.

12. Jalankan perintah untuk membagi jendela Cloud Shell dan menjalankan 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 menuju ke deployment frontend v1, yang ditentukan di VirtualService baru.

13. Menjalankan 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 akan menunggu 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, lihat traffic dari pod Dev2 yang bergerak secara bertahap 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 menggunakan skrip manual, Anda dapat otomatis memicu skrip canary ini sebagai pipeline Cloud Build, menggunakan pemicu seperti image baru yang diberi tag yang dikirim ke container registry. Anda juga ingin menambahkan analisis canary di antara setiap langkah, menganalisis latensi dan tingkat error v2 terhadap batas keamanan yang telah ditentukan, 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 TREK 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-tempel di bawah ini**.**

Tidak seperti aplikasi monolitik yang mungkin berjalan di satu tempat, aplikasi microservice yang didistribusikan secara global akan melakukan panggilan lintas batas jaringan. Artinya, Anda memiliki lebih banyak titik masuk ke aplikasi Anda, dan lebih banyak peluang untuk serangan berbahaya. Selain itu, karena pod Kubernetes memiliki IP sementara, aturan firewall berbasis IP tradisional tidak lagi memadai untuk mengamankan akses antar-beban kerja. Dalam arsitektur microservice, diperlukan pendekatan keamanan baru. Dibangun di atas elemen penyusun keamanan Kubernetes seperti akun layanan, Istio menyediakan serangkaian kebijakan keamanan yang fleksibel untuk aplikasi Anda.

Kebijakan Istio mencakup autentikasi dan otorisasi. Authentication memverifikasi identitas (apakah klien ini diizinkan untuk melakukan hal tersebut?), dan otorisasi memverifikasi izin. Kita telah membahas autentikasi Istio di bagian TLS bersama di Modul 1 (MeshPolicy). Di bagian ini, kita akan mempelajari cara menggunakan kebijakan otorisasi Istio untuk mengontrol akses ke salah satu workload aplikasi kami, yaitu currencyservice.

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

1. Periksa konten currency-deny-all.yaml. Kebijakan ini menggunakan pemilih label Deployment untuk membatasi akses ke layanan mata uang. 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 project Operasi Cloud Build di tab yang sebelumnya dibuka 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 pada 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 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 file bantuan layanan mata uang. Anda akan melihat pesan "enforced denied" pesan, 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 jangan layanan backend lainnya – untuk mengakses currencyservice. Buka currency-allow-frontend.yaml dan periksa kontennya. 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, kami mengizinkan source.principal (klien) tertentu untuk mengakses layanan mata uang. Source.principal ini ditentukan oleh Kubernetes Service Account. Dalam hal ini, akun layanan yang kita izinkan adalah akun layanan frontend di namespace frontend.

Catatan: saat menggunakan Akun Layanan Kubernetes di Istio AuthorizationPolicies, 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. Salin kebijakan mata uang yang telah 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 project Operasi Cloud Build di tab yang sebelumnya dibuka 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 frontend Hipstershop lagi. Kali ini, Anda tidak akan melihat error di halaman beranda - hal ini karena frontend diizinkan secara eksplisit untuk mengakses layanan saat ini.
13. Sekarang, coba jalankan checkout, dengan menambahkan item ke keranjang Anda dan mengklik "lakukan pemesanan". Kali ini, Anda akan melihat error konversi harga dari layanan mata uang. Hal ini terjadi karena kami hanya mengizinkan frontend, sehingga layanan checkout masih tidak dapat mengakses currencyservice.

14. Terakhir, mari kita izinkan akses layanan checkout ke mata uang, dengan menambahkan aturan lain ke AuthorizationPolicy layanan mata uang kami. Perlu diperhatikan bahwa kami hanya membuka akses mata uang ke dua layanan yang perlu mengaksesnya - frontend dan checkout. Backend lainnya masih akan diblokir.
15. Buka currency-allow-frontend-checkout.yaml dan periksa kontennya. Perhatikan bahwa daftar aturan berfungsi sebagai mata uang 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 project Operasi Cloud Build di tab yang sebelumnya dibuka 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 - build seharusnya berhasil.

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

12. Penskalaan Infrastruktur

Tujuan: Meningkatkan skala infrastruktur dengan menambahkan region, proyek, dan klaster baru.

• Meng-clone repo infrastructure
• Mengupdate file terraform untuk membuat resource baru
• 2 subnet di region baru (satu untuk project operasi dan satu untuk project baru)
• Cluster operasi baru di region baru (di subnet baru)
• Bidang kontrol Istio baru untuk region baru
• 2 cluster aplikasi dalam project baru di region baru
• Commit ke infrastructure repo
• Verifikasi penginstalan

SKRIP TREK 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-tempel di bawah ini**.**

Ada sejumlah cara untuk menskalakan platform. Anda dapat menambahkan lebih banyak komputasi dengan menambahkan node ke cluster yang ada. Anda dapat menambahkan lebih banyak cluster dalam satu region. Atau, Anda dapat menambahkan wilayah lain 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 kumpulan node) ke cluster yang ada mungkin sudah cukup. Namun, jika Anda memiliki cluster di dua dari tiga zona dalam satu region, maka menambahkan cluster baru di zona ketiga akan memberi Anda penskalaan dan domain fault tambahan (yaitu zona baru). Alasan lain untuk menambahkan cluster baru di suatu region mungkin adalah adanya kebutuhan untuk membuat satu cluster tenant - karena alasan peraturan atau kepatuhan (misalnya PCI, atau cluster database yang berisi informasi PII). Seiring dengan berkembangnya bisnis dan layanan Anda, menambahkan region baru menjadi keharusan 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:

• Vertikal - dalam setiap region dengan menambahkan lebih banyak komputasi. Hal ini dilakukan dengan menambahkan lebih banyak node (atau kumpulan node) ke cluster yang ada atau dengan menambahkan cluster baru dalam region. Hal ini dilakukan melalui repositori infrastructure. Jalur paling sederhana adalah menambahkan node ke cluster yang ada. Tidak diperlukan konfigurasi tambahan. Penambahan 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.
• Horizontal - dengan menambahkan lebih banyak wilayah. Platform saat ini menyediakan template regional. Terdiri dari cluster operasi regional tempat 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. 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 operasi dan cluster aplikasi baru.
2. Cluster operasi regional di region r3 tempat bidang kontrol ASM/Istio berada.
3. Dua cluster aplikasi zona di dua zona di region r3.
4. Update ke k8s-repo:
5. Men-deploy resource bidang kontrol ASM/Istio ke cluster operasi di region r3.
6. Men-deploy resource bidang kontrol bersama ASM/Istio ke cluster aplikasi di region r3.
7. Meskipun Anda tidak perlu membuat proyek baru, langkah-langkah dalam workshop ini menunjukkan penambahan 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. 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 repositori 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 untuk mengizinkan skrip di cabang agar dapat dijalankan.

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. Commit dan kirim perubahan untuk membuat project baru

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

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

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

Langkah ini memakan waktu 25 - 30 menit. Waktu yang tepat untuk beristirahat.

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

8. Setelah infrastruktur Cloud Build berhasil diselesaikan, buka k8s-repo 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 yang baru.

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

11. Buat daftar konteks cluster Anda. Anda akan melihat delapan klaster.

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 operasi baru dengan memeriksa semua pod yang 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, injektor file bantuan, dan coredn yang berjalan di cluster dev3. Aplikasi tersebut 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. Pastikan bahwa rahasia 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 Sirkuit

Tujuan: Menerapkan Pemutus Sirkuit untuk Layanan pengiriman.

• Membuat DestinationRule untuk Layanan shipping guna menerapkan pemutus arus listrik
• Gunakan fortio (utilitas peningkat beban) guna memvalidasi pemutus arus listrik untuk Layanan shipping dengan memaksa sirkuit

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 lihat bagaimana Istio membantu Anda meningkatkan ketahanan layanan, sehingga mengurangi jumlah pemecahan masalah yang harus Anda lakukan sejak awal.

Arsitektur microservice memperkenalkan risiko kegagalan beruntun, saat kegagalan satu layanan dapat menyebar ke dependensinya, dan dependensi dependensi tersebut, sehingga menyebabkan "efek riak" pemadaman layanan yang berpotensi mempengaruhi 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 yang tiba-tiba saat layanan kembali online. Secara keseluruhan, penggunaan Pemutus Sirkuit dapat membantu Anda menghindari kegagalan pada semua layanan dalam SLO karena ada satu layanan backend yang mengalami hang.

Pola Pemutus Sirkuit dinamakan berdasarkan sakelar listrik yang dapat "terputus" ketika terlalu banyak listrik mengalir, sehingga melindungi perangkat dari kelebihan beban. Dalam penyiapan Istio, hal ini berarti Envoy adalah pemutus arus listrik, yang melacak jumlah permintaan yang tertunda untuk suatu layanan. Dalam status tertutup default ini, permintaan mengalir melalui Envoy tanpa gangguan.

Namun, jika jumlah permintaan yang tertunda melebihi batas yang Anda tentukan, pemutus arus listrik akan putus (terbuka), dan Envoy langsung 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 beralih ke status setengah terbuka, di mana server dapat mulai menerima permintaan lagi dalam masa percobaan, dan jika berhasil merespons permintaan, pemutus sirkuit ditutup lagi, dan permintaan ke server mulai mengalir lagi.

Diagram ini merangkum pola pemutus arus listrik Istio. Persegi panjang biru mewakili Envoy, lingkaran berwarna biru mewakili klien, dan lingkaran putih mewakili penampung server:

Anda dapat menentukan kebijakan Pemutus Sirkuit menggunakan Istio DestinationRules. Di bagian ini, kami akan menerapkan kebijakan berikut untuk menerapkan pemutus arus listrik (MCB) 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 outlierDeteksi adalah tempat kami mengonfigurasi cara Envoy menentukan ambang batas untuk membuka pemutus arus listrik. Di sini, setiap detik (interval), Envoy akan menghitung jumlah error yang diterima dari penampung server. Jika melebihi batas consecutiveErrors, pemutus arus listrik Envoy akan terbuka, dan 100% pod katalog produk akan terlindung dari permintaan klien baru selama 10 detik. Setelah pemutus arus listrik Envoy terbuka (yaitu aktif), klien akan menerima error 503 (Layanan Tidak Tersedia). Mari kita lihat bagaimana penerapannya.

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

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

2. Mengupdate k8s-repo

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

3. Perbarui layanan pengiriman DestinationRule di kedua cluster Operasi.

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 pemuatan Fortio ke cluster GKE_1 di region Dev1. Ini adalah pod klien yang akan kita gunakan untuk "melakukan perjalanan" pemutus arus listrik untuk layanan pengiriman.

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

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

6. Tunggu hingga Cloud Build selesai.
7. Kembali ke Cloud Shell, gunakan pod fortio untuk mengirim traffic gRPC ke shippingservice dengan 1 koneksi serentak, dengan total 1.000 permintaan - hal ini tidak akan merusak pemutus arus listrik, 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, meningkatkan jumlah koneksi serentak menjadi 2, tetapi menjaga jumlah total permintaan tetap konstan. Kami akan melihat hingga dua pertiga permintaan menampilkan "overflow" error, karena pemutus arus listrik telah terputus: 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 terputus saat pemutus arus listrik aktif, dengan metrik upstream_rq_pending_overflow. Mari kita temukan hal 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 arus listrik dari kedua wilayah.

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 kebijakan pemutus arus listrik tunggal untuk layanan. Praktik terbaik adalah menyiapkan pemutus arus listrik untuk layanan upstream (backend) apa pun yang berpotensi berhenti berfungsi. Dengan menerapkan kebijakan pemutus arus listrik Istio, Anda membantu mengisolasi microservice, membangun fault tolerance ke dalam arsitektur Anda, dan mengurangi risiko kegagalan beruntun pada beban tinggi.

14. Injeksi Kesalahan

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

• Buat VirtualService untuk Layanan recommendation guna menyebabkan keterlambatan 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 arus listrik ke layanan Anda adalah salah satu cara untuk membangun ketahanan terhadap layanan dalam produksi. Namun, pemecahan sirkuit mengakibatkan kesalahan — yang berpotensi terjadi pada pengguna — dan hal ini tidak ideal. Untuk mengantisipasi kasus error ini, dan memprediksi dengan lebih baik cara layanan downstream merespons saat backend menampilkan error, Anda dapat mengadopsi pengujian kekacauan di lingkungan staging. Pengujian kekacauan adalah praktik dengan sengaja merusak layanan Anda untuk menganalisis titik lemah dalam sistem dan meningkatkan fault tolerance. Anda juga dapat menggunakan pengujian kekacauan untuk mengidentifikasi cara mengurangi error yang ditampilkan kepada pengguna saat backend gagal - misalnya, dengan menampilkan hasil yang di-cache di frontend.

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

Anda dapat menggunakan Istio untuk pengujian kekacauan dengan menerapkan VirtualService dengan "fault" kolom tersebut. Istio mendukung dua jenis kesalahan: kesalahan penundaan (memasukkan waktu tunggu) dan kesalahan pembatalan (memasukkan error HTTP). Dalam contoh ini, kita akan memasukkan kesalahan penundaan 5 detik ke dalam layanan rekomendasi. Namun, kali ini alih-alih menggunakan pemutus arus listrik untuk "gagal cepat" terhadap layanan menggantung ini, kita akan memaksa layanan downstream untuk bertahan selama waktu tunggu penuh.

11. Buka direktori injeksi fault.

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 kontennya. Perhatikan bahwa Istio memiliki opsi untuk memasukkan kesalahan ke dalam persentase permintaan - di sini, kami akan memperkenalkan waktu tunggu ke semua permintaan layanan rekomendasi.

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 menginjeksikan 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 ke pod fortio yang di-deploy di bagian pemutus arus listrik (MCB), lalu kirim beberapa traffic ke Recommendationsservice.

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 dalam tindakan adalah membuka frontend di browser web, dan mengklik produk apa pun. Halaman produk memerlukan waktu 5 detik tambahan untuk dimuat, karena halaman ini mengambil rekomendasi yang ditampilkan di bagian bawah halaman.
18. Bersihkan dengan menghapus layanan injeksi kesalahan dari kedua cluster Operasi.

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. Mendorong 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. Masing-masing mengirimkan metrik pemantauan yang relevan ke Prometheus, dan ASM dikirimkan dengan dasbor Grafana yang memungkinkan operator memvisualisasikan data pemantauan ini serta menilai kondisi dan performa bidang kontrol.

Melihat Dasbor

20. Meneruskan layanan Grafana Anda yang telah diinstal dengan Istio

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

21. Buka Grafana di browser Anda
22. Klik "Web Preview" di sudut kanan atas Jendela Cloud Shell
23. Klik Preview pada port 3000 (Catatan: jika port bukan 3000, klik ubah port dan 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. Lihat dasbor yang tersedia
26. Ubah URL menjadi " BASE_URL/dashboard"
27. Klik "istio" folder 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.

Pilot Pemantauan

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

• menggunakan lebih banyak resource dari yang dibutuhkan (CPU dan/atau RAM)
• menyebabkan penundaan dalam pengiriman informasi konfigurasi yang diperbarui ke Envoys

Catatan: jika periode Uji Coba tidak aktif, atau jika ada penundaan, workload Anda tetap melayani traffic.

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

Metrik penting yang dipantau

Penggunaan Resource

Gunakan halaman Istio Performance and Scalability sebagai panduan Anda untuk mengetahui jumlah penggunaan yang dapat diterima. Hubungi dukungan GCP jika Anda melihat penggunaan resource yang lebih berkelanjutan secara signifikan dari ini.

Informasi Dorongan Uji Coba

Bagian ini memantau permintaan uji coba konfigurasi ke proxy Envoy Anda.

• Dorongan Uji Coba menunjukkan jenis konfigurasi yang dikirim pada waktu tertentu.
• Pemantauan ADS menunjukkan 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 Uji Coba menunjukkan jumlah error yang ditemukan dari waktu ke waktu.
• Konflik menunjukkan jumlah konflik yang merupakan konfigurasi yang ambigu pada pemroses.

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

Informasi Envoy

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

Mixer Pemantauan

Mixer adalah komponen yang menyalurkan telemetri dari proxy Envoy ke backend telemetri (biasanya Prometheus, Stackdriver, dll.). Dalam kapasitas ini, hal ini tidak berada di bidang data. Layanan ini di-deploy sebagai dua Tugas 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 memang memengaruhi bidang data karena kebijakan akan memeriksa Mixer yang gagal memblokir akses ke layanan Anda.

Mixer cenderung menyesuaikan skala dengan volume lalu lintas.

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

Metrik penting yang dipantau

Penggunaan Resource

Gunakan halaman Istio Performance and Scalability sebagai panduan Anda untuk mengetahui jumlah penggunaan yang dapat diterima. Hubungi dukungan GCP jika Anda melihat penggunaan resource yang lebih berkelanjutan secara signifikan dari ini.

Ringkasan Mixer

• Durasi Respons adalah metrik penting. Meskipun laporan ke telemetri Mixer tidak ada di jalur data, jika latensi ini tinggi, performa proxy file bantuan pasti akan diperlambat. Anda harus memperkirakan persentil ke-90 dalam milidetik satu digit, dan persentil ke-99 menjadi di bawah 100 md.

• Adapter Dispatch Duration menunjukkan bahwa Mixer latensi terjadi dalam adaptor panggilan (yang digunakan untuk mengirim informasi ke telemetri dan sistem logging). Latensi tinggi di sini benar-benar akan memengaruhi performa pada mesh. Sekali lagi, latensi p90 harus di bawah 10 md.

Galeri Pemantauan

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

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

Metrik penting yang dipantau

Validasi Resource

Metrik terpenting yang perlu diikuti yang menunjukkan jumlah resource dari berbagai jenis seperti Aturan tujuan, Gateway, dan entri Layanan yang lulus atau gagal validasi.

Klien yang terhubung

Menunjukkan berapa banyak klien yang terhubung ke Galley; biasanya adalah 3 (pilot, istio-telemetry, istio-policy) dan akan diskalakan sesuai skala komponen tersebut.

16. Memecahkan Masalah Istio

Memecahkan masalah bidang data

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

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

Pada 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 apa pun yang terjadi saat mencoba mengirim konfigurasi ke proxy Envoy. Dalam hal ini, kita melihat beberapa "Cluster duplikat" pesan, yang menunjukkan tujuan upstream duplikat.

Untuk mendapatkan bantuan dalam mendiagnosis masalah, hubungi dukungan Google Cloud terkait masalah tersebut.

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 pada sistem Anda, menunjukkan masalah serta perubahan yang disarankan. Lihat dokumentasi untuk mengetahui daftar lengkap error konfigurasi yang dapat dideteksi 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 dijalankan.

• 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 ini di Cloud Shell. Klik link di bawah.

CLOUD SHELL

14. Pastikan Anda sudah 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}