Kubernetes (K8s) став де-факто стандартом для оркестрації контейнерів. Розроблений Google і нині підтримуваний CNCF, Kubernetes автоматизує розгортання, масштабування та управління контейнеризованими застосунками. Цей посібник проводить через налаштування локального кластера та розгортання першого застосунку.

Передумови

Базові знання Docker рекомендовані перед глибоким зануренням у Kubernetes. Контейнери є фундаментальними блоками, які оркеструє Kubernetes. Попереднє читання посібника з Docker значно полегшує розуміння представлених тут концепцій.

Розуміння архітектури Kubernetes

Kubernetes базується на архітектурі master-worker. Control Plane приймає глобальні рішення щодо кластера, тоді як Nodes виконують навантаження.

text

# Simplified Kubernetes Architecture

┌─────────────────────────────────────────────────────────────┐
│                      CONTROL PLANE                          │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐ │
│  │ API Server  │  │ Scheduler   │  │ Controller Manager  │ │
│  └─────────────┘  └─────────────┘  └─────────────────────┘ │
│  ┌─────────────────────────────────────────────────────────┐│
│  │                        etcd                             ││
│  └─────────────────────────────────────────────────────────┘│
└─────────────────────────────────────────────────────────────┘
                              │
         ┌────────────────────┼────────────────────┐
         ▼                    ▼                    ▼
┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│     NODE 1      │  │     NODE 2      │  │     NODE 3      │
│  ┌───────────┐  │  │  ┌───────────┐  │  │  ┌───────────┐  │
│  │  kubelet  │  │  │  │  kubelet  │  │  │  │  kubelet  │  │
│  ├───────────┤  │  │  ├───────────┤  │  │  ├───────────┤  │
│  │ kube-proxy│  │  │  │ kube-proxy│  │  │  │ kube-proxy│  │
│  ├───────────┤  │  │  ├───────────┤  │  │  ├───────────┤  │
│  │   Pods    │  │  │  │   Pods    │  │  │  │   Pods    │  │
│  └───────────┘  │  │  └───────────┘  │  │  └───────────┘  │
└─────────────────┘  └─────────────────┘  └─────────────────┘

API Server є точкою входу для всіх команд. etcd зберігає стан кластера. Scheduler призначає Pods до Nodes. Контролери підтримують бажаний стан системи.

Налаштування локального середовища

Існує кілька варіантів для експериментів з Kubernetes локально: minikube, kind, k3d або Docker Desktop. Minikube залишається найпопулярнішим рішенням для навчання.

bash

# terminal
# Install kubectl (Kubernetes client)
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
chmod +x kubectl
sudo mv kubectl /usr/local/bin/

# Verify installation
kubectl version --client
# Client Version: v1.31.0

# Install minikube
curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

# Start the local cluster
minikube start --driver=docker --cpus=2 --memory=4096

# Check status
minikube status
# minikube: Running
# cluster: Running
# kubectl: Configured

Minikube створює одновузловий кластер Kubernetes усередині віртуальної машини або контейнера Docker. Виділені ресурси (CPU, пам'ять) можна налаштовувати відповідно до потреб.

bash

# terminal
# Access the Kubernetes dashboard (web interface)
minikube dashboard

# Check cluster nodes
kubectl get nodes
# NAME       STATUS   ROLES           AGE   VERSION
# minikube   Ready    control-plane   5m    v1.31.0

# Detailed cluster information
kubectl cluster-info

Альтернативи Minikube

Kind (Kubernetes in Docker) запускається швидше та краще підходить для тестування CI/CD. K3d використовує k3s, легку дистрибутивну версію Kubernetes. Docker Desktop інтегрує Kubernetes напряму, але споживає більше ресурсів.

Pods: базова одиниця

Pod є найменшою одиницею для розгортання в Kubernetes. Pod інкапсулює один або кілька контейнерів, які поділяють спільну мережу та сховище.

yaml

# pod-simple.yaml
apiVersion: v1
kind: Pod
metadata:
  # Unique Pod name within the namespace
  name: nginx-pod
  # Labels for organization and selection
  labels:
    app: nginx
    environment: development
spec:
  containers:
    # Main container definition
    - name: nginx
      # Docker image to use
      image: nginx:1.25-alpine
      # Ports exposed by the container
      ports:
        - containerPort: 80
      # Container resource allocation
      resources:
        requests:
          memory: "64Mi"
          cpu: "100m"
        limits:
          memory: "128Mi"
          cpu: "200m"

Цей YAML-маніфест декларує Pod, що містить один контейнер nginx. Мітки дозволяють ідентифікувати та обирати Pods. Ресурси визначають мінімальні гарантії (requests) та максимальні обмеження (limits).

bash

# terminal
# Create the Pod
kubectl apply -f pod-simple.yaml
# pod/nginx-pod created

# List Pods
kubectl get pods
# NAME        READY   STATUS    RESTARTS   AGE
# nginx-pod   1/1     Running   0          30s

# Full Pod details
kubectl describe pod nginx-pod

# Container logs
kubectl logs nginx-pod

# Execute a command inside the Pod
kubectl exec -it nginx-pod -- /bin/sh

# Delete the Pod
kubectl delete pod nginx-pod

Pods за своєю природою є ефемерними. У разі збою або видалення Kubernetes не відтворює їх автоматично. Deployments вирішують це обмеження.

Deployments: декларативне керування

Deployment визначає бажаний стан для набору ідентичних Pods. Kubernetes автоматично підтримує цей стан, створюючи, оновлюючи або видаляючи Pods за потреби.

yaml

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  # Deployment name
  name: webapp-deployment
  labels:
    app: webapp
spec:
  # Desired number of replicas
  replicas: 3
  # Selector to identify managed Pods
  selector:
    matchLabels:
      app: webapp
  # Template for Pod creation
  template:
    metadata:
      labels:
        app: webapp
    spec:
      containers:
        - name: webapp
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"
          # Liveness probe: restarts container on failure
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10
          # Readiness probe: removes Pod from Service on failure
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5

Deployment створює ReplicaSet, який підтримує 3 ідентичних Pods. Проби перевіряють стан контейнерів та дозволяють Kubernetes автоматично реагувати на проблеми.

bash

# terminal
# Create the Deployment
kubectl apply -f deployment.yaml
# deployment.apps/webapp-deployment created

# Verify the Deployment
kubectl get deployments
# NAME                READY   UP-TO-DATE   AVAILABLE   AGE
# webapp-deployment   3/3     3            3           1m

# List Pods created by the Deployment
kubectl get pods -l app=webapp
# NAME                                READY   STATUS    RESTARTS   AGE
# webapp-deployment-7d9f8b6c4-abc12   1/1     Running   0          1m
# webapp-deployment-7d9f8b6c4-def34   1/1     Running   0          1m
# webapp-deployment-7d9f8b6c4-ghi56   1/1     Running   0          1m

# Manual scaling
kubectl scale deployment webapp-deployment --replicas=5

# Deployment history
kubectl rollout history deployment webapp-deployment

Видалення Pod автоматично запускає створення нового Pod для підтримки бажаної кількості реплік.

Готовий до співбесід з DevOps?

Практикуйся з нашими інтерактивними симуляторами, flashcards та технічними тестами.

Відкрий DevOps

Services: мережева експозиція

Pods мають ефемерні IP-адреси. Services надають стабільну адресу для доступу до набору Pods із вбудованим балансуванням навантаження.

yaml

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: webapp-service
spec:
  # Service type: ClusterIP (internal), NodePort, LoadBalancer
  type: ClusterIP
  # Selector to identify target Pods
  selector:
    app: webapp
  ports:
    # Port exposed by the Service
    - port: 80
      # Target container port
      targetPort: 80
      # Protocol (TCP by default)
      protocol: TCP

Цей Service ClusterIP доступний лише зсередини кластера. Запити до webapp-service:80 розподіляються між Pods, які мають мітку app: webapp.

bash

# terminal
# Create the Service
kubectl apply -f service.yaml
# service/webapp-service created

# List Services
kubectl get services
# NAME             TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)   AGE
# webapp-service   ClusterIP   10.96.123.456   <none>        80/TCP    30s

# Test from a temporary Pod
kubectl run curl-test --rm -it --image=curlimages/curl -- curl webapp-service

# Detailed Service description
kubectl describe service webapp-service

Щоб надати застосунку зовнішній доступ, потрібен тип NodePort або LoadBalancer.

yaml

# service-nodeport.yaml
apiVersion: v1
kind: Service
metadata:
  name: webapp-nodeport
spec:
  type: NodePort
  selector:
    app: webapp
  ports:
    - port: 80
      targetPort: 80
      # Port on each Node (30000-32767)
      nodePort: 30080

З minikube команда minikube service webapp-nodeport автоматично відкриває браузер за правильним URL.

ConfigMaps: винесена конфігурація

ConfigMaps відокремлюють конфігурацію від коду. Значення впроваджуються як змінні середовища або монтуються як файли.

yaml

# configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: webapp-config
data:
  # Simple key-value pairs
  APP_ENV: "production"
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
  # Multiline configuration (complete file)
  nginx.conf: |
    server {
        listen 80;
        server_name localhost;

        location / {
            root /usr/share/nginx/html;
            index index.html;
        }

        location /health {
            return 200 'OK';
            add_header Content-Type text/plain;
        }
    }

ConfigMaps зберігають нечутливі дані. Для секретів (паролів, токенів) краще підходять Secrets Kubernetes.

yaml

# deployment-with-config.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-configured
spec:
  replicas: 2
  selector:
    matchLabels:
      app: webapp-configured
  template:
    metadata:
      labels:
        app: webapp-configured
    spec:
      containers:
        - name: webapp
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          # Inject environment variables
          envFrom:
            - configMapRef:
                name: webapp-config
          # Or individual variables
          env:
            - name: SPECIFIC_VAR
              valueFrom:
                configMapKeyRef:
                  name: webapp-config
                  key: LOG_LEVEL
          # Mount configuration file
          volumeMounts:
            - name: nginx-config
              mountPath: /etc/nginx/conf.d/default.conf
              subPath: nginx.conf
      volumes:
        - name: nginx-config
          configMap:
            name: webapp-config

Ця конфігурація впроваджує змінні середовища та монтує файл nginx.conf усередині контейнера.

bash

# terminal
# Apply resources
kubectl apply -f configmap.yaml
kubectl apply -f deployment-with-config.yaml

# Verify environment variables
kubectl exec deployment/webapp-configured -- printenv | grep APP_ENV
# APP_ENV=production

# Verify mounted file
kubectl exec deployment/webapp-configured -- cat /etc/nginx/conf.d/default.conf

Оновлення ConfigMap

Зміна ConfigMap не перезапускає Pods автоматично. Щоб застосувати зміни, потрібен ручний перезапуск: kubectl rollout restart deployment webapp-configured. Інструменти на кшталт Reloader автоматизують цей процес.

Secrets: чутливі дані

Secrets зберігають чутливу інформацію, як-от паролі, токени або SSH-ключі. Хоча вони закодовані в base64, за замовчуванням вони не зашифровані у спокої.

yaml

# secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: webapp-secrets
type: Opaque
# Values must be base64-encoded
data:
  # echo -n 'admin' | base64
  username: YWRtaW4=
  # echo -n 'supersecretpassword' | base64
  password: c3VwZXJzZWNyZXRwYXNzd29yZA==
---
# Alternative: stringData accepts plain text values
apiVersion: v1
kind: Secret
metadata:
  name: webapp-secrets-plain
type: Opaque
stringData:
  username: admin
  password: supersecretpassword

Secrets впроваджуються так само, як і ConfigMaps.

yaml

# deployment-with-secrets.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-secure
spec:
  replicas: 1
  selector:
    matchLabels:
      app: webapp-secure
  template:
    metadata:
      labels:
        app: webapp-secure
    spec:
      containers:
        - name: webapp
          image: nginx:1.25-alpine
          env:
            - name: DB_USERNAME
              valueFrom:
                secretKeyRef:
                  name: webapp-secrets
                  key: username
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: webapp-secrets
                  key: password

bash

# terminal
# Create the Secret
kubectl apply -f secret.yaml

# List Secrets (values are not displayed)
kubectl get secrets
# NAME              TYPE     DATA   AGE
# webapp-secrets    Opaque   2      10s

# Decode a value
kubectl get secret webapp-secrets -o jsonpath='{.data.password}' | base64 -d
# supersecretpassword

Namespaces: логічна ізоляція

Namespaces поділяють кластер на ізольовані віртуальні середовища. Це розділення дозволяє керувати кількома командами або середовищами на одному кластері.

yaml

# namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: development
  labels:
    environment: development
---
apiVersion: v1
kind: Namespace
metadata:
  name: staging
  labels:
    environment: staging

Кожен ресурс можна створити в певному namespace.

bash

# terminal
# Create namespaces
kubectl apply -f namespace.yaml

# List namespaces
kubectl get namespaces
# NAME          STATUS   AGE
# default       Active   1d
# development   Active   10s
# staging       Active   10s

# Create a resource in a specific namespace
kubectl apply -f deployment.yaml -n development

# List Pods in a namespace
kubectl get pods -n development

# Change default namespace
kubectl config set-context --current --namespace=development

Ресурси в різних namespaces за замовчуванням ізольовані. Комунікація між namespaces здійснюється через внутрішній DNS: service-name.namespace.svc.cluster.local.

Повний застосунок: збирання ресурсів

Нижче наведено повний застосунок, що поєднує всі представлені концепції.

yaml

# complete-app.yaml
---
# Dedicated Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: myapp
---
# ConfigMap for configuration
apiVersion: v1
kind: ConfigMap
metadata:
  name: myapp-config
  namespace: myapp
data:
  APP_NAME: "MyApp"
  LOG_LEVEL: "info"
---
# Secret for sensitive data
apiVersion: v1
kind: Secret
metadata:
  name: myapp-secrets
  namespace: myapp
type: Opaque
stringData:
  api-key: "sk-1234567890abcdef"
---
# Deployment with 3 replicas
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
  namespace: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: myapp
          image: nginx:1.25-alpine
          ports:
            - containerPort: 80
          envFrom:
            - configMapRef:
                name: myapp-config
          env:
            - name: API_KEY
              valueFrom:
                secretKeyRef:
                  name: myapp-secrets
                  key: api-key
          resources:
            requests:
              memory: "64Mi"
              cpu: "100m"
            limits:
              memory: "128Mi"
              cpu: "200m"
          livenessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /
              port: 80
            initialDelaySeconds: 5
            periodSeconds: 5
---
# Service for internal exposure
apiVersion: v1
kind: Service
metadata:
  name: myapp-service
  namespace: myapp
spec:
  type: ClusterIP
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 80
---
# NodePort Service for external access (development)
apiVersion: v1
kind: Service
metadata:
  name: myapp-nodeport
  namespace: myapp
spec:
  type: NodePort
  selector:
    app: myapp
  ports:
    - port: 80
      targetPort: 80
      nodePort: 30100

Цей єдиний файл розгортає повний застосунок з винесеною конфігурацією, секретами, високою доступністю та мережевою експозицією.

bash

# terminal
# Deploy the complete application
kubectl apply -f complete-app.yaml

# Verify all resources
kubectl get all -n myapp
# NAME                         READY   STATUS    RESTARTS   AGE
# pod/myapp-7d9f8b6c4-abc12    1/1     Running   0          30s
# pod/myapp-7d9f8b6c4-def34    1/1     Running   0          30s
# pod/myapp-7d9f8b6c4-ghi56    1/1     Running   0          30s
#
# NAME                    TYPE        CLUSTER-IP      PORT(S)        AGE
# service/myapp-service   ClusterIP   10.96.123.456   80/TCP         30s
# service/myapp-nodeport  NodePort    10.96.123.789   80:30100/TCP   30s
#
# NAME                    READY   UP-TO-DATE   AVAILABLE   AGE
# deployment.apps/myapp   3/3     3            3           30s

# Access the application with minikube
minikube service myapp-nodeport -n myapp

Оновлення та відкат

Kubernetes полегшує поступові оновлення та відкати.

bash

# terminal
# Update the Deployment image
kubectl set image deployment/myapp myapp=nginx:1.26-alpine -n myapp

# Track deployment in real-time
kubectl rollout status deployment/myapp -n myapp
# Waiting for deployment "myapp" rollout to finish: 1 out of 3 new replicas updated
# Waiting for deployment "myapp" rollout to finish: 2 out of 3 new replicas updated
# deployment "myapp" successfully rolled out

# Revision history
kubectl rollout history deployment/myapp -n myapp
# REVISION  CHANGE-CAUSE
# 1         <none>
# 2         <none>

# Rollback to previous revision
kubectl rollout undo deployment/myapp -n myapp

# Rollback to a specific revision
kubectl rollout undo deployment/myapp --to-revision=1 -n myapp

Стандартна стратегія оновлення (RollingUpdate) поступово замінює старі Pods новими, гарантуючи безперервну доступність.

Основні команди kubectl

bash

# terminal
# ========================================
# General Information
# ========================================
kubectl cluster-info                    # Cluster info
kubectl get nodes -o wide               # Nodes with details
kubectl api-resources                   # List resource types

# ========================================
# Resource Management
# ========================================
kubectl get all                         # All namespace resources
kubectl get pods -A                     # Pods from all namespaces
kubectl get pods -o wide                # Pods with IP and Node
kubectl get pods -w                     # Watch mode (real-time)

# ========================================
# Inspection and Debugging
# ========================================
kubectl describe pod <name>             # Full details
kubectl logs <pod> -f                   # Streaming logs
kubectl logs <pod> -c <container>       # Specific container logs
kubectl exec -it <pod> -- /bin/sh       # Interactive shell
kubectl port-forward <pod> 8080:80      # Local tunnel to Pod

# ========================================
# Editing and Deletion
# ========================================
kubectl edit deployment <name>          # Live editing (vi)
kubectl delete -f manifest.yaml         # Delete via file
kubectl delete pod <name> --force       # Force deletion

Висновок

Kubernetes трансформує управління контейнеризованими застосунками, надаючи декларативний, стійкий і розширюваний фреймворк. Представлені тут фундаментальні концепції є основою для розгортань, готових до продакшену.

Чек-лист першого розгортання Kubernetes

✅ Працюючий локальний кластер (minikube, kind або k3d)
✅ Встановлений та налаштований kubectl
✅ Deployment з репліками та health probes
✅ Service для мережевої експозиції
✅ ConfigMap для винесеної конфігурації
✅ Secret для чутливих даних
✅ Namespace для ізоляції
✅ Визначені обмеження ресурсів (requests/limits)
✅ Освоєна стратегія оновлення та відкату

Починай практикувати!

Перевір свої знання з нашими симуляторами співбесід та технічними тестами.

Створити безкоштовний обліковий запис

Оволодіння Kubernetes відкриває двері до масштабованих cloud-native архітектур. Наступні кроки включають вивчення Ingress Controllers для маршрутизації HTTP, PersistentVolumes для зберігання та Helm для управління пакетами. Kubernetes стає важливим активом під час співбесід DevOps та SRE.

Kubernetes: розгортання першого застосунку

Розуміння архітектури Kubernetes

Налаштування локального середовища

Pods: базова одиниця

Deployments: декларативне керування

Готовий до співбесід з DevOps?

Services: мережева експозиція

ConfigMaps: винесена конфігурація

Secrets: чутливі дані

Namespaces: логічна ізоляція

Повний застосунок: збирання ресурсів

Оновлення та відкат

Основні команди kubectl

Висновок

Чек-лист першого розгортання Kubernetes

Починай практикувати!

Чи знайдеш ти помилку в DevOps?

Пов'язані статті

Ключові питання на DevOps-співбесіді: повний посібник 2026

Docker: від розробки до продакшну

Керування Секретами Kubernetes у 2026: External Secrets, Vault та Питання для Співбесід