Docker & k8s


Консоль и теория

Консоль и теория

Общая информация и установка

Установка
Доп. ссылка
Добавить пользователя, который впоследствии будет запускать контейнеры 
apt-get install sudo
usermod -aG sudo sergey
sudo apt-get update
Добавить сертификат и новое хранилище
(Вариант 1 - Debian)
sudo apt-get install ca-certificates curl gnupg lsb-release
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

(Вариант 2 - Ubuntu)

sudo install -m 0755 -d /etc/apt/keyrings
sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
sudo chmod a+r /etc/apt/keyrings/docker.asc
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Установка docker и docker compose

sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
Запуск docker при старте системы 
sudo systemctl enable docker

Добавить пользователя в группу docker 

sudo usermod -aG docker $USER

Информация о текущем статусе docker 

docker info
Теория
Образы (Images): неизменяемые элементы, основанные как минимум на ядре и архитектуре. Контейнер: исполняемый образ. Назначение контейнера - запуск одного приложения. Аналогия: Образ=класс, контейнер=объект. Т.е. к образу в момент запуска добавляются параметры и он становится исполняемым контейнером, но изменения в контейнере не затрагивают образ. Контейнер в текущем состоянии можно превратить в образ, но после остановки (если не сохранить данные в файловой системе хоста или еще где-либо) все данные будут потеряны. Повторный запуск будет произведен как будто создался новый объект. В этом принципиальное отличие от виртуальной машины.
docker_sheme.jpg
Может быть: архитектура ПК-ядро-образ-образ-образ-контейнер
Архитектура
Docker client -> Docker engine (daemon) -> containerd -> runc-> shim
runc легкая обертка libcontainer, задача - создание контейнеров. Для создании контейнера создается экземпляр runc, он создает контейнер, запускает и завершается. Контейнер передается shim. Shim сопоставляет процесс созданного контейнера с задачей в containerd, containerd логика выполнения контейнера, управления образами, томами, сетью, модульный, можно отключать
Пример процессов:
docker run --name ctr1 -it alpine:latest sh
Docker daemon может работать с сетью, non-TLS порт 2375, TLS port 2376
Контейнеры:
После запуска основным процессом становится приложение из параметров запуска
При отсутствии, используется приложение сконфигурированное в образе как точка запуска (Entrypoint)
Взаимоотношение между способами работы с Docker.
При работе с докером используются как минимум три способа (возможно больше) взаимодействий: прямое взаимодействие через консоль, dockerfile, docker compose. Терминология общая, но способы работы и результаты отличаются. Из-за того, что в целях упрощения консоли docker (групп команд docker ...) эти способы перемешаны, сначала возникает путаница. В статьях видимо по умолчанию считается, что читатель это отличие полностью осознал. Сравнение способов:

Консоль Dockerfile docker compose
Мое понимание термина Ввод команд настроек и запуска одного контейнера напрямую в консоли. Будет работать через  bash скрипт, но удобнее так не делать. Сохранение команд настроек одного контейнера в файл и запуск через консоль. Настройка взаимодействия нескольких взаимосвязанных контейнеров при условии подготовленных образов. Запуск через консоль / планировщик
Применение При тестовом запуске или для просмотра (корректировки) параметров работающего контейнера Шаблон одного контейнера. Нужно при создании образа для последующего использования в compose. Оркестрация образов.
Стадия использования Тестовая, до MVP. Либо product для анализа проблем. Тестирование, отладка одного образа. MVP - pre product. Комплексный запуск сервиса. Pre product - product
Формат Bash ini YAML
Точка использования Преимущественно на ПК разработчика, при обучении технологии или для выявления проблем с работающим контейнером на всех стадиях. ПК разработчика или тестовый сервер. Тестовый / product сервер.
Необходимость серьезного изучения Скорее администраторам.  Да, если для сервиса потребуется создание отдельных образов. Да. Данный способ можно использовать для одного контейнера, для product все равно потребуется.*
* При сборке из чистых образов (типа debian для запуска nginx+...) требуется доп. установка и настройка ПО, а данный вопрос проще решать через dockerfile. К тому же существует например ansible, позволяющий решить ряд вопросов. В книгах для примеров часто используют консоль (быстро, акцент на одном изучаемом аспекте). А через ansible возможно настроить и запустить контейнер (и оркестр) без dockerfile/docker compose. Но в случае ansible для compose используется терминология compose, а вид команд другой.
Резюме: это одни яйца, только с разных концов. Нужно общее понимание происходящего. Хотя формат compose чуть предпочтительнее.
Консоль и теория

Образы

Образ - контейнер только для чтения, содержащий все для запуска (минимальная ОС, приложение, зависимости, метаданные)
Образ состоит из слоев, существующие слои общие для использования и могут быть в разных образах.
Образ - manifest файл, в котором список слоев и метаданных.
Слой - целостный объект. 
Каждая команда в dockerfile, модифицирующая файловую систему контейнера, создает новый слой.
Нельзя удалить образ, пока последний контейнер не будет удален.
Образы обычно хранятся в /var/lib/docker/<storage-driver>
!Нужно достаточно места в /var!
У образа есть hash (digest), у каждого из слоев есть digest
Параметр distribution hash - hash сжатого образа или образа для размещения в hub
Для поддержки разных архитектур и платформ для одного названия (напр. golang:latest) используются manifest list и manifests
Для каждого контейнера создается новый слой чтения/записи
Команды работы с образами
Базовая команда Доп. парам. Описание
docker images
Список установленных образов

-q только отображение ID контейнеров

--digests добавляет столбец с хэшем образа

dangling: true/false Образы без тега. Происходит если при создании нового образа сохраняется тег старого. У старого обнуляется тэг, у нового остается.

label: <label> Фильтрует на основе наличия метки или ярлыка и значения. Команда docker images не отображает метки в своих выходных данных.
docker search <слово> поиск в dockerhub по слову <слово>

--filter "" Доп. фильтр 
docker search alpine --filter "is-official=true"

--limit число кол-во выдачи, максимум 100

docker image pull 

Синоним:

docker pull 

<repository>:<tag>

Загрузка образа из репозитория

repository: 

  • В случае официального образа на docker hub: одно слово
  • В случае неофициального образа на docker hub: слово/слово 
    docker pull nigelpoulton/tu-demo:v2
  • В случае внешнего хранилища: адрес хранилища без http(s) 
    docker pull gcr.io/google-containers/git-sync:v3.1.5

<digest> Хэш образа

docker image push

Синоним:

docker push 

<repository>:<tag>|<digest> Загрузка образа на репозиторий, доп. параметры аналогичны pull
docker image prune <repository>:<tag> удаление образа из локального хранилища

-a удаление всех неиспользуемых контейнерами образов

docker image build

docker build 

-t тег образа. обычно имя:версия

 

<путь к dockerfile> - обязательный

Создание образа из dockerfile 
docker build -t myapp:1.0 .
docker build -t ${PROJECT_NAME}_db:${VERSION} ./database

docker image tag

docker tag


Создать тэг TARGET_IMAGE связанный с SOURCE_IMAGE Это нужно только для публикации образа в dockerhub
docker tag ddd-book:ch8.1 nigelpoulton/ddd-book:ch8.1
docker rmi

Удаляет заданный образ или несколько образов.

Удаление всех образов:

docker rmi $(docker images -q) -f

Эта команда удаляет старые теги без удаления образа, если есть еще образы, ссылающиеся на этот образ.

docker inspect <имя или ID образа>

информация по образу

docker info | grep Storage

При использовании docker pull или docker-compose up -d образы размещаются в /var/lib/docker/overlay2

 

Консоль и теория

Контейнеры

Основные команды

Команда Доп. пар. Описание
docker ps
список работающих контейнеров

-a список остановленных но еще существующих контейнеров
docker logs <name>
список событий внутри контейнера name
docker start <name>
запуск остановленного контейнера
docker restart <name>
Перезапускает  один  или  несколько  контейнеров.  Можно  считать  приблизительным аналогом выполнения для заданных контейнеров команды docker stop, за которой сразу следует команда docker start.

-t определяет интервал времени ожидания, необходимого для завершения работы контейнера, перед его остановом по сигналу SIGTERM.
docker stop <name>
Останавливает (но не удаляет) один или несколько контейнеров. После выполнения этой команды заданный контейнер переходит в состояние «остановлен».

-t Аналогично restart
docker kill <name>
Сигнал основному процессу (PID=1) в контейнере. По умолчанию SIGKILL (немедленное завершение работы). Возвращает идентификатор контейнера.

-s другой сигнал
docker rm <name или id>
удаление остановленного контейнера

-f позволяет удалять работающие контейнеры.

-v

удалить тома, созданные удаляемым контейнером (если эти тома не смонтированы на каталоги и не используются другими контейнерами)

docker rm -v $(docker ps -aq -f status=exited)

удаляет все остановленные контейнеры

docker top <name или id>
информация о процессах внутри контейнера
docker port <name или id>
номера портов, назначенные механизмом Docker
docker create <name или id>
Создает контейнер из образа, но не запускает его. Аргументы как у docker run.
docker run
создание и запуск контейнера из образа

-it или -d сеанс интерактивной работы или  запуск в фоновом режиме

--link <namecur:nameinnew>

соединение между новым контейнером и существующим контейнером myredis, в новом контейнере ссылка на существующий обозначена именем redis

--link myredis:redis 

--name имя для дальнейшего взаимодействия

--hostname имя для обращения

--mount монтирование

--volumes-from CONTAINER использование томов контейнера

-p HostPort:ContPort перенаправление с портов хоста на порт контейнера

--rm удаление остановленного контейнера и файловой системы после запуска и выполнения команды. Несовместим с ключом -d.

--restart
Позволяет настроить образ действий при попытке Docker перезапустить остановленный  контейнер.  
  • no  запрещает  любые  попытки  перезапуска контейнера.
  • unless-stopped Будет перезагружаться до остановки. После перезагрузки демона Docker контейнер останется выключенным.
  • always попытки перезапуска выполняются в любом случае вне зависимости от состояния контейнера после выхода. После перезагрузки демона Docker контейнер опять запустится.
  • on-failure: перезапуск выполняются для контейнера, завершившего работу с ненулевым статусом. После перезагрузки демона Docker контейнер опять запустится. Может быть задан аргумент, определяющий максимальное количество попыток перезапуска (иначе попытки будут выполняться бесконечно). 
docker run --restart on-failure:10 postgres

-t, --tty Создает псевдоустройство TTY (терминал). Как правило, используется вместе с ключом -i для запуска контейнера в интерактивном режиме.

-e, --env Определяет переменные среды внутри контейнера. 

--entrypoint Определяет точку входа для запускаемого контейнера в соответствии с заданным аргументом, заменяя содержимое любой инструкции ENTRYPOINT из Dockerfile.

-u, --user Определяет пользователя, от имени которого выполняются команды. Может быть задано как символьное имя пользователя или как числовой идентификатор UID. Заменяет содержимое инструкции USER из Dockerfile.

-w, --workdir Устанавливает рабочий каталог в контейнере в соответствии с заданным путевым именем. Заменяет любые значения, определенные в файле Dockerfile.

--add-host=docker:10.180.0.1 ХЗ, узнать
docker pause/unpause
Временно приостанавливает/запускает все процессы внутри контейнера. Процессы не получают никаких сигналов приостановки(не могут быть остановлены и завершены или удалены).
docker commit <container name> <repo name>
 образ контейнера. По умолчанию приостанавливаются, без приостановки --pause=false. 
docker network ls
список сетей

Взаимодействие реального времени

Ctrl-PQ (или Ctrl+P, Ctrl+Q) отключение от контейнера без остановки

Команда Доп. пар. Описание
docker attach <name или id>
наблюдать  или  взаимодействовать с основным процессом внутри контейнера.
docker cp

Позволяет  копировать  файлы  между  файловыми  системами  контейнера и хоста.

docker cp /tmp/config.ini grafana:/usr/share/grafana/conf/
docker exec
Запускает заданную команду внутри контейнера (может быть работающий сейчас). Может использоваться для выполнения задач сопровождения или в качестве замены ssh при входе (регистрации) в контейнер. 
docker exec -it ubuntu:latest bash
docker events
Выводит в реальном времени события от демона демону. Выхода Ctrl-C. 
Примеры
 

 
Консоль и теория

Тома (volumes)

Тома (volumes) – файлы или каталоги, смонтированные на хосте и не являющиеся частью каскадно-объединенной файловой системы. 
Другие контейнеры могут совместно использовать их, и все изменения будут сразу же фиксироваться в файловой системе хоста. 

Устаревшее: В качестве точки монтирования можно определить любой другой каталог хоста в команде docker run (например, docker run -d -v /host/dir:/container/dir test/web-server). 

В Dockerfile bind mounts не работает - а это и не надо делать, т к это определяется при старте образа/через compose.

Способы хранения данных: 

  1. Временное (удаляется при остановке контейнера)
    1. по умолчанию изолировано на диске
    2. tmpfs в оперативной памяти
  2. Постоянное
    1. обычные тома Docker
    2. bind mounts - прямое монтирование папки в контейнер

Драйвера volumes

Драйвер Описание
local Драйвер по умолчанию. Только точки монтирования, доступные на хосте. 

И еще штук 30 драйверов, список драйверов

Управление томами при запуске контейнера из консоли:

Если тома нет - будет создан

Основная команда Параметр Описание
docker run ... --mount type=

Тип тома:

  • volume 
  • bind
  • tmpfs

source(src)= Имя тома или не указывается для анонимных

destination(dst)= точка монтирования в контейнере

volume-driver= local по умолчанию, локальный том

volume-opt=

опция=значение

volume-opt=type=nfs,volume-opt=device=<nfs-server>:<nfs-path>

 


readonly только для чтения

docker run ...

--volumes-from ContID


связывание с томами контейнера

Пример:

--mount 'type=volume,src=data-volume,dst=/var/opt/project,volume-driver=local,readonly'

Без пробелов после запятых.
Создание и управление томами независимо от контейнеров

Основная команда Параметр Описание
docker volume

create --name my_volume

create my_volume

Создание тома.

/var/lib/docker/volumes/имя тома/_data - расположение файлов

По умолчанию на хосте в каталоге установки Docker (обычно каталог /var/lib/docker/). /var/lib/docker/volumes/


ls местоположение определенных томов, по имени или ID тома.

inspect my_volume информация о томе

rm my_volume удаление тома

prune удаление всех томов, которыми не пользуются контейнерами. Но иногда после удаления контейнера данные не обновляются
docker system prune
очистка ресурсов docker. Потом - повторное удаление томов.
Примеры:
Автоматическое создание том с именем test-data в /var/lib/docker/volumes/test-data/_data
docker run -ti -d --name alpine-container -v test-data:/var/lib/app/content alpine
Монтирование в другую точку.
Нужно создать директорию.
mkdir /home/avimanyu/test-data
docker run -ti -d --name alpine-container -v /home/avimanyu/test-data:/var/lib/app/content alpine
Архивировать том datavol в dbdata и восстановить его в том dbdata2 контейнера dbstore2
Создание тома datavol в контейнере dbdata
docker run -it --mount 'type=volume,src=datavol,dst=/datavol' --name dbstore ubuntu /bin/bash
Создание временного контейнера, примонтирование тома из dbdata, создание тома backup и сохранение архива datavol в backup и удаление временного контейнера
docker run --rm --volumes-from dbstore --mount 'type=volume,src=backup,dst=/backup' --name tmpubn ubuntu tar cvf /backup/backup.tar /datavol
Создание тома datavol2 в контейнере dbdata2
docker run -it --mount 'type=volume,src=datavol2,dst=/datavol' --name dbstore2 ubuntu /bin/bash
Создание временного контейнера, примонтирование тома из dbstore2, создание тома backup и сохранение архива datavol в backup и удаление временного контейнера
docker run --rm --volumes-from dbstore2 --mount 'type=volume,src=backup,dst=/backup' ubuntu bash -c "cd /datavol && tar xvf /backup/backup.tar --strip 1"

Консоль и теория

Сеть (networking)

Docker поставляется со следующими сетевыми драйверами в рамках библиотеки libnetwork:

Для тестов нужно установить 

apt-get install bridge-utils

Docker регистрирует DNS сервис в пределах бриджа. Но в сети по умолчанию (docker0) DNS сервиса нет.

Команда Описание
brctl show

Список бриджей. 

sudo brctl show
bridge name     bridge id               STP enabled     interfaces
br-62694f46296d         8000.7ee73b5c2894       no
br-8af5ede4ffdc         8000.aee56ab6b984       no
br-96dd8dcd216d         8000.5a64a8825202       no
docker0         8000.f220300c62b1       no

Также есть опция поиска сервисов и балансировка входной нагрузки.

Основная команда Параметр Описание
docker network  ls Список сетей
docker inspect ИмяСети   Выводит информацию по указанной сети. bridge - сеть по умолчанию.
docker network create   -d драйвер 

 Создает сеть 

docker network create -d bridge localnet
   название сети  
 docker port ContName   Выводит map портов внутрь контейнера 
docker network prune   Удаляет неиспользуемые сети
docker network rm Название сети Удаляет конкретную сеть

Single-host bridge networks

Создается интерфейс на хосте docker. 

docker_networks_0.JPG

Один порт может занимать только один контейнер. Взаимодействие контейнеров внутри хоста.

Multi-host overlay networks

Для взаимодействия контейнеров внутри виртуальной сети нескольких хостов. Могут быть расположены на разных нодах swarm. Сеть второго уровня, распределяющаяся по нужным нодам с dns сервисом и распределением нагрузки.

Plugging into existing VLANs

Для прямого подключения к сетевому интерфейсу соответственно с независимым адресом. Необходим promiscuous mode на интерфейсе хоста (неразборчивый режим). 

ipvlan с возможностью независимого адреса в пределах диапазона сетевой карты хоста заработал

services:
  condb:
    image: nginx
    networks:
      my_ipvlan:
        ipv4_address: 192.168.1.40

networks:
  my_ipvlan:
    driver: ipvlan
    driver_opts:
      parent: enp0s3
      ipvlan_mode: l2
    ipam:
      config:
        - subnet: 192.168.1.0/24
          gateway: 192.168.1.1

macvlan напрямую не заработал. Из интернетов:

Консоль и теория

Yaml формат

# - комментарии

Ключ-значение 

first: second

Обязательный пробел после :

Вложенные ресурсы в python виде, два пробела

Типы данных

Строка. Может быть без кавычек если хотя-бы один нечисловой символ

Многостроковая переменная: 

config: |
  server.port=8443
  logfile=/var/log

Числа - как числа

Логические true/false

Список: 

ports:
  - 8080
  - 8443

Список словарей. 

env:
  - name: FIRSTVAR
    value: ONE
  - name: SECONDVAR
    value: TWO

Архивация образов и Хранилище образов (hub)

Терминология

реестр (registry или hub) – сервис, отвечающий за хранение и распространение образов.
репозиторий (repository) – набор взаимосвязанных образов, обычно различные версии приложения
тег (tag) – алфавитно-цифровой идентификатор, присваиваемый образам внутри репозитория (например, 14.04 или stable). Тегов может быть много.
Пространства имен:

Docker сохраняет аутентификационную информацию в файле .dockercfg, расположенном в вашем домашнем каталоге.

Создание архива образа из существующего образа

Создаем Dockerfile 

FROM alpine:latest
ARG NODE_ENV=production2
ENV NODE_ENV=${NODE_ENV}
RUN mkdir /var/www
RUN echo $NODE_ENV > /var/www/first.txt
CMD ["cat", "/var/www/first.txt"]

Собираем образ 

docker build -t bobrobot:1.0 .

 Сохраняем образ, копируем и устанавливаем на нужной системе, и запускаем

docker save bobrobot:1.0 > bobrobot:1.0.tar
docker load -i bobrobot\:1.0.tar
docker run bobrobot:1.0

Команды

Команда Доп. пар. Описание
docker login
Регистрация/вход на сервер реестра. По умолчанию Docker Hub. 
docker login https://hub.bobrobotirk.ru
docker logout
Выход из реестра Docker. По умолчанию Docker Hub.
docker pull
Загружает заданный образ из реестра. Реестр определяется по имени образа, по умолчанию принимается Docker Hub.
docker push
Выгружает образ или репозиторий в заданный реестр. При отсутствии тега выгружаются все образы указанного репозитория в заданный реестр. 
docker push hub.bobrobotirk.ru/testimage
docker search
Выводит список общедоступных репозиториев из реестра Docker Hub
docker build .


-t Определение имени репозитория и тега
docker tag <current> <in hub>
Устанавливается соответствие имени с образом, который ссылается на образ в репозитории Docker Hub. 
docker tag testimage hub.bobrobotirk.ru/testimage

Локальный hub (теория из разных источников, кое-что устаревшее)

Пример

На серверной стороне: 

mkdir dockertest_certs
openssl req -newkey rsa:4096 -nodes -sha256 -subj "/CN=dockertest" -addext "subjectAltName = DNS:dockertest" -keyout dockertest_certs/domain.key -x509 -days 365 -out dockertest_certs/domain.crt
docker run -d -p 5000:5000 -v $(pwd)/dockertest_certs:/certs -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key --restart=always --name registry registry
docker run --entrypoint htpasswd httpd:2 -Bbn testuser testpassword >> auth/htpasswd #добавить пользователя

На клиентской стороне (из-под root): 

mkdir -p /etc/docker/certs.d/dockertest:5000
#добавить в /etc/hosts запись о сервере dockertest
scp sergey@dockertest:/home/sergey/dockertest_certs/domain.crt /etc/docker/certs.d/dockertest:5000/ca.crt
service docker restart

Перелинковать на клиенте образ на новый хаб и загрузить его 

docker tag amouat/identidock:0.1 dockertest:5000/identidock:0.1
docker push dockertest:5000/identidock:0.1

Пример docker-compose.yml для запуска локального реестра

services:
 registry:
  restart: always
  image: registry
  ports:
   - "5000:5000"
  environment:
   REGISTRY_HTTP_TLS_CERTIFICATE: /certs/domain.crt
   REGISTRY_HTTP_TLS_KEY: /certs/domain.key
   REGISTRY_AUTH: htpasswd
   REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
   REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
  volumes:
   - ./dockertest_certs:/certs
   - ./auth:/auth

Практический запуск регистра

Поскольку это пока что тестовый хаб, решил сделать сертификат LetsEncrypt. На dns сервере сделал запись сайта hub.bobrobotirk.ru. Прокинул порты 443 и 8090 до виртуальной машины.  Создал папки 

mkdir data
mkdir auth
mkdir certs

В папку certs скопировал сертификат и ключ. Для создания пользователей установил утилиту 

sudo apt-get install apache2-utils

Создал пользователя testuser с паролем StrongPassword

htpasswd -Bbn testuser StrongPassword > auth/htpasswd

Для добавления пользователей: 

htpasswd -Bb auth/htpasswd user2 password2

Создал docker-compose.yaml 

services:
  registry-server:
    image: registry:2.8.2
    container_name: registry-server
    restart: always
    ports:
      - "443:5000" # Перенаправление HTTPS-трафика
    environment:
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Origin: '["https://hub.bobrobotirk.ru"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Methods: '["HEAD", "GET", "OPTIONS", "DELETE"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Credentials: '["true"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Headers: '["Authorization", "Accept", "Cache-Control"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Expose-Headers: '["Docker-Content-Digest"]'
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_HTTP_TLS_CERTIFICATE: /certs/cert.crt
      REGISTRY_HTTP_TLS_KEY: /certs/key.key
      REGISTRY_STORAGE_DELETE_ENABLED: "true"
    volumes:
      - ./data:/var/lib/registry # Для сохранения данных реестра
      - ./auth:/auth                     # Для файла htpasswd
      - ./certs:/certs                  # Для SSL сертификатов

  registry-ui:
    image: joxit/docker-registry-ui:main
    container_name: registry-ui
    restart: always
    ports:
      - "8090:80" # Интерфейс доступен по порту 8090
    environment:
      SINGLE_REGISTRY: "true"
      REGISTRY_TITLE: "BobRobotIRK Docker Registry"
      DELETE_IMAGES: "true"
      SHOW_CONTENT_DIGEST: "true"
      NGINX_PROXY_PASS_URL: "https://hub.bobrobotirk.ru" # URL реестра
      SHOW_CATALOG_NB_TAGS: "true"
      CATALOG_MIN_BRANCHES: "1"
      CATALOG_MAX_BRANCHES: "1"
      TAGLIST_PAGE_SIZE: "100"
      REGISTRY_SECURED: "true" # Реестр защищен авторизацией
      CATALOG_ELEMENTS_LIMIT: "1000"
    depends_on:
      - registry-server

И по адресу http://hub.bobrobotirk.ru:8090/ появился web интерфейс с авторизацией.

Авторизовался с другого сервера 

docker login https://hub.bobrobotirk.ru

Создал Dockerfile 

FROM alpine:latest
ARG NODE_ENV=production2
ENV NODE_ENV=${NODE_ENV}
RUN mkdir /var/www
RUN echo $NODE_ENV > /var/www/first.txt
CMD ["cat", "/var/www/first.txt"]

Собрал образ (пора переходить на buildx)

docker build -t testimage .

Точка обозначает расположение Dockerfile)

Он появился в списке образов 

docker images
REPOSITORY   TAG       IMAGE ID       CREATED         SIZE
testimage    latest    1f3755f48bea   3 minutes ago   7.83MB

Добавил тег образу 

docker tag testimage hub.bobrobotirk.ru/testimage

Загрузил образ на hub 

docker push hub.bobrobotirk.ru/testimage

Да, образ отобразился в списке. Теперь на третьем сервере авторизовался на hub.bobrobotirk.ru и попробовал запустить контейнер из образа

services:
  testapp:
    image: hub.bobrobotirk.ru/testimage

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

P.s. Второй вариант, в случае наличия внешнего nginx reverse proxy + https termination 

services:
  http-registry-server:
    image: registry:2.8.2
    container_name: http-registry-server
    restart: no
    ports:
      - "${HUB_BACKEND_PORT}:5000" # Перенаправление HTTP-трафика
    environment:
      REGISTRY_AUTH: htpasswd
      REGISTRY_AUTH_HTPASSWD_REALM: Registry Realm
      REGISTRY_AUTH_HTPASSWD_PATH: /auth/htpasswd
      REGISTRY_STORAGE_DELETE_ENABLED: "true"
      REGISTRY_HTTP_ADDR: 0.0.0.0:5000
      REGISTRY_HTTP_NET: "tcp"  # Явно указываем протокол
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Origin: '["*"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Methods: '["HEAD", "GET", "OPTIONS", "DELETE"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Credentials: '["true"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Allow-Headers: '["Authorization", "Accept", "Cache-Control"]'
      REGISTRY_HTTP_HEADERS_Access-Control-Expose-Headers: '["Docker-Content-Digest"]'
    volumes:
      - ./data:/var/lib/registry # Для сохранения данных реестра
      - ./auth:/auth                     # Для файла htpasswd

  http-registry-ui:
    image: joxit/docker-registry-ui:main
    container_name: http-registry-ui
    restart: no
    ports:
      - "${HUB_BACKEND_WEB_PORT}:80"
    environment:
      NGINX_PROXY_PASS_URL: "http://${HUB_BACKEND_IP}:${HUB_BACKEND_PORT}"
      SINGLE_REGISTRY: "true"
      REGISTRY_TITLE: "${WEB_TITLE}"
      DELETE_IMAGES: "true"
      SHOW_CONTENT_DIGEST: "true"
      SHOW_CATALOG_NB_TAGS: "true"
      CATALOG_MIN_BRANCHES: "1"
      CATALOG_MAX_BRANCHES: "1"
      TAGLIST_PAGE_SIZE: "100"
      REGISTRY_SECURED: "true" # Реестр защищен авторизацией
      CATALOG_ELEMENTS_LIMIT: "1000"
    depends_on:
      - http-registry-server

 

Примеры

Загрузка образа с тегом latest в репозиторий amouat/revealjs из реестра Docker Hub. 

docker pull amouat/revealjs:latest 

Загрузка образа из неофициального реестра. 

docker pull gcr.io/google-containers/git-sync:v3.1.5

Определение имени репозитория identidock и тега 0.1 для образа, собранного из локального dockerfile. 

docker build -t "identidock:0.1" .

Устанавливается соответствие имени amouat/identidock с образом, который ссылается на имя пользователя amouat в репозитории Docker Hub.

docker tag "identidock:0.1" "amouat/identidock:0.1"

Ссылки

Настройка локального hub

Dockerfile

DockerFile - набор инструкций по установке и настройке контейнера. Также используется для создания преднастроенных образов. Обычно dockerfile расположен в директории, из которой вызывается команда. 
Имя файла: Dockerfile (без расширения).
Контекст создания - набор локальных файлов/каталогов, к которым можно обращаться через copy/add. 
/ не стоит использовать как контекст, полностью включается в архив
# комментарии
При сборке образа попытки использования кэша идут до первого промаха. Затем кэш не проверяется.
.dockerignore - файл исключений из контекста
При сборке компилируемых приложений лучше использовать multi-stage build.
Основная команда Параметры Описание
docker build  

создание образа

Создание образа из docker файла . - контекст создания (текущая папка)

 

docker build -t test/cowsay-dockerfile .

После этого образ появляется в списке образов


-t имя слоя

-f расположение слоя

--squash сжимает все слои в один
docker history <image> инструкции создания образа
docker buildx
для компиляции под разные платформы
Формат exec и формат командной оболочки
Формат  exec
JSON-массив
первый элемент массива: имя выполняемого файла
остальные - параметры,  передаваемые  при  запуске.  
Формат  командной оболочки 
строка произвольной формы, передаваемая для интерпретации в /bin/sh -c. 
Используйте формат exec, чтобы избежать случайного искажения строк командной оболочки, или в тех случаях, когда образ не содержит /bin/sh.
Команды файла:
Основная команда Параметры Описание
FROM <name> название базового образа
MAINTAINER <name> имя поддерживающего пользователя
USER <name> !Всегда определять! Задает пользователя (по имени или по идентификатору UID) для использования во всех последующих инструкциях RUN, CMD, ENTRYPOINT.
WORKDIR 
рабочий каталог для последующих RUN, CMD, ENTRYPOINT, ADD, COPY. 
можно использовать несколько раз 
можно относительные пути, итоговый путь относительно предыдущего WORKDIR.
RUN <commands>
команды при инициализации образа, обычно установка пакетов
каждая создает новый слой
CMD {''}
команда с аргументами, выполняемая после запуска контейнера. Аргументы могут быть переопределены при запуске контейнера. В файле может присутствовать лишь одна инструкция CMD.
ENTRYPOINT <program name>
Выполняемый файл, который будет вызываться для обработки аргументов, переданных в команду docker run 
ENTRYPOINT ["/usr/games/cowsay", "-k"]
COPY <> <>
копирование файла из ФС ОС в ФС образа COPY . /src копирует все из текущей папки в папку /src
VOLUME <>
Том в ФС
ARG
Определяет переменные среды, доступные внутри образа при сборке. Неизменяемые.
ENV
Определяет переменные среды внутри образа, но могут изменяться. На эти переменные можно ссылаться в последующих инструкциях.*
ENV MY_VERSION 1.3
RUN apt-get install -y mypackage=$MY_VERSION

Переменные среды со значением по умолчанию

Файл first.sh 

echo $NODE_ENV

Dockerfile

FROM alpine:latest
ARG NODE_ENV=production2
ENV NODE_ENV=${NODE_ENV}
RUN mkdir /var/www
COPY first.sh /var/www/first.sh
CMD ["sh", "/var/www/first.sh"]

Собираем образ 

docker build -t bobrobot:1.0 .

docker-compose.yml 

services:
  bobrobot:
    image: bobrobot:1.0
    environment:
      NODE_ENV: "first2"

В итоге при указании NODE_ENV выводится first2, иначе production2 

EXPOSE
Сообщает механизму Docker, что в контейнере будет процесс, прослушивающий порт(ы)
не оказывает воздействия на сетевую среду
нужно для аргумента -p в docker run
ONBUILD
инструкция, выполняемая когда образ будет использоваться как основной уровень для другого образа. Полезным при обработке данных, добавляемых в образ-потомок 
(например, инструкция копирования дополнительного кода из заданного каталога и запуска скрипта сборки, обрабатывающего скопированные данные).
* Для различных образов могут использоваться доп. переменные, иногда обязательные. Детали нужно уточнять для конкретного образа.
При сборке команды исполняются однократно. Затем при запуске образа они не повторяют исполнение. Поэтому для  
FROM alpine:latest
ARG NODE_ENV=production2
ENV NODE_ENV=${NODE_ENV}
RUN mkdir /var/www
RUN echo $NODE_ENV > /var/www/first.txt
CMD ["cat", "/var/www/first.txt"]
вывод всегда будет production2.
Многошаговая сборка (Multi-stage building)
Создание одного образа с участием нескольких временных
Необходима если нужно при помощи временного образа скомпилировать исходники и результат сохранить в финальный образ. Временный образ удаляется.  
FROM golang:1.20-alpine AS base
WORKDIR /src
COPY go.mod go.sum .
RUN go mod download
COPY . .

FROM base AS build-client
RUN go build -o /bin/client ./cmd/client

FROM base AS build-server
RUN go build -o /bin/server ./cmd/server

FROM scratch AS prod
COPY --from=build-client /bin/client /bin/
COPY --from=build-server /bin/server /bin/
ENTRYPOINT [ "/bin/server" ]

Сборка образа: 

docker build -t multi:stage .

Создание нескольких образов

Также можно создать несколько образов при помощи одного Dockerfile. Отличие в последней стадии:

...
FROM scratch AS prod-client
COPY --from=build-client /bin/client /bin/
ENTRYPOINT [ "/bin/client" ]

FROM scratch AS prod-server
COPY --from=build-server /bin/server /bin/
ENTRYPOINT [ "/bin/server" ]

Сборка образов: 

docker build -t multi:client --target prod-client -f Dockerfile-final .
docker build -t multi:server --target prod-server -f Dockerfile-final .

Мультиплатформенная сборка

Возможно, но пока не интересно

Использование условий для создания разных образов

Условия можно использовать только в конструкции RUN и CMD 

RUN if [ "$TARGET" = "test" ]; then \
      cp -r /files/src/tests .; \
    fi

# Разные команды для production и тестов
CMD if [ "$TARGET" = "production" ]; then \
      exec gunicorn app.main:app --bind 0.0.0.0:8000; \
    else \
      exec pytest -v; \
    fi

Затем собирается образ с указанной переменной окружения 

docker build --build-arg TARGET=production -t myapp:prod .

Полный пример: 

FROM alpine:latest
ARG BUILD_ENV
RUN mkdir /var/www
WORKDIR /var/www
COPY test.txt .
COPY prod.txt .
RUN if [ "$BUILD_ENV" = "test" ]; then \
       cat test.txt > first.txt; \
    else \
       cat prod.txt > first.txt; \
    fi
CMD ["cat", "/var/www/first.txt"]

Использование multistage сборки для ограничения копирования

if не работает в команде COPY. Но иногда бывает нужен образ для тестирования без содержимого директории, а в prod с содержимым. Пример: 

# Общая стадия для подготовки файлов
FROM alpine:latest as base
COPY common_files /app/common_files

# Стадия для prod (копирует папку)
FROM base as prod
COPY prod_folder /app/prod_folder

# Стадия для test (не копирует папку)
FROM base as test
RUN echo "Running in test mode, no prod_folder copied"

# Выбираем финальную стадию через ARG
ARG TARGET_ENV=prod
FROM ${TARGET_ENV} as final

# Остальные инструкции...

 

 

Сжатие итогового образа (многоуровневого) в один уровень

Не рекомендуется, но если надо: --squash флаг при build

Разное

При apt-get install использовать no-install-recommends - сильно снижает объем.

Docker compose

Инструмент для управления несколькими контейнерами при помощи одного файла. 

Применение compose файла с политикой restart always/unless-stopped нужно быть внимательным. Повторное применение может создать копию, которая будет постоянно перезагружаться и забивать ресурсы. Для диагностики docker ps Если такое произошло, то 

docker update --restart=no 1945fa12ce27

Это обновит политику перезагрузки для контейнера и позволит разобраться в проблеме.

Консольные команды:

Основная команда Доп. параметры Описание
docker compose up

Запуск контейнеров через Compose файл. 

Вывод журнальных записей объединяется в один поток.

Создает образы, если они не существовали ранее


-d запуск в фоновом режиме

-f определяет имя compose файла

& в конце возвращает консоль, но продолжает выводить логи
docker compose build
Пересоздание образов из Dockerfile.
docker compose ps
Вывод информации о состоянии контейнеров. Работает только в контексте файла в текущей директории. 
docker compose run

Одноразовый запуск с выполнением одной команды (не в качестве сервиса).

Также запускаются все контейнеры, с которыми должны быть установлены соединения, если не задан аргумент --no-deps.

(Команды, передаваемые через run, заменяют команды, определенные в файле конфигурации сервиса. Кроме того, по умолчанию команда run не создает портов, определенных в файле конфигурации сервиса.)

docker compose top

процессы во всех контейнерах

docker compose stop

Останов контейнеров без их удаления

docker compose logs

Вывод журнальных записей с цветной подсветкой, объединенный для всех контейнеров

docker compose restart

запускает остановленные контейнеры

docker compose rm

Удаление остановленных контейнеров.


-v

удаляет тома, управляемые механизмом Docker

docker compose down

это stop+rm


--volumes

удаляет и тома


--rmi all

удаляет образы

Формат файла docker-compose.yaml

Имя файла docker-compose.yml
Язык yaml. Уровни вложенности определяются пробелами, параметр:значение, - список
Compose перекрывает настройки docker файла при пересечении.
Если микросервисы в одной сети (networks), то могут взаимодействовать по имени.
# комментарий, пустые строки игнорируются
сначала создается сеть и тома, затем сервисы.

Блоки конфигурации:

services #настройки запускаемых образов 
	firstapp:
		build: . #Расположение dockerfile, в данном случае в текущей папке
		command: python app.py #исполняемая комманда (точка входа)
		hostname: your-name
		ports:
			- target: 8080 #внутренний порт 
			  published: 5001 #внешний порт
		environment:
			- DEBUG=${DEBUG}
		networks:
			- counter-net #название подключенной сети, т е может быть разные подключенные сети. Подключенные к одной сети контейнеры видят друг друга по имени. Д б определена в networks
		volumes:
			- type: volume
			source: counter-vol #Д б определена в volumes
			target: /app
networks #Сеть
	counter-net:
		over-net: #имя сети
		driver: overlay	#драйвер
		attachable: true #разрешено подключаться из других докер контейнеров
volumes #Тома

Внешние переменные окружения

По умолчанию файл .env Формат файла: 

VERSION=v1.3
PG_USERNAME="superadmin"

Кавычки:

Использование внутри yml файла (без доступа во время выполнения): 

services:
  web:
    image: webapp:${VERSION}

Для использования внутри сервиса необходимо создать переменную внутри environment 

services:
  db:
    image: postgres
    environment:
      POSTGRES_USER: ${PG_USERNAME}

Использование различных файлов с переменными окружения 

docker compose --env-file <file> up

Предварительный вывод итогового yml файла: 

docker compose config

Приоритет переменных (от высокого к низкому):

  1. Файл Compose.
  2. Переменные среды оболочки.
  3. Файл среды.
  4. Dockerfile.
  5. Переменная не определена.

Именование контейнеров.

В случае использования image, имя контейнера берется из имени сервиса. В случае build <имя проекта>-<имя сервиса> Переменные в имени сервиса не поддерживаются.

Политика перезагрузки контейнера

services:
  postgres:
    image: ${PROJECT_NAME}_db:${VERSION}
    restart: always

Docker Swarm

Кластеризация приложений, упрощенный K8s.

Типы Nodes (хост Docker в Swarm кластере):

Конфигурация и состояние кластера хранится в распределенной хранимой в ОП БД, реплицированной по всем manager. Сервис (service) является атомарным элементом для управления. Сверху накручиваются фишки типа масштабирования, постоянного обновления и восстановления.

Для Node желательно настройка dns имен (в моем случае manager1, manager2, worker1, worker2)

Роли можно совмещать на одном VPS, актуально для маленьких кластеров.

Инициализация кластера

Инициализация первого manager - добавление остальных manager - добавление worker. Инициализация первого manager:

docker swarm init

Затем при помощи команд ... join-token смотрим инструкцию по подключению node. 

При размещении где-то, должны быть доступны следующие порты: 

Доступность кластера

Один manager активен в каждый момент времени. Это Leader manager. Остальные (Fallower managers) проксируют команды на лидера. Ситуации split-brain (в результате сбоя сети при котором одинаковое количество manager осталось в каждом сегменте и последующего восстановления связи) необходимо избегать. Желательно 3-5 manager. 

Подключение manager после перезагрузки / сбоя сети может привести к проблемам. Поэтому желательно установить правило блокировки при перезагрузке. 

docker swarm update --autolock=true

Она выдаст ключ разблокировки. После перезагрузки потребуется разблокировать 

docker swarm unlock

Есть нюанс: для работы кластера требуется доступность более половины manager. Поэтому кластер из 2 manager точно плохой вариант)

Сервисы (пользовательские приложения)

По умолчанию исполняются на всех нодах. Для исключения manager нужно ввести команду

docker node update --availability drain mgr1

В списке node Active поменяется на Drain

ID                            HOSTNAME                  STATUS    AVAILABILITY   MANAGER STATUS   ENGINE 
m1bhltzuvvzippoetl7b26m3j     manager1.bobrobotirk.ru   Ready     Drain          Leader           28.0.1
yjmubzqzvrvbhqaqw70rlorzk *   manager2.bobrobotirk.ru   Ready     Drain          Reachable        28.0.1
3s0jzf6fcw9ik5g9sqlrpmmgo     worker1.bobrobotirk.ru    Ready     Active                          28.0.1

Сервисы создаются через интерактивные команды или через описание (compose file + доп. настройки). 

Стандартный режим создания - реплика (количество, распределено по активным worker). Есть глобальный режим (mode global) при котором на каждом worker создается по одной реплике.

Архивация и восстановление 

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

tar -czvf swarm.bkp /var/lib/docker/swarm/

rm -r /var/lib/docker/swarm
tar -zxvf swarm.bkp -C /
docker swarm init --force-new-cluster

После восстановления директорий обязательна реинициализация кластера.

Примеры

5 реплик, доступ через любую ноду

docker service create --name web-fe -p 8080:8080 --replicas 5 nigelpoulton/ddd-book:web0.1
или
docker service create --name web-fe -p 8080:8080 --mode global nigelpoulton/ddd-book:web0.1
docker service rm web-fe

Через overlay сеть + обновление

docker network create -d overlay uber-net
docker service create --name web-fe --network uber-net -p 8080:8080 --replicas 5 nigelpoulton/ddd-book:web0.1
#без указания сети, запрос на manager:8080 обрабатываться не будет

docker service update --image nigelpoulton/ddd-book:web0.2 --update-parallelism 2 --update-delay 20s web-fe

Compose файл

networks:
  counter-net:
    driver: overlay
    driver_opts:
      encrypted: 'yes'
volumes:
  counter-vol:

services:
  web-fe:
    image: nigelpoulton/ddd-book:swarm-app
    mem_limit: 250m
    command: python app.py
    deploy:
      replicas: 4
      update_config:
        parallelism: 2
        delay: 10s
        failure_action: rollback
      placement:
        constraints:
          - 'node.role == worker'
      restart_policy:
        condition: on-failure
        delay: 5s
        max_attempts: 3
        window: 120s
    networks:
      - counter-net
    ports:
      - published: 5001
        target: 8080
    volumes:
      - type: volume
        source: counter-vol
        target: /app
  redis:
    image: "redis:alpine"
    networks:
      counter-net:

Основные команды

Команда Доп. пар. Описание
docker swam init
Инициализация первого manager кластера

--advertise-addr 10.0.0.1:2377 Необязательный параметр. Нужен если есть внешний балансировщик нагрузки - тогда адрес балансировщика, и указать listen-addr. 

--listen-addr 10.0.0.1:2377 Необязательный параметр. Нужен если много ip адресов. 
docker node ls
Список node в кластере
docker swarm join-token  worker Инструкция по подключению worker

manager Инструкция по подключению manager
docker swarm leave
Исключение node из кластера
docker swarm update  --autolock=true Блокировка после перезагрузки / потере связи

--availability drain name_manager Исключение manager из исполнения клиентских приложений.
docker swarm unlock
Разблокировка manager
docker service ls список сервисов

ps name список работающих контейнеров с именем name

inspect --pretty name детальная информация по сервису name

scale name=10 Изменение количества реплик сервиса name в режиме реального времени

rm name Удалить сервис

update

--image imname

--update-parallelism 2

--update-delay 20s 

name

Обновление сервиса name до образа imname


logs nameserv

Отобразить логи сервиса nameserv

docker stack 

deploy -c name.yml nameofstack

Создает стэк nameofstack из файла name.yml 

docker stack deploy -c compose.yaml ddd

Также используется для обновления существующего сервиса при обновлении compose файла


rm nameofstack

Удаление стэка nameofstack


ls 

Список 


ps

Детализация


Дополнительные инструменты

Контейнеры
Docker  Compose  –  создание  и  выполнение  приложений, скомпонованных  из  нескольких  Docker-контейнеров.  Такие  компоновки используются главным образом при разработке и тестировании
Docker Machine - устанавливает и конфигурирует Docker-хосты на локальных и удаленных ресурсах. Кроме того, Machine конфигурирует клиента Docker, упрощая процедуру переключения между средами.
Kitematic - графический  пользовательский  интерфейс для  операционных  систем  Mac  OS  и  Windows,  обеспечивающий  запуск и управление контейнеров Docker

Хранение и управление образами Docker
Docker Trusted Registry – локальная версия реестра Docker Hub, которую можно объединить с существующей инфраструктурой. Исходный код закрыт.
Enterprise Registry от CoreOS
Artifactory от JFrog.
Сетевая среда
Создание сетей контейнеров, распределенных между разными хостами
Weave
Project Calico  
Обнаружение  сервисов
Поиск других  сервисов  для  взаимодействия  с  ними. 
Consul 
Registrator  
SkyDNS  
etcd  
Оркестровка и управление кластером
Контроль и  управления  всей  системой  в  целом.
Kubernetes  от Google
Marathon  
фреймворк для Mesos  
Fleet   от CoreOS
Docker Swarm – решение задачи кластеризации от Docker. Группирует несколько Docker-хостов, после чего пользователь может работать с этой группой как с единым ресурсом.

Примеры

Примеры

Контейнеризация приложения из git

Создаем папку app и переходим в нее.

Клонируем git

git clone https://github.com/sudaka/irksecrets.git

Создаем dockerfile

FROM ubuntu:latest
LABEL maintainer="..." 
RUN apt-get update
RUN apt install -y python3 python3-pip uvicorn
RUN mkdir /var/www
WORKDIR /var/www
COPY ./irksecrets /var/www
RUN python3 -m pip install -r requirements.txt
EXPOSE 8000
ENTRYPOINT ["uvicorn", "irksecrets:app", "--host", "0.0.0.0", "--port", "8000"]

Создаем образ

docker build -t irkscweb:2.0 .

Создаем контейнер

docker run -d --name fa2 -p 8000:8000 irkscweb:2.0

Сейчас контейнер сервиса должен заработать, по адресу 127.0.0.1/docs должна быть страница сервиса. Останавливаем сервис.

Информация по официальному образу postgres: 

POSTGRES_PASSWORD=mysecretpassword
POSTGRES_USER
POSTGRES_DB #при отсутствии будет создана БД
POSTGRES_HOST_AUTH_METHOD
все файлы .sql .sh в папке docker-entrypoint-initdb.d исполняются при инициализации БД

Поднимаемся на один уровень и создаем папку db.

Создаем скрипт настройки

create role irksecrets with login superuser;
alter role irksecrets with encrypted password 'Password';
create table secrets (chash char(64) primary key, enctext bytea);
alter database irksecrets owner to irksecrets;
FROM postgres
LABEL maintainer="bobrovsa@yandex.ru"
ENV POSTGRES_PASSWORD qaz123wsx
ENV POSTGRES_HOST_AUTH_METHOD md5
ENV POSTGRES_DB: irksecrets
COPY *.sql /docker-entrypoint-initdb.d/ #инит скрипты, при наличии БД не запускаются
EXPOSE 5432

Создаем compose файл. Директории app db рядом с .yaml файлом

services
		webapp:
			build: app/.
			ports:
				- target: 8000
				  published: 8000
			networks:
				- isnet
		dbhost:
			build: db/.
			environment:
				- POSTGRES_PASSWORD=Password
				- POSTGRES_HOST_AUTH_METHOD=md5
				- POSTGRES_DB=irksecrets
			ports:
				- target: 5432
				  published: 5432
			networks:
				- isnet
		networks:
			isnet:

 

 

Примеры

Запуск из консоли и простые dockerfile

Запуск bash в контейнере:

docker run -i -t debian /bin/bash

Удаление всех остановленных контейнеров 

docker rm -v $(docker ps -aq -f status=exited)

Создание контейнера, установка доп. приложения и запуск

docker run -it --name cowsay --hostname cowsay debian bash
root@cowsay:/# apt-get update
root@cowsay:/# apt-get install -y cowsay fortune
root@cowsay:/# exit
docker commit cowsay test/cowsayimage
docker run test/cowsayimage /usr/games/cowsay "Moo"

Создание образа из docker файла

Dockerfile:

FROM debian:wheezy
RUN apt-get update && apt-get install -y cowsay fortune
ENTRYPOINT ["/usr/games/cowsay"]

Создание образа из dockerfile

docker build -t test/cowsay-dockerfile .

Пример скрипта вызова разных приложений при установленной точке входа

nano entrypoint.sh 
#!/bin/bash
if [ $# -eq 0 ]; then
  /usr/games/fortune | /usr/games/cowsay
else
  /usr/games/cowsay "$@"
chmod +x entrypoint.sh

DockerFile:

FROM debian
RUN apt-get update && apt-get install -y cowsay fortune
COPY entrypoint.sh /
ENTRYPOINT ["/entrtypoint.sh"]

 

Примеры

3 образа

services:
 identydock:
  build: . 			#build ссылается на docker file. Либо build, либо image.
  ports:
   - "5000:5000"
  environment:
   ENV: DEV
  volumes:
   - ./app:/app # старое описание
   - type: volume
     source: counter-vol
	 target: /app
  links:
   - dnmonster
   - redis

 dnmonster:
  image: amouat/dnmonster 

 redis:
  image: redis
volumes:
	counter-vol:

Примеры

Postgresql

Основа инструкции на хабре

Минимальный compose файл с возможностью подключиться извне, логином и паролем:

services:
  postgres:
    image: postgres:16.3
    environment:
      POSTGRES_DB: "testdb"
      POSTGRES_USER: "testuser"
      POSTGRES_PASSWORD: "testpass"
    ports:
      - "5432:5432"

Точка входа для инициализации базы данных: docker-entrypoint-initdb.d Все *.sql или *.sh файлы в этом каталоге - скрипты для инициализации БД. Детали использования:

  1. если БД уже была проинициализирована ранее, то никакие изменения к ней применяться не будут;

  2. если в каталоге присутствует несколько файлов, то они будут отсортированы по имени с использованием текущей локали (по умолчанию en_US.utf8).

services:
  postgres:
    image: postgres:16.3
    environment:
      POSTGRES_DB: "testdb"
      POSTGRES_USER: "testuser"
      POSTGRES_PASSWORD: "testpass"
    volumes:
      - .:/docker-entrypoint-initdb.d
    ports:
      - "5432:5432"

Для постоянного размещения БД нужно подмонтировать соответствующий каталог (куда будут сохраняться данные) в контейнер и при необходимости переопределить переменную окружения PGDATA

services:
  postgres:
    image: postgres:16.3
    environment:
      POSTGRES_DB: "testdb"
      POSTGRES_USER: "testuser"
      POSTGRES_PASSWORD: "testpass"
      PGDATA: "/var/lib/postgresql/data/pgdata"
    volumes:
      - .:/docker-entrypoint-initdb.d
      - mydata:/var/lib/postgresql/data
    ports:
      - "5432:5432"
volumes:
  mydata:

Подключение к базе через psql

psql -d testdb -U testuser -W -h 127.0.0.1 -p 5430

Примеры

Nginx

Создать директорию nginx_config.conf и внутри файл python_microservices

server {
  listen 8080;

  location /api/firstendpoint {
    proxy_pass http://firstendpoint:8000/api/firstendpoint;
  }

  location /api/secondendpoint {
    proxy_pass http://secondendpoint:8000/api/secondendpoint;
  }
}

Compose:

version: '3.7'

services:
  nginx:
    image: nginx:latest
    ports:
      - "8080:8080"
    volumes:
      - ./nginx_config.conf:/etc/nginx/conf.d/default.conf
    depends_on:
      - cast_service
      - movie_service

Источник

NGINX reverse proxy с https терминацией 

Обслуживает несколько доменов, для одного из доменов путь /auth ведет на отдельный сервер

Структура проекта: 

>certs
.env
docker-compose.yaml
nginx.conf.template

Директория certs: сертификаты в формате <domain name>.crt и <domain name>.key

.env 

# Backend сервисы
WOOD_BACKEND_IP=192.168.1.194
WOOD_BACKEND_PORT=8000
HUB_BACKEND_IP=192.168.1.194
HUB_BACKEND_PORT=8021
HUB_BACKEND_WEB_PORT=8020

WOOD_AUTH_IP=192.168.1.194
WOOD_AUTH_PORT=8001

# Домены
HUB_DOMAIN=hub.bobrobotirk.ru
HUB_WEB_DOMAIN=hubui.bobrobotirk.ru
WOOD_DOMAIN=wood.bobrobotirk.ru

nginx.conf.template 

worker_processes auto;

events {
    worker_connections 1024;
}

http {
    include mime.types;
    default_type application/octet-stream;
    sendfile on;
    keepalive_timeout 65;

    # SSL-настройки
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_prefer_server_ciphers on;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;

    # Upstreams
    upstream hub_backend {
        server ${HUB_BACKEND_IP}:${HUB_BACKEND_PORT};
    }

    upstream hub_backend_web {
        server ${HUB_BACKEND_IP}:${HUB_BACKEND_WEB_PORT};
    }

    upstream wood_backend {
        server ${WOOD_BACKEND_IP}:${WOOD_BACKEND_PORT};
    }

    upstream wood_auth_backend {
        server ${WOOD_AUTH_IP}:${WOOD_AUTH_PORT};
    }

    # HTTP → HTTPS редирект
    server {
        listen 80;
        server_name ${HUB_DOMAIN} ${WOOD_DOMAIN};
        return 301 https://$host$request_uri;
    }

    # Конфиг для hub.bobrobotirk.ru
    server {
        listen 443 ssl;
        server_name ${HUB_DOMAIN};

        ssl_certificate /etc/nginx/certs/${HUB_DOMAIN}.crt;
        ssl_certificate_key /etc/nginx/certs/${HUB_DOMAIN}.key;

        location / {
            proxy_pass http://hub_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-Proto $scheme;
        }
    }

    server {
        listen 443 ssl;
        server_name ${HUB_WEB_DOMAIN};

        ssl_certificate /etc/nginx/certs/${HUB_WEB_DOMAIN}.crt;
        ssl_certificate_key /etc/nginx/certs/${HUB_WEB_DOMAIN}.key;

        location / {
            proxy_pass http://hub_backend_web;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            }
        }

    # Конфиг для wood.bobrobotirk.ru
    server {
        listen 443 ssl;
        server_name ${WOOD_DOMAIN};

        ssl_certificate /etc/nginx/certs/${WOOD_DOMAIN}.crt;
        ssl_certificate_key /etc/nginx/certs/${WOOD_DOMAIN}.key;

        location /auth {
            proxy_pass http://wood_auth_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }

        location / {
            proxy_pass http://wood_backend;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
        }
    }
}

docker-compose.yaml 

services:
  nginx-proxy:
    image: nginx:latest
    container_name: nginx-proxy
    hostname: nginx-proxy
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf.template:/etc/nginx/templates/nginx.conf.template
      - ./certs:/etc/nginx/certs
    env_file: 
      - .env  # Подключаем переменные из файла
    command: >
      /bin/sh -c "
      envsubst '$${HUB_BACKEND_IP} $${HUB_BACKEND_PORT} $${HUB_BACKEND_WEB_PORT} $${WOOD_BACKEND_IP}
      $${WOOD_BACKEND_PORT} $${WOOD_AUTH_IP} $${WOOD_AUTH_PORT}
      $${HUB_DOMAIN} $${HUB_WEB_DOMAIN} $${WOOD_DOMAIN}'
      < /etc/nginx/templates/nginx.conf.template
      > /etc/nginx/nginx.conf
      && nginx -g 'daemon off;'
      "
    restart: no

Примеры

Файловый сервер

Один из самых простых S3-совместимых серверов - minio (официальный сайт) Еще есть FreeNAS.

Запуск сервера

Compose файл для тестов:

services:
  minio:
    image: minio/minio:latest
    container_name: minio
    restart: unless-stopped
    volumes:
      - minio-storage:/data
      - minio-config:/root/.minio
    environment:
      - MINIO_ROOT_USER=miniuser
      - MINIO_ROOT_PASSWORD=admin123
    command: server /data --console-address ":9001"
    ports:
      - "9000:9000"
      - "9001:9001"
volumes:
  minio-storage:
  minio-config:

Запускает сервер API на 9000 порту, web интерфейс управления на 9001

+ сертификаты

Тоже интересно

Настройка bucket

Создается группа с правом readwrite, создается пользователь и привязывается к группе. Создается bucket. 

Из-под пользователя создается ключ доступа.

 

Примеры

Mariadb

Установка клиента mariadb 

sudo apt install mariadb-client
mysql -u user -p -h 127.0.0.1 -P 3306

Dockerfile 

FROM mariadb:latest

# Устанавливаем переменные окружения
ENV MYSQL_ROOT_PASSWORD=...
ENV MYSQL_DATABASE=...
ENV MYSQL_USER=...
ENV MYSQL_PASSWORD=...
#ENV MYSQL_ROOT_HOST= '%'                    # Разрешить root-подключения с любого хоста (опционально)

# Копируем SQL-скрипт для дополнительных прав
COPY ./init.sql /docker-entrypoint-initdb.d/

init.sql 

GRANT ALL PRIVILEGES ON wood_db.* TO 'wooduser'@'%';
FLUSH PRIVILEGES;

docker-compose.yaml 

services:
  mariadb:
    image: hub.bobrobotirk.ru/appone-db:0.1.0
    container_name: mariadb
    volumes:
      - ./dbdata:/var/lib/mysql
    ports:
      - "${MYSQL_PORT}:3306"
    restart: unless-stopped

 

 

 

k8s

k8s

Тестовый kubernetes

Гитхаб книги

Интересная статья по настройке HA k8s

Hard way установка

Docker desktop

Введение.

Для изучения kubernetes в книге "The kubernetes book 2024 edition" автора Nigel Poulton предложено использовать Docker Desktop для запуска одноузлового кластера и дальнейших экспериментов. Я решил не устанавливать лишнего в систему и запустить все на виртуальной машине. Итоговый стек: Windows 10 - Virtualbox 7.0 - Ubuntu 24.04 - Docker Desktop - K8s.

Настройки VM:

k8s_install_vmsettings1.JPG

k8s_install_vmsettings2.JPG

k8s_install_vmsettings3.JPG

Установка

mkdir -p $HOME/.kube
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl gpg
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
sudo systemctl enable --now kubelet
swapoff -a
kubectl
kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=192.168.0.109
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
kubectl get nodes
kubeadm token create --print-join-command
kubectl get nodes
kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
kubectl get no
kubectl get po --all-namespaces

Дополнительные удобства

Настройка другого редактора (по умолчанию vi) например при выполнении команды kubectl edit pod ... 

nano .bashrc
#Добавить строку
export EDITOR=nano
#Для использования в текущей сессии, в последующих сессиях автоматически
source ~/.bashrc

При установке через kubeadm для балансировки трафика требуется MetalLB, детали установки

Установка kubectl для управления с другой системы

curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

Скопировать файл авторизации config в ~/.kube/config

k8s

Сетевая подсистема

Стартовая информация

Сетевой плагин выбирается во время установки кластера.

 Документация, сетевая модель K8s Выдержки:

  1. Сетевая подсистема используется только подами (не нодами).
  2. У каждой node свой пул ip адресов для запущенных у них pod.
  3. Каждый Pod в кластере имеет собственный уникальный в пределах кластера IP адрес.
  4. У каждого Pod свое частное сетевое пространство, общее для всех контейнеров внутри Pod. Контейнеры внутри Pod взаимодействуют через localhost.
  5. Pod'ы взаимодействуют с Pod на других нодах при помощи сетевого плагина (CNI).
  6. Служба - это метод предоставления доступа к Pod в кластере (внутренний и внешний)

Вот вроде просто, но нихера не понятно. Поэтому дальше начинается самое веселое) 

Следствия пункта 1. Связность между нодами и контроллером опосредованно зависит от сетевого взаимодействия подов. Поэтому вопрос сети при управлении - один вопрос, вопрос сети подов - второй вопрос.

Первый вопрос относительно простой: сетевая видимость точка - точка между IP адресами. Необходимые порты при настройке port-forwarding: 

На мастер нодах:

TCP     6443*       Kubernetes API Server
TCP     2379-2380   etcd server client API
TCP     10250       Kubelet API
TCP     10251       kube-scheduler
TCP     10252       kube-controller-manager
TCP     10255       Read-Only Kubelet API

На воркерах: 

TCP     10250       Kubelet API
TCP     10255       Read-Only Kubelet API
TCP     30000-32767 NodePort Services

Открываем порты и управление начнет работать. Теперь нужна сетевая связность между подами.

Для использования службы типа LoadBalancer необходимо установить балансировщик, например MetalLB. При существовании кластера в пределах одного L2 сегмента хватит L2 режима. Однако при разных сетях у worker потребуется BGP. Картинку можно представить следующим образом: 

Роли маршрутизаторов R1 и R2 выполняют сетевые плагины (MetalLB, Calico, ...) в BGP режиме. Им необходим обмен маршрутной информацией в пределах L3 сети. Классическая сетевая задача - сделать видимым IP Pool 1 для IP Pool 2. Тут можно решить при помощи VXLAN и т д. В случае реализации без туннелей в L3 сети требуется, чтобы маршрутизаторы внутри этой сети также обладали маршрутной информацией.

Настройка MetalLB

Примените манифест для установки MetalLB 

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.13.7/config/manifests/metallb-native.yaml

Дождаться запуска контейнеров 

kubectl get pods -n metallb-system

Создайте конфигурационный файл для MetalLB. Например, metallb-config.yaml 

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.1.240-192.168.1.250  # Укажите диапазон IP-адресов, доступных в вашей сети
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: l2advert
  namespace: metallb-system
spec:
  ipAddressPools:
  - first-pool

Применить конфигурацию: 

kubectl apply -f metallb-config.yaml


k8s

Pod & containers

Pod (под)

Pod это уровень абстракции. Он включает:

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

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

Настройка ноды для пода

NodeSelectors - список меток нодов. Простейший случай.

Affinity and anti-affinity - продвинутый способ Позволяет 
attract
• Anti-affinity rules repel
• Hard rules must be obeyed
• Soft rules are only suggestions

Topology spread constraints - ограничения на топологию
Resource requests and resource limits

Теория процесса запуска pod

  1. Создать YAML манифест
  2. Отправить манифест на API сервер
  3. Запрос будет аутентифицирован и авторизован
  4. Спецификация будет проверена
  5. Планировщик отфильтрует ноды на основе ограничений
  6. Под будет привязан к удовлетворяющей требованиям ноде
  7. Сервис kubelet на ноде получит задание
  8. Сервис kubelet скачает спецификацию и сформирует задачу для исполнения
  9. Сервис kubelet мониторит статус поды и в случае изменения направляет информацию на планировщик

Запуск пода

Есть два варианта: непосредственно через манифест на ноде или через контроллер. Первый вариант быстрый но без большинства возможностей (статический под, типа docker container). Второй вариант используется обычно.

Кластер создает сеть подов и автоматически подключает все поды к ней. Это одноуровневая L2 overlay сеть

Статусы пода

Pending под еще не создан, поиск ноды для запуска
Running нода найдена, запуск произведен
Init:X/Y исполнение инит контейнеров, завершено X из Y

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

Структура YAML файла

Верхний уровень

Параметр Описание
Kind

Тип определяемого объекта. В данном случае Pod

apiVersion

Версия API

metadata

Метаданные

spec

Спецификация контейнеров

Metadata: метаданные пода

Параметр Описание
name

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

labels

Метки пода

Spec: описание параметров контейнера, томов, внутри для каждого контейнера - name: имя_контейнера

Параметр Описание
containers

Обычные контейнеры 

spec:
  initContainers:
  - name: ...
  containers:
  - name: ...
initContainers

Контейнеры, запускаемые до старта обычных контейнеров. Обычные запускаются только после завершения init контейнеров.

volumes:

Тома 

volumes:
  - name: html
    emptyDir: {}

Параметры контейнера:

Параметр Описание
image

Образ 

image: nigelpoulton/k8sbook:1.0

Для использования другого хаба добавить URL перед именем образа

 

ports

Порты

resources

ограничения на ресурсы

resources:
  requests: <<==== Minimums for scheduling
    cpu: 0.5
    memory: 256Mi
  limits: <<==== Maximums for kubelet to cap
    cpu: 1.0
    memory: 512Mi

Если нода с нужными ресурсами не найдена - под в статусе Pending. Для всех контейнеров в поде.

env

Переменные окружения. 

env:
- name: GIT_SYNC_REPO
  value: https://github.com/nigelpoulton/ps-sidecar.git
volumeMounts

Тома 

volumeMounts:
- name: html <<==== Mount shared volume
  mountPath: /usr/share/nginx/

Настройки тома проводятся отдельно

Пример 1. 

kind: Pod
apiVersion: v1
metadata:
  name: hello-pod
  labels:
    zone: prod
    version: v1
spec:
  containers:
  - name: hello-ctr
    image: nigelpoulton/k8sbook:1.0
    ports:
    - containerPort: 8080
    resources:
      limits:
        memory: 128Mi
        cpu: 0.5

Пример 2. Init контейнер. 

apiVersion: v1
kind: Pod
metadata:
  name: initpod
  labels:
    app: initializer
spec:
  initContainers:
  - name: init-ctr
    # Pinned to 1.28 as newer versions have a sketchy nslookup command that doesn't work. Can also use a non-busybox image here
    image: busybox:1.28.4
    command: ['sh', '-c', 'until nslookup k8sbook; do echo waiting for k8sbook service; sleep 1; done; echo Service found!']
  containers:
    - name: web-ctr
      image: nigelpoulton/web-app:1.0
      ports:
        - containerPort: 8080

Пока образы в init контейнере не завершились, статус в Init:0/1

kubectl get pods --watch
NAME                               READY   STATUS     RESTARTS   AGE
initpod                            0/1     Init:0/1   0          16s

Пример 3. Дополнительный контейнер, обновляющий папку при изменении репозитория 

# Some network drivers and laptop VM implementations cause issues with Service port mapping
# Minikube users may have to `minikube service svc-sidecar` to be able to access on `localhost:30001`
# Other users may have to run `kubectl port-forward service/svc-sidecar 30001:80`
apiVersion: v1
kind: Pod
metadata:
  name: git-sync
  labels:
    app: sidecar
spec:
  containers:
  - name: ctr-web
    image: nginx
    volumeMounts:
    - name: html
      mountPath: /usr/share/nginx/
  - name: ctr-sync
    image: k8s.gcr.io/git-sync:v3.1.6
    volumeMounts:
    - name: html
      mountPath: /tmp/git
    env:
    - name: GIT_SYNC_REPO
      value: https://gitverse.ru/bobrobot/k8s_pods.git
    - name: GIT_SYNC_BRANCH
      value: master
    - name: GIT_SYNC_DEPTH
      value: "1"
    - name: GIT_SYNC_DEST
      value: "html"
  volumes:
  - name: html
    emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
  name: svc-sidecar
spec:
  selector:
    app: sidecar
  type: NodePort
  ports:
  - port: 80
    nodePort: 30001

При обращении на адрес кластера или ноды будет отображаться страница.

Основные команды

Команда Доп. пар. Описание
kubectl explain pods --recursive
Вывод всех параметров, доступных для конфигурирования Pod
kubectl get pods
список контейнеров

-o yaml расширенная информация о подах
kubectl apply -f file.yml Создание под из file.yml
kubectl describe  pod pod_name Описание пода
kubectl logs pod_name
логи на поде. По умолчанию первого контейнера в поде

--container cont_name логи конкретного контейнера
kubectl exec
Выполнение команд внутри контейнера Два варианта

pod_name -- command Выполняет command на pod_name и возвращает результат в консоль. По умолчанию на первом контейнере. -- container для указания контейнера.

-it pod_name -- command Подключается в интерактивном режиме на контейнер и выполняет команду. 
kubectl exec -it hello-pod -- sh
kubectl edit pod pod_name
Редактирование под (для nano - в части дополнительные удобства Тестовый k8s) Пока не получилось.
kubectl delete  pod Удаление подов. Имена подов через пробел

svc Удаление сервисов.

-f  Удаление с использованием yaml файлов.

Container (контейнер)

Паттерны мультиконтейнеров

Init контейнеры - специальный тип контейнеров, для которых K8s гарантирует единственный запуск и завершение, перед остальными контейнерами. Пример: есть приложение и внешнее API с которым обязательно должно быть взаимодействие при старте. Вместо нагрузки на основную логику, можно процесс проверки вывести в init контейнер.

Slidecar контейнеры - выполняют периферийные задачи. Пока что бета.

k8s

Namespaces

Разделяет кластер на виртуальные кластеры. Это не Namespace ядра! По умолчанию объекты попадают в default namespace. Настраиваются свои пользователи, права, ресурсы и политики.

Создание и привязка к пространству имен

Императивный способ: 

kubectl create ns hydra

Декларативный способ: создать yaml файл и применить его. 


Для привязки объекта к пространству имен в метаданных нужно указать namespace 

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: shield <<==== Namespace
  name: default

Структура YAML файла

Верхний уровень

Параметр Описание
Kind

Тип определяемого объекта, Namespace

apiVersion

Версия API

metadata

Метаданные

Metadata

Параметр Описание
name Имя
labels метки

Примеры

kind: Namespace
apiVersion: v1
metadata:
  name: shield
  labels:
    env: marvel

Основные команды

Команда Доп. пар. Описание
kubectl api-resources
Список API ресурсов, в частности - делятся ли на namespace
kubectl get namespaces
Список пространств имен
kubectl describe ns name_ns
Информация по name_ns пространству имен
Все команды получения информации --namespace default Фильтрация по определенному namespace

--all-namespaces Для всех namespace
kubectl create ns ns_name
Создание пространства имен ns_name
kubectl delete ns ns_name
Удаление пространства имен ns_name
kubectl config set-context --current --namespace shield
Установка пространства имен по умолчанию
k8s

Deployment

Deployments наиболее популярный способ для запуска приложений без сохранения состояния. Это добавляет проверку состояния, масштабирование, восстановление. 

Реализовано через deployment контроллер. Каждый контроллер управляет одним или несколькими одинаковыми подами.

k8s_deployments_1.JPG

Масштабирование (Scalling)

Существуют несколько типов 

Тип Описание
Horizontal Pod Autoscaler Масштабирование количества подов, наиболее часто используется.
Vertical Pod Autoscaler Масштабирование ресурсов, потребляемых подами. Не установлен по умолчанию. Редко используется
Cluster Autoscaler Добавляет/удаляет ноды. По умолчанию, часто используется.

Например, указываем кол-во подов от 2 до 10. Нагрузка повысилась, и HPA запрашивает еще 2 пода. Они запускаются. Но нагрузка растет, и запрашивается еще 2 пода. Однако на существующем кластере нет возможности запустить еще 2 пода, и они переходят в статус Pending. CA определяет Pending поды и увеличивает количество нодов, запуская там поды. И наоборот.

Масштабирование связано с понятием текущего состояния (state). Есть необходимое состояние и наблюдаемое состояние. При неравенстве контроллер запускает процесс изменений. 

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

Реплики

ReplicaSets - набор настроек и подов с одной версией конфигурации. При обновлении yaml создается вторая ReplicaSet и один новый под. Из старой ReplicaSet удаляется один под. И так далее до полного обновления. Но конфигурация сохраняется. Можно вернуть к старым настройкам.

Структура YAML файла

Верхний уровень

Параметр Описание
kind Тип, в данном случае Deployments
spec Спецификация

spec

Параметр Описание
strategy Стратегия восстановления
replicas кол-во реплик
selector правила выбора меток
template описание шаблона (все аналогично описанию пода)

Примеры

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hello-deploy
spec:
  replicas: 10
  selector:
    matchLabels:
      app: hello-world
  revisionHistoryLimit: 5
  progressDeadlineSeconds: 300
  minReadySeconds: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: hello-world
    spec:
      containers:
      - name: hello-pod
        image: nigelpoulton/k8sbook:1.0
        ports:
        - containerPort: 8080
        resources:
          limits:
            memory: 128Mi
            cpu: 0.1

Пример сервиса для данного приложения

apiVersion: v1
kind: Service
metadata:
  name: lb-svc
  labels:
    app: hello-world
spec:
  type: LoadBalancer
  ports:
  - port: 8080
    protocol: TCP
  selector:
    app: hello-world

Основные команды

Команда Доп. пар. Описание
kubectl get deploy dep_name   статус
kubectl describe deploy dep-name
Расширенная информация
kubectl get rs   Список реплик
kubectl scale deploy dep_name --replicas count Императивное масштабирование. Нежелательно.
kubectl rollout status deployment dep_name   Статус обновления подов
kubectl rollout pause deploy dep_name   Приостановка обновления
kubectl describe deploy dep_name   Отображает в частности список роллбеков
kubectl rollout history deployment dep_name   История роллбеков
kubectl rollout undo deployment hello-deploy --to-revision=1   Возврат. Быстро, но не рекомендуется. Лучше через загрузку старого файла из репозитория и обновление.
k8s

Services

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

В сервисе - раздел selector 

spec:
  replicas: 10
  <Snip>
  template:
    metadata:
      labels:
        project: tkb
        zone: prod
<Snip>
---
apiVersion: v1
kind: Service
metadata:
  name: tkb
spec:
  ports:
  - port: 8080
  selector:
    project: tkb 
    zone: prod 

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

ClusterIP Используется для доступности подов внутри кластера. Доступность по имени сервиса.

NodePort Services Используется для доступа приложений снаружи кластера. Добавляет указанный порт на каждую ноду. 

apiVersion: v1
kind: Service
metadata:
  name: skippy <<==== Registered with the internal cluster DNS (ClusterIP)
spec:
  type: NodePort <<==== Service type
  ports:
  - port: 8080 <<==== ClusterIP port
    targetPort: 9000 <<==== Application port in container
    nodePort: 30050 <<==== External port on every cluster node (NodePort)
selector:
  app: hello-world

В данном примере изнутри под доступен по порту 8080, снаружи - по порту 30050. Диапазон портов 30000-32767.

LoadBalancer Services Используется для сервисов со стартовым диапазоном портов, наиболее часто.  

apiVersion: v1
kind: Service
metadata:
  name: lb <<==== Registered with cluster DNS
spec:
  type: LoadBalancer
  ports:
  - port: 8080 <<==== Load balancer port
    targetPort: 9000 <<==== Application port inside container
selector:
  project: tkb

Мой кубер использует flannel, а для корректной работы LoadBalancer нужен балансировщик, например MetalLB. Стек в случае балансировщика: 

k8s_services_1.JPG

Headless сервисы

Сервисы без IP адреса. Их цель - создать DNS записи для StatefulSet подов. Клиенты запрашивают DNS имена подов и направляют непосредственно им запросы вместо использования кластерного IP. Пример сервиса: 

apiVersion: v1
kind: Service <<==== Normal Kubernetes Service
metadata:
  name: dullahan
  labels:
    app: web
spec:
  ports:
    - port: 80
  name: web
  clusterIP: None <<==== Make this a headless Service
  selector:
    app: web

Структура YAML файла

Верхний уровень

Параметр Описание
kind Тип, в данном случае Service
spec Спецификация

spec

Параметр Описание
type тип (ClusterIP, NodePort,  LoadBalancer)
ports

port - порт фронтенда

targetPort - порт на бэке

selector правила выбора меток

Пример yaml файла

apiVersion: v1
kind: Service
metadata:
  name: cloud-lb
spec:
  type: LoadBalancer
  ports:
  - port: 9000
    targetPort: 8080
  selector:
    chapter: services

Основные команды

Команда Доп. пар. Описание
kubectl expose deployment dep_name --type=LoadBalancer   Ручное создание сервиса. Вот только не поехало.
kubectl get svc -o wide   Информация по сервисам
kubectl get endpointslices
Список ендпоинтов
kubectl describe endpointslice epname
Описание ендпоинта

k8s

Ingress

Используется для организации внешнего взаимодействия на L7 уровне. Ingress ресурсы определяют правила маршрутизации, Ingress контроллер выполняет задачу. 

Маршрутизация в смысле L7, не в смысле L3

Могут быть host-based и path-based маршруты:

Host-based example Path-based example Backend K8s Service
shield.mcu.com mcu.com/shield shield
hydra.mcu.com mcu.com/hydra hydra

k8s_ingress_1.JPG

Необходим внешний Ingress-controller, очень часто Nginx.

Ingress классы

Позволяют запустить несколько ingress контроллеров в одном кластере. Сначала привязывается Ingress контроллер к классу, затем при создании объект Ingress привязывается к классу.

Пример

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: mcu-all
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: shield.mcu.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: svc-shield
            port:
              number: 8080
  - host: mcu.com
    http:
      paths:
      - path: /shield
        pathType: Prefix
        backend:
          service:
            name: svc-shield
            port:
              number: 8080

Основные команды

Команда Доп. пар. Описание
kubectl get ingressclass   Список классов Ingress
kubectl describe ingressclass class_name   Детализация для класса class_name
kubectl get ingress my-ingress -n my-ns -o yaml   Получить конфигурацию в виде yaml
kubectl get ing   Список ingress
kubectl describe ing mcu-all
Детализация ingress

k8s

Storages

Система хранения работает через драйверы (CSI плагины) или локально на нодах. Второй вариант неудобный. Далее первый вариант. Разработчик обычно предоставляет плагины в виде Helm чартов или yaml установщиков. Они устанавливаются в виде набора подов в namespace kube-system. Список плагинов Для тестов можно использовать встроенный драйвер, OpenEbs. К вопросу выбора драйвера, архитектуры хранилища и безопасности необходимо подходить очень серьезно.

Процесс запроса ресурсов: Pod Volume - PVC - SC - CSI Plugin

Storage Classes

ресурсы в storage.k8s.io/v1 группе. Неизменяемый. Для обновления нужно удалить и создать. SC access mode:

Все PV должны подключиться в одинаковом режиме.

Reclaim policy (политика восстановления)

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

Volume binding mode

Момент создания бакета. Immediate - сразу же, WaitForFirstConsumer - при подключении первого.

Примеры

Локальное хранилище (устаревшее)

На воркере 

sudo mkdir -p /mnt/disks/ssd1
sudo chmod 777 /mnt/disks/ssd1  # Для упрощения примера

Настройка PV 

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-local-pv
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - <node-name>  # Замените на имя узла, где находится директория

Настройка PVC 

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: example-local-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: local-storage
  resources:
    requests:
      storage: 10Gi

Проверка связи 

kubectl get pv
kubectl get pvc

Использование в Pod 

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: nginx
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: local-storage
  volumes:
    - name: local-storage
      persistentVolumeClaim:
        claimName: example-local-pvc

Удаление ресурсов 

kubectl delete pod example-pod
kubectl delete pvc example-local-pvc
kubectl delete pv example-local-pv

Хранилище Yandex.cloud

S3 aws - совместимое хранилище. 

1. Настройка доступа через консоль 

Установить консоль yc 

curl -sSL https://storage.yandexcloud.net/yandexcloud-yc/install.sh | bash
source ~/.bashrc

Запросить новый OAuth токен. Время жизни токена 1 год.

Инициализировать консоль 

yc init

2. Настройка доступа к бакету

Через web-консоль создать бакет.

k8s_volumes_1.JPG

Выяснить folder_id созданного аккаунта 

yc storage bucket get k8stest

name: k8stest
folder_id: b...q
anonymous_access_flags:
  read: false
  list: false
  config_read: false
default_storage_class: STANDARD
versioning: VERSIONING_DISABLED
max_size: "1073741824"
created_at: "2025-03-23T06:35:58.715069Z"

Создать сервисный аккаунт для доступа к бакету, в выводе будет id аккаунта

yc iam service-account create --name k8stest --output key.json

Файл key.json понадобится далее.

Добавить роль для созданного бакета сервис аккаунту 

yc resource-manager folder add-access-binding <идентификатор_каталога> \
  --role <роль> \
  --subject serviceAccount:<идентификатор_сервисного_аккаунта>

3. Установка CSI плагина для yandex.cloud

git clone https://github.com/deckhouse/yandex-csi-driver.git
cd yandex-csi-driver

В самом git сказано, что запускать нужно из папки deploy/1.17 установив 2 переменные. У меня это не заработало.

В папке yandex-csi-driver/charts/yandex-csi-controller установить serviceAccountJSON и folderID

В файле csidriver.yaml заменить apiVersion: storage.k8s.io/v1beta1 на apiVersion: storage.k8s.io/v1

Дополнительно:

# Список сервис аккаунтов
yc iam service-account list 
# Детализация информации по аккаунту
yc iam service-account get <идентификатор_аккаунта>
# Удаление аккаунта
yc iam service-account delete <идентификатор_аккаунта>

И нечего с yandex не получилось.

Настройка MinIO

Настройка внешнего MinIO

Настройка авторизации 

Создать Secret. Ключ и Секрет не в Base64, а как указано при создании бакета.

apiVersion: v1
kind: Secret
metadata:
  namespace: kube-system
  name: csi-s3-secret
stringData:
  accessKeyID: XP5...Ih
  secretAccessKey: klz...zo
  # For AWS set it to "https://s3.<region>.amazonaws.com"
  endpoint: http://192.168.1.194:9000
  # If not on S3, set it to ""
  region: ""

Применить Secret 

kubectl apply -f 1-minio-credentials.yaml
kubectl get secret

Установка csi драйвера

Проверить установленные csi драйверы, поставить драйвер

git clone https://github.com/ctrox/csi-s3.git
cd csi-s3/deploy/kubernetes
kubectl apply -f .

Вот только какого-то хера в данной директории не было yaml для создания драйвера) Добавляем драйвер

apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: ch.ctrox.csi.s3-driver
spec:
  attachRequired: false
  podInfoOnMount: true

Обязательно в списке драйверов должен появиться драйвер  

kubectl get csidrivers.storage.k8s.io
NAME                     ATTACHREQUIRED   PODINFOONMOUNT   TOKENREQUESTS   REQUIRESREPUBLISH   MODES        AGE
ch.ctrox.csi.s3-driver   false            true             <unset>         false               Persistent   36m

И все поды csi должны быть запущены 

kubectl --namespace kube-system get pods | grep csi
csi-attacher-s3-0               1/1     Running   0              9h
csi-provisioner-s3-0            2/2     Running   0              9h
csi-s3-f5v74                    2/2     Running   0              9h

Настройка класса и PVC

Добавляем StorageClass

---
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: csi-s3
provisioner: ch.ctrox.csi.s3-driver
parameters:
  # specify which mounter to use
  # can be set to rclone, s3fs, goofys or s3backer
  #mounter: rclone
  mounter: "s3fs"
  otherOpts: "-o allow_other -o uid=0 -o gid=0 -o umask=000"
  # to use an existing bucket, specify it here:
  bucket: bucketone
  path: "pvc-fbd999ab-1ba7-4b07-922d-51270e6028d9"
  csi.storage.k8s.io/provisioner-secret-name: csi-s3-secret
  csi.storage.k8s.io/provisioner-secret-namespace: kube-system
  csi.storage.k8s.io/controller-publish-secret-name: csi-s3-secret
  csi.storage.k8s.io/controller-publish-secret-namespace: kube-system
  csi.storage.k8s.io/node-stage-secret-name: csi-s3-secret
  csi.storage.k8s.io/node-stage-secret-namespace: kube-system
  csi.storage.k8s.io/node-publish-secret-name: csi-s3-secret
  csi.storage.k8s.io/node-publish-secret-namespace: kube-system
  sslVerify: "false"
reclaimPolicy: Retain
volumeBindingMode: Immediate

mounter rclone на финальном этапе отказался создавать файлы.

В директории бакета была создана директория pvc-fbd999ab-1ba7-4b07-922d-51270e6028d9/csi-fs Не знаю почему. но при команде ls (проверка) он находился внутри нее.

Добавляем PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: csi-s3-pvc
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: csi-s3

Проверка: 

apiVersion: v1
kind: Pod
metadata:
  name: minio-test-pod
spec:
  containers:
  - name: app
    image: alpine
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: minio-storage
      mountPath: /mnt/minio
  volumes:
  - name: minio-storage
    persistentVolumeClaim:
      claimName: csi-s3-pvc
      readOnly: false

Команда 

kubectl exec -it minio-test-pod -- sh -c "echo 'New test' > /mnt/minio/test2.txt && ls /mnt/minio"

должна вывести созданный файл в списке.

Основные команды

Команда Доп. пар. Описание
kubectl get csidrivers.storage.k8s.io   Список CSI-драйверов
kubectl get storageclass -o wide   Какой PROVISIONER используется
kubectl get pods -n kube-system | grep csi   Поды CSI-драйверов. Какие поды отвечают за CSI
kubectl get daemonsets -n kube-system   Где работает CSI-драйвер

k8s

Config maps & secrets

Набор конфигураций для различных окружений. Включают переменные окружения, конфиг файлы, имена хостов, порты, аккаунты.

kind: ConfigMap
apiVersion: v1
metadata:
  name: epl
data:
  Competition: epl
  Season: 2022-2023
  Champions: Manchester City
  test.conf: |
    env = plex-test
    endpoint = 0.0.0.0:31001
    char = utf8
    vault = PLEX/test
    log-size = 512M

Их можно использовать как переменные окружения, параметры запуска и файлы внутри контейнера.

Использование ConfigMap

В виде переменных окружения: 

apiVersion: v1
kind: Pod
<Snip>
spec:
  containers:
    - name: ctr1
      env:
        - name: FIRSTNAME
          valueFrom:
            configMapKeyRef: <<==== a ConfigMap
              name: multimap <<==== called "multimap"
              key: given

Не изменяются после создания.

В виде аргументов:

Сначала как переменные окружения, затем в команду создания

spec:
containers:
- name: args1
  image: busybox
  env:
    - name: FIRSTNAME <<==== Environment variable called FIRSTNAME
      valueFrom: <<==== based on
        configMapKeyRef: <<==== a ConfigMap
          name: multimap <<==== called "multimap"
          key: given <<==== and populated by the value in the "given" field
    - name: LASTNAME <<==== Environment variable called LASTNAME
      valueFrom: <<==== based on
        configMapKeyRef: <<==== a ConfigMap
          name: multimap <<==== called "multimap"
          key: family <<==== and populated by the value in the "family" field
  command: [ "/bin/sh", "-c", "echo First name $(FIRSTNAME) last name $(LASTNAME)" ]

В виде файлов:

Создается том и привязывается к нему ConfigMap 

apiVersion: v1
kind: Pod
metadata:
  name: cmvol
spec:
  volumes:
    - name: volmap <<==== Create a volume called "volmap"
      configMap: <<==== based on the ConfigMap
        name: multimap <<==== called "multimap"
  containers:
    - name: ctr
      image: nginx
      volumeMounts: <<==== These lines mount the
        - name: volmap <<==== the "volmap" volume into the
          mountPath: /etc/name <<==== container at "/etc/name"

Файлы будут созданы в соответствии именам в ConfigMap. При обновлении ConfigMap файлы в контейнере обновятся.

Secrets

Хранятся в Base64 но внутри контейнера хранятся в tmpfs виде обычного текста.

apiVersion: v1
kind: Secret
metadata:
  name: tkb-secret
  labels:
    chapter: configmaps
type: Opaque
data: <<==== Change to "stringData" for plain text
  username: bmlnZWxwb3VsdG9u
  password: UGFzc3dvcmQxMjM=

Использование в Pod:

apiVersion: v1
kind: Pod
metadata:
  name: secret-pod
  labels:
    topic: secrets
spec:
  volumes:
    - name: secret-vol <<==== Volume name
      secret: <<==== Volume type
        secretName: tkb-secret <<==== Populate volume with this Secret
  containers:
    - name: secret-ctr
      image: nginx
      volumeMounts:
        - name: secret-vol <<==== Mount the volume defined above
          mountPath: "/etc/tkb" <<==== into this path

В директории /etc/tkb будут храниться файлы, по одному на каждое значение.

Основные команды

Команда Доп. пар. Описание
kubectl get cm
Список ConfigMap
k8s

StatefulSet

Очень похожи на Deployments, но StatefulSet дополнительные функции:

Отличие: Deployment создает поды сразу же, а StatefulSet по одному. Это критично для сохранения данных.

Именование подов: <StatefulSet name>-<integer>. Число от 0-...

Для каждого пода создается свой том, с соответствующим именованием. Созданные тома имеют свой жизненный цикл и они не удаляются при масштабировании подов.  

Удаление Statefulset: Автоматического удаления подов нет. Сначала нужно снизить количество до 0. Также нужно использовать terminationGracePeriodSeconds около 10 секунд для безопасного завершения работы.

 

Создаем headless сервис (Services


k8s

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

Авторизация и аутентификация

По умолчанию аутентификация на основе сертификата, но поддерживаются внешние источники. 

Аутентификация на основе сертификата.

Авторизация RBAC (пользователь - действие - ресурс). По умолчанию запрещено все что не разрешено. Роли определяют правила, RoleBindings определяют принадлежность пользователей к ролям. Пример настройки ролей: 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: shield
  name: read-deployments
rules:
- verbs: ["get", "watch", "list"] <<==== Allowed actions
  apiGroups: ["apps"] <<==== on resources
  resources: ["deployments"] <<==== of this type

Пример RoleBinding: 

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-deployments
  namespace: shield
subjects:
- kind: User
  name: sky <<==== Name of the authenticated user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: read-deployments <<==== This is the Role to bind to the user
  apiGroup: rbac.authorization.k8s.io

Свойства правил роли: 

verbs  ["get", "watch", "list", "create", "update", "patch", "delete"]

ApiGroups (в пределах namespace):

apiGroup Ресурс
"" pods, secrets
“storage.k8s.io” storageclass
“apps” deployments

Полный список API ресурсов: 

kubectl api-resources --sort-by name -o wide

Можно использовать звездочку. 

Все роли используются только в контексте namespace!

Кластерные роли и привязки

ClusterRoleBindings используется для создания шаблонов ролей и привязки их к конкретным ролям. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole <<==== Cluster-scoped role
metadata:
  name: read-deployments
rules:
- verbs: ["get", "watch", "list"]
  apiGroups: ["apps"]
  resources: ["deployments"]

Пользователи

Интересная статья   Еще одна, тоже стоит почитать

Обычных пользователей нельзя добавить через вызовы API. Возможные варианты: 

Структура файла ~/.kube/config


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


Пример создания пользователя с авторизацией через X.509 сертификат.

Создаем директорию хранения информации о пользователях и генерируем в нее ключ 

mkdir -p users/sergey/.certs
openssl genrsa -out ~/users/sergey/.certs/sergey.key 2048

Генерируем запрос на сертификат 

openssl req -new -key ~/users/sergey/.certs/sergey.key -out ~/users/sergey/.certs/sergey.csr -subj "/CN=sergey/O=testgroup"

Обработка запроса на сертификат 

openssl x509 -req -in ~/users/sergey/.certs/sergey.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/users/sergey/.certs/sergey.crt -days 500

В некоторых ресурсах говорится, что команда kubectl config set-credentials ... создает пользователя в кластере Kubernetes. Но это не так, команда kubectl config ... создает/модифицирует файл .kube/config, поэтому нужно быть осторожным и не побить свой файл. А Kubernetes авторизует всех пользователей, чей сертификат подписан его центром сертификации. 

Добавляем пользователя sergey 

kubectl config set-credentials sergey \
--client-certificate=/root/users/sergey/.certs/sergey.crt \
--client-key=/root/users/sergey/.certs/sergey.key \
--embed-certs=true

Если нужно - создали бы настройки кластера, но у нас есть, поэтому создаем контекст с существующим кластером. Namespace, если нужно, указывается в настройках контекста. 

kubectl config set-context sergey-context --cluster=kubernetes --user=sergey --namespace=sergey-ns

Теперь осталось пользователю определить права. 

Например определим роль sergey-ns-full с полным доступом к namespace sergey-ns 

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: sergey-ns-full
  namespace: sergey-ns
rules:
  - apiGroups: [ "*" ]
    resources: [ "*" ]
    verbs: [ "*" ]

Сейчас вместо привязки пользователя, привяжем группу к роли.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: testgroup-rolebinding  # Название RoleBinding
  namespace: sergey-ns         # Namespace, где применяется
subjects:
- kind: Group                 # Тип субъекта — группа
  name: testgroup             # Название группы
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                  # Тип привязываемой роли (Role или ClusterRole)
  name: sergey-ns-full        # Название роли
  apiGroup: rbac.authorization.k8s.io

Переключаемся на контекст и проверяем 

kubectl config use-context sergey-context

Создаем простой под 

kind: Pod
apiVersion: v1
metadata:
  name: hello-pod
  labels:
    zone: prod
    version: v1
spec:
  containers:
  - name: hello-ctr
    image: nigelpoulton/k8sbook:1.0
    ports:
    - containerPort: 8080
    resources:
      limits:
        memory: 128Mi
        cpu: 0.5

Проверяем факт создания пода 

kubectl get pods

Удалось!

Основные команды управления пользователями

Если при создании ... указать флаг --embed-certs=true то тогда вместо путей к файлам сертификатов, в файл настройки будут встроено содержание сертификатов в Base64.

Команда Доп. параметры
Описание
kubectl get clusterroles.rbac.authorization.k8s.io --all-namespaces
Список пользователей
kubectl config view
Показать текущую конфигурацию (.kube/config)
kubectl config current-context
Показать текущий активный контекст
kubectl config get-contexts
Список всех контекстов
kubectl config use-context cont_name
Переключиться на контекст cont_name
kubectl config set-cluster clast_name
Добавить/изменить кластер  
kubectl config set-cluster my-new-cluster \
  --server=https://10.0.0.1:6443 \
  --certificate-authority=./ca.crt
kubectl config set-credentials
Добавить/изменить учетные данные пользователя 
kubectl config set-credentials sergey \
--client-certificate=/root/users/sergey/.certs/sergey.crt \
--client-key=/root/users/sergey/.certs/sergey.key \
--embed-certs=true
kubectl config set-context cont_name --cluster=dev-cluster \
--user=dev-user \
--namespace=dev-ns
Создать/изменить контекст
kubectl config delete-context
Удалить контекст
kubectl config delete-cluster 
Удалить кластер
kubectl config delete-user user_name
Удалить пользователя
kubectl config rename-context     
Переименовать контекст

Безопасность, общая теория

Инструменты

Запрет передачи ключей SA

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

apiVersion: v1
kind: Pod
metadata:
  name: service-account-example-pod
spec:
  serviceAccountName: some-service-account
  automountServiceAccountToken: false <<==== This line
<Snip>

Также можно передавать временные ключи, но это потом.

Контроль целостности ресурсов

Файловая система пода в read-only режим

apiVersion: v1
kind: Pod
metadata:
  name: readonly-test
spec:
  securityContext:
    readOnlyRootFilesystem: true <<==== R/O root filesystem
    allowedHostPaths: <<==== Make anything below
      - pathPrefix: "/test" <<==== this mount point
        readOnly: true <<==== read-only (R/O)
<Snip>

Лог действий на кластере и связанной инфраструктуре

Защита данных кластера

Cluster store (обычно etcd) хранит все данные. Необходимо ограничить и контролировать доступ к серверам, на которых работает Cluster store. 

DoS

Подвергается API сервер. Должно быть минимум 3 Control plane сервера и 3 worker ноды. Изоляция etcd на сетевом уровне. Ограничения ресурсов для подов и количества подов. 

apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-quota
  namespace: skippy
spec:
  hard:
    pods: "100"

Доп. опция podPidsLimit ограничивает количество процессов одним подом. Также можно ограничить кол-во подов на одной ноде. 

По умолчанию etcd устанавливается на сервер с control plane. На production кластере нужно разделять.

Запретить сетевое взаимодействие между подами и внешние взаимодействия (где это не нужно) при помощи сетевых политик Kubernetes.

Защита подов и контейнеров

Запрет запуска процессов от root 

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  securityContext: <<==== Applies to all containers in this Pod
    runAsUser: 1000 <<==== Non-root user
  containers:
    - name: demo
      image: example.io/simple:1.0

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

apiVersion: v1
kind: Pod
metadata:
  name: demo
spec:
  securityContext: <<==== Applies to all containers in this Pod
    runAsUser: 1000 <<==== Non-root user
  containers:
    - name: demo
      image: example.io/simple:1.0
      securityContext:
        runAsUser: 2000 <<==== Overrides the Pod-level setting

Рутовые права складываются примерно из 30 capabilities. Простой способ - в тестовом окружении ограничить все и по логам добавлять нужные. Естественно финальное тестирование должно быть максимально всеобъемлющим. Пример разрешений: 

apiVersion: v1
kind: Pod
metadata:
  name: capability-test
spec:
  containers:
    - name: demo
      image: example.io/simple:1.0
      securityContext:
        capabilities:
          add: ["NET_ADMIN", "CHOWN"]

Фильтрация системных вызовов.

Похоже на capabilities, но фильтрует системные вызовы. Способы поиска минимальных разрешений: разрешить все + логгирование, запрет + постепенное разрешение. 

Также есть Pod Security Standarts (PSS) и Pod Security Admission (PSA). PSA применяют PSS при старте пода. 

Основные команды

Параметр Описание
 kubectl describe clusterrole role_name Описание роли
kubectl get clusterrolebindings | grep role_name Список пользователей с такой ролью
kubectl describe clusterrolebindings role_name Информация по сопоставлению
Аналогично для ролей (clusterrolebindings -> rolebindings)

k8s

Job, cronjob

Job

Выполнения разовой задачи. Если запуск задачи завершается с ошибкой, Job перезапускает поды до успешного выполнения или до истечения таймаутов. Когда задача выполнена, Job считается завершённым и больше никогда в кластере не запускается.

Параметры в spec:

Параметр Описание
activeDeadlineSeconds количество секунд, которое отводится всему Job (не для одного пода) на выполнение.
backoffLimit количество попыток. Если указать 2, то Job дважды попробует запустить под и остановится.
ttlSecondsAfterFinished через сколько секунд специальный TimeToLive контроллер должен удалить завершившийся Job вместе с подами и их логами

После успешного завершения задания манифесты (Job и созданные поды) остаются в кластере навсегда. Все поля Job имеют статус Immutable, и поэтому при создании Job из автоматических сценариев сначала удаляют Job, который остался от предыдущего запуска. Генерация уникальных имен для Job приведет к накоплению ненужных манифестов. Обязательно указание ttlseconds...

При создании бесконечного цикла через activeDeadlineSeconds будет отправлен sigterm, затем через 30 секунд sigkill.

Если указать backoffLimit без restartPolicy, то при ошибке Job будет выполняться бесконечно.

Cronjob

Создание Job по расписанию. 

Параметры в spec:

Параметр Описание
schedule Расписание в виде строчки в cron-формате.
startingDeadlineSeconds Опциональный. Если по прошествии этого времени job не стартовал, старт отменяется. Желательно вместе с Forbid.
concurrencyPolicy

Одновременное выполнение заданий. 


Allow позволяет подам следующего задания запускаться. Если задание ежеминутное, за минуту Job не отработал, все равно будет создан ещё один. Одновременно могут выполняться несколько Job’ов. Есть риск перегрузки.

 

Replace заменяет запущенную нагрузку: старый Job убивается, запускается новый. Не самый лучший вариант, этот вариант осознанно.


Forbid запрет запуска новых Job’ов, пока не отработает предыдущий. С этой политикой можно быть уверенным, что всегда запускается только один экземпляр задачи. Используют наиболее часто

successfulJobsHistoryLimit

Глубина истории хранения удачных job, по умолчанию 3

failedJobsHistoryLimit

Глубина истории хранения неудачных job, по умолчанию 1

CronJob использовать аккуратно. Должны быть независимы и иметь возможность работать параллельно. В качестве альтернативы CronJob можно использовать под, в котором запущен самый обычный crond.

Основные команды

Команда Доп. пар. Описание
kubectl get job   список job
  --all-namespaces  
kubectl delete job jname
Удалить jname
kubectl get cronjobs.batch
Список cronjob

Примеры

Job

apiVersion: batch/v1
kind: Job
metadata:
  name: hello
spec:
  backoffLimit: 2
  activeDeadlineSeconds: 60
  ttlSecondsAfterFinished: 100
  template:
    spec:
      containers:
      - name: hello
        image: busybox
        args: 
        - /bin/sh
        - -c
        - date; echo Hello from the Kubernetes cluster
      restartPolicy: Never

Cronjob

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  jobTemplate:
    spec:
      backoffLimit: 2
      activeDeadlineSeconds: 100
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: Never

Helm

Helm

Helm

Один из самых популярных пакетных менеджеров для Kubernetes. 

Управление helm

Установка helm: 

curl https://baltocdn.com/helm/signing.asc | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
sudo apt-get install apt-transport-https --yes
echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/helm.gpg] https://baltocdn.com/helm/stable/debian/ all main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update
sudo apt-get install helm

Репозиторий

Команда Доп. пар. Описание
helm repo list Список репозиториев

add repo_name repo_url

Добавить репозиторий repo_name с адресом repo_url 

 

helm repo add stable https://kubernetes-charts.storage.googleapis.com/

Часто используют bitnami, но в России он сейчас закрыт. Есть зеркало: 

helm repo add bitnami https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami



update

обновить репозиторий

helm search 
repo keyword

Поиск чартов по репозиториям ключевого слова keyword


hub keyword

В официальном репозитории


--max-col-width=0

+ hub/repo полный вывод текста


--output yaml

+hub/repo вывод в yaml


--versions

Отсортировать по версиям чарта

Плагины

Он сам по себе мощный, но ссылка на плагины 

Команда Доп. пар. Описание
helm plugin install url   Установка плагина
helm plugin list
Список плагинов
helm plugin update pl_name
Обновление плагина
helm plugin unistall pl_name

Удаление плагина

Переменные окружения

Зависит от переменных окружения. Основные переменные: 

Переменная Описание
XDG_CACHE_HOME Размещение кешированных данных. По умолчанию ~/.cache/helm
XDG_CONFIG_HOME Размещение конфигурационного файла По умолчанию ~/.config/helm
XDG_DATA_HOME Размещение плагинов helm По умолчанию ~/.local/share/helm
HELM_DRIVER Драйвер для хранения данных. Secret - хранение авторизационных данных в файле, может быть configmap и memory
HELM_NO_PLUGINS Отключить плагины
KUBECONFIG Размещение конфигурационного файла kubectl

Charts

Команда Доп. пар. Описание
helm install name_chart repo Установить из репозитория repo чарт name_chart

--... Переменные внутри чарта
helm install kubeapps --namespace kubeapps bitnami/kubeapps

--debug --dry-run pr_name path_to_ch протестировать без установки чарта
helm inspect values 
name_chart > ...

Сохранение чарта в файл

helm inspect values stable/kube-ops-view > kube-ops-view.yaml
helm lint --strict path-to-chart

Проверить соответствие values схеме

helm fetch name_chart

Скачать чарт в tar 


--untar

И распаковать 

helm fetch bitnami/wordpress --untar
helm ls
--namespace namespace

список установленных чартов

helm upgrade ...

Обновление

helm rollback ch_name count

Откатить чарт ch_name на count назад 

helm rollback redis 1 --namespace=redis
helm uninstall name_ch


helm uninstall kubeapps --namespace kubeapps

Общая структура чарта

Helm автоматически определяет последовательность применения шаблонов в чарте. 

Директория/файл Описание Обяз.
Chart.yaml Метаданные чарта +
templates/

Ресурсы кубера в формате yaml helm (yaml с переменными)

Но файлы начинающиеся с _ не обрабатываются, _*.tpl обрабатываются как helper файлы.

+ если не составной
templates/NOTES.txt Инструкции по использованию -
values.yaml Переменные по умолчанию -
.helmignore Файлы исключения при упаковке чарта -
charts/ Зависимости (другие чарты) -, при отсутствии helm их сгенерирует в соответствии с Chart.yaml
Chart.lock Первично примененные зависимости. -, будет создан автоматически
crds/ Зависимости, которые должны быть собраны до основного чарта -
README.md Описание -
LICENSE Лицензия -
value.shema,json Шаблон в json формате -
files/ Дополнительные файлы

templates/

Измененные yaml. Добавлены переменные в формате Go шаблонизации. Переменные берутся из файла values.yaml 

apiVersion: v1
kind: ConfigMap
metadata: 
  name: {{ .Release.Name }}
data:
  configuration.txt: |-
    {{ .Values.configurationData }}

Родительские пространства имен у переменных:

Пространство имен Описание
.Release Переменные, связанные с релизом в устанавливаемой системе. .Release.Name - имя релиза  .Release.Namespace - пространство имен релиза .Release.Revision - номер версии
.Values Переменные, размещенные в файле values.yaml
.Chart Переменные, получаемые из файла Chart.yaml Например, .Chart.Name, .Chart.Version .Chart.AppVersion 
.Files

Работа с файлами в директории из директории files. Если файл не существует - вернется ошибка.

.Files.Get - Извлекает содержимое файлов

.Files.AsSecrets - Возвращает Base-64 закодированную строку для создания secret 

.Files.AsConfig - Возвращает данные для использования в виде ConfigMap

.Subcharts

Пространство имен дочерних чартов. Например .Subchart.MyChart.firstvalue

values.yaml

В виде обычного key: value yaml

Chart.yaml

Чарты бывают application и library. Application используются для деплоя приложений, library - для предоставления именованных шаблонов, используемых в других чартах. В library чартах не может быть ни одного шаблона, только helper файлы.

Обязательные поля: 

Поле Описание
apiVersion Версия. В helm 3 формате используется v2
name Имя чарта. Должно совпадать с именем директории чарта. В именах стоит использовать только -, например first-chart
version Версия. Формат X.Y.Z

Пример файла 

Команда Доп. пар. Описание
helm create chart_name   Создание шаблона чарта
helm install proj_name path
Создание проекта с названием proj_name используя чарт по пути path

-f par_file ссылка на другой файл параметров

--set foo=bar Ручная установка параметров
helm get manifest proj_name
Получить манифест проекта proj_name

Зависимости чарта

Заполняются в разделе dependencies файла Chart.yaml

Команда Доп. пар. Описание
helm dependency build путь до Chart.yaml Перестроить зависимые чарты, базируясь на файле Chart.lock Если этого файла нет - то же что и update
helm dependency list   Список зависимостей
helm dependency update   Обновление чартов и генерация Chart.lock

В зависимостях могут быть условия: 

dependencies:
  - name: dependency1
    repository: https://example.com
    version: 1.x.x
    condition: dependency1.enabled
    tags:
      - monitoring: true
  - name: dependency2
    repository: https://example.com
    version: 2.x.x
    condition: dependency2.enabled
    tags:
      - monitoring: true

В данном случае переменные dependency1.enabled и dependency2.enabled должны быть установлены в values.yaml файле. Можно несколько переменных через запятую, но лучше завести одну общую переменную и в values ее заполнять. Раздел tags разделяет по группам: если в родительском чарте переменная monitoring не выставлена - данные зависимости установлены не будут. Может быть несколько тэгов, но если хотя бы один подходит - будет добавлено.

Дочерние параметры чарта могут быть переопределены.

Можно импортировать параметры из дочернего чарта (если его параметры отмечены как экспортируемые).

Также есть хуки, позволяющие выполнять что-то при достижении определенной стадии.

Helm

Go templates

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

Конструкция {{- удаляет строку в которой функция.

Условия: 

{{ if ConditionOne }}
# Do something
{{ else if ConditionTwo }}
# Do something else
{{ else }}
# Default case
{{ end }}
{{ if eq .Values.favorite.drink "coffee" }}mug: "true"{{ end }}

With

Работает так же как и в python 

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  {{- with .Values.favorite }}
  drink: {{ .drink | default "tea" | quote }}
  food: {{ .food | upper | quote }}
  {{- end }}

Циклы

values.yaml: 

favorite:
  drink: coffee
  food: pizza
pizzaToppings:
  - mushrooms
  - cheese
  - peppers
  - onions
  - pineapple

cur.yaml: 

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"
  {{- with .Values.favorite }}
  drink: {{ .drink | default "tea" | quote }}
  food: {{ .food | upper | quote }}
  {{- end }}
  toppings: |-
    {{- range .Values.pizzaToppings }}
    - {{ . | title | quote }}
    {{- end }}  

Функции:

Можно использовать pipeline: {{ .Values.favorite.drink | quote }}

Функция Описание
quote Добавляет кавычки 
{{ quote .Values.favorite.food }}

upper В верхний регистр
repeat n

Повтор значения n раз 

{{ .Values.favorite.drink | repeat 5 | quote }}

default "some_hy"

Присвоить значение по умолчанию если отсутствует 

drink: {{ .Values.favorite.drink | default "tea" | quote }}
eq, ne, lt, gt, and, or

Логические функции

indent n

Поставить n пробелов перед конструкцией

Список функций

Именованные шаблоны

С шаблонами нужно запускать 

helm install --dry-run --disable-openapi-validation

Шаблон внутри _helpers.tpl файла:

{{- define "first.labels" -}}
labels:
  'app.kubernetes.io/instacce': {{ .Release.Name }}
  'app.kubernetes.io/managed-by': {{ .Release.Service }}
{{- end }}

{{- define "first.nameofchart" -}}
{{- printf "mycurname" -}}
{{ - end }}
apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "first.nameofchart" . }}
{{- include "first.labels" . | nindent 2 }}
data:
  myvalue: "Hello World"
  food: {{ .Values.favourite.food }}
  drink: {{ .Values.favourite.drink }}

Точка означает передачу внутрь шаблона всех переменных.

Разница между include и template: проще использовать include, template не дает использовать дополнительные функции через pipeline

Helm

Пример проекта

Задача: helm чарт приложения guestbook с БД redis

Создаем namespace для теста 

kubectl create namespace guestbook-learn

Создаем шаблон структуры папок 

helm create guestbook

Добавляем зеркало проекта bitnami и находим последнюю версию чарта

helm repo add bitnami https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami
helm search repo redis --versions
NAME                    CHART VERSION   APP VERSION     DESCRIPTION
bitnami/redis           20.11.4         7.4.2           Redis(R) is an open source, advanced key-value ...
bitnami/redis           20.11.3         7.4.2           Redis(R) is an open source, advanced key-value ...
bitnami/redis           20.11.2         7.4.2           Redis(R) is an open source, advanced key-value ...

 В моем случае это 20.11.4. Добавляем зависимость в Chart.yaml 

dependencies:
  - name: redis
    version: 20.11.x
    repository: https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami

Попробуем загрузить зависимость 

guestbook# helm dependency update .
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "bitnami" chart repository
Update Complete. ⎈Happy Helming!⎈
Saving 1 charts
Downloading redis from repo https://raw.githubusercontent.com/bitnami/charts/archive-full-index/bitnami
Pulled: registry-1.docker.io/bitnamicharts/redis:20.11.4
Digest: sha256:51ee4afc621d0e0b26109d41c32bf23f3db114f15dd816c1acf8d1ddbf8d57ed
Deleting outdated charts

Действительно, в папке charts появился архив 

guestbook# ls charts/
redis-20.11.4.tgz

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

helm show values charts/redis-20.11.4.tgz

Это выдало портянку (если убрать комментарии) в 698 строк. Был задан вопрос ИИ. Ответ отличался от приведенного варианта в книге и прямое использование не поехало бы. В values.yaml было добавлено