Что значит «Ванильный» Kubernetes?

Ванильный Kubernetes

«Ванильный» Kubernetes (Vanilla Kubernetes) — это чистая, неподдерживаемая версия Kubernetes, собранная напрямую из официального исходного кода без каких-либо модификаций, дополнений или специфических для поставщика оптимизаций.

Основные характеристики

Неподдерживаемое распределение — это официальный Kubernetes от CNCF, без корректировок и пакетирования от поставщиков.

Полная прозрачность — вся версия поддерживает стандартные компоненты: kubelet, kube-apiserver, kube-controller-manager, kube-scheduler, etcd.

Минимальные зависимости — без дополнительных инструментов управления, мониторинга или сетевых плагинов.

Отличие от управляемых сервисов

Managed Kubernetes (EKS, GKE, AKS)

• Облачный провайдер управляет control plane
• Автоматические обновления
• Встроенная высокая доступность
• Коммерческая поддержка

Vanilla Kubernetes

• Вы управляете всеми компонентами
• Полная ответственность за обновления
• Полная гибкость в конфигурации
• Требует собственной поддержки

Способы установки ванильного Kubernetes

kubeadm — официальный инструмент для bootstrap Kubernetes:

# На каждом сервере установить kubelet, kubeadm, kubectl
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl

# На master ноде
sudo kubeadm init --pod-network-cidr=10.244.0.0/16

# На worker нодах
sudo kubeadm join <master-ip>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

Kubernetes the Hard Way — полностью ручная установка всех компонентов для понимания архитектуры.

Kind (Kubernetes in Docker) — для разработки и тестирования.

kind create cluster --name vanilla-test
kubectl cluster-info --context kind-vanilla-test

Преимущества Vanilla Kubernetes

• Максимальная гибкость — полный контроль над конфигурацией
• Никаких vendor lock-in — полная переносимость
• Прямой доступ к исходному коду — все улучшения от сообщества
• Учебное значение — лучше всего понять внутреннее устройство
• Экономия на лицензиях — нет платежей за managed сервисы

Недостатки и вызовы

• Полная ответственность — вы отвечаете за обновления, безопасность, масштабирование
• Требует expertise — нужна глубокая компетенция в Kubernetes
• Операционные издержки — нужна собственная команда DevOps
• Обновления сложнее — требуют тщательного планирования
• Высокая доступность требует усилий — нужно самостоятельно настраивать etcd кластер

Практическая конфигурация

# Типичная архитектура
Master nodes (3+): kubeadm init
Worker nodes (N): kubeadm join
Etcd: обычно на master нодах
Networking: Flannel, Calico, Weave (вы выбираете)

Когда использовать Vanilla Kubernetes

• On-premise инсталляции — когда нет доступа к облаку
• Контролируемые окружения — когда требуется полный контроль
• Гибридные сценарии — когда нужна консистентность между облаком и on-prem
• R&D и обучение — для понимания архитектуры
• Специализированные требования — когда нужны кастомные расширения

Comparison таблица

В своей практике я использую Vanilla Kubernetes для on-premise развертываний с полным контролем и куделированным networking. Для cloud я предпочитаю managed решения (EKS), так как они позволяют сосредоточиться на приложениях, а не на операционной части.