Обеспечение конфиденциальности данных и кода в образах контейнеров

Вводные

Смежные работы по шифрованию и контейнерам

Структура

OpenPGP

JSON Web Encryption (JWE)

PKCS#7

• Сообщения OpenPGP, JWE и PKCS#7 хранятся в карте аннотаций, которая является частью манифеста.
• В каждом указанном слое содержится по одной карте. Карта аннотаций в основном представляет собой словарь со строками в качестве ключей и строками в качестве значений (пары ключ-значение).

• org.opencontainers.image.enc.keys.openpgp
• org.opencontainers.image.enc.keys.jwe
• org.opencontainers.image.enc.keys.pkcs7

• application/vnd.docker.image.rootfs.diff.tar+encrypted
• application/vnd.docker.image.rootfs.diff.tar.gzip+encrypted

Многослойное шифрование с использованием симметричных ключей

Пример реализации: containerd

Пошаговое руководство шифрования с использованием containerd

# make# sudo make install

# cat config.tomldisable_plugins = ["cri"]root = "/tmp/var/lib/containerd"state = "/tmp/run/containerd"[grpc]  address = "/tmp/run/containerd/containerd.sock"  uid = 0  gid = 0[stream_processors]    [stream_processors."io.containerd.ocicrypt.decoder.v1.tar.gzip"]        accepts = ["application/vnd.oci.image.layer.v1.tar+gzip+encrypted"]        returns = "application/vnd.oci.image.layer.v1.tar+gzip"        path = "/usr/local/bin/ctd-decoder"    [stream_processors."io.containerd.ocicrypt.decoder.v1.tar"]        accepts = ["application/vnd.oci.image.layer.v1.tar+encrypted"]        returns = "application/vnd.oci.image.layer.v1.tar"        path = "/usr/local/bin/ctd-decoder"# sudo ~/src/github.com/containerd/containerd/bin/containerd -c config.toml

# openssl genrsa --out mykey.pemGenerating RSA private key, 2048 bit long modulus (2 primes)...............................................+++++............................+++++e is 65537 (0x010001)# openssl rsa -in mykey.pem -pubout -out mypubkey.pemwriting RSA key# sudo chmod 0666 /tmp/run/containerd/containerd.sock# CTR="/usr/local/bin/ctr-enc -a /tmp/run/containerd/containerd.sock"# $CTR images pull --all-platforms docker.io/library/bash:latest[...]# $CTR images layerinfo --platform linux/amd64 docker.io/library/bash:latest   #                                                                    DIGEST      PLATFORM      SIZE   ENCRYPTION   RECIPIENTS   0   sha256:9d48c3bd43c520dc2784e868a780e976b207cbf493eaff8c6596eb871cbd9609   linux/amd64   2789669                             1   sha256:7dd01fd971d4ec7058c5636a505327b24e5fc8bd7f62816a9d518472bd9b15c0   linux/amd64   3174665                             2   sha256:691cfbca522787898c8b37f063dd20e5524e7d103e1a3b298bd2e2b8da54faf5   linux/amd64       340                          # $CTR images encrypt --recipient jwe:mypubkey.pem --platform linux/amd64 docker.io/library/bash:latest bash.enc:latestEncrypting docker.io/library/bash:latest to bash.enc:latest$ $CTR images layerinfo --platform linux/amd64 bash.enc:latest   #                                                                    DIGEST      PLATFORM      SIZE   ENCRYPTION   RECIPIENTS   0   sha256:360be141b01f69b25427a9085b36ba8ad7d7a335449013fa6b32c1ecb894ab5b   linux/amd64   2789669          jwe        [jwe]   1   sha256:ac601e66cdd275ee0e10afead03a2722e153a60982122d2d369880ea54fe82f8   linux/amd64   3174665          jwe        [jwe]   2   sha256:41e47064fd00424e328915ad2f7f716bd86ea2d0d8315edaf33ecaa6a2464530   linux/amd64       340          jwe        [jwe]

# docker pull registry:latest# docker run -d -p 5000:5000 --restart=always --name registry registry

# $CTR images tag bash.enc:latest localhost:5000/bash.enc:latest# $CTR images push localhost:5000/bash.enc:latest# $CTR images rm localhost:5000/bash.enc:latest bash.enc:latest# $CTR images pull localhost:5000/bash.enc:latest# sudo $CTR run --rm localhost:5000/bash.enc:latest test echo 'Hello World!'ctr: you are not authorized to use this image: missing private key needed for decryption# sudo $CTR run --rm --key mykey.pem localhost:5000/bash.enc:latest test echo 'Hello World!'Hello World!

Заключение

Утилиты проверки безопасности

Варианты внедрения утилит

1. Проверка корректности и безопасности инструкций Dockerfile утилитой линтером Hadolint
2. Проверка корректности и безопасности конечного и промежуточных образов утилитой Dockle
3. Проверка наличия общеизвестных уязвимостей (CVE) в базовом образе и ряде зависимостей утилитой Trivy

Интеграция в GitLab CI/CD

sudo apt-get update && sudo apt-get install docker.io

sudo addgroup <username> docker

ip addr

docker run --detach \--hostname 192.168.1.112 \--publish 443:443 --publish 80:80 \--name gitlab \--restart always \--volume /srv/gitlab/config:/etc/gitlab \--volume /srv/gitlab/logs:/var/log/gitlab \--volume /srv/gitlab/data:/var/opt/gitlab \gitlab/gitlab-ce:latest

sudo curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64

sudo chmod +x /usr/local/bin/gitlab-runner

sudo useradd --comment 'GitLab Runner' --create-home gitlab-runner --shell /bin/bashsudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runnersudo gitlab-runner start

local@osboxes:~$ sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runnerRuntime platform arch=amd64 os=linux pid=8438 revision=0e5417a3 version=12.0.1local@osboxes:~$ sudo gitlab-runner startRuntime platform arch=amd64 os=linux pid=8518 revision=0e5417a3 version=12.0.1

sudo gitlab-runner register \--non-interactive \--url "http://<URL>/" \--registration-token "<Registration Token>" \--executor "docker" \--docker-privileged \--docker-image alpine:latest \--description "docker-runner" \--tag-list "docker,privileged" \--run-untagged="true" \--locked="false" \--access-level="not_protected"

FROM amd64/node:10.16.0-alpine@sha256:f59303fb3248e5d992586c76cc83e1d3700f641cbcd7c0067bc7ad5bb2e5b489 AS tsbuildCOPY package.json .COPY yarn.lock .RUN yarn installCOPY lib libCOPY tsconfig.json tsconfig.jsonCOPY tsconfig.app.json tsconfig.app.jsonRUN yarn buildFROM amd64/ubuntu:18.04@sha256:eb70667a801686f914408558660da753cde27192cd036148e58258819b927395LABEL maintainer="Rhys Arkins <rhys@arkins.net>"LABEL name="renovate"...COPY php.ini /usr/local/etc/php/php.iniRUN cp -a /tmp/piik/* /var/www/html/RUN rm -rf /tmp/piwikRUN chown -R www-data /var/www/htmlADD piwik-cli-setup /piwik-cli-setupADD reset.php /var/www/html/## ENTRYPOINT ##ADD entrypoint.sh /entrypoint.shENTRYPOINT ["/entrypoint.sh"]USER root

variables:    DOCKER_HOST: "tcp://docker:2375/"    DOCKERFILE: "mydockerfile.df" # name of the Dockerfile to analyse       DOCKERIMAGE: "bkimminich/juice-shop" # name of the Docker image to analyse    # DOCKERIMAGE: "knqyf263/cve-2018-11235" # test Docker image with several CRITICAL CVE    SHOWSTOPPER_PRIORITY: "CRITICAL" # what level of criticality will fail Trivy job    TRIVYCACHE: "$CI_PROJECT_DIR/.cache" # where to cache Trivy database of vulnerabilities for faster reuse    ARTIFACT_FOLDER: "$CI_PROJECT_DIR" services:    - docker:dind # to be able to build docker images inside the Runner stages:    - scan    - report    - publish HadoLint:    # Basic lint analysis of Dockerfile instructions    stage: scan    image: docker:git     after_script:    - cat $ARTIFACT_FOLDER/hadolint_results.json     script:    - export VERSION=$(wget -q -O - https://api.github.com/repos/hadolint/hadolint/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')    - wget https://github.com/hadolint/hadolint/releases/download/v${VERSION}/hadolint-Linux-x86_64 && chmod +x hadolint-Linux-x86_64         # NB: hadolint will always exit with 0 exit code    - ./hadolint-Linux-x86_64 -f json $DOCKERFILE > $ARTIFACT_FOLDER/hadolint_results.json || exit 0     artifacts:        when: always # return artifacts even after job failure               paths:        - $ARTIFACT_FOLDER/hadolint_results.json Dockle:    # Analysing best practices about docker image (users permissions, instructions followed when image was built, etc.)    stage: scan       image: docker:git     after_script:    - cat $ARTIFACT_FOLDER/dockle_results.json     script:    - export VERSION=$(wget -q -O - https://api.github.com/repos/goodwithtech/dockle/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')    - wget https://github.com/goodwithtech/dockle/releases/download/v${VERSION}/dockle_${VERSION}_Linux-64bit.tar.gz && tar zxf dockle_${VERSION}_Linux-64bit.tar.gz    - ./dockle --exit-code 1 -f json --output $ARTIFACT_FOLDER/dockle_results.json $DOCKERIMAGE            artifacts:        when: always # return artifacts even after job failure               paths:        - $ARTIFACT_FOLDER/dockle_results.json Trivy:    # Analysing docker image and package dependencies against several CVE bases    stage: scan       image: docker:git     script:    # getting the latest Trivy    - apk add rpm    - export VERSION=$(wget -q -O - https://api.github.com/repos/knqyf263/trivy/releases/latest | grep '"tag_name":' | sed -E 's/.*"v([^"]+)".*/\1/')    - wget https://github.com/knqyf263/trivy/releases/download/v${VERSION}/trivy_${VERSION}_Linux-64bit.tar.gz && tar zxf trivy_${VERSION}_Linux-64bit.tar.gz         # displaying all vulnerabilities w/o failing the build    - ./trivy -d --cache-dir $TRIVYCACHE -f json -o $ARTIFACT_FOLDER/trivy_results.json --exit-code 0 $DOCKERIMAGE            # write vulnerabilities info to stdout in human readable format (reading pure json is not fun, eh?). You can remove this if you don't need this.    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 0 $DOCKERIMAGE         # failing the build if the SHOWSTOPPER priority is found    - ./trivy -d --cache-dir $TRIVYCACHE --exit-code 1 --severity $SHOWSTOPPER_PRIORITY --quiet $DOCKERIMAGE             artifacts:        when: always # return artifacts even after job failure        paths:        - $ARTIFACT_FOLDER/trivy_results.json     cache:        paths:        - .cache Report:    # combining tools outputs into one HTML    stage: report    when: always    image: python:3.5         script:    - mkdir json    - cp $ARTIFACT_FOLDER/*.json ./json/    - pip install json2html    - wget https://raw.githubusercontent.com/shad0wrunner/docker_cicd/master/convert_json_results.py    - python ./convert_json_results.py         artifacts:        paths:        - results.html

NB: Trivy требует для своего запуска установленные rpm и git. В противном случае он будет выдавать ошибки при сканировании RedHat-based образов и получении обновлений базы уязвимостей.

Shell-скрипт

~/docker_cicd$ ./docker_sec_check.sh[+] Setting environment variables[+] Installing required packages[+] Preparing necessary directories[+] Fetching sample Dockerfile2020-10-20 10:40:00 (45.3 MB/s) - Dockerfile saved [8071/8071][+] Pulling image to scanlatest: Pulling from bkimminich/juice-shop[+] Running Hadolint...Dockerfile:205 DL3015 Avoid additional packages by specifying `--no-install-recommends`Dockerfile:248 DL3002 Last USER should not be root...[+] Running Dockle...WARN    - DKL-DI-0006: Avoid latest tag        * Avoid 'latest' tagINFO    - CIS-DI-0005: Enable Content trust for Docker        * export DOCKER_CONTENT_TRUST=1 before docker pull/build...[+] Running Trivyjuice-shop/frontend/package-lock.json=====================================Total: 3 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 2, CRITICAL: 0)+---------------------+------------------+----------+---------+-------------------------+|       LIBRARY       | VULNERABILITY ID | SEVERITY | VERSION |             TITLE       |+---------------------+------------------+----------+---------+-------------------------+| object-path         | CVE-2020-15256   | HIGH     | 0.11.4  | Prototype pollution in  ||                     |                  |          |         | object-path             |+---------------------+------------------+          +---------+-------------------------+| tree-kill           | CVE-2019-15599   |          | 1.2.2   | Code Injection          |+---------------------+------------------+----------+---------+-------------------------+| webpack-subresource | CVE-2020-15262   | LOW      | 1.4.1   | Unprotected dynamically ||                     |                  |          |         | loaded chunks           |+---------------------+------------------+----------+---------+-------------------------+juice-shop/package-lock.json============================Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)...juice-shop/package-lock.json============================Total: 5 (CRITICAL: 5)...[+] Removing left-overs[+] Making the output look pretty[+] Converting JSON results[+] Writing results HTML[+] Clean exit ============================================================[+] Everything is done. Find the resulting HTML report in results.html

Docker-образ со всеми утилитами

docker build -t dscan:image -f docker_security.df .

docker run --rm -v $(pwd)/results:/results -v $(pwd)/docker_security.df:/Dockerfile -e DOCKERIMAGE="bkimminich/juice-shop" dscan:image

[+] Setting environment variables[+] Running Hadolint/Dockerfile:3 DL3006 Always tag the version of an image explicitly[+] Running DockleWARN    - DKL-DI-0006: Avoid latest tag        * Avoid 'latest' tagINFO    - CIS-DI-0005: Enable Content trust for Docker        * export DOCKER_CONTENT_TRUST=1 before docker pull/buildINFO    - CIS-DI-0006: Add HEALTHCHECK instruction to the container image        * not found HEALTHCHECK statementINFO    - DKL-LI-0003: Only put necessary files        * unnecessary file : juice-shop/node_modules/sqlite3/Dockerfile        * unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm64/Dockerfile        * unnecessary file : juice-shop/node_modules/sqlite3/tools/docker/architecture/linux-arm/Dockerfile[+] Running Trivy...juice-shop/package-lock.json============================Total: 20 (UNKNOWN: 0, LOW: 1, MEDIUM: 6, HIGH: 8, CRITICAL: 5)...[+] Making the output look pretty[+] Starting the main module ============================================================[+] Converting JSON results[+] Writing results HTML[+] Clean exit ============================================================[+] Everything is done. Find the resulting HTML report in results.html

Результаты

Кратко об Intel SGX и его роли в облаке

Наш подход к внедрению Intel SGX

• Включить поддержку Intel SGX на уровне BIOS.
• Поставить патченные QEMU/KVM.

• Проверили секцию /dev/sgx/virt_epc в файле /proc/$PID/smaps:
  
  

  [root@compute-sgx ~]# grep -A22 epc /proc/$PID/smaps7f797affe000-7f797b7fe000 rw-s 00000000 00:97 57466526/dev/sgx/virt_epcSize:               8192 kBKernelPageSize:        4 kBMMUPageSize:           4 kBRss:                   0 kBPss:                   0 kBShared_Clean:          0 kBShared_Dirty:          0 kBPrivate_Clean:         0 kBPrivate_Dirty:         0 kBReferenced:            0 kBAnonymous:             0 kBLazyFree:              0 kBAnonHugePages:         0 kBShmemPmdMapped:        0 kBFilePmdMapped:         0 kBShared_Hugetlb:        0 kBPrivate_Hugetlb:       0 kBSwap:                  0 kBSwapPss:               0 kBLocked:                0 kBTHPeligible:0VmFlags: rd wr sh mr mw me ms pf io dc dd hg
  

• И воспользовались данным shell-скриптом, предварительно поставив SGX-драйвер (все действия осуществлялись внутри ВМ):
  
  

  [root@sgx-vm ~]# cat check_sgx.sh#!/bin/bashMETRICS="sgx_nr_total_epc_pages \    sgx_nr_free_pages \    sgx_nr_low_pages \    sgx_nr_high_pages \    sgx_nr_marked_old \    sgx_nr_evicted \    sgx_nr_alloc_pages \    "MODPATH="/sys/module/isgx/parameters/"for metric in $METRICS ; do    echo "$metric= `cat $MODPATH/$metric`"done[root@sgx-vm ~]# curl -fsSL https://raw.githubusercontent.com/scontain/SH/master/install_sgx_driver.sh | bash -s - install -p metrics -p page0[root@sgx-vm ~]# ./check_sgx.shsgx_nr_total_epc_pages= 2048sgx_nr_free_pages= 2048sgx_nr_low_pages= 32sgx_nr_high_pages= 64sgx_nr_marked_old= 0sgx_nr_evicted= 0sgx_nr_alloc_pages= 0
  

  
  Стоит учитывать, что, если одна страница занимает 4 КиБ, то для 2048 страниц требуется 8 МиБ (2048 x 4 = 8192).

Трудности разработки и их преодоление

1. Добиться от сервиса OpenStack Nova генерации XML-файла с дополнительными параметрами для виртуальных машин с поддержкой Intel SGX.
2. Написать фильтр планировщика OpenStack Nova с целью определения доступной памяти для анклавов на вычислительных узлах и осуществления некоторых других проверок.

# openstack usage showUsage from 2020-11-04 to 2020-12-03 on project a968da75bcab4943a7beb4009b8ccb4a:+---------------+--------------+| Field         | Value        |+---------------+--------------+| CPU Hours     | 47157.6      || Disk GB-Hours | 251328.19    || EPC MB-Hours  | 26880.02     || RAM MB-Hours  | 117222622.62 || Servers       | 23           |+---------------+--------------+

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

Кейс Aggregion

Выводы

Что такое контейнер

Что представляет собой Kubernetes?

Ключевые функции Kubernetes

1. Поддержание среды с заданными параметрами для разработки, тестирования и внедрения
2. Предсказуемая и автоматически масштабируемая (горизонтально) инфраструктура
3. Самовосстанавливающаяся (с возможностью отмены) среда с балансировкой нагрузки
4. Широкие возможности для установки приложений
5. Инструменты управления на уровне приложений

Что представляет собой Docker?

Ключевые функции Docker

1. Совместное использование образов среды с помощью Docker Build
2. Docker Assemble для распознавания языка программирования и речи при создании контейнеров
3. Нативные и облачные инструменты для оптимизации производительности разработчиков
4. Инструменты CI/CD для команд, работающих над развивающимися приложениями с системой контроля версий
5. Высокая отказоустойчивость с надежной поддержкой больших кластеров

Docker или Kubernetes. Нужно ли выбирать между ними?

Плюсы и минусы Docker: контейнеризация

Плюсы:

• Легкость создания. Инициализация контейнеров в Docker выполняется быстро и требует минимальных технических навыков.
• Инструменты Docker. Управлять контейнерами легко благодаря полному набору стартовых инструментов
• Эффективная поддержка. У Docker есть активное сообщество разработчиков, которые предоставляют техническую поддержку и помогают устранить любые проблемы, с которыми вы можете столкнуться.

Минусы:

• Отсутствие хранилища. При каждой перезагрузке контейнер теряет ранее созданные вами данные. Сохранение не настроено по умолчанию, и для начинающих разработчиков это может создавать сложности.
• Низкая скорость. Контейнеры Docker никогда не достигнут уровня производительности выделенных серверов из-за сетевого уровня, на котором они теряют скорость. Нечто неслыханное при использовании инфраструктуры выделенных серверов для хостинга приложений.
• Отсутствие кроссплатформенной поддержки. Изолированный характер контейнеров Docker делает невозможным установку приложений в средах, отличных от среды, в которой они были разработаны.

Плюсы и минусы Kubernetes: оркестровка контейнеров

Плюсы:

• Модули pod (поды). К8 поддерживает поды (контейнеры и инструменты контейнеризации) для сохранения с автовосстановлением (воссозданием) в случае неожиданного сбоя.
• Разработка Google. Kubernetes вселяет уверенность (не всем, конечно) в своем качестве за счет известности разработчика и растущего (самого большого) сообщества.
• Наличие хранилища по умолчанию. Для удобства разработчиков K8 поставляется с облачными хранилищами и хранилищами SAN.

Минусы:

• Сложная установка. Требует значительных технических усилий, а для правильной установки и настройки нужно много времени.
• Overkill простым приложениям не нужна сложность Kubernetes. Но кто из ваших разработчиков признается, что ваше приложение простое?
• Технические возможности К8 обходятся недешево. Услуги разработчиков DevOps, способных создавать и поддерживать инструменты Kubernetes, стоят дорого.

Примеры использования Docker и Kubernetes

Когда нужно использовать Kubernetes

• Почти идеальное время безотказной работы. Функция самовосстановления Kubernetes позволяет ресурсоемким приложениям продолжать работу независимо от количества сбоев в системе.
• При выборе между различными поставщиками услуг контейнеризации. Так как К8 сотрудничает (на разных уровнях сложности) почти со всеми поставщиками, использование К8 в качестве системы оркестровки дарит свободу выбора. Ни один поставщик не может претендовать на контракт с вашей компанией, если вы не будете довольны качеством услуг после пробного периода.
• Если вы не уверены в потенциале роста. Во время горизонтального масштабирования К8 автоматически распределяет ресурсы по приложениям.

Когда нужно использовать Docker

• Если К8 не подходит. Недостаточные технические возможности, несовместимость с API и высокая стоимость услуг могут привести к необходимости использования Docker и его инструментов. Платформа оркестровки Docker Swarm может полностью заменить К8.
• Когда вы только начинаете развитие приложения. Вам не нужно использовать Docker совместно с какой-либо другой системой оркестровки, когда приложения еще находятся в стадии роста. На данных этапах скорость важнее устойчивости.
• При создании приложений CLI. При разработке Docker была предусмотрена его интеграция с приложениями CLI, благодаря эффективности которых повышается производительность.

Когда необходимо совместное использование

Инфраструктура как YAML

apiVersion: v1kind: Podmetadata:  name: site  labels:    app: webspec:  containers:    - name: front-end      image: nginx      ports:        - containerPort: 80

• GitOps или контроль версий Git Operations Version. Такой подход позволяет держать все YAML-файлы Kubernetes в репозиториях git, благодаря чему вы в точности можете отследить, когда было внесено изменение, кто его внес, и что именно изменилось. Благодаря этому повышается прозрачность операций в пределах всей организации, повышается эффективность работы в силу устранения неоднозначности, в частности, в том, где сотрудники должны искать нужные им ресурсы. В то же время, становится проще автоматически вносить изменения в ресурсы Kubernetes путем обычного слияния pull-запроса.
• Масштабируемость. Когда ресурсы определены в виде YAML, операторам кластера становится чрезвычайно просто изменить одно или два числа в ресурсе Kubernetes, изменив тем самым принципы его масштабирования. В Kubernetes предусмотрен механизм для горизонтального автомасштабирования подов, при помощи которого удобно определять, каково минимальное и максимальное количество подов, которое требуется в конкретной развернутой конфигурацией, чтобы справляться с низким и высоким уровнем трафика. Например, если вы развернули конфигурацию, для которой требуются дополнительные мощности из-за резкого всплеска трафика, то показатель maxReplicas можно изменить с 10 на 20:

apiVersion: autoscaling/v2beta2kind: HorizontalPodAutoscalermetadata:  name: myapp  namespace: defaultspec:  scaleTargetRef:    apiVersion: apps/v1    kind: Deployment    name: myapp-deployment  minReplicas: 1  maxReplicas: 20  metrics:  - type: Resource    resource:      name: cpu      target:        type: Utilization        averageUtilization: 50

• Безопасность и управление. YAML отлично подходит для оценки того, как те или иные вещи развертываются в Kubernetes. Например, серьезная проблема, связанная с обеспечением безопасности, касается того, запускаются ли ваши рабочие нагрузки из-под пользователя, не обладающего правами администратора. В данном случае нам могут пригодиться такие инструменты как conftest, валидатор YAML/JSON, плюс Open Policy Agent, валидатор политик, позволяющий убедиться, что контекст SecurityContext ваших рабочих нагрузок не позволяет контейнеру работать с привилегиями администратора. Если требуется это обеспечить, пользователи могут применить простую политику rego, вот так:

package maindeny[msg] {  input.kind = "Deployment"  not input.spec.template.spec.securityContext.runAsNonRoot = true  msg = "Containers must not run as root"}

• Варианты интеграции с облачным провайдером. Одна из наиболее заметных тенденций в современных высоких технологиях запускать рабочие нагрузки на мощностях общедоступных облачных провайдеров. При помощи компонента cloud-provider Kubernetes позволяет любому кластеру интегрироваться с тем облачным провайдером, на котором он работает. Например, если пользователь запустил приложение в Kubernetes на AWS и хочет открыть доступ к этому приложению через сервис, облачный провайдер помогает автоматически создать сервис LoadBalancer, который автоматически предоставит балансировщик нагрузки Amazon Elastic Load Balancer, чтобы перенаправить трафик в поды приложений.

Расширяемость

apiVersion: apiextensions.k8s.io/v1kind: CustomResourceDefinitionmetadata:  name: crontabs.my.orgspec:  group: my.org  versions:    - name: v1      served: true      storage: true      Schema:        openAPIV3Schema:          type: object          properties:            spec:              type: object              properties:                cronSpec:                  type: string                  pattern: '^(\d+|\*)(/\d+)?(\s+(\d+|\*)(/\d+)?){4}$'                replicas:                  type: integer                  minimum: 1                  maximum: 10  scope: Namespaced  names:    plural: crontabs    singular: crontab    kind: CronTab    shortNames:    - ct

apiVersion: "my.org/v1"kind: CronTabmetadata:  name: my-cron-objectspec:  cronSpec: "* * * * */5"  image: my-cron-image  replicas: 5

$ operator-sdk new my-operator --repo github.com/myuser/my-operator

.|____cmd| |____manager| | |____main.go|____go.mod|____deploy| |____role.yaml| |____role_binding.yaml| |____service_account.yaml| |____operator.yaml|____tools.go|____go.sum|____.gitignore|____version| |____version.go|____build| |____bin| | |____user_setup| | |____entrypoint| |____Dockerfile|____pkg| |____apis| | |____apis.go| |____controller| | |____controller.go

$ operator-sdk add api --api-version=myapp.com/v1alpha1 --kind=MyAppService$ operator-sdk add controller --api-version=myapp.com/v1alpha1 --kind=MyAppService

$ operator-sdk build your.container.registry/youruser/myapp-operator

$ kubectl kudo install zookeeper$ kubectl kudo install kafka

$ kubectl kudo install kafka --instance=my-kafka-name \            -p ZOOKEEPER_URI=zk-zookeeper-0.zk-hs:2181 \            -p ZOOKEEPER_PATH=/my-path -p BROKER_CPUS=3000m \            -p BROKER_COUNT=5 -p BROKER_MEM=4096m \            -p DISK_SIZE=40Gi -p MIN_INSYNC_REPLICAS=3 \            -p NUM_NETWORK_THREADS=10 -p NUM_IO_THREADS=20

Инновации

Сообщество

Будущее

Раздутые контейнеры

Задача

• Контейнер должен выдавать содержимое файла по http на выбранный вами порт
• Монтирование томов не допускается (так называемое Правило Марека )

Упрощенное решение

const fs = require("fs");const http = require('http');const server = http.createServer((req, res) => {res.writeHead(200, { 'content-type': 'text/html' })fs.createReadStream('index.html').pipe(res)})server.listen(port, hostname, () => {console.log(`Server: http://0.0.0.0:8080/`);});

FROM node:14COPY . .CMD ["node", "index.js"]

Уменьшенный базовый образ

Скомпилированные языки

package mainimport ("fmt""log""net/http")func main() {fileServer := http.FileServer(http.Dir("./"))http.Handle("/", fileServer)fmt.Printf("Starting server at port 8080\n")if err := http.ListenAndServe(":8080", nil); err != nil {log.Fatal(err)}}

FROM golang:1.14COPY . .RUN go build -o server .CMD ["./server"]

Многоступенчатые сборки

### этап сборки ###FROM golang:1.14-alpine AS builderCOPY . .RUN go build -o server .### этап запуска ###FROM alpine:3.12COPY --from=builder /go/server ./serverCOPY index.html index.htmlCMD ["./server"]

Статическая компиляция + образ Scratch

### этап сборки ###FROM golang:1.14 as builderCOPY . .RUN go build \-ldflags "-linkmode external -extldflags -static" \-a server.go### этап запуска ###FROM scratchCOPY --from=builder /go/server ./serverCOPY index.html index.htmlCMD ["./server"]

ASM как залог победы!

### этап сборки ###FROM ubuntu:18.04 as builderRUN apt updateRUN apt install -y make yasm as31 nasm binutilsCOPY . .RUN make release### этап запуска ###FROM scratchCOPY --from=builder /asmttpd /asmttpdCOPY /web_root/index.html /web_root/index.htmlCMD ["/asmttpd", "/web_root", "8080"]

Локдаун Китая в марте 2020 года

Разворот ситуации

Эффект домино

В мире насчитывается около 180 млн контейнеров, но все они находятся не в том месте, главный исполнительный директор логистической компании Redwood Logistics Марк Йегер

Как это сказалось на рынке электроники

Закрытые порты Китая

Перспективы

Ироничное послесловие

На правах рекламы

Предисловие

Я много раз заглядывал на просторы интернета, но вразумительного и полного описания, что же это такое хеш-таблицы, как они реализованы, так и не нашел. В связи с этим мне просто не терпелось написать пост на данную, столь интересную, тему.

Возможно, она не столь полезна для опытных программистов, но будет интересна для студентов технических ВУЗов и начинающих программистов-самоучек.

Мотивация использовать хеш-таблицы

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

Из этой таблицы очень хорошо понятно, почему же стоит использовать хеш-таблицы. Но тогда возникает противоположный вопрос: почему же тогда ими не пользуются постоянно?
Ответ очень прост: как и всегда, невозможно получить все сразу, а именно: и скорость, и память. Хеш-таблицы тяжеловесные, и, хоть они и быстро отвечают на вопросы основных операций, пользоваться ими все время очень затратно.

Понятие хеш-таблицы

Хеш-таблица это контейнер. Реализация у него, возможно, и не очевидная, но довольно простая.

Для начала объяснение в нескольких словах. Мы определяем функцию хеширования, которая по каждому входящему элементу будет определять натуральное число. А уже дальше по этому натуральному числу мы будем класть элемент в (допустим) массив. Тогда имея такую функцию мы можем за O(1) обработать элемент.

Теперь стало понятно, почему же это именно хеш-таблица.

Проблема коллизии

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

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

Решения проблемы коллизии методом двойного хеширования

Мы будем (как несложно догадаться из названия) использовать две хеш-функции, возвращающие взаимопростые натуральные числа.

Одна хеш-функция (при входе g) будет возвращать натуральное число s, которое будет для нас начальным. То есть первое, что мы сделаем, попробуем поставить элемент g на позицию s в нашем массиве. Но что, если это место уже занято? Именно здесь нам пригодится вторая хеш-функция, которая будет возвращать t шаг, с которым мы будем в дальнейшем искать место, куда бы поставить элемент g.

Мы будем рассматривать сначала элемент s, потом s + t, затем s + 2*t и т.д. Естественно, чтобы не выйти за границы массива, мы обязаны смотреть на номер элемента по модулю (остатку от деления на размер массива).

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

Реализация хеш-таблицы

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

int HashFunctionHorner(const std::string& s, int table_size, const int key){    int hash_result = 0;    for (int i = 0; s[i] != 0; ++i)        hash_result = (key * hash_result + s[i]) % table_size;    hash_result = (hash_result * 2 + 1) % table_size;    return hash_result;}struct HashFunction1 {    int operator()(const std::string& s, int table_size) const    {        return HashFunctionHorner(s, table_size, table_size - 1); // ключи должны быть взаимопросты, используем числа <размер таблицы> плюс и минус один.    }};struct HashFunction2 {    int operator()(const std::string& s, int table_size) const    {        return HashFunctionHorner(s, table_size, table_size + 1);    }};

Чтобы идти дальше, нам необходимо разобраться с проблемой: что же будет, если мы удалим элемент из таблицы? Так вот, его нужно пометить флагом deleted, но просто удалять его безвозвратно нельзя. Ведь если мы так сделаем, то при попытке найти элемент (значение хеш-функции которого совпадет с ее значением у нашего удаленного элемента) мы сразу наткнемся на пустую ячейку. А это значит, что такого элемента и не было никогда, хотя, он лежит, просто где-то дальше в массиве. Это основная сложность использования данного метода решения коллизий.

Помня о данной проблеме построим наш класс.

template <class T, class THash1 = HashFunction1, class THash2 = HashFunction2>class HashTable{    static const int default_size = 8; // начальный размер нашей таблицы    constexpr static const double rehash_size = 0.75; // коэффициент, при котором произойдет увеличение таблицы    struct Node    {        T value;        bool state; // если значение флага state = false, значит элемент массива был удален (deleted)        Node(const T& value_) : value(value_), state(true) {}    };    Node** arr; // соответственно в массиве будут хранится структуры Node*    int size; // сколько элементов у нас сейчас в массиве (без учета deleted)    int buffer_size; // размер самого массива, сколько памяти выделено под хранение нашей таблицы    int size_all_non_nullptr; // сколько элементов у нас сейчас в массиве (с учетом deleted)};

На данном этапе мы уже более-менее поняли, что у нас будет храниться в таблице. Переходим к реализации служебных методов.

...public:    HashTable()    {        buffer_size = default_size;        size = 0;        size_all_non_nullptr = 0;        arr = new Node*[buffer_size];        for (int i = 0; i < buffer_size; ++i)            arr[i] = nullptr; // заполняем nullptr - то есть если значение отсутствует, и никто раньше по этому адресу не обращался    }    ~HashTable()    {        for (int i = 0; i < buffer_size; ++i)            if (arr[i])                delete arr[i];        delete[] arr;    }

Из необходимых методов осталось еще реализовать динамическое увеличение, расширение массива метод Resize.
Увеличиваем размер мы стандартно вдвое.

void Resize()    {        int past_buffer_size = buffer_size;        buffer_size *= 2;        size_all_non_nullptr = 0;        Node** arr2 = new Node * [buffer_size];        for (int i = 0; i < buffer_size; ++i)            arr2[i] = nullptr;        std::swap(arr, arr2);        for (int i = 0; i < past_buffer_size; ++i)        {            if (arr2[i] && arr2[i]->state)                Add(arr2[i]->value); // добавляем элементы в новый массив        }        // удаление предыдущего массива        for (int i = 0; i < past_buffer_size; ++i)            if (arr2[i])                delete arr2[i];        delete[] arr2;    }

Немаловажным является поддержание асимптотики O(1) стандартных операций. Но что же может повлиять на скорость работы? Наши удаленные элементы (deleted). Ведь, как мы помним, мы ничего не можем с ними сделать, но и окончательно обнулить их не можем. Так что они тянутся за нами огромным балластом. Для ускорения работы нашей хеш-таблицы воспользуемся рехешом (как мы помним, мы уже выделяли под это очень странные переменные).

Теперь воспользуемся ими, если процент реальных элементов массива стало меньше 50 %, то мы производим Rehash, а именно делаем то же самое, что и при увеличении таблицы (resize), но не увеличиваем. Возможно, это звучит глуповато, но попробую сейчас объяснить. Мы вызовем наши хеш-функции от всех элементов, переместим их в новых массив. Но с deleted-элементами это не произойдет, мы не будем их перемещать, и они удалятся вместе со старой таблицей.

Но к чему слова, код все разъяснит:

void Rehash()    {        size_all_non_nullptr = 0;        Node** arr2 = new Node * [buffer_size];        for (int i = 0; i < buffer_size; ++i)            arr2[i] = nullptr;        std::swap(arr, arr2);        for (int i = 0; i < buffer_size; ++i)        {            if (arr2[i] && arr2[i]->state)                Add(arr2[i]->value);        }        // удаление предыдущего массива        for (int i = 0; i < buffer_size; ++i)            if (arr2[i])                delete arr2[i];        delete[] arr2;    }

Ну теперь мы уже точно на финальной, хоть и длинной, и полной колючих кустарников, прямой. Нам необходимо реализовать вставку (Add), удаление (Remove) и поиск (Find) элемента.

Начнем с самого простого метод Find элемент по значению.

bool Find(const T& value, const THash1& hash1 = THash1(), const THash2& hash2 = THash2())    {        int h1 = hash1(value, buffer_size); // значение, отвечающее за начальную позицию        int h2 = hash2(value, buffer_size); // значение, ответственное за "шаг" по таблице        int i = 0;        while (arr[h1] != nullptr && i < buffer_size)        {            if (arr[h1]->value == value && arr[h1]->state)                return true; // такой элемент есть            h1 = (h1 + h2) % buffer_size;            ++i; // если у нас i >=  buffer_size, значит мы уже обошли абсолютно все ячейки, именно для этого мы считаем i, иначе мы могли бы зациклиться.        }        return false;    }

Далее мы реализуем удаление элемента Remove. Как мы это делаем? Находим элемент (как в методе Find), а затем удаляем, то есть просто меняем значение state на false, но сам Node мы не удаляем.

bool Remove(const T& value, const THash1& hash1 = THash1(), const THash2& hash2 = THash2())    {        int h1 = hash1(value, buffer_size);        int h2 = hash2(value, buffer_size);        int i = 0;        while (arr[h1] != nullptr && i < buffer_size)        {            if (arr[h1]->value == value && arr[h1]->state)            {                arr[h1]->state = false;                --size;                return true;            }            h1 = (h1 + h2) % buffer_size;            ++i;        }        return false;    }

Ну и последним мы реализуем метод Add. В нем есть несколько очень важных нюансов. Именно здесь мы будем проверять на необходимость рехеша.

Помимо этого в данном методе есть еще одна часть, поддерживающая правильную асимптотику. Это запоминание первого подходящего для вставки элемента (даже если он deleted). Именно туда мы вставим элемент, если в нашей хеш-таблицы нет такого же. Если ни одного deleted-элемента на нашем пути нет, мы создаем новый Node с нашим вставляемым значением.

bool Add(const T& value, const THash1& hash1 = THash1(),const THash2& hash2 = THash2())    {        if (size + 1 > int(rehash_size * buffer_size))            Resize();        else if (size_all_non_nullptr > 2 * size)            Rehash(); // происходит рехеш, так как слишком много deleted-элементов        int h1 = hash1(value, buffer_size);        int h2 = hash2(value, buffer_size);        int i = 0;        int first_deleted = -1; // запоминаем первый подходящий (удаленный) элемент        while (arr[h1] != nullptr && i < buffer_size)        {            if (arr[h1]->value == value && arr[h1]->state)                return false; // такой элемент уже есть, а значит его нельзя вставлять повторно            if (!arr[h1]->state && first_deleted == -1) // находим место для нового элемента                first_deleted = h1;            h1 = (h1 + h2) % buffer_size;            ++i;        }        if (first_deleted == -1) // если не нашлось подходящего места, создаем новый Node        {            arr[h1] = new Node(value);            ++size_all_non_nullptr; // так как мы заполнили один пробел, не забываем записать, что это место теперь занято        }        else        {            arr[first_deleted]->value = value;            arr[first_deleted]->state = true;        }        ++size; // и в любом случае мы увеличили количество элементов        return true;    }

В заключение приведу полную реализацию хеш-таблицы:

int HashFunctionHorner(const std::string& s, int table_size, const int key){    int hash_result = 0;    for (int i = 0; s[i] != 0; ++i)    {        hash_result = (key * hash_result + s[i]) % table_size;    }    hash_result = (hash_result * 2 + 1) % table_size;    return hash_result;}struct HashFunction1 {    int operator()(const std::string& s, int table_size) const    {        return HashFunctionHorner(s, table_size, table_size - 1);    }};struct HashFunction2 {    int operator()(const std::string& s, int table_size) const    {        return HashFunctionHorner(s, table_size, table_size + 1);    }};template <class T, class THash1 = HashFunction1, class THash2 = HashFunction2>class HashTable{    static const int default_size = 8;    constexpr static const double rehash_size = 0.75;    struct Node    {        T value;        bool state;        Node(const T& value_) : value(value_), state(true) {}    };    Node** arr;    int size;    int buffer_size;    int size_all_non_nullptr;    void Resize()    {        int past_buffer_size = buffer_size;        buffer_size *= 2;        size_all_non_nullptr = 0;        Node** arr2 = new Node * [buffer_size];        for (int i = 0; i < buffer_size; ++i)            arr2[i] = nullptr;        std::swap(arr, arr2);        for (int i = 0; i < past_buffer_size; ++i)        {            if (arr2[i] && arr2[i]->state)                Add(arr2[i]->value);        }        for (int i = 0; i < past_buffer_size; ++i)            if (arr2[i])                delete arr2[i];        delete[] arr2;    }    void Rehash()    {        size_all_non_nullptr = 0;        Node** arr2 = new Node * [buffer_size];        for (int i = 0; i < buffer_size; ++i)            arr2[i] = nullptr;        std::swap(arr, arr2);        for (int i = 0; i < buffer_size; ++i)        {            if (arr2[i] && arr2[i]->state)                Add(arr2[i]->value);        }        for (int i = 0; i < buffer_size; ++i)            if (arr2[i])                delete arr2[i];        delete[] arr2;    }public:    HashTable()    {        buffer_size = default_size;        size = 0;        size_all_non_nullptr = 0;        arr = new Node*[buffer_size];        for (int i = 0; i < buffer_size; ++i)            arr[i] = nullptr;    }    ~HashTable()    {        for (int i = 0; i < buffer_size; ++i)            if (arr[i])                delete arr[i];        delete[] arr;    }    bool Add(const T& value, const THash1& hash1 = THash1(),const THash2& hash2 = THash2())    {        if (size + 1 > int(rehash_size * buffer_size))            Resize();        else if (size_all_non_nullptr > 2 * size)            Rehash();        int h1 = hash1(value, buffer_size);        int h2 = hash2(value, buffer_size);        int i = 0;        int first_deleted = -1;        while (arr[h1] != nullptr && i < buffer_size)        {            if (arr[h1]->value == value && arr[h1]->state)                return false;            if (!arr[h1]->state && first_deleted == -1)                first_deleted = h1;            h1 = (h1 + h2) % buffer_size;            ++i;        }        if (first_deleted == -1)        {            arr[h1] = new Node(value);            ++size_all_non_nullptr;        }        else        {            arr[first_deleted]->value = value;            arr[first_deleted]->state = true;        }        ++size;        return true;    }    bool Remove(const T& value, const THash1& hash1 = THash1(), const THash2& hash2 = THash2())    {        int h1 = hash1(value, buffer_size);        int h2 = hash2(value, buffer_size);        int i = 0;        while (arr[h1] != nullptr && i < buffer_size)        {            if (arr[h1]->value == value && arr[h1]->state)            {                arr[h1]->state = false;                --size;                return true;            }            h1 = (h1 + h2) % buffer_size;            ++i;        }        return false;    }    bool Find(const T& value, const THash1& hash1 = THash1(), const THash2& hash2 = THash2())    {        int h1 = hash1(value, buffer_size);        int h2 = hash2(value, buffer_size);        int i = 0;        while (arr[h1] != nullptr && i < buffer_size)        {            if (arr[h1]->value == value && arr[h1]->state)                return true;            h1 = (h1 + h2) % buffer_size;            ++i;        }        return false;    }

Процессорные ограничения и троттлинг

Что может случиться, если мы не зададим процессорные ограничения?

Проявление проблемы троттлинга и отклика

Снятие процессорных ограничений (с особой осторожностью)

Как защитить ваши ноды при снятии ограничений?

Результаты

Исправлен ли баг ядра Linux?

• Debian: фикс интегрирован в последнюю версию дистрибутива, buster, и выглядит достаточно свежим (август 2020 года). Некоторые предыдущие версии тоже могут быть пофикшены.
• Ubuntu: фикс интегрирован в последнюю версию Ubuntu Focal Fossa 20.04
• EKS обзавелся фиксом еще в декабре 2019 года. Если ваша версия ниже этой, следует обновить AMI.
• kops: С июня 2020 года у kops 1.18+ основным образом хоста станет Ubuntu 20.04. Если ваша версия kops старше, вам, вероятно, придется подождать фикса. Мы и сами сейчас ждем.
• GKE (Google Cloud): Фикс интегрирован в январе 2020 года, однако проблемы с троттлингом все еще наблюдаются.

Заключение

• Если вы работаете с Docker-контейнерами под Linux (не важно Kubernetes, Mesos, Swarm или еще какими), ваши контейнеры могут терять в производительности из-за троттлинга;
• Попробуйте обновиться до последней версии вашего дистрибутива в надежде, что баг уже пофиксили;
• Снятие процессорных ограничений решит проблему, но это опасный прием, который следует применять с особой осторожностью (лучше сначала обновить ядро и сравнить результаты);
• Если вы сняли процессорные ограничения, внимательно отслеживайте использование процессора и памяти, и убедитесь, что ваши ресурсы процессора превышают потребление;
• Безопасным вариантом будет автоскалирование подов для создания новых подов в случае высокой нагрузки на железо, чтобы kubernetes назначал их в свободные ноды.

Экстремальный минимализм

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

Язык Rust

Интеграция с сервисами AWS

На правах рекламы

Какой у вас тип организации?

Почему используете Ceph?

Как давно используете Ceph?

В каких странах у вас развернут Ceph?

Как устанавливаете Ceph?

N.B. Если всё ещё немного плаваете в вопросах, как устанавливать и разворачивать правильно Ceph c 15 октября запускается курс по Ceph от практиков. Вы изначально получите системные знания по базовым понятиям и терминам, а по окончании курса научитесь полноценно устанавливать, настраивать и управлять Ceph.

Как разворачиваете?

Применяемая операционная система

Какое оборудование применяете?

Какие накопители применяете?

Используете отдельную сеть для OSD?

Какое ПО используете совместно с Ceph?

Для чего используете RBD?

Для чего используете RGW?

Для чего используете CephFS?

Какой мониторинг используете?

N.B. Если есть необходимость подтянуть, а то и научиться правильному логированию и мониторингу, добро пожаловать на курс Мониторинг и логирование инфраструктуры в Kubernetes. Сейчас можно приобрести курс с существенной скидкой. На курсе узнаете Узнаете, что именно мониторить, какие метрики собирать и как настраивать алерты для оперативного поиска и устранения проблем в кластере. Какие метрики стоит собирать с помощью Prometheus? Как визуализировать мониторинг с помощью Grafana и как грамотно настроить алерты?

Шаг первый: настройка запросов пода и лимитов

Из документации Kubernetes: на шаге фильтрации определяется набор узлов, где можно запланировать под. Например, фильтр PodFitsResources проверяет, достаточно ли на узле ресурсов для удовлетворения конкретных запросов пода на ресурсы.

Опять же, из официальной документации: если для контейнера установлен лимит памяти 4 ГиБ, то kubelet (и среда выполнения контейнера) введет его принудительно. Среда выполнения не позволяет контейнеру использовать больше заданного лимита ресурсов. Например, когда процесс в контейнере пытается использовать больше допустимого объема памяти, ядро системы завершает этот процесс с ошибкой out of memory (OOM).

1. Используя инструмент нагрузочного тестирования, моделируем базовый уровень трафика и наблюдаем за использованием ресурсов пода (памяти и процессора).
2. Устанавливаем запросы пода на произвольно низкое значение (с ограничением ресурсов примерно в 5 раз больше значения запросов) и наблюдаем. Когда запросы на слишком низком уровне, процесс не может начаться, что часто вызывает загадочные ошибки времени выполнения Go.

Шаг второй: настройка тестов Liveness и Readiness

SELECT small_item FROM table LIMIT 1

livenessProbe:  httpGet:      path: /api/liveness       port: http readinessProbe:   httpGet:       path: /api/readiness       port: http  periodSeconds: 2

• initialDelaySeconds сколько секунд пройдет между запуском контейнера и началом запуска проб.
• periodSeconds интервал ожидания между запусками проб.
• timeoutSeconds количество секунд, по истечении которых под считается аварийным. Обычный тайм-аут.
• failureThreshold количество отказов тестов, прежде чем в под будет отправлен сигнал перезапуска.
• successThreshold количество успешных проб, прежде чем под переходит в состояние готовности (после сбоя, когда под запускается или восстанавливается).

Шаг третий: настройка дефолтных сетевых политик пода

---apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata:   name: default-deny-ingressspec:   podSelector: {}   policyTypes:     - Ingress

Шаг четвертый: нестандартное поведение с помощью хуков и init-контейнеров

lifecycle:  preStop:   exec:     command: ["/usr/local/bin/nginx-killer.sh"]

#!/bin/bashsleep 3PID=$(cat /run/nginx.pid)nginx -s quitwhile [ -d /proc/$PID ]; do   echo "Waiting while shutting down nginx..."   sleep 10done

Как обычно, цитата из документации: init-контейнеры безопасно запускают пользовательский код или утилиты, которые иначе снизят безопасность образа контейнера приложения. Храня отдельно ненужные инструменты, вы ограничиваете поверхность атаки образа контейнера приложения.

Шаг пятый: настройка ядра

initContainers:  - name: sysctl     image: alpine:3.10     securityContext:         privileged: true      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

В заключение

1. Сколько ресурсов потребляют приложения и как изменится этот объем?
2. Каковы реальные требования к масштабированию? Сколько трафика в среднем будет обрабатывать приложение? А как насчет пикового трафика?
3. Как часто сервису потребуется горизонтальное масштабирование? Как быстро нужно вводить в строй новые поды, чтобы принимать трафик?
4. Насколько корректно завершается работа подов? Нужно ли это вообще? Можно ли добиться развертывания без даунтайма?
5. Как минимизировать риски для безопасности и ограничить ущерб от любых скомпрометированных подов? Есть ли у каких-то сервисов разрешения или доступы, которые им не требуются?

1. Лучшие практики и рекомендации для запуска контейнеров и Kubernetes в производственных средах.
2. 90+ полезных инструментов для Kubernetes: развертывание, управление, мониторинг, безопасность и не только.
3. Наш канал Вокруг Kubernetes в Телеграме.

Чем контейнеры отличаются от виртуальных машин, почему Docker настолько популярен, что такое Kubernetes и в чём его преимущества и недостатки. В интервью АйТиБороде СТО Слёрма Марсель Ибраев и старший инженер Southbridge Николай Месропян рассказали о контейнеризации понятным языком. Мы перевели интервью в текст для тех, кому лень смотреть.
Мне не лень смотреть, мне лень читать

Разница между контейнеризацией и виртуализацией

Что такое виртуализация?

Виртуализация появилась как средство уплотнения окружений на одном и том же железе. Сначала программный продукт выполнялся на железном сервере. Потом, чтобы иметь возможность поселять в одно и то же железо больше клиентов, чтобы максимально полно утилизировать производительные мощности, придумали виртуализацию. Теперь на одном и том же железе можно держать несколько окружений. В зависимости от среды, опять же. Есть полностью проприетарные решения, такие как vmware vsphere, есть опенсорсные решения, как QEMU KVM, на основе которого Red Hat делает свой коммерческий гипервизор Red Hat Virtualization. На платформе Windows есть Hyper-V.

Благодаря виртуализации мы получаем возможность более полно утилизировать ресурсы железа. Но при этом речь идёт о полной изоляции: в виртуальной машине полностью изолированное ядро, все библиотеки, строго ограниченные ресурсы по процессору и памяти.

Ядра разделяются физически или можно виртуально разделить там одно физическое ядро на несколько при виртуализации?

Если у вас на хосте один процессор, то в виртуальной машине вы два иметь не можете. Ресурсы хоста можно делить произвольным образом между всеми виртуальными машинами. Либо статично, выделяя под конкретную виртуальную машину один, два, три процессора. Либо динамически, чтобы использовались просто свободные ресурсы в нужное время.

Что такое контейнеры и контейнеризация, и чем отличаются?

Детали зависят от операционной системы, на которой выполняется контейнер, но вообще контейнер делит с хостом ядро, пространство памяти ядра, и своё у контейнера только пользовательское окружение. Первая широко распространенная технология контейнеризации в Linux это OpenVZ, которая потом превратилась в коммерческий продукт Virtuozzo. Мы много работали и работаем с OpenVZ. У нас клиентские окружения жили в контейнерах OpenVZ, пока мы не перешли на более современные технологии.

То есть контейнер от виртуальной машины отличается только тем, что в контейнере общее адресное пространство?

Нет. Виртуальная машина изолируется полностью средствами процессора (технологии Intel, AMD, VMX).

Контейнер работает на ядре хостовой операционной системы и использует для изоляции возможности не железа, а операционной системы, так называемое пространство имён. Если мы говорим о Docker, как о наиболее распространённой сейчас технологии виртуализации, используются так называемые cgroups в ядре Linux.

Контейнер это продолжение виртуализации? То есть это технология, которая является преемником виртуализации?

Нет. Они ни в коем случае не конкурируют. Они занимают совершенно разные ниши в использовании.

Тогда почему их постоянно сравнивают? И постоянно есть вопрос, что лучше виртуализация или контейнеризация?

С моей точки зрения сравнить контейнеризацию и виртуализацию нельзя. Это сравнение теплого с мягким.

Где лучше использовать виртуализацию, а где контейнеризацию? Для как разработчика нет разницы: и то, и то используется для развертывания приложений. Два-три приложения ты фигачишь контейнером. Ты можешь виртуальных машин столько создать, и в каждой из них запустить своё приложение. В чем разница для обычных девелоперов?

Для тебя виртуальная машина это обычная изолированная операционная система, целиком: своё ядро, свой init, systemd и так далее. Чем она отличается от контейнера с точки зрения потребления ресурсов? Тем, что она полностью занимает все ресурсы, под неё выделенные. То есть, есть механизмы, когда можно динамически, то есть в зависимости от потребления процессами внутри виртуальной машины, освобождать память на хосте или занимать её. Но это всё полумеры.

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

Если мы говорим о Docker (а в рамках разговора мы не сможем обсудить все варианты контейнеризации), то он рассчитан на то, что в одном контейнере работает одно приложение.

Возвращаясь к твоему первому вопросу, разница вот в чём. Допустим, если у тебя на хосте Linux или VMware, то виртуальная машина у тебя может быть Windows. Если у тебя в контейнере Linux, то у тебя и снаружи Linux. Потому что мы в первую очередь пользуемся для изоляции не средствами железа, не средствами гипервизора, а средствами операционной системы cgroups и namespace.

Почему контейнеры разворачиваются быстрее? Потому что они маленькие, содержат в себе там одно приложение? Почему быстрее развернуть контейнер, нежели зафигачить, законфигурировать?

Виртуалка сама по себе большая, так как содержит целую операционную систему. Если нам нужно развернуть виртуальную машину, то нужно нести с собой и ядро, и всё пользовательское окружение, и какой-то запас места (потому что динамически оно с хостом шариться в общем случае не может). Я не видел линуксовую виртуальную машину весом меньше 10 Гб, и это без данных. Потом к ней еще нужно прицепить диски для данных, в зависимости от того, что будет внутри.

Если говорить о контейнерах, есть разные дистрибутивы, в том числе специально созданные для контейнеризации, тот же Alpine Linux, который в голом виде весит 20 или 50 Мб в зависимости от версии. То есть ничего не весит, собственно говоря.

Виртуалка тянет полностью всю операционку, а когда Docker создаешь, ты тянешь только какие-то небольшие пакеты?

Нет. Чтобы создать Docker-контейнер ты должен собрать образ. Ты берёшь какой-то базовый образ, тот же Alpine, CentOS или Ubuntu. В него с помощью специальных команд зашиваешь свое приложение и выгружаешь уже туда, где оно будет работать.

То есть все равно ты в контейнере используешь полноценную операционку? Вот тот же образ Alpine Linux.

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

Но потенциально ты можешь и полноценный Linux запустить в контейнере?

Потенциально да, можешь.

Но смысла в этом, наверное, нет.

В этом совершенно нет никакого смысла, потому что хорошей практикой при использовании Docker считается один контейнер одно приложение.

Один контейнер? А это не слишком жирно использовать для одного приложения, ну пусть и урезанную, но операционную систему?

Когда нужна изоляция это не слишком жирно.

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

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

Почему Docker захватил весь рынок? Вот ты говорил, что было решение какое-то изначально в Linux?

Нет. Оно занимало и занимает совершенно другую нишу. Docker захватил весь рынок в первую очередь потому, что он первым начал использовать технологии namespace и cgroups для, так сказать, народа. Понизил порог вхождения в эти технологии до того, чтобы можно было выйти на широкий рынок, на широкого пользователя.

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

А как тут обстоит дело с дебагом твоего кода, логированием и всем остальным? Со стороны кажется, что это сложновато: нужно залезть внутрь какого-то контейнера, который представляет из себя урезанную операционку

Когда работаешь с контейнерами, в принципе не обязательно думать, что это операционка, не операционка. Там начинается другой мир. Да, к нему надо привыкнуть, но с дебагом, логированием проблем нет никаких, потому что хорошим тоном считается писать все логи в stdout/stderr контейнера, а не в файлики внутри него.

Docker-контейнер знаменит тем, что он одноразовый. Он запустился, а после того, как ты контейнер удаляешь, если ты специально никаких мер не предпринимал, чтобы сохранить в нём данные, у тебя всё удаляется. Поэтому все логи обычно пишут в stdout/stderr, средствами Docker или внешних утилит экспортируют их в ElasticSearch, ClickHouse или какие-то другие системы хранения логов и централизованно уже с ними работают. В первую очередь потому, что контейнеров много. Контейнеров в сетапах могут быть десятки, сотни, тысячи и десятки тысяч.

Как правило, они весьма короткоживущие. Если мы сетапим железные сервер или виртуалку, они могут работать годами, то контейнер живёт до обновления образа максимум. Поэтому контейнеров много, они сравнительно короткоживущие, эфемерные, непостоянные. И поэтому всё, что нужно хранить вне них, нужно хранить специальными методами.

Что насчет контейнеризации в Windows? Насколько я помню, там если не всё очень плохо, то не всё так просто, как на Linux.

Там, действительно, очень сложно. Я ни в коем случае не Windows-админ, знаком поверхностно. Но насколько я знаю, нативная контейнеризация в Windows есть. Есть средства изоляции и по ресурсам, и по пространствам имен, сетевые пространства имен, для памяти, под файлы и так далее. То есть можно Windows запустить как контейнер Windows. Это Windows Server Containerization, если я не ошибаюсь (Windows-админы, не обессудьте).

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

Когда контейнер выполняется, он не представляет собой некий образ. Когда выполняется виртуальная машина это образ, внутри которого своя файловая система, свои разделы, где всё это нарезано и всё это варится. Когда выполняется контейнер, для операционной системы это просто набор ограничений. Когда мы смотрим на процесс виртуальной машины с хоста, мы видим один процесс. В винде это Microsoft Hyper-V, в Linux это QEMU KVM, в vSphere это тоже один процесс. Когда мы смотрим с хоста на контейнер, то видим дерево процессов.

Но почему мы образы передаем друг другу? Я приложение запаковываю в Docker, и мы девелоперы передаём друг другу образы.

Образ это то, из чего контейнер запускается. А с точки зрения хоста это дерево процессов, которые ограничены через встроенные средства ограничения, то есть через namespace и cgroups. Это я к тому, что Docker по своей сути линуксовый.

А почему нельзя было сделать универсальное решение, чтобы оно и для Linux, и для винды работала? Там нет общих API или в Linux есть что-то, чего нет

Ядро-то разное.

Архитектура разная, да?

Да, API Windows и API Linux это совершенно разные вещи. По той же причине нет нативного Docker для macOS. Потому что используются средства изоляции линуксового ядра.

Я думал, что ядра macOS и Linux очень похожи.

Нет. macOS больше UNIX-like, нежели Linux. Потому что, как известно GNU is not UNIX (рекурсивный акроним). А macOS внутри более, так сказать, близка к юниксам. И там нет таких механизмов, как в Linux. Они развиваются независимо.

Docker и для Windows, и для macOS это чужеродное тело, которое запускается в линуксовой виртуалке.

Получается, чтобы запустить контейнер, нужно запустить еще и виртуалку?

Мы запускаем линуксовую виртуалку, а уже в ней мы уже запускаем эти контейнеры. Docker Desktop скрывает от пользователя все сложные процессы, но внутри все равно остаются всякие. Ну не то, чтобы это очень неэффективно. Если вам нужно разрабатывать что-то под Docker, но у вас только Windows или только macOS, то это позволяет работать, да. Но в продакшене с нагрузками так ничего толком не запустишь.

Я понял, что ты в основном с Linux работаешь, но вдруг ты слышал про WSL (Windows Subsystem for Linux)?

Разумеется, я на OpenNET читаю об этом всём и удивляюсь.

А может ли эта штука запустить контейнеры нативно? Я просто не знаю, она тоже под виртуалкой?

Насколько я понимаю, WSL это Wine наоборот. То есть трансляция вызовов API в нативные для винды. Если у нас Wine это трансляция вызовов виндового API для ядра Linux, то WSL это наоборот. И поэтому средств изоляции там ядерных линуксовых нет. Поэтому увы, увы.

Про оркестрацию

Скажем, у нас микросервисная архитектура, и не одно приложение, а много всего: 10, 20, 40, 100 микросервисов. Руками их конфигурировать совсем не прикольно. Как с этим разбираются?

Да, это вполне типовая ситуация. Сейчас особенно, потому что стильно, модно, молодежно. Постепенно приложение обрастает логикой, микросервисов становится больше и больше. И одного Docker, и даже Docker Compose уже становится мало. Ну и плюс ко всему, наверное, еще хочется какую-то отказоустойчивость, чтобы это на нескольких серверах работало. Возможно, какой-то Service Discovery и прочее.

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

Марсель Ибраев, СТО Слёрм

Docker Compose не позволяет нам ничего делать? Ведь это тоже средство управления несколькими контейнерами.

Docker Compose, как минимум, не позволяет запускать проект на нескольких серверах. То есть это все равно все-таки история про одну ноду. Поэтому, да.

ОК. Что придумано? Что есть сейчас, чтобы это все делать?

Сразу нужно сказать, что инфраструктурный стандарт это всё-таки Kubernetes. Штука, которая в свое время была произведена в Google. И Google по зову сердца, по доброте своей решил поделиться с миром.

Есть ещё ряд решений, например, Docker Swarm, Mesos, OpenShift и другие, но всё-таки наиболее популярен и пользуется спросом Kubernetes. Компании, которые задумываются о том, что им нужен оркестратор, в первую очередь смотрят на Kubernetes.

Где обычно применяются оркестраторы, в частности Kubernetes?

Да, это очень важный вопрос. Дело в том, что Kubernetes все проблемы не решает. Компания работает, работает, у них всё плохо (как правило, плохо с процессами) они такие: Блин, Kubernetes классная штука. Давайте её себе поставим у нас всё сразу станет хорошо! Но становится сильно хуже.

К Kubernetes нужно подходить уже осознанно. Работу с Kubernetes стоит рассматривать, когда у вас действительно большое количество микросервисов, когда есть определённые требования к уровню доступности вашего сервиса, когда над одной частью приложения трудятся несколько команд, когда нужна инфраструктура для автоматизации деплоя и тестов. На этом этапе да, действительно стоит задуматься о Kubernetes.

Если вы небольшая компания или если у вас монолит, и вы такие: Сейчас мы его в куб засунем и все станет хорошо! Нет, не станет.

Kubernetes работает только с контейнерами Docker и с их оркестрацией?

Kubernetes работает с контейнерами, но не только с Docker. У Kubernetes есть такая штука, которая называется Container Runtime Interface. В принципе, все системы контейнеризации, которые сейчас есть и которые поддерживают Container Runtime Interface, могут работать с Kubernetes. Например, rkt.

Сейчас возникло движение энтузиастов, которые выкорчевывают Docker из Kubernetes и используют что-то другое. Потому что Docker тоже не без проблем. Главная проблема Docker это его демон, который имеет свойство зависать, особенно при большой нагрузке. Но зачем демон, если у нас уже есть Kubernetes, есть достаточно зрелая инфраструктура и нам надо просто какое-то место для запуска контейнеров.

Дополнительный демон по сути не нужен. В эту сторону движение сейчас активно идёт, но, я думаю, дойдёт не быстро. Устоявшееся мнение, что контейнеры равно Docker, будет держаться долго.

А что может быть использовано вместо Docker более оптимальным путем?

Оптимально пока сложно сказать, потому что у конкурентов Docker есть свои минусы. К примеру, containerd не имеет нормального средства управления им. К слову, с версии 1.11, кажется, под капотом Docker containerd и работает. По сути, сейчас Docker выполняет роль обёртки над containerd, а там containerd, а внутри ещё runC, если уж совсем углубляться.

Кто-то говорит про Podman: делайте просто алиас Podman Docker, и можно сразу работать. Но тоже есть свои нюансы, поэтому мы в том числе пока работаем с Docker.

Расскажи подробнее, как вообще Kubernetes работает? Что у него происходит под капотом? Для начала уточним, Kubernetes это сервис или это какое-то ПО, которое можно ставить на сервера, или это и то и то?

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

Всегда нужно держать в голове, что Kubernetes это в первую очередь оркестратор контейнеров. Когда вы это понимаете, то вы понимаете, для чего он нужен.

Kubernetes состоит из нескольких компонентов, которые выполняют каждый свою роль (подробно о них ещё поговорим). Из этого вытекает две особенности:

1. Компоненты друг друга не аффектят. Если один упал, то все остальные могут продолжить работать.
2. Эти компоненты работают по pull-модели. Нет никакого центрального компонента, командира, который всем раздаёт команды, а как сдох, так все не знают что делать. Каждый компонент выполняет свою часть работы: сделал, завершил. Если он умер, ну значит этот кусочек не выполнится.

Теперь по поводу самих компонентов. Основной компонент это API-сервер. Это просто апишка, REST API (разработчики понимают, о чём речь): управление с помощью http-запросов, версионирование кстати тоже. Очень важно, что там есть версия API, при обновлении мы можем на эти версии API завязываться и за счёт этого обновляться менее болезненно. Есть API, с которым работают все: и клиент (мы, как оператор кластера), и компоненты остальные в том числе.

API-сервер работает с хранилищем, которое представляет из себя просто etcd. Etcd это key-value хранилище, то есть ключ-значение. Вот и API-сервер это единственный компонент, который с этим хранилищем взаимодействует.

Это какая-то разработка команды kubernetes?

Нет, это отдельная штука, очень древняя.

А почему её у Redis нет, например?

У Redis есть проблемы с многопоточностью, есть проблемы с кластеризацией (хотя они ее постепенно решают). А etcd штука древняя, все детские болезни там уже вылечены, и она достаточно такая отказоустойчивая.

Кстати, это хороший показатель, что если разработчики Kubernetes уже начиная с первых версий используют etcd, то, наверное, у себя его тоже можно использовать как key-value в кластер-режиме.

API-сервер единственный, кто с etcd работает, он записывает, считывает информацию. А в etcd у нас хранится всё. Там наши настройки кластера, манифесты всё, что мы делаем.

Мы как клиент хотим что-то создать, запустить приложение, и мы эту информацию передаем в API-сервер. Мы непосредственно это не делаем, конечно, там есть такая утилита, которая называется kubectl. С её помощью мы управляем всем кластером, делаем все операции, в том числе и запускаем приложения. Передаем yaml-манифест, где у нас в декларативном формате описано, как должно выглядеть приложение в кластере. Вот мы это передаем. Оно сохраняется в etcd и следующие компоненты постоянно смотрят в API-сервер.

Если немного углубиться, там есть подписка на событие и они по сути watch'ат. То есть никакого DDoS'а самого себя там нет. Следующий компонент, который берёт эту историю в работу это kube-controller-manager. По сути, мозг кластера Kubernetes. В него вшиты множество контроллеров: node-controller, endpoint-controller. Практически у всех абстракций, которые есть в Kubernetes, есть контроллер, и он вшит в этот бинарь. Эти контроллеры занимаются просто контролем вот этой абстракции: смотрят, есть ли новые, нужно ли что-то удалить и так далее.

Давай на примере. Если продолжать говорить о приложении, то контроллер, который отвечает за какое-то конкретное приложение, точнее за его манифест, за его абстракцию он видит, что мы что-то хотим создать, запустить. И он выполняет соответствующую работу, а именно дописывает манифест в etcd, обновляет информацию. Тут, конечно, без некоторого углубления нормально не объяснишь. Но есть такая абстракция, которая называется ReplicaSet. Она позволяет запускать приложение в нескольких инстансах. Через нее мы можем увеличивать, уменьшать количество реплик. И все здорово.

Это балансировка нагрузки?

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

А зачем?

Чтобы иметь возможность в случае чего скейлить свое приложение или скейлить обратно. То есть хотим в три инстанса реплики просто пишем три у нас три инстанса.

Ну это очень похоже на балансировку нагрузок.

Балансировкой уже занимается другая абстракция, которая уже трафик распределяет на вот эти три инстанса.

То есть они в принципе могут в паре работать?

Да. Они в паре и работают.

ReplicaSet не только создаёт реплики, она ещё и следит, чтобы их действительно было три. Причем не больше, не меньше.

Инстансы, которые запускает ReplicaSet, называются подами. В подах и работает наше приложение (про поды мы ещё поговорим).

И вот как раз, когда мы создаем, например, ReplicaSet, у нас есть такой ReplicaSet controller в этом контроллер-менеджере, который описание подов для ReplicaSet генерирует, и туда же, грубо говоря, в etcd через API-сервер скидывает.

Потом подключается следующий компонент. После того, как мы поняли, какое приложение нам нужно из скольких инстансов запускать, оно вот в etcd хранится этот манифест. Далее у нас идет такой компонент, который называется scheduler. Его роль достаточно проста. Он решает, на каких серверах это приложение надо запускать. Но делает это не просто так, у него есть свои алгоритмы принятия решения.

Ну в частности, он смотрит на ресурсы, то есть сколько ресурсов на ноде, если мы для этого приложения запрашиваем 1 ГБ ОЗУ, а на ноде только 512 свободны, он туда не отправляет.

Под приложением ты понимаешь Docker-контейнер с приложением?

Да, контейнер.

Контейнер с приложением каким-то.

Да.

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

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

На стабильность он не смотрит. Он смотрит в первую очередь на ресурсы. Какой смысл отправлять приложение на запуск туда, где их недостаточно. Смотрит ещё на priority class это такая штука, с помощью которой мы можем задать приоритет.

Например, в кластере два окружения: продакшн и стейджинг. Конечно, продакшн более важен. И для них мы priority class выставляем высокий. Для стейджинга мы можем поставить поменьше. Когда происходит авария, Kubernetes понимает, что часть серверов отвалилась (за это будет отвечать Node Controller, который контролирует жизнь нод), он принимает решение, что надо те поды, которые там были, запустить в живых серверах. Scheduler будет запускать в первую очередь поды продакшена.

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

А если не хватит под продакшн места?

Если не хватит, ну сорян. Поды будут висеть в pending, то есть ждать, когда появятся ресурсы. И scheduler назначает Если на такой низкий уровень опуститься, то в манифесте пода есть специальное поле, которое называется nodeName имя ноды. И вот пока scheduler не принял решение оно пустое. Scheduler говорит, что вот этот под, вот это приложение нужно запускать там на Node 2, и он эту информацию передает, API-сервер это записывает в etcd и в это поле вносит это имя. А далее в работу вступает последний компонент всей этой схемы, который называется kubelet.

Kubelet это компонент своего рода "node agent", то есть агент, который запущен на всех серверах кластера. Он тоже постоянно в API-сервер смотрит. И он видит, что появился под, то есть приложение, у которого в поле имя сервера написано его имя, там, где он работает. Он такой: Ага! Значит его нужно у себя запустить! Он видит, что у него запущено, и что от него хотят. Он передает Docker API, из манифеста считывает, что там конкретно нужно запустить, и говорит Docker, какой контейнер нужно запустить.

Kubelet, получается, замена Docker демона?

Вот в том то и дело, что не замена, к сожалению. Поэтому вот эти альтернативы и изобретаются, поэтому туда люди идут, потому что Docker демон висит. Но по сути да, он общается с Docker демоном по API, но без него вполне можно было обойтись. Причем он не просто их запускает, он постоянно смотрит за статусом, и статус этот передаёт в API-сервер.

Хелс-чек такой?

В том числе хелс-чек тоже делает Kubelet. И мы постоянно видим, какой статус у наших приложений в реальном времени. Вот то, что там сейчас пулинг образа идёт, что там сейчас она запускается, вот он на раннинг все хорошо, все запустилось. И вот только на этом этапе у нас физический запуск произошёл. То есть всё вот это это подготовка.

Ноды это всегда сервер или это может быть кластер серверов?

Ноды это место, где запущен Kubelet.

Это может быть виртуалка, как я понимаю?

Да, может быть виртуалка.

Ты сказал, что в результате этих действий мы получаем физически развёрнутое приложение. Kubelet посылает какие-то свои статусы, либо он просто stdout контейнера фигачит? К чему этот вопрос. Потому что, если у тебя приложение в stdout выдает логи, какой-то дебаг kubernetes как-то умеет это в одно место собирать и предоставлять в удобочитаемом виде, или это не его обязанность вообще?

В твоем вопросе, два вопроса скрыты. Статус самого контейнера (жив или не жив) берёт из Docker. Функционал приложения (работает ли оно) вот эти дебаг, логи, какие-то хелс-чеки это все тоже делает Kubelet, но для этого надо несколько строчек в манифест добавить и сказать, как именно проверять.

На данный момент поддерживается три возможности проверять приложение:

1. http-get это http-запрос в контейнер на инпоинт, и мы видим, работает оно, не работает, отвечает, не отвечает. С 200 по 399 код это ок, если 301 даже редирект это ок. Если 404 это не ок. 500 тем более.
2. exec мы внутрь контейнера делаем какой-то запрос, какую-то команду, проваливаемся. Например, select 1, проверяем, всё ли нормально с базой.
3. tcp socket Kubelet просто проверяет доступные сокеты. Если все хорошо, то все хорошо.

Есть три типа проверки контейнеров: это liveness, readiness и startup пробы.

Liveness проба это контроль за жизнью приложения. Постоянно Kubelet смотрит, ходит и смотрит. Там гибкие настройки, можно написать, как часто ходить, как проверять и так далее.

Readiness проба проверяет, а готово ли приложение принимать трафик. Потому что разные истории могут быть, это могут быть разные инпоинты у приложения. Мы проверяем, работает ли приложение, готово ли оно принимать трафик.

Startup проба это больше для легаси таких историй, которые очень долго поднимаются, молотятся в самом начале. То есть очень долго инициализируются. И startup проба проверяет, запустилось ли вообще приложение.

На каком размере архитектуры может работать Kubernetes? Может ли он контролировать сразу миллион инстансов?

Насколько я помню из документации, это 5000+, что ли, нод. На одной ноде по умолчанию можно запустить 110 подов, 110 экземпляров приложения.

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

Под это абстракция, в которой запускается приложение. Тут важно понять, что это не какая-то физическая оболочка, не какой-то процесс ещё один, это скорее именно абстракция, с которой работает Kubernetes.

Kubernetes не умеет работать с контейнерами. Мы не можем сказать: заскейль нам вот это приложение в трёх контейнерах. Мы можем только сказать: заскейль нам в трех подах. В поде может быть как один контейнер, так и несколько. То есть мы можем туда запихнуть, например, nginx и php-fpm в связке, и они будут скейлится по два контейнера в связке.

Но тут надо понимать, что хорошая практика засовывать в контейнер неделимые части приложения. Всё-таки, если 2-3 контейнера надо засовывать, то может, стоит ещё поиграться с логикой приложения. Обычно один контейнер засовывают и там есть еще второй, который сам запускается, это pause контейнер, который держит сетевой namespace, чтобы все контейнеры в поде были в одном namespace, и чтобы всё хорошо работало.

Это первая часть беседы. Во второй будет про хранение данных в Kubernetes и про Ansible. Не пропустите!

Вопросы задавал Лекс АйТиБорода iamitbeard

В чём проблема с базами данных и как позаботиться о безопасности в Kubernetes? Как врубиться в Ansible? Ответы на эти и другие вопросы читайте в продолжении интервью Лекса АйТиБороды со старшим инженером Southbridge Николаем Месропяном и СТО Слёрма Марселем Ибраевым.

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

На вопросы отвечает Марсель Ибраев

В чём проблема с базами данных в Kubernetes? Для меня как для разработчика проблем нет: зафигачил базу в Docker-контейнер и работаешь.

Проблемы нет для половины, наверное, комьюнити. Это вообще холиварный вопрос. В чатике kubernetes_ru (официальном чате русскоязычного сообщества Kubernetes) постоянно эти вопросы поднимаются.

А может, Docker не нужен? Зачем мне Docker для базы?

И это тоже. Были даже такие разговоры, что если база данных удовлетворяет 12 факторам, то это обычное приложение, запускайте и всё, 2020 год на дворе. Зачем вы её выносите отдельно, туда-сюда.

Но 12 факторов это не совсем про базу данных, там больше про stateless говорится. У нас все-таки stateful приложение, то есть приложение, которое должно сохранять статус и результат работы. После перезапуска оно этот результат терять не должно, в отличие от stateless.

И вот именно здесь краеугольный камень. Чтобы научить Kubernetes сохранять статус приложения (базы данных, таблички вот это всё), нужно присыпать ещё несколько абстракций сверху: PersistentVolume, PersistentVolumeClaim, StorageClass не буду сильно углубляться. То есть просто нужно иметь в виду, что повышается планка работы с Kubernetes.
Нужен человек, который умеет настраивать кластер этой базы данных. Потому что Kubernetes не важно, что запускается в поде (Pod): stateless приложение или stateful приложение он с ними работает одинаково. Он не соберёт магическим образом кластер баз данных и не будет за ним следить. Вы напишете манифест с тремя инстансами базы данных, Kubernetes его запустит, и это будет три отдельных инстанса базы данных, которые будут не в кластере.

Но с приложениями он умеет это делать?

Тоже нет. По факту это как бы отдельные инстансы, отдельные реплики приложения. Они по идее самостоятельные.

То есть на уровне записи и чтения данных всё равно нужно будет абстракцию какую-то свою клепать, Kubernetes ни при чём?

Да, и поэтому здесь нужны компетенции какого-то DBA, который на монолитах это уже 1000 раз настраивал, и скажет: Да, без проблем! Настроим!.

Следующий вопрос возникает с запуском базы данных, когда нам нужно выставить request/limit. Request/limit это инструмент, который позволяет работать с ресурсами.

Request это запрос на ресурсы. Например, мы знаем, что этому приложению минимально нужно 200 МБ ОЗУ. Если будет меньше, оно просто крашнется и не запустится. Мы выставляем request 200.

limit максимальная планка. Мы говорим, что 512 максимум, а если выше, то оно явно потекло и надо с ним что-то делать.

А вот как это сделать для базы данных хрен его поймёшь! В понедельник мы работаем на типовой нагрузке, в пятницу пришла баба Люда из бухгалтерии и запустила выгрузку из 1С миллиона строк, и нагрузка в потолок.

На моей истории было дважды, когда приложение (не база данных, для базы данных это будет суперкритично) начало утилизировать очень много ресурсов, и на сервере ресурсов не хватило всё померло. Kubernetes умный, он всё понял: взял и перетащил это приложение на другой сервер, но потреблять много ресурсов оно не перестало. Новый сервер упал, и как домино всё сложилось. Может повезти, что это всё в цикл замкнётся и будет переезжать, но ничего хорошего всё равно не будет. А с базой данных это критично, потому что вам нужно сохранять свои данные.

Есть 4 способа, как это сделать:

1. очень стабильно, но дорого,
2. не очень производительно, но дёшево,
3. более или менее по производительности, но без гарантии,
4. и дёшево, и круто.

Очень стабильно, но дорого это когда мы покупаем энтерпрайз, какую-нибудь железку с поддержкой. Там стоит такая бандура, SaaS всякие, и все работает. Здорово, но не у всех есть такие возможности.

Не очень производительно, но дёшево это использование облачных сервисов, которые предоставляют диски. Но здесь нужно понимать, что у многих есть в инструкции (в том числе и в документации баз данных) такая сноска: Ребята, если вы будете использовать какие-нибудь диски Google или Digital Ocean, например, то поставьте галочку using local SSD, чтобы использовать локальные диски, а не какие-то там через сеть, и вот тогда всё с базой данных будет OK.

Более-менее по производительности, но без гарантии (этот вариант нативно поддерживает Kubernetes) это когда мы просто берём, грубо говоря, прокидываем диск сервера в контейнер. Мапим папочку прям. У нас на сервере могут быть SSD, и мы SSD внутрь контейнера и получаем. Минус в том, что мы тем самым прибиваем базу данных к этому серверу. Спрашивается, зачем мы запускаем её в Kubernetes, если что случись, она там и сдохнет. Ну и лежала бы на своём монолитовском сервере.

И дёшево, и круто это собственная СХД, которую построил и поддерживает какой-то бородатый админ. При этом он ещё должен вывести уровень производительности этой СХД на такой уровень, чтобы она сравнялась как-то с SSD. Первое, что приходит в голову, это Ceph. Но пока мы делали курс по Ceph, пообщались с теми, кто много с этой технологией работает, они сказали: Не, чувак, там столько костылей, что это всё равно придётся закрывать мощностями оборудования. То есть такого нет.

Вот такие варианты: даже не 2 стула, а 4 выбирай, куда садиться. Если у вас возникает вопрос: Могу ли я запустить базу данных в Kubernetes?, значит, конкретно вы не можете пока.

В Kubernetes есть чарты (charts) и хельм (Helm), что это такое?

Сначала расскажу, как возникла потребность в их создании. Вот у нас есть кластер, всё хорошо, но мы его поднимали не просто так, а чтобы запустить приложение.

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

Манифесты это yaml-файлики, которые отвечают за самые разные абстракции. В том числе сам под (Pod), хотя это будет не под, а абстракция, которая называется либо Deployment (именно в ней запускают приложение), либо StatefulSet (если это stateful-приложение), либо DaemonSet, ну неважно. К нему добавляется абстракция типа Service внутренний кубернетский балансировщик. К нему же добавится абстракция Ingress внешний балансировщик. Там же ещё могут быть PV/PVC короче, много всего.

Когда мы приложение разрабатываем, нам надо сделать какой-то релиз. Что-то поменялось в приложении, что-то поменяться могло в манифестах. Например, версия image была 2, стала 3. Нам придётся каждый раз ходить в репы и менять руками 2 на 3. Таких реп может быть сотни, и осталось только не забыть везде нужное поменять. В этот момент типичный админ задумывается об инструментах, которые позволяют менять все файлы внутри папки с одного паттерна на другой. И в принципе, это будет работать.

Только проблема в том, что это решение kubectl based, то есть всё равно весь вот этот вывод, который мы в папке перелопатили, мы через пайп отправляем в kubectl. Говорим: kubectl, вот теперь всё, что у нас есть новое в папке, отправляй в кластер. И это тоже будет работать. Но если что-то пойдёт не так (циферку не ту поставили или приложение просто не поднялось), нативного способа откатиться через kubectl нет. Там есть команда kubectl rollout undo, но она работает только с deployment, а у нас могут быть и другие абстракции, с которыми она не работает. И тут возникает вопрос, а как откатываться? Потому что шаблонизация вроде более-менее понятна, да и шаблонизаторов много всяких (и Kustomize, и json.net), но как откатываться большой вопрос.

Явный ответ на это дает Helm, потому что у него из коробки есть возможность cделать rollout, то есть откат, в случае, если какие-то есть проблемы. Работает он достаточно просто. Он все манифесты из папки, что мы нагенирировали, сохраняет в артефакт. Например, в config какой-то. Прям вот как оно есть, так и сохраняет подряд. Назвал его артефакт версия 1, сохранил в кластер. Потом мы выпустили новый релиз. Он ага, артефакт версия 2. И вот так они копятся. Потом мы выкатили новый релиз, какой-нибудь версии 9, и поняли, что это не то. Он говорит: Ок, у меня есть версия 8, достает все манифесты оттуда и фигачит в кластер.

Возвращаясь к вопросу, как вменять всё, когда этих манифестов становится за сотню и просто невозможно в голове удержать, что где поменять. Тогда на помощь приходят шаблонизаторы, темплейтирование и Helm это тоже умеет. Набор темплейтированных манифестов называется Chart.

Ты уже не раз говорил про stateful и stateless приложения. Разработчикам эти термины знакомы. И понятно, что со stateless просто: развернул и не паришься. Есть какие-то особенности разворачивания stateful приложений? И что для этого используется внутри Kubernetes? Какие-то может быть особенные штуки для хранения состояния приложения? Как оно хранится? Где оно хранится?

Сам по себе Kubernetes никакого решения не предоставляет. Нет внутренней системы хранения данных. В любом случае нужно использовать стороннее решение. Сейчас появился CSI Driver, и стало проще.

CSI Driver это ещё один интерфейс, который позволяет унифицировать подключение внешних инструментов. Как есть Container Runtime Interface, который не только Docker может подключить, но всё, что CRI поддерживает, так и CSI может подключить всё, что его поддерживает. Технология не так давно вышла в прод, развивается и допиливается, но в целом это хороший шаг. Остаётся подключить, например, Ceph как систему хранения данных и через абстракции Kubernetes запрашивать диски или файловые системы в этой СХД и подключать себе. То есть по сути приложение будет работать с этой СХД, а Kubernetes будет в роли посредника.

А до появления этого механизма в Kubernetes нельзя было разворачивать stateful приложения?

Можно было. Есть такая штука, как storage class. Это ещё одна абстракция, и там это всё настраивается. Скажем так, объём тех решений, которые можно применять в Kubernetes, будет расти. Уже есть всякие облачные хранилища, которые можно подключать, и множество всего другого.

Как построен механизм безопасности всего процесса поднятия, слежения за твоими приложениями? Общение наверняка ведётся по https, но есть ли ещё что-нибудь? Что, например, будет, если API Kubernetes завладеет злоумышленник? Как этого избежать?

Не открывать API наружу! Достаточно просто.

А как не открывать? Выстраивать приватную сеть?

Ну да, VPN, двухфакторная авторизация что-нибудь такое. API нужно закрывать очень хорошо, потому что каждый год находят уязвимости. В 2018 году, например, обнаружили критическую уязвимость с индексом 9,8, если я не путаю. Она позволяла поднять привилегии в API, и всё делай, что хочешь. Были уязвимости в 2019 году. Мне запомнилась возможность подменять файлы на хосте через контейнер.

И всё это можно сделать, если авторизоваться в API. Естественно, API не дураки писали, и там есть аутентификация, тот же самый TLS, просто так ничего не сделаешь. Но уязвимости бывают, поэтому API надо всеми возможными способами закрывать.

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

Например?

Глобально можно посмотреть в первую очередь как раз с точки зрения уязвимостей, получения прав и так далее. Решение закрытие API. Если Kubernetes развёрнут не в облаках, а на своих виртуалках, то надо регулярно обновлять свои сервера. Про iptables и SSH наружу, я думаю, говорить не надо. Это общие и достаточно банальные требования, но их надо выполнять. Kubernetes не панацея, это дополнительный слой абстракции. Сверху намазали, и за этим теперь тоже надо как-то следить.

Второй аспект безопасности это уровень привилегий пользователей. В Kubernetes это хорошо сделано. Есть так называемый Role Based Access Control или RBAC сокращенно. Мы можем разграничить пользователей по тому, какие действия им доступны: ты можешь работать только здесь, а ты только здесь. Но там есть достаточно простые хаки, которые позволяют это всё очень легко обойти.

Например, в Kubernetes есть namespace пространство имен. Условно, у нас есть Kubernetes, есть два namespace: стейджинг и продакшн. В стейджинг мы пускаем разработчиков, они там работают, но мы им не даем что-то править на проде. В прод ходит только CI/CD. Но просто имея возможность запускать свои приложения хоть где и ничего больше, я могу за 2 минуты стать админом кластера. Я запущу под (Pod), которого отправлю на запуск на master, где у нас находятся все доступы и креды, и подмонтирую их себе в контейнер. Потом я посмотрю токены, скопирую себе на компьютер и стану админом.

Это такая штука, о которой не все задумываются. Но эту штуку тоже уже прикрыли. Есть инструмент Pod security policy, который позволяет чётко сказать, какие поды и где и как могут запускаться, какие порты могут использовать.

Ещё один аспект безопасности касается работы нескольких команд в Kubernetes. Особенно, если есть на аутсорсе команды, которые пишут свою часть приложения. По умолчанию, любой человек с доступом в namespace может постучаться во все эндпоинты (endpoints), которые есть. Прикрыть это позволяет Network policies. Это своего рода firewall внутри кластера. Когда мы внешнюю команду к себе зовём, мы спрашиваем, к каким эндпоинтам она должна иметь доступ, чтобы взаимодействовать с приложением, и только эту часть открываем. В основной кластер они зайти не могут.

Если говорить про безопасность, то в Kubernetes есть ещё одна интересная штука защита от человеческого фактора. Известно много громких факапов, произошедших по вине человека (история с GitLab, когда они положили пол своего продакшена, с Yandex.Cloud и другими компаниями). Прод базу данных снёс и оказалось, что в шести местах бэкапов нет или они неконсистентные, и случайным образом где-то там дампик лежал несколько часовой давности и типа: Ух! (перекрестился) Слава Богу! Восстановили!

Чтобы этого избежать, в Kubernetes тоже есть инструменты. Например, limit ranges, resource quotas. Они позволяют держать в узде тех, кто работает с Kubernetes. Например, не дают заскейлить свое приложение в какое-то очень большое количество. А такое один раз было. Коллега рассказывал: админ хотел поставить единицу. Клавиша залипла, интернет лагнул, вместо одного раза он нажал несколько и всё. Правда, это было не на Kubernetes, а на Nomad. Но факт такой, что он: Вам надо 111 млн приложений? Хорошо. Сейчас будет! И всё начало лагать, естественно. Чтобы этого избежать, мы можем сказать: Здесь максимум 10 реплик, и всё.

Ты упомянул Nomad. Какие ещё есть аналоги Kubernetes?

Самый яркий аналог, про который все говорят, это Docker Swarm. Docker Swarm это разработка от Docker, их нативное решение. Не требует никакой дополнительной установки: переходим в swarm-режим, и у нас появляется возможность Docker Swarm.

Docker Swarm это тоже оркестратор, поэтому многие сравнивают его с Kubernetes. Но если говорить глобально, то Kubernetes это более мощный комбайн, в нём больше возможностей. В Docker Swarm их чуть поменьше, но я бы сказал так: если у вас супертребований нет, то можно пользоваться и Docker Swarm. Но в отличие от него, Kubernetes, например, хорошо умеет автоскейлить. Причем, как ноды автоскейлить, заказывать, так и поды, то есть реплики приложений. В облаках это работает вообще шикарно. Пришла нагрузка с рекламной кампании мы не сидим, не заказываем руками, а он сам сходил и заказал. Когда нагрузка ушла, он обратно их схлопнул до нужного количества.

На каких операционных системах обычно запускается Kubernetes?

Ну обычно на Linux: CentOS, Debian.

А на винде умеет?

Они делают сейчас движение в сторону Windows. В принципе, стало лучше, но я бы сказал, что не надо пока этого делать.

Какими навыками нужно обладать, чтобы успешно работать с Kubernetes? Программирование, может, какое-то нужно? YAML, понятно.

Знание YAML, некоторое понимание, как работает контейнеризация Я не знаком лично, но слышал о таких людях, которые не имеют базового бэкграунда, но с Kubernetes работать умеют. Они могут налажать с сетью, например, но при этом с Kubernetes работают.

Я бы добавил, что нужны базовые знания по сетям, по Linux (если Kubernetes будет запускаться на Linux-машинах, их надо будет тюнить) и умение читать документацию.

В каких случаях Kubernetes вообще не стоит использовать?

Не стоит использовать, если рассчитываете, что поставите его, и все вопросы решатся. К внедрению надо подходить системно, и ставить Kubernetes только тогда, когда есть реальная необходимость.

Есть ещё ситуация Kubernetes ради зарплаты. Это когда технический специалист зашёл на Хедхантер, посмотрел на зарплаты, и пошёл пропихивать это решение в компании, чтобы потом попросить повышение: Я же теперь специалист по Kubernetes, платите мне больше. Это вряд ли к чему-то хорошему приведёт.

С технической точки зрения Kubernetes не нужно применять для приложений, которые не удовлетворяют 12 факторам. Для приложений, которые неправильно работают на уровне микросервисов, которые не допилены до конца. В одном из проектов мы пилили и переносили, пилили и переносили, и это было сложно, потому что часть проекта работала в Kubernetes, а часть продолжала работать на монолите и надо было выстраивать взаимосвязь.

В идеальном мире, конечно, Kubernetes ставится сразу же Сначала приложение готовится, потом уже туда. Но чаще всего нет.

Переходя к следующему блоку, спрошу: в чём различие Kubernetes и Ansible?

Ansible это, в первую очередь, система управления конфигурацией. Kubernetes это оркестратор контейнеров.
Знание Ansible не будет лишним, когда вы начнёте работать с Kubernetes, и наоборот. Потому что Kubernetes нужно как-то управлять, и Ansible для этого хорошо подходит.
Если мы говорим, что Kubernetes это Infrastructure as code (IaC), то вот этим IaC нужно как-то управлять. Руками туда лезть? В идеальном мире не лезут, всё прогоняют через пайплайны: надо что-то сделать в Kubernetes запускаешь плейбук он пошёл сам сделал. Поэтому знание Ansible и Kubernetes, наверное, важны в равной степени.

Далее отвечает Николай Месропян

Что такое Ansible и для чего он нужен?

Это средство управления конфигурациями. Для чего нужно? Когда у вас один сервер, им можно управлять руками: просто ходить на него, набирать команды или тыкать мышкой, что-то руками править, настраивать. Если их 2, 10 это ещё реально. Но в конце концов серверов может стать и 20, и 100, и 1000. Вот тогда возникает необходимость управлять ими более автоматизированно и централизованно.

Мы говорим про управление конфигурациями операционной системы или вообще любыми? Я задеплоил 25 приложений разных на хост, и я хочу

Обычно я начинаю рассказ про Ansible и свой курс с концепции, которая называются питомцы и стадо Pets vs Cattle. Pets это питомцы. Ты за ними ухаживаешь, лечишь, даёшь им уникальные имена. Cattle это стадо. Если кто-то заболевает, ты его забиваешь и создаешь вместо него новый сервер. У тебя их очень много, и ты их в лицо не знаешь, а знаешь только по номерам. Питомцы превращаются в стадо, когда их становится много.

Но когда они заболевать начинают!

Когда они заболевают, это жесть, я согласен. И чтобы с этим стадом управляться, создана система управления конфигурациями. Да, разумеется, она используется и для деплоев приложений, но начинаем мы обычно с системы управления конфигурациями, операционной системой на наливке каких-то приложений, конфигурирования их в том или ином порядке оркестрацией как бы.

Jenkins вроде как тоже кроме того, что поддерживает пайплайны, умеет конфигурировать приложения. Это в чём-то похоже на Ansible?

Нет, это совершенно разные вещи. Ansible похож на Chef, Puppet, SaltStack. Jenkins больше похож на GitLab CI и TeamCity. Это совершенно разные классы программного обеспечения для разных целей, но они могут работать вместе.

Я встречался с решениями, когда через пайплайн на GitLab CI производился деплой приложений посредством приложения, использующего внутри себя Chef.
Сам я писал пайплайны для GitLab CI на Ansible. То есть они вместе работать могут. Иногда и просто должны.

Из чего состоит Ansible, и как он вообще работает? Это какое-то приложение над приложениями или отдельный сервер, что это вообще?

Cначала расскажу про ПО для управления конфигурациями. Расскажу, чем они друг от друга отличаются, и потом перейдём конкретно к Ansible.

ПО для управления конфигурациями можно разделить на два основных класса: pull и push.
Когда работает система принципа pull, на клиентских хостах, то есть на управляемых хостах, выполняется некий daemon (сервис), который подтягивает конфигурацию с центрального репозитория и на месте уже её раскатывает.

push это когда управляющий процесс выполняется на одном центральном сервере, а на конечные ноды доезжают только конечные изменения (по сети). То есть конфигурирование производится не на месте, а по сети.

По сети SSH, FTP?

Как правило, SSH. Вот Ansible относится именно к push. На центральном сервере выполняется процесс, который использует конфигурацию, чаще всего хранящуюся в репозитории.

Зачем вообще нужен pull, если push выглядит достаточно красиво и ненапряжно?

Push медленный.

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

При модели push центральный процесс каждый раз идёт к ноде по SSH, что-то там делает, возвращает результат, здесь он оценивается, и всё это повторяется.

Тогда чем push лучше pull?

На конечных нодах не хранится никакой конфигурации, что называется нулевой footprint (след).

Бывает важно, чтобы на клиентских машинах никто не мог понять, как и что конфигурируется. Расскажу про нашу компанию, Southbridge. У нас аутсорсинг, множество клиентов, и информация под клиентов хранится в репозитории. Потому что мы не хотим, чтобы клиент мог своими руками что-то подкрутить и сломать. Он может сделать это без злого умысла, просто: Программист сказал, что можно сделать так, давай-ка сделаем! А потом раз продакшн снесся, и он приходит к нам: У вас все плохо работает!

В действительности таких случаев у нас не было, когда мы использовали pull-системы. Но тем не менее. К тому же лучше подстраховаться, чтобы конфигурация одних клиентов не попала каким-то другим. Именно поэтому мы используем push.

Плюс нам понравилась сама парадигма, что всё лежит в одном месте. Сами клиентские процессы иногда написаны на тяжёлых языках (Ruby, например) и тоже подъедают системные ресурсы: и память, и процессор. Поэтому это в каких-то случаях может быть нежелательным.

А клиентские ПО, клиентские ресурсы, которые в push работают, они пишутся руками или есть готовые какие-то решения?

Вот теперь я могу рассказать, из чего Ansible состоит (без слайдов и доски сложно, но попробую объяснить на пальцах).

Для Ansible мы пишем конфигурацию, состоящую из сущности под названием плейбуки (playbook), ролей и инвентаря. Плейбуки и роли это определение конфигурации. Инвентарь это параметризация.

Плейбук это файл, состоящий из набора так называемых плеев (play).
Сразу скажу, что вся конфигурация пишется на YAML. Ansible написан на Python, поэтому для него родной язык разметки YAML.

Ansible, если что, лучше всего ставить в virtualenv, чтобы быть независимым от мейнтейнера
А, да, начнём с того, где Ansible работает: управляющие хосты поддерживаются только Linux.

А если это виртуалка?

Всё равно. Всё-таки используются системные вызовы, и чтобы не адаптироваться, в качестве управляющего хоста поддерживается только Linux. Управлять можем Linux-системами, Windows-системами и Mac OS. Но для Mac, насколько я знаю, оно пока в зачаточном состоянии.

Android, мобильные платформы?

Наверняка что-то есть, но пока оно большого распространения не получило.

У нас выполняется центральный процесс, который этот плейбук читает.

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

Если совсем примитивно, с помощью Ansible можно сделать на хостах всё то же, что мы делаем руками, только автоматизировано, массово, детерминировано и т. д. Поэтому элементарный task или элементарная задача это выполнение какой-нибудь команды, например. Но чаще всего используются специализированные модули: для шаблонизации файлов, для запуска сервисо

А команды это просто команды консоли или?

Да, есть такой модуль command, который просто выполняет консольную команду.

Он на клиенте?

На клиенте, да.

А почему нельзя просто через SSH напрямую в терминал фигачить?

Модуль command это последний шанс, если у тебя нет специализированного модуля для выполнения определённой задачи.

Чтобы запустить сервис, мы не делаем command systemctl start engine, мы используем модуль service или модуль systemd, который приводит систему, в данном случае сервис, в заданное состояние. То есть он запущен и включён либо остановлен и выключен.

Вообще, управление конфигурациями задумывалось как декларативное. То есть мы описываем желаемое состояние системы, потом эта самая управлялка приводит систему в заданное состояние. Если система уже находится в нужном состоянии, то не производится никаких действий. Это свойство называется идемпотентность.

Понятно, в не зависимости от того, сколько раз ты запускаешь

Результат всегда один и тот же.

Это прям как в REST API, разработчикам должно быть понятно.

Да!

Поэтому мы описываем в задачах желаемую конфигурацию и Ansible приводит (если это грамотно написано) систему в заданное состояние. Если система уже в заданном состоянии, то действие не производится. Потом мы в выводе команды всё это видим.

Что такое роли? Роли можно уподобить подключаемым библиотекам. То есть мы пишем роль, которая, допустим, настраивает веб-сервер nginx, и потом из разных плейбуков для разных хостов с разными параметрами мы эту роль подключаем.

Роли могут храниться как на диске вместе с плейбуками конфигурации, так и во внешних репозиториях. Есть такая штука, называется Ansible Galaxy это что-то вроде центрального хранилища ролей. Туда можно свою роль подать на рассмотрение. Это не то чтобы пакетный менеджер, а как GitHub, допустим. Только специализированный, исключительно для Ansible.

То есть роли это готовые куски конфигураций, которые ты можешь у себя встраивать и переиспользовать?

Это описание конфигурации, которому ты можешь сам задавать разные параметры из инвентаря.

Отлично. И тут включается механизм параметризации?

Да. При запуске команды ansible-playbook, которая и делает нужные изменения на хостах, мы задаём ей параметром так называемый инвентарь откуда брать параметры. В инвентаре у нас чаще всего список хостов, объединенных в группы (чтобы Ansible знал, на каких хостах выполнять те или иные задачи), и набор переменных для них, которые подставляются в роль и меняют поведение в нужную сторону.

Jinja2 это из этой темы?

Jinja2 это весьма мощный язык шаблонизации. Jinja2 используется в ролях.

Это параметризация, как я понимаю, нет?

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

Как гарантировать, что твой конфиг работоспособный, что он не устарел, не сломался вдруг на сервере что-то поменялось, и у тебя команда ansible-play не сработала. Это как-то тестируется?

Да, разумеется, это тестируется.

В правильно построенной инфраструктуре мимо Ansible и вообще любого средства управления конфигурациями ничего меняться не должно. То есть никто не должен ходить руками и там что-то делать и настраивать. Если он это делает, то за это нужно по рукам бить. Потому что правильный подход это вносить нужные изменения в инвентарь. Если в используемых ролях нет нужных действий, ты дописываешь.

Это подход инфраструктура как код (Infrastructure-as-Code, IaC). Код в каком смысле? Код должен проходить ревью, то есть твои коллеги должны видеть, что ты написал и подтвердить, что это вменяемо.

Речь про конфигурации?

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

Рядом с продуктовым кодом? Или это отдельная репа?

Разумеется, отдельная. Это много реп чаще всего. И потом перед тем как что-то изменить, ты делаешь merge request с изменениями (в зависимости от того, какая схема у вас в компании принята). В простейшем случае пишешь в телегу коллеге: Вот, я написал, посмотри и кидаешь ссылку. Он говорит: Всё нормально, идём на тестирование.

Раз инфраструктура как код, у нас код проходит пайплайн. Всегда самый первый или второй job это lint. Команда ansible-lint просматривает код на синтаксические ошибки и дает дельные советы. Если ты ставишь пакет, вызывая его как command "yum" или "apt-get" install, то тебе линтер напишет: Используй специализированный модуль yum или apt. То есть тут не только синтаксические ошибки, но и семантика.

Разумеется, кроме проверки синтаксиса, есть инструмент полного тестирования. Потому что синтаксический анализатор не знает общего замысла твоего плейбука и не может знать, что будет в конце, идемпотентна данная конфигурация или нет. Есть такой инструмент, называется Molecule. Она запускает виртуальную машину...

Главный вопрос: не на проде же ты это будешь делать?

Да, разумеется, запускается виртуалка, в ней согласно описанной для Molecule конфигурации запускается Ansible плейбук.

А где гарантия, что виртуалка похожа на прод?

Надо самому следить.

Продакшн у нас же изначально чистый, как я понимаю?

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

А по ресурсам она тоже должна быть такая же, как прод, или необязательно?

Это зависит от конкретного случая. Если после запуска Molecule ты тестируешь ещё что-то с помощью каких-то внешних инструментов Условно говоря, выкатываешь сайт, тестируешь Selenium (такое тоже бывает), то, естественно, ресурсов должно быть больше. Если он у тебя просто проходит набор ролей, то ресурсов нужно ровно столько, чтобы этот Python в память влез.

Тебе как человеку, который работает с Ansible, нужно программирование? Ты говорил, язык разметки YAML, написан на Python, нужно ли дописывать какие-то модули, ещё что-то. Просто, чтобы понимали девелоперы: нужно ли владеть языком при работе с Ansible?

Можно не владеть. Но лучше владеть.

Каким и для чего?

Python. Потому что, если под конкретную задачу нет нужного модуля, конечно, можно написать это всё в виде скрипта и дёргать его из task, но это плохой тон, это называется bashsible в комьюнити, связанных с Ansible. И это прям фу-фу.

Чаще советуют написать специализированный модуль под свою задачу. Его можно написать на Shell, да и вообще на любом языке, потому что там просто система вызовов, но лучше всего писать на нативном для этого дела.

Нативном для Ansible, да?

Да.

Потому что можно на C попробовать это сделать.

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

Какие есть более или менее популярные аналоги Ansible? Или это монополист на рынке?

Нет, это, конечно, не монополист. Значительно более старые решения (в смысле прошедшие более длинный путь развития) это Chef и CFEngine. Последний сейчас уже мало используется.

Они все работают примерно одинаково?

Они работают в основном как pull: на настраиваемой ноде выполняется сервис, который тянет конфигурацию.

Ansible единственный, кто делает push из крупных?

Ansible умеет pull, но это не основной его режим работы. SaltStack тоже умеет push, но это не его основной режим работы. Ansible, можно сказать, в этом плане единственный. Ну и видимо, народу нравится, потому что я смотрю время от времени Google Trends по запросам, относящимся к Chef, к Ansible, и вижу, что Ansible набирает всё большую популярность. Более старых решения на пятилетнем промежутке её чуть-чуть теряют. Хотя есть энтузиасты, которые за них топят и их поддерживают.

Может, есть какие-то книги, что можно почитать, чтобы базово познакомиться с Ansible?

Знакомство с Ansible лучше всего начать с документации. На docs.ansible.com расписаны и самые основы, и примеры простых плейбуков, и вообще всё что нужно.
Я еще скажу про книгу Ansible: Up and Running. Книга неплохая, но Ansible достаточно быстро развивается и поэтому многие вещи в ней уже устарели. Поэтому лучше всего начинать именно с документации на сайте, она там всегда актуальна.

Вопросы задавал Лекс АйТиБорода iamitbeard

В продолжение прошлой статьи о KVM публикуем новый перевод и разбираемся, как работают контейнеры на примере запуска Docker-образа busybox.

BusyBox Docker

Clone

• CLONE_NEWNET изолированные сетевые устройства
• CLONE_NEWUTS имя хоста и домена (система разделения времени UNIX)
• CLONE_NEWIPC объекты IPC
• CLONE_NEWPID идентификаторы процессов (PID)
• CLONE_NEWNS точки монтирования (файловые системы)
• CLONE_NEWUSER пользователи и группы.

static char child_stack[1024 * 1024];int child_main(void *arg) {  printf("Hello from child! PID=%d\n", getpid());  return 0;}int main(int argc, char *argv[]) {  int flags =      CLONE_NEWNS | CLONE_NEWUTS | CLONE_NEWPID | CLONE_NEWIPC | CLONE_NEWNET;  int pid = clone(child_main, child_stack + sizeof(child_stack),                  flags | SIGCHLD, argv + 1);  if (pid < 0) {    fprintf(stderr, "clone failed: %d\n", errno);    return 1;  }  waitpid(pid, NULL, 0);  return 0;}

Рабочая оболочка

int child_main(void *arg) {  char **argv = (char **)arg;  execvp(argv[0], argv);  return 0;}

Chroot

int child_main(void *arg) {  /* Unmount procfs */  umount2("/proc", MNT_DETACH);  /* Pivot root */  mount("./rootfs", "./rootfs", "bind", MS_BIND | MS_REC, "");  mkdir("./rootfs/oldrootfs", 0755);  syscall(SYS_pivot_root, "./rootfs", "./rootfs/oldrootfs");  chdir("/");  umount2("/oldrootfs", MNT_DETACH);  rmdir("/oldrootfs");  /* Re-mount procfs */  mount("proc", "/proc", "proc", 0, NULL);  /* Run the process */  char **argv = (char **)arg;  execvp(argv[0], argv);  return 0;}

Сеть

system("ip link add veth0 type veth peer name veth1");system("ip link set veth0 up");system("brctl addif br0 veth0");

char ip_link_set[4096];snprintf(ip_link_set, sizeof(ip_link_set) - 1, "ip link set veth1 netns %d",         pid);system(ip_link_set);

int child_main(void *arg) {  ....  sethostname("example", 7);  system("ip link set veth1 up");  char ip_addr_add[4096];  snprintf(ip_addr_add, sizeof(ip_addr_add),           "ip addr add 172.16.0.101/24 dev veth1");  system(ip_addr_add);  system("route add default gw 172.16.0.100 veth1");  char **argv = (char **)arg;  execvp(argv[0], argv);  return 0;}

Вывод