Что будете использовать для построения логики ванильного Kubernetes на облаке и bare metal

Общая архитектура и философия

Для построения производственной логики Kubernetes как на облачной, так и на bare metal инфраструктуре я применяю идиоматический подход GitOps с полной декларативностью и версионностью всей конфигурации. Ключевые принципы:

• Everything as Code (инфраструктура, конфигурация, политики)
• Минимальные отклонения от ванильного Kubernetes
• Стратегия разделения ответственности между платформенными и продуктовыми командами
• Единый процесс поставки для всех сред (cloud/bare metal)

Технологический стек для управления состоянием

1. Инфраструктурный слой (Provisioning)

Для облака и bare metal использую разные инструменты, но с единым интерфейсом:

# Пример структуры Terraform модуля для мульти-области
modules/kubernetes-platform/
├── cloud-provider/    # AWS/GCP/Azure специфичная логика
├── bare-metal/        # MetalLB, local-path-provisioner
├── common/           # Общие ресурсы (VPC, сеть, FW)
└── outputs.tf        # Единый интерфейс вывода

Для облачных провайдеров:

• Terraform с облачными провайдерами для управления ресурсами
• Использование managed-сервисов (EKS, GKE, AKS) где возможно
• Crossplane для унифицированного управления ресурсами нескольких облаков

Для bare metal:

• Terraform с провайдерами для физических устройств (например, для сетевого оборудования)
• Metal³ (Metal Kubed) для provisioning bare metal нод
• Ansible для предварительной настройки серверов (прошивка BIOS, RAID, сеть)

2. Конфигурация кластера (Day 1 Operations)

# Пример структуры кластерного конфига в Git
clusters/production/
├── base/
│   ├── cert-manager/
│   ├── ingress-nginx/
│   ├── monitoring-stack/
│   └── cluster-autoscaler/
├── cloud/           # Облачные специфичные конфиги
├── bare-metal/      # Bare metal специфичные конфиги
└── kustomization.yaml

Использую комбинацию:

• Cluster API (CAPI) для декларативного управления жизненным циклом кластеров
• kubeadm в связке с Ansible для ванильных bare metal установок
• Kustomize для управления конфигурациями с учетом окружения

3. GitOps-движок (Day 2 Operations)

Flux CD в качестве основного GitOps-оператора:

apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: platform-apps
  namespace: flux-system
spec:
  interval: 5m
  path: "./clusters/production"
  prune: true
  sourceRef:
    kind: GitRepository
    name: platform-manifests
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: ingress-nginx-controller
      namespace: ingress-nginx

Аргументы для выбора Flux:

• Более зрелая поддержка мульти-тенантности через Kustomization/HelmRelease CRD
• Встроенные политики зависимостей и здоровья
• Уведомления через Notification Controller
• Нативная интеграция с SOPS для шифрования секретов

4. Сетевая абстракция

Для решения различий между облаком и bare metal:

Ingress Controller:

• ingress-nginx как стандартный ингрес-контроллер
• Для bare metal: MetalLB в режиме BGP или L2
• Для облака: Cloud Provider LB интеграция

Service Mesh:

• Linkerd как легковесный service mesh
• Или Istio для сложных сценариев (при наличии ресурсов)

# Установка MetalLB для bare metal
helm upgrade --install metallb metallb/metallb \
  --namespace metallb-system \
  --create-namespace \
  --values values-baremetal.yaml

5. Хранилище (Storage)

Самое критичное различие между облаком и bare metal:

# StorageClass для разных окружений
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: # Зависит от окружения:
  # Облако: pd.csi.storage.gke.io (GKE), ebs.csi.aws.com (EKS)
  # Bare metal: rancher.io/local-path, cephfs.csi.ceph.com

Стратегия:

• Облако: CSI драйверы облачного провайдера
• Bare metal: Rook/Ceph или OpenEBS для распределенного хранилища
• Local storage: local-path-provisioner для разработки и некоторых production workloads

6. Мониторинг и логирование

Единый стек поверх различий инфраструктуры:

# Пример Prometheus Operator для всех сред
prometheus:
  prometheusSpec:
    storageSpec:
      volumeClaimTemplate:
        spec:
          storageClassName: fast-ssd # Абстрагирован от инфраструктуры
          resources:
            requests:
              storage: 200Gi

Использую:

• Prometheus Stack (kube-prometheus-stack)
• Loki для логов с Promtail
• Grafana как единую панель управления

7. Безопасность и политики

# Единые политики через OPA/Gatekeeper
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequiredLabels
metadata:
  name: namespace-mandatory-labels
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Namespace"]
  parameters:
    labels: ["environment", "team"]

• OPA/Gatekeeper для политик безопасности и compliance
• Kyverno для простых политик и mutation
• Cilium как CNI с поддержкой Network Policies и eBPF

Стратегия реализации различий

Облачные специфики:

1. Auto Scaling: Cluster Autoscaler + Cloud Provider
2. Load Balancing: Cloud Provider интеграция
3. Managed Services: Использование cloud-managed вариантов (RDS, ElastiCache)

Bare metal специфики:

1. Load Balancing: MetalLB или Keepalived VIP
2. Storage: Rook/Ceph или локальное хранилище
3. Резервирование: ручное планирование или с использованием kubevirt для виртуализации

Паттерны управления конфигурацией

# Использование Kustomize overlays
bases:
  - ../../base
patchesStrategicMerge:
  - loadbalancer-patch.yaml
  - storage-patch.yaml
configMapGenerator:
  - name: environment-config
    literals:
      - PLATFORM_TYPE=${PLATFORM_TYPE} # cloud или bare-metal

Заключение

Такой подход позволяет:

1. Создать единую платформу с различиями только на нижних уровнях
2. Обеспечить переносимость workload'ов между средами
3. Минимизировать операционные расходы через унификацию процессов
4. Соответствовать compliance требованиям через единые политики

Ключевой успех в построении такой системы — строгая дисциплина GitOps и инвестиции в создание правильных абстракций, которые скрывают различия инфраструктуры от разработчиков, предоставляя им единый интерфейс Kubernetes API независимо от того, где развернут кластер.