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

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

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

Робочий стіл

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

У кластері

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

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

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

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

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

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

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

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

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

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

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

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

• Адміністратори кластера керують встановленням, оновленнями та конфігурацією через Helm-чарт та стандартні інструменти 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-маніфест, який ви можете застосувати, а потім налаштувати відповідно до ваших потреб.

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

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

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 у 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 Робочий стіл: використання 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 У кластері: спільний доступ потребує плану входу

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

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

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

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

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

• Ідентифікатор клієнта (Client ID)
• Секрет клієнта (Client secret)
• URL видавця (Issuer URL)
• (Необовʼязково) області доступу (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 використовував токен службового облікового запису з високими привілеями, плануйте видалити або обмежити цей доступ після переходу.
• Для варіанта в кластері ставтеся до інтерфейсу користувача як до будь-якої іншої точки доступу. Використовуйте TLS і обмежуйте мережевий доступ.

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

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

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

У кластері: "Після перенаправлення не вдається увійти в 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 (роздільник :):

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

Windows (роздільник ;):

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

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

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

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

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

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

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

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

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

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

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

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

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

• Статус і стани (conditions)
• Події
• Мітки та анотації
• Повне визначення в 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. Натисніть Create.
3. Вставте або завантажте YAML-маніфест.
4. Перегляньте його.
5. Натисніть Apply.

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

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

Генерація 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 охоплює ті самі завдання і додає кілька корисних покращень.

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

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

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

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

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

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

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

Зі сторінки Podʼа:

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

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

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

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

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

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

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

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

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

Перегляд подій, коли щось пішло не так

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

У Headlamp ви можете:

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

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

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

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

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

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

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

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

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

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

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

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

• Користувачі можуть отримати доступ до потрібних кластерів у Headlamp.
• Основні завдання працюють:
  • перегляд ресурсів
  • розгортання за допомогою YAML
  • перегляд журналів та подій
  • виконання команд у Podʼах (якщо дозволено)
• 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

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

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

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

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

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

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

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

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

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

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

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

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

• ←Попередня
• Наступна→