Від Kubernetes Dashboard до Headlamp: покроковий посібник

Автор: Vincent T. (Microsoft) | Перекладач(і): Андрій Головін |

1. До того, як почати: що змінюється

Kubernetes Dashboard та Headlamp обидва показують, що працює в кластері, але вони працюють по-різному. Коли Headlamp запускається на робочому столі, він використовує ваш наявний kubeconfig для підключення до одного або кількох кластерів і може бути розширений втулками. Коли Headlamp запускається всередині кластера, він використовує Kubernetes ServiceAccount для доступу до API та дотримання правил RBAC. Kubernetes Dashboard, навпаки, працює лише всередині кластера і завжди покладається на токени службового облікового запису. Розуміння цих моделей на ранньому етапі допомагає вибрати правильну конфігурацію та дозволи.

1.1 Як працює Kubernetes Dashboard

Dashboard — це вебзастосунок, який працює всередині вашого кластера.

  • Ви встановлюєте його в кластері, часто за допомогою Helm.
  • Зазвичай ви запускаєте один Dashboard на кластер.
  • Часто ви отримуєте доступ до нього через kubectl port-forward або ingress.
  • Ви входите за допомогою токена на предʼявника. Цей токен часто походить від службового облікового запису.
  • Він включає форми, які допомагають створювати ресурси.
  • Він спирається на таблиці та списки для навігації.

Відчуття таке: інтерфейс користувача, який живе разом із кластером.

1.2 Як працює Headlamp

Headlamp діє більше як клієнт Kubernetes з інтерфейсом користувача.

  • Він може працювати на вашому робочому столі або в кластері.
  • Він читає ваш kubeconfig, як це робить kubectl.
  • Він може показувати більше одного кластера в одному місці.
  • Він віддає перевагу YAML при створенні або зміні ресурсів.
  • Він включає списки та візуальну мапу.
  • Ви можете додавати функції за допомогою втулків.

Headlamp — це інтерфейс користувача, який слідує за вашою ідентичністю, а не за кластером.

1.3 Що залишається без змін

Більшість робочих процесів залишаться знайомими:

  • Перегляд робочих навантажень та ресурсів
  • Фільтрація за простором імен
  • Перегляд YAML, подій та стану
  • Перегляд журналів
  • Виконання дій, дозволених вашим RBAC

1.4 Що змінюється

Деякі речі будуть відчуватися інакше:

  • Вхід змінюється з вставлених токенів на kubeconfig (а іноді і SSO).
  • Створення змінюється з заповнення форм на "застосування YAML".
  • Багатокластерність стає нормою, а не особливим випадком.
  • Візуальна мапа допомагає бачити, як повʼязані ресурси.

2. Перевірка перед міграцією

Цей контрольний список допоможе уникнути неприємних сюрпризів під час переходу. Він гарантує, що Headlamp може використовувати ту ж ідентичність та дозволи, яким ви вже довіряєте в Kubernetes. Він також дає швидкий спосіб перевірити, чи працює міграція, перш ніж вимкнути Dashboard.

2.1 Запишіть, що ви використовуєте сьогодні

Перелічіть основне:

  • Які кластери ви використовуєте (dev, staging, prod)
  • Які простори імен ви використовуєте найчастіше
  • Що ви робите найчастіше (перегляд, редагування, масштабування, видалення, налагодження)
  • Як ви отримуєте доступ до Dashboard сьогодні (port-forward або ingress)
  • Як ви входите (токен службового облікового запису та які RBAC-приʼязки)

Це ваша відправна точка.

2.2 Перевірте, чи працює kubeconfig

Headlamp використовує kubeconfig, особливо на робочому столі. Переконайтеся, що ваш працює, перш ніж встановлювати будь-що.

Запустіть:

kubectl config current-context

Потім спробуйте:

kubectl get nodes

Якщо ви не можете вивести список вузлів, спробуйте це зробтити в просторі імен, до якого у вас є доступ:

kubectl get pods -n <namespace>

Якщо ці команди працюють, Headlamp може використовувати ту ж ідентичність та RBAC.

2.3 Виберіть план розгортання

Немає потреби поспішати. Більшість команд обирають один з цих варіантів:

Паралельне розгортання (рекомендовано)

  • Встановіть Headlamp
  • Дайте людям спробувати його
  • Залиште Dashboard на короткий час
  • Видаліть Dashboard після того, як команда буде готова

Перемикання

  • Встановіть Headlamp
  • Перемкніть документацію та посилання
  • Видаліть Dashboard незабаром після цього

Паралельне розгортання безпечніше для спільних кластерів.

2.4 Виберіть, де буде працювати Headlamp

Ви можете використовувати будь-який варіант. Багато команд використовують обидва.

Desktop

  • Використовує ваш kubeconfig
  • Не використовує ресурси кластера
  • Не потребує port-forward
  • Багатокластерність працює з коробки

В кластері

  • Працює добре для спільного доступу через оглядач
  • Може керуватися як інші застосунки в кластері
  • Часто використовується разом з ingress та SSO

2.5 Зверніть увагу на необовʼязкові залежності

Це поширені залежності. Ви можете налаштувати їх пізніше.

  • metrics-server (для графіків використання CPU та памʼяті)
  • ingress (для URL всередині кластера)
  • OIDC / SSO (для входу через оглядач)
  • очищення старих службових облікових записів Dashboard та RBAC

3. Виберіть, де буде працювати Headlamp (робочий стіл або в кластері)

Headlamp може працювати на вашому робочому столі або всередині кластера. Обидва варіанти добре працюють, але вони підходять для різних потреб. Робочий стіл — найшвидший спосіб почати, оскільки він використовує ваш kubeconfig і не працює в кластері. В кластері краще, коли потрібен спільний URL і ви хочете, щоб команда платформи керувала оновленнями та доступом.

Варіант A: Desktop (керується користувачем)

Desktop Headlamp запускається на кожному компʼютері користувача. Він читає той самий kubeconfig, який ви використовуєте з kubectl. Це дозволяє доступ, привʼязаний до ідентичності та RBAC кожного користувача.

Чому команди обирають цей варіант

  • Немає сервісу в кластері для розгортання або відкриття.
  • Не використовує ресурси кластера (CPU або памʼять).
  • Використовує ваш kubeconfig і RBAC.
  • Працює з багатьма кластерами в одному застосунку.
  • Не потребує port-forward для щоденного використання.

Варіант B: In-cluster (найкраще для спільного доступу)

In-cluster Headlamp встановлюється як робоче навантаження Kubernetes (часто через Helm). Це дозволяє адміністраторам кластера керувати ним як іншими застосунками в кластері.

  • Адміністратори кластера керують встановленням, оновленнями та конфігурацією через Helm chart та стандартні інструменти Kubernetes.
  • Адміністратори контролюють ingress і можуть налаштувати вхід через OIDC для спільного доступу.
  • Підтримує спільне використання в командних середовищах.

4. Встановлення Headlamp (робочий стіл та в кластері)

Цей розділ допоможе запустити Headlamp. Дотримуйтесь шляху, який ви обрали в Розділі 3.

4.1 Встановлення на робочий стіл (найшвидший спосіб почати)

Встановіть Headlamp на вашому компʼютері. Потім відкрийте його як будь-який інший застосунок. Headlamp читає ваш kubeconfig і використовує ті ж правила ідентичності та RBAC, що й kubectl.

Windows

Встановлення за допомогою WinGet:

winget install headlamp

Або з Chocolatey:

choco install headlamp

macOS

Встановлення за допомогою Homebrew:

brew install --cask headlamp

Linux

Встановлення за допомогою Flatpak (Flathub):

flatpak install flathub io.kinvolk.Headlamp

Швидка перевірка

  1. Запустіть Headlamp.
  2. Підтвердьте, що ви бачите контекст кластера.
  3. Відкрийте простір імен, до якого у вас є доступ, і підтвердьте, що ви можете переглядати робочі навантаження. Headlamp покаже лише ті дії, на які дозволяє ваш RBAC.

4.2 Встановлення в кластері (спільний доступ)

Використовуйте цей шлях, якщо ви хочете спільний інтерфейс, яким може керувати команда платформи. Headlamp підтримує розгортання в кластері за допомогою Helm або YAML-манифесту.

Встановлення за допомогою Helm

Додайте репозиторій і оновіть його:

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update

Створіть простір імен (приклад):

kubectl create namespace headlamp

Встановіть чарт:

helm install headlamp headlamp/headlamp --namespace headlamp

Встановлення за допомогою YAML-манифесту (опціонально)

Headlamp також надає YAML-манифест, який ви можете застосувати, а потім налаштувати відповідно до ваших потреб.

Перевірка встановлення

Підтвердьте, що под запущений:

kubectl get pods -n headlamp

Підтвердьте, що сервіс існує:

kubectl get svc -n headlamp

Доступ до нього (два поширені способи)

Швидка перевірка за допомогою port-forward

Це найшвидший спосіб перевірити, чи працює сервіс:

kubectl port-forward -n headlamp svc/headlamp 8080:80

Потім відкрийте: http://localhost:8080

Спільний доступ через ingress

Якщо ви хочете мати стабільний URL, відкрийте сервіс через ваш ingress-контролер. Точний YAML для ingress залежить від вашої конфігурації. URL для OIDC callback у Headlamp — це ваш публічний URL плюс /oidc-callback, тому налаштування ingress і TLS мають значення.

4.3 Оновлення Headlamp

Оновлення залежить від того, як ви встановили Headlamp. Менеджери пакунків оновлюють застосунок на місці. Встановлення через DMG або EXE оновлюється шляхом повторного встановлення нової версії.

macOS

Якщо ви встановили за допомогою Homebrew, виконайте:

brew upgrade headlamp

Якщо ви встановили з DMG, завантажте новий DMG і перетягніть Headlamp у /Applications, замінивши стару версію. Встановлення через DMG не оновлюється автоматично.

Windows

Якщо ви встановили за допомогою WinGet, виконайте:

winget upgrade headlamp

Якщо ви встановили за допомогою Chocolatey, виконайте:

choco upgrade headlamp

Якщо ви встановили з EXE, завантажте новий інсталятор і запустіть його знову. Встановлення через EXE не оновлюється автоматично.

Linux

Якщо ви встановили за допомогою Flatpak, виконайте:

flatpak update io.kinvolk.Headlamp

Якщо ви встановили за допомогою AppImage, завантажте новий AppImage і запустіть цей файл замість старого.

Якщо ви встановили за допомогою tarball, завантажте новий tarball, розпакуйте його і запустіть новий бінарний файл headlamp.

4.4 Примітки щодо доступу в кластері (тримайте в безпеці)

Вважайте інтерфейс користувача в кластері як будь-який інший сервіс, що взаємодіє з кластером. Використовуйте TLS, обмежте доступ до нього і покладайтеся на автентифікацію Kubernetes та RBAC для контролю дій користувачів.

5. Автентифікація та RBAC

Headlamp використовує API Kubernetes так само, як і kubectl. Ваш кластер все ще вирішує, хто що може робити. Headlamp лише показує дії, які дозволені вашій ідентичності.

Цей розділ охоплює два налаштування: для десктопу та для роботи в кластері.

5.1 Desktop: використання kubeconfig

На десктопі Headlamp читає ваш kubeconfig і використовує ті ж облікові дані, що й kubectl. Немає окремого потоку входу з токеном для керування.

Крок 1: Підтвердьте, що ваш kubeconfig працює

Виконайте:

kubectl config current-context

Потім перевірте доступ:

kubectl get nodes

Якщо ви не можете отримати список вузлів, перевірте простір імен, до якого у вас є доступ:

kubectl get pods -n <namespace>

Якщо ці команди працюють, ваш kubeconfig і облікові дані дійсні для Headlamp також.

Крок 2: Вкажіть Headlamp правильний kubeconfig (якщо потрібно)

Headlamp може використовувати стандартний шлях до kubeconfig. Він також може використовувати власний шлях до файлу. Ви можете встановити KUBECONFIG, щоб вибрати конкретний файл.

Приклад:

KUBECONFIG=/path/to/config headlamp

Ви також можете використовувати більше одного файлу kubeconfig одночасно. В системах Unix розділяйте шляхи за допомогою :. У Windows розділяйте шляхи за допомогою ;.

Що очікувати в інтерфейсі користувача

Headlamp адаптується до ваших дозволів RBAC. Якщо у вас немає дозволу редагувати або видаляти ресурс, Headlamp не запропонує ці дії.

5.2 In-cluster: спільний доступ потребує плану входу

In-cluster Headlamp використовується багатьма користувачами. Вам потрібен чіткий план для входу та доступу. Headlamp підтримує OpenID Connect (OIDC) для потоку "Sign in".

Зазвичай ви обираєте один із цих варіантів:

  • A. Налаштуйте Headlamp з OIDC (вбудований).
  • B. Розмістіть шар автентифікації перед Headlamp (поширено на підприємствах).

A. Вбудований OIDC (Headlamp)

Щоб використовувати OIDC, Headlamp потребує:

  • Client ID
  • Client secret
  • Issuer URL
  • (Optional) scopes

Ваш провайдер OIDC також повинен дозволяти URL зворотного виклику Headlamp. URL зворотного виклику — це ваш URL Headlamp плюс:

  • /oidc-callback

Приклад:

  • https://headlamp.example.com/oidc-callback

Примітка щодо Ingress

Якщо Headlamp знаходиться за ingress або балансувальником навантаження, переконайтеся, що він пересилає X-Forwarded-Proto. Якщо ні, Headlamp може згенерувати URL зворотного виклику з http замість https. Це може порушити вхід.

B. Шар автентифікації перед Headlamp

Деякі команди захищають Headlamp за допомогою проксі, що розпізнає особу користувача, або системи автентифікації платформи. Це забезпечує узгоджений вхід у всі інструменти. Документація Headlamp містить приклад використання OpenUnison, який може розгорнути Headlamp з жорсткими стандартними налаштуваннями та інтегруватися з провайдерами ідентифікації.

5.3 RBAC: дотримуйтесь принципу найменших привілеїв

Безпека Kubernetes починається з автентифікації та авторизації API (RBAC). Headlamp дотримується цих правил.

Практичні поради:

  • Почніть з найнижчих дозволів, які все ще дозволяють користувачам виконувати свою роботу.
  • Якщо Dashboard використовував токен службового облікового запису з високими привілеями, плануйте видалити або обмежити цей доступ після переходу.
  • Для in-cluster, розглядайте інтерфейс користувача як будь-яку іншу точку доступу. Використовуйте TLS і обмежуйте доступ до мережі.

5.4 Швидке усунення несправностей

Desktop: "Я не бачу свій кластер"

Ваш kubeconfig може не знаходитися в стандартному місці. Вкажіть Headlamp файл за допомогою KUBECONFIG або шляху до файлу.

In-cluster: "Після перенаправлення не вдається увійти в OIDC"

Підтвердьте, що ваш провайдер дозволяє https://YOUR_URL/oidc-callback. Якщо ви використовуєте ingress, переконайтеся, що він пересилає X-Forwarded-Proto.

6. Керування кількома кластерами

Kubernetes Dashboard зазвичай привʼязаний до одного кластера одночасно. Headlamp створений для роботи з кількома кластерами. Це клієнт, який слідує за вашим kubeconfig, а не встановлення для одного кластера. Це означає, що ви можете тримати один інтерфейс відкритим і перемикатися між кластерами під час роботи.

Кластери беруться з вашого kubeconfig

Headlamp читає кластери з ваших файлів kubeconfig. Це означає, що кластери, до яких ви можете отримати доступ за допомогою kubectl, також можуть показуватися в Headlamp.

Перемикання між кластерами в інтерфейсі

Після завантаження kubeconfig у Headlamp, ви можете перемикатися між кластерами за допомогою селектора кластерів. Це полегшує переміщення між dev, staging та prod без зміни інструментів.

Опціонально: використання більше ніж одного файлу kubeconfig

Якщо у вас є окремі файли kubeconfig, ви можете завантажити їх разом. Headlamp підтримує кілька шляхів до kubeconfig у KUBECONFIG.

Unix/macOS/Linux (: separator):

KUBECONFIG=~/.kube/dev:~/.kube/prod headlamp

Windows (; separator):

$env:KUBECONFIG="$HOME\.kube\dev;$HOME\.kube\prod"

Опціонально: додавання кластера зсередини Headlamp

Ви також можете додавати кластери, завантажуючи додаткові файли kubeconfig з інтерфейсу користувача.

Дозволи залишаються тими ж

Використання Multi-cluster не змінює правила безпеки. Кожен кластер все ще застосовує власний RBAC. Headlamp показує лише те, що ваша ідентичність може робити в обраному кластері.

7. Навігація та розуміння ресурсів

Якщо ви використовували Kubernetes Dashboard, ця частина буде знайома. Headlamp зберігає ті ж основні перегляди ресурсів, але робить легшим переміщення та розуміння того, що підключено.

Знаходження ресурсів у знайомих місцях

Headlamp групує ресурси таким чином, що це близько до Dashboard:

  • Workloads для Pods, Deployments, StatefulSets та Jobs
  • Network для Services та Ingress
  • Storage для PersistentVolumes та Claims
  • Configuration для ConfigMaps та Secrets
  • Nodes для інфраструктури кластера

Ви можете фільтрувати за простором імен у верхній частині інтерфейсу, так само як у Dashboard.

Перегляд та редагування ресурсів

З будь-якого списку ви можете натиснути на ресурс, щоб побачити деталі:

  • Статус та стан
  • Події
  • Мітки та анотації
  • Повна YAML-версія

Якщо ваш RBAC дозволяє, ви можете редагувати YAML безпосередньо з інтерфейсу. Якщо ні, Headlamp показує ресурс лише для читання. Це відповідає поведінці kubectl.

Використання пошуку та фільтрів для швидшої роботи

Headlamp додає швидший пошук та фільтри у списках. Це допомагає, коли кластери або простори імен стають великими. Ви можете звужувати перегляди без переходу між сторінками.

Розуміння взаємозвʼязків за допомогою Map View

Dashboard в основному показує ресурси у вигляді списків. Headlamp також включає Map View.

Map View показує, як ресурси взаємоповʼязані:

  • Deployments
  • ReplicaSets
  • Pods
  • Services

Це допомагає під час усунення несправностей. Замість того, щоб переходити через кілька сторінок, ви можете бачити звʼязки одразу. Ви можете швидше виявити відсутні або порушені взаємозвʼязки.

Коли використовувати списки, а коли Map View

  • Використовуйте списки, коли ви знаєте, який ресурс шукаєте.
  • Використовуйте Map View, коли ви намагаєтеся зрозуміти, чому щось не працює.

Обидва перегляди працюють з одними й тими ж даними. Ви просто обираєте, скільки контексту вам потрібно в даний момент.

8. Розгортання застосунків за допомогою YAML

Цей момент є найбільшою зміною для більшості користувачів Kubernetes Dashboard. Dashboard покладався на форми. Headlamp покладається на маніфести. Мета не в тому, щоб уповільнити вас. Мета — узгодити інтерфейс користувача з тим, як Kubernetes зазвичай працює на практиці.

Від форм до маніфестів

У Kubernetes Dashboard ви часто розгортали застосунок, заповнюючи форму:

  • образ контейнера
  • кількість реплік
  • тип сервісу

Headlamp не включає той самий майстер. Замість цього він дозволяє застосовувати YAML безпосередньо з інтерфейсу. Це відповідає тому, як більшість команд виконують розгортання сьогодні:

  • маніфести зберігаються в Git
  • CI/CD застосовує їх
  • Helm або інструменти GitOps керують змінами

Headlamp вписується в цей процес, а не замінює його.

Створення ресурсів за допомогою YAML

Щоб розгорнути застосунок у Headlamp:

  1. Виберіть кластер і простір імен.
  2. Натисніть Створити.
  3. Вставте або завантажте YAML-маніфест.
  4. Перегляньте його.
  5. Натисніть Застосувати.
Кнопка Створити

Кнопка Створити

Ресурс зʼявляється негайно в інтерфейсі.

Якщо маніфест недійсний, Headlamp показує ті самі помилки, які ви б побачили від Kubernetes API.

Генерація YAML простим способом

Якщо вам не вистачає майстра Dashboard, ви все ще можете швидко згенерувати YAML.

Наприклад:

kubectl create deployment nginx \
  --image=nginx \
  --dry-run=client \
  -o yaml > nginx.yaml

Ви можете відредагувати файл за потреби, а потім вставити його в Headlamp і застосувати. Це дає вам повторюваний маніфест замість обʼєкта, створеного лише через інтерфейс користувача.

Що робити, якщо ви використовуєте Helm або GitOps?

Це добре працює з Headlamp.

  • Встановлюйте за допомогою Helm як зазвичай.
  • Розгортайте за допомогою GitOps-конвеєрів як зазвичай.
  • Використовуйте Headlamp для перегляду, інспекції та налагодження того, що працює.

Headlamp не замінює ці інструменти. Він дає вам видимість того, що вони створюють.

Чого очікувати порівняно з Dashboard

  • Ви не побачите багатокрокову форму розгортання.
  • Ви будете більше працювати з YAML.
  • Ви отримаєте ясність щодо того, що фактично застосовується до кластера.
  • Той самий маніфест можна повторно використовувати в CI, Git або інших інструментах.

9. Розгортання та налагодження робочих навантажень

Однією з основних причин, чому люди використовували Kubernetes Dashboard, було щоденне налагодження. Headlamp охоплює ті самі завдання і додає кілька корисних покращень.

Перегляд журналів

Ви можете переглядати журнали подів безпосередньо в інтерфейсі користувача.

Щоб перевірити журнали:

  1. Відкрийте Workloads.
  2. Виберіть Pods.
  3. Натисніть на под.
  4. Відкрийте вкладку Logs.
Інтерфейс Workloads

Інтерфейс Workloads

Якщо под має більше одного контейнера, ви можете перемикатися між контейнерами. Журнали транслюються в реальному часі, що допомагає під час розгортання або активних інцидентів.

Виконання команд у запущених подах

Headlamp також дозволяє відкрити оболонку всередині контейнера.

З перегляду пода:

  • Відкрийте меню дій пода.
  • Виберіть Terminal або Exec.

Це призведе до відкриття інтерактивної сесії всередині контейнера. Це замінює необхідність повертатися до терміналу для швидких перевірок.

Ця дія дотримується правил RBAC. Якщо ви не можете виконати kubectl exec, Headlamp також не дозволить це зробити.

Перевірка метрик та використання ресурсів

Headlamp може показувати використання CPU та памʼяті для подів і вузлів. Це працює так само, як і в Dashboard.

Декілька речей, які варто знати:

  • Метрики вимагають встановлення metrics-server у кластері.
  • Якщо метрики відсутні, Headlamp показує чітке повідомлення.
  • Після того як метрики стануть доступними, використання показується на сторінках подів і вузлів.

Це дозволяє легко відповісти на прості запитання:

  • Чи використовує цей под занадто багато памʼяті?
  • Чи знаходиться вузол під тиском навантаження?

Перегляд подій при виникненні проблем

Події часто є найшвидшим способом зрозуміти причини збоїв.

У Headlamp ви можете:

  • Переглядати події на сторінках деталей ресурсів.
  • Бачити попередження та помилки, повʼязані з подами, вузлами або розгортаннями.

Це часто перше місце, куди варто звернутися, коли робоче навантаження застрягає або аварійно завершується.

Як це в порівнянні з Dashboard

Що залишається без змін:

  • Перегляд журналів
  • Перегляд подій
  • Дії, що враховують RBAC

Що покращується:

  • Вбудовані сесії exec
  • Чіткіше розташування та фільтрація
  • Менше перемикань між UI та CLI

10. Видалення Kubernetes Dashboard

Після того як Headlamp працює і ваша команда звикла до нього, ви можете видалити Kubernetes Dashboard. Це останній крок очищення.

Видалення Dashboard зменшує безлад і запобігає збереженню невикористовуваних шляхів доступу.

Підтвердження, що Headlamp відповідає вашим потребам

Перед видаленням будь-чого переконайтеся, що:

  • Користувачі можуть отримати доступ до потрібних кластерів у Headlamp.
  • Основні завдання працюють:
    • перегляд ресурсів
    • розгортання за допомогою YAML
    • перегляд журналів та подій
    • виконання команд у подах (якщо дозволено)
  • RBAC працює відповідно до очікувань для різних ролей.

Після того як ці перевірки пройдено, ви готові видалити Dashboard.

Видалення Dashboard

Якщо ви встановили Kubernetes Dashboard за допомогою Helm, видаліть його за допомогою:

helm uninstall kubernetes-dashboard -n kubernetes-dashboard

Якщо Dashboard був встановлений за допомогою манифесту або надбудови, видаліть його, використовуючи той самий метод, який ви використовували для його встановлення.

Після видалення переконайтеся, що ресурси зникли:

kubectl get pods -n kubernetes-dashboard

Багато налаштувань Dashboard використовували виділені службові облікові записи та ролі на рівні кластера.

Перегляньте та видаліть усе, що було створено лише для доступу до Dashboard, наприклад:

  • службові облікові записи
  • привʼязки ролей або привʼязки ролей кластера
  • стара документація, яка вказує користувачам на URL-адреси Dashboard або команди port-forward

Це зменшує кількість довготривалих облікових даних та невикористовуваних дозволів.

Повідомлення про зміни

Переконайтеся, що ваша команда знає:

  • Headlamp тепер є основним інтерфейсом Kubernetes.
  • Як отримати до нього доступ (настільний додаток або URL).
  • Куди звертатися за допомогою, якщо щось виглядає інакше.

11. Контрольний список після міграції

Цей фінальний контрольний список допоможе вам переконатися, що міграція завершена. Він дає впевненість, що Headlamp працює належним чином і що нічого важливого не залишилося поза увагою.

Доступ та видимість

  • Headlamp відкривається без помилок.
  • Користувачі можуть отримати доступ до правильних кластерів.
  • Фільтрація за просторами імен працює належним чином.
  • Перемикання між кластерами працює правильно.

Автентифікація та RBAC

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

Основні робочі процеси

  • Ресурси завантажуються у Workloads, Network та Configuration.
  • YAML можна переглядати та редагувати там, де дозволяють права.
  • Застосунки можна розгортати за допомогою Create та YAML.
  • Логи завантажуються правильно для запущених подів.
  • Exec працює для користувачів, яким дозволено його використовувати.
  • Метрики зʼявляються, якщо встановлено metrics-server.

Операційна впевненість

  • Команди можуть усувати несправності без перемикання інструментів.
  • Map View допомагає пояснити взаємозвʼязки під час налагодження.
  • Platform або DevOps команди знають, як встановлюється та керується Headlamp.

Підтвердження очищення

  • Kubernetes Dashboard більше не працює.
  • Службові облікові записи і привʼязки RBAC, призначені лише для Dashboard, видалені.
  • Внутрішня документація більше не містить посилань на URL-адреси Dashboard або команди port-forward.

Узгодження з командою

  • Команда знає, що Headlamp є стандартним інтерфейсом Kubernetes.
  • Документація для новачків вказує новим користувачам на Headlamp.
  • Існує чіткий шлях для зворотного звʼязку або запитань.

Ось ви завершили перехід з Kubernetes Dashboard на Headlamp. Ваша команда може використовувати ту ж модель доступу до Kubernetes, працювати з різними кластерами та покладатися на робочі процеси, які відповідають сучасному використанню Kubernetes. Відтепер Headlamp стає вашим стандартним інтерфейсом, як на робочому столі, так і в спільних середовищах. Зі зростанням ваших потреб ви можете продовжувати використовувати його в поточному вигляді або розширювати за допомогою втулків та нових компонентів.

Якщо ви хочете допомогти формувати майбутнє Headlamp, приєднуйтесь до спільноти Headlamp і робіть внесок на headlamp.dev.

Це дзеркало оригінальної статті.

Востаннє змінено July 15, 2026 at 12:45 AM PST: [uk] Ukrainian translation (all-in-one) (193b0d4ea4)