1. Обзор
Переписать или перепроектировать существующие приложения для работы в Kubernetes не всегда возможно или осуществимо вручную. Миграция для Anthos поможет модернизировать существующие приложения и запустить их в Kubernetes. В этой лаборатории кода вы перенесете существующее веб-приложение, размещенное на Compute Engine, в Kubernetes Engine с помощью Migrate for Anthos.
Что вы узнаете
- Как развернуть Migrate for Anthos в кластере Kubernetes
- Как создать контейнер в наборе с отслеживанием состояния на основе существующего экземпляра 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 for Anthos
Далее мы создадим кластер GKE, куда мы в конечном итоге перенесем веб-сервер вычислительной системы. В облачной консоли выполните следующее:
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 для развертывания Migrate for Anthos:
На странице магазина «Миграция на Anthos» нажмите «Настроить» и при появлении запроса выберите свой проект из списка. На следующей странице будет представлена форма с введенными некоторыми значениями по умолчанию. Убедитесь, что выбран именно тот кластер, который мы только что создали, и нажмите «Развернуть» :
Теперь Migrate for Anthos должен быть развернут в нашем кластере Kubernetes. Когда развертывание завершится, вы увидите статус «ОК» на странице «Приложения Kubernetes Engine» :
4. От вычислительного экземпляра к набору с отслеживанием состояния
У нас есть кластер Kubernetes, на котором работает Migrate for Anthos, поэтому теперь мы можем начать процесс миграции. Чтобы развернуть наш вычислительный экземпляр в кластере Kubenetes, мы отключим наш экземпляр вычислительного механизма, чтобы иметь возможность делать снимки дисков. Прежде чем двигаться дальше, запишите идентификатор экземпляра , который нам понадобится позже:
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 предоставит набор с отслеживанием состояния в нашем кластере Kubernetes, а также постоянные заявки на тома, необходимые для монтирования скопированных дисков в контейнер нашего веб-сервера. Мы можем применить эти изменения с помощью kubectl :
kubectl apply -f containerized-webserver.yaml
Проверьте состояние набора состояний веб-сервера на странице «Рабочие нагрузки»:
Статус «Поды ожидают» в течение нескольких минут после запуска kubectl apply является нормальным явлением. Двигайтесь дальше, как только появится статус «ОК».
5. Предоставьте кластер балансировщику нагрузки.
На этом этапе в нашем кластере Kubenetes должен работать наш веб-сервер как набор с отслеживанием состояния, но нам также необходимо предоставить его контейнер балансировщику нагрузки для доступа к нашему веб-серверу через внешний 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-адреса службы веб-сервера-контейнера:
kubectl get services
Если мы введем внешний IP-адрес в нашем браузере, мы должны увидеть тот же экран приветствия nginx по умолчанию, что и ранее:
Мы сделали это! Наш веб-сервер GCE теперь размещен в Kubernetes! Хороший!
6. Мониторинг стекдрайвера
Метрики
Будучи управляемым сервисом Kubernetes, Kubernetes Engine автоматически оснащен инструментами для ведения журналов и мониторинга с помощью Stackdriver. Давайте проверим некоторые показатели, которые Stackdriver автоматически фиксирует.
Нажмите ссылку «Мониторинг» в меню продуктов — доступ к ней в первый раз из вашего проекта может занять несколько минут, пока будет настроено ваше рабочее пространство.
После загрузки наведите указатель мыши на «Ресурсы» на левой панели и выберите «Kubernetes Engine NEW» в меню.
Каждая строка представленной здесь информационной панели представляет ресурс Kubernetes. Вы можете переключаться между представлением инфраструктуры, рабочих нагрузок или служб с помощью ссылок над панелью мониторинга.
В представлении «Рабочие нагрузки» разверните «my-gke-cluster» и перейдите к элементу default > webserver-statefulset > webserver-statefulset-0 > webserver-statefulset. Нажмите на контейнер набора с отслеживанием состояния веб-сервера. Здесь вы найдете некоторые готовые показатели, собираемые Stackdriver, включая использование памяти и загрузку ЦП.
Диаграммы, отображаемые на этой информационной панели, мы сможем использовать для создания пользовательской информационной панели.
Пользовательские панели мониторинга
Stackdriver позволяет нам создавать собственные информационные панели, которые мы можем использовать для организации диаграмм и графиков для любых доступных нам показателей. Давайте создадим пользовательскую панель мониторинга, чтобы обеспечить быстрое представление некоторых показателей нашего веб-сервера.
На левой боковой панели наведите указатель мыши на «Панели мониторинга», затем нажмите «Создать панель мониторинга».
Теперь, когда у нас есть пустая панель мониторинга, мы можем добавить показатели, за которыми хотим следить. Давайте дадим нашей панели без названия полезное имя, например «Контейнеры моего веб-сервера», и нажмите «Добавить диаграмму» в правом верхнем углу:
Помните готовые метрики? Добавим диаграмму загрузки процессора контейнера. В поле «Заголовок диаграммы» введите «Загрузка ЦП». В поле «Найти тип ресурса и метрику» введите request_utilization и выберите загрузку запросов ЦП из отфильтрованного списка. Этот выбор заполнит для нас поля «Тип ресурса» и «Метрика».
Далее нам нужно фильтровать по нашему project_id (если у нас несколько проектов) иContainer_name. В поле «Фильтр» введите project_id , выберите его из отфильтрованного списка и выберите свой проект в поле «Значение». Нам также необходимо фильтровать по имени контейнера. В поле «Фильтр» введите имя_контейнера , выберите его из отфильтрованного списка и выберите webserver-statefulset в поле «Значение». Нажмите «Сохранить».
Теперь у нас есть панель мониторинга с нашей первой диаграммой.
7. Проверка работоспособности и политика оповещений
С помощью Stackdriver мы можем настроить оповещения, чтобы уведомлять нас, когда какие-либо показатели достигают указанных нами пороговых значений. Например, мы можем попросить Stackdriver отправить нам электронное письмо, когда загрузка ЦП на последнем этапе превышает определенный порог в течение длительного периода времени, что может указывать на проблему с нашим приложением. Чтобы продемонстрировать, как выглядят эти оповещения, давайте настроим проверку работоспособности , а затем смоделируем сбой.
На левой панели выберите «Проверки работоспособности», а затем «Обзор проверок работоспособности».
Как следует из страницы «Проверки работоспособности», давайте настроим нашу первую проверку работоспособности. Нажмите кнопку «Добавить проверку работоспособности» в правом верхнем углу страницы.
В форме ввода введите «Время работы конечной точки» в качестве заголовка и внешний IP-адрес вашего балансировщика нагрузки в качестве имени хоста.
Нажмите «Сохранить» , и вам будет предложено создать соответствующую политику оповещений :
Нажмите Создать политику оповещений.
Назовем это «Политикой работоспособности конечной точки». В разделе «Конфигурация» установите для параметра «Условие срабатывает, если» значение «Нарушение любого временного ряда» и нажмите « Сохранить» .
Мы еще не совсем закончили. Далее мы укажем канал уведомлений, чтобы получать уведомления в случае нарушения нашей политики оповещений. В раскрывающемся списке «Тип канала уведомлений» выберите «Электронная почта», а затем действительный адрес электронной почты.
Нажмите «Добавить канал уведомлений» . l. Наконец, в нижней части формы назовите политику «Время работы веб-приложения» и нажмите «Сохранить».
Чтобы увидеть, как будет выглядеть оповещение, в Cloud Console еще раз откройте Cloud Shell. Следующая команда остановит службу 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 перейдите на страницу диспетчера облачных ресурсов :
В списке проектов выберите проект, над которым мы работали, и нажмите «Удалить» . Вам будет предложено ввести идентификатор проекта. Введите его и нажмите «Выключить».
Если вы предпочитаете удалять различные компоненты один за другим, перейдите к следующему разделу.
Стекдрайвер
Панель управления
На странице панели управления щелкните значок настроек. 
вверху страницы и выберите «Удалить панель мониторинга» .
Политика оповещения
На странице «Политики» выберите «Удалить» в меню «Действия». 
справа для каждой созданной вами политики.
Проверка работоспособности
На странице «Проверки работоспособности» выберите «Удалить» в меню «Действия» справа от каждой созданной вами проверки.
GCE и Кубернетес
Экземпляр Google Compute Engine
gcloud compute instances delete webserver --zone=us-central1-a
Кластер Kubernetes (включает Migrate for Anthos, набор с отслеживанием состояния и службу балансировки нагрузки)
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.
- Мы открыли наш веб-сервер с сохранением состояния для всего мира, представив его через службу балансировки нагрузки Kubernetes.
- Мы включили Stackdriver и создали собственную панель управления.
- Мы настроили проверку работоспособности вместе с политикой оповещений, чтобы сообщать нам, когда наш веб-сервер выходит из строя.