# Від Kubernetes Dashboard до Headlamp: покроковий посібник LLMS index: [llms.txt](/llms.txt) --- ## 1. До того, як почати: що змінюється {#1-before-you-start-know-what-is-changing} Kubernetes Dashboard та Headlamp обидва показують, що працює в кластері, але вони працюють по-різному. Коли Headlamp запускається на робочому столі, він використовує ваш наявний kubeconfig для підключення до одного або кількох кластерів і може бути розширений втулками. Коли Headlamp запускається всередині кластера, він використовує Kubernetes ServiceAccount для доступу до API та дотримання правил RBAC. Kubernetes Dashboard, навпаки, працює лише всередині кластера і завжди покладається на токени службового облікового запису. Розуміння цих моделей на ранньому етапі допомагає вибрати правильну конфігурацію та дозволи. ### 1.1 Як працює Kubernetes Dashboard {#1-1-how-kubernetes-dashboard-works} Dashboard — це вебзастосунок, який працює всередині вашого кластера. - Ви встановлюєте його в кластері, часто за допомогою Helm. - Зазвичай ви запускаєте один Dashboard на кластер. - Часто ви отримуєте доступ до нього через `kubectl port-forward` або ingress. - Ви входите за допомогою токена на предʼявника. Цей токен часто походить від службового облікового запису. - Він включає форми, які допомагають створювати ресурси. - Він спирається на таблиці та списки для навігації. Відчуття таке: інтерфейс користувача, який живе разом із кластером. ### 1.2 Як працює Headlamp {#1-2-how-headlamp-works} Headlamp діє більше як клієнт Kubernetes з інтерфейсом користувача. - Він може працювати на вашому робочому столі або в кластері. - Він читає ваш kubeconfig, як це робить kubectl. - Він може показувати більше одного кластера в одному місці. - Він віддає перевагу YAML при створенні або зміні ресурсів. - Він включає списки та візуальну мапу. - Ви можете додавати функції за допомогою втулків. Headlamp — це інтерфейс користувача, який слідує за вашою ідентичністю, а не за кластером. ### 1.3 Що залишається без змін {#1-3-what-stays-the-same} Більшість робочих процесів залишаться знайомими: - Перегляд робочих навантажень та ресурсів - Фільтрація за простором імен - Перегляд YAML, подій та стану - Перегляд журналів - Виконання дій, дозволених вашим RBAC ### 1.4 Що змінюється {#1-4-what-changes} Деякі речі будуть відчуватися інакше: - Вхід змінюється з вставлених токенів на kubeconfig (а іноді і SSO). - Створення змінюється з заповнення форм на "застосування YAML". - Багатокластерність стає нормою, а не особливим випадком. - Візуальна мапа допомагає бачити, як повʼязані ресурси. ## 2. Перевірка перед міграцією {#2-pre-migration-checklist} Цей контрольний список допоможе уникнути неприємних сюрпризів під час переходу. Він гарантує, що Headlamp може використовувати ту ж ідентичність та дозволи, яким ви вже довіряєте в Kubernetes. Він також дає швидкий спосіб перевірити, чи працює міграція, перш ніж вимкнути Dashboard. ### 2.1 Запишіть, що ви використовуєте сьогодні {#2-1-write-down-what-you-use-today} Перелічіть основне: - Які кластери ви використовуєте (dev, staging, prod) - Які простори імен ви використовуєте найчастіше - Що ви робите найчастіше (перегляд, редагування, масштабування, видалення, налагодження) - Як ви отримуєте доступ до Dashboard сьогодні (port-forward або ingress) - Як ви входите (токен службового облікового запису та які RBAC-приʼязки) Це ваша відправна точка. ### 2.2 Перевірте, чи працює kubeconfig {#2-2-check-that-kubeconfig-works} Headlamp використовує kubeconfig, особливо на робочому столі. Переконайтеся, що ваш працює, перш ніж встановлювати будь-що. Запустіть: ```shell kubectl config current-context ``` Потім спробуйте: ```shell kubectl get nodes ``` Якщо ви не можете вивести список вузлів, спробуйте це зробтити в просторі імен, до якого у вас є доступ: ```shell kubectl get pods -n ``` Якщо ці команди працюють, Headlamp може використовувати ту ж ідентичність та RBAC. ### 2.3 Виберіть план розгортання {#2-3-pick-a-rollout-plan} Немає потреби поспішати. Більшість команд обирають один з цих варіантів: **Паралельне розгортання (рекомендовано)** - Встановіть Headlamp - Дайте людям спробувати його - Залиште Dashboard на короткий час - Видаліть Dashboard після того, як команда буде готова **Перемикання** - Встановіть Headlamp - Перемкніть документацію та посилання - Видаліть Dashboard незабаром після цього Паралельне розгортання безпечніше для спільних кластерів. ### 2.4 Виберіть, де буде працювати Headlamp {#2-4-decide-where-headlamp-will-run} Ви можете використовувати будь-який варіант. Багато команд використовують обидва. **Desktop** - Використовує ваш kubeconfig - Не використовує ресурси кластера - Не потребує port-forward - Багатокластерність працює з коробки **В кластері** - Працює добре для спільного доступу через оглядач - Може керуватися як інші застосунки в кластері - Часто використовується разом з ingress та SSO ### 2.5 Зверніть увагу на необовʼязкові залежності {#2-5-note-optional-dependencies} Це поширені залежності. Ви можете налаштувати їх пізніше. - `metrics-server` (для графіків використання CPU та памʼяті) - ingress (для URL всередині кластера) - OIDC / SSO (для входу через оглядач) - очищення старих службових облікових записів Dashboard та RBAC ## 3. Виберіть, де буде працювати Headlamp (робочий стіл або в кластері) {#3-choose-where-headlamp-will-run-desktop-or-in-cluster} Headlamp може працювати на вашому робочому столі або всередині кластера. Обидва варіанти добре працюють, але вони підходять для різних потреб. Робочий стіл — найшвидший спосіб почати, оскільки він використовує ваш kubeconfig і не працює в кластері. В кластері краще, коли потрібен спільний URL і ви хочете, щоб команда платформи керувала оновленнями та доступом. ### Варіант A: Desktop (керується користувачем) {#option-a-desktop-user-managed} Desktop Headlamp запускається на кожному компʼютері користувача. Він читає той самий kubeconfig, який ви використовуєте з kubectl. Це дозволяє доступ, привʼязаний до ідентичності та RBAC кожного користувача. **Чому команди обирають цей варіант** - Немає сервісу в кластері для розгортання або відкриття. - Не використовує ресурси кластера (CPU або памʼять). - Використовує ваш kubeconfig і RBAC. - Працює з багатьма кластерами в одному застосунку. - Не потребує port-forward для щоденного використання. ### Варіант B: In-cluster (найкраще для спільного доступу) {#option-b-in-cluster-best-for-shared-access} In-cluster Headlamp встановлюється як робоче навантаження Kubernetes (часто через Helm). Це дозволяє адміністраторам кластера керувати ним як іншими застосунками в кластері. - Адміністратори кластера керують встановленням, оновленнями та конфігурацією через Helm chart та стандартні інструменти Kubernetes. - Адміністратори контролюють ingress і можуть налаштувати вхід через OIDC для спільного доступу. - Підтримує спільне використання в командних середовищах. ## 4. Встановлення Headlamp (робочий стіл та в кластері) {#4-install-headlamp-desktop-and-in-cluster} Цей розділ допоможе запустити Headlamp. Дотримуйтесь шляху, який ви обрали в Розділі 3. ### 4.1 Встановлення на робочий стіл (найшвидший спосіб почати) {#4-1-desktop-install-fastest-way-to-start} Встановіть Headlamp на вашому компʼютері. Потім відкрийте його як будь-який інший застосунок. Headlamp читає ваш kubeconfig і використовує ті ж правила ідентичності та RBAC, що й kubectl. **Windows** Встановлення за допомогою WinGet: ```shell winget install headlamp ``` Або з Chocolatey: ```shell choco install headlamp ``` **macOS** Встановлення за допомогою Homebrew: ```shell brew install --cask headlamp ``` **Linux** Встановлення за допомогою Flatpak (Flathub): ```shell flatpak install flathub io.kinvolk.Headlamp ``` **Швидка перевірка** 1. Запустіть Headlamp. 2. Підтвердьте, що ви бачите контекст кластера. 3. Відкрийте простір імен, до якого у вас є доступ, і підтвердьте, що ви можете переглядати робочі навантаження. Headlamp покаже лише ті дії, на які дозволяє ваш RBAC. ### 4.2 Встановлення в кластері (спільний доступ) {#4-2-in-cluster-install-shared-access} Використовуйте цей шлях, якщо ви хочете спільний інтерфейс, яким може керувати команда платформи. Headlamp підтримує розгортання в кластері за допомогою Helm або YAML-манифесту. **Встановлення за допомогою Helm** Додайте репозиторій і оновіть його: ```shell helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/ helm repo update ``` Створіть простір імен (приклад): ```shell kubectl create namespace headlamp ``` Встановіть чарт: ```shell helm install headlamp headlamp/headlamp --namespace headlamp ``` **Встановлення за допомогою YAML-манифесту (опціонально)** Headlamp також надає YAML-манифест, який ви можете застосувати, а потім налаштувати відповідно до ваших потреб. **Перевірка встановлення** Підтвердьте, що под запущений: ```shell kubectl get pods -n headlamp ``` Підтвердьте, що сервіс існує: ```shell kubectl get svc -n headlamp ``` **Доступ до нього (два поширені способи)** _Швидка перевірка за допомогою port-forward_ Це найшвидший спосіб перевірити, чи працює сервіс: ```shell kubectl port-forward -n headlamp svc/headlamp 8080:80 ``` Потім відкрийте: _Спільний доступ через ingress_ Якщо ви хочете мати стабільний URL, відкрийте сервіс через ваш ingress-контролер. Точний YAML для ingress залежить від вашої конфігурації. URL для OIDC callback у Headlamp — це ваш публічний URL плюс `/oidc-callback`, тому налаштування ingress і TLS мають значення. ### 4.3 Оновлення Headlamp {#4-3-updating-headlamp} Оновлення залежить від того, як ви встановили Headlamp. Менеджери пакунків оновлюють застосунок на місці. Встановлення через DMG або EXE оновлюється шляхом повторного встановлення нової версії. **macOS** Якщо ви встановили за допомогою Homebrew, виконайте: ```shell brew upgrade headlamp ``` Якщо ви встановили з DMG, завантажте новий DMG і перетягніть Headlamp у `/Applications`, замінивши стару версію. Встановлення через DMG не оновлюється автоматично. **Windows** Якщо ви встановили за допомогою WinGet, виконайте: ```shell winget upgrade headlamp ``` Якщо ви встановили за допомогою Chocolatey, виконайте: ```shell choco upgrade headlamp ``` Якщо ви встановили з EXE, завантажте новий інсталятор і запустіть його знову. Встановлення через EXE не оновлюється автоматично. **Linux** Якщо ви встановили за допомогою Flatpak, виконайте: ```shell flatpak update io.kinvolk.Headlamp ``` Якщо ви встановили за допомогою AppImage, завантажте новий AppImage і запустіть цей файл замість старого. Якщо ви встановили за допомогою tarball, завантажте новий tarball, розпакуйте його і запустіть новий бінарний файл headlamp. ### 4.4 Примітки щодо доступу в кластері (тримайте в безпеці) {#4-4-notes-for-in-cluster-access-keep-it-safe} Вважайте інтерфейс користувача в кластері як будь-який інший сервіс, що взаємодіє з кластером. Використовуйте TLS, обмежте доступ до нього і покладайтеся на автентифікацію Kubernetes та RBAC для контролю дій користувачів. ## 5. Автентифікація та RBAC {#5-authentication-and-rbac} Headlamp використовує API Kubernetes так само, як і kubectl. Ваш кластер все ще вирішує, хто що може робити. Headlamp лише показує дії, які дозволені вашій ідентичності. Цей розділ охоплює два налаштування: для десктопу та для роботи в кластері. ### 5.1 Desktop: використання kubeconfig {#5-1-desktop-use-kubeconfig} На десктопі Headlamp читає ваш kubeconfig і використовує ті ж облікові дані, що й kubectl. Немає окремого потоку входу з токеном для керування. **Крок 1: Підтвердьте, що ваш kubeconfig працює** Виконайте: ```shell kubectl config current-context ``` Потім перевірте доступ: ```shell kubectl get nodes ``` Якщо ви не можете отримати список вузлів, перевірте простір імен, до якого у вас є доступ: ```shell kubectl get pods -n ``` Якщо ці команди працюють, ваш kubeconfig і облікові дані дійсні для Headlamp також. **Крок 2: Вкажіть Headlamp правильний kubeconfig (якщо потрібно)** Headlamp може використовувати стандартний шлях до kubeconfig. Він також може використовувати власний шлях до файлу. Ви можете встановити `KUBECONFIG`, щоб вибрати конкретний файл. Приклад: ```shell KUBECONFIG=/path/to/config headlamp ``` Ви також можете використовувати більше одного файлу kubeconfig одночасно. В системах Unix розділяйте шляхи за допомогою `:`. У Windows розділяйте шляхи за допомогою `;`. **Що очікувати в інтерфейсі користувача** Headlamp адаптується до ваших дозволів RBAC. Якщо у вас немає дозволу редагувати або видаляти ресурс, Headlamp не запропонує ці дії. ### 5.2 In-cluster: спільний доступ потребує плану входу {#5-2-in-cluster-shared-access-needs-a-sign-in-plan} 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: дотримуйтесь принципу найменших привілеїв {#5-3-rbac-keep-it-least-privilege} Безпека Kubernetes починається з автентифікації та авторизації API (RBAC). Headlamp дотримується цих правил. Практичні поради: - Почніть з найнижчих дозволів, які все ще дозволяють користувачам виконувати свою роботу. - Якщо Dashboard використовував токен службового облікового запису з високими привілеями, плануйте видалити або обмежити цей доступ після переходу. - Для in-cluster, розглядайте інтерфейс користувача як будь-яку іншу точку доступу. Використовуйте TLS і обмежуйте доступ до мережі. ### 5.4 Швидке усунення несправностей {#5-4-quick-troubleshooting} **Desktop: "Я не бачу свій кластер"** Ваш kubeconfig може не знаходитися в стандартному місці. Вкажіть Headlamp файл за допомогою `KUBECONFIG` або шляху до файлу. **In-cluster: "Після перенаправлення не вдається увійти в OIDC"** Підтвердьте, що ваш провайдер дозволяє `https://YOUR_URL/oidc-callback`. Якщо ви використовуєте ingress, переконайтеся, що він пересилає `X-Forwarded-Proto`. ## 6. Керування кількома кластерами {#6-managing-multiple-clusters} Kubernetes Dashboard зазвичай привʼязаний до одного кластера одночасно. Headlamp створений для роботи з кількома кластерами. Це клієнт, який слідує за вашим kubeconfig, а не встановлення для одного кластера. Це означає, що ви можете тримати один інтерфейс відкритим і перемикатися між кластерами під час роботи. ### Кластери беруться з вашого kubeconfig {#clusters-come-from-your-kubeconfig} Headlamp читає кластери з ваших файлів kubeconfig. Це означає, що кластери, до яких ви можете отримати доступ за допомогою kubectl, також можуть показуватися в Headlamp. ### Перемикання між кластерами в інтерфейсі {#switch-clusters-in-the-ui} Після завантаження kubeconfig у Headlamp, ви можете перемикатися між кластерами за допомогою селектора кластерів. Це полегшує переміщення між dev, staging та prod без зміни інструментів. ### Опціонально: використання більше ніж одного файлу kubeconfig {#optional-use-more-than-one-kubeconfig-file} Якщо у вас є окремі файли kubeconfig, ви можете завантажити їх разом. Headlamp підтримує кілька шляхів до kubeconfig у `KUBECONFIG`. Unix/macOS/Linux (`:` separator): ```shell KUBECONFIG=~/.kube/dev:~/.kube/prod headlamp ``` Windows (`;` separator): ```powershell $env:KUBECONFIG="$HOME\.kube\dev;$HOME\.kube\prod" ``` ### Опціонально: додавання кластера зсередини Headlamp {#optional-add-a-cluster-from-inside-headlamp} Ви також можете додавати кластери, завантажуючи додаткові файли kubeconfig з інтерфейсу користувача. ### Дозволи залишаються тими ж {#permissions-stay-the-same} Використання Multi-cluster не змінює правила безпеки. Кожен кластер все ще застосовує власний RBAC. Headlamp показує лише те, що ваша ідентичність може робити в обраному кластері. ## 7. Навігація та розуміння ресурсів {#7-navigate-and-understand-resources} Якщо ви використовували Kubernetes Dashboard, ця частина буде знайома. Headlamp зберігає ті ж основні перегляди ресурсів, але робить легшим переміщення та розуміння того, що підключено. ### Знаходження ресурсів у знайомих місцях {#find-resources-in-familiar-places} Headlamp групує ресурси таким чином, що це близько до Dashboard: - **Workloads** для Pods, Deployments, StatefulSets та Jobs - **Network** для Services та Ingress - **Storage** для PersistentVolumes та Claims - **Configuration** для ConfigMaps та Secrets - **Nodes** для інфраструктури кластера Ви можете фільтрувати за простором імен у верхній частині інтерфейсу, так само як у Dashboard. ### Перегляд та редагування ресурсів {#inspect-and-edit-resources} З будь-якого списку ви можете натиснути на ресурс, щоб побачити деталі: - Статус та стан - Події - Мітки та анотації - Повна YAML-версія Якщо ваш RBAC дозволяє, ви можете редагувати YAML безпосередньо з інтерфейсу. Якщо ні, Headlamp показує ресурс лише для читання. Це відповідає поведінці kubectl. ### Використання пошуку та фільтрів для швидшої роботи {#use-search-and-filters-to-move-faster} Headlamp додає швидший пошук та фільтри у списках. Це допомагає, коли кластери або простори імен стають великими. Ви можете звужувати перегляди без переходу між сторінками. ### Розуміння взаємозвʼязків за допомогою Map View {#understand-relationships-with-map-view} Dashboard в основному показує ресурси у вигляді списків. Headlamp також включає Map View. Map View показує, як ресурси взаємоповʼязані: - Deployments - ReplicaSets - Pods - Services Це допомагає під час усунення несправностей. Замість того, щоб переходити через кілька сторінок, ви можете бачити звʼязки одразу. Ви можете швидше виявити відсутні або порушені взаємозвʼязки. ### Коли використовувати списки, а коли Map View {#when-to-use-lists-vs-map-view} - Використовуйте **списки**, коли ви знаєте, який ресурс шукаєте. - Використовуйте **Map View**, коли ви намагаєтеся зрозуміти, чому щось не працює. Обидва перегляди працюють з одними й тими ж даними. Ви просто обираєте, скільки контексту вам потрібно в даний момент. ## 8. Розгортання застосунків за допомогою YAML {#8-deploying-applications-with-yaml} Цей момент є найбільшою зміною для більшості користувачів Kubernetes Dashboard. Dashboard покладався на форми. Headlamp покладається на маніфести. Мета не в тому, щоб уповільнити вас. Мета — узгодити інтерфейс користувача з тим, як Kubernetes зазвичай працює на практиці. ### Від форм до маніфестів {#from-forms-to-manifests} У Kubernetes Dashboard ви часто розгортали застосунок, заповнюючи форму: - образ контейнера - кількість реплік - тип сервісу Headlamp не включає той самий майстер. Замість цього він дозволяє застосовувати YAML безпосередньо з інтерфейсу. Це відповідає тому, як більшість команд виконують розгортання сьогодні: - маніфести зберігаються в Git - CI/CD застосовує їх - Helm або інструменти GitOps керують змінами Headlamp вписується в цей процес, а не замінює його. ### Створення ресурсів за допомогою YAML {#create-resources-using-yaml} Щоб розгорнути застосунок у Headlamp: 1. Виберіть кластер і простір імен. 2. Натисніть **Створити**. 3. Вставте або завантажте YAML-маніфест. 4. Перегляньте його. 5. Натисніть **Застосувати**.
Кнопка Створити

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

Ресурс зʼявляється негайно в інтерфейсі. Якщо маніфест недійсний, Headlamp показує ті самі помилки, які ви б побачили від Kubernetes API. ### Генерація YAML простим способом {#generate-yaml-the-easy-way} Якщо вам не вистачає майстра Dashboard, ви все ще можете швидко згенерувати YAML. Наприклад: ```shell kubectl create deployment nginx \ --image=nginx \ --dry-run=client \ -o yaml > nginx.yaml ``` Ви можете відредагувати файл за потреби, а потім вставити його в Headlamp і застосувати. Це дає вам повторюваний маніфест замість обʼєкта, створеного лише через інтерфейс користувача. ### Що робити, якщо ви використовуєте Helm або GitOps? {#what-if-you-use-helm-or-gitops} Це добре працює з Headlamp. - Встановлюйте за допомогою Helm як зазвичай. - Розгортайте за допомогою GitOps-конвеєрів як зазвичай. - Використовуйте Headlamp для перегляду, інспекції та налагодження того, що працює. Headlamp не замінює ці інструменти. Він дає вам видимість того, що вони створюють. ### Чого очікувати порівняно з Dashboard {#what-to-expect-compared-to-dashboard} - Ви не побачите багатокрокову форму розгортання. - Ви будете більше працювати з YAML. - Ви отримаєте ясність щодо того, що фактично застосовується до кластера. - Той самий маніфест можна повторно використовувати в CI, Git або інших інструментах. ## 9. Розгортання та налагодження робочих навантажень {#9-deploy-and-debug-workloads} Однією з основних причин, чому люди використовували Kubernetes Dashboard, було щоденне налагодження. Headlamp охоплює ті самі завдання і додає кілька корисних покращень. ### Перегляд журналів {#view-logs} Ви можете переглядати журнали подів безпосередньо в інтерфейсі користувача. Щоб перевірити журнали: 1. Відкрийте **Workloads**. 2. Виберіть **Pods**. 3. Натисніть на под. 4. Відкрийте вкладку **Logs**.
Інтерфейс Workloads

Інтерфейс Workloads

Якщо под має більше одного контейнера, ви можете перемикатися між контейнерами. Журнали транслюються в реальному часі, що допомагає під час розгортання або активних інцидентів. ### Виконання команд у запущених подах {#exec-into-running-pods} Headlamp також дозволяє відкрити оболонку всередині контейнера. З перегляду пода: - Відкрийте меню дій пода. - Виберіть **Terminal** або **Exec**. Це призведе до відкриття інтерактивної сесії всередині контейнера. Це замінює необхідність повертатися до терміналу для швидких перевірок. Ця дія дотримується правил RBAC. Якщо ви не можете виконати `kubectl exec`, Headlamp також не дозволить це зробити. ### Перевірка метрик та використання ресурсів {#check-metrics-and-resource-usage} Headlamp може показувати використання CPU та памʼяті для подів і вузлів. Це працює так само, як і в Dashboard. Декілька речей, які варто знати: - Метрики вимагають встановлення `metrics-server` у кластері. - Якщо метрики відсутні, Headlamp показує чітке повідомлення. - Після того як метрики стануть доступними, використання показується на сторінках подів і вузлів. Це дозволяє легко відповісти на прості запитання: - Чи використовує цей под занадто багато памʼяті? - Чи знаходиться вузол під тиском навантаження? ### Перегляд подій при виникненні проблем {#view-events-when-things-go-wrong} Події часто є найшвидшим способом зрозуміти причини збоїв. У Headlamp ви можете: - Переглядати події на сторінках деталей ресурсів. - Бачити попередження та помилки, повʼязані з подами, вузлами або розгортаннями. Це часто перше місце, куди варто звернутися, коли робоче навантаження застрягає або аварійно завершується. ### Як це в порівнянні з Dashboard {#how-this-compares-to-dashboard} **Що залишається без змін:** - Перегляд журналів - Перегляд подій - Дії, що враховують RBAC **Що покращується:** - Вбудовані сесії exec - Чіткіше розташування та фільтрація - Менше перемикань між UI та CLI ## 10. Видалення Kubernetes Dashboard {#10-remove-kubernetes-dashboard} Після того як Headlamp працює і ваша команда звикла до нього, ви можете видалити Kubernetes Dashboard. Це останній крок очищення. Видалення Dashboard зменшує безлад і запобігає збереженню невикористовуваних шляхів доступу. ### Підтвердження, що Headlamp відповідає вашим потребам {#confirm-headlamp-covers-your-needs} Перед видаленням будь-чого переконайтеся, що: - Користувачі можуть отримати доступ до потрібних кластерів у Headlamp. - Основні завдання працюють: - перегляд ресурсів - розгортання за допомогою YAML - перегляд журналів та подій - виконання команд у подах (якщо дозволено) - RBAC працює відповідно до очікувань для різних ролей. Після того як ці перевірки пройдено, ви готові видалити Dashboard. ### Видалення Dashboard {#uninstall-the-dashboard} Якщо ви встановили Kubernetes Dashboard за допомогою Helm, видаліть його за допомогою: ```shell helm uninstall kubernetes-dashboard -n kubernetes-dashboard ``` Якщо Dashboard був встановлений за допомогою манифесту або надбудови, видаліть його, використовуючи той самий метод, який ви використовували для його встановлення. Після видалення переконайтеся, що ресурси зникли: ```shell kubectl get pods -n kubernetes-dashboard ``` ### Очищення артефактів доступу (рекомендовано) {#clean-up-access-artifacts-recommended} Багато налаштувань Dashboard використовували виділені службові облікові записи та ролі на рівні кластера. Перегляньте та видаліть усе, що було створено лише для доступу до Dashboard, наприклад: - службові облікові записи - привʼязки ролей або привʼязки ролей кластера - стара документація, яка вказує користувачам на URL-адреси Dashboard або команди port-forward Це зменшує кількість довготривалих облікових даних та невикористовуваних дозволів. ### Повідомлення про зміни {#communicate-the-changes} Переконайтеся, що ваша команда знає: - Headlamp тепер є основним інтерфейсом Kubernetes. - Як отримати до нього доступ (настільний додаток або URL). - Куди звертатися за допомогою, якщо щось виглядає інакше. ## 11. Контрольний список після міграції {#11-post-migration-checklist} Цей фінальний контрольний список допоможе вам переконатися, що міграція завершена. Він дає впевненість, що Headlamp працює належним чином і що нічого важливого не залишилося поза увагою. ### Доступ та видимість {#access-and-visibility} - [ ] Headlamp відкривається без помилок. - [ ] Користувачі можуть отримати доступ до правильних кластерів. - [ ] Фільтрація за просторами імен працює належним чином. - [ ] Перемикання між кластерами працює правильно. ### Автентифікація та RBAC {#authentication-and-rbac} - [ ] Користувачі настільних застосунків отримують доступ до кластерів за допомогою kubeconfig. - [ ] Користувачі в кластері можуть увійти, використовуючи обраний метод автентифікації. - [ ] Користувачі бачать лише ті дії, які дозволяє їх RBAC. - [ ] Під час нормального використання не виникають несподівані помилки дозволів. ### Основні робочі процеси {#core-workflows} - [ ] Ресурси завантажуються у Workloads, Network та Configuration. - [ ] YAML можна переглядати та редагувати там, де дозволяють права. - [ ] Застосунки можна розгортати за допомогою Create та YAML. - [ ] Логи завантажуються правильно для запущених подів. - [ ] Exec працює для користувачів, яким дозволено його використовувати. - [ ] Метрики зʼявляються, якщо встановлено metrics-server. ### Операційна впевненість {#operational-confidence} - [ ] Команди можуть усувати несправності без перемикання інструментів. - [ ] Map View допомагає пояснити взаємозвʼязки під час налагодження. - [ ] Platform або DevOps команди знають, як встановлюється та керується Headlamp. ### Підтвердження очищення {#cleanup-confirmation} - [ ] Kubernetes Dashboard більше не працює. - [ ] Службові облікові записи і привʼязки RBAC, призначені лише для Dashboard, видалені. - [ ] Внутрішня документація більше не містить посилань на URL-адреси Dashboard або команди port-forward. ### Узгодження з командою {#team-alignment} - [ ] Команда знає, що Headlamp є стандартним інтерфейсом Kubernetes. - [ ] Документація для новачків вказує новим користувачам на Headlamp. - [ ] Існує чіткий шлях для зворотного звʼязку або запитань. Ось ви завершили перехід з Kubernetes Dashboard на Headlamp. Ваша команда може використовувати ту ж модель доступу до Kubernetes, працювати з різними кластерами та покладатися на робочі процеси, які відповідають сучасному використанню Kubernetes. Відтепер Headlamp стає вашим стандартним інтерфейсом, як на робочому столі, так і в спільних середовищах. Зі зростанням ваших потреб ви можете продовжувати використовувати його в поточному вигляді або розширювати за допомогою втулків та нових компонентів. Якщо ви хочете допомогти формувати майбутнє Headlamp, приєднуйтесь до спільноти Headlamp і робіть внесок на [headlamp.dev](https://headlamp.dev).