Настройка базовых параметров Kubernetes

Введение

Kubernetes сегодня — это стандарт де-факто для управления контейнеризированными приложениями. Однако эффективная работа кластера невозможна без правильной настройки базовых параметров. Здесь я расскажу, как подходит к этой задаче, на какие моменты стоит обратить внимание, и как добиться безопасности и стабильности вашей инфраструктуры с первого шага. Мы подробно разберём ключевые параметры, способы их изменения и рекомендации по их использованию.

Родоначальные понятия: Как устроен Kubernetes

Прежде чем настраивать кластер, полезно понять, что из себя представляет Kubernetes. Вся система строится на так называемых ресурсах — это сущности, описывающие приложения, вычислительные ресурсы кластера, сетевые политики и многое другое. Самыми базовыми объектами выступают узлы (nodes), на которых запускаются контейнеры, и управляющие компоненты Control Plane.

Control Plane и рабочие узлы (worker nodes)

• Control Plane — принимает решения о расписании контейнеров, хранит состояние кластера, контролирует коммуникацию.
• Worker nodes — именно здесь ваши контейнеры запускаются и обслуживаются.

Общение между этими компонентами осуществляется через API сервер, а вся конфигурация хранится в etcd.

Теперь, когда есть базовое понимание, давайте перейдём к первичным настройкам после установки кластера.

Базовые параметры и их настройка

Настройка kubelet'а — сердца node

kubelet — это агент, который устанавливается на каждом узле. Он следит за тем, чтобы контейнеры соответствовали желаемому состоянию, описанному в параметрах Kubernetes.

Пример настройки флага max-pods

Этот параметр регулирует максимальное количество Pod'ов на одном worker-узле. Вот как можно изменить его в файле запуска kubelet:

# Добавьте параметр max-pods при запуске kubelet
--max-pods=110

Комментарий:
По умолчанию значение часто бывает 110, но для некоторых сценариев, например, при ограниченных ресурсах узла, иногда нужно выставлять меньшее значение — это позволит избежать перегрузки.

Изменение значения на уже работающем узле (пример для systemd)

# Откройте файл конфигурации kubelet
sudo vi /etc/systemd/system/kubelet.service.d/10-kubeadm.conf

# Найдите строку с Environment="KUBELET_CONFIG_ARGS=..." и добавьте/отредактируйте
--max-pods=80 \
# Перезапустите сервис
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Настройка сети: параметры kubernetes networking

Kubernetes поддерживает разные модели сетей. Важнейшие параметры — это CIDR под сеть подов и услуг.

Пример задания сети для подов и сервисов

Обычно эти параметры передаются при инициализации кластера через kubeadm:

# Пример инициализации кластера с указанием сетевых диапазонов
kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --service-cidr=10.96.0.0/12

Комментарий:
CIDR-диапазоны больше менять нельзя, когда кластер уже создан. Они определяют, где будут размещаться IP подов и сервисов, и должны совпадать с поддерживаемыми вашими сетевыми плагинами (например, Flannel, Calico).

API Server: важные параметры и доступ

Kube-apiserver — центральное место общения между пользователями, автоматикой и компонентами кластера. Через его параметры можно регулировать многое: от безопасности до лимитов обращения.

Пример задания лимита на входящий трафик

--max-requests-inflight=400
--max-mutating-requests-inflight=200

Комментарий:
Эти параметры полезны, чтобы защитить кластер от резких всплесков нагрузки. Значения чаще всего подбирают опытным путем, чтобы избежать перегрузки Control Plane.

Включение RBAC-аутентификации

RBAC — это система контроля доступа на основе ролей.

# Включаем RBAC как флаг apiserver
--authorization-mode=Node,RBAC

Комментарий:
Без этой настройки любые пользователи с доступом к API смогут выполнять опасные действия!

Настройка resource limits и requests

Вы должны управлять ресурсами, выделяемыми подам. Это помогает предотвратить «захват» ресурсов одним контейнером.

Пример описания в манифесте (YAML)

apiVersion: v1
kind: Pod
metadata:
  name: resource-demo
spec:
  containers:
  - name: demo
    image: nginx
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"

Комментарий:
requests — это минимум, который будет выделен, а limits — максимум, который сможет занять контейнер. Если контейнер превысит лимит по памяти, его остановят OOM killer-ом.

Подключение кластера к внешнему хранилищу (Persistent Volumes)

Kubernetes позволяет управлять хранилищем с помощью Persistent Volume (PV) и Persistent Volume Claim (PVC).

Пример создания PV и PVC

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

Комментарий:
PV описывает реальное хранилище, PVC — запрос от пода. Как только PVC совпадает с PV, он автоматически монтируется в нужный под.

Настройка логирования и аудит Kubernetes

Без централизованного логирования трудно поддерживать безопасность и отлаживать кластер.

Пример настройки логирования приложений

В Kubernetes принято выводить логи в stdout/stderr контейнеров, а затем собирать их через специализированные решения (например, Fluentd, Loki, ELK).

# В pod-контейнере ваше приложение должно логировать в стандартный вывод
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date); sleep 5; done"]

Включение аудита событий API

Можно включить аудит событий — эти логи помогают анализировать кто и что делает с кластером.

--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100

Комментарий:
Далее к файлам аудита можно подключить сборщики логов.

Конфигурирование kubeconfig

Ваш доступ к кластеру осуществляется через kubeconfig — файл, используемый, например, kubectl.

Получение и настройка kubeconfig

# После инициализации кластера получите kubeconfig
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

Комментарий:
Теперь kubectl будет знать, как подключаться к вашему кластеру.

Настройка Namespace и изоляция

Namespaces — инструмент для изоляции ресурсов внутри кластера, по сути, виртуальные окружения.

Пример создания namespace

kubectl create namespace dev-environment

Использование namespace

kubectl run nginx --image=nginx --namespace=dev-environment

Комментарий:
Таким способом удобно разделять ресурсы и доступы по командам/продуктам.

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

Большинство Kubernetes-кластеров требует отдельного сетевого плагина для корректной работы межподовой сетевой коммуникации.

Пример установки Flannel

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

Настройка autoscaling базовых параметров

Kubernetes поддерживает автоскейлинг подов и узлов.

Пример Horizontal Pod Autoscaler

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-demo
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: demo-deployment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

Комментарий:
Это автоматически масштабирует ваш deployment при увеличении нагрузки по CPU.

Заключение

Настройка базовых параметров Kubernetes — это обязательный этап для продуктивной и стабильной работы ваших приложений. Мы рассмотрели ключевые настройки, которые необходимо задавать в самом начале: лимиты ресурсов, сетевые параметры, параметры безопасности и аутентификации, работу с логами, хранилищем, namespace и масштабированием. Такой подход обеспечивает вам управляемость, безопасность и надежность инфраструктуры, экономит ресурсы и время в дальнейшем.

Частозадаваемые технические вопросы по теме статьи и ответы на них

Как изменить сетевой диапазон для подов после инициализации кластера?

Изменение диапазона сети после инициализации невозможно стандартными средствами — рекомендуется пересоздать весь кластер с правильным параметром --pod-network-cidr при kubeadm init. Перед этим сохраните манифесты, чтобы можно было развернуть их повторно.

Как включить автозапуск подов после перезагрузки worker-узлов?

Поды автоматически восстанавливаются после рестарта, если используются реплика-сеты или deployment. Для статических подов убедитесь, что файлы с их описаниями находятся в /etc/kubernetes/manifests/.

Как добавить новый worker node в существующий кластер?

Сначала получите команду для join с master узла (kubeadm token create --print-join-command). Выполните её на новом worker. Проверьте, что firewall и сеть настроены — порты 6443, 10250 и канал overlay-плагина должны быть открыты.

Что делать, если pod не стартует из-за ошибки OOMKilled?

Повысьте лимиты памяти для контейнера в секции resources.limits.memory вашего pod/deployment YAML. Оцените, есть ли в кластере свободная память, или добавьте node или уменьшите требования других подов.

Как защитить доступ к API серверу Kubernetes извне?

Для защиты отключите проброс портов master наружу или используйте только контролируемые ingress-настройки, включите RBAC, настройте firewall, используйте kubectl proxy, а для удаленного доступа всегда применяйте kubeconfig с минимальными правами и туннели VPN/TLS.