Kubernetes как сервис использует общую архитектуру: на хост‑кластере развертываются виртуальные кластеры (control plane), которые работают изолированно друг от друга. Для доступа к kube‑api виртуального кластера предоставляется kubeconfig. Его можно добавить либо в `~user/.kube/config`, либо в настольные дашборды управления Kubernetes, такие как Lens или Headlamp.

• Руководство по установке Lens
• Руководство по установке Headlamp

• Версия Kubernetes: 1.32.8
• Каждый виртуальный кластер имеет собственные control plane, etcd и CoreDNS, отделённые от хост‑кластера.
• Каждый pod в кластере запускается в user namespace и получает уникальные непривилегированные UID и GID на хост‑кластере. Это позволяет контейнерам использовать pid 0 внутри pod.
• Всем pod в кластере автоматически назначаются fsgroup и supplemental group с фиксированным ID для данного кластера.
• В контейнерах pod обязательно должны быть указаны ресурсы. По умолчанию всем контейнерам в кластере назначаются:

limits:
  memory: 100Mi
requests:
  ephemeral-storage: 200Mi
  memory: 100Mi
  cpu: 100m

• В дашбордах отображаемые ресурсы нод и их использование не соответствуют действительности. Эти показатели сгенерированы и не несут полезной информации.
• За размещение pod на нодах отвечает scheduler хост‑кластера.
• Использование CPU и памяти для pod отображается согласно данным metrics server хост‑кластера.

• Для внешнего доступа к сервисам предоставляется LoadBalancer IP.
• Рекомендуется использовать Ingress Controller и привязывать к нему сервисы, которым необходим внешний доступ.
• Control plane виртуальных кластеров (persistent volumes для etcd и конфигурация кластера) резервируется со стороны хост‑кластера.
• Дополнительно мы можем выполнять резервное копирование persistent volumes ваших pod.
• Виртуальные кластеры также могут использовать k8up для резервного копирования persistent volumes.
• Если используется база данных, резервное копирование можно выполнять средствами соответствующего оператора базы данных, например Percona Operator.