Kubernetes – Как работи

Какво е Kubernetes

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

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

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

Том (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 controller, Job 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 следи състоянието на възлите и рестартира Pod-овете на други възли, ако нещо излезе от строя.

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-а на Service.
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 заявява от API на облака създаването на външен Load Balancer
Балансьорът получава публичен 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-ове във всички namespace-ове
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>           # указване на 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