Как развернуть приложение?

Сервисы и физическое железо

Обычно физический сервер слишком большой для одного экземпляра сервиса.

Есть потребность запускать несколько разных сервисов на одном физичесом сервере.

Несколько сервисов на одном сервере

Технически можно установить несколько сервисов на одном сервере.

• Общая операционная система, которую очень больно обновлять
• Проблема изоляции ресурсов
• Проблема общих зависимостей
• Проблема воспроизводимости окружения

Какие пути решения?

Виртуализация

Внутри гипервизора запускаем несколько виртуальных хостов.

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

Контейнеризация

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

Каждый процесс контейнера является обычным процессом операционной системы.

Виртуализация

Важно

• Диск - блочный файл/устройство

Плюсы

• Можно запустить другую операционную систему (к примеру Windows, Linux или FreeBSD)
• Высокая степень изоляции
• Можно эмулировать другую архитектуру (к примеру PlayStation 2)

Минусы

• Высокие накладные расходы

Контейнеризация

Важно

• Диск - каталог на хостовой машине

Плюсы

• Минимальные накладные расходы

Минусы

• Общее ядро операционной системы
• Более слабая изоляция ресурсов (например: общий дисковый кэш)

Docker

Контейнеры существуют очень давно, но до Docker-а не было простой инфраструктуры для работы с контейнерами.

Docker предоставил законченное решение для:

• Сборки контейнеров
• Обмена и переиспользования контейнеров
• Запуска контейнеров

Docker-контейнеры поддерживают операционные системы:

• Linux
• Windows

Docker-образ

git clone https://github.com/docker/docker-gs-ping .
docker build --tag docker-gs-ping .

Dockerfile

# syntax=docker/dockerfile:1
FROM golang:1.19
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY *.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping
EXPOSE 8080
CMD [ "/docker-gs-ping" ]

Docker-образ (multistage)

git clone https://github.com/docker/docker-gs-ping .
docker build --tag docker-gs-ping -f Dockerfile.multistage .

Dockerfile.multistage

# syntax=docker/dockerfile:1
FROM golang:1.19 AS build-stage
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY *.go ./
RUN CGO_ENABLED=0 GOOS=linux go build -o /docker-gs-ping

FROM gcr.io/distroless/base-debian11 AS build-release-stage
WORKDIR /
COPY --from=build-stage /docker-gs-ping /docker-gs-ping
EXPOSE 8080
USER nonroot:nonroot
ENTRYPOINT ["/docker-gs-ping"]

Кэширование сборки docker-образов

Не правильно

RUN apt update
RUN apt install -y golang

RUN apt update && apt install -y golang

RUN --mount=type=cache,sharing=private,target=/var/cache/apt \
    --mount=type=tmpfs,target=/tmp \
    apt update && apt install -y golang && apt-get clean all

Что внутри образа?

Подведём итоги

• OCI Image — вырос из Docker Image и является его развитием
• Сборки порождают слои, каждый из которых используется только для чтения (overlayfs)
• OCI Image содержит метаданные: переменные окружения, команда выполнения, порты и т.п., которые используются как значения по-умолчанию при запуске контейнера
• В контейнер можно передавать конфигурацию через модификацию переменных окружения и монтирования каталогов/файлов при его запуске

Шпаргалки по Docker

https://docker.how/

https://docs.docker.com/get-started/docker_cheatsheet.pdf

Kubernetes (K8S) — среда для контейнеров

Как запустить контейнер в Kubernetes?

Описание Pod-а pods/simple-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Создание Pod-а

kubectl apply -f https://k8s.io/examples/pods/simple-pod.yaml

Как запустить контейнер в Kubernetes?

kubectl get pods
kubectl describe pod nginx
kubectl logs nginx
kubectl delete pod nginx

Открытые вопросы

• Какой контейнер будет использоваться для Pod-а и откуда он берётся?
• Где именно будет запущен Pod?
• Какие Pod-у будут выделены ресурсы?
• Как достучаться до Pod-а?
• Что произойдёт если удалить хост с Pod-ом?
• Как передать конфигурацию в Pod?

Ресурсы в Kubernetes

Запуск приложения

Pod

Минимальный объект в Kubernetes.

ReplicaSet

Управляет количеством однотипных Pod-ов.

Deployment, StatefulSet, DaemonSet

Объекты, которые управляют жизненным циклом контейнерных приложений.

Ресурсы в Kubernetes

Конфигурация приложения

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

У Pod-а можно переопределить переменные окружения. Так же через них можно прокинуть часть данных о Pod-е в контейнер (https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/).

Параметры командной строки

Можно переопределить параметры командной строки для Pod-а.

Secret, ConfigMap

Специальные ресурсы, которые можно отобразить на файловую систему Pod-а.

Ресурсы в Kubernetes

Ресурсы для доступа к Pod-у

Service

Объект, который позволяет адресовать группу Pod-ов.

Ingress

Объект, который позволяет достучаться к Pod-у снаружи Kubernetes-кластера.

Запуск Pod-ов через Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

Указываем, какие ресурсы нужны Pod-ам

Контроль жизненного цикла

Для определения состояния Pod-а есть следующие "пробы":

readinessProbe

Готов ли Pod принимать пользовательскую нагрузку?

livenessProbe

Жив ли Pod?
Если Pod не живой, то его удалит автоматика

startupProbe

До завершения старта сервиса к нему не применяются readinessProbe и livenessProbe

Долго стартующие приложения причиняют боль страдание.

Контроль жизненного цикла

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
    readinessProbe:
      httpGet:
        path: /
        port: 80
      periodSeconds: 3

Конфигурация внутри Pod-а

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    command: ["nginx", "-g", "daemon off;"]
    env:
    - name: FOO
      value: "bar"
    - name: MY_POD_NAME
      valueFrom:
        fieldRef:
          fieldPath: metadata.name
    ports:
    - containerPort: 80

Конфигурация снаружи Pod-а

apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx
data:
  index.html: |
    <html><body><h1>Hello, world!!!</h1></body></html>
  ping.html: |
    <html><body><h1>Pong</h1></body></html>

Доступ к Pod-у снаружи Kubernetes-кластера

Подведём итоги

• Ресурсами управляет Deployment
• Конфигурацию можно задать через ConfigMap и переменные окружения
• Обязательно надо прописывать requests для Pod-а
• Обязательно надо прописывать livenessProbe, readinessProbe и startupProbe
• Для адресации между Pod-ами используются Service
• Для адресации снаружи Kubernetes-кластера используются Ingress

Что осталось за кадром?

• Pod nodeAffinity
• Pod topologySpreadConstraints
• HorizontalPodAutoscaler
• PodDisruptionBudget
• Состояние в Kubernetes: StatefulSet, Persistent Volume.

Шпаргалки по Kubernetes

Откуда берутся ресурсы для Kubernetes?

При раскатки приложения ресурсы для Kubernetes обычно генерируются каким-либо образом.

Применение ресурсов через kubectl apply имеет существенный недостаток: никто не удаляет более ненужные ресурсы.

Стандартом де-факто для создания "приложений" в Kubernetes является Helm

Helm

Helm — менеджер пакетов для Kubernetes, который упрощает установку, обновление и управление приложениями в кластере. Особенность — использование чартов (Helm Charts) — стандартизированных пакетов, в которых содержатся все необходимые ресурсы и конфигурации.

Шаблонизатор Helm

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"

Внутри Helm использует шаблонизатор Go Template с набором дополнительных функций (в том числе go-spew).

Одна из проблем такого подхода: шаблонизатор работает с Yaml на уровне текста.

Как всё выкатить?

• Разработчик заливает изменения в main-ветку Git-а
• На CI собирается Docker-образ с приложением
• На CI публикуется Helm-чарт для приложения
• CI устанавливает helm-чарт в Kubernetes-кластер

Подготовка Docker Registry

Подготовка Kubernetes-кластера

Настройка CI

Настройка CI

Сбор метрик с Pod-ов

Спасибо за внимание!