Архитектура

Kubernetes Cluster
│
├─ Namespaces (логическая изоляция)
│
├─ Workload объекты
│ ├─ Pod
│ │ ├─ Containers
│ │ └─ Volumes (локальные или PV/PVC)
│ └─ Deployment / ReplicaSet / StatefulSet / DaemonSet / Job / CronJob 
├─ Nodes (Worker / Control Plane)
│ ├─ Kubelet (node agent, выполняет Pod)
│ ├─ Container Runtime (containerd / CRI-O)
│ └─ Kube-Proxy / CNI (сетевой слой)
│
├─ Scheduler (размещает Pod на Node)
├─ Controller Manager (обеспечивает desired state)
├─ API Server (точка входа для всех операций)
└─ etcd (источник истины)

1.  etcd — источник истины

2.  API Server — точка входа для всего

3.  Controller Manager — мозг, поддерживающий desired state

4.  Scheduler — размещает Pod

5.  Kubelet / Node Agent — исполнитель на ноде

6.  Kube-Proxy / CNI — сеть

7.  Container Runtime — запускает контейнеры

8.  Node — физический или виртуальный сервер, на котором работают Pods. Каждый Node содержит Kubelet (агент, который управляет контейнерами) и контейнерный движок (например, Docker).

9.  Namespace — логическая изоляция

10.  Workload объекты — Pod, Deployment, StatefulSet… и прочая БАЛАЛАЙКА

Зачем нужны объекты K8s

Возле подов, деплойментов и служб, есть ещё много других ресурсов — для конфигов, секретов, томов, контроля доступа и т.д. Всё это — объекты с разным назначением, которые вместе делают кластер гибким и мощным. Эти сущности и их взаимодействие позволяют Kubernetes обеспечивать эффективное и гибкое управление контейнерами и ресурсами в кластере. Объекты Kubernetes — это способ описать, что ты хочешь запустить, и как ты хочешь, чтобы это работало. Вместо того чтобы вручную управлять контейнерами, ты описываешь желаемое состояние, а Kubernetes следит, чтобы всё было так, как ты описал.

Pod

Pod — наименьшая и самая базовая единица развертывания в Kubernetes. Это группа контейнеров, которые делят общую сеть и хранилище. Контейнеры в Pod могут обмениваться данными между собой через shared volumes. Самый маленький объект который можно создать в K8s. Состоит из контейнера или нескольких контейнеров, то есть контейнер вы не запускаете на K8s, а запускаете Pod. Best practice — 1 Pod = 1 Container. Когда весь проект разделен на микросервисы, которые эскалируются по мере необходимости. Для этого нужен Deployment.

#----------------my-web.yaml----------------------------------
# Simpliest Manifest File to create Pod with one Container
#-------------------------------------------------------------
apiVersion : v1              #Какой API используется
kind: Pod                    #ЧТО создается
metadata:
  name: hello                #Просто имя
  labels:                    #Просто мета-информация
    env  : prod
    app  : main
    tier : frontend
    owner: kowalski
spec:                        #Спицификация
  containers:                #Контейнер
    - name : container-hello #Просто имя
      image: nginx:latest    ##Можно менять без delete pods
      ports:                 ##изменить и apply -f еще раз
        - containerPort: 80  #Порт контейнера
    - name : container-api
      image: tomcat:8.5.38
      ports:
        - containerPort: 8080

ConfigMap и Secret

Чтобы отделить конфигурацию от образов, K8s даёт объекты вроде ConfigMap и Secret — ты хранишь настройки, переменные окружения, пароли, ключи, и подставляешь их в поды, не запихивая всё прямо в Docker‑image. Это даёт гибкость и безопасность.

ConfigMap — позволяет хранить неструктурированные конфигурационные данные, которые можно использовать в Pods. Например, можно хранить конфигурационные файлы, переменные окружения.

Secret — похож на ConfigMap, но предназначен для хранения чувствительных данных, таких как пароли или ключи. Данные в Secret'ах шифруются.

Service и Ingress

Чтобы ваши поды были доступны извне (или друг другу внутри кластера), используют объекты вроде Service и Ingress — они настраивают маршрутизацию, балансировку, доступ и пр. Это абстракции над сетевыми правилами и коннектами, которые удручающе сложно было бы делать вручную на уровне контейнеров или VM.

Service — абстракция для обеспечения стабильного доступа к Pods, которые запущены в deployment через ClusterIP, NodePort, LoadBalancer, ExternalName. С помощью Service можно связать набор Pod'ов, чтобы обращаться к ним по одному имени и порту, даже если сами Pods изменяются или перезапускаются.

Существует 4 вида серивисов. При создании Service, прилодение будет доступно по:

• ClusterIP - IP только внутри K8s Cluster(default).

• NodePort - Определенный Порт на ВСЕХ K8s Worker Nodes.

• ExternalName - DNS CNAME Record.

• LoadBalancer - только для Cloud Cluster (AWS, GCP, Azure).

#-------------------------------------------------------------------------------------
# Manifest File to create Single Container Pod with AutoScaling Deployment and Service
#-------------------------------------------------------------------------------------
apiVersion : apps/v1
kind: Deployment
metadata:
  name: my-web-deployment-autoscaling
  labels:
    app : my-k8s-deployment
spec:
  selector:
    matchLabels:
      project: xyz
  template:
    metadata:
      labels:
        project: xyz                     #Service will look for those PODS Labels!!!
    spec:
      containers:
        - name : xyz-web
          image: nginx:latest
          ports:
            - containerPort: 80
---
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: my-autoscaling
spec:
  scaleTargetRef:
    apiVersion: apps/v2beta1v1
    kind: Deployment
    name: my-web-deployment-autoscaling
  minReplicas: 2
  maxReplicas: 6
  metrics:
  - type: Resource
    resource:
      name: cpu
      targetAverageUtilization: 70
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 80
---
apiVersion: v1
kind: Service
metadata:
  name: my-autoscaling-pod-service
  labels:
     env  : prod
     owner: kowalski
spec:
  selector:
    project: xyz                         #Selecting PODs with those Labels
  ports:
    - name      : app-listener
      protocol  : TCP
      port      : 80                     #Port on Load Balancer
      targetPort: 80                     #Port on Pod
  type: LoadBalancer

Ingress — объект, который управляет доступом к сервисам в кластере Kubernetes, чаще всего через HTTP. Он позволяет настроить маршрутизацию и SSL-терминацию для внешнего трафика.

Controllers

ReplicaSet — обеспечивает заданное количество реплик Pod'ов, поддерживая их стабильное состояние. Если один из Pod'ов выходит из строя, ReplicaSet создает новый Pod для замены.

Deployment — управляет созданием и обновлением ReplicaSet'ов, что позволяет контролировать версионирование и стратегию развертывания приложений (например, rolling update). Набор из ReplicaSet'ов Pod'ов и нужен для деплоя по Nodes, обновлений Container Image и распределения ресурсов. Объект, который описывает, как должны запускаться и масштабироваться поды, сколько реплик, как обрабатывать обновления, rollback и пр. Это позволяет управлять группами подов декларативно, а не вручную.

Deployments созадаются и управляются манифест-файлами и командами.

#---------------------------------------------------------------
# Manifest File to create Deployment with Labels and AutoScaling
#---------------------------------------------------------------
apiVersion : apps/v1
kind: Deployment
metadata:
  name: my-web-deployment-autoscaling
  labels:
    app  : my-k8s-application
    env  : prod
    owner: DenisAstahov
spec:
  replicas: 2 #Не нужно, если используется HorizontalPodAutoscaler
  selector:                              #Будет работать с подами
    matchLabels:                         #которые совпадают с этими Labels
      project: mossad                    #Можно использовать RegExp
  template:                              #Шаблон
    metadata: 
      labels:                            #Какие Labels будут присваиваться подам
        project: mossad
    spec:
      containers:
        - name : mossad-web
          image: nginx:latest
          ports:
            - containerPort: 80
---
apiVersion: autoscaling/v2beta1
kind: HorizontalPodAutoscaler
metadata:
  name: my-autoscaling
spec:
  scaleTargetRef:
    apiVersion: apps/v2beta1v1           #Эскалация
    kind: Deployment                     #ЧТО эскалировать
    name: my-web-deployment-autoscaling  #с КАКИМ именем
  minReplicas: 2
  maxReplicas: 6
  metrics:                               #основываясь НА
  - type: Resource 
    resource:
      name: cpu
      targetAverageUtilization: 70       #70% vCPU perContainer
  - type: Resource
    resource:
      name: memory
      targetAverageUtilization: 80

StatefulSet — похож на Deployment, но используется для приложений, которые требуют уникальных идентификаторов, стабильных имен хостов и стабильных хранилищ (например, базы данных).

DaemonSet — гарантирует, что экземпляры Pods будут запущены на каждом Node'е в кластере. Это полезно для задач, таких как логирование, мониторинг или другие процессы, которые должны быть запущены на каждом узле.

Job — позволяет выполнять одноразовую задачу или набор задач, которые должны завершиться. Например, это может быть задача по миграции базы данных.

CronJob — аналогично Job, но задачи запускаются по расписанию, как в cron на Unix-системах.

Namespace

Namespace — изолирует ресурсы в кластере Kubernetes, позволяя разделять среду (например, для разных команд или приложений). Это помогает управлять доступом и лимитами ресурсов, способ разделить кластер на “виртуальные пространства”: для dev, test, prod и т.п. В разных namespace могут лежать свои поды, сервисы и всё остальное — удобно для изоляции, управления доступом и разделения окружений. Это даёт структуру и порядок.

Volumes в Kubernetes

Volumes — это объекты, которые обеспечивают хранение данных для Pod.

• Они не Pod сами по себе, а часть Pod’а.

• Они не контроллеры, не Service и не Network.

• Они не Cluster, не Node, не Namespace.

То есть Volumes — это ресурс внутри Pod, но на уровне runtime/исполнителя, который обеспечивает доступность данных для контейнеров.

• Volume — абстракция для хранения данных, которую можно использовать в Pods. Есть различные типы Volumes, включая временные (emptyDir) и постоянные (PersistentVolume, PersistentVolumeClaim).

• PersistentVolume (PV) и PersistentVolumeClaim (PVC) — PersistentVolume — это ресурс в кластере, представляющий собой постоянное хранилище данных, а PersistentVolumeClaim — запрос на доступ к этому хранилищу. PVC можно использовать для динамического выделения хранилища.

Как писать манифест

Манифест — это YAML (или JSON), где ты описываешь объект: apiVersion, kind (тип объекта), metadata (имя, namespace, лейблы), spec (содержимое: сколько реплик, контейнеры, порты и пр.). Kubernetes читает этот манифест и создаёт объект. Это декларативный подход: ты говоришь «чтобы было так», а K8s сам приводит в соответствие.

Вывод

Понимание, какие бывают объекты Kubernetes и зачем они нужны — это база, без которой сложно адекватно работать с кластерами. Под, Deployment, Service, ConfigMap, Secret, Namespace и другие — это кирпичики, из которых строится твоя инфраструктура. Когда ты начнёшь мыслить на уровне «объект → состояние → K8s сам приведёт всё в порядок» — работа станет куда проще и чище.