Как разворачивал кластер Kubernetes

Мой подход к развёртыванию кластера Kubernetes

Развёртывание кластеров Kubernetes — ключевая часть моей работы как DevOps-инженера. Я использую разные подходы в зависимости от контекста: локальная разработка, staging-среда или production-кластеры в облаке. Вот мой комплексный подход, отточенный за годы практики.

1. Выбор инструмента развёртывания

Для разных целей я использую разные инструменты:

• Для локальной разработки и тестирования: Minikube, k3d (K3s в Docker) или Kind (Kubernetes in Docker). Они легковесны и позволяют быстро создавать/уничтожать кластеры.
• Для production-сред: kubeadm для контроля над каждым компонентом или управляемые сервисы (EKS, GKE, AKS), которые снимают нагрузку по управлению control plane.

2. Развёртывание production-кластера с помощью kubeadm (on-premise/cloud VMs)

Этот подход даёт максимальный контроль. Шаги детально проработаны и автоматизированы.

Подготовка инфраструктуры и хостов

# Пример Ansible-плейбука для подготовки хостов (фрагмент)
- name: Prepare Kubernetes cluster nodes
  hosts: k8s_nodes
  become: yes
  tasks:
    - name: Disable swap
      command: swapoff -a
      register: swap_result

    - name: Remove swap from /etc/fstab
      replace:
        path: /etc/fstab
        regexp: '^.*swap.*$'
        replace: '# \g<0>'

    - name: Load kernel modules
      modprobe:
        name: "{{ item }}"
        state: present
      loop:
        - br_netfilter
        - overlay

    - name: Configure sysctl params
      sysctl:
        name: "{{ item.name }}"
        value: "{{ item.value }}"
        state: present
        reload: yes
      loop:
        - { name: 'net.bridge.bridge-nf-call-iptables', value: '1' }
        - { name: 'net.ipv4.ip_forward', value: '1' }

    - name: Install Docker CE
      apt:
        name: docker-ce
        state: present

Инициализация control plane

На первом master-узле выполняю инициализацию с предварительно настроенным конфигурационным файлом.

# kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: 1.28.0
controlPlaneEndpoint: "load-balancer.example.com:6443" # Указываю адрес балансировщика
networking:
  podSubnet: "10.244.0.0/16" # Для Calico или Flannel
  serviceSubnet: "10.96.0.0/12"
apiServer:
  extraArgs:
    advertise-address: 192.168.1.100

# Инициализация кластера
sudo kubeadm init --config=kubeadm-config.yaml --upload-certs

# Настройка доступа для обычного пользователя
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Установка сетевого плагина (CNI)

Без CNI поды не смогут "общаться". Чаще всего выбираю Calico или Cilium (для eBPF-фич).

# Установка Calico
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# Проверка установки
kubectl get pods -n kube-system -l k8s-app=calico-node

Присоединение worker-узлов

На каждом worker-узле выполняю команду kubeadm join, полученную после инициализации control plane.

sudo kubeadm join load-balancer.example.com:6443 \
  --token <token> \
  --discovery-token-ca-cert-hash sha256:<hash>

3. Использование инфраструктурного кода (IaC) для облачных кластеров

Для production в облаке я предпочитаю объявлять кластер как код, используя Terraform или Pulumi, вместе с managed-сервисами.

# Пример Terraform для AWS EKS
resource "aws_eks_cluster" "production" {
  name     = "production-cluster"
  role_arn = aws_iam_role.eks_cluster.arn
  version  = "1.28"

  vpc_config {
    subnet_ids = [aws_subnet.private_1.id, aws_subnet.private_2.id]
  }

  depends_on = [
    aws_iam_role_policy_attachment.eks_cluster_policy
  ]
}

resource "aws_eks_node_group" "workers" {
  cluster_name    = aws_eks_cluster.production.name
  node_group_name = "linux-workers"
  node_role_arn   = aws_iam_role.eks_node.arn
  subnet_ids      = [aws_subnet.private_1.id, aws_subnet.private_2.id]

  scaling_config {
    desired_size = 3
    max_size     = 6
    min_size     = 3
  }
}

4. Пост-установочная настройка и "закаливание" кластера

После развёртывания выполняю стандартный набор действий:

1. Настройка контроля доступа (RBAC): Создаю ServiceAccount'ы, ClusterRole и ClusterRoleBinding для CI/CD и членов команды.
2. Установка системных компонентов:

    *   **Ingress-контроллер** (чаще Nginx или Traefik).
    *   **ExternalDNS** для автоматического управления DNS-записями.
    *   **Cert-manager** для автоматического получения SSL-сертификатов от Let's Encrypt.
    *   **Мониторинг:** Устанавливаю **Prometheus Stack** (Grafana, Alertmanager) или коммерческие решения.
    *   **Логирование:** Настраиваю **Fluentd** или **Fluent Bit** для сбора логов и их отправки в **Elasticsearch** или **Loki**.

1. Применение политик безопасности: Использую OPA Gatekeeper или Kyverno для создания и enforcement политик (например, запрет запуска подов от root, требования к меткам).
2. Настройка бэкапа: Разворачиваю Velero для резервного копирования ресурсов Kubernetes и persistent volumes.

5. Автоматизация и CI/CD для самого кластера

Конфигурация самого кластера также хранится в Git и применяется через GitOps-подход. Я использую ArgoCD или Flux для непрерывной синхронизации желаемого состояния (описанного в Helm charts или Kustomize) с фактическим состоянием в кластере.

# Пример Application CRD для ArgoCD
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: monitoring-stack
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/my-org/gitops-configs.git
    targetRevision: HEAD
    path: clusters/production/monitoring
  destination:
    server: https://kubernetes.default.svc
    namespace: monitoring
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Ключевые принципы моего подхода

• Идемпотентность: Все шаги автоматизированы и могут выполняться многократно с одинаковым результатом.
• Воспроизводимость: Кластер можно воссоздать с нуля в любой момент с минимальными усилиями.
• Безопасность с самого начала: Применение политик безопасности, использование минимально необходимых привилегий, шифрование секретов (с помощью Sealed Secrets или внешних хранилищ типа HashiCorp Vault).
• Масштабируемость: Архитектура кластера (отдельные subnets для узлов, использование managed-сервисов для etcd) позволяет легко масштабироваться.

Такой многослойный подход — от выбора инструмента до полной GitOps-автоматизации — позволяет создавать стабильные, безопасные и легко управляемые Kubernetes-кластеры, соответствующие требованиям enterprise-среды.