1. Обзор
Переписывание или перепроектирование существующих приложений для работы в Kubernetes не всегда возможно или целесообразно делать вручную. Migrate for Anthos может помочь модернизировать ваши существующие приложения и запустить их в Kubernetes. В этом практическом занятии вы перенесете существующее веб-приложение, размещенное на Compute Engine, в Kubernetes Engine с помощью Migrate for Anthos.
Что вы узнаете
- Как развернуть Migrate for Anthos в кластере Kubernetes
- Как создать контейнер в stateful-set из существующего экземпляра Compute Engine
- Как развернуть контейнер в Kubernetes и настроить его с помощью балансировщика нагрузки.
Что вам понадобится
- Проект Google Cloud с настроенной системой оплаты. Если у вас его нет, вам придётся его создать .
2. Настройка
Данный практический урок можно полностью выполнить на платформе Google Cloud Platform без какой-либо локальной установки или настройки.
Включить API
Перед началом работы убедитесь, что необходимые API включены в вашем проекте Google Cloud:
Создание вычислительного экземпляра веб-сервера
Давайте создадим вычислительный экземпляр, который будем использовать для размещения нашего первоначального веб-сервера nginx, а также правила брандмауэра, которые позволят нам просматривать главную страницу веб-сервера по умолчанию. Есть несколько способов это сделать, но для удобства мы воспользуемся Cloud Shell .
В оболочке Cloud Shell выполните следующие действия:
gcloud compute instances create webserver --zone=us-central1-a && \ gcloud compute firewall-rules create default-allow-http --allow=tcp:80
Первая часть этой команды создаст экземпляр Google Cloud в зоне us-central1-a, а вторая часть создаст правило брандмауэра с именем 'default-allow-http', которое разрешит HTTP-трафик в нашей сети.
После успешного создания экземпляра отобразится таблица с его подробными сведениями. Запишите внешний IP-адрес — он понадобится нам позже для проверки работоспособности веб-сервера.
После запуска и настройки экземпляра мы можем подключиться к нему по SSH из Cloud Shell, чтобы установить nginx и запустить веб-сервер:
gcloud compute ssh --zone us-central1-a webserver
После входа в систему на нашем вычислительном сервере установите nginx:
sudo apt install nginx
Выход из SSH-сессии с помощью команды logout
Давайте убедимся, что наш веб-сервер запущен, введя в браузер внешний IP-адрес экземпляра, который вы видели ранее. Вы должны увидеть стандартный экран приветствия Nginx:
Этот веб-сервер будет использоваться в качестве устаревшего веб-приложения, которое мы перенесем в Kubernetes с помощью Migrate for Anthos.
3. Кластер Kubernetes с Migrate для Anthos
Далее мы создадим кластер GKE, куда в конечном итоге перенесём веб-сервер Compute Engine. В консоли Cloud выполните следующие действия:
gcloud container clusters create my-gke-cluster \ --zone us-central1-a \ --cluster-version 1.13 \ --machine-type n1-standard-4 \ --image-type "UBUNTU" \ --num-nodes 1 \ --enable-stackdriver-kubernetes
Подождите несколько минут, пока команда выполнится. После создания кластера вы получите подробный вывод:
Далее перейдите на GCP Marketplace, чтобы выполнить развертывание и миграцию для Anthos:
На странице Marketplace для Migrate for Anthos нажмите «Настроить» и, если потребуется, выберите свой проект из списка. На следующей странице отобразится форма с некоторыми значениями по умолчанию. Убедитесь, что выбран именно тот кластер, который мы только что создали, и нажмите «Развернуть» .
Теперь Migrate for Anthos должен быть развернут в нашем кластере Kubernetes. После завершения развертывания на странице приложений Kubernetes Engine вы увидите статус «OK»:
4. От вычислительного экземпляра к набору состояний.
У нас запущен кластер Kubernetes с использованием Migrate for Anthos, поэтому теперь мы можем начать процесс миграции. Чтобы развернуть наш вычислительный экземпляр в кластере Kubernetes, мы остановим наш экземпляр Compute Engine, чтобы иметь возможность сделать снимки дисков. Прежде чем продолжить, запишите идентификатор экземпляра , который нам понадобится позже:
gcloud compute instances describe webserver --zone us-central1-a | grep ^id
Давайте выключим наш вычислительный экземпляр:
gcloud compute instances stop webserver --zone us-central1-a
Теперь, когда экземпляр остановлен, мы можем безопасно создать снимок дисков, запустив следующий скрипт. Обязательно укажите идентификатор вашего проекта и идентификатор вашего экземпляра :
python3 /google/migrate/anthos/gce-to-gke/clone_vm_disks.py \ -p <project-id> -i <instance-id> \ -z us-central1-a \ -T us-central1-a \ -A webserver-statefulset \ -o containerized-webserver.yaml
При наличии этих флагов скрипт clone_vm_disks.py выполнит следующие действия:
- Убедитесь, что ваш экземпляр GCE отключен.
- Создайте снимок с каждого диска вашего экземпляра.
- Создавайте новый диск из каждого снимка.
- Удалите созданные снимки.
- Создайте YAML-файл в текущей рабочей директории для развертывания среды выполнения, которая будет размещать ваш веб-сервер.
Сгенерированный YAML-файл создаст stateful set в нашем кластере Kubernetes, а также запросит постоянные тома, необходимые для монтирования скопированных дисков в контейнер веб-сервера. Эти изменения можно применить с помощью kubectl :`.
kubectl apply -f containerized-webserver.yaml
Проверьте состояние webserver-statefulset на странице «Рабочие нагрузки»:
После выполнения команды kubectl apply статус несколько минут отображается как «Поды находятся в состоянии ожидания». Продолжайте, когда статус изменится на «ОК».
5. Предоставьте доступ к кластеру балансировщику нагрузки.
На данном этапе наш кластер Kubenetes должен запускать веб-сервер в режиме stateful set, но нам также потребуется предоставить доступ к его контейнеру балансировщику нагрузки для доступа к веб-серверу через внешний IP-адрес. В оболочке Cloud создайте новый файл с именем loadbalancer.yaml со следующим содержимым:
loadbalancer.yaml
apiVersion: v1
kind: Service
metadata:
name: webserver-loadbalancer
spec:
type: LoadBalancer
selector:
app: webserver-statefulset
ports:
- protocol: TCP
port: 80
targetPort: 80
А теперь применим это с помощью kubectl :
kubectl apply -f loadbalancer.yaml
Мы можем использовать kubectl для получения внешнего IP-адреса сервиса webserver-container:
kubectl get services
Если мы введем внешний IP-адрес в браузере, то должны увидеть тот же стандартный экран приветствия Nginx, что и раньше:
Мы это сделали! Наш веб-сервер GCE теперь размещен на Kubernetes! Отлично!
6. Мониторинг Stackdriver
Метрики
Как управляемый сервис Kubernetes, Kubernetes Engine автоматически настраивается для логирования и мониторинга с помощью Stackdriver. Давайте рассмотрим некоторые метрики, которые Stackdriver автоматически собирает для нас.
Нажмите на ссылку «Мониторинг» в меню продуктов — первый доступ к этой функции из вашего проекта может занять несколько минут, пока настраивается ваше рабочее пространство.
После загрузки наведите курсор на «Ресурсы» в левой панели и выберите в меню «Kubernetes Engine NEW».
Каждая строка на представленной здесь панели мониторинга соответствует ресурсу Kubernetes. Вы можете переключаться между представлениями инфраструктуры, рабочих нагрузок или сервисов с помощью ссылок над панелью мониторинга.
В представлении «Рабочие нагрузки» разверните «my-gke-cluster» и перейдите к default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset. Щелкните по контейнеру webserver-statefulset. Здесь вы найдете некоторые стандартные метрики, собираемые Stackdriver, включая использование памяти и использование ЦП.
Диаграммы, отображаемые на этой панели мониторинга, мы сможем использовать для создания собственной панели мониторинга.
Настраиваемые панели мониторинга
Stackdriver позволяет создавать пользовательские панели мониторинга, которые можно использовать для организации диаграмм и графиков по любым доступным нам метрическим данным. Давайте создадим пользовательскую панель мониторинга, чтобы обеспечить быстрый обзор некоторых метрик нашего веб-сервера.
В левой боковой панели наведите курсор на «Панели мониторинга», затем нажмите «Создать панель мониторинга».
Теперь, когда у нас есть пустая панель мониторинга, мы можем добавить метрики, за которыми хотим следить. Давайте дадим нашей панели мониторинга «Без названия» полезное имя, например, «Контейнеры моего веб-сервера», и нажмем «Добавить диаграмму» в правом верхнем углу:
Помните стандартные метрики? Давайте добавим диаграмму использования ЦП контейнером. В поле «Заголовок диаграммы» введите «Использование ЦП». В поле «Найти тип ресурса и метрику» введите request_utilization и выберите «Использование запросов ЦП» из отфильтрованного списка. Этот выбор автоматически заполнит поля «Тип ресурса» и «Метрика».
Далее нам нужно отфильтровать данные по project_id (если у нас несколько проектов) и container_name. В поле «Фильтр» введите project_id , выберите его из отфильтрованного списка и выберите свой проект в поле «Значение». Также необходимо отфильтровать данные по container_name. В поле «Фильтр» введите container_name , выберите его из отфильтрованного списка и выберите webserver-statefulset в поле «Значение». Нажмите «Сохранить».
Теперь у нас есть панель управления с первым графиком.
7. Политика проверки доступности и оповещения.
С помощью Stackdriver мы можем настроить оповещения, которые будут уведомлять нас о достижении любых заданных нами пороговых значений метрик. Например, мы можем настроить Stackdriver так, чтобы он отправлял нам электронное письмо, когда загрузка ЦП на предыдущем шаге будет превышать определенный порог в течение длительного времени, что может указывать на проблему с нашим приложением. Чтобы продемонстрировать, как выглядят эти оповещения, давайте настроим проверку доступности , а затем смоделируем сбой.
В левой панели выберите «Проверки времени безотказной работы», а затем «Обзор проверок времени безотказной работы»:
Как указано на странице «Проверки доступности», давайте настроим первую проверку доступности. Нажмите кнопку «Добавить проверку доступности» в правом верхнем углу страницы.
В следующей форме введите «Время безотказной работы конечной точки» в качестве заголовка и внешний IP-адрес вашего балансировщика нагрузки в качестве имени хоста.
Нажмите «Сохранить» , и вам будет предложено создать соответствующую политику оповещений :
Нажмите «Создать политику оповещений».
Назовём это «Политика обеспечения бесперебойной работы конечных точек». В разделе «Конфигурация» установите параметр «Условие срабатывает, если» в значение «Любой временной ряд нарушает» и нажмите «Сохранить ».
Мы еще не совсем закончили. Далее мы укажем канал уведомлений, чтобы получать оповещения о нарушениях нашей политики оповещений. В раскрывающемся списке «Тип канала уведомлений» выберите «Электронная почта», а затем укажите действительный адрес электронной почты.
Click Add Notification Channe l. Finally, at the bottom of the form, name the policy 'Web App Uptime' and click Save.
Чтобы увидеть, как будет выглядеть оповещение, откройте Cloud Shell в консоли Cloud Console еще раз. Следующая команда остановит службу nginx, работающую в нашем поде веб-сервера:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx -s stop"
Через несколько минут вы должны получить электронное письмо с уведомлением о сбое:
Давайте это отменим. Вернувшись в Cloud Shell, перезапустим nginx:
kubectl exec -t webserver-statefulset-0 -- /bin/bash -c "nginx"
Через несколько минут вы получите еще одно письмо от Stackdriver, на этот раз с более позитивными новостями, чем раньше:
8. Уборка
Теперь, когда мы перешли с GCE на GKE с помощью Migrate for Anthos, давайте очистим наш проект от всех созданных нами ресурсов.
Удалить проект
При желании вы можете удалить весь проект. В консоли GCP перейдите на страницу «Менеджер облачных ресурсов» :
В списке проектов выберите проект, над которым мы работали, и нажмите «Удалить» . Вам будет предложено ввести идентификатор проекта. Введите его и нажмите «Завершить».
Если вы предпочитаете удалять компоненты по одному, перейдите к следующему разделу.
Stackdriver
Панель управления
На странице панели управления нажмите значок настроек. 
В верхней части страницы выберите «Удалить панель управления» .
Политика оповещения
На странице «Политики» в меню «Действия» выберите «Удалить». 
Справа от каждой созданной вами политики.
Проверка времени безотказной работы
На странице «Проверки доступности» выберите «Удалить» в меню «Действия» справа от каждой созданной вами проверки.
GCE и Kubernetes
Экземпляр Google Compute Engine
gcloud compute instances delete webserver --zone=us-central1-a
Кластер Kubernetes (включает Migrate for Anthos, stateful set и службу балансировки нагрузки)
gcloud container clusters delete my-gke-cluster --zone=us-central1-a
Диски
В нашем наборе данных с сохранением состояния использовался созданный нами диск. Воспользуйтесь следующей ссылкой, чтобы получить его имя:
gcloud compute disks list --filter=webserver
Удалите диск, заменив мое имя на имя вашего диска, с помощью следующей команды:
gcloud compute disks delete vls-690d-webserver --zone=us-central1-a
Всё убрано!
9. Поздравляем!
Отлично! Вы перенесли свой веб-сервер с экземпляра GCE на кластер Kubernetes, используя Migrate for Anthos.
Что мы рассмотрели
- Мы перенесли веб-сервер с GCE на кластер Kubernetes, используя Migrate for Anthos.
- Мы открыли доступ к нашему веб-серверу с поддержкой StatefulSet для всего мира, предоставив к нему доступ через службу балансировки нагрузки Kubernetes.
- Мы включили Stackdriver и создали собственную панель мониторинга.
- Мы настроили проверку доступности сервера, а также политику оповещений, чтобы получать уведомления о сбоях в работе нашего веб-сервера.