Внешний HTTPs LB с расширенным управлением трафиком (Envoy) Codelab

1. Введение

Добро пожаловать в раздел «Внешний HTTPs LB» с расширенным управлением трафиком (Envoy) Codelab!

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

Что вы узнаете

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

Что вам понадобится

  • Базовые настройки сети и знание HTTP
  • Базовые знания командной строки Unix/Linux.

Топология и вариант использования Codelab

bfc43fd0ca39047a.png

Рис. 1. Топология маршрутизации HTTP Load Balancer

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

2. Настройка и требования

Самостоятельная настройка среды

  1. Войдите в Google Cloud Console и создайте новый проект или повторно используйте существующий. Если у вас еще нет учетной записи Gmail или Google Workspace, вам необходимо ее создать .

96a9c957bc475304.png

b9a10ebdf5b5a448.png

a1e3c01a38fa61c2.png

  • Имя проекта — это отображаемое имя для участников этого проекта. Это строка символов, не используемая API Google, и вы можете обновить ее в любое время.
  • Идентификатор проекта должен быть уникальным для всех проектов Google Cloud и неизменяемым (нельзя изменить после его установки). Cloud Console автоматически генерирует уникальную строку; обычно тебя не волнует, что это такое. В большинстве лабораторий кода вам потребуется указать идентификатор проекта (обычно он обозначается как PROJECT_ID ), поэтому, если он вам не нравится, создайте другой случайный идентификатор или попробуйте свой собственный и посмотрите, доступен ли он. Затем он «замораживается» после создания проекта.
  • Существует третье значение — номер проекта , который используют некоторые API. Подробнее обо всех трех этих значениях читайте в документации .
  1. Затем вам необходимо включить выставление счетов в Cloud Console, чтобы использовать облачные ресурсы/API. Прохождение этой лаборатории кода не должно стоить много, если вообще стоит. Чтобы отключить ресурсы и не платить за выставление счетов за пределами этого руководства, следуйте инструкциям по «очистке», которые можно найти в конце лаборатории кода. Новые пользователи Google Cloud имеют право на участие в программе бесплатной пробной версии стоимостью 300 долларов США .

Запустить Cloud Shell

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

В консоли GCP щелкните значок Cloud Shell на верхней правой панели инструментов:

bce75f34b2c53987.png

Подготовка и подключение к среде займет всего несколько минут. Когда все будет готово, вы должны увидеть что-то вроде этого:

f6ef2b5f13479f3a.png

Эта виртуальная машина оснащена всеми необходимыми инструментами разработки. Он предлагает постоянный домашний каталог объемом 5 ГБ и работает в Google Cloud, что значительно повышает производительность сети и аутентификацию. Всю работу в этой лабораторной работе можно выполнять с помощью простого браузера.

Прежде чем вы начнете

В Cloud Shell убедитесь, что идентификатор вашего проекта настроен.

проект списка конфигурации gcloud

проект набора конфигурации gcloud [ВАШЕ-ИМЯ-ПРОЕКТА]

PROJECT_ID=[ИМЯ-ВАШЕГО-ПРОЕКТА]

эхо $PROJECT_ID

Включить API

Включите все необходимые службы

gcloud services enable compute.googleapis.com
gcloud services enable logging.googleapis.com
gcloud services enable monitoring.googleapis.com

3. Создайте сеть VPC.

Создать сеть VPC

Из Cloud Shell

gcloud compute networks create httplbs --subnet-mode=auto

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks/httplbs].
NAME: httplbs
SUBNET_MODE: AUTO
BGP_ROUTING_MODE: REGIONAL
IPV4_RANGE:
GATEWAY_IPV4:

Создание правил брандмауэра VPC

После создания VPC вы создадите правила брандмауэра. Правило брандмауэра будет использоваться, чтобы разрешить всем IP-адресам доступ к внешнему IP-адресу веб-сайта тестового приложения через порт 80 для HTTP-трафика.

Из Cloud Shell

gcloud compute firewall-rules create httplb-allow-http-rule \
--allow tcp:80 \
--network httplbs \
--source-ranges 0.0.0.0/0 \
--priority 700

Выход

Creating firewall...working..Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls/httplb-allow-http-rule].
Creating firewall...done.
NAME: httplb-allow-http-rule
NETWORK: httplbs
DIRECTION: INGRESS
PRIORITY: 700
ALLOW: tcp:80
DENY:
DISABLED: False

4. Настройте группы управляемых экземпляров.

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

Группы управляемых экземпляров могут быть зональными или региональными по объему. Для этого лабораторного упражнения мы создадим три региональные группы управляемых экземпляров: одну в us-east1, одну в us-west1 и одну в us-central1.

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

Создайте шаблоны экземпляров East, West и Central.

Первым шагом является создание шаблона экземпляра us-east-1.

Из Cloud Shell

gcloud compute instance-templates create us-east1-template \
   --region=us-east1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-east1-template].
NAME: us-east1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:02:37.511-08:00

Следующим шагом будет создание шаблона экземпляра us-west-1.

Из Cloud Shell

gcloud compute instance-templates create us-west1-template \
   --region=us-west1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-west1-template].
NAME: us-west1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:08.577-08:00

Следующим шагом будет создание шаблона экземпляра us-central-1.

Из Cloud Shell

gcloud compute instance-templates create us-central1-template \
   --region=us-central1 \
   --network=httplbs \
   --tags=http-server, \
   --image-family=debian-9 \
   --image-project=debian-cloud \
   --metadata=startup-script='#! /bin/bash
     apt-get update
     apt-get install apache2 -y
     a2ensite default-ssl
     a2enmod ssl
     vm_hostname="$(curl -H "Metadata-Flavor:Google" \
     http://169.254.169.254/computeMetadata/v1/instance/name)"
     echo "Page served from: $vm_hostname" | \
     tee /var/www/html/index.html
     systemctl restart apache2'

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates/us-central1-template].
NAME: us-central1-template
MACHINE_TYPE: n1-standard-1
PREEMPTIBLE:
CREATION_TIMESTAMP: 2021-11-11T11:03:44.179-08:00

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

Из Cloud Shell

gcloud compute instance-templates list

Выход

NAME                  MACHINE_TYPE   PREEMPTIBLE  CREATION_TIMESTAMP
us-central1-template   n1-standard-1         2021-11-09T09:25:37.263-08:00
us-east1-template      n1-standard-1         2021-11-09T09:24:35.275-08:00
us-west1-template      n1-standard-1         2021-11-09T09:25:08.016-08:00

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

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

Из Cloud Shell

gcloud compute instance-groups managed create us-east1-mig \
--base-instance-name=us-east1-mig \
--size=1 \
--template=us-east1-template \
--zone=us-east1-b 

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-east1-b/instanceGroupManagers/us-east1-mig].
NAME: us-east1-mig
LOCATION: us-east1-b
SCOPE: zone
BASE_INSTANCE_NAME: us-east1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-east1-template
AUTOSCALED: no

Из Cloud Shell

gcloud compute instance-groups managed create us-west1-mig \
--base-instance-name=us-west1-mig \
--size=1 \
--template=us-west1-template \
--zone=us-west1-a  

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-west1-a/instanceGroupManagers/us-west1-mig].
NAME: us-west1-mig
LOCATION: us-west1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-west1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-west1-template
AUTOSCALED: no

Из Cloud Shell

gcloud compute instance-groups managed create us-central1-mig \
--base-instance-name=us-central1-mig \
--size=1 \
--template=us-central1-template \
--zone=us-central1-a 

Выход

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/us-central1-a/instanceGroupManagers/us-central1-mig].
NAME: us-central1-mig
LOCATION: us-central1-a
SCOPE: zone
BASE_INSTANCE_NAME: us-central1-mig
SIZE: 0
TARGET_SIZE: 1
INSTANCE_TEMPLATE: us-central1-template
AUTOSCALED: no

Мы можем убедиться, что наши группы экземпляров были успешно созданы с помощью следующей команды gcloud:

Из Cloud Shell

gcloud compute instance-groups list

Выход

NAME                  LOCATION      SCOPE   NETWORK         MANAGED INSTANCES
us-central1-mig       us-central1   zone    httplbs          Yes      1
us-west1-mig          us-west1      zone    httplbs          Yes      1
us-east1-mig          us-east1      zone    httplbs          Yes      1

Проверка функциональности веб-сервера

Каждый экземпляр настроен для запуска веб-сервера Apache с простым PHP-скриптом, который отображает:

a6ab2f8c3b5d5680.png

Чтобы убедиться, что ваши веб-серверы работают правильно, перейдите в раздел Compute Engine -> Экземпляры виртуальных машин. Убедитесь, что ваши новые экземпляры (например, us-east1-mig-xxx) созданы в соответствии с определениями групп экземпляров.

Теперь сделайте к нему веб-запрос в браузере, чтобы убедиться, что веб-сервер работает (запуск может занять минуту). На странице экземпляров виртуальных машин в разделе Compute Engine выберите экземпляр, созданный вашей группой экземпляров, и щелкните его внешний (общедоступный) IP-адрес.

Или в браузере перейдите по адресу http://<IP_Address>.

5. Настройте балансировщик нагрузки.

Создать проверку работоспособности

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

Из Cloud Shell

gcloud compute health-checks create http http-basic-check \
    --port 80

Зарезервировать внешний IP-адрес

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

Из Cloud Shell

gcloud compute addresses create lb-ipv4-2 \
    --ip-version=IPV4 \
    --global

Обязательно запишите зарезервированный IP-адрес.

gcloud compute addresses describe lb-ipv4-2 \
    --format="get(address)" \
    --global

Создать серверные службы

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

Создание серверной службы для группы управляемых экземпляров East.

Из Cloud Shell

gcloud beta compute backend-services create east-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Создание серверной службы для группы управляемых экземпляров West.

Из Cloud Shell

gcloud beta compute backend-services create west-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

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

Из Cloud Shell

gcloud beta compute backend-services create central-backend-service \
    --load-balancing-scheme=EXTERNAL_MANAGED \
    --protocol=HTTP \
    --port-name=http \
    --health-checks=http-basic-check \
    --global

Добавьте MIG в серверные службы

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

Добавьте East MIG в серверную службу.

Из Cloud Shell

gcloud beta compute backend-services add-backend east-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-east1-mig \
    --instance-group-zone=us-east1-b \
    --global

Добавьте West MIG в серверную службу.

Из Cloud Shell

gcloud beta compute backend-services add-backend west-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-west1-mig \
    --instance-group-zone=us-west1-a \
    --global

Добавьте West MIG в серверную службу.

Из Cloud Shell

gcloud beta compute backend-services add-backend central-backend-service \
    --balancing-mode='UTILIZATION' \
    --instance-group=us-central1-mig \
    --instance-group-zone=us-central1-a \
    --global

Создать карту URL-адресов

Карта URL-адресов — это место, где будут размещены расширенные функции управления трафиком для этой лабораторной работы. Мы должны создать файл .yaml, который будет содержать конфигурацию. В файле .yaml мы создали соответствие префикса для /roundrobbin, поэтому эти конфигурации будут влиять только на трафик, соответствующий /roundrobbin. Мы указали, что 50% трафика должно идти на восточную серверную службу, а 50% трафика должно идти на западную серверную службу. Мы дополнительно добавили значение заголовка ответа: {test}, которое будет присутствовать во всех ответах. Наконец, мы добавили, что весь трафик должен зеркалироваться в центральную серверную службу. Трафик дублируется и отправляется сюда только в целях тестирования.

Сохраните пример как файл .yaml на своем компьютере.

defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
kind: compute #urlMap
name: web-map-http
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
  name: matcher1
  routeRules:
  - matchRules:
    - prefixMatch: /roundrobbin
    priority: 2
    headerAction:
        responseHeadersToAdd:
          - headerName: test
            headerValue: value
            replace: True
    routeAction:
        weightedBackendServices:
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/east-backend-service
          weight: 50
        - backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/west-backend-service
          weight: 50
        retryPolicy:
            retryConditions: ['502', '504']
            numRetries: 3
            perTryTimeout:
                seconds: 1
                nanos: 50
        requestMirrorPolicy:
          backendService: https://www.googleapis.com/compute/v1/projects/[project_id]/global/backendServices/central-backend-service

Создайте карту URL-адресов, импортировав документ с вашего компьютера. Обратите внимание, что исходный путь будет отличаться в зависимости от того, где вы сохраняете файл .yaml.

Из Cloud Shell

gcloud beta compute url-maps import web-map-http \
   --source /Users/[USERNAME]/Documents/Codelab/lbconfig.yaml \
   --global

Создать HTTP-интерфейс

Последним шагом в создании балансировщика нагрузки является создание внешнего интерфейса. Это сопоставит зарезервированный ранее IP-адрес с созданной вами картой URL-адресов балансировщика нагрузки.

Из Cloud Shell

gcloud beta compute target-http-proxies create http-lb-proxy-adv \
    --url-map=web-map-http

Далее вам необходимо создать глобальное правило переадресации, которое будет сопоставлять зарезервированный ранее IP-адрес с HTTP-прокси.

Из Cloud Shell

gcloud beta compute forwarding-rules create http-content-rule \
    --load-balancing-scheme EXTERNAL_MANAGED \
    --address=lb-ipv4-2 \
    --global \
    --target-http-proxy=http-lb-proxy-adv \
    --ports=80

6. Убедитесь, что расширенные функции трафика работают.

Чтобы убедиться, что реализованная функция разделения трафика работает, вам необходимо сгенерировать некоторую нагрузку. Для этого мы создадим новую виртуальную машину для имитации нагрузки.

Создать правило брандмауэра «Разрешить SSH»

Чтобы подключиться по SSH к виртуальной машине, от которой мы будем генерировать трафик, сначала необходимо создать правило брандмауэра, которое разрешит трафик SSH к виртуальной машине.

Из Cloud Shell

gcloud compute firewall-rules create fw-allow-ssh \
    --network=httplbs \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

Выход

NAME          NETWORK  DIRECTION  PRIORITY  ALLOW   DENY  DISABLED
fw-allow-ssh  httplbs  INGRESS    1000      tcp:22        False

Создать Siege-VM

Теперь вы создадите siege-vm, который будете использовать для генерации нагрузки.

Из Cloud Shell

gcloud compute instances create siege-vm \
    --network=httplbs \
    --zone=us-east4-c \
    --machine-type=e2-medium \
    --tags=allow-ssh,http-server \
    --metadata=startup-script='sudo apt-get -y install siege'

Выход

NAME     ZONE        MACHINE_TYPE INTERNAL_IP  EXTERNAL_IP    STATUS
siege-vm us-east4-c  e2-medium    10.150.0.3   34.85.218.119  RUNNING

Затем вы можете подключиться по SSH к созданной вами виртуальной машине. После создания нажмите SSH, чтобы запустить терминал и подключиться.

После подключения выполните следующую команду для генерации нагрузки. Используйте IP-адрес, который вы зарезервировали ранее для внешнего балансировщика нагрузки HTTP.

Из Cloud Shell

siege -c 250 http://$lb-ipv4-2/roundrobbin

Выход

New configuration template added to /home/cloudcurriculumdeveloper/.siege
Run siege -C to view the current settings in that file
[alert] Zip encoding disabled; siege requires zlib support to enable it: No such file or directory
** SIEGE 4.0.2
** Preparing 250 concurrent users for battle.
The server is now under siege...

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

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

В облачной консоли в меню «Навигация» выберите «Сетевые службы» > «Балансировка нагрузки». Нажмите «Бэкэнды». Нажмите расширенное меню, как показано на скриншоте ниже.

b40b0a9f0373f907.png

Перейдите на вкладку Backend-службы и выберите East-Backend-Service.

6972d9d311ed2b5c.png

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

b1301b304c461069.png

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

1674c04b73ea2e00.png

Чтобы убедиться, что созданная вами политика зеркалирования трафика работает, вам необходимо проверить использование группы управляемых экземпляров Central-Backend-Service. Для этого перейдите к «Вычислить», «Вычислительный механизм», «Группы экземпляров» и выберите файл us-central1-mig. Далее перейдите на вкладку мониторинга.

4cf569efb3ba3c2b.png

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

Остановить осаду

Теперь, когда вы продемонстрировали, что расширенное разделение трафика работает, пришло время прекратить осаду. Для этого вернитесь к SSH-терминалу siege-vm и нажмите CTRL+C, чтобы остановить выполнение осады.

Проверка отправляемого заголовка ответа

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

Из Cloud Shell

curl -svo /dev/null http://lb-ipv4-2/roundrobbin

Выход

*   Trying lb-ipv4-2..
* TCP_NODELAY set
* Connected to  lb-ipv4-2 ( lb-ipv4-2) port 80 (#0)
> GET /roundrobbin HTTP/1.1
> Host:  lb-ipv4-2
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 404 Not Found
< date: Wed, 10 Nov 2021 17:05:27 GMT
< server: envoy
< Content-Length: 273
< content-type: text/html; charset=iso-8859-1
< via: 1.1 google
< test: value
<
{ [273 bytes data]
* Connection #0 to host 34.149.2.26 left intact
* Closing connection 0

7. Уборка лаборатории

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

Из Cloud Shell

gcloud compute instances delete siege-vm

gcloud alpha compute forwarding-rules delete http-content-rule --global
gcloud alpha compute target-http-proxies delete http-lb-proxy-adv
gcloud alpha compute url-maps delete web-map-http
gcloud alpha compute backend-services delete east-backend-service --global
gcloud alpha compute backend-services delete west-backend-service --global
gcloud alpha compute backend-services delete central-backend-service --global

gcloud compute addresses delete lb-ipv4-2 --global
gcloud compute health-checks delete http-basic-check 

gcloud compute instance-groups managed delete us-east1-mig --zone us-east1-b
gcloud compute instance-groups managed delete us-west1-mig --zone us-west1-a
gcloud compute instance-groups managed delete us-central1-mig --zone us-central1-a

gcloud compute instance-templates delete "us-east1-template" 
gcloud compute instance-templates delete "us-west1-template" 
gcloud compute instance-templates delete "us-central1-template" 

gcloud compute firewall-rules delete httplb-allow-http-rule
gcloud compute firewall-rules delete fw-allow-ssh

gcloud compute networks delete httplbs 

8. Поздравляем!

Вы завершили изучение внешнего HTTPs LB с помощью Codelab Advanced Traffic Management (Envoy)!

Что мы рассмотрели

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

Следующие шаги

  • Попробуйте некоторые другие расширенные функции маршрутизации, такие как перезапись URL-адресов, добавление заголовков CORS и многое другое ( ссылка ).