Семинар Anthos Service Mesh: Руководство по лабораторной работе

1. АЛЬФА-СЕМИНАР

ВАЖНОЕ ПРИМЕЧАНИЕ: ЭТО АЛЬФА-СЕМИНАР, И СТРОГО ПРЕДНАЗНАЧЕНО ДЛЯ ОБУЧЕНИЯ В КЛАССЕ ПОД ПОД руководством ИНСТРУКТОРА.

Ссылка на мастер-класс codelab bit.ly/asm-workshop

2. Обзор

Схема архитектуры

Этот семинар представляет собой практический захватывающий опыт, в котором рассказывается, как настроить глобально распределенные сервисы на GCP в производстве. Основными используемыми технологиями являются Google Kubernetes Engine (GKE) для вычислений и сервисная сетка Istio для создания безопасного подключения, наблюдения и расширенного формирования трафика. Все методы и инструменты, использованные на этом семинаре, — это те же методы, которые вы будете использовать в производстве.

Повестка дня

• Модуль 0. Введение и настройка платформы.
• Введение и архитектура
• Введение в Service Mesh и Istio/ASM
• Лабораторная работа: Настройка инфраструктуры: Рабочий процесс пользователя.
• Перерыв
• КнА
• Модуль 1. Установка, защита и мониторинг приложений с помощью ASM
• Модель репо: объяснение инфраструктуры и репозиториев Kubernetes
• Лабораторная работа: Развертывание примера приложения.
• Распределенные сервисы и наблюдаемость
• Обед
• Лабораторная работа: Наблюдаемость с помощью Stackdriver.
• КНА
• Модуль 2 — DevOps — развертывание Canary, политика/RBAC
• Обнаружение нескольких кластерных служб и безопасность/политика
• Лабораторная работа: Взаимный TLS
• Канарские развертывания
• Лабораторная работа: Canary-развертывания
• Безопасная глобальная балансировка нагрузки в нескольких кластерах
• Перерыв
• Лабораторная работа: Политика авторизации
• КНА
• Модуль 3. Инфраоперационная система. Обновления платформы.
• Строительные блоки распределенных служб
• Лабораторная работа: Масштабирование инфраструктуры.
• Следующие шаги

Слайды

Слайды к этому мастер-классу можно найти по следующей ссылке:

Слайды семинара ASM

Предварительные условия

Прежде чем приступить к этому мастер-классу, необходимо выполнить следующее:

1. Узел организации GCP
2. Идентификатор платежного аккаунта (ваш пользователь должен быть администратором платежного аккаунта в этом платежном аккаунте).
3. Роль IAM администратора организации на уровне организации для вашего пользователя.

3. Настройка инфраструктуры — рабочий процесс администратора

Действия, описанные в этом разделе, выполняются администратором, создающим мастерскую.

Если вы являетесь пользователем, проводящим семинар, перейдите к следующему разделу « Infrastructure Setup - User Workflow

Объяснение сценария семинара Bootstrap

Скрипт bootstrap_workshop.sh используется для настройки начальной среды мастерской. Вы можете использовать этот сценарий для настройки одной среды для себя или нескольких сред для нескольких пользователей, если вы проводите этот семинар в качестве обучения для нескольких пользователей.

Сценарий начальной загрузки требует в качестве входных данных следующее:

• Название организации (например, yourcompany.com ). Это организация, в которой вы создаете среду для семинара.
• Идентификатор выставления счетов (например, 12345-12345-12345 ). Этот идентификатор выставления счетов используется для выставления счетов за все ресурсы, используемые во время семинара.
• Номер мастерской (например 01 ) – двузначное число. Это используется в том случае, если вы проводите несколько семинаров в один день и хотите отслеживать их отдельно. Номера мастерских также используются для получения идентификаторов проектов. Наличие отдельных номеров мастерских позволяет каждый раз получать уникальные идентификаторы проектов. Помимо номера мастерской, для идентификаторов проектов также используется текущая дата (в формате YYMMDD ). Комбинация даты и номера мастерской обеспечивает уникальные идентификаторы проектов.
• Стартовый номер пользователя (например, 1 ) — этот номер обозначает первого пользователя в мастерской. Например, если вы хотите создать мастерскую для 10 пользователей, у вас может быть номер начального пользователя 1 и номер конечного пользователя 10.
• Номер конечного пользователя (например, 10 ). Этот номер обозначает последнего пользователя в мастерской. Например, если вы хотите создать мастерскую для 10 пользователей, у вас может быть номер начального пользователя 1 и номер конечного пользователя 10. Если вы настраиваете одну среду (например, для себя), начните и номер конечного пользователя тот же. Это создаст единую среду.

Помимо даты и номера мастерской, в идентификаторы проекта также включаются номера начального и конечного пользователя. Идентификаторы пользователей (для пользователей, проводящих семинар) получаются из номеров начального и конечного пользователя. Идентификаторы пользователей описаны в разделе « User schema and permissions performing the workshop .

• Корзина GCS администратора (например my-gcs-bucket-name ). Корзина GCS используется для хранения информации, связанной с мастерской. Эта информация используется сценарием cleanup_workshop.sh для корректного удаления всех ресурсов, созданных во время сценария начальной загрузки. Администраторы, создающие семинары, должны иметь права на чтение и запись в этот сегмент.

Сценарий мастерской начальной загрузки использует приведенные выше значения и действует как сценарий-оболочка, вызывающий сценарий setup-terraform-admin-project.sh . Скрипт setup-terraform-admin-project.sh создает среду мастерской для одного пользователя.

Для запуска мастерской необходимы права администратора.

В этом семинаре есть два типа пользователей. ADMIN_USER , который создает и удаляет ресурсы для этого семинара. Второй — MY_USER , который выполняет шаги мастерской. MY_USER имеет доступ только к своим собственным ресурсам. ADMIN_USER имеет доступ ко всем настройкам пользователя. Если вы создаете эту настройку для себя, то ADMIN_USER и MY_USER совпадают. Если вы преподаватель, создающий этот семинар для нескольких студентов, ваши ADMIN_USER и MY_USER будут разными.

Для ADMIN_USER требуются следующие разрешения на уровне организации:

• Владелец — разрешение Владельца проекта на все проекты в Организации.
• Администратор папок — возможность создавать и удалять папки в организации. Каждый пользователь получает одну папку со всеми своими ресурсами внутри проекта.
• Администратор организации
• Создатель проекта - Возможность создавать проекты в Организации.
• Удаление проектов — возможность удалять проекты в организации.
• Администратор проекта IAM — возможность создавать правила IAM во всех проектах в организации.

В дополнение к этому ADMIN_USER также должен быть администратором выставления счетов для идентификатора выставления счетов, используемого для семинара.

Схема пользователя и права проведения семинара

Если вы планируете создать этот семинар для пользователей (кроме вас самих) в вашей организации, вы должны следовать определенной схеме именования пользователей для MY_USERs . В сценарии bootstrap_workshop.sh вы указываете начальный и конечный номер пользователя. Эти номера используются для создания следующих имен пользователей:

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

Например, если вы запустите сценарий начальной загрузки семинара с номером начального пользователя 1 и номером конечного пользователя 3, в вашей организации с именем yourcompany.com будут созданы среды семинара для следующих пользователей:

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

Этим именам пользователей назначаются роли владельцев проектов для конкретных проектов, созданных во время сценария setup_terraform_admin_project.sh. Вы должны придерживаться этой схемы именования пользователей при использовании сценария начальной загрузки. Узнайте , как добавить сразу несколько пользователей в GSuite .

Инструменты, необходимые для мастерской

Этот семинар предназначен для загрузки из Cloud Shell. Для этого мастер-класса потребуются следующие инструменты.

• gcloud (версия >= 270)
• кубектл
• sed (работает с sed в Cloud Shell/Linux, а не в Mac OS)
• git (убедитесь, что вы в курсе)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• настроить

Все инструменты, кроме kustomize уже установлены в Cloud Shell по умолчанию. Если kustomize не установлен, установите его с помощью сценария bash, представленного в ссылке выше, и убедитесь, что двоичный файл kustomize находится в вашем PATH, и подтвердите, выполнив команду kustomize в Cloud Shell.

Настройте мастерскую для себя (однопользовательская настройка)

1. Откройте Cloud Shell, выполните все действия, указанные ниже, в Cloud Shell. Нажмите на ссылку ниже.

ОБЛАЧНАЯ ОБОЛОЧКА

2. Убедитесь, что вы вошли в gcloud с правами администратора.

gcloud config list
 

3. Создайте WORKDIR и клонируйте репозиторий мастерской.

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

4. Укажите название своей организации, платежный идентификатор, номер семинара и сегмент GCS администратора, который будет использоваться для семинара. Ознакомьтесь с разрешениями, необходимыми для создания мастерской, в разделах выше.

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. Выполнение этого сценария может занять несколько минут.

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 
 

Обратите внимание, что вам не нужно определять номер начального и конечного пользователя, поскольку вы настраиваете его самостоятельно.

После завершения сценария bootstrap_workshop.sh для каждого пользователя в организации создается папка GCP. В этой папке создается проект администратора terraform . Проект администратора terraform используется для создания остальных ресурсов GCP, необходимых для этого семинара. Вы включаете необходимые API в проекте администрирования terraform. Вы используете Cloud Build для применения планов Terraform. Вы предоставляете учетной записи службы Cloud Build соответствующие роли IAM, чтобы она могла создавать ресурсы в GCP. Наконец, вы настраиваете удаленный бэкэнд в корзине Google Cloud Storage (GCS) для хранения состояний Terraform для всех ресурсов GCP.

Чтобы просмотреть задачи Cloud Build в проекте администратора terraform, вам понадобится идентификатор проекта администратора terraform. Он хранится в файле vars/vars.sh в вашем каталоге asm. Этот каталог сохраняется только в том случае, если вы настраиваете мастерскую для себя в качестве администратора.

6. Создайте файл переменных для установки переменных среды.

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

Настройка семинара для нескольких пользователей (многопользовательская настройка)

7. Откройте Cloud Shell, выполните все действия, указанные ниже, в Cloud Shell. Нажмите на ссылку ниже.

ОБЛАЧНАЯ ОБОЛОЧКА

8. Убедитесь, что вы вошли в gcloud с правами администратора.

gcloud config list
 

9. Создайте WORKDIR и клонируйте репозиторий мастерской.

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

10. Определите название своей организации, платежный идентификатор, номер семинара, номер начального и конечного пользователя, а также сегмент GCS администратора, который будет использоваться для семинара. Ознакомьтесь с разрешениями, необходимыми для создания мастерской, в разделах выше.

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. Выполнение этого сценария может занять несколько минут.

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. Получите файл Workshop.txt из корзины администратора GCS, чтобы получить идентификаторы проектов terraform.

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

4. Настройка лаборатории и подготовка

Здесь начинаются пользователи, проводящие семинар. Выполните все действия из окна INCOGNITO в Chrome или Firefox.

Выберите свой путь в лаборатории

Лабораторные работы на этом семинаре могут выполняться одним из двух способов:

• Способ « простых и ускоренных интерактивных сценариев »
• Способ « ручного копирования и вставки каждой инструкции »

Метод ускоренных сценариев позволяет запускать один интерактивный сценарий для каждой лабораторной работы, который проведет вас по лабораторной работе, автоматически выполняя команды для этой лабораторной работы. Команды выполняются пакетно с краткими пояснениями каждого шага и того, что они выполняют. После каждого пакета вам будет предложено перейти к следующему пакету команд. Таким образом, вы сможете проводить лаборатории в своем темпе. Сценарии ускоренного режима являются идемпотентными , то есть их можно запускать несколько раз, что приведет к одному и тому же результату.

Сценарии ускоренного режима появятся в верхней части каждой лаборатории в зеленом поле, как показано ниже.

УСКОРЕННЫЙ СЦЕНАРИЙ

${WORKDIR}/asm/fasttrack_scripts/<имя_скрипта>.sh

Метод копирования и вставки — это традиционный способ копирования и вставки отдельных блоков команд с пояснениями к командам. Этот метод предназначен для запуска только один раз. Нет никакой гарантии, что повторный запуск команд в этом методе даст вам те же результаты.

При выполнении лабораторных работ выберите один из двух методов.

После того как вы выбрали метод и выполнили шаги этого метода, не выполняйте шаги другого метода.

Ускоренная настройка сценария

После того как вы завершите сценарий ускоренного прохождения, вы завершите эту лабораторную работу. Не выполняйте действия, описанные в лабораторных инструкциях по копированию и вставке.

Получить информацию о пользователе

Этот семинар проводится с использованием временной учетной записи пользователя (или учетной записи лаборатории), созданной администратором семинара. Учетная запись лаборатории владеет всеми проектами в мастерской. Администратор семинара предоставляет учетные данные лабораторной учетной записи (имя пользователя и пароль) пользователю, проводящему семинар. Все проекты пользователя имеют префикс имени пользователя учетной записи лаборатории, например, для учетной записи лаборатории [e-mail] идентификатор проекта администратора terraform будет user001-200131-01-tf-abcde и так далее для остальных проектов. Каждый пользователь должен войти в систему под учетной записью лаборатории, предоставленной администратором семинара, и провести семинар, используя учетную запись лаборатории.

Проверьте свою корпоративную электронную почту (тот же адрес электронной почты, который вы использовали при регистрации на семинар). Вы должны были получить электронное письмо от администратора семинара с учетными данными вашей лабораторной учетной записи (т. е. именем пользователя и паролем). Электронная почта выглядит следующим образом.

1. Откройте Cloud Shell, нажав на ссылку ниже.

ОБЛАЧНАЯ ОБОЛОЧКА

2. Войдите в систему, используя учетные данные лабораторной учетной записи (не входите в систему, используя свою корпоративную или личную учетную запись). Учетная запись лаборатории выглядит как userXYZ@<workshop_domain>.com .
3. Поскольку это новая учетная запись, вам будет предложено принять Условия использования Google . Нажмите «Принять».

4. На следующем экране установите флажок, чтобы согласиться с Условиями обслуживания Google, и нажмите « Start Cloud Shell .

На этом этапе создается небольшая виртуальная машина Linux Debian, которую вы можете использовать для доступа к ресурсам GCP. Каждая учетная запись получает виртуальную машину Cloud Shell. Вход в систему с использованием условий учетной записи лаборатории и вход в систему с использованием учетных данных учетной записи лаборатории. В дополнение к Cloud Shell также предусмотрен редактор кода, упрощающий редактирование файлов конфигурации (terraform, YAML и т. д.). По умолчанию экран Cloud Shell разделен на среду оболочки Cloud Shell (внизу) и редактор кода Cloud (вверху). Карандаш и приглашение оболочки значки в правом верхнем углу позволяют переключаться между ними (оболочкой и редактором кода). Вы также можете перетащить среднюю полосу-разделитель (вверх или вниз) и вручную изменить размер каждого окна. 5. Создайте WORKDIR для этого семинара. WORKDIR — это папка, из которой вы выполняете все лабораторные работы этого семинара. Выполните следующие команды в Cloud Shell, чтобы создать WORKDIR.

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

6. Экспортируйте пользователя учетной записи лаборатории как переменную, которая будет использоваться в этом семинаре. Это та же учетная запись, с которой вы вошли в Cloud Shell.

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

Примечание. Если вы являетесь администратором и настроили семинар для себя, используя флаги «-sufa» или «–setup-for-admin», установите для MY_USER адрес электронной почты учетной записи GCP, которую вы использовали для создания проектов семинара.

7. Повторите переменные WORKDIR и MY_USER, чтобы убедиться, что обе они установлены правильно, выполнив следующие команды.

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

8. Клонируйте репозиторий мастерской.

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

5. Настройка инфраструктуры — рабочий процесс пользователя

Цель: проверить инфраструктуру и установку Istio.

• Установить инструменты мастерской
• Репозиторий мастерской клонов
• Проверка установки Infrastructure
• Проверьте установку k8s-repo
• Проверьте установку Istio

УСКОРЕННЫЙ СЦЕНАРИЙ

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторную работу.

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

После завершения выполнения скрипта создайте исходный файл bashrc, чтобы обновить переменные в сеансе Cloud Shell.

source ${HOME}/.bashrc

Лабораторные инструкции по методу копирования и вставки

ВАЖНО. Если вы уже выполнили сценарий ускоренного выполнения этой лабораторной работы, не выполняйте метод копирования и вставки, описанный ниже**.**

Получить информацию о пользователе

Администратор, настраивающий мастерскую, должен предоставить пользователю имя пользователя и пароль. Все проекты пользователя будут иметь префикс имени пользователя, например для пользователя [e-mail] , идентификатор проекта администратора terraform будет user001-200131-01-tf-abcde и так далее для остальных проектов. Каждый пользователь имеет доступ только к своей собственной среде мастерской.

Инструменты, необходимые для мастерской

Этот семинар предназначен для загрузки из Cloud Shell. Для этого мастер-класса потребуются следующие инструменты.

Все инструменты, кроме kustomize и pv , уже установлены в Cloud Shell по умолчанию. Инструкции по установке обоих из них вы найдете ниже.

• gcloud (версия >= 270)
• кубектл
• sed (работает с sed в Cloud Shell/Linux, а не в Mac OS)
• git (убедитесь, что вы в курсе)
• sudo apt update
• sudo apt install git
• jq
• envsubst
• настроить
• пв

Доступ к проекту администратора terraform

После завершения сценария bootstrap_workshop.sh для каждого пользователя в организации создается папка GCP. В этой папке создается проект администратора terraform . Проект администратора terraform используется для создания остальных ресурсов GCP, необходимых для этого семинара. Скрипт setup-terraform-admin-project.sh включает необходимые API в проекте администрирования terraform. Cloud Build используется для применения планов Terraform. С помощью сценария вы предоставляете учетной записи службы Cloud Build соответствующие роли IAM, чтобы она могла создавать ресурсы в GCP. Наконец, в корзине Google Cloud Storage (GCS) настраивается удаленный бэкэнд для хранения состояний Terraform для всех ресурсов GCP.

Чтобы просмотреть задачи Cloud Build в проекте администратора terraform, вам понадобится идентификатор проекта администратора terraform. Он хранится в сегменте GCS администратора, указанном в сценарии начальной загрузки. Если вы запускаете сценарий начальной загрузки для нескольких пользователей, все идентификаторы проектов администратора terraform находятся в корзине GCS.

Этот семинар предназначен для проведения в Cloud Shell и Cloud Console. Выполните следующие шаги в окне INCOGNITO , поскольку вы будете входить в систему с отдельным именем пользователя и паролем.

1. Откройте Cloud Shell (если он еще не открыт в разделе «Настройка и подготовка лаборатории»), нажав ссылку ниже.

ОБЛАЧНАЯ ОБОЛОЧКА

2. Установите kustomize (если он еще не установлен) в папку $HOME/bin и добавьте папку $HOME/bin в $PATH.

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

3. Установите pv и переместите его в $HOME/bin/pv.

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

4. Обновите приглашение bash.

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 с нужной учетной записью пользователя.

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

6. Получите идентификатор проекта администратора Terraform, выполнив следующую команду:

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

7. Все ресурсы, связанные с мастерской, хранятся в виде переменных в файле vars.sh, хранящемся в корзине GCS в проекте администратора terraform. Получите файл vars.sh для вашего проекта администратора terraform.

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 и убедиться, что сборка завершена успешно.

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

При первом доступе к Cloud Console примите Условия использования Google.

9. Теперь, когда вы просматриваете страницу Cloud Build , нажмите ссылку History в левой навигационной панели и выберите последнюю сборку, чтобы просмотреть подробную информацию о первоначальном применении Terraform. Следующие ресурсы создаются как часть скрипта Terraform. Вы также можете обратиться к схеме архитектуры выше.

• 4 проекта GCP в организации. Предоставленный платежный аккаунт связан с каждым проектом.
• Один проект — это network host project для общего VPC. Никакие другие ресурсы в этом проекте не создаются.
• Одним из проектов является ops project используемый для кластеров GKE плоскости управления Istio.
• Два проекта представляют собой две разные команды разработчиков, работающие над своими соответствующими сервисами.
• В каждом из трех проектов ops , dev1 и dev2 создается по два кластера GKE.
• Создается репозиторий CSR с именем k8s-repo , который содержит шесть папок для файлов манифестов Kubernetes. Одна папка на кластер GKE. Этот репозиторий используется для развертывания манифестов Kubernetes в кластерах в стиле GitOps.
• Триггер Cloud Build создается таким образом, что каждый раз при фиксации основной ветки k8s-repo он развертывает манифесты Kubernetes в кластерах GKE из соответствующих папок.

Скрипт терраформирования занимает 40-50 минут.

10. Как только сборка завершится в terraform admin project начнется другая сборка проекта ops. Щелкните отображаемую ссылку, чтобы открыть страницу Cloud Build для ops project и убедиться, что облачная сборка k8s-repo успешно завершена.

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

Примечание. Эту сборку необходимо завершить, прежде чем вы сможете проверить установку Istio.

Проверка установки

11. Создайте файлы kubeconfig для всех кластеров. Запустите следующий скрипт.

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

Этот скрипт создает новый файл kubeconfig в папке gke с именем kubemesh .

12. Измените переменную KUBECONFIG , чтобы она указывала на новый файл kubeconfig.

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

13. Добавьте переменную vars.sh и KUBECONFIG в файл .bashrc в Cloud Shell, чтобы она получалась каждый раз при перезапуске Cloud Shell.

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

14. Перечислите контексты вашего кластера. Вы должны увидеть шесть кластеров.

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

15. Убедитесь, что Istio установлен в обоих кластерах, проверив, что все модули работают и задания завершены.

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 установлен в обоих кластерах dev1 . В кластерах dev1 работают только Citadel, Sidecar-injector и coredns. Они используют общую плоскость управления Istio, работающую в кластере ops-1.

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

17. Убедитесь, что Istio установлен в обоих кластерах dev2 . В кластерах dev2 работают только Citadel, Sidecar-injector и coredns. Они используют общую плоскость управления Istio, работающую в кластере ops-2.

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

    `Output (do not copy)`

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

Проверка обнаружения служб для общих плоскостей управления

18. При необходимости убедитесь, что секреты развернуты.

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

В этом семинаре вы используете один общий VPC , в котором создаются все кластеры GKE. Чтобы обнаружить сервисы в кластерах, вы используете файлы kubeconfig (для каждого из кластеров приложений), созданные как секреты в кластерах операций. Pilot использует эти секреты для обнаружения Сервисов путем запроса API-сервера Kube кластеров приложений (аутентифицированных с помощью секретов, указанных выше). Вы видите, что оба кластера операций могут аутентифицироваться во всех кластерах приложений, используя секреты, созданные kubeconfig. Кластеры Ops могут автоматически обнаруживать сервисы, используя файлы kubeconfig в качестве секретного метода. Для этого необходимо, чтобы пилот в операционных кластерах имел доступ к API-серверу Kube всех остальных кластеров. Если Pilot не может получить доступ к серверам Kube API, вам придется вручную добавить удаленные службы как ServiceEntries . Вы можете рассматривать ServiceEntries как записи DNS в реестре служб. ServiceEntries определяет службу, используя полное DNS-имя ( FQDN ) и IP-адрес, по которому к ней можно получить доступ. Дополнительную информацию см. в документации Istio Multicluster .

6. Объяснение инфраструктуры репо

Создание облачной инфраструктуры

Ресурсы GCP для семинара создаются с использованием Cloud Build и репозитория CSR infrastructure . Вы только что запустили сценарий начальной загрузки (находится по адресу scripts/bootstrap_workshop.sh ) со своего локального терминала. Сценарий начальной загрузки создает папку GCP, проект администратора terraform и соответствующие разрешения IAM для учетной записи службы Cloud Build . Проект администратора Terraform используется для хранения состояний, журналов и различных скриптов terraform. Он содержит infrastructure и репозитории CSR k8s_repo . Эти репозитории подробно описаны в следующем разделе. Никакие другие ресурсы мастерской в ​​проекте администратора terraform не создаются. Учетная запись службы Cloud Build в проекте администратора terraform используется для создания ресурсов для мастерской.

Файл cloudbuild.yaml , расположенный в папке infrastructure , используется для создания ресурсов GCP для семинара. Он создает собственный образ компоновщика со всеми инструментами, необходимыми для создания ресурсов GCP. Эти инструменты включают в себя gcloud SDK, terraform и другие утилиты, такие как python, git, jq и т. д. Пользовательский образ компоновщика запускает terraform plan и apply к каждому ресурсу. Файлы terraform каждого ресурса расположены в отдельных папках (подробности в следующем разделе). Ресурсы создаются по одному и в том порядке, в котором они обычно создаются (например, проект GCP создается до создания ресурсов в проекте). Для получения более подробной информации просмотрите файл cloudbuild.yaml .

Cloud Build запускается каждый раз при фиксации репозитория infrastructure . Любое изменение, внесенное в инфраструктуру, сохраняется как «Инфраструктура как код» (IaC) и фиксируется в репозитории. Состояние вашей мастерской всегда хранится в этом репозитории.

Структура папок — команды, среды и ресурсы

Репозиторий инфраструктуры настраивает ресурсы инфраструктуры GCP для семинара. Он структурирован по папкам и подпапкам. Базовые папки в репозитории представляют team , владеющую конкретными ресурсами GCP. Следующий уровень папок представляет конкретную environment для команды (например, dev, stage, prod). Следующий уровень папок в среде представляет конкретный resource (например, host_project, gke_clusters и т. д.). Необходимые сценарии и файлы terraform находятся в папках ресурсов.

На семинаре представлены следующие четыре типа команд:

1. инфраструктура — представляет команду облачной инфраструктуры. Они отвечают за создание ресурсов GCP для всех остальных команд. Они используют административный проект Terraform для своих ресурсов. Сам репозиторий инфраструктуры находится в проекте администратора Terraform, а также в файлах состояния Terraform (поясняется ниже). Эти ресурсы создаются сценарием bash во время процесса начальной загрузки (подробности см. в разделе «Модуль 0 — Рабочий процесс администратора»).
2. сеть — представляет сетевую команду. Они отвечают за VPC и сетевые ресурсы. Им принадлежат следующие ресурсы GCP.
3. host project — представляет общий хост-проект VPC.
4. shared VPC — представляет общий VPC, подсети, дополнительные диапазоны IP-адресов, маршруты и правила брандмауэра.
5. ops — представляет команду эксплуатации/разработки. Им принадлежат следующие ресурсы.
6. ops project — представляет проект для всех ресурсов ops.
7. gke clusters — кластер ops GKE для каждого региона. Плоскость управления Istio установлена ​​в каждом из кластеров ops GKE.
8. k8s-repo — репозиторий CSR, содержащий манифесты GKE для всех кластеров GKE.
9. apps — представляет команды приложений. В этом семинаре моделируются две команды, а именно app1 и app2 . Им принадлежат следующие ресурсы.
10. app projects — каждая команда разработчиков приложений получает свой собственный набор проектов. Это позволяет им контролировать выставление счетов и IAM для своего конкретного проекта.
11. gke clusters — это кластеры приложений, в которых запускаются контейнеры/поды приложений.
12. gce instances — необязательно, если у них есть приложения, работающие на экземплярах GCE. В этом семинаре у приложения app1 есть несколько экземпляров GCE, в которых выполняется часть приложения.

В этом семинаре одно и то же приложение (приложение магазина хипстеров) представляет как приложение1, так и приложение2.

Поставщик, состояния и выходные данные — серверные части и общие состояния

Поставщики google и google-beta расположены по адресу gcp/[environment]/gcp/provider.tf . Файл provider.tf имеет символическую ссылку в каждой папке ресурсов. Это позволяет менять провайдера в одном месте вместо того, чтобы индивидуально управлять провайдерами для каждого ресурса.

Каждый ресурс содержит файл backend.tf , который определяет расположение файла tfstate ресурса. Этот файл backend.tf создается на основе шаблона (находится по адресу templates/backend.tf_tmpl ) с помощью сценария (находится по адресу scripts/setup_terraform_admin_project ), а затем помещается в соответствующую папку ресурсов. Корзины Google Cloud Storage (GCS) используются для серверных частей. Имя папки сегмента GCS соответствует имени ресурса. Все серверные части ресурсов находятся в проекте администратора terraform.

Ресурсы с взаимозависимыми значениями содержат файл output.tf . Требуемые выходные значения хранятся в файле tfstate, определенном в серверной части для этого конкретного ресурса. Например, чтобы создать в проекте кластер GKE, вам необходимо знать идентификатор проекта. Идентификатор проекта выводится через файл output.tf в файл tfstate, который можно использовать через источник данных terraform_remote_state в ресурсе кластера GKE.

Файлshared_state — это источник данных terraform_remote_state указывающий на файл tfstate ресурса. Файл shared_state_[resource_name].tf (или файлы) существует в папках ресурсов, которым требуются выходные данные из других ресурсов. Например, в папке ресурсов ops_gke находятся файлыshared_state из ресурсов ops_project shared_vpc , поскольку вам нужен идентификатор проекта и сведения о VPC для создания кластеров GKE в проекте ops. Файлыshared_state генерируются из шаблона (находящегося по адресу templates/shared_state.tf_tmpl ) с помощью сценария (находящегося по адресу scripts/setup_terraform_admin_project ). Файлыshared_state всех ресурсов помещаются в папку gcp/[environment]/shared_states . Требуемые файлыshared_state имеют символические ссылки в соответствующих папках ресурсов. Размещение всех файловshared_state в одной папке и символическая связь с ними в соответствующих папках ресурсов упрощает управление всеми файлами состояния в одном месте.

Переменные

Все значения ресурсов хранятся как переменные среды. Эти переменные хранятся (как операторы экспорта) в файле vars.sh , расположенном в корзине GCS в проекте администратора terraform. Он содержит идентификатор организации, платежный аккаунт, идентификаторы проектов, сведения о кластере GKE и т. д. Вы можете загрузить и получить vars.sh из любого терминала, чтобы получить значения для вашей настройки.

Переменные Terraform хранятся в vars.sh как TF_VAR_[variable name] . Эти переменные используются для создания variables.tfvars в соответствующей папке ресурсов. Файл variables.tfvars содержит все переменные с их значениями. Файл variables.tfvars создается из файла шаблона в той же папке с помощью сценария (находится по адресу scripts/setup_terraform_admin_project ).

Объяснение репо K8s

k8s_repo — это репозиторий CSR (отдельный от репозитория инфраструктуры), расположенный в проекте администрирования Terraform. Он используется для хранения и применения манифестов GKE ко всем кластерам GKE. k8s_repo создается с помощью Cloud Build инфраструктуры (подробности см. в предыдущем разделе). В ходе первоначального процесса построения инфраструктуры Cloud Build создается в общей сложности шесть кластеров GKE. В k8s_repo создаются шесть папок. Каждая папка (имя соответствует имени кластера GKE) соответствует кластеру GKE, содержащему соответствующие файлы манифеста ресурсов. Подобно построению инфраструктуры, Cloud Build используется для применения манифестов Kubernetes ко всем кластерам GKE с помощью k8s_repo. Cloud Build запускается каждый раз при фиксации репозитория k8s_repo . Как и в случае с инфраструктурой, все манифесты Kubernetes хранятся в виде кода в репозитории k8s_repo , а состояние каждого кластера GKE всегда хранится в соответствующей папке.

В рамках первоначальной сборки инфраструктуры создается k8s_repo и устанавливается Istio на все кластеры.

Проекты, кластеры GKE и пространства имен

Ресурсы этого семинара разделены на различные проекты GCP. Проекты должны соответствовать организационной (или командной) структуре вашей компании. Команды (в вашей организации), ответственные за разные проекты/продукты/ресурсы, используют разные проекты GCP. Наличие отдельных проектов позволяет создавать отдельные наборы разрешений IAM и управлять выставлением счетов на уровне проекта. Кроме того, квоты также управляются на уровне проекта.

В этом мастер-классе представлены пять команд, каждая со своим проектом.

1. Команда инфраструктуры , создающая ресурсы GCP, использует Terraform admin project . Они управляют инфраструктурой как кодом в репозитории CSR (называемом infrastructure ) и хранят всю информацию о состоянии Terraform, относящуюся к ресурсам, встроенным в GCP, в сегментах GCS. Они контролируют доступ к репозиторию CSR и корзинам GCS состояния Terraform.
2. Сетевая команда , которая создает общий VPC, использует host project . Этот проект содержит VPC, подсети, маршруты и правила брандмауэра. Наличие общего VPC позволяет им централизованно управлять сетью ресурсов GCP. Все проекты использовали этот общий VPC для сети.
3. Команда ops/platform , которая создает кластеры GKE и плоскости управления ASM/Istio, использует ops project . Они управляют жизненным циклом кластеров GKE и сервисной сети. Они отвечают за усиление защиты кластеров, управление устойчивостью и масштабированием платформы Kubernetes. В этом семинаре вы используете метод gitops для развертывания ресурсов в Kubernetes. Репозиторий CSR (называемый k8s_repo ) существует в проекте ops.
4. Наконец, команды dev1 и dev2 (представляют собой две команды разработчиков), создающие приложения, используют свои собственные проекты dev1 и dev2 projects . Это приложения и услуги, которые вы предоставляете своим клиентам. Они построены на платформе, которой управляет команда эксплуатации. Ресурсы (развертывания, службы и т. д.) передаются в k8s_repo и развертываются в соответствующих кластерах. Важно отметить, что этот семинар не фокусируется на лучших практиках и инструментах CI/CD. Вы используете Cloud Build для автоматизации развертывания ресурсов Kubernetes напрямую в кластерах GKE. В реальных производственных сценариях для развертывания приложений в кластерах GKE следует использовать подходящее решение CI/CD.

В этом мастер-классе представлены два типа кластеров GKE.

1. Кластеры Ops — используются командой эксплуатации для запуска инструментов Devop. На этом семинаре они запускают плоскость управления ASM/Istio для управления сервисной сеткой.
2. Кластеры приложений (приложений) — используются группами разработчиков для запуска приложений. В этом мастер-классе используется приложение Hipster shop.

Отделение инструментов эксплуатации/администрирования от кластеров, на которых работает приложение, позволяет вам управлять жизненным циклом каждого ресурса независимо. Два типа кластеров также существуют в различных проектах, относящихся к команде/продукту, которые используют их, что делает разрешения IAM также легче управлять.

Всего есть шесть кластеров GKE. Два региональных кластера OPS созданы в проекте OPS. Плона управления ASM/ISTIO устанавливается на обоих кластерах OPS. Каждый кластер OPS находится в другой области. Кроме того, существует четыре зональных кластера. Они созданы в их собственных проектах. Этот семинар имитирует две команды разработчиков со своими собственными проектами. Каждый проект содержит два кластера приложения. Кластеры приложений являются зональными кластерами в разных зонах. Четыре кластера приложения расположены в двух регионах и в четырех зонах. Таким образом, вы получаете региональную и зональную избыточность.

Приложение, используемое в этом семинаре, приложение Hipster Shop, развернуто во всех четырех кластерах приложений. Каждый микросервис живет в своем собственном пространстве имен в каждом кластере приложений. Развертывания приложений Hipster Shop (POD) не развернуты в кластерах OPS. Тем не менее, пространства имен и сервисные ресурсы для всех микросервисов также создаются в кластерах OPS. Самона управления ASM/ISTIO использует реестры услуг Kubernetes для обнаружения услуг. В отсутствие услуг (в кластерах OPS) вам придется вручную создавать ServiceEntries для каждой услуги, работающей в кластере приложений.

Вы развертываете 10-уровневое приложение микросервисов в этом семинаре. Приложение представляет собой веб-приложение для электронной коммерции под названием « Hipster Shop », где пользователи могут просматривать предметы, добавить их в корзину и приобрести их.

Kubernetes manifests и k8s_repo

Вы используете k8s_repo , чтобы добавить ресурсы Kubernetes ко всем кластерам GKE. Вы делаете это, копируя манифесты Kubernetes и посвятив k8s_repo . Все общаются с запуска k8s_repo задания по сборке облачной, которая развертывает Kubernetes, проявляется в соответствующем кластере. Манифест каждого кластера расположен в отдельной папке с названием «Имя кластера».

Шесть имен кластеров:

1. GKE-ASM-1-R1-PROD -Региональный кластер OPS в области 1
2. GKE-ASM-2-R2-PROD -Региональный кластер OPS в области 2
3. GKE-1-APPS-R1A-PROD -кластер приложений в зоне 1 зоны A
4. GKE-2-APPS-R1B-PROD -кластер приложений в зоне 1 зоны B
5. GKE-3-APPS-R2A-PROD -кластер приложений в зоне 2 зоны 2
6. GKE-4-APPS-R2B-PROD -кластер приложений в зоне 2 зоны 2

k8s_repo имеет папки, соответствующие этим кластерам. Любой манифест, помещенный в эти папки, применяется к соответствующему кластеру GKE. Манифесты для каждого кластера размещаются в подпадчиках (в основной папке кластера) для простоты управления. На этом семинаре вы используете Kustomize , чтобы отслеживать ресурсы, которые развертываются. Пожалуйста, обратитесь к официальной документации Kustomize для получения более подробной информации.

7. Разверните приложение Sample

Цель: развернуть приложение Hipster Shop на кластерах приложений

• Клон k8s-repo
• Скопировать Hipster Shop Manifests во все кластеры приложений
• Создать услуги для приложения Hipster Shop в кластерах OPS
• Настройка loadgenerators в кластерах OPS для проверки глобальной связи
• Проверьте безопасное подключение к приложению Hipster Shop

Быстрый сценарий

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторию.

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

Скопирование метода лабораторных инструкций

Если вы уже завершили скрипт Fast Track для этой лаборатории, не выполняйте метод копирования и вставки ниже **. **

Клонировать Ops Project Source Repo

В рамках первоначальной сборки инфраструктуры Terraform, k8s-repo уже создан в проекте OPS.

1. Создайте пустой каталог для Git Repo:

mkdir $WORKDIR/k8s-repo
 

2. Init git repo, добавить удаленный и вытащить мастер из Remote Repo:

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. Установите локальную локальную конфигурацию GIT.

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

Копирование манифестов, фиксация и отправка

4. Скопируйте пространства и услуги Hipster Shop в исходном репо для всех кластеров.

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 для всех кластеров.

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, RBAC и PodsecurityPolicy в исходное репо для кластеров приложений.

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, RBAC и PodsecurityPolicy из всех, кроме одного кластера Dev. Hipstershop не был построен для многокластерного развертывания, поэтому, чтобы избежать противоречивых результатов, мы используем только одно уборку.

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. Добавьте развертывание CartService, RBAC и PodsecurityPolicy в Kustomization.yaml только в первом кластере Dev.

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

9. Удалить PodsecurityPolicies, развертывания и каталоги RBAC из OPS Clusters Kustomization.yaml

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

10. Замените Project_ID в манифестах RBAC.

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

11. Скопируйте INGRESSGATEWAY и VirtualService, проявляющиеся в исходном репо для кластеров OPS.

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

12. Скопируйте ресурсы Config Connector в один из кластеров в каждом проекте.

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. Замените Project_ID в манифестах конфигурации.

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 Manifests (развертывание, PodsecurityPolicy и RBAC) в кластеры OPS. Приложение Hipster Shop обнажается с использованием глобального балансировщика Google Cloud Load (GCLB). GCLB получает клиент -трафик (суждено на frontend ) и отправляет его в ближайший экземпляр Сервиса. Размещение loadgenerator в обоих кластерах OPS обеспечит отправку трафика для обоих шлюзов ISTIO Ingress, работающих в кластерах OPS. Балансировка нагрузки подробно объясняется в следующем разделе.

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. Замените идентификатор проекта OPS в манифестах loadgenerator для обоих кластеров OPS.

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

16. Добавьте ресурсы loadgenerator в Kustomization.yaml для обоих кластеров OPS.

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 .

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

18. Посмотреть статус построения Cloud Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

Проверьте развертывание приложения

19. Проверьте стручки во всех пространствах имен приложений, кроме CART, находящиеся в состоянии управления во всех кластерах DEV.

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

Output (do not copy)

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

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

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

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

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

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

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

20. Проверьте стручки в пространстве имен корзины находятся в состоянии управления только в первом кластере Dev.

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

Глобальная балансировка нагрузки

Теперь у вас есть приложение Hipster Shop, развернутое во всех четырех кластерах приложений. Эти кластеры находятся в двух регионах и в четырех зонах. Клиенты могут получить доступ к приложению Hipster Shop, получив доступ к услуге frontend . Служба frontend работает на всех четырех кластерах приложений. Balancer Google Cloud Load Load ( GCLB ) используется для получения клиентского трафика для всех четырех экземпляров службы frontend .

Istio Ingress Gateways работают только в кластерах OPS и выступают в качестве регионального балансировщика нагрузки для двух зональных кластеров применения в регионе. GCLB использует две шлюзы ISTIO Ingress (работая в двух кластерах OPS) в качестве бэкэндов для глобальной службы фронта. Шлюзы Istio Ingress получают клиент -трафик от GCLB, а затем отправляют клиент -трафик вперед на фронтальные стручки, работающие в кластерах приложения.

В качестве альтернативы, вы можете напрямую поместить шлюзы ISTIO Ingress в кластеры приложения, и GCLB может использовать их в качестве бэкэндов.

GKE Autoneg Controller

Istio Ingress Gateway Kebernetes Service регистрируется в качестве бэкэнда для GCLB с использованием групп конечных точек сети (NEGS). NEGS позволяет балансировать нагрузку с контейнером с использованием GCLBS. NEGS создается посредством специальной аннотации в службе Kubernetes, поэтому она может зарегистрироваться в контроллере NEG. Autoneg Controller - это специальный контроллер GKE, который автоматизирует создание NEGS, а также назначает их в качестве бэкэндов GCLB с использованием сервисных аннотаций. Плоки управления ISTIO, включая шлюзы ISTIO Ingress, развернуты во время начальной инфраструктуры Terraform Cloud Build. Конфигурация GCLB и Autoneg выполняется как часть начальной сборки облака инфраструктуры терраформ.

Безопасный вход с использованием облачных конечных точек и управляемых сертификатов

Управляемые GCP CERT используются для обеспечения трафика клиента на frontend GCLB Service. GCLB использует управляемые CERT для глобальной службы frontend , а сертификат прекращается в GCLB. На этом семинаре вы используете облачные конечные точки в качестве домена для управляемого сертификата. В качестве альтернативы, вы можете использовать свой домен и название DNS для frontend для создания управляемых GCP CERT.

21. Чтобы получить доступ к магазину Hipster, нажмите на вывод ссылки следующей команды.

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

22. Вы можете проверить, что сертификат действителен, щелкнув символ блокировки в панели URL вашей вкладки Chrome.

Проверьте глобальную балансировку нагрузки

В рамках развертывания приложений генераторы нагрузки были развернуты в обоих кластерах OPS, которые генерируют тестовый трафик для ссылки на облачные конечные точки GCLB Hipster Shop. Убедитесь, что GCLB получает трафик и отправляется в оба шлюза Istio Ingress.

23. Получите ссылку на мониторинг GCLB> для проекта OPS, где создается Hipster Shop GCLB.

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. Изменить от всех бэкэндов на Istio-Engressgateway от выпадающего меню с бэкэнд, как показано ниже.

25. Обратите внимание на трафик, идущий в оба istio-ingressgateways .

Существует три оттенка, созданные для istio-ingressgateway . Поскольку кластеры OPS являются региональными кластерами, для каждой зоны в регионе создается один нега. Однако стручки istio-ingressgateway работают в одной зоне на область. Трафик показан, идущий на стручки istio-ingressgateway .

Генераторы нагрузки работают в обоих кластерах OPS istio-ingressgateway имитирующих трафик клиента из двух областей, в которых они находятся. Нагрузка, генерируемая в области 1 кластера OPS отправлено в istio-ingressgateway в регионе 2.

8. Наблюдаемость со Stackdriver

Цель: подключите телеметрию ISTIO к стекдриверу и проверке.

• Установите ресурсы istio-telemetry
• Создание/обновление мониторных панелей ISTIO Services
• Просмотреть журналы контейнеров
• Просмотреть распределенную трассировку в Stackdriver

Быстрый сценарий

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторию.

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

Скопирование метода лабораторных инструкций

Если вы уже завершили скрипт Fast Track для этой лаборатории, не выполняйте метод копирования и вставки ниже **. **

Одной из основных особенностей ISTIO является встроенная наблюдаемость («O11y»). Это означает, что даже с черными ящиками, не взыскательными контейнерами, операторы все еще могут наблюдать за тем, как трафик входит и выходит из этих контейнеров, предоставляя услуги клиентам. Это наблюдение принимает форму нескольких различных методов: метрики, журналы и следы.

Мы также будем использовать встроенную систему генерации нагрузки в Hipster Shop. Наблюдение не очень хорошо работает в статической системе без трафика, поэтому генерация нагрузки помогает нам понять, как она работает. Эта нагрузка уже работает, теперь мы просто сможем ее увидеть.

1. Установите файл конфигурации iStio в StackDriver.

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

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

2. Сделать K8S-Repo.

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

3. Посмотреть статус построения Cloud Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

4. Проверьте интеграцию ISTIO → StackDriver Получить обработчик StackDriver CRD.

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

Вывод должен показывать обработчик по имени Stackdriver:

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

5. Убедитесь, что работает экспорт метрик ISTIO в StackDriver. Нажмите на вывод ссылки из этой команды:

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

Вам будет предложено создать новое рабочее пространство, названное в честь проекта OPS, просто выберите OK. Если это подсказывает вам новый пользовательский интерфейс, просто отклоните диалог.

В исследователе метриков в разделе «Найти тип ресурса и метрический тип» istio , чтобы увидеть, как есть такие параметры, как «количество запросов сервера» в типе ресурса «контейнер Kubernetes». Это показывает нам, что метрики текут из сетки в стекдривер.

(Вам придется группироваться по метке destination_service_name , если вы хотите увидеть строки ниже.)

Визуализация метрик с мониторингами:

Теперь, когда наши метрики находятся в системе StackDriver APM, мы хотим, чтобы их визуализировать их. В этом разделе мы установим предварительно созданную панель панели, которая показывает нам три из четырех « золотых сигналов » метрик: трафик (запросы в секунду), задержку (в данном случае, 99-й и 50-й процентиль) и ошибки (мы «За исключением насыщения в этом примере).

Прокси -сервер Envoy's Istio дает нам несколько метрик , но это хороший набор для начала. (исчерпывающий список здесь ). Обратите внимание, что каждая метрика имеет набор меток, которые можно использовать для фильтрации, агрегирования, таких как: destination_service, source_workload_namespace, response_code, istio_tcp_received_bytes_total и т. Д.).

6. Теперь давайте добавим нашу предварительно зарегистрированную панель мониторинга. Мы собираемся использовать API приборной панели напрямую. Это то, что вы обычно не делаете, с помощью вызовов API-сгенерирования вручную, это было бы частью системы автоматизации, или вы создадите панель инструментов вручную в веб-интерфейсе. Это заставит нас быстро начать:

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. Перейдите к выходной ссылке ниже, чтобы просмотреть недавно добавленную «Dashboard Services».

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

Мы могли бы редактировать панель приборной панели, используя UX, но в нашем случае мы собираемся быстро добавить новый график, используя API. Чтобы сделать это, вы должны снять последнюю версию панели панели, применить свои изменения, затем нажмите обратно, используя метод HTTP Patch.

8. Вы можете получить существующую панель панели, запрашивая API мониторинга. Получите существующую панель, которая была только что добавлена:

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. Добавьте новый график: (50 -е %задержки ILE): [ ссылка API ] Теперь мы можем добавить новый виджет графа в нашу панель панели в коде. Это изменение может быть рассмотрено сверстниками и зарегистрировано в управлении версиями. Вот виджет, который показывает 50%задержки ILE (медианная задержка).

Попробуйте отредактировать приборную панель, которую вы только что получили, добавив новую строфе:

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. Обновите существующую панель панели услуг:

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. Просмотреть обновленную панель мониторинга, перейдя по следующей выводительной ссылке:

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

12. Сделайте несколько простого анализа журналов.

Istio предоставляет набор структурированных журналов для всех сетевых трафиков в сетке и загружает их в журнал StackDriver, чтобы разрешить кросс-кластерный анализ одним мощным инструментом. Журналы аннотируются с метаданными на уровне обслуживания, такими как кластер, контейнер, приложение, connection_id и т. Д.

Пример записи журнала (в данном случае, AccessLog Envoy Proxy) может выглядеть как это (триммирован):

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

Просмотреть свои журналы здесь:

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

Вы можете просмотреть журналы плоскости управления ISTIO, выбрав ресурс> kubernetes Container и поиск в «Пилоте» -

Здесь мы можем увидеть плоскость управления ISTIO, толкающая прокси -конфигурацию прокси в прокси -прокси для каждой службы приложений. «CDS», «LDS» и «RDS» представляют различные API -интерфейсы ENGOY ( больше информации ).

Помимо журналов Istio, вы также можете найти журналы контейнеров, а также инфраструктуру или другие журналы служб GCP в одном и том же интерфейсе. Вот несколько образцов журналов запросов для GKE. Просмотрщик журналов также позволяет создавать метрики из журналов (например: «Считайте каждую ошибку, которая соответствует некоторой строке»), которые можно использовать на панели панели или как часть оповещения. Журналы также могут быть переданы на другие инструменты анализа, такие как BigQuery.

Некоторые образцы фильтров для Hipster Shop:

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

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

13. Проверьте распределенные следы.

Теперь, когда вы работаете с распределенной системой, отладка нуждается в новом инструменте: распределенное трассировку . Этот инструмент позволяет вам обнаружить статистику о том, как взаимодействуют ваши услуги (например, поиск медленных событий на рисунке ниже), а также погрузиться в необработанные следов образцов, чтобы исследовать детали того, что на самом деле происходит.

Вид с временной шкалой показывает все запросы с течением времени, графические из -за их задержки или времени, проведенного между первоначальным запросом, через стек хипстер, чтобы наконец -то ответить на конечного пользователя. Чем выше точки, тем медленнее (и менее счастливое!) Опыт пользователя.

Вы можете нажать на точку, чтобы найти подробный вид водопада по этому конкретному запросу. Эта способность найти необработанные детали конкретного запроса (не только совокупную статистику) жизненно важна для понимания взаимодействия между услугами, особенно при поиске редких, но плохих взаимодействий между услугами.

Вид водопада должен быть знаком всем, кто использовал отладчика, но в этом случае вместо того, чтобы показывать время, проведенное в разных процессах одного приложения, это показывает время, проходящее время, проходящее, между службами, работающими в отдельных контейнерах.

Здесь вы можете найти свои следы:

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

Пример скриншота инструмента:

9. Взаимная аутентификация TLS

Цель: безопасное соединение между микросервисами (AUTHN).

• Включить MTLS сетки
• Проверьте MTL, осматривая журналы

Быстрый сценарий

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторию.

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

Скопирование метода лабораторных инструкций

Если вы уже завершили скрипт Fast Track для этой лаборатории, не выполняйте метод копирования и вставки ниже **. **

Теперь, когда наши приложения установлены и настраиваются наблюдаемость, мы можем начать защищать соединения между службами и убедиться, что они продолжают работать.

Например, на приборной панели Kiali мы можем видеть, что наши услуги не используют MTL (No «Lock»). Но трафик течет, и система работает нормально. Наша панель Dashboard Golden Metrics Stackdriver дает нам душевное спокойствие, что в целом все работает.

1. Проверьте сетку в кластерах OPS. Примечание MTLS PERMISSIVE как зашифрованный, так и не MTLS-трафик.

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

    `Output (do not copy)`

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

ISTIO настроен на всех кластерах с использованием оператора ISTIO, который использует пользовательский ресурс IstioControlplane (CR). Мы будем настроить MTL во всех кластерах, обновляя IstioControlplane CR и обновляя K8S-Repo. Установка Global> MTLS> включена: true в IstioControlplane CR приводит к следующим двум изменениям в плоскости управления ISTIO:

• Meshpolicy собирается включить MTLS сетки для всех услуг, работающих во всех кластерах.
• DestinationRule создан, чтобы разрешить istio_mutual трафик между службами, работающими во всех кластерах.

2. Мы применим кувшиновый патч на IstioControlplane CR, чтобы включить кластер MTLS шириной. Скопируйте патч для соответствующего DIR для всех кластеров и добавьте патч Kustomize.

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

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

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

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

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

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

3. Сделать K8S-Repo.

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

4. Посмотреть статус построения Cloud Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

 

Проверьте MTL

5. Проверьте Meshpolicy еще раз в кластерах OPS. Примечание MTLS больше не PERMISSIVE и позволит только провести трафик MTLS.

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

Вывод (не копируйте):

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

6. Опишите DestinationRule, созданный контроллером оператора ISTIO.

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

Вывод (не копируйте):

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

Мы также можем увидеть переход от HTTP к HTTPS в журналах.

Мы можем разоблачить это конкретное поле из журналов в пользовательском интерфейсе, нажав один вход в один из журналов, а затем нажав на значение поля, которое вы хотите отобразить, в нашем случае нажмите «http» рядом с «Протокол:

Это приводит к хорошему способу визуализации переключения.:

10. Канарские развертывания

Цель: разверните новую версию Frontend Service.

• Руководитель frontend-v2 (Next Production Version) в одном регионе
• Используйте DestinationRules и VirtualServices , чтобы медленно направлять трафик на frontend-v2
• Проверьте трубопровод развертывания Gitops, осматривая серию коммитов в k8s-repo

Быстрый сценарий

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторию.

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

Скопирование метода лабораторных инструкций

Если вы уже завершили скрипт Fast Track для этой лаборатории, не выполняйте метод копирования и вставки ниже **. **

Канарское развертывание - это прогрессивное развертывание нового сервиса. В канарейском развертывании вы отправляете растущий объем трафика в новую версию, в то же время отправляя оставшийся процент в текущую версию. Общей схемой является выполнение канарского анализа на каждом этапе расщепления трафика и сравнить «золотые сигналы» новой версии (задержка, частота ошибок, насыщение) с базовой линией. Это помогает предотвратить перебои и обеспечить стабильность новой услуги "V2" на каждом этапе расщепления трафика.

В этом разделе вы узнаете, как использовать облачные политики в области сборки и ISTIO для создания базового развертывания канарейки для новой версии Frontend Service.

Во-первых, мы запустим канарейский трубопровод в регионе Dev1 (US-WEST1) и развернут Frontend V2 на обоих кластерах в этом регионе. Во-вторых, мы запустим канарейский трубопровод в области Dev2 (США-центр) и развернут V2 на обоих кластерах в этом регионе. Запуск трубопровода в регионах по порядку по сравнению с параллелью во всех регионах помогает избежать глобальных отключений, вызванных плохой конфигурацией, или путем ошибок в самом приложении V2.

Примечание . Мы вручную запустили канарейский трубопровод в обоих регионах, но в производстве вы будете использовать автоматический триггер, например, на основе нового тега изображения Docker, выдвинутого в реестр.

1. Из облачной оболочки определите некоторые переменные ENV, чтобы упростить запуск остальных команд.

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

2. Запустите сценарий repo_setup.sh, чтобы скопировать базовые манифесты в K8S-Repo.

$CANARY_DIR/repo-setup.sh 
 

Следующие манифесты скопированы:

• Развертывание Frontend-V2
• Frontend-V1 Patch (чтобы включить этикетку «V1» и изображение с конечной точкой «/версии»)
• Respy , небольшой стручок, который будет напечатать распределение ответов HTTP и поможет нам визуализировать развертывание Канарских островов в режиме реального времени.
• Frontend Istio DestinationRule - разбивает сервис Frontend Kubernetes на два подмножества, V1 и V2, на основе лейбла «Версия» развертывания
• Frontend Istio VirtualService - Маршруты 100% трафика на фронт V1. Это переопределяет услуги Kubernetes Default Default Count Robin поведение, которое немедленно отправило бы 50% всего регионального трафика Dev1 на фронт V2.

3. Сделать изменения в K8S_REPO:

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

4. Посмотреть статус построения Cloud Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

5. Перейдите к Cloud Build в консоли для проекта OPS1. Дождитесь завершения конвейера Cloud Build , а затем получите стручки в пространстве имен Frontend в обоих кластерах Dev1. Вы должны увидеть следующее:

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

Примечание: Ctrl-C для выхода из команд часов

Мы будем использовать Tmux, чтобы разделить наше окно Croudshell на 2 панели:

• Нижняя панель будет запускать команду часов, чтобы наблюдать распределение ответов HTTP для службы Frontend.
• Верхняя панель будет запускать фактический сценарий канарского трубопровода.

6. Запустите команду, чтобы разделить окно Облачной оболочки и выполнить команду Watch на нижней панели.

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"
 

Вывод (не копируйте)

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

Мы видим, что весь трафик идет на развертывание Frontend V1, определенное в новом виртуальном сервисе.

7. Выполните канарейский трубопровод в области DEV1. Мы предоставляем сценарий, который обновляет проценты трафика Frontend-V2 в виртуальном сервисе (обновляя веса до 20%, 50%, 80%, затем 100%). Между обновлениями скрипт ждет завершения конвейера Cloud Build. Запустите сценарий развертывания канарейки для региона Dev1. Примечание - этот сценарий занимает около 10 минут.

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. Например, на отметке 20%:

Вывод (не копируйте)

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

8. Как только развертывание Dev2 завершится для Frontend-V2, вы должны увидеть сообщение о успехе в конце сценария:

    Output (do not copy) 
   

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

9. И весь фронтальный трафик от Pod Dev2 должен идти на Frontend-V2:

    Output (do not copy) 
   

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

10. Закройте расщепленную панель.

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

11. Перейдите к облачным исходным репо с образованной ссылкой.

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

Вы должны увидеть отдельный коммит для каждого процента трафика, с самым последним коммитом в верхней части списка:

Теперь вы повторите тот же процесс для области Dev2. Обратите внимание, что область Dev2 все еще «заблокирована» на V1. Это связано с тем, что в базовом сценарии Repo_setup мы выдвинули виртуальную службу, чтобы явно отправить весь трафик в V1. Таким образом, мы смогли безопасно сделать региональную канарейку на Dev1 и убедиться, что она успешно работает, прежде чем выпустить новую версию во всем мире.

12. Запустите команду, чтобы разделить окно Облачной оболочки и выполнить команду Watch на нижней панели.

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"
 

Вывод (не копируйте)

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

Мы видим, что весь трафик идет на развертывание Frontend V1, определенное в новом виртуальном сервисе.

13. Выполните канарейский трубопровод в области Dev2. Мы предоставляем сценарий, который обновляет проценты трафика Frontend-V2 в виртуальном сервисе (обновляя веса до 20%, 50%, 80%, затем 100%). Между обновлениями скрипт ждет завершения конвейера Cloud Build. Запустите сценарий развертывания канарейки для региона Dev1. Примечание - этот сценарий занимает около 10 минут.

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

Вывод (не копируйте)

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

14. От Respy Pod в Dev2, наблюдая за трафиком от стручков Dev2 постепенно перемещается с фронта V1 на V2. Как только сценарий завершится, вы должны увидеть:

Вывод (не копируйте)

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

15. Закройте расщепленную панель.

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

В этом разделе представилось, как использовать ISTIO для региональных развертываний канарейки. В производстве, вместо ручного сценария, вы можете автоматически запустить этот Canary Script в качестве конвейера облачных сборки, используя триггер, такой как новое тегинговое изображение, выдвинутое в реестр контейнеров. Вы также хотели бы добавить канарейский анализ между каждым шагом, анализируя задержку V2 и частоту ошибок в отношении предопределенного порога безопасности, прежде чем отправлять больше трафика.

11. Политики авторизации

Цель: Настройка RBAC между микросервисами (Authz).

• Создать AuthorizationPolicy , чтобы отказать в доступе к микросервисам
• Создать AuthorizationPolicy , чтобы обеспечить конкретный доступ к микросервисам

Быстрый сценарий

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторию.

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

Скопирование метода лабораторных инструкций

Если вы уже завершили скрипт Fast Track для этой лаборатории, не выполняйте метод копирования и вставки ниже **. **

В отличие от монолитного приложения, которое может работать в одном месте, приложения микросервисов по всему миру делают вызовы по границам сети. Это означает больше очков въезда в ваши приложения и больше возможностей для вредоносных атак. А поскольку капсулы Kubernetes имеют переходные IPS, традиционные правила брандмауэра на основе IP больше не являются адекватными для обеспечения доступа между рабочими нагрузками. В архитектуре микросервисов необходим новый подход к безопасности. Опираясь на здания Kubernetes Security Blocks, такие как сервисные учетные записи , Istio предоставляет гибкий набор политик безопасности для ваших приложений.

Политики ISTIO охватывают как аутентификацию, так и разрешение. Аутентификация проверяет личность (этот сервер, кто они говорят?), А разрешение проверяет разрешения (разрешено ли это клиенту?). Мы рассмотрели аутентификацию ISTIO во взаимном разделе TLS в модуле 1 (Meshpolicy). В этом разделе мы узнаем, как использовать политики авторизации ISTIO для контроля доступа к одной из наших рабочих нагрузок приложений, CurrenceService .

Во -первых, мы разместим авторизацию ProLicy во всех 4 кластерах DEV, закрыв весь доступ к CurrenceService и вызовуте ошибку на фронте. Затем мы позволим только передовой службе получить доступ к CurrenceService.

1. Осмотрите содержимое currency-deny-all.yaml . Yaml. В этой политике используются селекторы метки развертывания для ограничения доступа к CurrenceService. Обратите внимание, как нет поля spec - это означает, что эта политика будет отрицать весь доступ к выбранной службе.

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

Вывод (не копируйте)

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

2. Скопируйте политику валюты в K8S-Repo, для кластеров OPS в обоих регионах.

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. Протолкнуть изменения.

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

4. Проверьте состояние построения облака Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

5. После того, как сборка успешно завершится, попробуйте добраться до фронта Hipstershop в браузере по следующей ссылке:

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

Вы должны увидеть ошибку авторизации от CurrenceService:

6. Давайте рассмотрим, как валютная служба обеспечивает соблюдение этой авторизации. Во-первых, включите журналы на уровне трассировки на прокси-сервере Enguy для одного из валютных стручков, поскольку заблокированные вызовы авторизации не регистрируются по умолчанию.

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. Получите журналы RBAC (авторизация) из прокси -сидовой службы валютной службы. Вы должны увидеть сообщение «принудительное отклонение», указывающее, что CurrenceService установлен для блокировки всех входящих запросов.

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

Вывод (не копируйте)

[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. Теперь давайте позволим Frontend - но не другие сервисные услуги - получить доступ к CurrenceService. Открытая currency-allow-frontend.yaml и осмотрите его содержимое. Обратите внимание, что мы добавили следующее правило:

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

Вывод (не копируйте)

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

Здесь мы ведем белый список конкретного источника. ПРИНКИПАЛЬНЫЙ (Клиент) для доступа к валютной службе. Этот источник. Principal определяется IS IS Kubernetes Service Account. В этом случае учетная запись сервиса, которую мы ведем в белом списке, является учетной записью Frontend Service в пространстве имен Frontend.

ПРИМЕЧАНИЕ. При использовании учетных записей услуг Kubernetes в istio AuthorizationPolicies вы должны сначала включить взаимные TLS в кластере, как мы делали в модуле 1. Это для обеспечения того, чтобы учетные данные об учетной записи были включены в запросы.

9. Скопировать обновленную политику валюты

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. Протолкнуть изменения.

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

11. Посмотреть статус построения Cloud Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

12. После того, как сборка успешно завершится, снова откройте фронт Hipstershop. На этот раз вы не должны видеть ошибок на домашней странице - это потому, что фронта явно разрешено получить доступ к текущей службе.
13. Теперь попробуйте выполнить оформление заказа, добавив элементы в корзину и нажав «Заказ на размещение». На этот раз вы должны увидеть ошибку конверсии цен из валютного сервиса - это потому, что мы только белые списки на фронте, поэтому Checkoutservice по -прежнему не может получить доступ к CurrenceService.

14. Наконец, давайте позволим службу оформления заказа доступ к валюте, добавив другое правило в нашу CurrenceService AuthorizationPolicy. Обратите внимание, что мы открываем только валютный доступ к двум сервисам, которые должны получить к нему доступ - Frontend и Checkout. Другие бэкэнды все еще будут заблокированы.
15. Открытая currency-allow-frontend-checkout.yaml Обратите внимание, что список функций правил как логическая или валюта будет принимать только запросы из рабочих нагрузок с любым из этих двух учетных записей услуг.

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

Вывод (не копируйте)

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. Скопируйте окончательную политику авторизации в K8S-Repo.

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

17. Протолкнуть изменения

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

18. Посмотреть статус построения Cloud Project Project Project в ранее открытой вкладке или нажав следующую ссылку:

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

19. После того, как сборка успешно завершится, попробуйте выполнить оформление заказа - она ​​должна успешно работать.

Этот раздел прошел через то, как использовать политики авторизации ISTIO для обеспечения соблюдения гранулированного контроля доступа на уровне для каждого услуги. В производстве вы можете создать одну авторизацию POLICY PER SERVICE и (например) использовать политику All-All , чтобы все рабочие нагрузки в одном пространстве имен доступны друг другу.

12. Масштаб инфраструктуры

Цель: масштабная инфраструктура путем добавления нового региона, проекта и кластеров.

• Клонировать infrastructure репо
• Обновите файлы Terraform для создания новых ресурсов
• 2 подсети в новом регионе (одна для проекта OPS и одна для нового проекта)
• Новый кластер OPS в новом регионе (в новой подсети)
• Новая плоскость управления ISTIO для нового региона
• 2 кластера приложения в новом проекте в новом регионе
• Посвятить себя infrastructure репо
• Проверка установки

Быстрый сценарий

Если вы выберете этот метод, запустите следующий сценарий, чтобы завершить эту лабораторию.

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

Скопирование метода лабораторных инструкций

Если вы уже завершили скрипт Fast Track для этой лаборатории, не выполняйте метод копирования и вставки ниже **. **

Есть несколько способов масштабировать платформу. Вы можете добавить больше вычислений, добавив узлы в существующие кластеры. Вы можете добавить больше кластеров в регион. Или вы можете добавить больше регионов на платформу. Решение о том, какой аспект платформы масштабируется, зависит от требований. Например, если у вас есть кластеры во всех трех зонах в регионе, возможно, добавить больше узлов (или пулов узлов) к существующему кластеру. Однако, если у вас есть кластеры в двух из трех зон в одной области, то добавление нового кластера в третьей зоне дает вам масштабирование и дополнительный домен ошибки (то есть новая зона). Еще одной причиной добавления нового кластера в регион может быть необходимость создания одного кластера арендаторов - по соображениям регулирования или соблюдения (например, PCI или кластера базы данных, в котором находится информация PII). По мере расширения вашего бизнеса и услуг добавление новых регионов становится неизбежным, чтобы предоставить услуги ближе к клиентам.

Текущая платформа состоит из двух регионов и кластеров в двух зонах на регион. Вы можете думать о масштабировании платформы двумя способами:

• Вертикально - в каждом регионе, добавив больше вычислений. Это делается либо путем добавления большего количества узлов (или пулов узлов) к существующим кластерам, либо путем добавления новых кластеров в регионе. Это делается через репо infrastructure . Самый простой путь - добавление узлов к существующим кластерам. Не требуется дополнительная конфигурация. Adding new clusters may require additional subnets (and secondary ranges), adding appropriate firewall rules, adding the new clusters to the regional ASM/Istio service mesh control plane and deploying application resources to the new clusters.
• Horizontally - by adding more regions. The current platform gives you a regional template. It consists on a regional ops cluster where the ASM/Istio control please resides and two (or more) zonal application clusters where application resources are deployed.

In this workshop, you scale the platform "horizontally" as it encompasses the vertical use case steps as well. In order to horizontally, scale the platform by adding a new region (r3) to the platform, the following resources need to be added:

1. Subnets in the host project shared VPC in region r3 for the new ops and application clusters.
2. A regional ops cluster in region r3 where the ASM/Istio control plane resides.
3. Two zonal application clusters in two zones on region r3.
4. Update to the k8s-repo:
5. Deploy ASM/Istio control plane resources to the ops cluster in region r3.
6. Deploy ASM/Istio shared control plane resources to the app clusters in region r3.
7. While you don't need to create a new project, the steps in the workshop demonstrate adding a new project dev3 to cover the use case of adding a new team to the platform.

Infrastructure repo is used to add new resources stated above.

1. In Cloud Shell, navigate to WORKDIR and clone the infrastructure repo.

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

2. Clone the workshop source repo add-proj branch into the add-proj-repo directory.

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

 

3. Copy files from the add-proj branch in the source workshop repo. The add-proj branch contains the changes for this section.

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

4. Replace the infrastructure directory in the add-proj repo directory with a symlink to the infra-repo directory to allow the scripts on the branch to run.

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

5. Run the add-project.sh script to copy the shared states and vars to the new project directory structure.

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

6. Commit and push changes to create new project

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

7. The commit triggers the infrastructure repo to deploy the infrastructure with the new resources. View the Cloud Build progress by clicking on the output of the following link and navigating to the latest build at the top.

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

This step takes 25 - 30 minutes to complete. Good time for a coffee break.

The last step of the infrastructure Cloud Build creates new Kubernetes resources in the k8s-repo . This triggers the Cloud Build in the k8s-repo (in the ops project). The new Kubernetes resources are for the three new clusters added in the previous step. ASM/Istio control plane and shared control plane resources are added to the new clusters with the k8s-repo Cloud Build.

8. After the infrastructure Cloud Build successfully finishes, navigate to the k8s-repo latest Cloud Build run by clicking on the following output link.

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

9. Run the following script to add the new clusters to the vars and kubeconfig file.

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

10. Change the KUBECONFIG variable to point to the new kubeconfig file.

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

11. List your cluster contexts. You should see eight clusters.

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

Verify Istio Installation

12. Ensure Istio is installed on the new ops cluster by checking all pods are running and jobs have completed.

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. Ensure Istio is installed on both dev3 clusters. Only Citadel, sidecar-injector and coredns run in the dev3 clusters. They share an Istio controlplane running in the ops-3 cluster.

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

Verify service discovery for shared control planes

14. Verify the secrets are deployed in all ops clusters for all six application clusters.

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

Objective: Implement a Circuit Breaker for the shipping Service.

• Create a DestinationRule for the shipping Service to implement a circuit breaker
• Use fortio (a load gen utility) to validate circuit breaker for the shipping Service by force tripping the circuit

Fast Track Script Lab Instructions

Fast Track Script Lab is coming soon!!

Copy-and-Paste Method Lab Instructions

Now that we've learned some basic monitoring and troubleshooting strategies for Istio-enabled services, let's look at how Istio helps you improve the resilience of your services, reducing the amount of troubleshooting you'll have to do in the first place.

A microservices architecture introduces the risk of cascading failures , where the failure of one service can propagate to its dependencies, and the dependencies of those dependencies, causing a "ripple effect" outage that can potentially affect end-users. Istio provides a Circuit Breaker traffic policy to help you isolate services, protecting downstream (client-side) services from waiting on failing services, and protecting upstream (server-side) services from a sudden flood of downstream traffic when they do come back online. Overall, using Circuit Breakers can help you avoid all your services failing their SLOs because of one backend service that is hanging.

The Circuit Breaker pattern is named for an electrical switch that can "trip" when too much electricity flows through, protecting devices from overload. In an Istio setup , this means that Envoy is the circuit breaker, keeping track of the number of pending requests for a service. In this default closed state, requests flow through Envoy uninterrupted.

But when the number of pending requests exceeds your defined threshold, the circuit breaker trips (opens), and Envoy immediately returns an error. This allows the server to fail fast for the client, and prevents the server application code from receiving the client's request when overloaded.

Then, after your defined timeout, Envoy moves to a half open state, where the server can start receiving requests again in a probationary way, and if it can successfully respond to requests, the circuit breaker closes again, and requests to the server begin to flow again.

This diagram summarizes the Istio circuit breaker pattern. The blue rectangles represent Envoy, the blue-filled circle represents the client, and the white-filled circles represent the server container:

You can define Circuit Breaker policies using Istio DestinationRules. In this section, we'll apply the following policy to enforce a circuit breaker for the shipping service:

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

There are two DestinationRule fields to note here. connectionPool defines the number of connections this service will allow. The outlierDetection field is where we configure how Envoy will determine the threshold at which to open the circuit breaker. Here, every second (interval), Envoy will count the number of errors it received from the server container. If it exceeds the consecutiveErrors threshold, the Envoy circuit breaker will open, and 100% of productcatalog pods will be shielded from new client requests for 10 seconds. Once the Envoy circuit breaker is open (ie. active), clients will receive 503 (Service Unavailable) errors. Let's see this in action.

1. Set environment variables for the k8s-repo and asm dir to simplify commands.

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

2. Update the k8s-repo

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

3. Update the shipping service DestinationRule on both Ops clusters.

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. Copy a Fortio load generator pod into the GKE_1 cluster in the Dev1 region. This is the client pod we'll use to "trip" the circuit breaker for shippingservice.

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

5. Commit changes.

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

6. Wait for Cloud Build to complete.
7. Back in Cloud Shell, use the fortio pod to send gRPC traffic to shippingservice with 1 concurrent connection, 1000 requests total - this will not trip the circuit breaker, because we have not exceeded the connectionPool settings yet.

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

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

Output (do not copy)

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

8. Now run fortio again, increasing the number of concurrent connections to 2, but keeping the total number of requests constant. We should see up to two-thirds of the requests return an "overflow" error, because the circuit breaker has been tripped: in the policy we defined, only 1 concurrent connection is allowed in a 1-second interval.

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

Output (do not copy)

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 keeps track of the number of connections it dropped when the circuit breaker is active, with the upstream_rq_pending_overflow metric. Let's find this in the fortio pod:

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

Output (do not copy)

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. Clean up by removing the circuit breaker policy from both regions.

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
 

This section demonstrated how to set up a single circuit breaker policy for a service. A best practice is to set up a circuit breaker for any upstream (backend) service that has the potential to hang. By applying Istio circuit breaker policies, you help isolate your microservices, build fault tolerance into your architecture, and reduce the risk of cascading failures under high load.

14. Fault Injection

Objective: Test the resilience of the recommendation Service by introducing delays (before it is pushed to production).

• Create a VirtualService for the recommendation Service to introduce a 5s delay
• Test the delay using fortio load generator
• Remove the delay in the VirtualService and validate

Fast Track Script Lab Instructions

Fast Track Script Lab is coming soon!!

Copy-and-Paste Method Lab Instructions

Adding circuit breaker policies to your services is one way to build resilience against services in production. But circuit breaking results in faults — potentially user-facing errors — which is not ideal. To get ahead of these error cases, and better predict how your downstream services might respond when backends do return errors, you can adopt chaos testing in a staging environment. Chaos testing is the practice of deliberately breaking your services, in order to analyze weak points in the system and improve fault tolerance. You can also use chaos testing to identify ways to mitigate user-facing errors when backends fail - for instance, by displaying a cached result in a frontend.

Using Istio for fault injection is helpful because you can use your production release images, and add the fault at the network layer, instead of modifying source code. In production, you might use a full-fledged chaos testing tool to test resilience at the Kubernetes/compute layer in addition to the network layer.

You can use Istio for chaos testing by applying a VirtualService with the "fault" field. Istio supports two kinds of faults: delay faults (inject a timeout) and abort faults (inject HTTP errors). In this example, we'll inject a 5-second delay fault into the recommendations service . But this time instead of using a circuit breaker to "fail fast" against this hanging service, we will force downstream services to endure the full timeout.

11. Navigate into the fault injection directory.

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

12. Open k8s_manifests/prod/istio-networking/app-recommendation-vs-fault.yaml to inspect its contents. Notice that Istio has an option to inject the fault into a percentage of the requests - here, we'll introduce a timeout into all recommendationservice requests.

Output (do not copy)

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. Copy the VirtualService into k8s_repo. We'll inject the fault globally, across both regions.

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

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

15. Wait for Cloud Build to complete.
16. Exec into the fortio pod deployed in the circuit breaker section, and send some traffic to recommendationservice.

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

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

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

Output (do not copy)

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. Another way to see the fault we injected in action is open the frontend in a web browser, and click on any product. A product page should take 5 extra seconds to load, since it fetches the recommendations that are displayed at the bottom of the page.
18. Clean up by removing the fault injection service from both Ops clusters.

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. Push changes:

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

15. Monitoring the Istio Control Plane

ASM installs four important control plane components: Pilot, Mixer, Galley and Citadel. Each sends its relevant monitoring metrics to Prometheus, and ASM ships with Grafana dashboards that let operators visualize this monitoring data and assess the health and performance of the control plane.

Просмотр информационных панелей

20. Port-forward your Grafana service installed with Istio

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

21. Open Grafana in your browser
22. Click on the "Web Preview" icon on the top right corner of your Cloud Shell Window
23. Click Preview on port 3000 (Note: if the port is not 3000, click on change port and select port 3000)
24. This will open a tab in your browser with a URL similar to " BASE_URL/?orgId=1&authuser=0&environment_id=default "
25. View available dashboards
26. Modify the URL to " BASE_URL/dashboard "
27. Click on "istio" folder to view available dashboards
28. Click on any of those dashboards to view the performance of that component. We'll look at the important metrics for each component in the following sections.

Monitoring Pilot

Pilot is the control plane component that distributes networking and policy configuration to the data plane (the Envoy proxies). Pilot tends to scale with the number of workloads and deployments, although not necessarily with the amount of traffic to those workloads. An unhealthy Pilot can:

• consume more resources than necessary (CPU and/or RAM)
• result in delays in pushing updated configuration information to Envoys

Note: if Pilot is down, or if there are delays, your workloads still serve traffic.

23. Navigate to " BASE_URL/dashboard/db/istio-pilot-dashboard " in your browser to view Pilot metrics.

Important monitored metrics

Resource Usage

Use the Istio Performance and Scalability page as your guide for acceptable usage numbers. Contact GCP support if you see significantly more sustained resource usage than this.

Pilot Push Information

This section monitors Pilots pushes of configuration to your Envoy proxies.

• Pilot Pushes shows the type of configuration pushed at any given time.
• ADS Monitoring shows the number of Virtual Services, Services and Connected Endpoints in the system.
• Clusters with no known endpoints shows endpoints that have been configured but do not have any instances running (which may indicate external services, such as *.googleapis.com).
• Pilot Errors show the number of errors encountered over time.
• Conflicts show the number of conflicts which are ambiguous configuration on listeners.

If you have Errors or Conflicts, you have bad or inconsistent configuration for one or more of your services. See Troubleshooting the data plane for information.

Envoy Information

This section contains information about the Envoy proxies contacting the control plane. Contact GCP support if you see repeated XDS Connection Failures.

Monitoring Mixer

Mixer is the component that funnels telemetry from the Envoy proxies to telemetry backends (typically Prometheus, Stackdriver, etc). In this capacity, it is not in the data plane. It is deployed as two Kubernetes Jobs (called Mixer) deployed with two different service names (istio-telemetry and istio-policy).

Mixer can also be used to integrate with policy systems. In this capacity, Mixer does affect the data plane, as policy checks to Mixer that fail block access to your services.

Mixer tends to scale with volume of traffic.

24. Navigate to " BASE_URL/dashboard/db/istio-mixer-dashboard " in your browser to view Mixer metrics.

Important monitored metrics

Resource Usage

Use the Istio Performance and Scalability page as your guide for acceptable usage numbers. Contact GCP support if you see significantly more sustained resource usage than this.

Mixer Overview

• Response Duration is an important metric. While reports to Mixer telemetry are not in the datapath, if these latencies are high it will definitely slow down sidecar proxy performance. You should expect the 90th percentile to be in the single-digit milliseconds, and the 99th percentile to be under 100ms.

• Adapter Dispatch Duration indicates the latency Mixer is experiencing in calling adapters (through which it sends information to telemetry and logging systems). High latencies here will absolutely affect performance on the mesh. Again, p90 latencies should be under 10ms.

Monitoring Galley

Galley is Istio's configuration validation, ingestion, processing and distribution component. It conveys configuration from the Kubernetes API server to Pilot. Like Pilot, it tends to scale with the number of services and endpoints in the system.

25. Navigate to " BASE_URL/dashboard/db/istio-galley-dashboard " in your browser to view Galley metrics.

Important monitored metrics

Resource Validation

The most important metric to follow which indicates the number of resources of various types like Destination rules, Gateways and Service entries that are passing or failing validation.

Connected clients

Indicates how many clients are connected to Galley; typically this will be 3 (pilot, istio-telemetry, istio-policy) and will scale as those components scale.

16. Troubleshooting Istio

Troubleshooting the data plane

If your Pilot dashboard indicates that you have configuration issues, you should examine PIlot logs or use istioctl to find configuration problems.

To examine Pilot logs, run kubectl -n istio-system logs istio-pilot-69db46c598-45m44 discovery, replacing istio-pilot-... with the pod identifier for the Pilot instance you want to troubleshoot.

In the resulting log, search for a Push Status message. Например:

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

The Push Status will indicate any issues that occurred when trying to push the configuration to Envoy proxies – in this case, we see several "Duplicate cluster" messages, which indicate duplicate upstream destinations.

For assistance in diagnosing problems, contact Google Cloud support with issues.

Finding configuration errors

In order to use istioctl to analyze your configuration, run istioctl experimental analyze -k --context $OPS_GKE_1 . This will perform an analysis of configuration in your system, indicate any problems along with any suggested changes. See documentation for a full list of configuration errors that this command can detect.

17. Cleanup

The following steps are performed by an administrator after the workshop is completed.

An administrator runs the cleanup_workshop.sh script to delete resources created by the bootstrap_workshop.sh script. You need the following pieces of information for the cleanup script to run.

• Organization name - for example yourcompany.com
• Workshop ID - in the form YYMMDD-NN for example 200131-01
• Admin GCS bucket - defined in the bootstrap script.

13. Open Cloud Shell, perform all actions below in Cloud Shell. Нажмите на ссылку ниже.

ОБЛАЧНАЯ ОБОЛОЧКА

14. Verify you are logged into gcloud with the intended Admin user.

gcloud config list
 

15. Navigate you the asm folder.

cd ${WORKDIR}/asm
 

16. Define your Organization name and workshop ID to be deleted.

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

17. Run the cleanup script as follows.

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