1 
2Если вы работаете в мире разработки программного обеспечения, вы наверняка слышали о Kubernetes. Но что это такое и почему он стал стандартом де-факто для управления контейнеризированными приложениями? Это руководство проведёт вас от основ к ключевым концепциям с практическими примерами и диаграммами.
3 
4## До Kubernetes: немного истории
5 
6Чтобы понять, почему Kubernetes настолько революционен, сделаем шаг назад.
7 
81.  **Традиционное развёртывание**: изначально приложения запускались на физических серверах. Этот подход был дорогим, сложно масштабируемым и подверженным конфликтам ресурсов.
92.  **Виртуализированное развёртывание**: затем появились виртуальные машины (ВМ). ВМ позволяли запускать несколько изолированных приложений на одном оборудовании, улучшая использование ресурсов и безопасность. Однако каждая ВМ запускает полноценную операционную систему, потребляя много ресурсов.
103.  **Контейнерное развёртывание**: контейнеры (например, Docker)  -  следующий этап эволюции. Они используют общую операционную систему хоста, но запускают изолированные процессы. Они лёгкие, быстро запускаются и переносимы.
11 
12Контейнеры решили проблему переносимости, но создали другую: как управлять сотнями (или тысячами) контейнеров в продакшн-среде? Как гарантировать, что они всегда работают, могут взаимодействовать друг с другом и масштабироваться в зависимости от нагрузки?
13 
14Здесь на сцену выходит **Kubernetes**.
15 
16## Что такое Kubernetes?
17 
18Kubernetes (часто сокращают до **K8s**)  -  это платформа с открытым исходным кодом для оркестрации контейнеров. Простыми словами, она автоматизирует развёртывание, масштабирование и управление контейнеризированными приложениями. Создан Google и теперь поддерживается Cloud Native Computing Foundation (CNCF), Kubernetes стал основным инструментом для всех, кто работает с микросервисами в масштабе.
19 
20## Архитектура кластера Kubernetes
21 
22Среда Kubernetes называется **кластером**. Кластер состоит из набора машин, называемых **нодами** (nodes), которые запускают наши приложения. Архитектура разделена на две основные части: Control Plane и Worker Nodes.
23 
24```mermaid
25graph TD
26    subgraph "Control Plane (Master)"
27        A["API Server"]
28        B["etcd"]
29        C["Scheduler"]
30        D["Controller Manager"]
31    end
32 
33    subgraph "Worker Node 1"
34        E["Kubelet"] --- F["Container Runtime"]
35        G["Kube-proxy"]
36        F --- H["Pod"]
37        F --- I["Pod"]
38    end
39 
40    subgraph "Worker Node 2"
41        J["Kubelet"] --- K["Container Runtime"]
42        L["Kube-proxy"]
43        K --- M["Pod"]
44    end
45 
46    A -- "Communicates with" --> E
47    A -- "Communicates with" --> J
48    User -- "kubectl" --> A
49    C -- "Assigns Pods to Nodes" --> E
50    D -- "Maintains state" --> A
51    A -- "Saves/Reads state" --> B
52```
53 
54### Control Plane
55 
56Control Plane  -  это «мозг» кластера. Он принимает глобальные решения (такие как планирование) и обнаруживает события кластера и реагирует на них. Его основные компоненты:
57 
58-   **API Server (`kube-apiserver`)**: шлюз кластера. Он предоставляет API Kubernetes, который используется пользователями (через `kubectl`), компонентами кластера и внешними инструментами для взаимодействия.
59-   **etcd**: согласованная и высокодоступная база данных «ключ-значение». Хранит все данные кластера, представляя желаемое и текущее состояние системы.
60-   **Scheduler (`kube-scheduler`)**: назначает вновь созданные Pods на доступные Worker Nodes с учётом требований к ресурсам, политик и других ограничений.
61-   **Controller Manager (`kube-controller-manager`)**: запускает контроллеры  -  циклы управления, которые отслеживают состояние кластера и работают над приведением его к желаемому состоянию. Например, `Node Controller` управляет нодами, а `Replication Controller` обеспечивает работу нужного количества Pods.
62 
63### Worker Node
64 
65Worker Nodes  -  это машины (физические или виртуальные), на которых фактически работают приложения. Каждая нода управляется Control Plane и содержит следующие компоненты:
66 
67-   **Kubelet**: агент, работающий на каждой ноде. Обеспечивает запуск и работоспособность контейнеров, описанных в Pods.
68-   **Kube-proxy**: сетевой прокси, управляющий сетевыми правилами на нодах. Позволяет выполнять сетевое взаимодействие с Pods из сессий внутри или снаружи кластера.
69-   **Container Runtime**: программное обеспечение, отвечающее за запуск контейнеров. Docker наиболее известен, но Kubernetes также поддерживает другие среды выполнения, такие как `containerd` и `CRI-O`.
70 
71## Основные объекты Kubernetes
72 
73В Kubernetes всё представлено **объектами**. Эти объекты  -  «записи намерений»: создав объект, Kubernetes постоянно работает над тем, чтобы он существовал и соответствовал желаемому состоянию.
74 
75Вот наиболее важные:
76 
77### Pod
78 
79**Pod**  -  наименьшая единица выполнения в Kubernetes. Он представляет один или несколько контейнеров, которые работают вместе на одной ноде, разделяя ресурсы, такие как сеть и хранилище.
80 
81Обычно в Pod запускается только один контейнер, но в продвинутых сценариях (например, «sidecar containers» для логирования или мониторинга) их может быть больше.
82 
83Вы почти никогда не создаёте Pods напрямую. Используются абстракции более высокого уровня, такие как Deployments.
84 
85### Deployment
86 
87**Deployment**  -  объект, который вы будете использовать чаще всего. Он описывает желаемое состояние для группы идентичных Pods. Контроллер Deployment отвечает за:
88 
89-   Создание и управление **ReplicaSet** (другой объект, обеспечивающий запуск определённого количества реплик Pod).
90-   **Масштабирование** количества Pods вверх или вниз.
91-   Управление **обновлениями** приложения контролируемым образом (например, *Rolling Update*) без простоя.
92 
93Пример YAML-файла для Deployment, запускающего 3 реплики сервера NGINX:
94 
95```yaml
96# nginx-deployment.yaml
97apiVersion: apps/v1
98kind: Deployment
99metadata:
100  name: nginx-deployment
101spec:
102  replicas: 3
103  selector:
104    matchLabels:
105      app: nginx
106  template:
107    metadata:
108      labels:
109        app: nginx
110    spec:
111      containers:
112      - name: nginx
113        image: nginx:1.14.2
114        ports:
115        - containerPort: 80
116```
117 
118### Service
119 
120Pods в Kubernetes эфемерны: они могут создаваться и уничтожаться в любой момент. У каждого Pod есть собственный IP-адрес, но он нестабилен. Как же надёжно предоставить доступ к приложению?
121 
122С помощью **Service**. Service  -  это абстракция, определяющая логический набор Pods и политику доступа к ним. Он предоставляет **стабильную точку доступа** (виртуальный IP-адрес и DNS-имя) для группы Pods.
123 
124```mermaid
125graph TD
126    subgraph "Service (nginx-service)"
127        A["ClusterIP: 10.96.0.10"]
128    end
129 
130    subgraph "Pods"
131        B("Pod 1 - IP: 192.168.1.2")
132        C("Pod 2 - IP: 192.168.1.3")
133        D("Pod 3 - IP: 192.168.1.4")
134    end
135 
136    A -- "Selector: app=nginx" --> B
137    A -- "Selector: app=nginx" --> C
138    A -- "Selector: app=nginx" --> D
139 
140    Client -- "Request to nginx-service" --> A
141```
142 
143Service использует `selector` на основе `labels` для поиска Pods, к которым нужно направлять трафик.
144 
145Как создать Service для нашего NGINX Deployment:
146 
147```yaml
148# nginx-service.yaml
149apiVersion: v1
150kind: Service
151metadata:
152  name: nginx-service
153spec:
154  selector:
155    app: nginx
156  ports:
157    - protocol: TCP
158      port: 80
159      targetPort: 80
160  type: ClusterIP # Default - exposes the service only within the cluster
161```
162 
163Существуют различные типы Services:
164- `ClusterIP`: предоставляет доступ к сервису по внутреннему IP кластера (по умолчанию).
165- `NodePort`: предоставляет доступ к сервису через статический порт на каждой Worker Node.
166- `LoadBalancer`: создаёт внешний балансировщик нагрузки в облачном провайдере (например, AWS, GCP) и назначает публичный IP сервису.
167 
168### Ingress
169 
170Service типа `LoadBalancer` удобен, но создание его для каждого сервиса может быть дорогим. Для предоставления нескольких HTTP/HTTPS-сервисов внешнему миру используется **Ingress**.
171 
172Ingress действует как «интеллектуальный маршрутизатор» для внешнего трафика. Он позволяет определять правила маршрутизации на основе хоста (например, `api.mysite.com`) или пути (например, `mysite.com/api`).
173 
174```mermaid
175graph LR
176    User -- "mysite.com/api" --> Ingress
177    User -- "mysite.com/ui" --> Ingress
178 
179    subgraph "Cluster"
180        Ingress -- "/api" --> ServiceA("api-service")
181        Ingress -- "/ui" --> ServiceB("ui-service")
182 
183        ServiceA --> PodA1("API Pod 1")
184        ServiceA --> PodA2("API Pod 2")
185 
186        ServiceB --> PodB1("UI Pod 1")
187        ServiceB --> PodB2("UI Pod 2")
188    end
189```
190 
191Пример Ingress:
192```yaml
193# example-ingress.yaml
194apiVersion: networking.k8s.io/v1
195kind: Ingress
196metadata:
197  name: example-ingress
198spec:
199  rules:
200  - host: mysite.com
201    http:
202      paths:
203      - path: /api
204        pathType: Prefix
205        backend:
206          service:
207            name: api-service
208            port:
209              number: 8080
210      - path: /ui
211        pathType: Prefix
212        backend:
213          service:
214            name: ui-service
215            port:
216              number: 3000
217```
218 
219### Другие полезные объекты
220 
221-   **Namespace**: позволяет создавать «виртуальные кластеры» внутри физического кластера. Полезно для изоляции сред (например, `development`, `staging`, `production`) или команд.
222-   **ConfigMap и Secret**: для управления конфигурационными данными и секретами (паролями или API-ключами), отделёнными от образа контейнера.
223-   **StatefulSet**: аналогичен Deployment, но предназначен для приложений с сохранением состояния (например, баз данных), требующих стабильных сетевых идентификаторов и постоянного хранилища.
224-   **PersistentVolume (PV) и PersistentVolumeClaim (PVC)**: для управления постоянным хранилищем в кластере.
225 
226## Заключение
227 
228Kubernetes  -  невероятно мощный инструмент, но его кривая обучения может быть крутой. Это руководство лишь затронуло поверхность, но мы надеемся, что оно дало вам прочное понимание базовых концепций.
229 
230**Что делать дальше?**
231- **Экспериментируйте локально**: установите [Minikube](https://minikube.sigs.k8s.io/docs/start/) или [Kind](https://kind.sigs.k8s.io/docs/user/quick-start/) для создания кластера Kubernetes на вашем компьютере.
232- **Используйте `kubectl`**: освойте команду `kubectl`  -  ваш основной инструмент взаимодействия с кластером. Попробуйте создать NGINX Deployment и Service из этой статьи.
233- **Изучите официальные туториалы**: [документация Kubernetes](https://kubernetes.io/docs/tutorials/)  -  отличный ресурс с множеством примеров.
234 
235Оркестрация контейнеров  -  фундаментальный навык в мире cloud-native, и владение Kubernetes откроет перед вами мир возможностей. Удачи!
236