--- title: "Kubernetes — Як це працює" url: "https://romankryvolapov.com/uk/kubernetes/" description: "Будова Kubernetes: архітектура control plane, namespace, балансування навантаження, команди kubectl, Dashboard і моніторинг через Prometheus." language: uk updated: 2026-01-21 --- ## Що таке Kubernetes **Kubernetes**:\ відкрите програмне забезпечення для оркестрування контейнеризованих застосунків — автоматизації їх розгортання, масштабування та координації в умовах кластера. Підтримує основні технології контейнеризації, включно з Docker, rkt, також можлива підтримка технологій апаратної віртуалізації. Оригінальна версія була розроблена компанією Google для внутрішніх потреб, згодом систему передано під управління Cloud Native Computing Foundation. **Вузол (node):**\ це окрема фізична або віртуальна машина, на якій розгорнуті та виконуються контейнери застосунків. Кожен вузол у кластері містить сервіси для запуску застосунків у контейнерах (наприклад Docker), а також компоненти, призначені для централізованого управління вузлом. ![](/images/2025/07/image-3.png) **Под (pod):**\ базова одиниця для запуску та управління застосунками: один або кілька контейнерів, яким гарантовано запуск на одному вузлі, забезпечується спільне використання ресурсів і міжпроцесна взаємодія та надається унікальна в межах кластера IP-адреса\[16\]. Останнє дозволяє застосункам, розгорнутим на поді, використовувати фіксовані та наперед визначені номери портів без ризику конфлікту. Поди можуть напряму керуватися з використанням API Kubernetes або керування ними може бути передане контролеру. ![](/images/2025/07/image-4.png) **Том (volume):**\ спільний ресурс сховища для спільного використання з контейнерів, розгорнутих у межах одного пода. **Деплой застосунку:**\ Ти описуєш застосунок у маніфесті (зазвичай YAML-файл): скільки реплік, образ контейнера, ресурси, змінні середовища тощо. **Приклад deployment.yaml:** ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-app spec: replicas: 3 selector: matchLabels: app: my-app template: metadata: labels: app: my-app spec: containers: - name: app image: my-app:latest ports: - containerPort: 8080 ``` **kubectl:**\ командна утиліта для управління кластером Kubernetes.\ Вона дозволяє надсилати команди та отримувати інформацію від Kubernetes API Server, тобто — це основний інструмент роботи з кластером через термінал. **Що можна робити за допомогою kubectl:**\ Створювати, оновлювати та видаляти ресурси (Pods, Deployments, Services тощо)\ Отримувати інформацію про стан кластера, застосунків і нод\ Підключатися до працюючих контейнерів (через exec)\ Переглядати логи (logs)\ Масштабувати застосунки (scale)\ Налагоджувати збої (describe, events)\ Застосовувати конфігурації з YAML-файлів (apply, create) ## Архітектура **kube-apiserver:**\ REST-інтерфейс до всього кластера. Приймає команди від kubectl, інших сервісів і клієнтів. Це точка входу в усю систему.\ Мова: Go\ Формат: бінарний файл, запускається як процес або контейнер\ Протоколи: HTTP/HTTPS (REST API)\ Функції: приймання команд (kubectl, UI, CI/CD), валідація, авторизація, запис в etcd **etcd:**\ розподілене key-value сховище. У ньому зберігається весь стан кластера. Це окремий процес, часто винесений на свою ноду (або кілька для відмовостійкості).\ Мова: Go\ Формат: окремий бінарний файл (etcd), часто запускається як systemd-сервіс або контейнер\ Тип БД: key-value (Raft-кластер)\ Функції: зберігання всього стану: Pods, Deployments, ConfigMaps тощо. **kube-scheduler:**\ обирає, на якій робочій ноді запускати Pod, спираючись на ресурси, taints, affinity та ін.\ Мова: Go\ Формат: бінарник\ Функції: при появі нового Pod'а обирає відповідну ноду на основі доступних ресурсів, affinity, taints тощо. **kube-controller-manager:**\ стежить за об'єктами в etcd (наприклад, що має бути 3 репліки Pod'а) і приводить кластер до потрібного стану. Включає: Node controller, Replication controller, Deployment controllerJob controller та ін.\ Мова: Go\ Формат: бінарний файл\ Функції: містить кілька контролерів (наприклад, для ReplicaSets, Endpoints тощо), кожен з яких відстежує поточні об'єкти в etcd і створює/видаляє ресурси за потреби. **cloud-controller-manager (опційно):**\ Керує ресурсами хмарного провайдера: балансувальники, диски, IP.\ Підключається до API провайдера (AWS, GCP та ін.) через SDK\ Відповідає за створення LoadBalancer'ів, дисків, маршрутів тощо **Де вони запускаються:**\ На керуючій ноді (master node)\ Найчастіше — у вигляді контейнерів, запущених через kubelet і маніфести в /etc/kubernetes/manifests/\*.yaml (у kubeadm-кластері) **Як вони пов'язані:**\ Усі спілкуються з kube-apiserver (навіть контролери та планувальник)\ kube-apiserver спілкується з etcd\ Жоден компонент не має прямого доступу до etcd, окрім apiserver **kubelet:**\ агент, що взаємодіє з керуючою площиною та стежить за Pod'ами на ноді, на обраних нодах запускає контейнери. **kube-proxy:**\ реалізує мережеву маршрутизацію та балансування, налаштовує iptables або ipvs для маршрутизації трафіку. **Container runtime:**\ наприклад, Docker або containerd, запускає контейнери. **Масштабування та самовідновлення:**\ Якщо Pod падає, ReplicaSet controller автоматично запускає новий.\ Можна масштабувати застосунок вручну (kubectl scale) або автоматично (HPA).\ Kubernetes відстежує стан нод і перезапускає Pods на інших, якщо щось вийшло з ладу. ## Namespace Це логічна ізоляція ресурсів усередині одного кластера. **Навіщо потрібен Namespace:**\ Розділення середовища: dev, test, prod\ Розмежування доступу за командами (RBAC)\ Управління ресурсами (ліміти CPU/пам'яті можна задавати на рівень namespace)\ Ізоляція конфігурації та мереж **Що ізолюється в Namespace:** Pods, Services, ConfigMaps, Secrets, Deployments та ін.\ **Не ізолюються:** Nodes, Persistent Volumes (без PVC), ClusterRoles / ClusterRoleBindings **Стандартні Namespace:** ![](/images/2025/07/image-2-1024x485.png) **kubernetes-dashboard:**\ Це namespace, створений автоматично під час встановлення Dashboard. У ньому знаходяться:\ Pod Dashboard (UI-інтерфейс)\ Сервіс Dashboard (Service)\ Сервісні акаунти (admin-user, dashboard-admin)\ Усі об'єкти, пов'язані з панеллю управління\ Використовується тільки для Dashboard. Краще не розміщувати туди свої застосунки. **default:**\ Основний namespace за замовчуванням. Якщо ти не вказуєш -n або --namespace, усі ресурси створюються тут.\ Добре підходить для тестів і простих застосунків\ Але для реальних проєктів краще використовувати окремі namespace'и (dev, prod, team-a) **kube-node-lease:**\ Технічний namespace для внутрішніх lease-об'єктів (lease = оренда) між kubelet і kube-controller-manager.\ Використовується для перевірки життєздатності нод\ Забезпечує масштабованість heartbeat-сигналів від нод\ Зазвичай не потрібен для ручної роботи, але важливий для стабільності кластера. **kube-public:**\ Спільний namespace, доступний усім (включно з неавтентифікованими користувачами, якщо дозволено).\ Зазвичай використовується для публічної інформації про кластер\ Наприклад, cluster-info config map (використовується kubectl cluster-info)\ За замовчуванням не містить критичних об'єктів. Можна використовувати як джерело відкритих даних. **kube-system:**\ Критично важливий namespace. Тут знаходяться всі системні компоненти Kubernetes:\ DNS (CoreDNS)\ Мережеві плагіни (наприклад, CNI)\ kube-proxy\ kube-controller-manager (якщо не в окремій ноді)\ Storage provisioners та інше\ Ніколи не розміщуй сюди свої застосунки. ## Балансування навантаження **Внутрішньокластерне балансування (Service → Pod)** Коли ти створюєш Service типу ClusterIP, NodePort або LoadBalancer, Kubernetes автоматично розподіляє трафік між Pod-ами, які відповідають цьому сервісу. **Як це працює**\ У Service є IP-адреса.\ Коли хтось звертається до цього IP, kube-proxy перенаправляє трафік на один з Pod-ів, що відповідають selector сервісу.\ kube-proxy використовує:\ iptables (за замовчуванням)\ або ipvs (оптимізований режим)\ Трафік рівномірно розподіляється між живими Pod-ами (round-robin). **Вхідний HTTP(S) трафік — через Ingress** Якщо ти хочеш приймати зовнішній HTTP(S)-трафік, використовується Ingress + Ingress Controller (наприклад, NGINX, Traefik, Istio). **Як це працює:**\ Ingress Controller отримує весь зовнішній HTTP-трафік\ На основі Ingress-правил він визначає, у який Service передати трафік\ Далі трафік іде за звичайною схемою Service → Pod\ Контролер може використовувати Sticky Sessions, Path-based routing, TLS, балансування за вагою та ін. **Зовнішнє балансування (у хмарі)** Якщо використовується Service типу LoadBalancer, і кластер розгорнутий у хмарі (AWS, GCP, Azure):\ Kubernetes запитує створення зовнішнього Load Balancer'а у хмарного API\ Балансувальник отримує публічний IP і спрямовує трафік у NodePort-и нод\ Зовнішнє балансування працює поза кластером, як класичний хмарний LB. **Приклади балансування:** **ClusterIP (внутрішній сервіс):**\ автоматично балансує трафік між Pod'ами app=my-app ```yaml apiVersion: v1 kind: Service metadata: name: my-service spec: selector: app: my-app ports: - port: 80 targetPort: 8080 type: ClusterIP ``` **Ingress (HTTP):**\ NGINX Ingress Controller буде спрямовувати запити до `web-service`, який балансує між Pod'ами ```yaml apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: web-ingress spec: rules: - host: app.local http: paths: - path: / pathType: Prefix backend: service: name: web-service port: number: 80 ``` ## Приклад локального запуску Kubernetes Найпростіший спосіб- увімкнути в Docker Desktop [https://docs.docker.com/desktop/setup/install/windows-install](https://docs.docker.com/desktop/setup/install/windows-install) ![](/images/2025/07/image-1024x618.png) або встановити та запустити Minikube [https://minikube.sigs.k8s.io/docs/start](https://minikube.sigs.k8s.io/docs/start) або встановити та запустити Kind (Kubernetes IN Docker) [https://kind.sigs.k8s.io](https://kind.sigs.k8s.io) ## Основні команди kubectl **Робота з ресурсами:** ```text kubectl get pods # список Pod-ів kubectl get pods -A # усі Pod-и в усіх неймспейсах kubectl get services # список сервісів kubectl get deployments # список Deployment-ів kubectl get nodes # список нод kubectl get all # усі ресурси поточного namespace ``` Приклади: ```text kubectl get pods: NAME READY STATUS RESTARTS AGE ubuntu-test 1/1 Running 0 27m kubectl get pods -A: NAMESPACE NAME READY STATUS RESTARTS AGE default ubuntu-test 1/1 Running 0 28m kube-system coredns-668d6bf9bc-spsws 1/1 Running 0 41m kube-system coredns-668d6bf9bc-t9jkx 1/1 Running 0 41m kube-system etcd-docker-desktop 1/1 Running 0 41m kube-system kube-apiserver-docker-desktop 1/1 Running 0 41m kube-system kube-controller-manager-docker-desktop 1/1 Running 0 41m kube-system kube-proxy-xd582 1/1 Running 0 41m kube-system kube-scheduler-docker-desktop 1/1 Running 0 41m kube-system storage-provisioner 1/1 Running 0 41m kube-system vpnkit-controller 1/1 Running 0 41m kubernetes-dashboard dashboard-metrics-scraper-5bd45c9dd6-55lj2 1/1 Running 0 35m kubernetes-dashboard kubernetes-dashboard-79cbcf9fb6-q792g 1/1 Running 0 35m kubectl get services: NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 10.96.0.1 443/TCP 41m kubectl get nodes: NAME STATUS ROLES AGE VERSION docker-desktop Ready control-plane 33m v1.32.2 kubectl get all: NAME READY STATUS RESTARTS AGE pod/ubuntu-test 1/1 Running 0 29m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 443/TCP 42m ``` **Діагностика та налагодження:** ```text kubectl describe pod <ім'я> # подробиці Pod-а kubectl logs # логи контейнера kubectl logs -c # логи конкретного контейнера kubectl exec -it -- bash # термінал у контейнері (bash/sh) kubectl top pod # використання ресурсів (якщо встановлено metrics-server) ``` Приклади: ```text kubectl exec -it ubuntu-test -- bash: root@ubuntu-test:/# ``` **Управління ресурсами:** ```text kubectl apply -f <файл.yaml> # створити або оновити ресурси kubectl delete -f <файл.yaml> # видалити ресурси kubectl delete pod <ім'я> # видалити Pod kubectl create -f <файл.yaml> # створити ресурси (лише нові) kubectl scale deployment <ім'я> --replicas=3 ``` **Контекст і namespace:** ```text kubectl config get-contexts # усі кластери kubectl config use-context <ім'я> # перемкнутися на інший кластер kubectl config current-context # поточний контекст kubectl get pods -n # вказати неймспейс ``` Приклади: ```text kubectl config get-contexts: CURRENT NAME CLUSTER AUTHINFO NAMESPACE * docker-desktop docker-desktop docker-desktop minikube minikube minikube default kubectl config current-context: docker-desktop ``` **Дії:** ```text kubectl run ubuntu --image=ubuntu:22.04 # запуск образу ``` Приклади: ```kotlin kubectl run ubuntu --image=ubuntu:22.04 --restart=Never --command -- sleep infinity: pod/ubuntu created ``` **Імпорт/експорт конфігурації:** ```text kubectl get pod <ім'я> -o yaml # вивести YAML kubectl explain pod # довідка щодо структури ресурсу kubectl apply -k <директорія> # застосувати Kustomize-конфігурацію ``` Приклади: ```text kubectl explain pod: KIND: Pod VERSION: v1 DESCRIPTION: Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts. FIELDS: apiVersion APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources kind Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds metadata Standard object's metadata. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata spec Specification of the desired behavior of the pod. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status status Most recently observed status of the pod. This data may not be up to date. Populated by the system. Read-only. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status ``` **Встановлення Dashboard:** ```text kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v7.13.0/aio/deploy/recommended.yaml // найновішу версію можна подивитися на https://github.com/kubernetes/dashboard ``` **Namespace:** ```text kubectl create namespace my-team # Створити Namespace kubectl apply -f app.yaml -n my-team # Застосувати маніфест у Namespace kubectl get pods -n my-team # Переглянути ресурси в Namespace kubectl config set-context --current --namespace=my-team # Змінити активний Namespace (kubectl config) ``` **Створення admin-доступу до Dashboard:** ```yaml # admin-user.yaml apiVersion: v1 kind: ServiceAccount metadata: name: admin-user namespace: kubernetes-dashboard --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: admin-user-binding roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: admin-user namespace: kubernetes-dashboard ``` ```text kubectl apply -f admin-user.yaml ``` **Створення токена для доступу до Dashboard:** ```yaml # admin-user-token.yaml apiVersion: v1 kind: Secret metadata: name: admin-user-token namespace: kubernetes-dashboard annotations: kubernetes.io/service-account.name: admin-user type: kubernetes.io/service-account-token ``` ```text kubectl apply -f admin-user-token.yaml // Отримання токена: kubectl -n kubernetes-dashboard get secret admin-user-token -o jsonpath="{.data.token}" | ` %{ [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($_)) } ``` **Доступ до Dashboard:** ```text kubectl proxy // Відкрити в браузері: http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/ ``` ## Kubernetes Dashboard ![](/images/2025/07/image-1-1024x563.png) **Верхня панель:** **Namespace (default):**\ поточний namespace. Можна обрати інший (наприклад, kube-system, kubernetes-dashboard). ![](/images/2025/07/image-2-1024x485.png) **Кнопка «+» (Create):**\ відкрити форму/редактор для створення ресурсу (через YAML). ![](/images/2025/07/image-10-1024x640.png) ![](/images/2025/07/image-11-952x1024.png) **Бічна панель:** **Workloads — робочі навантаження** **Cron Jobs:**\ Періодичні завдання (аналог cron у Linux). Запускають Job за розкладом. **Daemon Sets:**\ Запускають Pod на кожній ноді (або обраних), наприклад для логера, моніторингу (Prometheus Node Exporter тощо). **Deployments:**\ Основний спосіб розгортання застосунків. Керує кількістю реплік Pod-ів, оновленнями, відкатами. **Jobs:**\ Одноразові завдання, які виконуються до завершення (наприклад, міграції БД, генерація звітів). **Pods:**\ Базові одиниці виконання — обгортки для контейнерів. Можна запускати окремо або через контролери (Deployments тощо). ![](/images/2025/07/image-4-1024x141.png) **Replica Sets:**\ Забезпечують потрібну кількість однакових Pod-ів. Зазвичай створюються та керуються через Deployment. **Replication Controllers:**\ Застарілий попередник ReplicaSet. Не використовується в сучасних кластерах. **Stateful Sets:**\ Контролери для Pod-ів з унікальними іменами, стабільними томами та послідовним масштабуванням (використовується в БД, Kafka тощо). **Service — доступ до застосунків** **Ingresses:**\ Правила маршрутизації HTTP(S)-трафіку до Pod-ів через єдиний вхід. Працює з Ingress Controller (наприклад, nginx, traefik). **Ingress Classes:**\ Визначають типи контролерів Ingress. Дозволяють використовувати різні реалізації (наприклад, nginx, istio, haproxy) одночасно. **Services:**\ Об'єкти, що забезпечують мережевий доступ до Pod-ів (тип ClusterIP, NodePort, LoadBalancer). ![](/images/2025/07/image-6-1024x117.png) **Config and Storage — конфігурація та сховища** **Config Maps:**\ Зберігання конфігурації у вигляді ключ-значення. Підключаються до Pod-ів як змінні середовища або файли. ![](/images/2025/07/image-5-1024x103.png) **Persistent Volume Claims:**\ Запити на постійне сховище (PV). Зв'язуються з Persistent Volumes. **Secrets:**\ Зберігання чутливих даних (паролі, токени, ключі). Можна монтувати в контейнери або використовувати як змінні. **Storage Classes:**\ Визначають, як і де створювати сховища (наприклад, вручну або динамічно в хмарі). ![](/images/2025/07/image-8-1024x104.png) **Cluster — управління кластером** **Cluster Role Bindings:**\ Прив'язка ClusterRole до користувача або ServiceAccount на рівні всього кластера. **Cluster Roles:**\ Визначають набори дозволів (RBAC) на рівні кластера. **Events:**\ Системні події в кластері: створення/видалення ресурсів, помилки, рестарти Pod-ів тощо. ![](/images/2025/07/image-7-1024x207.png) **Namespaces:**\ Логічна ізоляція ресурсів (наприклад: default, kube-system, dev, prod). Корисно для розділення доступу та середовищ. **Network Policies:**\ Визначають правила мережевої взаємодії між Pod-ами. Аналог firewall усередині кластера. **Nodes:**\ Фізичні або віртуальні машини, на яких запущені Pod-и. ![](/images/2025/07/image-3-1024x293.png) **Persistent Volumes:**\ Фізичне сховище, доступне для Pod-ів (локальне, NFS, хмарне). **Role Bindings:**\ Прив'язка Role (обмеженої межами namespace) до суб'єктів (SA, користувачів). **Roles:**\ Набори дозволів (RBAC) у межах одного namespace. **Service Accounts:**\ Облікові записи, що використовуються Pod-ами для взаємодії з API Kubernetes (наприклад, для CI/CD або внутрішньої авторизації). **Custom Resource Definitions (CRD):**\ Розширення API Kubernetes. Дозволяє додавати свої ресурси (наприклад, HelmRelease, PrometheusRule, KedaScalers тощо). **Settings:**\ Налаштування інтерфейсу Dashboard (тема, мова, поведінка). ![](/images/2025/07/image-9-1024x499.png) **About:**\ Інформація про версію Kubernetes Dashboard, його компоненти та залежності. ## Як моніторити здоров'я сервісів **Probes (перевірка здоров'я):**\ Додай livenessProbe і readinessProbe у контейнер. Kubernetes буде відстежувати стан Pod і перезапускати його при збоях. Але ці перевірки лише перезапускають Pod, не надсилають сповіщення. ```yaml livenessProbe: httpGet: path: /health port: 8080 initialDelaySeconds: 5 periodSeconds: 10 readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 3 periodSeconds: 5 ``` **Нотифікації через Prometheus + Alertmanager:**\ Найгнучкіший спосіб — використовувати Prometheus з Alertmanager. **Кроки:**\ Встанови Prometheus + Alertmanager (можна через Helm)\ Налаштуй збір метрик з kubelet, kube-state-metrics, або самого застосунку\ Створи правила сповіщень (alerting rules)\ Підключи отримувачів: Email, Slack, Telegram, Webhook **Приклад алерта:** ```yaml groups: - name: kube-alerts rules: - alert: PodDown expr: kube_pod_status_phase{phase="Running"} == 0 for: 1m labels: severity: critical annotations: summary: "Pod {{ $labels.pod }} is down" description: "Pod {{ $labels.pod }} in namespace {{ $labels.namespace }} is not running" ``` **Вебхуки через Kubernetes Events (прослуховування подій):**\ Можна використовувати Event-Listener (наприклад, k8s-event-exporter):\ Слухає kubectl get events\ Надсилає в Slack, Webhook, Elasticsearch та ін. ```yaml receivers: - name: "slack" slack: webhook: "https://hooks.slack.com/services/..." username: "k8s-event-exporter" icon_emoji: ":kubernetes:" ``` **Підключення до CI/CD (наприклад, Argo CD, GitLab):**\ Якщо ти використовуєш ArgoCD або GitLab/Kubernetes CI:\ Можна налаштувати хук при зміні статусу Deployments/Pod\ І запускати сповіщення через Telegram, Discord тощо. ## Prometheus Це система моніторингу та сповіщень з відкритим кодом, створена для збору метрик із застосунків і сервісів. У Kubernetes Prometheus застосовується для:\ збору метрик (CPU, пам'ять, статус Pod-ів, нод тощо)\ візуалізації (через Grafana)\ сповіщень (через Alertmanager)\ аналізів навантаження та продуктивності **Формат:**\ текстовий, простий і читабельний, використовується Prometheus exposition format, який експортується по HTTP на endpoint, зазвичай /metrics. ```text {=, ...} [] ``` **Приклади:** ```text Приклад простих метрик: # HELP http_requests_total Кількість HTTP-запитів # TYPE http_requests_total counter http_requests_total{method="GET", path="/api"} 1025 http_requests_total{method="POST", path="/login"} 214 Приклад системних метрик: # HELP process_cpu_seconds_total CPU time consumed # TYPE process_cpu_seconds_total counter process_cpu_seconds_total 12.42 # HELP process_memory_usage_bytes Memory usage in bytes # TYPE process_memory_usage_bytes gauge process_memory_usage_bytes 4382720 Підтримувані типи метрик: counter Лічильник, який лише зростає gauge Значення, яке може зростати/спадати histogram Розподіл значень за кошиками summary Статистика (сума, квантиль тощо) Приклад histogram: # HELP request_duration_seconds Час відповіді # TYPE request_duration_seconds histogram request_duration_seconds_bucket{le="0.1"} 53 request_duration_seconds_bucket{le="0.5"} 87 request_duration_seconds_bucket{le="1"} 103 request_duration_seconds_bucket{le="+Inf"} 120 request_duration_seconds_count 120 request_duration_seconds_sum 45.3 ``` **Як працює Prometheus:**\ Періодично опитує endpoints (target'и) по HTTP (/metrics)\ Зберігає метрики у внутрішню базу (TSDB — Time Series DB)\ Надає мову запитів PromQL для фільтрації та агрегації\ Може тригерити алерти через Alertmanager **Де застосовується в Kubernetes:**\ Що моніториться Приклади метрик\ Ноди (Nodes) CPU, RAM, диск, статус\ Pod-и Час життя, перезапуски, помилки, фази\ Deployment / Service Кількість реплік, доступність\ Kubernetes API latency, errors\ Застосунки (якщо налаштовано) /metrics endpoint з кастомними метриками **Основні компоненти:** **Prometheus:**\ Збір і зберігання метрик **Alertmanager:**\ Надсилання сповіщень (Slack, Email та ін.) **Grafana:**\ Візуалізація графіків і дашбордів **node-exporter:**\ Метрики ОС (CPU, пам'ять, диск тощо) **kube-state-metrics:**\ Стан об'єктів Kubernetes Ось приклади типових метрик Prometheus, які можна збирати в Kubernetes. ```text Метрики Kubernetes-кластера: Pod / контейнери: container_cpu_usage_seconds_total Використання CPU у секундах container_memory_usage_bytes Використання пам'яті container_fs_usage_bytes Використання диска container_restart_count Кількість рестартів container_last_seen Останнє оновлення метрики Deployment / ReplicaSet / StatefulSet: kube_deployment_status_replicas_available Скільки реплік готові kube_deployment_spec_replicas Скільки очікується за планом kube_statefulset_status_replicas Репліки StatefulSet Pod / статус і фаза: kube_pod_status_phase{phase="Running"} К-сть працюючих Pod-ів kube_pod_status_phase{phase="Pending"} К-сть очікуючих Pod-ів kube_pod_container_status_restarts_total Кількість рестартів Ноди: node_cpu_seconds_total Завантаженість CPU node_memory_MemAvailable_bytes Доступна пам'ять node_disk_io_time_seconds_total Час введення-виведення kube_node_status_condition Стан ноди (Ready, NotReady тощо) Метрики самого застосунку: http_requests_total{handler="/api", method="GET", status="200"} 105 my_service_errors_total{type="db"} 3 job_duration_seconds{job="cleanup"} 1.25 rate(http_requests_total[1m]) # К-сть HTTP-запитів за секунду sum(my_service_errors_total) # Помилки за весь час avg(job_duration_seconds) # Середня тривалість завдання ``` [ Copyright: Roman Kryvolapov ](https://t.me/RomanKryvolapov)