Чи готові ви до Kubernetes на власній інфраструктурі?

Цей місток призначений для тих, хто вміє експлуатувати Kubernetes у керованих хмарних або сертифікаційних середовищах і розглядає можливість роботи з кластерами на bare-metal чи на власній інфраструктурі (on-premises). Він закриває розрив у готовності між використанням керованих припущень хмарного провайдера та самостійним володінням обладнанням, мережею, сховищем, провіженінгом, доступністю площини управління й поведінкою балансування навантаження.

Діагностика — чи готові ви?

• Ви можете по пам’яті накреслити базову мережу spine-leaf і пояснити, де розташовані стійки, ToR-комутатори, аплінки та межі маршрутизації.
• Ви завантажували фізичний сервер через PXE або можете пояснити передачу керування між DHCP, TFTP, iPXE, прошивкою та інсталятором.
• Ви можете пояснити різницю між «худобою» та «улюбленцями» (cattle vs pets) на рівні обладнання, зокрема те, як замінюють несправні диски, мережеві карти, модулі пам’яті та вузли.
• Ви вмієте розраховувати потрібний обсяг CPU, RAM, диску та GPU для тривалих навантажень, а не для імпульсних хмарних інстансів.
• Ви розумієтеся на анонсуванні маршрутів BGP достатньо, щоб пояснити, чому MetalLB у режимі BGP змінює поведінку маршрутизації вище за течією.
• Ви можете пояснити, коли kube-vip, MetalLB та зовнішній балансувальник навантаження розв’язують різні задачі.
• Ви експлуатували Ceph, Rook, Longhorn, Portworx чи іншу розподілену систему зберігання за межами демонстраційного встановлення.
• Ви можете описати, як руйнується кворум etcd, коли фізичні домени відмов відображено невдало.
• Ви знаєте, що відбувається, коли стійка втрачає живлення, комутатор перезавантажується або деградує бекплейн сховища.
• Ви можете відокремити доступність робочих навантажень від доступності інфраструктури, коли керованої площини управління не існує.
• Ви можете оцінити цикл закупівлі, постачання, обкатки (burn-in) та заміни серверного обладнання.
• У вас є план моніторингу справності обладнання, дрейфу прошивок та фізичного інвентарю.

Карта прогалин у навичках

Що ви маєте	Що вам потрібно	Де це вивчати
Вільне володіння Kubernetes API	Володіння фізичною інфраструктурою	Планування та економіка
Операції з кластером у стилі CKA	Впевненість у роботі з Linux-хостом та ядром	Поглиблений курс Linux
Керовані групи вузлів	Робочий процес провіженінгу bare-metal	Провіженінг bare-metal
Хмарні балансувальники навантаження	BGP, VIP та публікація сервісів на bare-metal	Мережа на власній інфраструктурі
Хмарне блокове сховище	Ceph та операції з розподіленим сховищем	Сховище на власній інфраструктурі
Хмарні домени відмов	Домени відмов стійки, живлення, комутатора та диску	Планування та економіка
Очікування від керованої площини управління	Життєвий цикл самокерованої площини управління	Провіженінг bare-metal
Адміністрування одного кластера	Патерни відновлення та розміщення для кількох кластерів	Патерни для кількох кластерів
Усунення несправностей застосунків	Усунення несправностей інфраструктури нижче за Kubernetes	Поглиблений курс Linux
Усвідомлення хмарних витрат	Капітальні витрати, амортизація, запасні частини та утилізація	Планування та економіка

Послідовний шлях

1. Почніть із Поглибленого курсу Linux. Чому саме цей крок: відмови Kubernetes на власній інфраструктурі часто починаються нижче за Kubernetes — у ядрі, на дисках, у мережевому стеку, прошивці чи хостових службах.

2. Прочитайте Планування та економіку. Чому саме цей крок: кластери на bare-metal є планами потужностей та операційними зобов’язаннями ще до того, як вони стають кластерами Kubernetes.

3. Опрацюйте Провіженінг bare-metal. Чому саме цей крок: повторюване встановлення вузлів — це різниця між парком серверів, який можна відновити, і купою серверів-особливих випадків.

4. Вивчіть Мережу на власній інфраструктурі. Чому саме цей крок: публікація сервісів, досяжність вузлів, анонсування маршрутів BGP, перемикання VIP та топологія стійок визначають, чи будуть робочі навантаження досяжними під час відмови.

5. Вивчіть Сховище на власній інфраструктурі. Чому саме цей крок: стейтфул-навантаження на bare-metal залежать від систем зберігання, які потрібно проєктувати, моніторити, ремонтувати й оновлювати.

6. Перейдіть до Патернів для кількох кластерів. Чому саме цей крок: один кластер на власній інфраструктурі рідко є остаточною межею надійності для продакшн-, навчальних чи регульованих навантажень.

Антипатерни

• Припущення, що звички з керованої хмари без змін переносяться на фізичну інфраструктуру.
• Ставлення до площини управління як до чужої зони відповідальності за аптайм.
• Проєктування публікації сервісів до розуміння BGP, перемикання VIP та маршрутизації вище за течією.
• Запуск стейтфул-навантажень до опанування системи зберігання, яка їх обслуговує.
• Купівля обладнання до визначення профілів навантажень, доменів відмов, запасних частин та політики життєвого циклу.
• Ставлення до живлення стійки, охолодження, прошивок та фізичного інвентарю як до другорядних деталей.

Як виглядає успіх

• Ви можете пояснити дизайн кластера від живлення стійки до публікації сервісів Kubernetes.
• Ви можете перебудувати відмовлений вузол без саморобних кроків відновлення.
• Ви можете обґрунтувати вибір сховища для стейтлес-, стейтфул- та навчальних навантажень.
• Ви можете описати, як трафік досягає сервісу, коли відмовляє вузол, комутатор чи стійка.
• Ви можете зіставити etcd, репліки сховища та репліки навантажень із реальними доменами відмов.
• Ви можете визначити, до чого належить проблема — до Kubernetes, Linux, мережі, обладнання чи сховища.

Перший модуль для читання

Почніть із Планування та економіки.