Anthos Service Mesh Atölyesi: Laboratuvar Rehberi

1. ALFA ATÖLYESİ

ÖNEMLİ NOT: BU, ALFA ÇALIŞMASI OLUP KESİNLİKLE EĞİTMENLİ SINIF EĞİTİMİ OLARAK TASARLANMIŞTIR.

Atölye codelab'inin bağlantısı: bit.ly/asm-workshop

2. Genel Bakış

Mimari Diyagramı

Bu atölye çalışması, GCP'de üretimde küresel olarak dağıtılmış hizmetlerin nasıl ayarlanacağını ele alan uygulamalı ve sürükleyici bir deneyimdir. Kullanılan temel teknolojiler arasında, bilgi işlem için Google Kubernetes Engine (GKE) ve güvenli bağlantı, gözlemlenebilirlik ve gelişmiş trafik şekillendirme oluşturmak için Istio hizmet ağı yer alır. Bu atölyede kullanılan tüm uygulamalar ve araçlar, üretimde kullanacağınız uygulamalar ve araçlardır.

Gündem

• Modül 0: Giriş ve Platform Kurulumu
• Giriş ve mimari
• Hizmet ağı ve Istio/ASM'ye giriş
• Laboratuvar: Altyapı Kurulumu: Kullanıcı iş akışı�
• Ara
• QnA
• 1. Modül: ASM ile uygulamaları yükleme, güvenliğini sağlama ve izleme
• Depo modeli: Altyapı ve Kubernetes depoları açıklanıyor
• Laboratuvar: Örnek uygulama dağıtma
• Dağıtılmış Hizmetler ve Gözlemlenebilirlik
• Öğle yemeği
• Laboratuvar: Stackdriver ile Gözlemlenebilirlik
• QNA
• 2. Modül - DevOps - Canary dağıtımları, politika/RBAC
• Çok kümeli hizmet keşfi ve güvenlik/politika
• Laboratuvar: Karşılıklı TLS
• Canary dağıtımları
• Laboratuvar: Canary Dağıtımları
• Güvenli çok kümeli küresel yük dengeleme
• Ara
• Laboratuvar: Yetkilendirme Politikası
• QNA
• 3. Modül - Infra Ops - Platform yükseltmeleri
• Dağıtılmış hizmet yapı taşları
• Laboratuvar: Altyapı Ölçeklendirme
• Sonraki adımlar

Slaytlar

Bu atölyenin slaytlarını aşağıdaki bağlantıda bulabilirsiniz:

ASM Atölyesi Slaytları

Ön koşullar

Bu atölye çalışmasına devam etmeden önce aşağıdakileri yapmanız gerekir:

1. Bir GCP kuruluşu düğümü
2. Faturalandırma hesabı kimliği (kullanıcınız bu faturalandırma hesabında Faturalandırma Yöneticisi olmalıdır)
3. Kullanıcınız için kuruluş düzeyinde Kuruluş Yöneticisi IAM rolü

3. Altyapı Kurulumu - Yönetici İş Akışı

Bu bölümdeki adımlar, atölyeyi oluşturan bir yönetici tarafından gerçekleştirilir.

Çalıştaya katılan bir kullanıcıysanız Infrastructure Setup - User Workflow başlıklı sonraki bölüme geçin.

Bootstrap atölye çalışması komut dosyası açıklandı

Çalıştayın ilk ortamını ayarlamak için bootstrap_workshop.sh adlı bir komut dosyası kullanılır. Bu atölyeyi birden fazla kullanıcıya eğitim olarak veriyorsanız bu komut dosyasını kendiniz için tek bir ortam veya birden fazla kullanıcı için birden fazla ortam oluşturmak üzere kullanabilirsiniz.

Bootstrap atölye komut dosyası için giriş olarak aşağıdakiler gerekir:

• Kuruluş adı (örneğin yourcompany.com): Bu, atölye için ortamlar oluşturduğunuz kuruluştur.
• Faturalandırma kimliği (örneğin 12345-12345-12345): Bu faturalandırma kimliği, atölye çalışması sırasında kullanılan tüm kaynakları faturalandırmak için kullanılır.
• Atölye numarası (örneğin 01): İki haneli bir sayıdır. Bu özellik, aynı gün içinde birden fazla atölye çalışması yapıyorsanız ve bunları ayrı ayrı takip etmek istiyorsanız kullanılır. Proje kimliklerini türetmek için atölye numaraları da kullanılır. Ayrı atölye numaraları, her seferinde benzersiz proje kimlikleri almanızı kolaylaştırır. Proje kimlikleri için atölye numarasına ek olarak mevcut tarih (YYMMDD biçiminde) de kullanılır. Tarih ve atölye numarası kombinasyonu, benzersiz proje kimlikleri sağlar.
• Başlangıç kullanıcı numarası (örneğin 1): Bu numara, atölyedeki ilk kullanıcıyı ifade eder. Örneğin, 10 kullanıcılık bir atölye oluşturmak istiyorsanız başlangıç kullanıcı sayısı 1, bitiş kullanıcı sayısı ise 10 olabilir.
• Son kullanıcı numarası (örneğin 10): Bu numara, atölyedeki son kullanıcıyı ifade eder. Örneğin, 10 kullanıcılık bir atölye oluşturmak istiyorsanız başlangıç kullanıcı sayısı 1, bitiş kullanıcı sayısı ise 10 olabilir. Tek bir ortam kuruyorsanız (örneğin, kendiniz için) başlangıç ve bitiş kullanıcı numarasını aynı yapın. Bu işlem tek bir ortam oluşturur.

Tarih ve atölye numarasına ek olarak, başlangıç ve bitiş kullanıcı numaraları da proje kimliklerine dahil edilir. Kullanıcı kimlikleri (atölye çalışmasını yapan kullanıcılar için) başlangıç ve bitiş kullanıcı numarasından türetilir. Kullanıcı kimlikleri, User schema and permissions performing the workshop başlıklı bölümde açıklanmaktadır.

• Yönetici GCS paketi (örneğin my-gcs-bucket-name): GCS paketi, atölye çalışmasıyla ilgili bilgileri depolamak için kullanılır. Bu bilgiler, bootstrap atölye çalışması sırasında oluşturulan tüm kaynakları sorunsuz bir şekilde silmek için cleanup_workshop.sh komut dosyası tarafından kullanılır. Çalıştay oluşturan yöneticilerin bu pakete okuma/yazma izni olması gerekir.

Bootstrap atölye komut dosyası, yukarıda belirtilen değerleri kullanır ve setup-terraform-admin-project.sh komut dosyasını çağıran bir sarmalayıcı komut dosyası olarak işlev görür. setup-terraform-admin-project.sh komut dosyası, tek bir kullanıcı için atölye ortamı oluşturur.

Çalıştayı başlatmak için yönetici izinleri gerekir.

Bu atölyede iki tür kullanıcı vardır. Bu atölye çalışması için kaynak oluşturan ve silen bir ADMIN_USER. İkincisi ise MY_USER. Bu kişi, atölyedeki adımları gerçekleştirir. MY_USER yalnızca kendi kaynaklarına erişebilir. ADMIN_USER, tüm kullanıcı kurulumlarına erişebilir. Bu kurulumu kendiniz için yapıyorsanız ADMIN_USER ve MY_USER aynıdır. Bu atölyeyi birden fazla öğrenci için oluşturan bir eğitmen iseniz ADMIN_USER ve MY_USER değerleriniz farklı olur.

ADMIN_USER için aşağıdaki kuruluş düzeyinde izinler gereklidir:

• Sahip: Kuruluştaki tüm projeler için proje sahibi izni.
• Klasör yöneticisi: Kuruluşta klasör oluşturma ve silme olanağı. Her kullanıcı, projedeki tüm kaynaklarının bulunduğu tek bir klasör alır.
• Kuruluş yöneticisi
• Proje Oluşturucu: Kuruluşta proje oluşturma olanağı.
• Project Deleter (Proje Silici): Kuruluşta projeleri silme olanağı.
• Project IAM Admin (Proje IAM Yöneticisi): Kuruluştaki tüm projelerde IAM kuralları oluşturma yetkisi.

Bunlara ek olarak, ADMIN_USER, atölye için kullanılan faturalandırma kimliğinin faturalandırma yöneticisi de olmalıdır.

Çalıştayı gerçekleştiren kullanıcının şeması ve izinleri

Bu atölyeyi kuruluşunuzdaki kullanıcılar (kendiniz hariç) için oluşturmayı planlıyorsanız MY_USERs için belirli bir kullanıcı adlandırma şemasını uygulamanız gerekir. bootstrap_workshop.sh komut dosyası sırasında bir başlangıç ve bir bitiş kullanıcı numarası sağlarsınız. Bu sayılar aşağıdaki kullanıcı adlarını oluşturmak için kullanılır:

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

Örneğin, başlangıç kullanıcı numarası 1 ve bitiş kullanıcı numarası 3 ile bootstrap atölyesi komut dosyasını çalıştırırsanız yourcompany.com adlı kuruluşunuzda aşağıdaki kullanıcılar için atölye ortamları oluşturulur:

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

Bu kullanıcı adlarına, setup_terraform_admin_project.sh komut dosyası sırasında oluşturulan belirli projeleri için proje sahibi rolleri atanır. Bootstrap komut dosyasını kullanırken bu kullanıcı adlandırma şemasına uymanız gerekir. G Suite'te tek seferde birden çok kullanıcı ekleme başlıklı makaleyi inceleyin.

Atölye için gerekli araçlar

Bu atölye çalışması, Cloud Shell'den başlatılmak üzere tasarlanmıştır. Bu atölye çalışması için aşağıdaki araçlar gereklidir.

• gcloud (sürüm >= 270)
• kubectl
• sed (Cloud Shell/Linux'ta sed ile çalışır, Mac OS'te çalışmaz)
• git (güncel olduğunuzdan emin olun)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize

kustomize dışındaki tüm araçlar Cloud Shell'de varsayılan olarak yüklüdür. Kustomize yüklü değilse yukarıdaki bağlantıda verilen bash komut dosyasını kullanarak yükleyin, kustomize ikili programının PATH'inizde olduğundan emin olun ve Cloud Shell'de kustomize komutunu çalıştırarak onaylayın.

Kendiniz için atölye ayarlama (tek kullanıcılı kurulum)

1. Cloud Shell'i açın ve aşağıdaki tüm işlemleri Cloud Shell'de gerçekleştirin. Aşağıdaki bağlantıyı tıklayın.

CLOUD SHELL

2. gcloud'a amaçlanan yönetici kullanıcısıyla giriş yaptığınızı doğrulayın.

gcloud config list
 

3. WORKDIR oluşturun ve atölye deposunu klonlayın.

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

4. Kuruluş adınızı, Faturalandırma Kimliğinizi, atölye numaranızı ve atölyede kullanılacak bir yönetici GCS paketinizi tanımlayın. Atölyeyi ayarlamak için gereken izinleri yukarıdaki bölümlerde inceleyin.

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. bootstrap_workshop.sh komut dosyasını çalıştırın. Bu komut dosyasının tamamlanması birkaç dakika sürebilir.

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 
 

Bu ayarı kendiniz için yaptığınızdan başlangıç ve bitiş kullanıcı sayısını tanımlamanız gerekmediğini unutmayın.

bootstrap_workshop.sh komut dosyası tamamlandıktan sonra kuruluş içindeki her kullanıcı için bir GCP klasörü oluşturulur. Klasörde bir terraform admin project oluşturulur. Bu atölye çalışması için gereken GCP kaynaklarının geri kalanını oluşturmak üzere terraform yönetici projesi kullanılır. Gerekli API'leri Terraform yönetici projesinde etkinleştirirsiniz. Terraform planlarını uygulamak için Cloud Build'ü kullanıyorsunuz. Cloud Build hizmet hesabına, GCP'de kaynak oluşturabilmesi için uygun IAM rollerini veriyorsunuz. Son olarak, tüm GCP kaynakları için Terraform durumlarını depolamak üzere bir Google Cloud Storage (GCS) paketinde uzak bir arka uç yapılandırırsınız.

Cloud Build görevlerini Terraform yönetici projesinde görüntülemek için Terraform yönetici projesi kimliğine ihtiyacınız vardır. Bu, asm dizininizdeki vars/vars.sh dosyasında saklanır. Bu dizin yalnızca atölyeyi yönetici olarak kendiniz için ayarlıyorsanız kalıcı hale getirilir.

6. Ortam değişkenlerini ayarlamak için değişkenler dosyasını kaynaklandırma

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

Birden fazla kullanıcı için atölye kurulumu (çok kullanıcılı kurulum)

7. Cloud Shell'i açın ve aşağıdaki tüm işlemleri Cloud Shell'de gerçekleştirin. Aşağıdaki bağlantıyı tıklayın.

CLOUD SHELL

8. gcloud'a amaçlanan yönetici kullanıcısıyla giriş yaptığınızı doğrulayın.

gcloud config list
 

9. WORKDIR oluşturun ve atölye deposunu klonlayın.

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

10. Kuruluşunuzun adını, Faturalandırma Kimliğini, atölye numarasını, başlangıç ve bitiş kullanıcı numarasını ve atölyede kullanılacak bir yönetici GCS paketi tanımlayın. Atölyeyi ayarlamak için gereken izinleri yukarıdaki bölümlerde inceleyin.

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. bootstrap_workshop.sh komut dosyasını çalıştırın. Bu komut dosyasının tamamlanması birkaç dakika sürebilir.

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. Terraform proje kimliklerini almak için yönetici GCS paketinden workshop.txt dosyasını edinin.

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

4. Laboratuvar Kurulumu ve Hazırlığı

Çalıştayı gerçekleştiren kullanıcılar buradan başlayabilir. Tüm adımları Chrome veya Firefox'taki bir INCOGNITO penceresinden gerçekleştirin.

Laboratuvar yolunuzu seçin

Bu atölyedeki laboratuvarlar iki şekilde yapılabilir:

• "Kolay hızlı etkileşimli komut dosyaları" yöntemi
• "Her talimatı manuel olarak kopyalayıp yapıştırma" yöntemi

Hızlı komut dosyası yöntemi, her laboratuvar için tek bir etkileşimli komut dosyası çalıştırmanıza olanak tanır. Bu komut dosyası, laboratuvarla ilgili komutları otomatik olarak çalıştırarak laboratuvarı adım adım tamamlamanıza yardımcı olur. Komutlar, her adımın ve neyi başardıklarının kısa açıklamalarıyla birlikte toplu olarak çalıştırılır. Her toplu işlemden sonra, bir sonraki toplu komuta geçmeniz istenir. Bu sayede laboratuvarları kendi hızınızda çalıştırabilirsiniz. Hızlı izleme komut dosyaları idempotent'tir. Bu nedenle, bu komut dosyalarını birden çok kez çalıştırabilirsiniz ve aynı sonucu elde edersiniz.

Hızlı ilerleme senaryoları, aşağıdaki örnekte gösterildiği gibi her laboratuvarın üst kısmında yeşil bir kutu içinde görünür.

FAST TRACK SCRIPT

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

Kopyalama ve yapıştırma yöntemi, komutların açıklamalarıyla birlikte tek tek komut bloklarını kopyalayıp yapıştırmanın geleneksel yoludur. Bu yöntemin yalnızca bir kez çalıştırılması amaçlanmıştır. Bu yöntemde komutları yeniden çalıştırmanın aynı sonuçları vereceği garanti edilmez.

Laboratuvarları yaparken lütfen iki yöntemden birini seçin.

Bir yöntem seçip bu yöntemin adımlarını uyguladıktan sonra diğer yöntemin adımlarını uygulamayın.

Hızlı Komut Dosyası Kurulumu

Hızlı başlangıç senaryosunu tamamladığınızda ilgili laboratuvarı bitirmiş olursunuz. Kopyalama ve Yapıştırma Laboratuvarı Talimatları'ndaki adımları uygulamayın.

Kullanıcı bilgilerini alma

Bu atölye çalışması, atölye çalışmasının yöneticisi tarafından oluşturulan geçici bir kullanıcı hesabı (veya laboratuvar hesabı) kullanılarak gerçekleştirilir. Laboratuvar hesabı, atölyedeki tüm projelerin sahibidir. Çalıştay yöneticisi, çalıştayı gerçekleştiren kullanıcıya laboratuvar hesabı kimlik bilgilerini (kullanıcı adı ve şifre) sağlar. Kullanıcının tüm projelerinin önüne laboratuvar hesabının kullanıcı adı eklenir. Örneğin, [e-mail] laboratuvar hesabında Terraform yönetici projesi kimliği user001-200131-01-tf-abcde olur ve diğer projeler için de benzer şekilde devam eder. Her kullanıcının, çalıştay yöneticisi tarafından sağlanan laboratuvar hesabıyla giriş yapması ve çalıştayı laboratuvar hesabını kullanarak gerçekleştirmesi gerekir.

Kurumsal e-postanızı (atölyeye kaydolurken kullandığınız e-posta adresi) kontrol edin. Atölye yöneticisinden laboratuvar hesabınızın kimlik bilgileriyle (ör. kullanıcı adı ve şifre) ilgili bir e-posta almış olmanız gerekir. E-posta şu şekilde görünür.

1. Aşağıdaki bağlantıyı tıklayarak Cloud Shell'i açın.

CLOUD SHELL

2. Laboratuvar hesabı kimlik bilgileriyle giriş yapın (şirket veya kişisel hesabınızla giriş yapmayın). Laboratuvar hesabı userXYZ@<workshop_domain>.com şeklinde olur.
3. Bu yeni bir hesap olduğundan Google Hizmet Şartları'nı kabul etmeniz istenir. Kabul et'i tıklayın.

4. Bir sonraki ekranda, Google Hizmet Şartları'nı kabul etmek için onay kutusunu işaretleyin ve Start Cloud Shell simgesini tıklayın.

Bu adımda, GCP kaynaklarına erişmek için kullanabileceğiniz küçük bir Linux Debian sanal makinesi sağlanır. Her hesap bir Cloud Shell VM'si alır. Lab hesabıyla giriş yaptığınızda, lab hesabı kimlik bilgileri kullanılarak hesabınız sağlanır ve oturumunuz açılır. Cloud Shell'e ek olarak, yapılandırma dosyalarını (terraform, YAML vb.) düzenlemeyi kolaylaştıran bir kod düzenleyici de sağlanır. Varsayılan olarak Cloud Shell ekranı, Cloud Shell kabuk ortamı (altta) ve Cloud Code Editor (üstte) olmak üzere ikiye bölünür. Sağ üst köşedeki kalem ve kabuk istemi simgeleri, ikisi (kabuk ve kod düzenleyici) arasında geçiş yapmanızı sağlar. Ortadaki ayırıcı çubuğu (yukarı veya aşağı) sürükleyip her pencerenin boyutunu manuel olarak da değiştirebilirsiniz. 5. Bu atölye için bir WORKDIR oluşturun. WORKDIR, bu atölye çalışmasındaki tüm laboratuvarları gerçekleştireceğiniz klasördür. WORKDIR'i oluşturmak için Cloud Shell'de aşağıdaki komutları çalıştırın.

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

6. Laboratuvar hesabı kullanıcısını, bu atölye çalışmasında kullanılacak bir değişken olarak dışa aktarın. Bu hesap, Cloud Shell'e giriş yaptığınız hesapla aynıdır.

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

Not: Yöneticiyseniz ve "-sufa" veya "–setup-for-admin" işaretlerini kullanarak atölyeyi kendiniz için oluşturduysanız MY_USER'ı atölye projelerini oluşturmak için kullandığınız GCP hesabının e-posta adresine ayarlayın.

7. Aşağıdaki komutları çalıştırarak WORKDIR ve MY_USER değişkenlerinin her ikisinin de doğru şekilde ayarlandığından emin olmak için bu değişkenleri yansıtın.

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

8. Atölye çalışması deposunu klonlayın.

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

5. Altyapı Kurulumu - Kullanıcı İş Akışı

Amaç: Altyapı ve Istio kurulumunu doğrulama

• Atölye araçlarını yükleme
• Atölye deposunu klonlama
• Infrastructure yüklemesini doğrulayın
• k8s-repo yüklemesini doğrulayın
• Istio kurulumunu doğrulama

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Komut dosyası tamamlandıktan sonra Cloud Shell oturumunuzdaki değişkenleri güncellemek için bashrc dosyanızı kaynaklandırın.

source ${HOME}/.bashrc

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

ÖNEMLİ: Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Kullanıcı bilgilerini alma

Çalıştayı ayarlayan yöneticinin, kullanıcıya kullanıcı adı ve şifre bilgilerini vermesi gerekir. Kullanıcının tüm projelerinin önüne kullanıcı adı eklenir. Örneğin, [e-mail] kullanıcısının Terraform yönetici projesi kimliği user001-200131-01-tf-abcde olur. Diğer projeler için de aynı durum geçerlidir. Her kullanıcı yalnızca kendi atölye ortamına erişebilir.

Atölye için gerekli araçlar

Bu atölye çalışması, Cloud Shell'den başlatılmak üzere tasarlanmıştır. Bu atölye çalışması için aşağıdaki araçlar gereklidir.

kustomize ve pv dışındaki tüm araçlar Cloud Shell'de varsayılan olarak yüklüdür. Her ikisini de yükleme talimatlarını aşağıda bulabilirsiniz.

• gcloud (sürüm >= 270)
• kubectl
• sed (Cloud Shell/Linux'ta sed ile çalışır, Mac OS'te çalışmaz)
• git (güncel olduğunuzdan emin olun)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• kustomize
• pv

Terraform yönetici projesine erişme

bootstrap_workshop.sh komut dosyası tamamlandıktan sonra kuruluş içindeki her kullanıcı için bir GCP klasörü oluşturulur. Klasörde bir terraform admin project oluşturulur. Bu atölye çalışması için gereken GCP kaynaklarının geri kalanını oluşturmak üzere terraform yönetici projesi kullanılır. setup-terraform-admin-project.sh komut dosyası, Terraform yönetici projesinde gerekli API'leri etkinleştirir. Terraform planlarını uygulamak için Cloud Build kullanılır. Komut dosyası aracılığıyla, Cloud Build hizmet hesabına GCP'de kaynak oluşturabilmesi için uygun IAM rolleri verilir. Son olarak, tüm GCP kaynakları için Terraform durumlarını depolamak üzere bir Google Cloud Storage (GCS) paketinde uzak bir arka uç yapılandırılır.

Cloud Build görevlerini Terraform yönetici projesinde görüntülemek için Terraform yönetici projesi kimliğine ihtiyacınız vardır. Bu, bootstrap komut dosyasında belirtilen yönetici GCS paketinde saklanır. Başlatma komut dosyasını birden fazla kullanıcı için çalıştırırsanız tüm Terraform yönetici projesi kimlikleri GCS paketindedir.

Bu atölye çalışması Cloud Shell ve Cloud Console'da gerçekleştirilmek üzere tasarlanmıştır. Ayrı bir kullanıcı adı ve şifreyle giriş yapacağınız için aşağıdaki adımları bir INCOGNITO penceresinde uygulayın.

1. Aşağıdaki bağlantıyı tıklayarak Cloud Shell'i açın (Laboratuvar Kurulumu ve Hazırlık bölümünde henüz açılmamışsa).

CLOUD SHELL

2. Kustomize'ı (yüklü değilse) $HOME/bin klasörüne yükleyin ve $HOME/bin klasörünü $PATH'e ekleyin.

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. pv'yi yükleyin ve $HOME/bin/pv'ye taşıyın.

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

4. Bash isteminizi güncelleyin.

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. gcloud'a amaçlanan kullanıcı hesabıyla giriş yaptığınızı doğrulayın.

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

6. Aşağıdaki komutu çalıştırarak Terraform yönetici projenizin kimliğini alın:

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

7. Çalıştayla ilişkili tüm kaynaklar, Terraform yönetici projesindeki bir GCS paketinde depolanan vars.sh dosyasında değişken olarak saklanır. Terraform yönetici projeniz için vars.sh dosyasını alın.

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. Görüntülenen bağlantıyı tıklayarak Terraform yönetici projesinin Cloud Build sayfasını açın ve derlemenin başarıyla tamamlandığını doğrulayın.

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

Cloud Console'a ilk kez erişiyorsanız Google Hizmet Şartları'nı kabul edin.

9. Cloud Build sayfasına baktığınıza göre, sol gezinme çubuğundaki History bağlantısını ve ilk Terraform uygulamasının ayrıntılarını görüntülemek için en son derlemeyi tıklayın. Terraform komut dosyası kapsamında aşağıdaki kaynaklar oluşturulur. Yukarıdaki mimari şemaya da bakabilirsiniz.

• Kuruluşta 4 GCP projesi var. Belirtilen faturalandırma hesabı her projeyle ilişkilendirilmelidir.
• Bir proje, paylaşılan VPC için network host project olur. Bu projede başka kaynak oluşturulmamıştır.
• Bir proje, Istio kontrol düzlemi GKE kümeleri için kullanılan ops project'dir.
• İki proje, kendi hizmetleri üzerinde çalışan iki farklı geliştirme ekibini temsil ediyor.
• Üç projenin (ops, dev1 ve dev2) her birinde iki GKE kümesi oluşturulur.
• Kubernetes manifest dosyaları için altı klasör içeren k8s-repo adlı bir CSR deposu oluşturulur. GKE kümesi başına bir klasör. Bu depo, Kubernetes manifestlerini GitOps tarzında kümelere dağıtmak için kullanılır.
• k8s-repo ana dalına her commit yapıldığında Kubernetes manifest'lerini ilgili klasörlerinden GKE kümelerine dağıtmak için bir Cloud Build tetikleyicisi oluşturulur.

Terraform komut dosyası 40-50 dakika sürer.

10. Derleme terraform admin project tamamlandıktan sonra operasyon projesinde başka bir derleme başlatılır. ops project için Cloud Build sayfasını açmak üzere gösterilen bağlantıyı tıklayın ve k8s-repo Cloud Build'un başarıyla tamamlandığını doğrulayın.

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

Not: İstio yüklemesini doğrulayabilmeniz için bu derlemenin tamamlanması gerekir.

Yüklemeyi doğrula

11. Tüm kümeler için kubeconfig dosyaları oluşturun. Aşağıdaki komut dosyasını çalıştırın.

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

Bu komut dosyası, gke klasöründe kubemesh adlı yeni bir kubeconfig dosyası oluşturur.

12. KUBECONFIG değişkenini yeni kubeconfig dosyasına yönlendirecek şekilde değiştirin.

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

13. Cloud Shell her yeniden başlatıldığında kaynaklanması için vars.sh ve KUBECONFIG değişkenini Cloud Shell'deki .bashrc dosyasına ekleyin.

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

14. Küme bağlamlarınızı listeleyin. Altı küme görmelisiniz.

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

Istio kurulumunu doğrulama

15. Tüm kapsüllerin çalıştığını ve işlerin tamamlandığını kontrol ederek Istio'nun her iki kümeye de yüklendiğinden emin olun.

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. Istio'nun her iki dev1 kümesine de yüklendiğinden emin olun. dev1 kümelerinde yalnızca Citadel, sidecar-injector ve coredns çalışır. Bunlar, ops-1 kümesinde çalışan bir Istio kontrol düzlemini paylaşır.

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

17. Istio'nun her iki dev2 kümesine de yüklendiğinden emin olun. dev2 kümelerinde yalnızca Citadel, sidecar-injector ve coredns çalışır. Bunlar, ops-2 kümesinde çalışan bir Istio kontrol düzlemini paylaşır.

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

Paylaşılan kontrol düzlemleri için hizmet keşfini doğrulama

18. İsteğe bağlı olarak, gizli anahtarların dağıtıldığını doğrulayın.

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

Bu atölye çalışmasında, tüm GKE kümelerinin oluşturulduğu tek bir paylaşılan VPC kullanırsınız. Kümelerdeki hizmetleri keşfetmek için operasyon kümelerinde sır olarak oluşturulan kubeconfig dosyalarını (uygulama kümelerinin her biri için) kullanırsınız. Pilot, uygulama kümelerinin Kube API sunucusuna (yukarıdaki gizli dizeler aracılığıyla kimliği doğrulanmış) sorgu göndererek Hizmetleri bulmak için bu gizli dizeleri kullanır. Her iki işlem kümesinin de kubeconfig ile oluşturulan gizli anahtarları kullanarak tüm uygulama kümelerinde kimlik doğrulayabildiğini görürsünüz. Operasyon kümeleri, kubeconfig dosyalarını gizli bir yöntem olarak kullanarak hizmetleri otomatik olarak keşfedebilir. Bunun için operasyon kümelerindeki Pilot'un diğer tüm kümelerin Kube API sunucusuna erişmesi gerekir. Pilot, Kube API sunucularına ulaşamıyorsa uzak hizmetleri manuel olarak ServiceEntries olarak eklersiniz. ServiceEntry'leri, hizmet kayıt defterinizdeki DNS girişleri olarak düşünebilirsiniz. ServiceEntry'ler, tam nitelikli bir DNS adı ( FQDN) ve ulaşılabileceği bir IP adresi kullanarak hizmeti tanımlar. Daha fazla bilgi için Istio Multicluster belgelerine bakın.

6. Infrastructure Repo ile ilgili açıklamalar

Altyapı Cloud Build

Çalıştayla ilgili GCP kaynakları, Cloud Build ve infrastructure CSR deposu kullanılarak oluşturulur. Az önce yerel terminalinizden bir bootstrap komut dosyası (scripts/bootstrap_workshop.sh konumunda bulunur) çalıştırdınız. Bootstrap komut dosyası, bir GCP klasörü, bir Terraform yönetici projesi ve Cloud Build hizmet hesabı için uygun IAM izinleri oluşturur. Terraform yönetici projesi, Terraform durumlarını, günlüklerini ve çeşitli komut dosyalarını depolamak için kullanılır. infrastructure ve k8s_repo CSR depolarını içerir. Bu depolar, sonraki bölümde ayrıntılı olarak açıklanmıştır. Terraform yönetici projesinde başka atölye kaynakları oluşturulmamıştır. Terraform yönetici projesindeki Cloud Build hizmet hesabı, atölye çalışması için kaynak oluşturmak üzere kullanılır.

Çalıştay için GCP kaynakları oluşturmak üzere infrastructure klasöründe bulunan bir cloudbuild.yaml dosyası kullanılır. GCP kaynakları oluşturmak için gereken tüm araçları içeren özel bir oluşturucu resmi oluşturur. Bu araçlar arasında gcloud SDK, Terraform ve Python, Git, jq gibi diğer yardımcı programlar bulunur. Özel oluşturucu görüntüsü, her kaynak için terraform plan ve apply komutlarını çalıştırır. Her kaynağın Terraform dosyaları ayrı klasörlerde bulunur (ayrıntılar sonraki bölümde verilmiştir). Kaynaklar, genellikle oluşturulma sırasına göre (ör. bir GCP projesi, projede kaynaklar oluşturulmadan önce oluşturulur) tek tek oluşturulur. Daha ayrıntılı bilgi için lütfen cloudbuild.yaml dosyasını inceleyin.

infrastructure deposuna her commit işlemi yapıldığında Cloud Build tetiklenir. Altyapıda yapılan tüm değişiklikler kod olarak altyapı (IaC) olarak depolanır ve depoya işlenir. Atölyenizin durumu her zaman bu depoda saklanır.

Klasör yapısı: ekipler, ortamlar ve kaynaklar

Altyapı deposu, atölye çalışması için GCP altyapı kaynaklarını ayarlar. Klasörler ve alt klasörler halinde düzenlenir. Depodaki temel klasörler, belirli GCP kaynaklarının sahibi olan team'ları temsil eder. Bir sonraki klasör katmanı, ekip için belirli bir environment'yı (ör. geliştirme, hazırlık, üretim) temsil eder. Ortamdaki bir sonraki klasör katmanı, belirli resource öğelerini (örneğin, host_project, gke_clusters vb.) temsil eder. Gerekli komut dosyaları ve Terraform dosyaları kaynak klasörlerinde bulunur.

Bu atölye çalışmasında aşağıdaki dört tür ekip temsil edilmektedir:

1. infrastructure: Bulut altyapısı ekibini temsil eder. Diğer tüm ekipler için GCP kaynaklarını oluşturmaktan sorumludurlar. Kaynakları için Terraform yönetici projesini kullanıyorlar. Altyapı deposu ve Terraform durum dosyaları (aşağıda açıklanmıştır) Terraform yönetici projesinde bulunur. Bu kaynaklar, başlatma işlemi sırasında bir bash komut dosyası tarafından oluşturulur (ayrıntılar için Modül 0 - Yönetici İş Akışı'na bakın).
2. network: Ağ ekibini temsil eder. VPC ve ağ iletişimi kaynaklarından sorumludurlar. Aşağıdaki GCP kaynaklarının sahibi olmalıdır.
3. host project: Paylaşılan VPC ana makine projesini temsil eder.
4. shared VPC: Paylaşılan VPC'yi, alt ağları, ikincil IP aralıklarını, rotaları ve güvenlik duvarı kurallarını temsil eder.
5. ops: İşlemler/DevOps ekibini temsil eder. Aşağıdaki kaynakların sahibi olmalıdır.
6. ops project: Tüm işlem kaynakları için bir projeyi temsil eder.
7. gke clusters: Bölge başına bir operasyon GKE kümesi. Istio kontrol düzlemi, her bir operasyon GKE kümesine yüklenir.
8. k8s-repo: Tüm GKE kümeleri için GKE manifestlerini içeren bir CSR deposu.
9. apps: Uygulama ekiplerini temsil eder. Bu atölye çalışmasında app1 ve app2 olmak üzere iki ekip simüle edilmektedir. Aşağıdaki kaynakların sahibi olmalıdır.
10. app projects: Her uygulama ekibi kendi proje grubunu alır. Bu sayede, belirli projeleri için faturalandırma ve IAM'yi kontrol edebilirler.
11. gke clusters: Uygulama container'larının/kapsüllerinin çalıştığı uygulama kümeleridir.
12. gce instances (isteğe bağlı) GCE örneklerinde çalışan uygulamaları varsa. Bu atölyede, uygulama1'in bir kısmının çalıştığı birkaç GCE örneği vardır.

Bu atölye çalışmasında, aynı uygulama (Hipster shop uygulaması) hem uygulama1'i hem de uygulama2'yi temsil etmektedir.

Sağlayıcılar, durumlar ve çıkışlar - arka uçlar ve paylaşılan durumlar

google ve google-beta sağlayıcıları gcp/[environment]/gcp/provider.tf adresinde bulunuyor. provider.tf dosyası, her kaynak klasöründe symlinked. Bu sayede, her kaynak için sağlayıcıları ayrı ayrı yönetmek yerine sağlayıcıyı tek bir yerden değiştirebilirsiniz.

Her kaynak, kaynağın tfstate dosyasının konumunu tanımlayan bir backend.tf dosyası içerir. Bu backend.tf dosyası, scripts/setup_terraform_admin_project konumundaki bir komut dosyası kullanılarak templates/backend.tf_tmpl konumundaki bir şablondan oluşturulur ve ilgili kaynak klasörüne yerleştirilir. Arka uçlar için Google Cloud Storage (GCS) paketleri kullanılır. GCS paketi klasör adı, kaynak adıyla eşleşir. Tüm kaynak arka uçları, Terraform yönetici projesinde bulunur.

Birbirine bağımlı değerlere sahip kaynaklar output.tf dosyası içerir. Gerekli çıkış değerleri, söz konusu kaynak için arka uçta tanımlanan tfstate dosyasında saklanır. Örneğin, bir projede GKE kümesi oluşturmak için proje kimliğini bilmeniz gerekir. Proje kimliği, GKE küme kaynağında terraform_remote_state veri kaynağı aracılığıyla kullanılabilen tfstate dosyasına output.tf üzerinden aktarılır.

shared_state dosyası, bir kaynağın tfstate dosyasını işaret eden bir terraform_remote_state veri kaynağıdır. Kaynak klasörlerde, diğer kaynaklardan çıktı gerektiren bir shared_state_[resource_name].tf dosyası (veya dosyaları) vardır. Örneğin, ops_gke kaynak klasöründe ops_project ve shared_vpc kaynaklarından shared_state dosyaları vardır. Bunun nedeni, operasyon projesinde GKE kümeleri oluşturmak için proje kimliğine ve VPC ayrıntılarına ihtiyacınız olmasıdır. shared_state dosyaları, scripts/setup_terraform_admin_project konumundaki bir komut dosyası kullanılarak templates/shared_state.tf_tmpl konumundaki bir şablondan oluşturulur. Tüm kaynakların shared_state dosyaları gcp/[environment]/shared_states klasörüne yerleştirilir. Gerekli shared_state dosyaları, ilgili kaynak klasörlerinde sembolik olarak bağlanır. Tüm shared_state dosyalarını tek bir klasöre yerleştirip uygun kaynak klasörlerine sembolik olarak bağlamak, tüm durum dosyalarını tek bir yerden yönetmeyi kolaylaştırır.

Değişkenler

Tüm kaynak değerleri ortam değişkenleri olarak depolanır. Bu değişkenler, Terraform yöneticisi projesindeki bir GCS paketinde bulunan vars.sh adlı dosyada (dışa aktarma ifadeleri olarak) saklanır. Bu dosya; kuruluş kimliği, faturalandırma hesabı, proje kimlikleri, GKE küme ayrıntıları vb. bilgiler içerir. Kurulumunuz için değerleri almak üzere vars.sh dosyasını herhangi bir terminalden indirebilir ve kaynak olarak kullanabilirsiniz.

Terraform değişkenleri vars.sh içinde TF_VAR_[variable name] olarak depolanır. Bu değişkenler, ilgili kaynak klasöründe variables.tfvars dosyası oluşturmak için kullanılır. variables.tfvars dosyası, tüm değişkenleri değerleriyle birlikte içerir. variables.tfvars dosyası, aynı klasördeki bir şablon dosyasından scripts/setup_terraform_admin_project konumundaki bir komut dosyası kullanılarak oluşturulur.

K8s deposu açıklaması

k8s_repo, Terraform yönetici projesinde bulunan bir CSR deposudur (altyapı deposundan ayrı). GKE manifestlerini tüm GKE kümelerinde depolamak ve uygulamak için kullanılır. k8s_repo, altyapı Cloud Build tarafından oluşturulur (ayrıntılar için önceki bölüme bakın). İlk altyapı Cloud Build işlemi sırasında toplam altı GKE kümesi oluşturulur. k8s_repo içinde altı klasör oluşturulur. Her klasör (GKE küme adıyla eşleşen ad) kendi kaynak manifest dosyalarını içeren bir GKE kümesine karşılık gelir. Altyapı oluşturmaya benzer şekilde, Cloud Build, k8s_repo kullanılarak Kubernetes manifestlerini tüm GKE kümelerine uygulamak için kullanılır. Cloud Build, k8s_repo deposuna her taahhüt yapıldığında tetiklenir. Altyapıya benzer şekilde, tüm Kubernetes manifestleri k8s_repo deposunda kod olarak depolanır ve her GKE kümesinin durumu her zaman kendi klasöründe depolanır.

İlk altyapı oluşturma sürecinde k8s_repo oluşturulur ve tüm kümelere Istio yüklenir.

Projeler, GKE kümeleri ve ad alanları

Bu atölyedeki kaynaklar farklı GCP projelerine bölünmüştür. Projeler, şirketinizin organizasyon (veya ekip) yapısıyla eşleşmelidir. Farklı projelerden/ürünlerden/kaynaklardan sorumlu ekipler (kuruluşunuzda) farklı GCP projeleri kullanır. Ayrı projeler oluşturarak ayrı IAM izinleri grupları oluşturabilir ve faturalandırmayı proje düzeyinde yönetebilirsiniz. Ayrıca kotalar proje düzeyinde de yönetilir.

Bu atölye çalışmasında her biri kendi projesine sahip beş ekip yer alıyor.

1. GCP kaynaklarını oluşturan altyapı ekibi, Terraform admin project kullanır. Altyapıyı bir CSR deposunda (infrastructure olarak adlandırılır) kod olarak yönetirler ve GCP'de oluşturulan kaynaklarla ilgili tüm Terraform durum bilgilerini GCS paketlerinde saklarlar. CSR deposuna ve Terraform durumu GCS paketlerine erişimi kontrol ederler.
2. Paylaşılan VPC'yi oluşturan ağ ekibi, host project kullanır. Bu proje VPC, alt ağlar, rotalar ve güvenlik duvarı kurallarını içerir. Paylaşılan VPC, GCP kaynaklarının ağ iletişimi için merkezi yönetim olanağı sunar. Tüm projeler, ağ iletişimi için bu tek paylaşılan VPC'yi kullanıyordu.
3. GKE kümelerini ve ASM/Istio kontrol düzlemlerini oluşturan operasyon/platform ekibi, ops project kullanır. GKE kümelerinin ve hizmet ağının yaşam döngüsünü yönetirler. Kümeleri sağlamlaştırmak, Kubernetes platformunun esnekliğini ve ölçeğini yönetmekten sorumludurlar. Bu atölye çalışmasında, kaynakları Kubernetes'e dağıtmak için GitOps yöntemini kullanırsınız. Operasyon projesinde bir CSR deposu (k8s_repo olarak adlandırılır) bulunur.
4. Son olarak, uygulama geliştiren dev1 ve dev2 ekipleri (iki geliştirme ekibini temsil eder) kendi dev1 ve dev2 projects'lerini kullanır. Bunlar, müşterilerinize sunduğunuz uygulamalar ve hizmetlerdir. Bunlar, operasyon ekibinin yönettiği platformda oluşturulur. Kaynaklar (Dağıtımlar, Hizmetler vb.) k8s_repo'ya gönderilir ve uygun kümelere dağıtılır. Bu atölye çalışmasının CI/CD ile ilgili en iyi uygulamalara ve araçlara odaklanmadığını belirtmek isteriz. Kubernetes kaynaklarını doğrudan GKE kümelerine dağıtma işlemini otomatikleştirmek için Cloud Build'ü kullanırsınız. Gerçek dünyadaki üretim senaryolarında, uygulamaları GKE kümelerine dağıtmak için uygun bir CI/CD çözümü kullanırsınız.

Bu atölyede iki tür GKE kümesi vardır.

1. Operasyon kümeleri: Operasyon ekibi tarafından DevOps araçlarını çalıştırmak için kullanılır. Bu atölye çalışmasında, hizmet ağını yönetmek için ASM/Istio kontrol düzlemini çalıştırırlar.
2. Uygulama (apps) kümeleri: Uygulamaları çalıştırmak için geliştirme ekipleri tarafından kullanılır. Bu atölye çalışmasında Hipster Shop uygulaması kullanılmaktadır.

Operasyon/yönetici araçlarını uygulamayı çalıştıran kümelerden ayırmak, her kaynağın yaşam döngüsünü bağımsız olarak yönetmenize olanak tanır. İki küme türü, bunları kullanan ekibe/ürüne ait farklı projelerde de bulunur. Bu sayede IAM izinlerinin yönetimi de kolaylaşır.

Toplam altı GKE kümesi vardır. İşlemler projesinde iki bölgesel işlemler kümesi oluşturulur. ASM/Istio kontrol düzlemi her iki işlem kümesine de yüklenir. Her bir operasyon kümesi farklı bir bölgededir. Ayrıca dört bölgesel uygulama kümesi vardır. Bunlar kendi projelerinde oluşturulur. Bu atölye çalışmasında, her biri kendi projelerine sahip iki geliştirme ekibi simüle edilir. Her proje iki uygulama kümesi içerir. Uygulama kümeleri, farklı bölgelerdeki bölgesel kümelerdir. Dört uygulama kümesi iki bölgede ve dört alt bölgede yer alır. Bu şekilde bölgesel ve bölgesel yedeklilik elde edersiniz.

Bu atölyede kullanılan uygulama olan Hipster Shop uygulaması, dört uygulama kümesinin tümüne dağıtılır. Her mikro hizmet, her uygulama kümesinde kendi ad alanında bulunur. Hipster shop uygulaması dağıtımları (pod'lar), ops kümelerine dağıtılmaz. Ancak tüm mikro hizmetlerin ad alanları ve hizmet kaynakları da operasyon kümelerinde oluşturulur. ASM/Istio kontrol düzlemi, hizmet keşfi için Kubernetes hizmet kayıtlarını kullanır. Hizmetler (işlem kümelerinde) olmadığında, uygulama kümesinde çalışan her hizmet için ServiceEntry'leri manuel olarak oluşturmanız gerekir.

Bu atölyede 10 katmanlı bir mikro hizmet uygulaması dağıtıyorsunuz. Uygulama, kullanıcıların ürünlere göz atabildiği, bunları sepete ekleyebildiği ve satın alabildiği "Hipster Shop" adlı web tabanlı bir e-ticaret uygulamasıdır.

Kubernetes manifestleri ve k8s_repo

Tüm GKE kümelerine Kubernetes kaynakları eklemek için k8s_repo simgesini kullanırsınız. Bunun için Kubernetes manifestlerini kopyalayıp k8s_repo'ya göndermeniz gerekir. k8s_repo ile ilgili tüm işlemeler, Kubernetes manifestlerini ilgili kümeye dağıtan bir Cloud Build işini tetikler. Her kümenin manifesti, küme adıyla aynı adı taşıyan ayrı bir klasörde bulunur.

Altı küme adı şunlardır:

1. gke-asm-1-r1-prod: 1. bölgedeki bölgesel işlemler kümesi
2. gke-asm-2-r2-prod: 2. bölgedeki bölgesel işlemler kümesi
3. gke-1-apps-r1a-prod: 1. bölge a alt bölgesindeki uygulama kümesi
4. gke-2-apps-r1b-prod: 1. bölge b alanındaki uygulama kümesi
5. gke-3-apps-r2a-prod: 2. bölge a alanındaki uygulama kümesi
6. gke-4-apps-r2b-prod: 2. bölge b alanındaki uygulama kümesi

k8s_repo, bu kümelerle eşleşen klasörlere sahip. Bu klasörlere yerleştirilen tüm manifestler ilgili GKE kümesine uygulanır. Her kümenin manifestleri, yönetim kolaylığı için alt klasörlere (kümenin ana klasöründe) yerleştirilir. Bu atölye çalışmasında, dağıtılan kaynakları takip etmek için Kustomize'ı kullanacaksınız. Daha fazla bilgi için lütfen Kustomize'ın resmi belgelerine bakın.

7. Örnek Uygulamayı Dağıtma

Amaç: Hipster Shop uygulamasını uygulama kümelerine dağıtma

• k8s-repo klonu
• Hipster mağazası manifestlerini tüm uygulama kümelerine kopyalayın
• Operasyon kümelerinde Hipster shop uygulaması için hizmet oluşturma
• Global bağlantıyı test etmek için operasyon kümelerinde loadgenerators kurulumu
• Hipster shop uygulamasına güvenli bağlantıyı doğrulama

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

İşlemler projesi kaynak deposunu klonlayın

İlk Terraform altyapı derlemesinin bir parçası olarak k8s-repo, ops projesinde zaten oluşturulmuştur.

1. Git deposu için boş bir dizin oluşturun:

mkdir $WORKDIR/k8s-repo
 

2. Git deposunu başlatın, uzaktan ekleyin ve ana dalı uzaktan depodan çekin:

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. Yerel Git yapılandırmasını ayarlayın.

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

Manifestleri kopyalama, commit ve push işlemleri

4. Hipster Shop ad alanlarını ve hizmetlerini tüm kümeler için kaynak depoya kopyalayın.

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. kustomization.yaml adlı uygulama klasörünü tüm kümelere kopyalayın.

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. Hipster Shop Deployments, RBAC ve PodSecurityPolicy'yi uygulama kümeleri için kaynak depoya kopyalayın.

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. Cartservice dağıtımını, rbac'yi ve podsecuritypolicy'yi bir geliştirme kümesi hariç tüm kümelerden kaldırın. Hipstershop, çok kümeli dağıtım için oluşturulmadığından tutarsız sonuçları önlemek için yalnızca bir cartservice kullanıyoruz.

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. Yalnızca ilk geliştirme kümesinde kustomization.yaml dosyasına cartservice dağıtımını, rbac'yi ve podsecuritypolicy'yi ekleyin.

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. Podsecuritypolicies, deployments ve rbac dizinlerini ops kümelerinin kustomization.yaml dosyasından kaldırın.

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. RBAC manifest'lerindeki PROJECT_ID'yi değiştirin.

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. IngressGateway ve VirtualService manifestlerini, operasyon kümeleri için kaynak depoya kopyalayın.

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. Config Connector kaynaklarını her projedeki kümelerden birine kopyalayın.

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. Config Connector manifestlerindeki PROJECT_ID'yi değiştirin.

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. loadgenerator manifestlerini (Deployment, PodSecurityPolicy ve RBAC) operasyon kümelerine kopyalayın. Hipster Shop uygulaması, global bir Google Cloud Yük Dengeleyici (GCLB) kullanılarak kullanıma sunulur. GCLB, istemci trafiğini (frontend için) alır ve hizmetin en yakın örneğine gönderir. Her iki işlem kümesine loadgenerator yerleştirmek, trafiğin işlem kümelerinde çalışan her iki Istio giriş ağ geçidine gönderilmesini sağlar. Yük dengeleme, aşağıdaki bölümde ayrıntılı olarak açıklanmıştır.

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. Her iki işlem kümesi için loadgenerator manifest'lerindeki işlem projesi kimliğini değiştirin.

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. Her iki işlem kümesi için de loadgenerator kaynaklarını kustomization.yaml dosyasına ekleyin.

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. k8s-repo için taahhütte bulunun.

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

18. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu görüntüleyin:

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

Uygulama dağıtımını doğrulama

19. Alışveriş sepeti hariç tüm uygulama ad alanlarındaki pod'ların tüm geliştirme kümelerinde Çalışıyor durumunda olduğunu doğrulayın.

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. Yalnızca ilk geliştirme kümesinde, sepet ad alanındaki kapsüllerin Çalışıyor durumunda olduğunu doğrulayın.

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

Hipster Shop uygulamasına erişme

Küresel yük dengeleme

Artık Hipster Shop uygulaması dört uygulama kümesinin tümüne dağıtıldı. Bu kümeler iki bölgede ve dört alt bölgede yer almaktadır. Müşteriler, frontend hizmetine erişerek Hipster shop uygulamasına erişebilir. frontend hizmeti, dört uygulama kümesinin tamamında çalışır. İstemci trafiğini frontend hizmetinin dört örneğine de yönlendirmek için Google Cloud Load Balancer ( GCLB) kullanılır.

Istio Ingress ağ geçitleri yalnızca işlem kümelerinde çalışır ve bölgedeki iki bölgesel uygulama kümesi için bölgesel yük dengeleyici görevi görür. GCLB, küresel kullanıcı arabirimi hizmetinin arka uçları olarak iki Istio giriş ağ geçidini (iki işlem kümesinde çalışır) kullanır. Istio Ingress ağ geçitleri, GCLB'den gelen istemci trafiğini alır ve ardından istemci trafiğini uygulama kümelerinde çalışan ön uç pod'larına gönderir.

Alternatif olarak, Istio Ingress ağ geçitlerini doğrudan uygulama kümelerine yerleştirebilirsiniz. GCLB, bunları arka uç olarak kullanabilir.

GKE Autoneg denetleyicisi

Istio Ingress ağ geçidi Kubernetes hizmeti, ağ uç noktası gruplarını (NEG'ler) kullanarak kendisini GCLB'ye arka uç olarak kaydeder. NEG'ler, GCLB'ler kullanılarak container'da yerel yük dengeleme yapılmasını sağlar. NEG'ler, bir Kubernetes hizmetinde özel bir ek açıklama aracılığıyla oluşturulur. Bu nedenle, NEG denetleyicisine kaydedilebilir. Autoneg denetleyicisi, NEG'lerin oluşturulmasını otomatikleştiren ve hizmet ek açıklamalarını kullanarak bunları GCLB'ye arka uç olarak atayan özel bir GKE denetleyicisidir. Istio giriş ağ geçitleri de dahil olmak üzere Istio kontrol düzlemleri, ilk altyapı Terraform Cloud Build sırasında dağıtılır. GCLB ve autoneg yapılandırması, ilk Terraform altyapısı Cloud Build'in bir parçası olarak yapılır.

Cloud Endpoints ve yönetilen sertifikaları kullanarak güvenli giriş

frontend GCLB hizmetine yönelik istemci trafiğini güvenli hale getirmek için GCP tarafından yönetilen sertifikalar kullanılır. GCLB, küresel frontend hizmeti için yönetilen sertifikaları kullanır ve sertifika GCLB'de sonlandırılır. Bu atölye çalışmasında, yönetilen sertifika için alan olarak Cloud Endpoints'i kullanacaksınız. Alternatif olarak, GCP tarafından yönetilen sertifikalar oluşturmak için alanınızı ve frontend için bir DNS adı kullanabilirsiniz.

21. Hipster mağazasına erişmek için aşağıdaki komutun bağlantı çıkışını tıklayın.

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

22. Chrome sekmenizin URL çubuğundaki kilit simgesini tıklayarak sertifikanın geçerli olup olmadığını kontrol edebilirsiniz.

Küresel yük dengelemeyi doğrulama

Uygulama dağıtımı kapsamında, GCLB Hipster shop Cloud Endpoints bağlantısına test trafiği oluşturan her iki işlem kümesine de yük oluşturucular dağıtıldı. GCLB'nin trafik aldığını ve her iki Istio Ingress ağ geçidine de gönderdiğini doğrulayın.

23. Hipster Shop GCLB'nin oluşturulduğu operasyon projesi için GCLB > İzleme bağlantısını alın.

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. Aşağıda gösterildiği gibi, Backend açılır menüsünden All backends (Tüm arka uçlar) seçeneğini istio-ingressgateway olarak değiştirin.

25. Trafiğin istio-ingressgateways sürümüne gittiğini unutmayın.

istio-ingressgateway başına üç NEG oluşturulur. İşlemler kümeleri bölgesel kümeler olduğundan bölgedeki her alt bölge için bir NEG oluşturulur. Ancak istio-ingressgateway pod'ları bölge başına tek bir bölgede çalışır. Trafiğin istio-ingressgateway kapsüllerine gittiği gösterilir.

Yük oluşturucular, bulundukları iki bölgeden gelen istemci trafiğini simüle ederek her iki işlem kümesinde de çalışır. İşlemler kümesi bölgesi 1'de oluşturulan yük, bölge 2'deki istio-ingressgateway'ya gönderiliyor. Benzer şekilde, ops kümesi bölgesi 2'de oluşturulan yük, bölge 2'deki istio-ingressgateway'ya gönderiliyor.

8. Stackdriver ile gözlemlenebilirlik

Amaç: Istio telemetrisini Stackdriver'a bağlayın ve doğrulayın.

• istio-telemetry kaynaklarını yükleme
• Istio Hizmetleri kontrol panellerini oluşturma/güncelleme
• Kapsayıcı günlüklerini görüntüleme
• Stackdriver'da dağıtılmış izlemeyi görüntüleme

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Istio'nun temel özelliklerinden biri yerleşik gözlemlenebilirliktir ("o11y"). Bu sayede, operatörler kara kutu olan ve enstrüman içermeyen kapsayıcılarla bile bu kapsayıcılara giren ve çıkan trafiği gözlemleyebilir ve müşterilere hizmet sunabilir. Bu gözlem, metrikler, günlükler ve izler olmak üzere birkaç farklı yöntemle yapılır.

Ayrıca Hipster Shop'taki yerleşik yük oluşturma sisteminden de yararlanacağız. Gözlemlenebilirlik, trafik olmayan statik bir sistemde çok iyi çalışmaz. Bu nedenle yük oluşturma, nasıl çalıştığını görmemize yardımcı olur. Bu yükleme zaten çalışıyor. Artık yalnızca görebileceğiz.

1. istio-to-stackdriver yapılandırma dosyasını yükleyin.

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. k8s-repo'ya commit edin.

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

3. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu görüntüleyin:

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

4. Istio → Stackdriver entegrasyonunu doğrulama Stackdriver Handler CRD'yi alın.

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

Çıkışta stackdriver adlı bir işleyici gösterilmelidir:

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

5. Istio metriklerinin Stackdriver'a aktarılmasının çalıştığını doğrulayın. Bu komutun çıktısını tıklayın:

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

Ops projesinin adını taşıyan yeni bir Çalışma Alanı oluşturmanız istenir. Tamam'ı seçmeniz yeterlidir. Yeni kullanıcı arayüzüyle ilgili bir istem gösterilirse iletişim kutusunu kapatmanız yeterlidir.

Metrik Gezgini'ndeki "Kaynak türünü ve metriği bul" bölümünde "istio" yazarak "Kubernetes Container" kaynak türünde "Sunucu İsteği Sayısı" gibi seçeneklerin olduğunu görebilirsiniz. Bu, metriklerin ağdan Stackdriver'a aktığını gösterir.

(Aşağıdaki satırları görmek istiyorsanız destination_service_name etiketine göre gruplandırmanız gerekir.)

Metrikleri kontrol panelleriyle görselleştirme:

Metriklerimiz Stackdriver APM sisteminde olduğuna göre, bunları görselleştirmenin bir yolunu bulmamız gerekiyor. Bu bölümde, dört "Altın Sinyal" metriğinden üçünü gösteren önceden oluşturulmuş bir kontrol paneli yükleyeceğiz: Trafik (saniyedeki istek sayısı), Gecikme (bu örnekte, %99 ve %50 yüzdelik dilimi) ve Hatalar (bu örnekte Doygunluk metriğini hariç tutuyoruz).

Istio'nun Envoy proxy'si bize çeşitli metrikler sunar ancak başlangıç için bu metrikler iyi bir seçenektir. (Kapsamlı listeyi burada bulabilirsiniz). Her metriğin, filtreleme ve toplama için kullanılabilecek bir dizi etiketi olduğunu unutmayın. Örneğin: destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total vb.

6. Şimdi de önceden hazırlanmış metrikler kontrol panelimizi ekleyelim. Kontrol Paneli API'sini doğrudan kullanacağız. Bu, normalde API çağrılarını manuel olarak oluşturarak yapmayacağınız bir işlemdir. Otomasyon sisteminin bir parçası olur veya kontrol panelini web kullanıcı arayüzünde manuel olarak oluşturursunuz. Bu sayede hızlı bir başlangıç yapabiliriz:

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. Yeni eklenen "Hizmetler kontrol paneli"ni görüntülemek için aşağıdaki çıkış bağlantısına gidin.

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

Kontrol panelini kullanıcı deneyimini kullanarak yerinde düzenleyebiliriz ancak bu örnekte API'yi kullanarak hızlıca yeni bir grafik ekleyeceğiz. Bunu yapmak için kontrol panelinin en son sürümünü çekmeniz, düzenlemelerinizi uygulamanız ve ardından HTTP PATCH yöntemini kullanarak tekrar göndermeniz gerekir.

8. İzleme API'sini sorgulayarak mevcut bir kontrol panelini alabilirsiniz. Yeni eklenen mevcut kontrol panelini alma:

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. Yeni bir grafik ekleme: (50. yüzdelik dilim gecikmesi): [ API referansı] Artık kontrol panelimize kodla yeni bir grafik widget'ı ekleyebiliriz. Bu değişiklik, diğer geliştiriciler tarafından incelenebilir ve sürüm kontrolüne eklenebilir. %50'lik gecikmeyi (ortanca gecikme) gösteren bir widget'ı aşağıda bulabilirsiniz.

Yeni aldığınız kontrol panelini düzenlemeyi deneyin ve yeni bir kıta ekleyin:

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. Mevcut hizmetler kontrol panelini güncelleme:

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. Aşağıdaki çıkış bağlantısına giderek güncellenen kontrol panelini görüntüleyin:

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

12. Basit günlük analizi yapın.

Istio, ağdaki tüm trafik için bir dizi yapılandırılmış günlük sağlar ve bunları Stackdriver Logging'e yükleyerek tek bir güçlü araçta kümeler arası analiz yapılmasına olanak tanır. Günlüklere küme, kapsayıcı, uygulama, connection_id gibi hizmet düzeyinde meta veriler eklenir.

Örnek bir günlük girişi (bu örnekte Envoy proxy'nin accesslog'u) şu şekilde görünebilir (kırpılmış):

*** 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" 
...  
 }

Günlüklerinizi buradan görüntüleyebilirsiniz:

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

Kaynak > Kubernetes Container'ı seçip "pilot" araması yaparak Istio'nun kontrol düzlemi günlüklerini görüntüleyebilirsiniz:

Burada, Istio kontrol düzleminin her örnek uygulama hizmeti için yardımcı dosya proxy'lerine proxy yapılandırması gönderdiğini görebiliriz. "CDS", "LDS" ve "RDS", farklı Envoy API'lerini temsil eder ( daha fazla bilgi).

Istio'nun günlüklerinin yanı sıra kapsayıcı günlüklerini ve altyapı ya da diğer GCP hizmetlerinin günlüklerini de aynı arayüzde bulabilirsiniz. GKE için bazı örnek günlük sorgularını aşağıda bulabilirsiniz. Günlük görüntüleyici, günlüklerden metrikler (ör. "belirli bir dizeyle eşleşen her hatayı say") oluşturmanıza da olanak tanır. Bu metrikler bir kontrol panelinde veya uyarı kapsamında kullanılabilir. Günlükler, BigQuery gibi diğer analiz araçlarına da aktarılabilir.

Hipster mağazası için bazı örnek filtreler:

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

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

13. Dağıtılmış İzlemeler'e göz atın.

Artık dağıtılmış bir sistemle çalıştığınız için hata ayıklama işleminde yeni bir araç kullanmanız gerekir: Dağıtılmış İzleme. Bu araç, hizmetlerinizin nasıl etkileşim kurduğuyla ilgili istatistikleri (ör. aşağıdaki resimde gösterildiği gibi aykırı yavaş etkinlikleri bulma) keşfetmenize ve neler olduğunu ayrıntılı olarak incelemek için ham örnek izlere girmenize olanak tanır.

Zaman Çizelgesi Görünümü, tüm istekleri zaman içinde gösterir. Bu istekler, gecikme sürelerine veya ilk istekten Hipster yığını üzerinden geçip son olarak son kullanıcıya yanıt verilene kadar geçen süreye göre grafiklendirilir. Noktalar ne kadar yukarıda olursa kullanıcının deneyimi o kadar yavaş (ve daha az memnuniyet verici!) olur.

Belirli bir isteğin ayrıntılı şelale görünümünü görmek için bir noktayı tıklayabilirsiniz. Belirli bir isteğin işlenmemiş ayrıntılarını (yalnızca toplu istatistikler değil) bulabilme özelliği, hizmetler arasındaki etkileşimi anlamak için çok önemlidir. Özellikle hizmetler arasındaki nadir ancak kötü etkileşimleri tespit etmek için bu özellikten yararlanılır.

Şelale görünümü, hata ayıklayıcı kullanan herkesin aşina olduğu bir görünümdür. Ancak bu durumda, tek bir uygulamanın farklı işlemlerinde harcanan süreyi göstermek yerine, ayrı kapsayıcılarda çalışan hizmetler arasında ağımızda gezinirken harcanan süre gösterilir.

İzlerinizi burada bulabilirsiniz:

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

Aracın örnek ekran görüntüsü:

9. Karşılıklı TLS kimlik doğrulaması

Amaç: Mikro hizmetler arasında güvenli bağlantı (kimlik doğrulama)

• Ağ genelinde mTLS'yi etkinleştirme
• Günlükleri inceleyerek mTLS'yi doğrulama

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Uygulamalarımız yüklendiğine ve Observability ayarlandığına göre artık hizmetler arasındaki bağlantıları güvenli hale getirmeye başlayabilir ve çalışmaya devam etmesini sağlayabiliriz.

Örneğin, Kiali kontrol panelinde hizmetlerimizin MTLS kullanmadığını görebiliriz ("kilit" simgesi yok). Ancak trafik akıyor ve sistem sorunsuz çalışıyor. StackDriver Golden Metrics kontrol panelimiz, genel olarak her şeyin çalıştığı konusunda bize biraz rahatlık veriyor.

1. Operasyon kümelerinde MeshPolicy'yi kontrol edin. mTLS'nin hem şifrelenmiş hem de mTLS dışı trafiğe PERMISSIVE izin verdiğini unutmayın.

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, IstioControlPlane özel kaynağını (CR) kullanan Istio operatörü kullanılarak tüm kümelerde yapılandırılır. IstioControlPlane CR'yi ve k8s-repo'yu güncelleyerek tüm kümelerde mTLS'yi yapılandıracağız. IstioControlPlane CR'de global > mTLS > enabled: true ayarlandığında Istio kontrol düzleminde aşağıdaki iki değişiklik yapılır:

• MeshPolicy, tüm kümelerde çalışan tüm hizmetler için mTLS'yi ağ genelinde etkinleştirecek şekilde ayarlanır.
• Tüm kümelerde çalışan hizmetler arasında ISTIO_MUTUAL trafiğine izin vermek için bir DestinationRule oluşturulur.

2. Küme genelinde mTLS'yi etkinleştirmek için istioControlPlane CR'ye bir kustomize yaması uygulayacağız. Yamanın tüm kümeler için ilgili dizine kopyalayın ve bir kustomize yaması ekleyin.

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. k8s-repo'ya commit edin.

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

4. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu görüntüleyin:

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

 

mTLS'yi doğrulama

5. İşlem kümelerinde MeshPolicy'yi bir kez daha kontrol edin. Not: mTLS artık PERMISSIVE değildir ve yalnızca mTLS trafiğine izin verir.

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

Çıkış (kopyalamayın):

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

6. Istio operatör denetleyicisi tarafından oluşturulan DestinationRule'u açıklayın.

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'

Çıkış (kopyalamayın):

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

Günlüklerde HTTP'den HTTPS'ye geçişi de görebiliriz.

Bir günlük girişini ve ardından görüntülemek istediğiniz alanın değerini tıklayarak bu alanı kullanıcı arayüzündeki günlüklerde gösterebiliriz. Bizim durumumuzda, "protocol:" ifadesinin yanındaki "http"yi tıklayın.

Bu sayede, geçişi güzel bir şekilde görselleştirebilirsiniz:

10. Canary dağıtımları

Amaç: Ön uç hizmetinin yeni bir sürümünü kullanıma sunma.

• frontend-v2 (sonraki üretim sürümü) hizmetini bir bölgede kullanıma sunma
• Trafiği yavaş yavaş frontend-v2'ye yönlendirmek için DestinationRules ve VirtualServices'yi kullanın.
• k8s-repo öğesine yapılan bir dizi commit'i inceleyerek GitOps dağıtım hattını doğrulayın.

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Canary dağıtımı, yeni bir hizmetin kademeli olarak kullanıma sunulmasıdır. Canary dağıtımında, yeni sürüme gönderdiğiniz trafik miktarı artarken kalan yüzdeyi mevcut sürüme göndermeye devam edersiniz. Yaygın bir yöntem, trafik bölmenin her aşamasında kanarya analizi yapmak ve yeni sürümün "altın sinyallerini" (gecikme, hata oranı, doygunluk) bir referans değerle karşılaştırmaktır. Bu sayede kesintiler önlenir ve trafik bölme işleminin her aşamasında yeni "v2" hizmetinin kararlılığı sağlanır.

Bu bölümde, ön uç hizmetinin yeni bir sürümü için temel bir canary dağıtımı oluşturmak üzere Cloud Build ve Istio trafik politikalarını nasıl kullanacağınızı öğreneceksiniz.

İlk olarak, DEV1 bölgesinde (us-west1) Canary ardışık düzenini çalıştırıp bu bölgedeki her iki kümede de frontend v2'yi kullanıma sunacağız. İkinci olarak, DEV2 bölgesinde (us-central) Canary ardışık düzenini çalıştırıp v2'yi bu bölgedeki her iki kümeye de dağıtacağız. Boru hattını tüm bölgelerde paralel olarak değil, bölgelerde sırayla çalıştırmak, kötü yapılandırmadan veya v2 uygulamasındaki hatalardan kaynaklanan küresel kesintileri önlemeye yardımcı olur.

Not: Her iki bölgede de canary ardışık düzenini manuel olarak tetikleyeceğiz ancak Production'da, örneğin bir kayıt otoritesine gönderilen yeni bir Docker görüntüsü etiketine dayalı olarak otomatik bir tetikleyici kullanırsınız.

1. Cloud Shell'den, komutların geri kalanını çalıştırmayı kolaylaştırmak için bazı ortam değişkenleri tanımlayın.

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

2. Temel manifestleri k8s-repo'ya kopyalamak için repo_setup.sh komut dosyasını çalıştırın.

$CANARY_DIR/repo-setup.sh 
 

Aşağıdaki manifestler kopyalanır:

• frontend-v2 dağıtımı
• frontend-v1 yaması ("v1" etiketini ve "/version" uç noktasına sahip bir resmi içerecek şekilde)
• HTTP yanıt dağıtımını yazdıracak ve kanarya dağıtımını gerçek zamanlı olarak görselleştirmemize yardımcı olacak küçük bir pod olan respy.
• ön uç Istio DestinationRule: "version" dağıtım etiketine göre ön uç Kubernetes hizmetini v1 ve v2 olmak üzere iki alt kümeye böler
• Ön uç Istio VirtualService: Trafiğin% 100'ünü ön uç v1'e yönlendirir. Bu, Kubernetes Service'in varsayılan sıralı dağıtım davranışını geçersiz kılar. Bu davranış, tüm Dev1 bölgesel trafiğinin% 50'sini hemen frontend v2'ye gönderir.

3. k8s_repo'da değişiklikleri işleme:

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

4. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu görüntüleyin:

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

5. OPS1 projesi için konsolda Cloud Build'e gidin. Cloud Build işlem hattının tamamlanmasını bekleyin, ardından her iki DEV1 kümesinde de ön uç ad alanındaki pod'ları alın. Aşağıdaki ekranı görmeniz gerekir:

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

Not: İzleme komutlarından çıkmak için Ctrl-C tuşlarına basın.

Cloud Shell penceremizi 2 bölmeye ayırmak için tmux'i kullanacağız:

• Alttaki bölmede, ön uç hizmetinin HTTP yanıt dağıtımını gözlemlemek için watch komutu çalıştırılacaktır.
• Üst bölmede gerçek canary işlem hattı komut dosyası çalıştırılır.

6. Cloud Shell penceresini bölmek için komutu çalıştırın ve watch komutunu alt bölmede yürütün.

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"
 

Çıkış (kopyalamayın)

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

Tüm trafiğin, yeni VirtualService'te tanımlanan frontend v1 dağıtımına gittiğini görüyoruz.

7. Canary ardışık düzenini Dev1 bölgesinde yürütün. VirtualService'teki frontend-v2 trafiği yüzdelerini güncelleyen bir komut dosyası sağlıyoruz (ağırlıkları %20, %50, %80 ve ardından %100 olarak günceller). Komut dosyası, güncellemeler arasında Cloud Build işlem hattının tamamlanmasını bekler. Dev1 bölgesi için canary dağıtım komut dosyasını çalıştırın. Not: Bu komut dosyasının tamamlanması yaklaşık 10 dakika sürer.

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

Trafik bölme işlemini, respy komutunu çalıştırdığınız alttaki pencerede anlık olarak görebilirsiniz. Örneğin, %20 işaretinde :

Çıkış (kopyalamayın)

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

8. Dev2'nin frontend-v2 için kullanıma sunulması tamamlandığında komut dosyasının sonunda başarı mesajı görmeniz gerekir:

    Output (do not copy) 
   

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

9. Ayrıca, bir Dev2 pod'undan gelen tüm ön uç trafiği frontend-v2'ye yönlendirilmelidir:

    Output (do not copy) 
   

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

10. Bölünmüş bölmeyi kapatın.

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

11. Oluşturulan bağlantıdan Cloud Source Repos'a gidin.

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

Her trafik yüzdesi için ayrı bir onaylama görmeniz gerekir. En son onaylama listenin en üstünde yer alır:

Şimdi de aynı işlemi Dev2 bölgesi için tekrarlayacaksınız. Dev2 bölgesinin v1'de hâlâ "kilitli" olduğunu unutmayın. Bunun nedeni, temel repo_setup komut dosyasında tüm trafiği açıkça v1'e göndermek için bir VirtualService'in gönderilmesidir. Bu sayede, yeni sürümü küresel olarak kullanıma sunmadan önce Dev1'de bölgesel bir kontrollü sürüm yayınlama işlemini güvenli bir şekilde gerçekleştirebildik ve başarılı bir şekilde çalıştığından emin olduk.

12. Cloud Shell penceresini bölmek için komutu çalıştırın ve watch komutunu alt bölmede yürütün.

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"
 

Çıkış (kopyalamayın)

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

Tüm trafiğin, yeni VirtualService'te tanımlanan frontend v1 dağıtımına gittiğini görüyoruz.

13. Canary ardışık düzenini Dev2 bölgesinde yürütün. VirtualService'teki frontend-v2 trafiği yüzdelerini güncelleyen bir komut dosyası sağlıyoruz (ağırlıkları %20, %50, %80 ve ardından %100 olarak günceller). Komut dosyası, güncellemeler arasında Cloud Build işlem hattının tamamlanmasını bekler. Dev1 bölgesi için canary dağıtım komut dosyasını çalıştırın. Not: Bu komut dosyasının tamamlanması yaklaşık 10 dakika sürer.

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

Çıkış (kopyalamayın)

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

14. Dev2'deki Respy pod'undan, Dev2 pod'larındaki trafiğin kademeli olarak frontend v1'den v2'ye geçişini izleyin. Komut dosyası tamamlandığında şunları görürsünüz:

Çıkış (kopyalamayın)

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

15. Bölünmüş bölmeyi kapatın.

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

Bu bölümde, bölgesel erken erişim dağıtımları için Istio'nun nasıl kullanılacağı açıklanmıştır. Üretim ortamında, manuel komut dosyası yerine bu canary komut dosyasını Cloud Build ardışık düzeni olarak otomatik olarak tetikleyebilirsiniz. Bunun için, kapsayıcı kayıt defterine aktarılan yeni etiketli bir görüntü gibi bir tetikleyici kullanabilirsiniz. Ayrıca, daha fazla trafik göndermeden önce her adımın arasına kanarya analizi ekleyerek v2'nin gecikme süresini ve hata oranını önceden tanımlanmış bir güvenlik eşiğine göre analiz etmeniz de gerekir.

11. Yetkilendirme Politikaları

Amaç: Mikro hizmetler arasında RBAC (AuthZ) ayarlama.

• Bir mikro hizmete erişimi REDDETMEK için AuthorizationPolicy oluşturun.
• Bir mikro hizmete belirli erişim izni VERMEK için AuthorizationPolicy oluşturun.

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Tek bir yerde çalıştırılabilecek monolitik bir uygulamanın aksine, küresel olarak dağıtılmış mikro hizmet uygulamaları ağ sınırları arasında çağrı yapar. Bu durum, uygulamalarınıza daha fazla giriş noktası ve kötü amaçlı saldırılar için daha fazla fırsat anlamına gelir. Ayrıca Kubernetes pod'larının geçici IP'leri olduğundan, iş yükleri arasındaki erişimi güvenli hale getirmek için geleneksel IP tabanlı güvenlik duvarı kuralları artık yeterli değildir. Mikro hizmet mimarisinde güvenliğe yeni bir yaklaşım gerekir. Istio, hizmet hesapları gibi Kubernetes güvenlik yapı taşlarını temel alarak uygulamalarınız için esnek bir güvenlik politikaları grubu sağlar.

Istio politikaları hem kimlik doğrulama hem de yetkilendirmeyi kapsar. Kimlik doğrulama, kimliği doğrular (Bu sunucu, olduğunu söylediği kişi mi?) ve yetkilendirme, izinleri doğrular (Bu istemcinin bunu yapmasına izin veriliyor mu?). Istio kimlik doğrulamasını 1. modüldeki (MeshPolicy) karşılıklı TLS bölümünde ele almıştık. Bu bölümde, authorization policies'i kullanarak uygulama iş yüklerimizden biri olan currencyservice'e erişimi nasıl kontrol edeceğimizi öğreneceğiz.

İlk olarak, 4 geliştirme kümesinin tamamında bir AuthorizationPolicy dağıtacağız. Bu işlem, currencyservice'e tüm erişimi kapatacak ve ön uçta bir hataya neden olacak. Ardından, yalnızca ön uç hizmetinin currencyservice'e erişmesine izin veririz.

1. currency-deny-all.yaml içeriğini inceleyin. Bu politika, Deployment label selectors kullanarak currencyservice'e erişimi kısıtlar. spec alanının olmadığını fark edin. Bu, bu politikanın seçilen hizmete tüm erişimi reddedeceği anlamına gelir.

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

Çıkış (kopyalamayın)

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

2. Para birimi politikasını, her iki bölgedeki operasyon kümeleri için k8s-repo'ya kopyalayın.

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. Değişiklikleri aktarın.

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

4. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu kontrol edin:

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

5. Derleme başarıyla tamamlandıktan sonra aşağıdaki bağlantıyı kullanarak bir tarayıcıda hipstershop ön ucuna ulaşmayı deneyin:

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

currencyservice'ten bir yetkilendirme hatası görürsünüz:

6. Para birimi hizmetinin bu AuthorizationPolicy'yi nasıl zorunlu kıldığına bakalım. Engellenen yetkilendirme çağrıları varsayılan olarak kaydedilmediğinden, öncelikle para birimi podlarından biri için Envoy proxy'de izleme düzeyi günlüklerini etkinleştirin.

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. Para birimi hizmetinin yardımcı proxy'sinden RBAC (yetkilendirme) günlüklerini alın. "Enforced denied" (Reddetme zorunlu kılındı) mesajını görürsünüz. Bu mesaj, currencyservice'in tüm gelen istekleri engelleyecek şekilde ayarlandığını gösterir.

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

Çıkış (kopyalamayın)

[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. Şimdi de ön uca (diğer arka uç hizmetlerine değil) currencyservice'e erişim izni verelim. currency-allow-frontend.yaml dosyasını açıp içeriğini inceleyin. Aşağıdaki kuralı eklediğimizi belirtmek isteriz:

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

Çıkış (kopyalamayın)

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

Burada, para birimi hizmetine erişmek için belirli bir source.principal (istemci) izin verilenler listesine ekleniyor. Bu kaynak.principal, Kubernetes hizmet hesabı tarafından tanımlanır. Bu durumda, izin verilenler listesine eklediğimiz hizmet hesabı, ön uç ad alanındaki ön uç hizmet hesabıdır.

Not: Istio AuthorizationPolicies'de Kubernetes hizmet hesaplarını kullanırken önce 1. modülde yaptığımız gibi küme genelinde karşılıklı TLS'yi etkinleştirmeniz gerekir. Bunun nedeni, hizmet hesabı kimlik bilgilerinin isteklere yerleştirilmesini sağlamaktır.

9. Güncellenen para birimi politikasını kopyalama

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. Değişiklikleri aktarın.

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

11. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu görüntüleyin:

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

12. Derleme başarıyla tamamlandıktan sonra Hipstershop ön ucunu tekrar açın. Bu kez ana sayfada herhangi bir hata görmemeniz gerekir. Bunun nedeni, ön uca mevcut hizmete erişim izni verilmiş olmasıdır.
13. Şimdi, sepetinize ürün ekleyip "Sipariş ver"i tıklayarak ödeme yapmayı deneyin. Bu kez, para birimi hizmetinden bir fiyat dönüştürme hatası görmeniz gerekir. Bunun nedeni, yalnızca ön ucu beyaz listeye almış olmamızdır. Bu nedenle, ödeme hizmeti hala para birimi hizmetine erişememektedir.

14. Son olarak, ödeme hizmetinin para birimine erişmesine izin verelim. Bunun için currencyservice AuthorizationPolicy'mize başka bir kural ekleyelim. Para birimi erişimini yalnızca erişmesi gereken iki hizmete (ön uç ve ödeme) açtığımızı unutmayın. Diğer arka uçlar engellenmeye devam eder.
15. currency-allow-frontend-checkout.yaml dosyasını açıp içeriğini inceleyin. Kural listesinin mantıksal OR işlevi gördüğünü unutmayın. Para birimi, yalnızca bu iki hizmet hesabından birine sahip iş yüklerinden gelen istekleri kabul eder.

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

Çıkış (kopyalamayın)

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. Nihai yetkilendirme politikasını k8s-repo'ya kopyalayın.

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. Değişiklikleri gönderme

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

18. Daha önce açılmış bir sekmede veya aşağıdaki bağlantıyı tıklayarak Ops projesi Cloud Build'in durumunu görüntüleyin:

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

19. Derleme başarıyla tamamlandıktan sonra ödeme yapmayı deneyin. Ödeme işlemi başarıyla tamamlanmalıdır.

Bu bölümde, hizmet düzeyinde ayrıntılı erişim denetimini zorunlu kılmak için Istio yetkilendirme politikalarının nasıl kullanılacağı açıklanmıştır. Üretim ortamında, hizmet başına bir AuthorizationPolicy oluşturabilir ve (örneğin) aynı ad alanındaki tüm iş yüklerinin birbirine erişmesine izin vermek için bir allow-all policy (herkese izin verme politikası) kullanabilirsiniz.

12. Altyapı Ölçeklendirme

Amaç: Yeni bölgeler, projeler ve kümeler ekleyerek altyapıyı ölçeklendirme.

• infrastructure deposunu klonlayın
• Yeni kaynaklar oluşturmak için Terraform dosyalarını güncelleyin.
• Yeni bölgede 2 alt ağ (biri operasyon projesi, diğeri yeni proje için)
• Yeni bölgedeki yeni operasyon kümesi (yeni alt ağda)
• Yeni bölge için yeni Istio kontrol düzlemi
• Yeni bölgedeki yeni projede 2 uygulama kümesi
• infrastructure deposuna commit işlemi yapma
• Yüklemeyi doğrula

FAST TRACK SCRIPT

Bu yöntemi seçerseniz bu laboratuvarı tamamlamak için aşağıdaki komut dosyasını çalıştırın.

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

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Bu laboratuvar için hızlı başlangıç komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Bir platformu ölçeklendirmenin çeşitli yolları vardır. Mevcut kümelere düğüm ekleyerek daha fazla işlem gücü ekleyebilirsiniz. Bir bölgeye daha fazla küme ekleyebilirsiniz. Alternatif olarak, platforma daha fazla bölge ekleyebilirsiniz. Platformun hangi yönünün ölçeklendirileceğine ilişkin karar, gereksinimlere bağlıdır. Örneğin, bir bölgedeki üç alt bölgenin tümünde kümeleriniz varsa mevcut kümeye daha fazla düğüm (veya düğüm havuzu) eklemek yeterli olabilir. Ancak tek bir bölgedeki üç bölgeden ikisinde kümeleriniz varsa üçüncü bölgeye yeni bir küme eklemek ölçeklendirme ve ek bir hata alanı (yani yeni bir bölge) sağlar. Bir bölgeye yeni bir küme eklemenin bir diğer nedeni de yasal düzenlemeler veya uyumluluk nedenleriyle (ör. PCI ya da kimliği tanımlayabilecek bilgileri barındıran bir veritabanı kümesi) tek kiracılı bir küme oluşturma ihtiyacı olabilir. İşletmeniz ve hizmetleriniz genişledikçe, müşterilere daha yakın hizmet sunmak için yeni bölgeler eklemeniz kaçınılmaz hale gelir.

Mevcut platform iki bölge ve bölge başına iki alt bölgedeki kümelerden oluşur. Platformu ölçeklendirmeyi iki şekilde düşünebilirsiniz:

• Dikey olarak: Daha fazla işlem gücü ekleyerek her bölgede ölçeklendirme yapabilirsiniz. Bu işlem, mevcut kümelere daha fazla düğüm (veya düğüm havuzu) eklenerek ya da bölgeye yeni kümeler eklenerek yapılır. Bu işlem, infrastructure deposu üzerinden yapılır. En basit yol, mevcut kümelere düğüm eklemektir. Ek yapılandırma gerekmez. Yeni kümeler eklemek için ek alt ağlar (ve ikincil aralıklar) gerekebilir, uygun güvenlik duvarı kuralları eklenmesi, yeni kümelerin bölgesel ASM/Istio hizmet ağı kontrol düzlemine eklenmesi ve uygulama kaynaklarının yeni kümelere dağıtılması gerekebilir.
• Yatay olarak: Daha fazla bölge ekleyerek. Mevcut platform size bölgesel bir şablon sunar. ASM/Istio kontrol düzleminin bulunduğu bölgesel bir işlem kümesi ve uygulama kaynaklarının dağıtıldığı iki (veya daha fazla) bölgesel uygulama kümesinden oluşur.

Bu atölye çalışmasında, dikey kullanım alanı adımlarını da kapsadığı için platformu "yatay" olarak ölçeklendirirsiniz. Platforma yeni bir bölge (r3) ekleyerek platformu yatay olarak ölçeklendirmek için aşağıdaki kaynakların eklenmesi gerekir:

1. Yeni işlemler ve uygulama kümeleri için r3 bölgesindeki ana makine projesi Paylaşılan VPC'sindeki alt ağlar.
2. ASM/Istio kontrol düzleminin bulunduğu r3 bölgesindeki bölgesel bir operasyon kümesi.
3. r3 bölgesindeki iki alt bölgede iki alt bölgesel uygulama kümesi.
4. k8s-repo'yu güncelleyin:
5. ASM/Istio kontrol düzlemi kaynaklarını r3 bölgesindeki operasyon kümesine dağıtın.
6. ASM/Istio paylaşılan kontrol düzlemi kaynaklarını r3 bölgesindeki uygulama kümelerine dağıtın.
7. Yeni bir proje oluşturmanız gerekmez ancak atölyedeki adımlarda, platforma yeni bir ekip ekleme kullanım alanını kapsamak için yeni bir proje (dev3) ekleme işlemi gösterilmektedir.

Altyapı deposu, yukarıda belirtilen yeni kaynakları eklemek için kullanılır.

1. Cloud Shell'de WORKDIR'e gidin ve infrastructure deposunu klonlayın.

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. Çalıştay kaynak deposunun add-proj dalını add-proj-repo dizinine klonlayın.

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

 

3. Kaynak atölye deposundaki add-proj dalından dosyaları kopyalayın. add-proj dalı, bu bölümdeki değişiklikleri içerir.

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

4. Daldaki komut dosyalarının çalıştırılmasına izin vermek için add-proj repo dizinindeki infrastructure dizinini infra-repo dizinine yönelik bir sembolik bağlantıyla değiştirin.

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

5. Paylaşılan durumları ve değişkenleri yeni proje dizin yapısına kopyalamak için add-project.sh komut dosyasını çalıştırın.

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

6. Yeni proje oluşturmak için değişiklikleri kaydedip gönderin

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

7. Commit işlemi, altyapının yeni kaynaklarla dağıtılması için infrastructure deposunu tetikler. Aşağıdaki bağlantının çıktısını tıklayıp en üstteki en son derlemeye giderek Cloud Build ilerleme durumunu görüntüleyin.

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

Bu adımın tamamlanması 25-30 dakika sürer. Kahve molası için iyi bir zaman.

infrastructure Cloud Build'in son adımında k8s-repo içinde yeni Kubernetes kaynakları oluşturulur. Bu işlem, k8s-repo (işlemler projesinde) Cloud Build'i tetikler. Yeni Kubernetes kaynakları, önceki adımda eklenen üç yeni küme içindir. ASM/Istio kontrol düzlemi ve paylaşılan kontrol düzlemi kaynakları, k8s-repo Cloud Build ile yeni kümelere eklenir.

8. Altyapı Cloud Build işlemi başarıyla tamamlandıktan sonra aşağıdaki çıkış bağlantısını tıklayarak k8s-repo en son Cloud Build çalıştırmasına gidin.

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

9. Yeni kümeleri vars ve kubeconfig dosyasına eklemek için aşağıdaki komut dosyasını çalıştırın.

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

10. KUBECONFIG değişkenini yeni kubeconfig dosyasına yönlendirecek şekilde değiştirin.

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

11. Küme bağlamlarınızı listeleyin. Sekiz küme görmeniz gerekir.

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

Istio kurulumunu doğrulama

12. Tüm pod'ların çalıştığını ve işlerin tamamlandığını kontrol ederek yeni ops kümesine Istio'nun yüklendiğinden emin olun.

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. Istio'nun her iki dev3 kümesine de yüklendiğinden emin olun. dev3 kümelerinde yalnızca Citadel, sidecar-injector ve coredns çalışır. ops-3 kümesinde çalışan bir Istio kontrol düzlemini paylaşırlar.

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

Paylaşılan kontrol düzlemleri için hizmet keşfini doğrulama

14. Gizli dizilerin, altı uygulama kümesinin tümü için tüm işlem kümelerine dağıtıldığını doğrulayın.

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

Amaç: Kargo hizmeti için devre kesici uygulamak.

• Devre kesici uygulamak için shipping hizmeti için DestinationRule oluşturun.
• Devreyi zorla açarak shipping hizmeti için devre kesiciyi doğrulamak üzere fortio (yük oluşturma yardımcı programı) kullanın.

Fast Track Script Lab Talimatları

Fast Track Script Lab çok yakında kullanıma sunulacak.

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Istio'nun etkinleştirildiği hizmetler için temel izleme ve sorun giderme stratejilerini öğrendiğimize göre, şimdi de Istio'nun hizmetlerinizin esnekliğini artırarak en başta yapmanız gereken sorun giderme işlemlerinin sayısını nasıl azalttığına bakalım.

Mikro hizmet mimarisi, bir hizmetin arızasının bağımlı hizmetlere ve bu bağımlı hizmetlerin bağımlı hizmetlerine yayılabileceği kademeli arızalar riskini ortaya çıkarır. Bu durum, son kullanıcıları etkileyebilecek bir "dalgalanma etkisi" kesintisine neden olabilir. Istio, hizmetleri yalıtmanıza yardımcı olmak için bir devre kesici trafik politikası sunar. Bu politika, aşağı akış (istemci tarafı) hizmetlerini başarısız olan hizmetleri beklemekten, yukarı akış (sunucu tarafı) hizmetlerini ise tekrar çevrimiçi olduklarında aşağı akış trafiğinin ani bir şekilde artmasından korur. Genel olarak, devre kesicileri kullanmak, tek bir arka uç hizmetinin askıda kalması nedeniyle tüm hizmetlerinizin HDS'lerini karşılayamamasına engel olabilir.

Devre kesici modeli, çok fazla elektrik akımı geçtiğinde "atabilen" ve cihazları aşırı yüklenmeye karşı koruyan bir elektrik anahtarından adını alır. Istio kurulumunda bu, Envoy'un devre kesici olduğu ve bir hizmet için bekleyen isteklerin sayısını takip ettiği anlamına gelir. Bu varsayılan kapalı durumda, istekler Envoy üzerinden kesintisiz olarak akar.

Ancak bekleyen isteklerin sayısı tanımladığınız eşiği aştığında devre kesici açılır ve Envoy hemen bir hata döndürür. Bu, sunucunun istemci için hızlı bir şekilde başarısız olmasına olanak tanır ve aşırı yüklendiğinde sunucu uygulama kodunun istemcinin isteğini almasını engeller.

Ardından, tanımladığınız zaman aşımından sonra Envoy yarı açık duruma geçer. Bu durumda sunucu, deneme süresi boyunca tekrar istek almaya başlayabilir. İsteklere başarıyla yanıt verebilirse devre kesici tekrar kapanır ve sunucuya istekler tekrar gönderilmeye başlar.

Bu şemada, Istio devre kesici deseni özetlenmektedir. Mavi dikdörtgenler Envoy'u, mavi dolgulu daire istemciyi, beyaz dolgulu daireler ise sunucu kapsayıcısını temsil eder:

Istio DestinationRules'u kullanarak devre kesici politikaları tanımlayabilirsiniz. Bu bölümde, kargo hizmeti için devre kesici uygulamak üzere aşağıdaki politikayı uygulayacağız:

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

Burada dikkat edilmesi gereken iki DestinationRule alanı vardır. connectionPool, bu hizmetin izin vereceği bağlantı sayısını tanımlar. Envoy'un devre kesiciyi açacağı eşiği nasıl belirleyeceğini yapılandırdığımız yer outlierDetection alanıdır. Burada, her saniyede (aralık), Envoy sunucu kapsayıcısından aldığı hata sayısını sayar. Bu değer consecutiveErrors eşiğini aşarsa Envoy devre kesicisi açılır ve productcatalog pod'larının% 100'ü 10 saniye boyunca yeni istemci isteklerinden korunur. Envoy devre kesicisi açıldığında (yani etkin olduğunda) istemciler 503 (Hizmet Kullanılamıyor) hataları alır. Bunu uygulamalı olarak görelim.

1. Komutları basitleştirmek için k8s-repo ve asm dizini için ortam değişkenlerini ayarlayın.

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

2. k8s-repo'yu güncelleyin

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

3. Her iki operasyon kümesinde de kargo hizmeti DestinationRule'u güncelleyin.

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. Bir Fortio yük oluşturucu pod'unu Dev1 bölgesindeki GKE_1 kümesine kopyalayın. Bu, shippingservice için devre kesiciyi "tetiklemek " üzere kullanacağımız istemci pod'udur.

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. Değişiklikleri işleyin.

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

6. Cloud Build'in tamamlanmasını bekleyin.
7. Cloud Shell'e geri dönün ve fortio pod'unu kullanarak shippingservice'e gRPC trafiği gönderin. Bu işlem için 1 eşzamanlı bağlantı ve toplamda 1.000 istek kullanın. Bu işlem, connectionPool ayarlarını henüz aşmadığımız için devre kesiciyi tetiklemeyecektir.

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 
 

Çıkış (kopyalamayın)

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

8. Şimdi eşzamanlı bağlantı sayısını 2'ye çıkararak ancak toplam istek sayısını sabit tutarak Fortio'yu tekrar çalıştırın. Devre kesici tetiklendiğinden isteklerin en fazla üçte ikisi "overflow" hatası döndürmelidir: Tanımladığımız politikada, 1 saniyelik aralıkta yalnızca 1 eşzamanlı bağlantıya izin verilir.

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 
 

Çıkış (kopyalamayın)

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, devre kesici etkin olduğunda bıraktığı bağlantıların sayısını upstream_rq_pending_overflow metriğiyle takip eder. Bunu fortio pod'unda bulalım:

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

Çıkış (kopyalamayın)

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. Devre kesici politikasını her iki bölgeden de kaldırarak temizleme

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
 

Bu bölümde, bir hizmet için tek bir devre kesici politikasının nasıl ayarlanacağı gösterilmiştir. En iyi uygulama, askıda kalma potansiyeli olan tüm yukarı akış (arka uç) hizmetleri için devre kesici ayarlamaktır. Istio devre kesici politikalarını uygulayarak mikro hizmetlerinizi yalıtmanıza, mimarinizde hataya dayanıklılık oluşturmanıza ve yüksek yük altında kademeli arıza riskini azaltmanıza yardımcı olursunuz.

14. Hata Ekleme

Amaç: Öneri hizmetinin dayanıklılığını, üretim ortamına aktarılmadan önce gecikmeler ekleyerek test edin.

• recommendation hizmeti için 5 saniyelik gecikme oluşturmak üzere VirtualService oluşturun
• fortio yük oluşturucuyu kullanarak gecikmeyi test etme
• VirtualService gecikmesini kaldırın ve doğrulayın

Fast Track Script Lab Talimatları

Fast Track Script Lab çok yakında kullanıma sunulacak.

Kopyalama ve Yapıştırma Yöntemi Lab Talimatları

Hizmetlerinize devre kesici politikaları eklemek, üretimdeki hizmetlere karşı dayanıklılık oluşturmanın bir yoludur. Ancak devre kesme, hatalara (kullanıcıya yönelik hatalar da dahil) neden olur ve bu durum ideal değildir. Bu hata durumlarını önceden tespit etmek ve arka uçlar hata döndürdüğünde aşağı akış hizmetlerinizin nasıl yanıt vereceğini daha iyi tahmin etmek için hazırlama ortamında kaos testi uygulayabilirsiniz. Kaos testi, sistemdeki zayıf noktaları analiz etmek ve hata toleransını artırmak için hizmetlerinizi kasıtlı olarak bozma uygulamasıdır. Ayrıca, arka uçlar başarısız olduğunda kullanıcıya yönelik hataları azaltmanın yollarını belirlemek için de kaos testi kullanabilirsiniz. Örneğin, ön uçta önbelleğe alınmış bir sonuç görüntüleyebilirsiniz.

Hata yerleştirme için Istio kullanmak, üretim sürümü resimlerinizi kullanabileceğiniz ve kaynak kodu değiştirmek yerine hatayı ağ katmanına ekleyebileceğiniz için faydalıdır. Üretim aşamasında, ağ katmanına ek olarak Kubernetes/işlem katmanındaki esnekliği test etmek için tam teşekküllü bir kaos testi aracı kullanabilirsiniz.

"Hata" alanına sahip bir VirtualService uygulayarak kaos testi için Istio'yu kullanabilirsiniz. Istio iki tür hatayı destekler: Gecikme hataları (zaman aşımı ekleme) ve iptal hataları (HTTP hataları ekleme). Bu örnekte, öneriler hizmetine 5 saniyelik gecikme hatası ekleyeceğiz. Ancak bu kez, bu askıda kalma hizmetine karşı "hızlı hata verme" için devre kesici kullanmak yerine, aşağı akış hizmetlerinin tam zaman aşımına dayanmasını zorlayacağız.

11. Hata yerleştirme dizinine gidin.

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

12. İçeriğini incelemek için k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml dosyasını açın. Istio'nun, hatayı isteklerin belirli bir yüzdesine yerleştirme seçeneği olduğunu unutmayın. Burada, tüm recommendationservice isteklerine zaman aşımı uygulayacağız.

Çıkış (kopyalamayın)

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. VirtualService'i k8s_repo'ya kopyalayın. Hata, her iki bölgede de dünya genelinde uygulanacak.

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. Değişiklikleri gönderme

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

15. Cloud Build'in tamamlanmasını bekleyin.
16. Devre kesici bölümünde dağıtılan fortio kapsülüne girin ve recommendationservice'e biraz trafik gönderin.

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:

Çıkış (kopyalamayın)

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. Enjekte ettiğimiz hatayı işlem gerçekleştirirken görmenin bir başka yolu da ön ucu bir web tarayıcısında açıp herhangi bir ürünü tıklamaktır. Bir ürün sayfası, sayfanın en altında gösterilen önerileri getirdiği için 5 saniye daha uzun sürede yüklenir.
18. Hata yerleştirme hizmetini her iki işlem kümesinden de kaldırarak temizleme işlemini yapın.

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. Değişiklikleri aktarma:

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

15. Istio kontrol düzlemini izleme

ASM, dört önemli kontrol düzlemi bileşeni yükler: Pilot, Mixer, Galley ve Citadel. Her biri ilgili izleme metriklerini Prometheus'a gönderir. ASM, operatörlerin bu izleme verilerini görselleştirmesine ve kontrol düzleminin durumunu ve performansını değerlendirmesine olanak tanıyan Grafana kontrol panelleriyle birlikte gelir.

Gösterge Tablolarını Görüntüleme

20. Istio ile yüklenen Grafana hizmetiniz için bağlantı noktası yönlendirme

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

21. Grafana'yı tarayıcınızda açın
22. Cloud Shell pencerenizin sağ üst köşesindeki "Web Önizlemesi" simgesini tıklayın.
23. 3000 numaralı bağlantı noktasında önizle'yi tıklayın (Not: Bağlantı noktası 3000 değilse bağlantı noktasını değiştir'i tıklayın ve 3000 numaralı bağlantı noktasını seçin).
24. Bu işlem, tarayıcınızda " BASE_URL/?orgId=1&authuser=0&environment_id=default" gibi bir URL'ye sahip sekme açar.
25. Kullanılabilir kontrol panellerini görüntüleme
26. URL'yi "BASE_URL/dashboard" olarak değiştirin.
27. Kullanılabilir kontrol panellerini görüntülemek için "istio" klasörünü tıklayın.
28. İlgili bileşenin performansını görüntülemek için bu kontrol panellerinden herhangi birini tıklayın. Aşağıdaki bölümlerde her bileşen için önemli metrikleri inceleyeceğiz.

Monitoring Pilot

Pilot, ağ ve politika yapılandırmasını veri düzlemine (Envoy proxy'leri) dağıtan kontrol düzlemi bileşenidir. Pilot, iş yüklerine gelen trafik miktarıyla değil, iş yüklerinin ve dağıtımların sayısıyla ölçeklenir. Sağlıksız bir Pilot:

• gerekenden daha fazla kaynak (CPU ve/veya RAM) tüketiyorsa
• güncellenen yapılandırma bilgilerinin Envoy'lara gönderilmesinde gecikmelere neden olur.

Not: Pilot çalışmıyorsa veya gecikmeler varsa iş yükleriniz trafiğe hizmet vermeye devam eder.

23. Pilot metriklerini görüntülemek için tarayıcınızda "BASE_URL/dashboard/db/istio-pilot-dashboard" adresine gidin.

Önemli izlenen metrikler

Kaynak Kullanımı

Kabul edilebilir kullanım sayıları için Istio Performansı ve Ölçeklenebilirlik sayfasını kılavuz olarak kullanın. Bundan çok daha fazla kaynak kullanımının devam ettiğini görürseniz GCP Destek Ekibi ile iletişime geçin.

Pilot Push Information

Bu bölüm, Envoy proxy'lerinize yapılandırma gönderme işlemlerini izler.

• Pilot Pushes, herhangi bir zamanda gönderilen yapılandırmanın türünü gösterir.
• ADS İzleme, sistemdeki sanal hizmetlerin, hizmetlerin ve bağlı uç noktaların sayısını gösterir.
• Bilinen uç noktası olmayan kümeler, yapılandırılmış ancak çalışan örneği olmayan uç noktaları gösterir (bu, *.googleapis.com gibi harici hizmetleri gösterebilir).
• Pilot hataları, zaman içinde karşılaşılan hataların sayısını gösterir.
• Çakışmalar, dinleyicilerde belirsiz yapılandırmadan kaynaklanan çakışma sayısını gösterir.

Hata veya Çakışma varsa hizmetlerinizin birinde ya da daha fazlasında hatalı veya tutarsız yapılandırma vardır. Bilgi için Veri düzlemiyle ilgili sorunları giderme başlıklı makaleye bakın.

Envoy Bilgileri

Bu bölümde, kontrol düzlemiyle iletişim kuran Envoy proxy'leri hakkında bilgiler yer alır. Tekrarlanan XDS bağlantı hataları görürseniz GCP Destek Ekibi ile iletişime geçin.

Monitoring Mixer

Mixer, Envoy proxy'lerinden gelen telemetriyi telemetri arka uçlarına (genellikle Prometheus, Stackdriver vb.) yönlendiren bileşendir. Bu kapasitede, veri düzleminde değildir. İki farklı hizmet adıyla (istio-telemetry ve istio-policy) dağıtılan iki Kubernetes işi (Mixer olarak adlandırılır) olarak dağıtılır.

Mixer, politika sistemleriyle entegrasyon için de kullanılabilir. Bu kapasitede Mixer, hizmetlerinize erişimi engellediği için politika kontrolleri Mixer'a başarısız olduğunda veri düzlemini etkiler.

Mikser, trafik hacmiyle ölçeklenir.

24. Mixer metriklerini görüntülemek için tarayıcınızda "BASE_URL/dashboard/db/istio-mixer-dashboard" adresine gidin.

Önemli izlenen metrikler

Kaynak Kullanımı

Kabul edilebilir kullanım sayıları için Istio Performansı ve Ölçeklenebilirlik sayfasını kılavuz olarak kullanın. Bundan çok daha fazla kaynak kullanımının devam ettiğini görürseniz GCP Destek Ekibi ile iletişime geçin.

Mixer'a Genel Bakış

• Yanıt Süresi önemli bir metriktir. Mixer telemetrisine yönelik raporlar veri yolunda olmasa da bu gecikmeler yüksekse kesinlikle yardımcı proxy performansını yavaşlatır. 90. yüzdelik dilimin tek haneli milisaniyeler, 99. yüzdelik dilimin ise 100 ms'nin altında olmasını bekleyebilirsiniz.

• Adapter Dispatch Duration (Adaptör Gönderme Süresi), Mixer'ın adaptörleri çağırırken (telemetri ve günlük kaydı sistemlerine bilgi gönderdiği) yaşadığı gecikmeyi gösterir. Buradaki yüksek gecikmeler, ağdaki performansı kesinlikle etkiler. Yine, p90 gecikmeleri 10 ms'nin altında olmalıdır.

İzleme Galeri

Galley, Istio'nun yapılandırma doğrulama, alma, işleme ve dağıtım bileşenidir. Kubernetes API sunucusundan Pilot'a yapılandırma iletir. Pilot gibi, sistemdeki hizmet ve uç nokta sayısıyla birlikte ölçeklenir.

25. Galley metriklerini görüntülemek için tarayıcınızda "BASE_URL/dashboard/db/istio-galley-dashboard" adresine gidin.

Önemli izlenen metrikler

Kaynak Doğrulama

Doğrulamayı geçen veya doğrulamada başarısız olan hedef kuralları, ağ geçitleri ve hizmet girişleri gibi çeşitli türlerdeki kaynakların sayısını gösteren en önemli metriktir.

Bağlı istemciler

Galley'ye kaç istemcinin bağlı olduğunu gösterir. Bu sayı genellikle 3'tür (pilot, istio-telemetry, istio-policy) ve bu bileşenler ölçeklendikçe artar.

16. Istio ile ilgili sorunları giderme

Veri düzlemiyle ilgili sorunları giderme

Pilot kontrol panelinizde yapılandırma sorunlarınız olduğu belirtiliyorsa yapılandırma sorunlarını bulmak için Pilot günlüklerini incelemeniz veya istioctl'i kullanmanız gerekir.

Pilot günlüklerini incelemek için kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery komutunu çalıştırın. istio-pilot-... kısmını, sorun gidermek istediğiniz Pilot örneğinin pod tanımlayıcısıyla değiştirin.

Oluşan günlükte Push Status (Push Durumu) mesajını arayın. Örneğin:

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="
}

Yapılandırmayı Envoy proxy'lerine göndermeye çalışırken oluşan sorunlar Push Status (Gönderme Durumu) bölümünde gösterilir. Bu durumda, "Duplicate cluster" (Küme yineleniyor) mesajları gösteriliyor. Bu mesajlar, yukarı akış hedeflerinin yinelenmiş olduğunu belirtir.

Sorunları teşhis etme konusunda yardım almak için Google Cloud Destek Ekibi ile iletişime geçin.

Yapılandırma hatalarını bulma

Yapılandırmanızı analiz etmek için istioctl'u kullanmak üzere istioctl experimental analyze -k --context $OPS_GKE_1 komutunu çalıştırın. Bu işlem, sisteminizdeki yapılandırmayı analiz eder ve önerilen değişikliklerle birlikte sorunları belirtir. Bu komutun algılayabileceği yapılandırma hatalarının tam listesi için belgelere bakın.

17. Temizleme

Aşağıdaki adımlar, atölye çalışması tamamlandıktan sonra bir yönetici tarafından gerçekleştirilir.

Yönetici, bootstrap_workshop.sh komut dosyası tarafından oluşturulan kaynakları silmek için cleanup_workshop.sh komut dosyasını çalıştırır. Temizleme komut dosyasının çalıştırılması için aşağıdaki bilgilere ihtiyacınız vardır.

• Kuruluş adı (ör. yourcompany.com)
• Atölye kimliği: YYMMDD-NN biçimindedir. Örneğin, 200131-01.
• Yönetici GCS paketi: Bootstrap komut dosyasında tanımlanır.

13. Cloud Shell'i açın ve aşağıdaki tüm işlemleri Cloud Shell'de gerçekleştirin. Aşağıdaki bağlantıyı tıklayın.

CLOUD SHELL

14. gcloud'a amaçlanan yönetici kullanıcısıyla giriş yaptığınızı doğrulayın.

gcloud config list
 

15. asm klasörüne gidin.

cd ${WORKDIR}/asm
 

16. Silinecek kuruluş adınızı ve atölye kimliğinizi tanımlayın.

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

17. Temizleme komut dosyasını aşağıdaki gibi çalıştırın.

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