Anthos Service Mesh Atölyesi: Laboratuvar Rehberi

1. ALFA ATÖLYESİ

ÖNEMLİ NOT: BU BİR ALFA ATÖLYESİDİR ve EĞİTİCİ ONAYLI BİR SINIF EĞİTİMİ OLMASI ZORUNLUDUR.

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

2. Genel Bakış

Mimari Diyagramı

Bu atölyede, GCP'de küresel olarak dağıtılan hizmetlerin üretim aşamasında nasıl ayarlanacağının açıklandığı uygulamalı bir deneyim sunulur. Kullanılan ana teknolojiler; 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ğı'dır. Bu atölyede kullanılan tüm uygulamalar ve araçlar, üretim aşamasında kullanacağınız uygulamalardı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 - Uygulamaları ASM ile yükleme, güvenliğini sağlama ve izleme
• Depo modeli: Altyapı ve Kubernetes depoları hakkında bilgi
• Laboratuvar: Örnek uygulamayı dağıtma
• Dağıtılmış Hizmetler ve Gözlemlenebilirlik
• Öğle yemeği
• Laboratuvar: Stackdriver ile Gözlemlenebilirlik
• QNA
• 2. Modül - DevOps - Canary'nin kullanıma sunulması, politika/RBAC
• Çoklu küme hizmet keşfi ve güvenliği/politikası
• Laboratuvar: Karşılıklı TLS
• Canary Dağıtımları
• Laboratuvar: Canary Dağıtımları
• Çok kümeli güvenli küresel yük dengeleme
• Ara
• Laboratuvar: Yetkilendirme Politikası
• QNA
• Modül 3 - Infra Ops - Platform yükseltmeleri
• Dağıtılmış Hizmet yapı taşları
• Laboratuvar: Altyapı Ölçeklendirme
• Sonraki adımlar

Slaytlar

Bu atölyenin slaytlarına aşağıdaki bağlantıdan ulaşabilirsiniz:

ASM Atölyesi Slaytları

Ön koşullar

Bu atölyeye devam etmeden önce aşağıdakiler gereklidir:

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.

Atölyeyi düzenleyen bir kullanıcıysanız Infrastructure Setup - User Workflow etiketli bir sonraki bölüme geçin

Önyükleme atölye komut dosyası açıklaması

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

Bootstrap atölye komut dosyası için şu girişler gereklidir:

• Kuruluş adı (örneğin, yourcompany.com): Atölye için ortamlar oluşturduğunuz kuruluştur.
• Faturalandırma Kimliği (örneğin, 12345-12345-12345): Atölye sırasında kullanılan tüm kaynakları faturalandırmak için bu faturalandırma kimliği kullanılır.
• Atölye numarası (örneğin 01) - İki haneli bir sayıdır. Bir günde birden fazla atölye gerçekleştirecek ve bunları ayrı ayrı takip etmek istiyorsanız bu özellik kullanılır. Atölye numaraları, proje kimliklerini elde etmek için de kullanılır. Ayrı atölye numaralarına sahip olmak, her seferinde benzersiz proje kimlikleri elde etmenizi kolaylaştırır. Proje kimlikleri için atölye numarasının yanı sıra bugünkü tarih de (YYMMDD biçiminde) kullanılır. Tarih ve atölye numarasının birlikte kullanılması benzersiz proje kimlikleri sağlar.
• Başlangıç kullanıcı numarası (örneğin, 1): Bu sayı, atölyedeki ilk kullanıcıyı gösterir. Örneğin, 10 kullanıcı için bir atölye oluşturmak istiyorsanız başlangıç kullanıcı numaranız 1, son kullanıcı numaranız ise 10 olabilir.
• Son kullanıcı numarası (örneğin, 10) - Bu numara, atölyedeki son kullanıcıyı belirtir. Örneğin, 10 kullanıcı için bir atölye oluşturmak istiyorsanız başlangıç kullanıcı numaranız 1, son kullanıcı numaranız ise 10 olabilir. Tek bir ortam oluşturuyorsanız (örneğin, kendiniz için) başlangıç ve son kullanıcı numarasını aynı yapın. Bu işlem, tek bir ortam oluşturur.

Proje kimliklerine tarih ve atölye numarasının yanı sıra başlangıç ve son kullanıcı numaraları da eklenir. Kullanıcı Kimlikleri (atölyeyi gerçekleştiren kullanıcılar için), başlangıç ve son kullanıcı numarasından türetilir. Kullanıcı kimlikleri User schema and permissions performing the workshop adlı bölümde açıklanmıştır.

• Yönetici GCS paketi (örneğin my-gcs-bucket-name): Atölyeyle ilgili bilgileri depolamak için bir GCS paketi kullanılır. Bu bilgiler, bootstrap atölye komut dosyası sırasında oluşturulan tüm kaynakları sorunsuzca silmek için cleanup_workshop.sh komut dosyası tarafından kullanılır. Atölye oluşturan yöneticiler bu pakette okuma/yazma izinlerine sahip olmalıdır.

Önyükleme atölye komut dosyası yukarıda verilen değerleri kullanır ve setup-terraform-admin-project.sh komut dosyasını çağıran bir sarmalayıcı komut dosyası görevi görür. Setup-terraform-admin-project.sh komut dosyası, tek bir kullanıcı için atölye ortamı oluşturur.

Atölyenin önyüklemesi için yönetici izinleri gerekli

Bu atölyede iki tür kullanıcı var. Bu atölyeyle ilgili kaynakları oluşturan ve silen ADMIN_USER. İkincisi ise atölyedeki adımları MY_USER gerçekleştiriyor. MY_USER yalnızca kendi kaynaklarına erişebiliyor. ADMIN_USER, tüm kullanıcı kurulumlarına erişebilir. Bu kurulumu kendiniz için oluşturuyorsanız ADMIN_USER ve MY_USER aynıdır. Bu atölyeyi birden fazla öğrenci için oluşturan bir eğitmenseniz ADMIN_USER ve MY_USER bilgileriniz farklı olacaktır.

ADMIN_USER için kuruluş düzeyinde aşağıdaki 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 yetkisi. Her kullanıcı, tüm kaynaklarını proje içinde içeren tek bir klasör alır.
• Kuruluş Yöneticisi
• Proje Oluşturucu: Kuruluşta proje oluşturma yetkisi.
• Proje Silici: Kuruluştaki projeleri silme yetkisi.
• Proje IAM Yöneticisi: Kuruluştaki tüm projelerde IAM kuralları oluşturma yetkisi.

Ayrıca ADMIN_USER, atölyede kullanılan Faturalandırma Kimliği için Faturalandırma Yöneticisi olmalıdır.

Atölyeyi gerçekleştiren kullanıcı şeması ve izinleri

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

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

Örneğin, sirketiniz.com adlı kuruluşunuzda, başlangıç kullanıcı numarası 1 ve son kullanıcı numarası 3 olan önyükleme atölye komut dosyasını çalıştırırsanız, 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 projelerde "Sahip" 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 fazla kullanıcı ekleme başlıklı makaleyi inceleyin.

Atölye için gereken araçlar

Bu atölyenin Cloud Shell'den başlatılması amaçlanmıştır. Bu atölye çalışmasında aşağıdaki araçlar gereklidir.

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

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

Kendiniz için atölye oluşturma (tek kullanıcı kurulumu)

1. Cloud Shell'i açın, 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 istenen Yönetici kullanıcıyla giriş yaptığınızı doğrulayın.

gcloud config list
 

3. Bir 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şunuzun adını, faturalandırma kimliğini, atölye numarasını ve atölyede kullanılacak yönetici GCS paketini 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 
 

Başlangıç ve son kullanıcı numaralarını kendiniz ayarladığınızdan bu numarayı tanımlamanıza gerek yoktur.

bootstrap_workshop.sh komut dosyası tamamlandıktan sonra, kuruluştaki her kullanıcı için bir GCP klasörü oluşturulur. Klasörün içinde bir terraform yönetici projesi oluşturulur. Bu çalıştay için gereken GCP kaynaklarının geri kalanını oluşturmak için terraform yönetici projesi kullanılacak. Terraform yönetici projesinde gerekli API'leri etkinleştirin. Terraform planlarını uygulamak için Cloud Build'i kullanırsınız. GCP'de kaynak oluşturabilmesi için Cloud Build hizmet hesabına uygun IAM rollerini verin. Son olarak Google Cloud Storage (GCS) paketinde bir uzak arka ucu yapılandırarak tüm GCP kaynakları için Terraform durumlarını depolamanız gerekir.

Terraform yönetici projesinde Cloud Build görevlerini görüntülemek için terraform yönetici proje kimliğine ihtiyacınız vardır. Bu kimlik, asm dizininizin altındaki vars/vars.sh dosyasında depolanır. Bu dizin yalnızca, atölyeyi yönetici olarak kendiniz için ayarlıyorsanız korunur.

6. Ortam değişkenlerini ayarlamak için değişkenler dosyasını kaynağı olarak kullanın

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

Birden çok kullanıcı için atölye oluşturma (çok kullanıcılı kurulum)

7. Cloud Shell'i açın, 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 istenen Yönetici kullanıcıyla giriş yaptığınızı doğrulayın.

gcloud config list
 

9. Bir 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ıç ile son kullanıcı numarasını ve atölyede kullanılacak yönetici GCS paketini 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ı alın.

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

Atölyeyi gerçekleştiren kullanıcılar buradan başlar. Tüm adımları Chrome veya Firefox'ta bir INCOGNITO penceresinde uygulayın.

Laboratuvar yolunuzu seçin

Bu atölyedeki laboratuvarlar iki yöntemden biriyle gerçekleştirilebilir:

• "Kolay hızlı geçiş etkileşimli komut dosyaları" yol
• "Her talimatı manuel olarak kopyalayıp yapıştırma" yol

Hızlı izleme komut dosyaları yöntemi, her laboratuvar için tek bir etkileşimli komut dosyası çalıştırmanıza olanak tanır. Bu komut dosyası, ilgili laboratuvardaki komutları otomatik olarak çalıştırarak laboratuvarda size yol gösterir. Komutlar, her adımın kısa ve öz açıklamalarıyla birlikte gruplar halinde çalıştırılır. Her gruptan sonra, bir sonraki komut grubuna geçmeniz istenir. Böylece laboratuvarları istediğiniz hızda çalıştırabilirsiniz. Hızlı izleme komut dosyaları ihtiyatlıdır. Yani bu komut dosyalarını birden çok kez çalıştırarak aynı sonucu alabilirsiniz.

Hızlı izleme komut dosyaları, her laboratuvarın üst kısmında aşağıda gösterildiği gibi yeşil bir kutu içinde gösterilir.

HIZLI PARÇA METNİ

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

Kopyala ve yapıştır yöntemi, komutların açıklamalarını içeren tek tek komut bloklarını kopyalayıp yapıştırmanın geleneksel bir yoludur. Bu yöntem yalnızca bir kez çalıştırılacak şekilde tasarlanmıştır. Bu yöntemde yeniden komut çalıştırmanın aynı sonuçları vereceğinin garantisi yoktur.

Laboratuvarları gerçekleştirirken lütfen iki yöntemden birini seçin.

Bir yöntem seçip bu yöntemdeki adımları gerçekleştirdikten sonra, diğer yöntemdeki adımları uygulamayın.

Fast Track Komut Dosyası Kurulumu

Hızlı izleme komut dosyasını tamamladıktan sonra laboratuvarı tamamlamış olursunuz. Kopyalama ve yapıştırma Laboratuvarı Talimatları'ndaki adımları uygulamayın.

Kullanıcı bilgilerini alma

Bu atölye, atölye yöneticisi tarafından oluşturulan geçici bir kullanıcı hesabı (veya laboratuvar hesabı) kullanılarak gerçekleştirilecektir. Atölyedeki tüm projeler laboratuvar hesabına aittir. Atölye yöneticisi, atölyeyi gerçekleştiren kullanıcıya laboratuvar hesabı kimlik bilgilerini (kullanıcı adı ve şifre) sağlar. Kullanıcının tüm projelerine laboratuvar hesabının kullanıcı adı eklenir. Örneğin, [e-mail] laboratuvar hesabı için terraform yönetici proje kimliği user001-200131-01-tf-abcde olur ve projelerin geri kalanı için bu durum devam eder. Her kullanıcı, atölye yöneticisi tarafından sağlanan laboratuvar hesabıyla giriş yapmalı ve laboratuvar hesabını kullanarak atölyeyi gerçekleştirmelidir.

Kurumsal e-postanızı (atölyeye kaydolmak için kullandığınız e-posta adresi) kontrol edin. Atölye yöneticisinden laboratuvar hesabınızın kimlik bilgilerini (ör. kullanıcı adı ve şifreyi) içeren bir e-posta almış olmanız gerekir. E-posta aşağıdaki gibi 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). Lab hesabı userXYZ@<workshop_domain>.com gibi görünüyor.
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 düğmesini tıklayın.

Bu adımda, GCP kaynaklarına erişmek üzere kullanmanız için küçük bir Linux Debian sanal makinesi sağlanır. Her hesap bir Cloud Shell sanal makinesine sahip olur. Laboratuvar hesabı hükümleriyle giriş yapar ve laboratuvar hesabı kimlik bilgilerini kullanarak giriş yapmanızı sağlar. Cloud Shell'in yanı sıra, yapılandırma dosyalarının (terraform, YAML vb.) düzenlenmesini kolaylaştıran bir Kod Düzenleyici de sağlanır. Cloud Shell ekranı varsayılan olarak Cloud Shell kabuk ortamına (altta) ve Cloud Code Düzenleyici'ye (üstte) ayrılmıştır. Sağ üst köşedeki kalem ve kabuk istemi simgeleri, bu ikisi arasında (kabuk ve kod düzenleyici) geçiş yapmanıza olanak tanır. Ayrıca ortadaki ayırıcı çubuğu (yukarı veya aşağı) sürükleyebilir ve her bir pencerenin boyutunu manuel olarak değiştirebilirsiniz. 5. Bu atölye için bir WORKDIR oluşturun. WORKDIR, bu atölyedeki tüm laboratuvarları gerçekleştireceğiniz bir klasördür. WORKDIR 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ölyede kullanılacak değişken olarak dışa aktarın. Bu, Cloud Shell'e giriş yaptığınız hesapla aynı hesaptır.

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

Not: Yöneticiyseniz ve "-sufa" kullanarak atölyeyi kendiniz oluşturduysanız veya "-yönetici-kurulum" işaretlerinden sonra MY_USER adresini, atölye projelerini oluşturmak için kullandığınız GCP hesabının e-posta adresi olarak ayarlayın.

7. Aşağıdaki komutları çalıştırarak WORKDIR ve MY_USER değişkenlerini tekrarlayarak her ikisinin de doğru şekilde ayarlandığından emin olun.

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

8. Atölye deposunu klonlayın.

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

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

Amaç: Altyapıyı 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

HIZLI PARÇA METNİ

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'nizi kaynak olarak kullanın.

source ${HOME}/.bashrc

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

ÖNEMLİ: Bu laboratuvardaki hızlı izleme komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Kullanıcı bilgilerini alma

Atölyeyi ayarlayan yöneticinin, kullanıcı adı ve şifre bilgilerini kullanıcıya vermesi gerekir. Kullanıcının tüm projelerine kullanıcı adı öneki eklenir. Örneğin [e-mail] kullanıcısı için, terraform yönetici proje kimliği user001-200131-01-tf-abcde olur ve diğer projelerin geri kalanı için bu durum devam eder. Her kullanıcı yalnızca kendi atölye ortamına erişebilir.

Atölye için gereken araçlar

Bu atölyenin Cloud Shell'den başlatılması amaçlanmıştır. Bu atölye çalışmasında aşağıdaki araçlar gereklidir.

kustomize ve pv dışındaki tüm araçlar varsayılan olarak Cloud Shell'e yüklenmiştir. Aşağıda her ikisini de yükleme talimatlarını bulabilirsiniz.

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

Terraform yönetici projesine erişim

bootstrap_workshop.sh komut dosyası tamamlandıktan sonra, kuruluştaki her kullanıcı için bir GCP klasörü oluşturulur. Klasörün içinde bir terraform yönetici projesi oluşturulur. Bu çalıştay için gereken GCP kaynaklarının geri kalanını oluşturmak için terraform yönetici projesi kullanılacak. set-terraform-admin-project.sh komut dosyası, terraform yönetici projesindeki 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 doğru IAM rollerini vererek GCP'de kaynak oluşturabiliyorsunuz. Son olarak, uzak arka uç tüm GCP kaynakları için Terraform durumlarını depolamak amacıyla bir Google Cloud Storage (GCS) paketinde yapılandırılır.

Terraform yönetici projesinde Cloud Build görevlerini görüntülemek için terraform yönetici proje kimliğine ihtiyacınız vardır. Bu öğe, önyükleme komut dosyasında belirtilen yönetici GCS paketinde depolanır. Önyükleme komut dosyasını birden fazla kullanıcı için çalıştırırsanız tüm terraform yönetici proje kimlikleri GCS paketinde bulunur.

Bu atölyenin Cloud Shell ve Cloud Console'da uygulanması amaçlanmış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ırlama bölümünden daha önce açılmamışsa).

CLOUD SHELL

2. $HOME/bin klasörüne kustomize'ı (yüklü değilse) yükleyin ve $HOME/bin klasörünü $PATH yoluna 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ükleyip $HOME/bin/pv bölümüne 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 istenen 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 proje kimliğinizi alın:

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

7. Atölyeyle ilişkili tüm kaynaklar, terraform Admin projesindeki bir GCS paketinde depolanan bir vars.sh dosyasında değişken olarak depolanır. Terraform yönetici projenizin 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. Terraform yönetici projesinin Cloud Build sayfasını açmak ve derlemenin başarıyla tamamlandığını doğrulamak için görüntülenen bağlantıyı tıklayı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. Artık Cloud Build sayfasına baktığınıza göre soldaki gezinme bölmesinden History bağlantısını ve ardından en son derlemeyi tıklayarak ilk Terraform'un ayrıntılarını görebilirsiniz. Aşağıdaki kaynaklar Terraform komut dosyası kapsamında oluşturulmuştur. Yukarıdaki mimari şemasına da bakabilirsiniz.

• Kuruluştaki 4 GCP Projesi Sağlanan Faturalandırma hesabı her projeyle ilişkilendirilir.
• Bir proje, paylaşılan VPC için network host project projesidir. Bu projede başka kaynak oluşturulmaz.
• Bir proje, Istio kontrol düzlemi GKE kümeleri için kullanılan ops project öğesidir.
• İki proje, ilgili hizmetleri üzerinde çalışan iki farklı geliştirme ekibini temsil eder.
• Üç ops, dev1 ve dev2 projesinin her birinde iki GKE kümesi oluşturulur.
• k8s-repo adlı bir CSR deposu oluşturulur. Bu depoda Kubernetes manifest dosyaları için altı klasör bulunur. GKE kümesi başına bir klasör. Bu kod deposu, Kubernetes manifestlerini kümelere GitOps tarzında dağıtmak için kullanılır.
• Cloud Build tetikleyicisi oluşturulur. Böylece k8s-repo ana dalına bir kaydetme olduğunda Kubernetes manifest'lerini ilgili klasörlerden GKE kümelerine dağıtır.

Terraform komut dosyasının oluşturulması 40-50 dakika sürer.

10. terraform admin project sisteminde derleme tamamlandıktan sonra, işlem projesine başka bir derleme başlar. ops project için Cloud Build sayfasını açmak ve k8s-repo Cloud Build'in başarıyla tamamlandığını doğrulamak üzere gösterilen bağlantıyı tıklayın.

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

Not: Istio Yüklemesini doğrulayabilmeniz için öncelikle 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 işaret edecek şekilde değiştirin.

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

13. Cloud Shell'in her yeniden başlatılmasında kaynak olarak kullanılması için vars.sh ve KUBECONFIG varlarını 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öreceksiniz.

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 Yüklemesini Doğrulama

15. Tüm kapsüllerin çalışıp çalışmadığı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ümeye de yüklendiğinden emin olun. dev1 kümelerinde yalnızca Citadel, yardımcı dosya enjektör ve çekirdekler çalışır. Operasyon-1 kümesinde çalışan bir Istio kontrol düzlemini paylaşırlar.

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ümeye de yüklendiğinden emin olun. dev2 kümelerinde yalnızca Citadel, yardımcı dosya enjektör ve çekirdekler çalışır. Operasyon-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ölyede, tüm GKE kümelerinin oluşturulduğu tek bir paylaşılan VPC kullanacaksınız. Kümeler genelinde hizmetleri keşfetmek için işlem kümelerinde gizli anahtar olarak oluşturulan kubeconfig dosyalarını (uygulama kümelerinin her biri için) kullanırsınız. Pilot, uygulama kümelerinin Kube API sunucusunu sorgulayarak Hizmetler'i keşfetmek için bu gizli anahtarları kullanır (yukarıdaki gizli anahtarlarla kimliği doğrulanır). Her iki işlem kümesinin kubeconfig tarafından oluşturulan gizli anahtarları kullanarak tüm uygulama kümelerinde kimlik doğrulaması yapabildiğini görüyorsunuz. İşlem kümeleri, gizli yöntem olarak kubeconfig dosyalarını kullanarak hizmetleri otomatik olarak keşfedebilir. Bu, işlem kümelerindeki Pilot'un diğer tüm kümelerin Kube API sunucusuna erişmesini gerektirir. Pilot, Kube API sunucularına erişemezse uzak hizmetleri manuel olarak ServiceEntries biçiminde ekleyebilirsiniz. ServiceEntries'i, hizmet kayıt defterinizdeki DNS girişleri olarak düşünebilirsiniz. ServiceEntries, bir hizmeti tam nitelikli DNS adı ( FQDN) ve bu hizmete ulaşılabilecek bir IP adresi kullanarak tanımlar. Daha fazla bilgi için Istio Multicluster belgelerine bakın.

6. Altyapı Deposu açıklaması

Altyapı Cloud Build

Atölyenin GCP kaynakları Cloud Build ve infrastructure CSR deposu kullanılarak oluşturuldu. Az önce yerel terminalinizden bir önyükleme komut dosyası (scripts/bootstrap_workshop.sh konumunda) ç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 izinlerini oluşturur. Terraform yönetici projesi; terraform durumlarını, günlükleri ve çeşitli komut dosyalarını depolamak için kullanılır. infrastructure ve k8s_repo CSR depolarını içerir. Bu depolar bir sonraki bölümde ayrıntılı olarak açıklanmıştır. Terraform Admin projesinde başka atölye kaynağı oluşturulmamış. Terraform yönetici projesindeki Cloud Build hizmet hesabı, atölye için kaynak derlemek amacıyla kullanılır.

infrastructure klasöründe bulunan cloudbuild.yaml dosyası, atölye için GCP kaynakları oluşturma amacıyla kullanılacak. GCP kaynakları oluşturmak için gereken tüm araçları içeren özel bir derleyici görüntüsü oluşturur. gcloud SDK, terraform ve python, git, jq gibi diğer yardımcı programlar bu araçlar arasındadır. Özel derleyici görüntüsü, her kaynak için terraform plan ve apply öğelerini çalıştırır. Her kaynağın terraform dosyaları ayrı klasörlerde bulunur (ayrıntılar bir sonraki bölümde verilmiştir). Kaynaklar teker teker ve genel olarak nasıl derleneceklerine göre sıralanır (örneğin, bir GCP projesi, kaynaklar projede oluşturulmadan önce oluşturulur). Daha fazla ayrıntı için lütfen cloudbuild.yaml dosyasını inceleyin.

Cloud Build, infrastructure deposunda her kaydetme yapıldığında tetiklenir. Altyapıda yapılan değişiklikler Kod olarak altyapı (IaC) olarak depolanır ve depoya aktarılır. Atölyenizin durumu her zaman bu depoda saklanır.

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

Altyapı deposu, atölye için GCP altyapı kaynaklarını ayarlar. Klasörler ve alt klasörler şeklinde yapılandırılır. Depodaki temel klasörler, belirli GCP kaynaklarına sahip olan team klasörlerini temsil eder. Bir sonraki klasör katmanı ekibe özel environment öğesini temsil eder (örneğin, geliştirme, aşama, üretim). Ortamdaki klasörlerin bir sonraki katmanı belirli resource öğesini temsil eder (örneğin hosts_projesi, gke_clusters vb.). Gerekli komut dosyaları ve terraform dosyaları, kaynak klasörlerin içinde bulunur.

Bu atölyede aşağıdaki dört tür ekip temsil edilir:

1. infrastructure (altyapı): 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ı deposunun kendisi Terraform yönetici projesinde ve Terraform durum dosyalarındadır (aşağıda açıklanmıştır). Bu kaynaklar, önyükleme işlemi sırasında bir bash komut dosyası tarafından oluşturulur (ayrıntılar için Modül 0 - Yönetici İş Akışı bölümüne bakın).
2. network: Ağ ekibini temsil eder. VPC ve ağ kaynaklarından sorumludurlar. Aşağıdaki GCP kaynaklarına sahip olurlar.
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 (işlemler), operasyonlar/devops ekibini temsil eder. Müşteriniz aşağıdaki kaynaklara sahip.
6. ops project: Tüm işlem kaynakları için bir projeyi temsil eder.
7. gke clusters - bölge başına bir işlem GKE kümesi. Istio kontrol düzlemi, işlemlerin GKE kümelerinin her birine yüklenir.
8. k8s-repo: Tüm GKE kümeleri için GKE manifest'lerini içeren CSR deposu.
9. apps - Uygulama ekiplerini temsil eder. Bu atölyede app1 ve app2 adlı iki ekibin simülasyonu gerçekleştirilecektir. Müşteriniz aşağıdaki kaynaklara sahip.
10. app projects: Her uygulama ekibinin kendi projesi vardır. Bu sayede onların belirli projeleri için faturalandırmayı ve IAM'yi kontrol edebilirler.
11. gke clusters: Uygulama kapsayıcılarının/kapsüllerinin çalıştığı uygulama kümeleridir.
12. gce instances: İsteğe bağlı olarak, GCE örneklerinde çalışan uygulamaları varsa. Bu atölyedeki uygulama1'de, uygulamanın bir kısmının çalıştığı birkaç GCE örneği bulunmaktadır.

Bu atölyede, aynı uygulama (Hipster mağaza uygulaması) hem uygulama1 hem de uygulama2'yi temsil etmektedir.

Sağlayıcı, 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 yer alıyor. provider.tf dosyası her kaynak klasörde semboliktir. 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ı, komut dosyası kullanılarak (scripts/setup_terraform_admin_project konumunda) bir şablondan (templates/backend.tf_tmpl konumunda bulunur) oluşturulur ve ardından ilgili kaynak klasörüne yerleştirilir. Google Cloud Storage (GCS) paketleri, arka uçlar için kullanılır. GCS paket klasörü adı, kaynak adıyla eşleşiyor. Tüm kaynak arka uçları terraform yönetici projesinde bulunur.

Birbirine bağımlı değerleri olan kaynaklar bir output.tf dosyası içerir. Gerekli çıkış değerleri, söz konusu kaynağın arka ucunda tanımlanan tfstate dosyasında depolanır. Örneğin, bir projede GKE kümesi oluşturmak için proje kimliğini bilmeniz gerekir. Proje kimliği, GKE kümesi kaynağındaki bir terraform_remote_state veri kaynağı üzerinden kullanılabilen tfstate dosyasına çıkış.tf aracılığıyla gönderilir.

shared_state dosyası, bir kaynağın tfstate dosyasına işaret eden bir terraform_remote_state veri kaynağıdır. Kaynak klasörlerde, diğer kaynaklardan çıkış alınmasını gerektiren bir shared_state_[resource_name].tf dosyası (veya dosyaları) bulunuyor. Örneğin, ops_gke kaynak klasöründe ops_project ve shared_vpc kaynaklarından alınan shared_state dosyaları bulunur. Bunun nedeni, işlemler 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 konumunda bulunan bir komut dosyası kullanılarak bir şablondan (templates/shared_state.tf_tmpl konumunda) oluşturulur. Tüm kaynaklar shared_state dosyaları gcp/[environment]/shared_states klasörüne yerleştirilir. Gerekli shared_state dosyaları, ilgili kaynak klasörlerinde sembollü bağlantılı. Tüm shared_state dosyalarının bir klasöre yerleştirilmesi ve bunların uygun kaynak klasörlerine bağlanması, tüm durum dosyalarının tek bir yerden yönetilmesini 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önetici projesindeki bir GCS paketinde bulunan vars.sh adlı bir dosyada depolanır (dışa aktarma ifadeleri olarak). Kuruluş kimliği, faturalandırma hesabı, proje kimlikleri, GKE kümesi ayrıntıları vb. bu bilgiler arasındadır. Kurulumunuzun değerlerini almak için vars.sh öğesini herhangi bir terminalden indirip 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 bir variables.tfvars dosyası oluşturmak için kullanılır. variables.tfvars dosyası, değerleriyle birlikte tüm değişkenleri içerir. variables.tfvars dosyası, bir komut dosyası kullanılarak aynı klasördeki bir şablon dosyasından oluşturulur (scripts/setup_terraform_admin_project konumunda bulunur).

K8s Deposu açıklaması

k8s_repo, Terraform yönetici projesinde bulunan (altyapı deposundan ayrı) bir CSR deposudur. GKE manifest'lerini depolamak ve tüm GKE kümelerine uygulamak için kullanılır. k8s_repo, Cloud Build altyapısı 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ümesi adıyla eşleşen ad), ilgili kaynak manifest dosyalarını içeren bir GKE kümesine karşılık gelir. Altyapı oluşturmaya benzer şekilde Cloud Build, Kubernetes manifest'lerini tüm GKE kümelerine k8s_repo kullanılarak uygulamak için kullanılır. Cloud Build, k8s_repo deposuna kayıt yapıldığında tetiklenir. Altyapıya benzer şekilde, tüm Kubernetes manifest'leri k8s_repo deposunda kod olarak depolanır ve her GKE kümesinin durumu her zaman ilgili klasörde depolanır.

İlk altyapı oluşturma işleminin bir parçası olarak k8s_repo oluşturulur ve Istio tüm kümelere yüklenir.

Projeler, GKE kümeleri ve ad alanları

Bu atölyedeki kaynaklar, farklı GCP projelerine bölünmüştür. Projeler şirketinizin kurumsal (veya ekip) yapısına uygun olmalıdır. Farklı projelerden/ürünlerden/kaynaklardan sorumlu ekipler (kuruluşunuzda) farklı GCP projelerini kullanır. Ayrı projelere sahip olmak, ayrı IAM izin grupları oluşturmanıza ve faturalandırmayı proje düzeyinde yönetmenize olanak tanır. Ayrıca kotalar proje düzeyinde de yönetilir.

Bu atölyede, her biri kendi projesine sahip beş ekip temsil ediliyor.

1. GCP kaynaklarını oluşturan altyapı ekibi Terraform admin project kullanır. Altyapıyı bir CSR deposunda (infrastructure adlı) kod olarak yönetirler ve GCS paketlerinde GCP'de oluşturulan kaynaklara ait tüm Terraform durum bilgilerini depolarlar. 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'si sayesinde GCP kaynakları için ağ iletişimi merkezi olarak yönetilebilir. Tüm projeler ağ iletişimi için bu tek paylaşılan VPC'yi kullandı.
3. GKE kümelerini ve ASM/Istio kontrol düzlemlerini oluşturan işlem/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ırmaktan, Kubernetes platformunun esnekliğini ve ölçeğini yönetmekten bu iş ortakları sorumludur. Bu atölyede kaynakları Kubernetes'e dağıtmak için gitops yöntemini kullanacaksınız. Operasyon projesinde bir CSR deposu (k8s_repo olarak adlandırılır) mevcut.
4. Son olarak, uygulamalar oluşturan dev1 ve dev2 ekipleri (iki geliştirme ekiplerini temsil eder) kendi dev1 ve dev2 projects ekiplerini 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 içine aktarılır ve uygun kümelere dağıtılır. Bu atölyenin CI/CD ile ilgili en iyi uygulamalara ve araçlara odaklanmadığını unutmayın. Kubernetes kaynaklarını doğrudan GKE kümelerine dağıtma işlemini otomatikleştirmek için Cloud Build'i kullanabilirsiniz. Gerçek hayattan ü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 bulunmaktadır.

1. İşlem kümeleri: İşlem ekibi tarafından DevOps araçlarını çalıştırmak için kullanılır. Bu atölyede, servis ağını yönetmek için ASM/Istio kontrol düzlemini yürüttüler.
2. Uygulama (uygulama) kümeleri: Geliştirme ekipleri tarafından uygulamaları çalıştırmak için kullanılır. Bu atölyede Hipster mağaza uygulaması kullanılmıştır.

İşlem/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. Bu iki küme türü, bunları kullanan ekip/ürünle ilişkili farklı projelerde de bulunur. Bu da IAM izinlerini yönetmeyi kolaylaştırır.

Toplam altı GKE kümesi mevcuttur. İşlemler projesinde iki bölgesel işlem kümesi oluşturulur. ASM/Istio kontrol düzlemi her iki işlem kümesine de yüklenmiştir. Her işlem kümesi farklı bir bölgede yer alır. Ayrıca dört adet alt bölgesel uygulama kümesi bulunur. Bunlar kendi projelerinde oluşturulur. Bu atölyede, her biri kendi projesi bulunan iki geliştirme ekibi simüle edilir. Her projede iki uygulama kümesi bulunur. Uygulama kümeleri, farklı alt bölgelerdeki alt bölgesel kümelerdir. Dört uygulama kümesi, iki bölge ve dört alt bölgede bulunmaktadır. Böylece bölgesel ve alt bölgesel yedeklilik elde edersiniz.

Bu atölyede kullanılan Hipster Shop uygulaması, dört uygulama kümesinin tamamında dağıtıldı. Her mikro hizmet, her uygulama kümesinde kendi ad alanında bulunur. Hipster mağaza uygulaması dağıtımları (Kapsüller), işlem kümelerine dağıtılmaz. Ancak tüm mikro hizmetlerin ad alanları ve hizmet kaynakları da işlem 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 ServiceEntries'i manuel olarak oluşturmanız gerekir.

Bu atölyede 10 katmanlı bir mikro hizmet uygulaması dağıtacaksınız. Uygulama, " Hipster Dükkanı" Kullanıcılar ürünlere göz atabilir, bunları sepete ekleyebilir ve satın alabilir.

Kubernetes manifest dosyaları ve k8s_repo

Tüm GKE kümelerine Kubernetes kaynakları eklemek için k8s_repo kullanırsınız. Bunun için Kubernetes manifest'lerini kopyalayıp k8s_repo şartlarına uymanız gerekir. k8s_repo için yapılan tüm kayıtlar, Kubernetes manifestlerini ilgili kümeye dağıtan bir Cloud Build işini tetikler. Her kümenin manifest dosyası, küme adıyla aynı olan ayrı bir klasörde bulunur.

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

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

k8s_repo, bu kümelere karşılık gelen klasörler içerir. Bu klasörlere yerleştirilen tüm manifestler ilgili GKE kümesine uygulanır. Her kümenin manifestleri, yönetim kolaylığı sağlamak için alt klasörlere (kümenin ana klasöründe) yerleştirilir. Bu atölyede, dağıtılan kaynakların takibi için Kustomize'ı kullanacaksınız. Daha fazla ayrıntı için lütfen Kustomize resmi dokümanlarına bakın.

7. Örnek Uygulamayı Dağıtma

Hedef: Hipster store uygulamasını uygulama kümelerine dağıtma

• k8s-repo klonu
• Hipster mağaza manifestlerini tüm uygulama kümelerine kopyala
• İşlem kümelerinde Hipster mağaza uygulaması için Hizmetler oluşturma
• Genel bağlantıyı test etmek için işlem kümelerinde loadgenerators ayarlarını yapın
• Hipster mağazası uygulamasıyla güvenli bağlantıyı doğrulama

HIZLI PARÇA METNİ

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 Laboratuvarı Talimatları

Bu laboratuvardaki hızlı izleme komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Operasyon projesi kaynak deposunu klonlama

k8s-repo, ilk Terraform altyapı derlemesi kapsamında operasyon projesinde oluşturulmuş.

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

mkdir $WORKDIR/k8s-repo
 

2. Git deposunu başlatın, uzak depodan Remote'u (Uzaktan Uzak Depo) ve "pus" (ana depo) ekleyin:

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 yerel 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, kaydetme ve aktarma

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 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ümelerinin kaynak deposuna 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ı, rbac ve podsecuritypolicy öğelerini, bir tanesi hariç tüm geliştirici kümesinden kaldırın. Hipstershop çok kümeli dağıtım için tasarlanmamıştır. Bu nedenle, sonuçların tutarsız olmasını önlemek için tek bir alışveriş sepeti hizmeti 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 alışveriş sepeti hizmeti dağıtımı, rbac ve podsecuritypolicy 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. kustomization.yaml işlem kümelerinden podsecuritypolicies, dağıtım ve rbac dizinlerini 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 dosyalarında PROJECT_ID değerini 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 manifest'lerini işlem 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 manifest'lerinde 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 manifest'lerini (Deployment, PodSecurityPolicy ve RBAC) işlem kümelerine kopyalayın. Hipster mağazası, küresel bir Google Cloud Yük Dengeleyici (GCLB) kullanılarak kullanıma sunulur. GCLB istemci trafiğini (frontend hedefine gider) alır ve Hizmet'in en yakın örneğine gönderir. Her iki işlem kümesine de loadgenerator eklenmesi, işlem kümelerinde çalışan her iki Istio Giriş ağ geçidine de trafiğin 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ümesinin loadgenerator manifestlerindeki 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 kustomization.yaml dosyasına loadgenerator kaynaklarını 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. Önceden açılan bir sekmede veya aşağıdaki bağlantıyı tıklayarak Operasyon projesinin 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 kapsüllerin, 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. Alışveriş sepeti ad alanındaki kapsüllerin yalnızca ilk geliştirme kümesinde Ç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

Hipster Shop uygulamanız dört uygulama kümesinin hepsine dağıtılmış durumda. Bu kümeler iki bölge ve dört alt bölgededir. Müşteriler, frontend hizmetine erişerek Hipster mağazası uygulamasına erişebilir. frontend hizmeti, dört uygulama kümesinin tamamında çalışır. frontend hizmetinin dört örneğine de istemci trafiği sağlamak için Google Cloud Yük Dengeleyici ( GCLB) kullanılır.

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

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

GKE Autoneg denetleyicisi

Istio Giriş ağ geçidi Kubernetes Hizmeti, Ağ Uç Noktası Grupları (NEG'ler) kullanarak kendisini GCLB'ye arka uç olarak kaydeder. NEG'ler, GCLB'leri kullanarak container'da yerel yük dengelemeye olanak tanır. NEG'ler, Kubernetes Hizmetinde özel bir not ile oluşturulur. Böylece Kubernetes NEG Denetleyicisi'ne kendisini kaydedebilir. Autoneg denetleyici, NEG oluşturma işlemini otomatikleştiren ve Hizmet ek açıklamalarını kullanarak bunları bir 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ı olan Cloud Build'in bir parçası olarak yapılır.

Cloud Endpoints ve yönetilen sertifikaları kullanarak Giriş'i güvenli hale getirin

GCP Yönetilen sertifikaları, frontend GCLB hizmetine giden istemci trafiğinin güvenliğini sağlamak için kullanılır. GCLB, genel frontend hizmeti için yönetilen sertifikalar kullanır ve sertifika GCLB'de sonlandırılır. Bu atölyede, yönetilen sertifika alanı olarak Cloud Endpoints'i kullanacaksınız. Alternatif olarak, frontend için alan adınızı ve DNS adınızı kullanarak GCP tarafından yönetilen sertifikalar oluşturabilirsiniz.

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.

Global yük dengelemeyi doğrulama

Uygulama dağıtımının bir parçası olarak, GCLB Hipster mağazasının Cloud Endpoints bağlantısına yönelik 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 gönderdiğini doğrulayın.

23. GCLB'yi edinin > Hipster mağazası GCLB'sinin oluşturulduğu işlem projesinin Monitoring bağlantısı.

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 Arka uç açılır menüsünden Tüm arka uçlar'ı istio-ingressgateway olarak değiştirin.

25. Hem istio-ingressgateways hedefine giden trafik olduğuna dikkat edin.

Her istio-ingressgateway için üç NEG oluşturulur. İşlem kümeleri bölgesel kümeler olduğundan, bölgedeki her alt bölge için bir NEG oluşturulur. Ancak istio-ingressgateway kapsülleri bölge başına tek bir alt bölgede çalışır. istio-ingressgateway kapsüllerine giden trafik gösterilir.

Yük oluşturucular, her iki işlem kümesinde de çalıştıkları iki bölgeden gelen istemci trafiğini simüle eder. İşlem kümesi bölgesi 1'de oluşturulan yük, 2. bölgedeki istio-ingressgateway bölgesine gönderiliyor. Benzer şekilde, işlem kümesi bölgesi 2'de oluşturulan yük, bölge 2'deki istio-ingressgateway bölümüne gönderilir.

8. Stackdriver ile Gözlemlenebilirlik

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

• istio-telemetry kaynağı yükleyin
• Istio Hizmetleri kontrol panelleri oluşturma/güncelleme
• Kapsayıcı günlüklerini göster
• Stackdriver'da dağıtılmış izlemeyi göster

HIZLI PARÇA METNİ

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 Laboratuvarı Talimatları

Bu laboratuvardaki hızlı izleme 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, kara kutu, araçsız kapsayıcılarda bile operatörler, bu kapsayıcılara giren ve çıkan trafiği gözlemleyerek müşterilere hizmet sunabilir. Bu gözlem birkaç farklı yöntemden oluşuyor: metrikler, günlükler ve izler.

Ayrıca Hipster Shop'taki yerleşik yük oluşturma sistemini de kullanacağız. Gözlemlenebilirlik, trafik içermeyen statik bir sistemde çok iyi çalışmadığından, yük oluşturma nasıl çalıştığını anlamamıza yardımcı olur. Bu yükleme zaten çalışıyor, şimdi onu yalnızca görebileceğiz.

1. istio'yu yığındriver yapılandırma dosyasına 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 kaydolun.

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

3. Önceden açılan bir sekmede veya aşağıdaki bağlantıyı tıklayarak Operasyon projesinin 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ğrulayın. Stackdriver işleyici CRD'sini edinin.

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

Çıkışta, yığın sürücü adlı bir işleyici gösterilmelidir:

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

5. Stackdriver'a aktarılan Istio metriklerinin çalıştığını doğrulayın. Bu komuttaki bağlantı çıkışını tıklayın:

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

Adını Ops projesinden alan yeni bir Workspace oluşturmanız istenecektir. Tamam'ı seçmeniz yeterlidir. Yeni kullanıcı arayüzü görüntülenirse iletişim kutusunu kapatın.

Metrik Gezgini'ndeki "Kaynak türünü ve metriği bul" bölümünün altında "istio" yazın "Sunucu İstek Sayısı" gibi seçenekler olduğundan emin olun. "Kubernetes Container'ında" kaynak türü. Bu, metriklerin ağdan Stackdriver'a aktarıldığını gösterir.

(Aşağıdaki satırları görmek istiyorsanız Gruplandırma Ölçütü destination_service_name etiketini girmeniz gerekir.)

Gösterge Tabloları ile metrikleri görselleştirme:

Metriklerimiz artık Stackdriver APM sistemi içinde olduğuna göre bunları görselleştirmek için bir yönteme ihtiyaç duyuyoruz. Bu bölümde, bize dört " Altın Sinyaller" oranında metrik: Trafik (Saniye başına istek sayısı), Gecikme (bu örnekte 99. ve 50. yüzdelik dilim) ve Hatalar (bu örnekte Doygunluk hariç tutulmuştur).

Istio'nun Envoy proxy'si bize çeşitli metrikler sağlar ancak bunlar iyi bir başlangıç setidir. (kapsamlı listeyi burada bulabilirsiniz). Her metriğin, filtreleme ve toplama için kullanılabilecek bir grup etiket bulunduğunu unutmayın. Örneğin: hedef_hizmet, source_workload_namespace, response_code, istio_tcp_received_bytes_total vb.).

6. Şimdi, önceden hazırlanmış metrikler kontrol panelimizi ekleyelim. Doğrudan Kontrol Paneli API'sini kullanacağız. Bu, normalde API çağrılarını elle oluşturduğunuzda yapmamanız gereken bir şeydir. Bir otomasyon sisteminin parçası olur veya kontrol panelini web kullanıcı arayüzünde manuel olarak oluşturursunuz. Bunu yapmak hızlı bir başlangıç yapmamızı sağlayacaktır:

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"
 
 

Kullanıcı deneyimini kullanarak kontrol panelini yerinde düzenleyebiliriz. Ancak bizim örneğimizde, API'yi kullanarak hızlı bir şekilde yeni bir grafik ekleyeceğiz. Bunu yapmak için kontrol panelinin en son sürümünü alın, düzenlemelerinizi uygulayın, ardından HTTP YAMA yöntemini kullanarak kontrol panelini tekrar gönderin.

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

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 ekleyin: (50. yüzdelik dilim gecikmesi): [API referansı] Artık kontrol panelimize kod olarak yeni bir grafik widget'ı ekleyebiliriz. Bu değişiklik, benzer kullanıcılar tarafından incelenebilir ve sürüm kontrolüne kontrol edilebilir. %50'lik gecikmeyi (ortanca gecikme) gösteren, eklenecek bir widget'ı burada bulabilirsiniz.

Yeni bir metin ekleyerek az önce sahip olduğunuz kontrol panelini düzenlemeyi deneyin:

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üncelleyin:

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üncellenmiş 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, tüm örgü içi ağ trafiği için bir yapılandırılmış günlük grubu sağlar ve bunları, tek bir güçlü araçta kümeler arası analize olanak tanımak için Stackdriver Logging'e yükler. Günlüklere küme, container, uygulama, Connectivity_id gibi hizmet düzeyindeki meta veriler eklenir.

Örnek bir günlük girişi (bu örnekte, Envoy proxy'nin erişim günlüğü) şöyle görünebilir (kısaltılmıştır):

*** 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 şurada görüntüleyebilirsiniz:

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

Istio'nun kontrol düzlemi günlüklerini Kaynak > "pilot" aşamasında arama yapma -

Burada, Istio Kontrol Düzlemi'nin her örnek uygulama hizmeti için proxy yapılandırmasını yardımcı dosya proxy'lerine aktardığını görebiliriz. "CDS", "LDS", ve "RDS" Farklı Envoy API'lerini temsil eder ( daha fazla bilgi).

Istio günlüklerinin yanı sıra container günlüklerini, altyapı veya diğer GCP hizmeti günlüklerini 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, bir kontrol panelinde veya bir uyarının parçası olarak kullanılabilen, günlüklerden (ör. "belirli bir dizeyle eşleşen her hatayı say") metrikler oluşturmanıza da olanak tanır. 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ış İzler'e göz atın.

Artık dağıtılmış bir sistemle çalıştığınıza göre, hata ayıklama için yeni bir araca ihtiyaç duyuyoruz: Dağıtılmış İzleme. Bu araç, hizmetlerinizin nasıl etkileşimde bulunduğuna ilişkin istatistikleri keşfetmenize (örneğin, aşağıdaki resimde gösterilen yavaş etkinlikleri bulma) ve gerçekten neler olduğunu öğrenmek için ham örnek izlerini incelemenize olanak tanır.

Zaman çizelgesi görünümü, son kullanıcıya yanıt vermek için zaman içindeki tüm istekleri, gecikmeleri veya ilk istek arasında, Hipster yığını aracılığıyla harcanan süreye göre grafik halinde gösterir. Noktalar ne kadar yüksekse kullanıcının deneyimi o kadar yavaş (ve daha az mutlu) demektir.

Bir noktayı tıklayarak söz konusu isteğe ilişkin ayrıntılı Şelale Görünümünü bulabilirsiniz. Belirli bir isteğin ham ayrıntılarını (yalnızca toplu istatistiklerin değil) bulabilme olanağı, özellikle hizmetler arasındaki nadir ama kötü etkileşimleri ararken, hizmetler arasındaki etkileşimi anlamak açısından çok önemlidir.

Hata ayıklayıcı kullanan herkes Şelale Görünümü'ne aşina olmalıdır. Ancak bu durumda tek bir uygulamanın farklı işlemlerinde harcanan zaman yerine, hizmet ağımızda gezinirken, hizmetler arasında ve ayrı container'larda çalışırken harcanan süre burada 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ı

Hedef: Mikro hizmetler arasında güvenli bağlantı (AuthN).

• Örgü genişliğinde mTLS'yi etkinleştir
• Günlükleri inceleyerek mTLS'yi doğrulayın

HIZLI PARÇA METNİ

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 Laboratuvarı Talimatları

Bu laboratuvardaki hızlı izleme 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 Gözlemlenebilirlik'i ayarladığımıza göre artık hizmetler arasındaki bağlantıları korumaya başlayabilir ve uygulamanın çalışmaya devam etmesini sağlayabiliriz.

Örneğin, Kiali kontrol panelinde hizmetlerimizin MTLS kullanılmadığını ("kilit" simgesi yoktur) görüyoruz. Ancak trafik akıyor ve sistem iyi çalışıyor. StackDriver Golden Metrics kontrol panelimiz, genel olarak her şeyin yolunda gittiğine dair içimizi rahatlatıyor.

1. İşlem kümelerinde MeshPolicy'yi kontrol edin. mTLS'nin PERMISSIVE, hem şifrelenmiş hem de mTLS olmayan trafiğe 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ümeler üzerinde yapılandırılır. IstioControlPlane CR'sini güncelleyip k8s deposunu güncelleyerek tüm kümelerde mTLS'yi yapılandıracağız. Genel ayar > mTLS > etkin: IstioControlPlane CR'de doğru, Istio kontrol düzleminde aşağıdaki iki değişikliğe yol açar:

• MeshPolicy, tüm kümelerde çalışan tüm Hizmetler için mTLS hizmet ağı genelinde etkinleştirecek şekilde ayarlanmıştır.
• Tüm kümelerde çalışan Hizmetler arasındaki ISTIO_MUTUAL trafiğe izin vermek için bir HedefRule oluşturulur.

2. mTLS kümesinin tamamında etkinleştirmek için istioControlPlane CR'ye bir kustomize yaması uygulayacağız. Yamayı tüm kümeler için ilgili dosyaya 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 kaydolun.

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

4. Önceden açılan bir sekmede veya aşağıdaki bağlantıyı tıklayarak Operasyon projesinin 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ğrula

5. İşlem kümelerinde MeshPolicy'yi bir kez daha kontrol edin. mTLS'nin artık PERMISSIVE olmadığını ve yalnızca mTLS trafiğine izin vereceğ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
 

Çıkış (kopyalamayın):

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

6. Istio operatör denetleyicisi tarafından oluşturulan TargetRule'ı 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
      }
   }
}

Ayrıca günlüklerde HTTP'den HTTPS'ye geçişi de görebiliyoruz.

Kullanıcı arayüzündeki günlüklerde bulunan bu özel alanı, tek bir günlük girişini ve ardından görüntülemek istediğiniz alanın değerini (bu örnekte "http" seçeneğini tıklayarak) açığa çıkarabiliriz. yanında "protokol:

Böylece, değişimi görselleştirmek için iyi bir yol elde etmiş olursunuz.

10. Canary Dağıtımları

Hedef: Ö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 frontend-v2 konumuna yavaş yavaş yönlendirmek için DestinationRules ve VirtualServices özelliklerini kullanın
• k8s-repo kaydı serisini inceleyerek GitOps dağıtım ardışık düzenini doğrulayın.

HIZLI PARÇA METNİ

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 Laboratuvarı Talimatları

Bu laboratuvardaki hızlı izleme 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. Bir canary dağıtımında, yeni sürüme artan miktarda trafik gönderirken, kalan yüzdeyi geçerli sürüme göndermeye devam edersiniz. Trafiği bölmenin her aşamasında canary analizi yapıp "altın sinyalleri" karşılaştırmak yaygın bir kalıptır. bir referans değere göre (gecikme, hata oranı, doygunluk) elde edilir. Bu, kesintileri önlemeye ve yeni "v2"nin kararlılığını sağlamaya yardımcı olur kullanıma sunuyoruz.

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

İlk olarak Canary ardışık düzenini DEV1 bölgesinde (us-west1) çalıştıracağız ve bu bölgedeki her iki kümede ön uç v2'yi kullanıma sunacağız. İkinci olarak, DEV2 bölgesinde (us-central) Canary ardışık düzenini çalıştıracak ve v2'yi bu bölgedeki her iki kümeye dağıtacağız. Ardışık düzeni tüm bölgelerde paralel olarak değil, sıralı olarak çalıştırmak, kötü yapılandırmanın veya v2 uygulamasındaki hataların neden olduğu küresel kesintileri önlemeye yardımcı olur.

Not: Canary ardışık düzenini her iki bölgede de manuel olarak tetikleyeceğiz. Ancak üretim aşamasında, otomatik bir tetikleyici kullanırsınız (örneğin, bir kayıt defterine aktarılan yeni Docker görüntüsü etiketine göre).

1. Geri kalan komutların çalıştırılmasını kolaylaştırmak için Cloud Shell'den bazı env değişkenlerini tanımlayın.

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

2. Referans manifest'leri k8s deposuna kopyalamak için repo_setup.sh komut dosyasını çalıştırın.

$CANARY_DIR/repo-setup.sh 
 

Aşağıdaki manifest'ler kopyalanır:

• frontend-v2 dağıtımı
• frontend-v1 yaması ("v1" etiketini ve "/version" uç noktasına sahip bir görüntüyü içerir)
• respy.
• ön uç Istio DestinationRule: ön uç Kubernetes Hizmeti'ni "sürüme" göre v1 ve v2 olmak üzere iki alt gruba ayırır dağıtım etiketi
• ön uç Istio VirtualService: Trafiğin% 100'ünü ön uç v1'e yönlendirir. Bu durum, Kubernetes Hizmeti'nin varsayılan döngülü davranışını geçersiz kılar. Bu durum, tüm Dev1 bölgesel trafiğinin% 50'sini hemen ön uç v2'ye gönderir.

3. k8s_repo'daki değişiklikleri kaydetme:

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

4. Önceden açılan bir sekmede veya aşağıdaki bağlantıyı tıklayarak Operasyon projesinin 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 projesinin konsolunda Cloud Build'e gidin. Cloud Build ardışık düzeninin tamamlanmasını bekleyin, ardından her iki DEV1 kümesindeki ön uç ad alanında kapsüller 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: Saat komutlarından çıkmak için Ctrl-C tuşlarına basın

Cloudshell penceremizi 2 bölmeye bölmek için tmux'u kullanacağız:

• Alt bölme, ön uç hizmeti için HTTP yanıtı dağıtımını gözlemlemek amacıyla watch komutunu çalıştıracaktır.
• Üst bölme, gerçek canary ardışık düzen komut dosyasını çalıştırır.

6. Cloud Shell penceresini bölmek için komutu çalıştırın ve alt bölmede watch komutunu çalıştırı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 ön uç v1 dağıtımına gittiğini görebiliyoruz.

7. Canary ardışık düzenini Dev1 bölgesinde yürütün. VirtualService'te ön uç-v2 trafik yüzdelerini güncelleyen bir komut dosyası sağlarız (ağırlıkları %20, %50, %80 ve ardından %100 olarak günceller). Güncellemeler arasında komut dosyası, Cloud Build ardışık düzeninin 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
 

respy komutunu çalıştırdığınız alt pencerede trafiğin gerçek zamanlı olarak bölündüğünü 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. Ön uç-v2 için Dev2'nin kullanıma sunulması tamamlandığında komut dosyasının sonunda başarı mesajı göreceksiniz:

    Output (do not copy) 
   

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

9. Dev2 kapsülünden gelen tüm ön uç trafiği ön uç-v2'ye gitmelidir:

    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ıda Cloud Kaynak Kod Depolarına gidin.

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

Her trafik yüzdesi için ayrı bir kaydetme gösterilir. En son kaydedilen kayıt ise listenin en üstünde yer alır:

Şimdi, aynı işlemi Dev2 bölgesi için tekrarlayacaksınız. Dev2 bölgesinin hâlâ "kilitli" olduğunu unutmayın. v1'de. Bunun nedeni, referans repo_setup komut dosyasında bir VirtualService'i, tüm trafiği açıkça v1'e gönderecek şekilde aktarmamızdır. Bu sayede, Dev1'da güvenli bir şekilde bölgesel canary sürümü çalıştırabildik ve yeni sürümü tüm dünyada kullanıma sunmadan önce başarılı bir şekilde çalıştığından emin olduk.

12. Cloud Shell penceresini bölmek için komutu çalıştırın ve alt bölmede watch komutunu çalıştırı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 ön uç v1 dağıtımına gittiğini görebiliyoruz.

13. Canary ardışık düzenini Dev2 bölgesinde yürütün. VirtualService'te ön uç-v2 trafik yüzdelerini güncelleyen bir komut dosyası sağlarız (ağırlıkları %20, %50, %80 ve ardından %100 olarak günceller). Güncellemeler arasında komut dosyası, Cloud Build ardışık düzeninin 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 kapsülünden, Dev2 kapsüllerinden gelen trafiğin ön uç v1'den v2'ye kademeli olarak ilerlediğini izleyin. Komut dosyası tamamlandıktan sonra şunu 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 canary dağıtımları için Istio'nun nasıl kullanılacağı açıklanmaktadır. Üretimde, manuel komut dosyası yerine bu canary komut dosyasını Cloud Build ardışık düzeni olarak otomatik şekilde tetikleyebilir ve container kaydına aktarılan yeni bir etiketli görüntü gibi bir tetikleyici kullanabilirsiniz. Ayrıca, daha fazla trafik göndermeden önce her adımın arasına canary analizi ekleyerek v2'nin gecikme oranını ve hata oranını önceden tanımlanmış bir güvenlik eşiğine göre analiz edebilirsiniz.

11. Yetkilendirme Politikaları

Amaç: Mikro hizmetler arasında RBAC'yi kurun (AuthZ).

• Bir mikro hizmete erişimi REDDETMEk için AuthorizationPolicy oluşturun
• Bir mikro hizmete belirli erişime İZİN VERMEK için AuthorizationPolicy oluşturun

HIZLI PARÇA METNİ

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 Laboratuvarı Talimatları

Bu laboratuvardaki hızlı izleme komut dosyasını zaten tamamladıysanız aşağıdaki kopyalama ve yapıştırma yöntemini uygulamayın**.**

Tek bir yerde çalışan monolitik uygulamanın aksine, küresel olarak dağıtılan mikro hizmet uygulamaları ağ sınırları genelinde çağrılar yapar. Bu da uygulamalarınıza daha fazla giriş noktası ve kötü amaçlı saldırılar için daha fazla fırsat anlamına gelir. Kubernetes kapsüllerinin geçici IP'leri olduğundan, iş yükleri arasında erişimi güvence altına almak için artık IP tabanlı geleneksel güvenlik duvarı kuralları yeterli değildir. Mikro hizmet mimarisinde güvenlik için yeni bir yaklaşım gereklidir. Hizmet hesapları gibi Kubernetes güvenliği yapı taşlarını temel alan Istio, uygulamalarınız için esnek bir güvenlik politikaları grubu sağlar.

Istio politikaları hem kimlik doğrulamayı hem de yetkilendirmeyi kapsar. Kimlik doğrulama, kimliği doğrular (bu sunucu olduğunu söyledikleri kişi mi?) ve Yetkilendirme, izinleri doğrular (bu istemcinin bunu yapmasına izin veriliyor mu?). Istio kimlik doğrulamasını Modül 1'in (MeshPolicy) karşılıklı TLS bölümünde ele aldık. Bu bölümde, uygulama iş yüklerimizden biri olan currencyservice'e erişimi kontrol etmek için Istio yetkilendirme politikalarının nasıl kullanılacağını öğreneceksiniz.

İlk olarak 4 geliştirici kümesinin tamamına bir AuthorizationPolicy dağıtacağız, para birimi hizmetine erişimi tamamen kapatacağız ve ön uçta bir hata tetikleyeceğiz. Ardından, para birimi hizmetine yalnızca ön uç hizmetinin erişmesine izin veririz.

1. currency-deny-all.yaml içeriğini inceleyin. Bu politika, para birimi hizmetine erişimi kısıtlamak için Dağıtım etiketi seçicileri kullanır. spec alanı olmadığına dikkat edin. Bu durumda bu politika, seçilen hizmete tüm erişimi reddeder.

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. Her iki bölgedeki işlem kümeleri için para birimi politikasını 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 Cloud Build'in Operasyon projesinin 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 tarayıcıdaki hipstershop ön ucuna erişmeyi deneyin:

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

Para birimi hizmetinde bir Yetkilendirme hatası görürsünüz:

6. Para birimi hizmetinin bu AuthorizationPolicy'yi nasıl uyguladığını inceleyelim. Engellenen yetkilendirme çağrıları varsayılan olarak günlüğe kaydedilmediğinden önce, para birimi kapsüllerinden biri için Envoy proxy'sinde izleme düzeyi günlükleri 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. "Zorunlu kılındı" mesajı gösterilir. mesajı gösterilir.

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 diğer arka uç hizmetlerinin değil ön ucun para birimi hizmetine erişmesine izin verelim. currency-allow-frontend.yaml uygulamasını açın ve içeriğini inceleyin. Aşağıdaki kuralı eklediğimizi unutmayın:

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) öğesini beyaz listeye ekliyoruz. Bu source.principal Kubernetes Hizmet Hesabı'nda tanımlanır. Bu örnekte, beyaz listeye 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 Modül 1'de yaptığımız gibi küme genelinde karşılıklı TLS'yi etkinleştirmeniz gerekir. Bunun amacı, hizmet hesabı kimlik bilgilerinin isteklere eklenmesini sağlamaktır.

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

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. Önceden açılan bir sekmede veya aşağıdaki bağlantıyı tıklayarak Operasyon projesinin 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 yeniden açın. Bu kez ana sayfada hata görmezsiniz. Bunun nedeni, ön ucun geçerli hizmete açıkça erişmesine izin verilmesidir.
13. Şimdi alışveriş sepetinize ürün ekleyip "sipariş ver"i tıklayarak ödeme yapmayı deneyin. Bu kez, para birimi hizmetinde bir fiyat dönüştürme hatası görürsünüz. Bunun nedeni, yalnızca ön ucu beyaz listeye eklenmiş olması ve ödeme hizmetinin, para birimi hizmetine hâlâ erişememesidir.

14. Son olarak, currencyservice AuthorizationPolicy'mize başka bir kural ekleyerek ödeme hizmetinin para birimine erişmesine izin verelim. Para birimi erişimini yalnızca bu hizmete 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 uygulamasını açın ve içeriğini inceleyin. Kural listesinin mantıksal bir VEYA (VEYA) para birimi işlevi gördüğüne dikkat edin. Para birimi, yalnızca bu iki hizmet hesabından birine sahip olan 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. Son 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 aktar

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

18. Önceden açılan bir sekmede veya aşağıdaki bağlantıyı tıklayarak Operasyon projesinin 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 işlemi yürütmeyi deneyin. Başarılı bir şekilde çalışacaktır.

Bu bölümde, hizmet düzeyinde ayrıntılı erişim denetimi uygulamak için Istio Yetkilendirme Politikaları'nın nasıl kullanılacağı anlatılmaktadır. Üretimde, hizmet başına bir AuthorizationPolicy oluşturabilir ve (örneğin) aynı ad alanındaki tüm iş yüklerinin birbirine erişmesini sağlamak için bir allow-all politikası kullanabilirsiniz.

12. Altyapı Ölçeklendirme

Hedef: Yeni bölge, proje ve kümeler ekleyerek altyapıyı ölçeklendirmek.

• infrastructure deposunu klonlama
• 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ölgede yeni işlem 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 kod deposuna kaydetme
• Yüklemeyi doğrula

HIZLI PARÇA METNİ

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 Laboratuvarı Talimatları

Bu laboratuvardaki hızlı izleme 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 yapabilirsiniz. Bir bölgeye daha fazla küme ekleyebilirsiniz. Dilerseniz platforma daha fazla bölge de ekleyebilirsiniz. Platformun hangi yönünün ölçeklendirileceğine dair karar şartlara bağlıdır. Örneğin, bir bölgedeki üç alt bölgede de kümeleriniz varsa mevcut kümeye daha fazla düğüm (veya düğüm havuzu) eklemek yeterli olabilir. Ancak tek bir bölgedeki üç alt bölgeden ikisinde kümeleriniz varsa üçüncü bölgeye yeni bir küme eklemek size ölçeklendirme sağlar ve ek bir hata alanı (ör. yeni bir alt bölge) sağlar. Bir bölgeye yeni küme eklemenin bir diğer nedeni de yasal düzenlemeler veya uyumluluk nedeniyle (ör. PCI veya kimliği tanımlayabilecek bilgiler içeren bir veritabanı kümesi) tek bir kiracılı küme oluşturma ihtiyacı olabilir. İşletmeniz ve hizmetleriniz genişledikçe müşterilere daha yakın hizmetler sunmak için yeni bölgeler eklemek kaçınılmaz hale gelir.

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

• Dikey olarak: Daha fazla işlem özelliği ekleyerek her bölgede. Bu işlem, mevcut kümelere daha fazla düğüm (veya düğüm havuzları) ya da bölge içinde yeni kümeler ekleyerek 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. Bunun için uygun güvenlik duvarı kurallarının 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. Geçerli platform size bölgesel bir şablon sağlar. ASM/Istio denetiminin bulunduğu bölgesel bir işlem kümesinden ve uygulama kaynaklarının dağıtıldığı iki (veya daha fazla) alt bölgesel uygulama kümesinden oluşur.

Bu atölyede, platformu "yatay" olarak ölçeklendiriyorsunuz. kapsamlı kullanım alanı adımlarını da kapsadığından emin olun. Platforma yeni bir bölge (r3) ekleyerek platformu yatay olarak ölçeklendirmek için aşağıdaki kaynakların eklenmesi gerekir:

1. Ana makine projesindeki alt ağlar, yeni işlemler ve uygulama kümeleri için r3. bölgede VPC paylaştı.
2. ASM/Istio kontrol düzleminin bulunduğu r3 bölgesinde bölgesel bir işlem kümesi.
3. r3 bölgesinde iki alt bölgede iki alt bölgesel uygulama kümesi.
4. k8s deposuna güncelleme:
5. ASM/Istio kontrol düzlemi kaynaklarını, r3 bölgesindeki işlem 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ıza gerek yoktur. Atölyedeki adımlarda, platforma yeni bir ekip eklemenin kullanım alanını açıklamak için yeni bir proje geliştirme ekibi 3'ün eklendiği gösterilmektedir.

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

1. Cloud Shell'de WORKDIR konumuna gidip 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. Atölye kaynak deposu 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ındaki 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ılabilmesi için add-proj depo dizinindeki infrastructure dizinini, infra-repo dizinine giden 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 bir proje oluşturmak için değişiklikleri kaydetme ve aktarma

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

7. Kaydetme işlemi, yeni kaynaklarla altyapıyı dağıtmak için infrastructure deposunu tetikler. Aşağıdaki bağlantının çıkışını tıklayıp en üstten 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 ila 30 dakika sürer. Kahve molası vermenin tam zamanı.

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

8. Cloud Build altyapısı başarıyla tamamlandıktan sonra aşağıdaki çıkış bağlantısını tıklayarak en son k8s-repo 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 işaret edecek ş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öreceksiniz.

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 Yüklemesini Doğrulama

12. Tüm kapsüllerin çalışıp çalışmadığını ve işlerin tamamlandığını kontrol ederek Istio'nun yeni işlem kümesine 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ümeye de yüklendiğinden emin olun. dev3 kümelerinde yalnızca Citadel, yardımcı dosya enjektör ve çekirdekler ç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 anahtarların, altı uygulama kümesinin tamamında 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ç: Gönderim hizmeti için bir devre kesici uygulamak.

• Devre kesici uygulamak amacıyla shipping Hizmeti için bir DestinationRule oluşturun
• shipping Hizmeti için devre kesiciyi, devreyi zorla ayırarak doğrulamak için fortio (yük üretme yardımcı programı) kullanın

Fast Track Script Lab Talimatları

Fast Track Script Lab yakında kullanıma sunuluyor!

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

Istio özellikli hizmetlere yönelik bazı temel izleme ve sorun giderme stratejilerini öğrendiğimize göre, şimdi de Istio'nun hizmetlerinizin esnekliğini artırmanıza nasıl yardımcı olduğuna bakalım. Böylece, öncelikle yapmanız gereken sorun giderme miktarını azaltabilirsiniz.

Mikro hizmet mimarisi, geçişli hata riskini beraberinde getirir. Bu durumda bir hizmetin arızası, hizmetin bağımlılıklarına ve bu bağımlılıkların bağımlılıklarına yayılarak "dalga etkisi"ne neden olabilir. son kullanıcıları etkilemesi olasıdır. Istio, hizmetleri izole etmenize, aşağı akış (istemci tarafı) hizmetlerini başarısız hizmetleri beklemeye karşı korumanıza ve tekrar internete bağlandıklarında aşağı akış (sunucu tarafı) hizmetlerini ani bir aşağı akış trafiği selinden korumanıza yardımcı olmak için bir Devre Kesici trafik politikası sağlar. Genel olarak Devre Kesicileri kullanmak, tüm hizmetlerinizin askıda olan bir arka uç hizmeti nedeniyle SLO'larının başarısız olmasını önlemenize yardımcı olabilir.

Devre Kesici deseni, "açılan" bir elektrik anahtarından alınmıştır. Cihazları aşırı yükten korur. Istio kurulumunda bu, Envoy'un devre kesici olduğu ve bir hizmet için bekleyen istek sayısını takip ettiği anlamına gelir. Bu varsayılan kapalı durumda, istekler Envoy üzerinden kesintisiz olarak gerçekleşir.

Ancak bekleyen istek sayısı tanımladığınız eşiği aştığında devre kesici devreye girer (açılır) ve Envoy hemen bir hata döndürür. Bu, sunucunun istemci için hızla başarısız olmasına olanak tanır ve sunucu uygulaması kodunun aşırı yüklendiğinde istemcinin isteğini almasını önler.

Ardından, tanımladığınız zaman aşımı süresinden sonra Envoy yarı açık duruma geçer. Bu durumda sunucu deneme amaçlı tekrar istek almaya başlayabilir ve isteklere başarıyla yanıt verebilirse devre kesici tekrar kapanır ve sunucuya yeniden istek akışı başlar.

Bu diyagram, Istio devre kesici kalıbını özetler. Mavi dikdörtgenler Envoy'u, mavi dolgulu daire istemciyi, beyaz içi dolgulu daireler ise sunucu kapsayıcısını temsil eder:

Istio Hedef Kuralları'nı kullanarak Devre Kesici politikalarını tanımlayabilirsiniz. Bu bölümde, gönderim hizmeti için bir devre kesiciyi zorunlu kılmak amacıyla 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 TargetRule alanı vardır. connectionPool, bu hizmetin izin vereceği bağlantı sayısını tanımlar. OutlierDetection alanı, Envoy'un devre kesicinin açılacağı eşiği belirleme şeklini yapılandırdığımız yerdir. Burada, Envoy her saniyede (aralık) sunucu kapsayıcısından aldığı hataların sayısını sayar. consecutiveErrors eşiğini aşarsa Envoy devre kesici açılır ve ürün kataloğu kapsüllerinin% 100'ü, 10 saniye boyunca yeni müşteri isteklerine karşı korunur. Envoy devre kesici açıldıktan (ör. etkin) sonra istemciler 503 (Hizmet Kullanılamıyor) hatalarını alır. Bunu uygulamalı olarak görelim.

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

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

2. k8s deposunu güncelleme

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

3. Her iki işlem kümesinde de kargo hizmetini TargetRule'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 kapsülünü Dev1 bölgesindeki GKE_1 kümesine kopyalayın. Bu, "seyahat" için kullanacağımız istemci kapsülüdür devre kesiciyi yeni sürüme geçiriyorum.

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

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 dönerseniz gRPC trafiğini kargo hizmetine 1 eşzamanlı bağlantıyla (toplam 1.000 istek) göndermek için fortio kapsülünü kullanın. connectionPool ayarlarını henüz aşmadığımız için devre kesiciyi devre dışı bırakmaz.

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 ve toplam istek sayısını sabit tutarak kaleyi tekrar çalıştırın. İsteklerin üçte ikisine kadar olan sürede bir "taşma" hatası oluştu. Bunun nedeni, devre kesicinin devre dışı bırakılmasıdır: Tanımladığımız politikada, 1 saniyelik aralıklarla 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 etkinken bıraktığı bağlantı sayısını upstream_rq_pending_overflow metriğiyle takip eder. Bunu fortio pod'da 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 temizleyin.

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 devre kesici politikasının nasıl ayarlanacağı gösterilmiştir. En iyi uygulamalardan biri, asma potansiyeli olan herhangi bir yukarı akış (arka uç) hizmeti için devre kesici kurmaktır. Istio devre kesici politikalarını uygulayarak mikro hizmetlerinizin yalıtılmasına, mimarinize hata toleransı eklenmesine ve yüksek yük altında birbirini tetikleyen arıza riskini azaltmaya yardımcı olursunuz.

14. Hata Yerleştirme

Amaç: Gecikmeler ekleyerek (üretime aktarılmadan önce) öneri Hizmetinin direncini test edin.

• 5 saniyelik gecikme sağlamak üzere recommendation hizmeti için bir VirtualService oluşturun
• fortio yük oluşturma aracını kullanarak gecikmeyi test edin
• VirtualService içindeki gecikmeyi kaldırın ve doğrulayın

Fast Track Script Lab Talimatları

Fast Track Script Lab yakında kullanıma sunuluyor!

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

Hizmetlerinize devre kesici politikaları eklemek, üretim aşamasındaki hizmetlere karşı dayanıklılığı artırmanın bir yoludur. Ancak devre kesilmesi, ideal olmayan hatalara (potansiyel olarak kullanıcılara yönelik hatalar) yol açar. Bu hata durumlarında önceden hazırlık yapmak ve arka uçlar hata döndürdüğünde aşağı akış hizmetlerinizin nasıl yanıt verebileceğini daha iyi tahmin etmek için hazırlık ortamında kaos testini uygulayabilirsiniz. Kaos testi, sistemdeki zayıf noktaları analiz etmek ve hata toleransını iyileştirmek amacıyla hizmetlerinizi kasıtlı olarak bozma uygulamasıdır. Arka uçlar başarısız olduğunda kullanıcılara yönelik hataları azaltmanın yollarını belirlemek için kaos testinden de yararlanabilirsiniz. Örneğin, önbelleğe alınmış bir sonucu bir ön uçta görüntüleyerek.

Hata ekleme için Istio'yu kullanmak faydalı olacaktır. Çünkü kaynak kodunu değiştirmek yerine üretim sürümü resimlerinizi kullanabilir ve hatayı ağ katmanına ekleyebilirsiniz. Üretim aşamasında, ağ katmanının yanı sıra Kubernetes/işlem katmanındaki esnekliği test etmek için tam kapsamlı bir kaos test aracı kullanabilirsiniz.

"Hata" ile bir VirtualService uygulayarak kaos testi için Istio'yu kullanabilirsiniz. girin. Istio iki tür hatayı destekler: gecikme hataları (zaman aşımı ekleme) ve hataları iptal etme (HTTP hataları ekleme). Bu örnekte, öneri hizmetine 5 saniyelik gecikme hatası ekleyeceğiz. Ancak bu kez "hatada hızlı" olması için devre kesici kullanmak yerine aşağı akış hizmetlerini, zaman aşımı süresinin tamamında kullanmaya zorlayacağız.

11. Hata ekleme 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 uygulamasını açın. Istio'da, hatayı isteklerin belirli bir yüzdesine ekleme seçeneği bulunur. Burada, tüm öneri hizmeti isteklerine zaman aşımı sağlayacağı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. Hatayı dünya genelinde her iki bölgeye de ekleyeceğiz.

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 aktar

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ünü yürütün ve öneri hizmetine 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. Uygulamaya koyduğumuz hatayı görmenin başka bir yolu da ön ucu bir web tarayıcısında açmak ve herhangi bir ürünü tıklamaktır. Bir ürün sayfasının en altında gösterilen önerileri getirdiğinden, bu sayfanın yüklenmesi fazladan 5 saniye sürmelidir.
18. Hata ekleme hizmetini her iki işlem kümesinden kaldırarak temizleme 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 İzleme

ASM, dört önemli kontrol düzlemi bileşenini yüklüyor: Pilot, Karıştırıcı, Galley ve Citadel. Her biri ilgili izleme metriklerini Prometheus'a gönderir. ASM ise operatörlerin bu izleme verilerini görselleştirmesini ve kontrol düzleminin performansını ve performansını değerlendirmesini sağlayan Grafana kontrol panellerini sunar.

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

20. Istio ile yüklenen Grafana hizmetinizi taşıma

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. "Web Önizlemesi"ni tıklayın Cloud Shell pencerenizin sağ üst köşesindeki simge
23. Bağlantı noktası 3000'de Önizleme'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, tarayıcınızda " BASE_URL/?orgId=1&authuser=0&environment_id=varsayılan"
25. Kullanılabilir kontrol panellerini görüntüle
26. URL'yi " BASE_URL/dashboard"
27. "Istio"yu tıklayın. mevcut kontrol panellerini görüntülemek için klasör
28. Söz konusu bileşenin performansını görüntülemek için bu kontrol panellerinden birini tıklayın. Aşağıdaki bölümlerde her bileşen için önemli metriklere göz atacağız.

İzleme Pilotu

Pilot, ağ ve politika yapılandırmasını veri düzlemine (Envoy proxy'leri) dağıtan kontrol düzlemi bileşenidir. Pilot program, iş yükü ve dağıtım sayısına göre ölçeklenme eğilimindedir. Ancak söz konusu iş yüklerine gelen trafik miktarıyla orantılı olmayabilir. Sağlıksız bir Pilot şunları yapabilir:

• gerekenden daha fazla kaynak tüketiyor (CPU ve/veya RAM)
• güncellenen yapılandırma bilgilerinin Envoys'a aktarılmasında gecikmelere neden olur.

Not: Pilot çalışma kapalıysa veya gecikmeler varsa iş yükleriniz trafik sağlamaya devam eder.

23. Şuraya git: " BASE_URL/dashboard/db/istio-pilot-dashboard" tarayıcınızda görebilirsiniz.

İzlenen önemli 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 uzun süreli kaynak kullanımı görürseniz GCP destek ekibiyle iletişime geçin.

Pilot İtme Bilgileri

Bu bölümde, Pilot'ların Envoy proxy'lerinize yaptığı yapılandırma aktarımları izlenir.

• Pilot Aktarımlar, herhangi bir zamanda aktarılan yapılandırma türünü gösterir.
• ADS Monitoring, sistemdeki Sanal Hizmetler, Hizmetler ve Bağlı Uç noktaların sayısını gösterir.
• Bilinen uç noktası olmayan kümeler, yapılandırılmış ancak herhangi bir örneği olmayan (*.googleapis.com gibi harici hizmetleri belirtebilir) uç noktaları gösterir.
• Pilot Hatalar, zaman içinde karşılaşılan hataların sayısını gösterir.
• Çakışmalar, işleyicilerde yapılandırması belirsiz olan çakışmaların sayısını gösterir.

Hatalar veya Çakışmalar yaşıyorsanız hizmetlerden biri veya daha fazlası için yapılandırma bozuk ya da tutarsız demektir. Bilgi için Veri düzleminde sorun giderme bölümüne 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üyorsanız GCP destek ekibiyle iletişime geçin.

İzleme Mikseri

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

Mixer, politika sistemleriyle entegrasyon için de kullanılabilir. Bu kapasitede, Mixer'ın hizmetlerinize erişimi engelleyemeyen politika kontrolleri nedeniyle Mixer veri düzlemini etkiler.

Karıştırıcı, trafik hacmine göre ölçeklenme eğilimindedir.

24. Şuraya git: " BASE_URL/dashboard/db/istio-mixer-dashboard" açın.

İzlenen önemli 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 uzun süreli kaynak kullanımı görürseniz GCP destek ekibiyle iletişime geçin.

Miksere Genel Bakış

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

• Bağdaştırıcı Gönderme Süresi, Karıştırıcı'nın çağrı bağdaştırıcılarında yaşadığı gecikmeyi gösterir (bu şekilde telemetri ve günlük kaydı sistemlerine bilgi gönderir). Buradaki yüksek gecikmeler, ağ performansını kesinlikle etkiler. p90 gecikmelerinin de 10 ms'nin altında olması gerekir.

İzleme Ekipmanları

Galley, Istio'nun yapılandırma doğrulama, besleme, işleme ve dağıtım bileşenidir. Kubernetes API sunucusundan Pilot'a yapılandırma aktarır. Pilot uygulamada olduğu gibi, sistemdeki hizmet ve uç nokta sayısına göre ölçeklendirilebilir.

25. Şuraya git: " BASE_URL/dashboard/db/istio-galley-dashboard" inceleyebilirsiniz.

İzlenen önemli metrikler

Kaynak Doğrulama

Hedef kuralları, Ağ Geçitleri ve Hizmet girişleri gibi çeşitli türlerdeki kaynakların sayısını gösteren, izlenmesi gereken en önemli metriktir.

Bağlı istemciler

Galley'e kaç istemcinin bağlı olduğunu gösterir; bu genellikle 3 olur (pilot, istio-telemetri, istio-policy) ve bu bileşenler ölçeklendikçe ölçeklendirilir.

16. Istio sorunlarını giderme

Veri düzleminde sorun giderme

Pilot kontrol paneliniz yapılandırma sorunlarınız olduğunu gösteriyorsa yapılandırma sorunlarını bulmak için Pilot günlüklerini incelemeniz veya istioctl dosyasını kullanmanız gerekir.

Pilot günlüklerini incelemek için istio-pilot-... ifadesini, sorun gidermek istediğiniz Pilot örneğin kapsül tanımlayıcısıyla değiştirerek kubectl -n istio-system istio-pilot-69db46c598-45m44 discovery günlüklerini çalıştırın.

Açılan günlükte, bir Aktarma Durumu mesajı 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="
}

Aktarma Durumu, yapılandırmayı Envoy proxy'lerine aktarmaya çalışırken oluşan sorunları belirtir. Bu örnekte, birkaç "Yinelenen küme" olduğunu görüyoruz. belirten bir uyarı içerir. Bu, yinelenen yukarı akış hedeflerini gösterir.

Sorunların teşhisi konusunda yardım almak için Google Cloud destek ekibiyle iletişime geçin.

Yapılandırma hatalarını bulma

istioctl kullanarak yapılandırmanızı analiz etmek için 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 olası sorunları gösterir. Bu komutun algılayabileceği yapılandırma hatalarının tam listesi için dokümanlara bakın.

17. Temizleme

Atölye tamamlandıktan sonra aşağıdaki adımlar bir yönetici tarafından gerçekleştirilir.

Bir yönetici, bootstrap_workshop.sh komut dosyası tarafından oluşturulan kaynakları silmek için clearup_workshop.sh komut dosyasını çalıştırır. Temizlik komut dosyasının çalışması için aşağıdaki bilgilere ihtiyacınız vardır.

• Kuruluş adı - örneğin yourcompany.com
• Atölye kimliği, YYMMDD-NN biçiminde, örneğin 200131-01
• Yönetici GCS paketi - önyükleme komut dosyasında tanımlanır.

13. Cloud Shell'i açın, 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 istenen Yönetici kullanıcıyla giriş yaptığınızı doğrulayın.

gcloud config list
 

15. Asm klasöründe gezinme.

cd ${WORKDIR}/asm
 

16. Silinecek kuruluşunuzun adını 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}