Kubernetes — Як це працює

Що таке Kubernetes

Kubernetes:
відкрите програмне забезпечення для оркестрування контейнеризованих застосунків — автоматизації їх розгортання, масштабування та координації в умовах кластера. Підтримує основні технології контейнеризації, включно з Docker, rkt, також можлива підтримка технологій апаратної віртуалізації. Оригінальна версія була розроблена компанією Google для внутрішніх потреб, згодом систему передано під управління Cloud Native Computing Foundation.

Вузол (node):
це окрема фізична або віртуальна машина, на якій розгорнуті та виконуються контейнери застосунків. Кожен вузол у кластері містить сервіси для запуску застосунків у контейнерах (наприклад Docker), а також компоненти, призначені для централізованого управління вузлом.

Под (pod):
базова одиниця для запуску та управління застосунками: один або кілька контейнерів, яким гарантовано запуск на одному вузлі, забезпечується спільне використання ресурсів і міжпроцесна взаємодія та надається унікальна в межах кластера IP-адреса[16]. Останнє дозволяє застосункам, розгорнутим на поді, використовувати фіксовані та наперед визначені номери портів без ризику конфлікту. Поди можуть напряму керуватися з використанням API Kubernetes або керування ними може бути передане контролеру.

Том (volume):
спільний ресурс сховища для спільного використання з контейнерів, розгорнутих у межах одного пода.

Деплой застосунку:
Ти описуєш застосунок у маніфесті (зазвичай YAML-файл): скільки реплік, образ контейнера, ресурси, змінні середовища тощо.

Приклад deployment.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:

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

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'ами

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

або встановити та запустити Minikube

https://minikube.sigs.k8s.io/docs/start

або встановити та запустити Kind (Kubernetes IN Docker)

https://kind.sigs.k8s.io

Основні команди kubectl

Робота з ресурсами:

kubectl get pods                          # список Pod-ів
kubectl get pods -A                       # усі Pod-и в усіх неймспейсах
kubectl get services                      # список сервісів
kubectl get deployments                   # список Deployment-ів
kubectl get nodes                         # список нод
kubectl get all                           # усі ресурси поточного namespace

Приклади:

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    <none>        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    <none>        443/TCP   42m

Діагностика та налагодження:

kubectl describe pod <ім'я>               # подробиці Pod-а
kubectl logs <pod>                        # логи контейнера
kubectl logs <pod> -c <container>         # логи конкретного контейнера
kubectl exec -it <pod> -- bash            # термінал у контейнері (bash/sh)
kubectl top pod                           # використання ресурсів (якщо встановлено metrics-server)

Приклади:

kubectl exec -it ubuntu-test -- bash:
root@ubuntu-test:/#

Управління ресурсами:

kubectl apply -f <файл.yaml>              # створити або оновити ресурси
kubectl delete -f <файл.yaml>             # видалити ресурси
kubectl delete pod <ім'я>                 # видалити Pod
kubectl create -f <файл.yaml>             # створити ресурси (лише нові)
kubectl scale deployment <ім'я> --replicas=3

Контекст і namespace:

kubectl config get-contexts               # усі кластери
kubectl config use-context <ім'я>         # перемкнутися на інший кластер
kubectl config current-context            # поточний контекст
kubectl get pods -n <namespace>           # вказати неймспейс

Приклади:

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

Дії:

kubectl run ubuntu --image=ubuntu:22.04                # запуск образу

Приклади:

kubectl run ubuntu --image=ubuntu:22.04 --restart=Never --command -- sleep infinity:
pod/ubuntu created

Імпорт/експорт конфігурації:

kubectl get pod <ім'я> -o yaml            # вивести YAML
kubectl explain pod                       # довідка щодо структури ресурсу
kubectl apply -k <директорія>             # застосувати Kustomize-конфігурацію

Приклади:

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    <string>
    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  <string>
    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      <ObjectMeta>
    Standard object's metadata. More info:
    https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
  spec  <PodSpec>
    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        <PodStatus>
    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:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v7.13.0/aio/deploy/recommended.yaml

// найновішу версію можна подивитися на
https://github.com/kubernetes/dashboard

Namespace:

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:

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

kubectl apply -f admin-user.yaml

Створення токена для доступу до Dashboard:

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

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:

kubectl proxy

// Відкрити в браузері:
http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

Kubernetes Dashboard

Верхня панель:

Namespace (default):
поточний namespace. Можна обрати інший (наприклад, kube-system, kubernetes-dashboard).

Кнопка «+» (Create):
відкрити форму/редактор для створення ресурсу (через YAML).

Бічна панель:

Workloads — робочі навантаження

Cron Jobs:
Періодичні завдання (аналог cron у Linux). Запускають Job за розкладом.

Daemon Sets:
Запускають Pod на кожній ноді (або обраних), наприклад для логера, моніторингу (Prometheus Node Exporter тощо).

Deployments:
Основний спосіб розгортання застосунків. Керує кількістю реплік Pod-ів, оновленнями, відкатами.

Jobs:
Одноразові завдання, які виконуються до завершення (наприклад, міграції БД, генерація звітів).

Pods:
Базові одиниці виконання — обгортки для контейнерів. Можна запускати окремо або через контролери (Deployments тощо).

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).

Config and Storage — конфігурація та сховища

Config Maps:
Зберігання конфігурації у вигляді ключ-значення. Підключаються до Pod-ів як змінні середовища або файли.

Persistent Volume Claims:
Запити на постійне сховище (PV). Зв'язуються з Persistent Volumes.

Secrets:
Зберігання чутливих даних (паролі, токени, ключі). Можна монтувати в контейнери або використовувати як змінні.

Storage Classes:
Визначають, як і де створювати сховища (наприклад, вручну або динамічно в хмарі).

Cluster — управління кластером

Cluster Role Bindings:
Прив'язка ClusterRole до користувача або ServiceAccount на рівні всього кластера.

Cluster Roles:
Визначають набори дозволів (RBAC) на рівні кластера.

Events:
Системні події в кластері: створення/видалення ресурсів, помилки, рестарти Pod-ів тощо.

Namespaces:
Логічна ізоляція ресурсів (наприклад: default, kube-system, dev, prod). Корисно для розділення доступу та середовищ.

Network Policies:
Визначають правила мережевої взаємодії між Pod-ами. Аналог firewall усередині кластера.

Nodes:
Фізичні або віртуальні машини, на яких запущені Pod-и.

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 (тема, мова, поведінка).

About:
Інформація про версію Kubernetes Dashboard, його компоненти та залежності.

Як моніторити здоров'я сервісів

Probes (перевірка здоров'я):
Додай livenessProbe і readinessProbe у контейнер. Kubernetes буде відстежувати стан Pod і перезапускати його при збоях. Але ці перевірки лише перезапускають Pod, не надсилають сповіщення.

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

Приклад алерта:

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 та ін.

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.

<metric_name>{<label_key>=<label_value>, ...} <value> [<timestamp>]

Приклади:

Приклад простих метрик:
# 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.

Метрики 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