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:

# 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

kubectl apply -f admin-user.yaml

Создание токена для доступа к Dashboard:

# 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

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