Що таке kubectl і як працювати з кластером
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: kubectl — це інструмент командного рядка для роботи з Kubernetes — системою, яка керує застосунками, запущеними в контейнерах. Він дає змогу перевіряти стан застосунків, розгортати зміни, читати журнали й керувати ресурсами кластера. Це не сам Kubernetes, і цей інструмент не створює автоматично середовище для запуску застосунків: йому потрібен доступ до наявного кластера.
Як kubectl взаємодіє з Kubernetes
Кластер Kubernetes — це середовище, що складається з машин, які називають вузлами, та компонентів, які керують запуском застосунків. Контейнер — це спосіб пакування застосунку разом із його залежностями. Kubernetes запускає контейнери в одиницях, які називають Pod; один Pod може містити один або кілька контейнерів, що працюють разом.
kubectl працює на комп’ютері адміністратора чи розробника або в системі автоматизації розгортань. Він надсилає запити до сервера API системи Kubernetes — точки взаємодії для читання та зміни ресурсів кластера. Він не керує кожним контейнером безпосередньо: потрібні для досягнення заданого стану дії виконують компоненти Kubernetes.
Наприклад, якщо ви задасте підтримання трьох копій застосунку, kubectl передасть цю конфігурацію до API. Далі Kubernetes намагатиметься забезпечити роботу потрібних копій. Термінал можна закрити: робота застосунку не залежить від запущеного процесу kubectl.
Що потрібно для початку
Самого встановлення kubectl недостатньо. Потрібен кластер — локальне тестове середовище, наприклад створене за допомогою kind або minikube, чи кластер, наданий компанією або хмарним провайдером, — а також права на його використання.
Дані підключення зазвичай містяться у файлі kubeconfig. У ньому зберігаються адреси кластерів, налаштування автентифікації або посилання на механізми входу, а також контексти. Контекст визначає, з яким кластером і від імені якого користувача ви працюєте; він також може задавати простір імен за замовчуванням. Простір імен, або namespace, групує ресурси в межах кластера.
За замовчуванням конфігурація розташована в $HOME/.kube/config, але можна вказати інший файл. Перед початком роботи перевірте клієнт і поточне підключення:
kubectl version --client
kubectl config current-context
kubectl cluster-info
Перша команда перевіряє версію локального інструмента, але не підтверджує доступ до кластера. Друга показує вибраний контекст, а третя намагається отримати інформацію про кластер. Помилки можуть виникати через відсутність конфігурації, проблеми з мережею, завершення строку дії сеансу входу або недостатні права доступу.
Спосіб встановлення та допустимі розбіжності між версіями клієнта й сервера перевірте в офіційній документації Kubernetes. У корпоративному середовищі також дотримуйтеся інструкцій адміністратора щодо входу.
Основні команди для перевірки застосунків
Команди зазвичай мають вигляд kubectl diia typ-resursu imia. Параметри дають змогу, зокрема, вибрати простір імен і формат результату. На початку найкориснішими є операції читання:
| Команда | Призначення |
|---|---|
kubectl get pods -n test | Список Pod у просторі імен test та їхній загальний стан. |
kubectl describe pod IMIA -n test | Відомості про Pod і події, корисні для діагностики. |
kubectl logs IMIA -n test | Журнали контейнера у вказаному Pod. |
kubectl get deployments -n test | Стан ресурсів, які керують копіями застосунку. |
Замініть IMIA на фактичне ім’я Pod. Якщо Pod містить кілька контейнерів, для читання журналів може знадобитися параметр -c IMIA_KONTEINERA.
Припустімо, що після розгортання застосунок не відповідає. Почніть із get pods, щоб перевірити, чи працюють його Pod. Потім скористайтеся describe і пошукайте події, пов’язані, наприклад, із завантаженням образу або запуском контейнера. Після цього прочитайте журнали застосунку. Самого стану Pod не завжди достатньо, щоб визначити причину проблеми.
Як розгортати зміни за допомогою файлу YAML
kubectl може створювати ресурси окремими командами, але конфігурацію застосунку часто записують у маніфесті — файлі, що описує бажаний стан ресурсів. Найчастіше використовують формат YAML. Такий файл можна зберігати в репозиторії та переглядати зміни в ньому перед розгортанням.
Наведений нижче маніфест створює Deployment — ресурс, який підтримує задану кількість копій застосунку та керує їхнім оновленням:
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 1
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
spec:
containers:
- name: nginx
image: nginx:stable
Збережіть його як deployment.yaml. У тестовому кластері можна застосувати конфігурацію та перевірити перебіг розгортання:
kubectl apply -f deployment.yaml
kubectl rollout status deployment/demo
kubectl get pods -l app=demo
Цей приклад запускає сервер nginx, але не робить його автоматично доступним в інтернеті. Мережевий доступ потребує додаткового налаштування, часто — ресурсу Service, який спрямовує трафік до Pod. Запуск прикладу також залежить від можливості завантажити образ і від наявних ресурсів кластера.
Як уникнути змін не в тому середовищі
kubectl може працювати як із тестовим, так і з виробничим середовищем. Перед операцією, що змінює ресурси, перевірте контекст і простір імен. Їх можна явно вказати параметрами --context і -n, замість того щоб покладатися на налаштування за замовчуванням.
Перед застосуванням маніфесту корисні команда kubectl diff -f deployment.yaml, яка показує відмінності від наявних ресурсів, і команда kubectl apply --dry-run=server -f deployment.yaml, яка надсилає пробний запит без збереження змін. Проте вони не гарантують, що після розгортання застосунок працюватиме правильно.
Команда delete видаляє ресурси й може перервати роботу застосунку. Вважайте kubeconfig файлом із конфіденційними даними: не публікуйте його в репозиторії та не використовуйте конфігурацію з ненадійного джерела. Перші вправи виконуйте в тестовому кластері, починаючи з перевірки контексту та перегляду стану Pod.
Дивіться також: Що таке FTP?
Читайте також
