Handbook

# Kubernetes

# Рекомендации

# По архитектуре кластеров

# Prod (production) кластеры

  • Микрокластеры - каждой группе проектов свой кластер. Этим мы снижем вероятность single point of failure.
    • Предпочитаем брать несколько небольших серверов, чем один крупный.
    • Держим запас ресурсов 20-30% на случай скачков нагрузки.
    • При возможности используем LoadBalancer.
  • Допустимо держать несколько групп проектов, если на них не ожидается большой нагрузки.
  • Группа проектов должна также быть объединена в подгруппу (subgroup) в Gitlab.
  • Namespace имеет то же название, что группа проектов (. заменены на -). Также в Rancher должен быть заведен Project для мониторинга.
  • Поднимаем Prometheus/Grafana для каждой группы проектов через Rancher.
  • Если проект использует PostgreSQL и требуется хорошая производительность, лучше поднять HA кластер (смотрите проект apliteni/infra/postgres-cluster).

# Dev (Development) кластеры

  • Монолитные.
    • Максимально выжимаем ресурсы из кластера, прежде чем добавляем новые ноды.
    • Берем для кластера более крупные сервера.
    • Не используем LoadBalancer.
  • Namespace должен быть по имени проекта или по имени группы проектов (. заменены на -).
    • Если необходимо разделить на окружения, добавляем к названию: project-staging, project-test.
  • Не запускаем на проекте ничего, что может использоваться публично или требует высокого HA (High Availability).
  • Поднимаем Prometheus/Grafana один для всего кластера.

# Общие

  • Используйте общий инструментарий shared-tools (opens new window), не создавая скрипты деплоя с нуля.

# Безопасность

  • При создании шаблона в Rancher, добавляйте cloud-config (opens new window)
  • Используйте официальные образы, те, что в https://hub.docker.com/_/. Все остальные должны собираться на нашей стороне, где каждые новые изменения Dockerfile проходят code-review.
  • Не используйте персональные ключи доступа для доступа к SSH. В случае крайне необходимости, запрашиваем ключи из Rancher.
  • Всегда рассчитывайте requests и limits (opens new window) для подов.

# Отладка внутри кластера

  • Прочтите официальную документацию Application Introspection and Debugging (opens new window)
  • Контейнер отладки DNS kubectl run --namespace=NAMESPACE -it --rm --image=apliteni/network-utils debug-pod -- bash
  • Контейнер для отладки Postgres kubectl run --namespace=NAMESPACE -it --rm --image=postgres debug-pod -- bash

# Мониторинг и логирование

  • Поднимаем и используем Prometheus/Grafana через Rancher.

# Taints и Labels

  • Формат метки для выставления роли: node-role.kubernetes.io/maintenance=true (maintenance - роль)
  • Формат taint'а для ноды: node-role.kubernetes.io/maintenance=true:NoSchedule (maintenance - имя taint'а)

# Helm и чарты

  • Используем Helm v3
  • Чарты, которые можно переиспользовать, публикуем в Chart Registry. Чарты используемые только для развертки конкретного проекта держите в самом репозитории проекта.
  • Репозитории общих чартов храним в apliteni/charts.
  • Пароли и ключи не храним в общих чартах.
  • Все чарты покрываем тестами. Для примера, смотрите чарт apliteni/charts/universal и статью про terratest (opens new window).
  • Чтобы использовать helm-cli в CI используем наш образ apliteni/kubernetes-helm:3.

# Полезные инструменты

# Shell Aliases

alias k=kubectl 
alias h=helm

# Быстрое переключение между контекстами

https://github.com/ahmetb/kubectx (opens new window)

# Просмотр taints у нод

kubectl get nodes -o json | jq ".items[]|{NAME:.metadata.name, TAINTS:.spec.taints}"

# Просмотр меток у нод

 kubectl get nodes --show-labels

# Проверка шаблонов чарта

Проверить корректность helm chart можно через --dry-run --debug:

helm install --dry-run --debug ci/chart --values ci/chart/values.production.yaml --name RELEASE_NAME

# FAQ

# Как подключиться к кластеру

Вариант 1 (нативный kubectl):

  1. Установите kubectl (ля Mac OS: brew install kubernetes-cli)
  2. В нашем Rancher зайдите в кластер, затем нажмите кнопку Kubeconfig File. (Как объединить несколько конфиг-файлов (opens new window))

Вариант 2 (rancher cli):

Смотрите https://rancher.com/docs/rancher/v2.x/en/cli/ (opens new window).

# Как настроить новый проект на деплой в кластер

  • Для организации .gitlab-ci.yml, смотрите проект apliteni/js/shared-tools.
  • Для быстрого создания helm chart'а, смотрите apliteni/charts/universal.

# Как попасть в Grafana проекта

  1. Зайдите в Rancher
  2. Через верхнее меню зайдите в проект (не в кластер!)
  3. Откроется страница проекта с новой навигацией. Затем через верхнее меню в Apps.
  4. Нажмите на /index.html. Логин и пароль админа admin:admin (не переживайте, без доступа к Rancher в Grafana не попасть).

# Устранение сбоев

# Одна из нод в состоянии NotReady

  1. В первую очередь нужно перенести с ноды все поды:
kubectl drain [имя_ноды] --ignore-daemonsets
  1. Следуйте официальным рекомендациям Troubleshoot Clusters (opens new window).
  2. После восстановления верните доступность ноды для запуска подов kubectl uncordon [имя_ноды]

# Если упала нода с ролью lb в одном из кластеров hz*

  1. Выберите новую ноду, через которую пойдет трафик.
  2. Перенесите floating ip на эту ноду.
  3. Поставьте метку новой ноде kubectl label nodes node-role.kubernetes.io/lb=true.
  4. Проверьте, что ресурсы снова доступны.

# Checklist настройки кластера

  1. Запуск hcloud
  2. Запуск metalb
  3. Запуск nginx-ingress
  4. Настройка DNS
Edit this page (opens new window)
Last Updated: 2/25/2021, 11:19:48 AM

←