
Before you begin
- Labs create a Google Cloud project and resources for a fixed time
- Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
- On the top left of your screen, click Start lab to begin
Create a Kubernetes cluster and deployments (Auth, Hello, and Frontend)
/ 50
Canary Deployment
/ 50
У DevOps є різні сценарії розгортання додатків (безперервне, синьо-зелене, канаркове тощо), для яких регулярно використовуються кілька розгортань. Під час цієї практичної роботи ви навчитеся змінювати кількість контейнерів і керувати ними, щоб виконувати поширені сценарії з кількома гетерогенними розгортаннями.
У цій практичній роботі ви навчитеся виконувати наведені нижче дії.
kubectl
yaml
Результати практичної роботи будуть кращими, якщо ви:
Зазвичай гетерогенними вважаються розгортання, у яких через певну технічну чи операційну потребу поєднуються два або більше інфраструктурних середовищ чи регіонів. Залежно від особливостей такі розгортання також називають "гібридними", "мультихмарними" або "загальнодоступно-приватними".
У цій практичній роботі до гетерогенних розгортань належать ті, що вміщують кілька регіонів у єдиному хмарному середовищі, кілька загальнодоступних хмарних середовищ (мультихмарні) або поєднання локальних середовищ із загальнодоступними хмарними середовищами (гібридні або загальнодоступно-приватні).
У розгортаннях, які обмежені одним середовищем або регіоном, можуть виникати різні організаційні чи технічні проблеми.
Гетерогенні розгортання допомагають усувати такі проблеми, але при цьому потрібно використовувати програмовані й детерміновані процеси та процедури. Одноразові або нетипові процедури можуть робити розгортання вразливими й нестійкими до збоїв. Нетипові процеси можуть призводити до втрати даних чи зупинки трафіку. Варто застосовувати повторювані процеси розгортання, які використовують надійні підходи до керування розподіленням, конфігурацією і обслуговуванням.
Гетерогенні розгортання застосовуються в трьох основних сценаріях:
За допомогою наведених далі вправ ви потренуєтеся виконувати поширені сценарії для гетерогенних розгортань, а також ознайомитеся з добре спроектованими підходами з використанням Kubernetes і іншими інфраструктурними ресурсами.
Ознайомтеся з наведеними нижче вказівками. На виконання практичної роботи відводиться обмежений час, і її не можна призупинити. Щойно ви натиснете Start Lab (Почати практичну роботу), з’явиться таймер, який показуватиме, скільки часу для роботи з ресурсами Google Cloud у вас залишилося.
Ви зможете виконати практичну роботу в дійсному робочому хмарному середовищі (не в симуляції або демонстраційному середовищі). Для цього на час виконання практичної роботи вам надаються тимчасові облікові дані для реєстрації і входу в Google Cloud.
Щоб виконати цю практичну роботу, потрібно мати:
Натисніть кнопку Start Lab (Почати практичну роботу). Якщо за практичну роботу необхідно заплатити, відкриється спливаюче вікно, де ви зможете обрати спосіб оплати. Ліворуч розміщено панель Lab Details (Відомості про практичну роботу) з такими даними:
Натисніть Open Google Cloud console (Відкрити Google Cloud Console) або натисніть правою кнопкою миші й виберіть Open Link in Incognito Window (Відкрити посилання в анонімному вікні), якщо ви використовуєте вебпереглядач Chrome.
Завантажаться необхідні ресурси. Потім відкриється нова вкладка зі сторінкою Sign in (Вхід).
Порада. Упорядковуйте вкладки в окремих вікнах, розміщуючи їх поруч.
За потреби скопіюйте значення в полі Username (Ім’я користувача) нижче й вставте його у вікні Sign in (Вхід).
Поле Username (Ім’я користувача) також можна знайти на панелі Lab Details (Відомості про практичну роботу).
Натисніть Next (Далі).
Скопіюйте значення в полі Password (Пароль) нижче й вставте його у вікні Welcome (Привітання).
Поле Password (Пароль) також можна знайти на панелі Lab Details (Відомості про практичну роботу).
Натисніть Next (Далі).
Виконайте наведені нижче дії.
Через кілька секунд Google Cloud Console відкриється в новій вкладці.
Cloud Shell – це віртуальна машина з попередньо завантаженими інструментами для розробників. Вона містить головний каталог обсягом 5 ГБ постійної пам’яті й працює в середовищі Google Cloud. Cloud Shell надає доступ до ресурсів Google Cloud через командний рядок.
Щойно ви підключитеся, вас буде автентифіковано, а проект отримає ваш PROJECT_ID (ІДЕНТИФІКАТОР ПРОЕКТУ). Вивід міститиме рядок зі значенням PROJECT_ID (ІДЕНТИФІКАТОР ПРОЕКТУ) для цього сеансу:
gcloud
– це інструмент командного рядка для Google Cloud. Він входить у пакет Cloud Shell і підтримує функцію автозавершення клавішею TAB.
Натисніть Authorize (Авторизувати).
Вихідні дані матимуть такий вигляд:
Вивід:
Вивід:
Приклад виводу:
gcloud
, перегляньте посібник з інтерфейсу командного рядка gcloud у Google Cloud.
Налаштуйте робочу зону Google Cloud, виконавши наведену нижче команду. Вставте потрібну зону замість
Для початку дізнайтеся більше про об’єкт розгортання.
explain
в інструменті kubectl
:--recursive
:deployments/auth.yaml
:image
на таке значення:auth.yaml
. Для цього натисніть <Esc>
і введіть:<Enter>
. Тепер створіть просте розгортання. Перегляньте файл конфігурації розгортання:Вивід:
Зверніть увагу, що розгортання створює одну копію і для контейнера auth використовується версія 1.0.0.
Коли ви виконаєте команду kubectl create
, щоб створити розгортання auth, буде створено одну групу контейнерів, яка відповідає даним у маніфесті розгортання. Це означає, що ви можете збільшити кількість таких груп, змінивши число, указане в полі replicas
.
kubectl create
:ReplicaSet
. Щоб перевірити, чи створено ReplicaSet
, виконайте команду:Має відображатися об’єкт ReplicaSet
під назвою на зразок auth-xxxxxxx
.
ReplicaSet
створюється одна група контейнерів:Час створити сервіс для розгортання auth. Ви вже знайомі з файлами маніфесту сервісів, тому ми не будемо докладно їх описувати.
kubectl create
:hello
й надати до нього доступ:frontend
:ConfigMap
.Ви отримаєте відповідь hello.
kubectl
можна запускати команду curl в одному рядку:Щоб підтвердити виконання завдання, натисніть Підтвердити виконання нижче. Якщо ви правильно створили кластер і розгортання auth, hello й frontend, з’явиться оцінка.
Створене розгортання можна масштабувати. Для цього оновіть поле spec.replicas
.
kubectl explain
:kubectl scale
:Після оновлення розгортання Kubernetes автоматично оновить об’єкт ReplicaSet
і запустить нові групи контейнерів, щоб їх загалом стало 5.
hello
:Ви ознайомилися з розгортаннями Kubernetes, а також навчилися керувати групою контейнерів і змінювати їх кількість.
Розгортання підтримують перехід на нову версію образу шляхом послідовного оновлення. Під час такого оновлення розгортання створює новий об’єкт ReplicaSet
і поступово збільшує в ньому кількість копій, зменшуючи кількість копій у старому об’єкті
ReplicaSet
.
image
на таке значення:Оновлене розгортання збережеться в кластері, і Kubernetes почне послідовне оновлення.
ReplicaSet
, створений у Kubernetes:Якщо в процесі оновлення виникли проблеми, призупиніть його.
Якщо оновлення призупинено, одні групи контейнерів перейшли на нову версію, а інші залишилися на попередній.
resume
:status
ви маєте побачити наведений нижче вивід.Вивід:
Уявіть, що в новій версії виявлено помилку. Через це всі користувачі, які підключатимуться до нових груп контейнерів, стикатимуться з проблемами.
Ви хочете повернутися на попередню версію, щоб знайти причину проблеми, усунути її і випустити виправлену версію.
rollout
:Чудово! Ви навчилися повертатися до попередньої версії розгортання Kubernetes і оновлювати додатки без простою.
Використовуйте цей тип розгортання, якщо працюєте на новим розгортанням і хочете протестувати його на невеликій аудиторії. Так ви зможете зробити певну зміну доступною для маленької групи користувачів і уникнете ризиків, пов’язаних із новими випусками.
Канаркове розгортання складається з окремого розгортання нової версії і сервісу, який націлюється як на звичайне стабільне розгортання, так і на канаркове.
Вивід:
hello
й hello-canary
. Перевірте це за допомогою команди kubectl
:У селекторі app:hello
сервісу hello
відображатимуться групи контейнерів обох розгортань: робочого й канаркового. Однак оскільки канаркове розгортання має менше груп контейнерів, воно показуватиметься меншій кількості користувачів.
hello
використовується, виконайте такий запит:Щоб підтвердити виконання завдання, натисніть Підтвердити виконання нижче. Якщо ви правильно створили канаркове розгортання, з’явиться оцінка.
У цій практичній роботі канаркове розгортання могло обробляти будь-який запит, надісланий у сервіс Nginx. Але іноді потрібно зробити так, щоб користувач не натрапляв на канаркове розгортання. Наприклад, ви внесли зміни в інтерфейс і не хочете нікого спантеличити. У такому разі варто "закріпити" за користувачем певне розгортання.
Для цього можна створити сервіс із відповідністю сеансів. Так користувач завжди обслуговуватиметься тією самою версією. У прикладі нижче в знайомий вам код сервісу додано поле sessionAffinity
зі значенням ClientIP
. Запити від усіх клієнтів із незмінною ІР-адресою надсилатимуться до тієї самої версії додатка hello
.
Ми не перевірятимемо цей метод у практичній роботі, оскільки для цього потрібно виконати складні налаштування. Однак поле sessionAffinity
варто використовувати під час створення робочих канаркових розгортань.
Послідовні оновлення дуже зручні, оскільки дають змогу повільно розгортати додаток із мінімальними накладними витратами, втратами продуктивності й часом простою. Однак бувають випадки, коли краще спочатку повністю розгорнути нову версію, а потім націлити на неї розподілювачі навантаження. У такому разі слід використовувати синьо-зелені розгортання.
Для цього методу Kubernetes створює два окремі розгортання: "синє" для старої версії і "зелене" для нової. Використовуйте наявне розгортання hello
як "синю" версію. Доступ до розгортання надаватиметься через сервіс, який працюватиме як маршрутизатор. Коли "зелену" версію буде повністю розгорнуто, ви перейдете на неї, оновивши сервіс.
Візьміть за основу наявний сервіс hello й додайте в нього селектор app:hello
, version: 1.0.0
. Цей селектор буде таким самим, як і в наявному "синьому" розгортанні, але в "зеленому" розгортанні він відрізнятиметься, оскільки там використовується інша версія.
resource service/hello is missing
, оскільки проблема усувається автоматично.Щоб виконати таке оновлення, створіть "зелене" розгортання для нової версії. Воно відрізнятиметься міткою версії і шляхом до образу.
За потреби ви можете так само повернутися до попередньої версії.
Вам удалося! Ви навчилися створювати синьо-зелені розгортання й оновлювати додатки у випадку, коли потрібно перейти одразу на готову версію.
Ви розширили свій досвід роботи з інструментом командного рядка kubectl
і навчилися створювати різні конфігурації розгортань у файлах YAML, щоб запускати, оновлювати й масштабувати розгортання. Це базове тренування, якого має бути достатньо, щоб застосовувати набуті навички в реальних завданнях у галузі DevOps.
Рішення й вказівки з DevOps у документації Google Cloud.
Долучайтеся до спільноти Kubernetes!
…допомагають ефективно використовувати технології Google Cloud. Наші курси передбачають опанування технічних навичок, а також ознайомлення з рекомендаціями, що допоможуть вам швидко зорієнтуватися й вивчити матеріал. Ми пропонуємо курси різних рівнів – від базового до високого. Ви можете вибрати формат навчання (за запитом, онлайн або офлайн) відповідно до власного розкладу. Пройшовши сертифікацію, ви перевірите й підтвердите свої навички та досвід роботи з технологіями Google Cloud.
Посібник востаннє оновлено 2 квітня 2024 року
Практичну роботу востаннє протестовано 14 серпня 2023 року
© Google LLC 2025. Усі права захищено. Назва та логотип Google є торговельними марками Google LLC. Усі інші назви компаній і продуктів можуть бути торговельними марками відповідних компаній, з якими вони пов’язані.
This content is not currently available
We will notify you via email when it becomes available
Great!
We will contact you via email if it becomes available
One lab at a time
Confirm to end all existing labs and start this one