--- title: "Kubernetes – Как работи" url: "https://romankryvolapov.com/bg/kubernetes/" description: "Устройство на Kubernetes: архитектура на control plane, namespace, балансиране на натоварването, команди на kubectl, Dashboard и мониторинг с Prometheus." language: bg published: 2025-07-03 updated: 2026-11-13 --- ## Какво е Kubernetes **Kubernetes**:\ софтуер с отворен код за оркестрация на контейнеризирани приложения – автоматизиране на тяхното внедряване, мащабиране и координиране в условията на клъстер. Поддържа основните технологии за контейнеризация, включително Docker, rkt, а е възможна и поддръжка на технологии за хардуерна виртуализация. Оригиналната версия е разработена от Google за вътрешни нужди, а впоследствие системата е предадена за управление на Cloud Native Computing Foundation. **Възел (node):**\ това е отделна физическа или виртуална машина, на която са разгърнати и се изпълняват контейнерите на приложенията. Всеки възел в клъстера съдържа услуги за стартиране на приложения в контейнери (например Docker), както и компоненти, предназначени за централизирано управление на възела. ![](/images/2025/07/image-3.png) **Под (pod):**\ основната единица за стартиране и управление на приложения: един или няколко контейнера, за които е гарантирано, че ще се стартират на един и същ възел, осигурени са споделяне на ресурси и междупроцесно взаимодействие и се предоставя IP адрес, уникален в рамките на клъстера\[16\]. Последното позволява на приложенията, разгърнати в под, да използват фиксирани и предварително определени номера на портове без риск от конфликт. Подовете могат да се управляват директно чрез Kubernetes API или управлението им може да се предаде на контролер. ![](/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 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:** ![](/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-а на 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 ```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 **Работа с ресурси:** ```bash kubectl get pods # списък с Pod-ове kubectl get pods -A # всички Pod-ове във всички namespace-ове kubectl get services # списък с услуги kubectl get deployments # списък с Deployment-и kubectl get nodes # списък с възли kubectl get all # всички ресурси на текущия namespace ``` Примери: ```text languages="Shell" 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 ``` **Диагностика и дебъгване:** ```bash kubectl describe pod <име> # подробности за Pod kubectl logs # логове на контейнера kubectl logs -c # логове на конкретен контейнер kubectl exec -it -- bash # терминал в контейнера (bash/sh) kubectl top pod # използване на ресурси (ако е инсталиран metrics-server) ``` Примери: ```text languages="Shell" kubectl exec -it ubuntu-test -- bash: root@ubuntu-test:/# ``` **Управление на ресурси:** ```bash kubectl apply -f <файл.yaml> # създава или обновява ресурси kubectl delete -f <файл.yaml> # изтрива ресурси kubectl delete pod <име> # изтрива Pod kubectl create -f <файл.yaml> # създава ресурси (само нови) kubectl scale deployment <име> --replicas=3 ``` **Контекст и namespace:** ```bash kubectl config get-contexts # всички клъстери kubectl config use-context <име> # превключване към друг клъстер kubectl config current-context # текущ контекст kubectl get pods -n # указване на namespace ``` Примери: ```text languages="Shell" 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 ``` **Действия:** ```bash kubectl run ubuntu --image=ubuntu:22.04 # стартиране на образ ``` Примери: ```text languages="Shell" kubectl run ubuntu --image=ubuntu:22.04 --restart=Never --command -- sleep infinity: pod/ubuntu created ``` **Импорт/експорт на конфигурация:** ```bash kubectl get pod <име> -o yaml # извеждане на YAML kubectl explain pod # справка за структурата на ресурса kubectl apply -k <директория> # прилагане на Kustomize конфигурация ``` Примери: ```text languages="Shell" 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:** ```bash kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v7.13.0/aio/deploy/recommended.yaml # последната версия може да се види на https://github.com/kubernetes/dashboard ``` **Namespace:** ```bash 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 ``` ```bash 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 ``` ```powershell 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:** ```bash 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)