Заметки о Kubernetes

Архитектура 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
  1. Извлечем:
tar xzvf etcd-v3.3.11-linux-amd64.tar.gz
  1. Чтобы запустить ECTD необходимо выполнить следующую команду:
./etcd

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

Операции с ETCD

  1. Установить ключ-значение.
etcdctl set key1 value1
  1. Получить значение по ключу.
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.

Тип сервиса Описание
ClusterIP По-умолчанию предоставляет службу на внутреннем IP-адресе кластера. Вы можете связаться с сервисом только из кластера.
NodePort Предоставляет службу на IP-адресе каждого узла на статическом порту. Служба ClusterIP создается автоматически, и служба NodePort перенаправляет на нее. Из-за пределов кластера вы можете связаться со службой NodePort, используя NodeIP: NodePort. Выбор портов возможен из списка 30000-32767.
LoadBalancer Предоставляет службу извне с помощью балансировщика нагрузки вашего облачного провайдера. Внешний балансировщик нагрузки направляет ваши службы NodePort и ClusterIP, которые создаются автоматически.
ExternalName Тип сопоставляет службу с содержимым поля externalName (например, foo.bar.example.com). Для этого он возвращает значение записи CNAME.

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

Affinity

Node Affinity

Типы Node Affinity:

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

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

Тип \ Момент DuringScheduling DuringExecution
Тип 1 Required Ignored
Тип 2 Preferred Ignored
Тип 3 Required Required
Сведения о статье:
Дата публикации: 13/09/2020 12:05AM
Последнее обновление: 04/01/2021 8:09PM (rmntrvn)
Поделиться статьей: 
Автор: rmntrvn
Постоянная ссылка: http://kb.rmntrvn.ru/kb/notes-about-kubernetes
kubernetes | notes |