Эта страница выглядит лучше всего при включенном JavaScript

10 передовых практик Kubernetes для лучшей контейнерной оркестровки

 ·  ☕ 7 мин чтение  ·  🤖 Виктор

Давайте поговорим о некоторых из лучших практик, которым следует применять при использовании Kubernetes.

Kubernetes - это открытая контейнерная оркестровочная платформа, которая автоматизирует развертывание контейнеров, непрерывное масштабирование и демасштабирование, балансировку нагрузки контейнеров и многое другое.

Так как контейнеризация используется на многих производственных серверах с 1000ми контейнеров, становится очень важно хорошо ими управлять, и это то, что делает Kubernetes.

Если вы используете Kubernetes, вы должны принять лучшие практики для лучшей контейнерной оркестровки.

Вот список некоторых из лучших практик Kubernetes вы должны следовать.

#1. Установить Запросы на ресурсы и ограничения

Когда вы разворачиваете большое приложение на производственном кластере с ограниченными ресурсами, где у узлов заканчивается память или процессор, приложение перестает работать. Этот простой приложения может иметь огромное влияние на бизнес. Но вы можете решить эту проблему с помощью запросов ресурсов и ограничений.

Запросы и ограничения ресурсов - это механизмы в Kubernetes для контроля над использованием таких ресурсов, как память и процессор. Если одна капсула потребляет всю процессорную мощность и оперативную память, то другие капсулы будут испытывать недостаток в ресурсах, а в следствии не смогут запустить приложение. Следовательно, для повышения надежности необходимо установить запросы на ресурсы и лимиты на Поды.

Просто FYI, лимит всегда будет выше запроса. Ваш контейнер не будет работать, если ваш запрос превысит установленный лимит. Вы можете установить запросы и лимиты для каждого контейнера в поде. ЦП определяется в миллибайтах, а память - в байтах (мегабайт/мегабайт).

Ниже приведен пример установки лимита в 500 милликоров процессора и 128 мегабайт, а также установка квоты на запросы в 300 милликоров процессора и 64 мегабайта.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
containers:
- name: prodcontainer1
    image: ubuntu
    resources:
        requests:
            memory: “64Mi”
            cpu: “300m”
        limits:                              
            memory: “128Mi”
            cpu: “500m”

#2. Использовать livenessProbe и готовностьProbe

Проверки здоровья очень важны в Кубернете.

Он предоставляет два вида проверок здоровья - Готовность зондов и Жизнеспособность зондов.

Датчики готовности используются для проверки готовности приложения к началу обслуживания трафика или нет. Этот зонд должен пройти в Kubernetes, прежде чем он начнет посылать трафик в капсулу с приложением внутри контейнера. Kubernetes прекратит отправку трафика в капсулу до тех пор, пока эта проверка готовности не завершится неудачей.

Зонды готовности используются для проверки того, работает ли приложение (живое) или оно остановилось (мертвое). Если приложение работает правильно, Kubernetes ничего не делает. Если ваше приложение не работает, Kubernetes запустит новый капсулу и запустит в ней приложение.

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

Существует три типа зондов, которые могут быть использованы для проверок на живость и готовность - HTTP, Command, и TCP.

Позвольте мне показать пример наиболее распространенного из них - HTTP-зонд.

Здесь ваше приложение будет иметь HTTP-сервер внутри него. Когда Kubernetes пингует путь к HTTP-серверу и получает HTTP-ответ, он помечает приложение здоровым, в противном случае нездоровым.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
     livenessProbe:
       httpGet:
         path: /prodhealth
         port: 8080

#3. Построить изображения маленьких контейнеров

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

Есть два способа уменьшить размер контейнера - с помощью уменьшенного базового образа и шаблона сборщика. В настоящее время последнее базовое изображение NodeJS составляет 345 МБ, в то время как альпийское изображение NodeJS составляет всего 28 МБ, что более чем в десять раз меньше. Поэтому всегда используйте меньшие по размеру изображения и добавляйте зависимости, необходимые для работы вашего приложения.

Для сохранения изображений контейнера еще меньшего размера вы можете использовать шаблон сборки. Код собирается в первый контейнер, а затем скомпилированный код упаковывается в конечный контейнер без использования всех компиляторов и инструментов, необходимых для создания скомпилированного кода, что делает изображение контейнера еще меньше.

#4. Grant Safe Levels of Access (RBAC) (Предоставить безопасные уровни доступа)

Наличие безопасного кластера Kubernetes очень важно.

Доступ к кластеру должен быть хорошо сконфигурирован. Вы должны определить количество запросов на пользователя в секунду/минуту/час, разрешенные параллельные сеансы на IP-адрес, размер запроса и ограничение на пути и имена хостов. Это поможет защитить кластер от DDoS атак.

Разработчики и инженеры DevOps, работающие на кластере Kubernetes, должны иметь определенный уровень доступа. Функция контроля доступа на основе ролей (RBAC) в Kubernetes полезна здесь. Вы можете использовать роли и кластерные роли для определения профилей доступа. Для простоты настройки RBAC, вы можете использовать rbac-менеджеры с открытым исходным кодом, доступные для помощи в упрощении синтаксиса, или использовать Rancher, он предоставляет RBAC по умолчанию.

1
2
3
4
5
6
7
8
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

Kubernetes Secrets хранит конфиденциальную информацию, такую как автотокены, пароли и ssh ключи. Вы никогда не должны проверять Kubernetes Secrets в IaC репозитории, иначе она будет открыта тем, кто имеет доступ к вашему git-репозиторию.

DevSecOps сейчас является модным словом, которое говорит о DevOps и безопасности. Организации принимают эту тенденцию, так как они понимают ее важность.

#5. Будьте в курсе

Рекомендуется всегда иметь на кластере последнюю версию Kubernetes.

Последняя версия Kubernetes включает в себя новые функции, обновления предыдущих функций, обновления безопасности, исправления ошибок и т.д. Если вы используете Kubernetes с облачным провайдером, обновление становится очень простым.

#6. Использовать пространства имен

Kubernetes поставляет три различных пространства имен - default, kube-система и kube-публичное.

Эти пространства имен играют очень важную роль в кластере Kubernetes для организации и безопасности между командами.

Имеет смысл использовать пространство имен по умолчанию, если вы небольшая команда, работающая только с 5-10 микросервисами. Но быстро растущая команда или большая организация будет иметь несколько команд, работающих в тестовом или производственном окружении, поэтому каждой команде необходимо отдельное пространство имён для более простого управления.

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

Вот пример создания ресурсов внутри пространства имен:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
apiVersion: v1
kind: Pod
metadata:
   name: pod01
namespace: prod
   labels:
      image: pod01
spec:
   containers:
- name: prod01
  Image: ubuntu

#7. Использовать этикетки

По мере роста числа развертываний Kubernetes, они будут неизменно включать в себя множество сервисов, стручков и других ресурсов. Слежение за ними может стать обременительным. Еще более сложным может быть описание того, как Kubernetes взаимодействуют эти различные ресурсы, как Вы хотите, чтобы они были скопированы, масштабированы и обслуживались. Ярлыки в Kubernetes очень помогают в решении этих проблем.

Метки - это пары ключ-значение, которые используются для организации элементов в интерфейсе Kubernetes.

Например, app: kube-app, phase: test, role: front-end. Они используются для описания Kubernetes того, как различные объекты и ресурсы внутри кластера работают вместе.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
apiVersion: v1
kind: Pod
metadata:
 name: test-pod
 labels:
   environment: testing
   team: test01
spec:
 containers:
   - name: test01
     image: "Ubuntu"
     resources:
       limits:
        cpu: 1

Таким образом, вы можете уменьшить боль производства Kubernetes, всегда маркируя ресурсы и объекты.

#8. Журнал аудита

Для выявления угроз в кластере Kubernetes очень важен аудит журналов. Аудит помогает ответить на такие вопросы, как что произошло, почему это произошло, кто это сделал и т.д.

Все данные, связанные с запросами к серверу kube-apiserver, хранятся в файле журнала под названием audit.log. Этот лог-файл структурирован в формате JSON. В Kubernetes, по умолчанию, журнал аудита хранится в /var/log/audit.log и политика аудита присутствует в /etc/kubernetes/audit-policy.yaml

Чтобы включить ведение журнала аудита, запустите сервер kube-apiserver с этими параметрами:

1
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-log-path=/var/log/audit.log

Вот пример audit.log файл, настроенный для регистрации изменений в капсулах:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:
  - "RequestReceived"
rules:
  - level: RequestResponse
    resources:
    - group: ""
      resources: ["pods"]
   - level: Metadata
     resources:
     - group: ""
      resources: ["pods/log", "pods/status"]

Вы всегда можете вернуться назад и проверить журналы аудита в случае любой проблемы в кластере Kubernetes. Это поможет вам восстановить правильное состояние кластера.

#9. Применить правила аффинити (узел/под)

В Кубернете есть два механизма для лучшего ассоциирования стручков с узлами - под и узел аффинити. Рекомендуется использовать эти механизмы для лучшей производительности.

Используя сродство узлов, можно планировать поды на узлах по заданным критериям В зависимости от требований к подам, соответствующий узел выбирается и назначается в кластере Kubernetes.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1
kind: Pod
metadata:
  name: ubuntu
spec:
  affinity:
    nodeAffinity:    
preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 2
        preference:        
matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd          
  containers:
  - name: ubuntu
    image: ubuntu
    imagePullPolicy: IfNotPresent

Используя сродство стручков, вы можете запланировать несколько стручков на одном узле (для улучшения латентности) или решить оставить стручки на отдельных узлах (для высокой доступности), чтобы увеличить производительность.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: v1
kind: Pod
metadata:
  name: ubuntu-pod
spec:
  affinity:
    podAffinity:
     
requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
         
matchExpressions:
          - key: security
            operator: In
            values:
            - S1
        topologyKey: failure-domain.beta.kubernetes.io/zone
  containers:
  - name: ubuntu-pod
    image: ubuntu

После анализа загруженности вашего кластера, вам необходимо решить, какую стратегию сродства использовать.

#10. Kubernetes Termination

Kubernetes прекращает работу капсул, когда они больше не нужны. Вы можете инициировать его с помощью команды или вызова API, выбранные капсулы переходят в состояние завершения, и трафик к этим капсулам не отправляется. Затем в эти поды посылается сообщение SIGTERM (ЗАПИСЬ), после чего поды завершают работу.

По умолчанию льготный период составляет 30 секунд. Если капсулы все еще работают, Kubernetes посылает сообщение SIGKILL, которое принудительно завершает работу капсул. Наконец, эти капсулы удаляются Kubernetes с сервера API на главной машине.

В случае, если ваши капсулы всегда занимают более 30 секунд, вы можете увеличить этот льготный период до 45 или 60 секунд.

1
2
3
4
5
6
7
8
9
apiVersion: v1
kind: Pod
metadata:
 name: container10
spec:
 containers:
   - image: ubuntu
     name: container10
  terminationGracePeriodSeconds: 60

Заключение

Я надеюсь, что эти лучшие практики помогут вам в лучшей контейнерной оркестровке с использованием Kubernetes. Попробуйте применить их в вашем кластере Kubernetes для достижения лучших результатов.

Поделиться
Поддержать автора

Victor Sanikovich
Автор
Виктор
FullStack Developer