Архитектура Kubernetes

Кластер Kubernetes состоит из Master и Worker нод.

Master nodes

Фунции Master node

1. Управление
2. Планирование
3. Мониторинг нод

Состав Master node

В состав Master ноды входит:

1. kube-apiserver Kube-apiserver отвечает за оркестрацию всех операций кластера.
2. Controller-manager (Node controller + Replication Controller) Controller отвечает за функции контроля за нодами, репликами.
3. ETCD cluster (распределенное хранилище ключ-значение) ETCD хранит информацию о кластере и его конфигурацию.
4. Kube-sheduler Kuber-sheduler отвечает за планирование приложений и контейнеров на нодах.

Worker nodes

На worker нодах по-умолчанию размещаются контейнеры приложений. На каждой ноде кластера устанавливается Docker или другая платформа контейнеризации (например RKT или containterd). На Master ноде также устанавливается Docker, если необходимо использовать компоненты Kubernetes в контейнерах.

Состав Worker node

В состав Worker ноды входит:

1. kubelet Kubelet слушает инструкции от kube-apiserver и разворачивает или удаляет контейнеры на нодах.
2. kube-proxy Kube-proxy отвечает за взаимодействие между сервисами на разных нодах кластера.

ETCD хранилище

ETCD в Kubernetes является распределенным хранилищем информации о кластере. Информация в ETCD хранится в формате ключ-значение. База данных “ключ-значение” является нереляционной. Подобная база данных обеспечивает хорошую горизонтальную (увеличение количества нод) масштабируемость.

Установка ETCD

1. Скачаем архив etcd:

curl -L https://github.com/etcd-io/etcd/releases/download/v3.3.11/etcd-
v3.3.11-linux-amd64.tar.gz -o etcd-v3.3.11-linux-amd64.tar.gz

2. Извлечем:

tar xzvf etcd-v3.3.11-linux-amd64.tar.gz

3. Чтобы запустить ECTD необходимо выполнить следующую команду:

./etcd

По-умолчанию ETCD хранилище запускается на порту 2379.

Операции с ETCD

1. Установить ключ-значение.

etcdctl set key1 value1

2. Получить значение по ключу.

etcdctl get key1

При установке кластера Kubernetes также будет установлено под etcd в пространствен имё kube-system.

Чтобы просмотреть ключи, используемые в etcd, необходимо выполнить команду:

kubectl exec etcd-master –n kube-system etcdctl get / --prefix –keys-only

Kube-API Server

Kube-API server выполняеет функцию центрального управления кластера. С помощью утилиты kubectl выполняется обращение к API серверу кластера и передаются команды, которые необходимо выполнить в кластере. Также возможно управление с помощью запроса curl (curl –X POST /api/v1/namespaces/default/pods ...[other]), при этом необходимо пройти аутентификацию пользователя kubernetes.

Чтобы просмотреть текущую конфигурацию kube-api server необходимо выполнить следующую команду:

cat /etc/kubernetes/manifests/kube-apiserver.yaml

Чтобы проверить настройки запуска юнита systemd выполнить команду.

cat /etc/systemd/system/kube-apiserver.service

Kube Controller Manager

Controller выполняет постоянный процесс мониторинга состояния кластера и различных компонент.

Опции запуска kube-contoller:

cat /etc/kubernetes/manifests/kube-controller-manager.yaml

Юнит systemd kube-contoller:

cat /etc/systemd/system/kube-controller-manager.service

Kube-scheduler

Kuber-scheduler выполняет фильтрацию и ранжирование нод для лучшего выбора для размещения контейнера на нодах.

Просмотр опций scheduler в конфигурации kubeadm:

cat /etc/kubernetes/manifests/kube-scheduler.yaml

Kubelet

Kubelet выполняет функцию управления запуска и остановки контейнера на worker нодах. Kubelet принимает информацию от kube-api server и передаёт ей на платформу контейнеризации (например Docker) на ноде. В свою очередь kube-api server принимает информацию о запуске или остановке контейнера от kube-scheduler.

Если используется kubeadm для установки кластера, kubelet не будет автоматически установлен на worker нодах. Необходимо произвести установку самостоятельно на каждой worker ноде.

wget https://storage.googleapis.com/kubernetes-release/release/v1.13.0/bin/linux/amd64/kubelet

Файл юнита systemd:

ExecStart=/usr/local/bin/kubelet \\
--config=/var/lib/kubelet/kubelet-config.yaml \\
--container-runtime=remote \\
--container-runtime-endpoint=unix:///var/run/containerd/containerd.sock \\
--image-pull-progress-deadline=2m \\
--kubeconfig=/var/lib/kubelet/kubeconfig \\
--network-plugin=cni \\
--register-node=true \\
--v=2

Kube-proxy

Kube-proxy устанавливается на каждую worker ноду и отвечает за маршрутизацию трафика к нужному поду.

Сервис

Сервис в Kubernetes - это объект REST, похожий на под. Как и все объекты REST, вы можете отправить определение службы на сервер API Kubernetes, чтобы создать новый экземпляр. Имя объекта службы должно быть допустимым именем метки DNS. Пример манифеста для создания сервиса:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Данная спецификация создает новый объект службы с именем my-service, который проброшен с 80 порта пода на TCP-порт 9376 контейнера на любом поде с меткой app = MyApp.

Kubernetes назначает этому сервису IP-адрес (иногда называемый clusterIP), который используется прокси-серверами сервиса.

Служба может сопоставить любой входящий порт (port) с целевым портом (targetPort). По-умолчанию и для удобства targetPort имеет то же значение, что и поле порта.

Типы сервисов в Kubernetes.

Демонстрация работы NodePort:

Affinity

Node Affinity

Типы Node Affinity:

• requiredDuringSchedulingIgnoredDuringExecution - если метка на ноде меняется, то под все равно продолжит работу на узле
• preferedDuringSchedulingIgnoredDuringExecution - попытается запустить поды на необходимой ноде, но если это невозможно, то разместить поды на других нодах.
• requiredDuringSchedulingRequiredDuringExecution - удалит поды с нод, которые перестают удовлетворять условиям наличия меток на ноде.

<Требование 1><Момент 1><Требование 2><Момент 2> requiredDuringSchedulingRequiredDuringExecution