Kubernetes (k8s)
Зачем
- Платформа для оркестрации контейнеров
- Обнаружение сервисов Service Discovery
- Окружения
- организованы используя kubernetes namespaces в рамках одного кластера. Такой подход является максимально простым и быстрым на старте, но так же имеет свои недостатки: namespaces не полностью изолированы друг от друга в kubernetes
- Удобство для разработчиков. Встроить Kubernetes в workflow разработки можно разными способами:
- Telepresence.io
- Skaffold
- управление конфигурациями и секретами
- Config, secrets
- Configmaps
- Consul, Vault и Consul Template для управления конфигурациями.
- Consul Template запускается как init-контейнер, а в будущем планируется запускать его как sidecar к pod’ам, чтобы он следил за изменениями конфигурации в Consul и обновлял секреты с истекающим сроком действия в Vault и мягко (gracefully) перезапускал процессы приложений.
- Observability
- Отличие от Docker - инструмент для создания и запуска контейнеров
Элементы k8s
Reference Architecture
Patterns
- Для упрощения развертывания k8s используются платформы управления: Rancher
TODO
Storage Solutions
- Container Attached Storage - это программное обеспечение, включающее контроллеры хранения на основе микросервисов, управляемые Kubernetes.
- Эти контроллеры хранилища могут работать в любом месте, которое доступно Kubernetes, то есть на любом облачном сервере или даже на обычном сервере с общим хранилищем или поверх традиционной системы общего хранения.
- Критически важно, что доступ к самим данным также осуществляется через контейнеры, в отличие от хранения в системе общего масштабирования вне платформы.
- three categories of volumes
- Persistent volumes: storage in the Kubernetes cluster that is preprovisioned or created via dynamic provisioning using storage classes
- Projected volumes: a type of storage that can map several existing volumes in the same directory
- Ephemeral volumes: storage that does not persist across restarts like emptyDir (useful for logs), configMap, or secret
- Container Attached Storage - Distributed Persistent Volumes easily deploy Kubernetes Stateful Workloads
- OpenEBS
- Rook
- GlusterFS
- Compare OpenEBS-Rook-GlusterFS
- Distributed storage - NFS
- Object Storage - Minio
Performance
Stateful Workloads
- Stateful Workloads on multi-container pods and container communication
Naming convention
- can only contain alphanumeric characters and hyphens. The alpha characters can only be lower-case, and names cannot start with hyphens. If you try to create objects that violate this naming convention, Kubernetes will complain.
- namespaces can be used for grouping:
- Resources that are a part of the same application.
- Resources that belong to a particular user. For example, I can create a namespace called adri, and create a bunch of resources in there as part of my Kubernetes experimentations.
- Environment-specific resources. For example, rather than having a separate cluster for Dev and QA, you can simply create a dev namespace, and a qa namespace in the same cluster, and deploy resources to the appropriate namespace.
- Изоляция ресурсов - когда вы удаляете пространство имен, оно удаляет само пространство имен вместе со всеми связанными объектами в этом пространстве имен
- RBAC
- Labels can be useful for:
- Determining whether a pod is part of a production or a canary deployment
- Differentiating between stable and alpha releases
- Specifying to which layer (UI, business logic, database, and so forth) an object belongs
- Identifying whether a pod is front-end or back-end
- Specifying an object’s release version (V1.0, V2.0, V2.1, and so on)
- Constraints on Labels
- The following syntax constraints are applied to labels:
- Key must be unique within a given object
- Min 0-max 63 characters for the segment (required): 253 for prefix (optional)
- Start and end with alphanumerics “a-z0-9A-Z” (unless length is 0)
- dashes “-“, underscore “_” and dot “.” allowed (internally)
- (Optional) prefix must be a series of DNS labels separated by dots and followed by a slash
Deployment
- TODO Кол-во сервисов на контейнер
- Ограничение кластера по подам на ноде?
- создание маленьких контейнеров, т.к. контейнеры автоматически запускаются на разных хостах, и их меньший размер ускорит время запуска (поскольку предварительно их нужно физически скопировать на хостовую систему)
Canary deployment
Scalability Performance масштабирование
- метрики
- Avtoscaling
- Min max nodes in cluster
- Горизонтальный POD Autoscaling
- RAM, CPU
- Запросы requests
- Лимиты limits
- by namespace, node, pod, container
- Утилизация ресурсов cluster, nodes, pods, container
- Когда вы утилизируете большую часть ресурсов кластера, контейнеры могут работать без проблем при обычной нагрузке, но в сценариях с высокой нагрузкой контейнеры могут начать использовать ЦП и память до предела.
- Это приведет к тому, что узел начнет выселять pods
- превышен limit RAM - статус перезапуска pod=OOMKilled
- превышен limit CPU - включается троттлинг (т.е. оно получает меньше тактов CPU)
- в критических ситуациях узел перестанет работать из-за нехватки ресурсов. )
- Это приведет к тому, что узел начнет выселять pods
- Quality of Service (QoS) classes to the Pod:
- Guaranteed
- Burstable
- BestEffort
- настраивать проверки работоспособности (health probes)
Мониторинг
Технологии
- CI/CD
- Jenkins - automation server on Kubernetes, pipeline
- IaC
- Container Registry
- Nexus
- Service mesh