It's Wednesday, my friends! 🆘

Пособирали разных статей, делимся подборкой.

▪️Гайд «GitHub to GitLab migration the easy way» — как перейти с GitHub на GitLab, используя функцию импорта проектов. Рассматривается и ручная миграция GitHub Actions в GitLab pipelines. Есть видео :)

▪️Статья «How to delegate tasks as a senior/lead engineer?» — как эффективно делегировать задачи членам команды. Забавные аналогии и жизненные ситуации прилагаются.

▪️Статья «Как я стал девопсом в городе, в котором есть только завод» — всегда интересно почитать про путь в профессию, особенно, когда у автора в моногороде два пути: на завод или в IT.

▪️Статья «Монолит или микросервисы — это не вопрос технологических предпочтений, это про time-to-market» — из названия все понятно, автор рассматривает вопрос монолит vs микросервисы через призму команд, их взаимодействия и интересов бизнеса.

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

Всем DevOps! 🖖

#статьи

В эфире — новости!

▪️На 15 августа 2023 года запланирован релиз Kubernetes 1.28. Ожидается 59 новых улучшений , из которых 33 — alpha, 19 — beta и 15 — stable. Подробное описание доступно в release notes (пока черновик).

▪️Состоялся релиз KubeVirt 1.0.0. Подробности — в release notes.

❓KubeVirt — это надстройка по управлению ВМ для K8s. Его цель — обеспечить общую основу для решений виртуализации поверх K8s. С помощью KubeVirt можно управлять ВМ как ресурсом K8s, подобно подам.

▪️В пятницу, 7 июля 2023 года, в инфраструктуре Jenkins произошел серьезный сбой с 11:05 UTC до 15:25 UTC, Jenkins выпустили Postmortem об этом инциденте.

*️⃣Писали про Postmortem здесь :)

▪️Компания Yandex Cloud проинформировала пользователей об ограничении доступности Managed service for Elasticsearch.

Действующие пользователи смогут работать с существующими кластерами и создавать новые до апреля 2024 года. Пользователи, которые пока не работали с Elasticsearch в облаке, не смогут создать кластеры сервиса с 20 июля 2023 года.

▪️Istio получили статус CNCF Graduated project. Первоначально Istio был разработан Google и IBM и построен на основе проекта Envoy от Lyft. В настоящее время в проекте участвуют более 16 компаний, в том числе многие крупнейшие поставщики сетевых услуг и облачные организации по всему миру. Istio — третий по активности проект CNCF по количеству открытых и смерженных PR.

❓Istio — инструмент конфигурации service mesh

#новости

Всем DevOps! 🖖

Начнем неделю с полезных советов: Три простых приема для уменьшения Docker-образов 💻

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

1️⃣ Объединяем несколько слоев в один с помощью поэтапной сборки Docker-образов

Когда Git-репозиторий разрастается, можно просто свести всю историю изменений в один commit и забыть о нем. Оказалось, что нечто подобное можно реализовать и в Docker — посредством поэтапной сборки.

Давайте создадим контейнер Node.js.

Начнем с index.js:

const express = require('express')
const app = express()
app.get('/', (req, res) => res.send('Hello World!'))
app.listen(3000, () => {
 console.log(Example app listening on port 3000!)
})

и package.json:

{
 "name": "hello-world",
 "version": "1.0.0",
 "main": "index.js",
 "dependencies": {
   "express": "^4.16.2"
 },
 "noscripts": {
   "start": "node index.js"
 }
}

Упакуем приложение со следующим Dockerfile:

FROM node:8
EXPOSE 3000
WORKDIR /app
COPY package.json index.js ./
RUN npm install
CMD ["npm", "start"]

Создадим образ:

$ docker build -t node-vanilla .

Проверим, что все работает:

$ docker run -p 3000:3000 -ti --rm --init node-vanilla

Теперь можно пройти по ссылке: http://localhost:3000 и увидеть там «Hello World!».

В Dockerfile теперь у нас есть операторы COPY и RUN, так что фиксируем увеличение как минимум на два слоя, по сравнению с исходным образом:

$ docker history node-vanilla

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

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]

Первая часть Dockerfile создает три слоя. Затем слои объединяются и копируются на второй и заключительный этапы. Сверху в образ добавляются еще два слоя. В итоге имеем три слоя.

Давайте пробовать. Сначала создаем контейнер:

$ docker build -t node-multi-stage .

Проверяем историю:

$ docker history node-multi-stage

Смотрим, изменился ли размер файла:

$ docker images | grep node-
node-multi-stage   331b81a245b1   678MB
node-vanilla       075d229d3f48   679MB

Да, он стал меньше, но пока не значительно. Есть способы уменьшить его сильнее.

*️⃣2 и 3 приемы будут чуть позже :)

#лонгрид

2️⃣ Сносим все лишнее из контейнера с помощью distroless

Текущий образ предоставляет нам Node.js, yarn, npm, bash и много других полезных бинарников. Также, он создан на базе Ubuntu. Таким образом, развернув его, мы получаем полноценную операционную систему со множеством полезных бинарников и утилит.

При этом они не нужны нам для запуска контейнера. Единственная нужная зависимость — это Node.js.

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

Таким образом, мы можем вынести из него все, кроме Node.js.

Но как?

В Google уже пришли к подобному решению — GoogleCloudPlatform/distroless.

Описание к репозиторию гласит:

Distroless-образы содержат только приложение и зависимости для его работы. Там нет менеджеров пакетов, shell'ов и других программ, которые обычно есть в стандартном дистрибутиве Linux.

Это то, что нужно!

Запускаем Dockerfile, чтобы получить новый образ:

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM gcr.io/distroless/nodejs
COPY --from=build /app /
EXPOSE 3000
CMD ["index.js"]

Собираем образ как обычно:

$ docker build -t node-distroless .

Приложение должно нормально заработать. Чтобы проверить, запускаем контейнер:

$ docker run -p 3000:3000 -ti --rm --init node-distroless

И идем на http://localhost:3000. Стал ли образ легче без лишних бинарников?

$ docker images | grep node-distroless
node-distroless   7b4db3b7f1e5   76.7MB

Еще как! Теперь он весит всего 76,7 МБ, на целых 600 Мб меньше!

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

$ docker exec -ti <insert_docker_id> bash

Подключение к работающему контейнеру и запуск bash очень похоже на создание SSH-сессии.

Но поскольку distroless — это урезанная версия исходной операционной системы, там нет ни дополнительных бинарников, ни, собственно, shell!

Как подключиться к запущенному контейнеру, если нет shell?

Самое интересное, что никак.

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

$ docker exec -ti <insert_docker_id> node

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

Тут надо бы оговориться, что подключать и отлаживать контейнеры на prod-окружении не стоит. Лучше положиться на правильно настроенные системы логирования и мониторинга.

Но что, если нам-таки нужен дебаггинг, и при этом мы хотим, чтобы docker-образ имел наименьший размер?

#лонгрид

3️⃣ Уменьшаем базовые образы с помощью Alpine

Можно заменить distroless на Alpine-образ.

Alpine Linux — это ориентированный на безопасность, легкий дистрибутив на основе musl libc и busybox. Но не будем верить на слово, а лучше проверим.

Запускаем Dockerfile с использованием node:8-alpine:

FROM node:8 as build
WORKDIR /app
COPY package.json index.js ./
RUN npm install
FROM node:8-alpine
COPY --from=build /app /
EXPOSE 3000
CMD ["npm", "start"]

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

$ docker build -t node-alpine .

Проверяем размер:

$ docker images | grep node-alpine
node-alpine   aa1f85f8e724   69.7MB

На выходе имеем 69.7MB — это даже меньше, чем distroless-образ.

Проверим, можно ли подключиться к работающему контейнеру (в случае с distrolles-образом мы не могли этого сделать).

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

$ docker run -p 3000:3000 -ti --rm --init node-alpine
Example app listening on port 3000!

И подключаемся:

$ docker exec -ti 9d8e97e307d7 bash
OCI runtime exec failed: exec failed: container_linux.go:296: 
starting container process caused "exec: \"bash\": 
executable file not found in $PATH": unknown

Неудачно. Но, возможно, у контейнера есть sh'ell…:

$ docker exec -ti 9d8e97e307d7 sh / #

Отлично! У нас получилось подключиться к контейнеру, и при этом его образ имеет ещё и меньший размер. Но и тут не обошлось без нюансов.

Alpine-образы основаны на muslc — альтернативной стандартной библиотеке для C. В то время, как большинство Linux-дистрибутивов, таких как Ubuntu, Debian и CentOS, основаны на glibc. Считается, что обе эти библиотеки предоставляют одинаковый интерфейс для работы с ядром.

Однако у них разные цели: glibc является наиболее распространенной и быстрой, muslc же занимает меньше места и написана с уклоном в безопасность. Когда приложение компилируется, как правило, оно компилируется под какую-то определенную библиотеку C. Если потребуется использовать его с другой библиотекой, придется перекомпилировать.

Другими словами, сборка контейнеров на Alpine-образах может привести к неожиданному развитию событий, поскольку используемая в ней стандартная библиотека C отличается. Разница будет заметна при работе с прекомпилируемыми бинарниками, такими как расширения Node.js для C++.

Например, готовый пакет PhantomJS не работает на Alpine.

Так какой же базовый образ выбрать?

Alpine, distroless или ванильный образ — решать, конечно, лучше по ситуации.

Если имеем дело с prod-ом и важна безопасность, возможно, наиболее уместным будет distroless.

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

Например, если злоумышленник смог найти уязвимость в приложении, запущенном на базе distroless-образа, он не сможет запустить в контейнере shell, потому что его там нет!

Если же по каким-то причинам размер docker-образа для вас крайне важен, определенно стоит присмотреться к образам на основе Alpine.

Они реально маленькие, но, правда, ценой совместимости. Alpine использует немного другую стандартную библиотеку C — muslc, так что иногда будут всплывать какие-то проблемы. С примерами можно ознакомиться по ссылкам: https://github.com/grpc/grpc/issues/8528 и https://github.com/grpc/grpc/issues/6126.

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

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

#лонгрид

Представляем nxs-data-anonymizer — удобный инструмент для анонимизации баз данных 🔥

И не просто инструмент, а open source инструмент компании Nixys! Поддерживает PostgreSQL (все версии) и MySQL/MariaDB/Percona (все версии).

Решение получилось достаточно гибким и простым в эксплуатации, и строится на следующих основных идеях:

⚙️ Потоковая обработка данных. Не обязательно предварительно готовить и сохранять где-то на диске дамп исходной базы. Инструмент может менять на лету данные, которые ему передаются на stdin. А выдавать всё — на stdout.

⚙️ Значения описываются Go template. То, на что вы хотите заменить нужные вам ячейки в таблице, определяется шаблонами как в Helm, который многим должен быть знаком.

⚙️ Использование условий и данных других ячеек в строке. Фильтры могут быть гибкими и делать те или иные подстановки в зависимости от значений других (или даже себя самого) ячеек в той же строке;

⚙️ Проверка уникальности данных.

Подробно рассказали про инструмент в статье на Хабре! Делитесь вашим мнением в комментариях :)

И, конечно, заходите в репозиторий — пользуйтесь инструментом, ставьте звездочки, оставляйте PR, рассказывайте коллегам 🦾

💻 Ссылка на GitHub

#open_source #статья_Nixys

Мы не договорили! 😁 Недавно делали подборку про Network Policy в Kubernetes, сегодня хочется сделать тематический день и рассказать про управление трафиком в Kubernetes-кластере с Calico.

Поехали! 💻

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

Помимо этого Calico добавляет свою политику GlobalNetworkPolicy. Она позволяет применять набор правил доступа по селектору не только для pod’ов, но и для групп хостов/контейнеров/pod’ов, и контролировать применение мер безопасности для различных цепочек путей трафика с помощью таких параметров, как preDNAT, doNotTrack и applyOnForward.

Задачу по обеспечению базовых принципов безопасности мы условно разделим на две:

1) на подзадачу по настройке взаимодействия между pod’ами

2) на подзадачу по настройке доступа к узлу в целом

Решить первую подзадачу можно при помощи такой сущности Kubernetes как NetworkPolicies и при этом можно расширить функционал данной сущности, если использовать её с api, предоставляемого Calico. Для решения второй подзадачи мы будем использовать сущность GlobalNetworkPolicy. По ходу дела так же будем анализировать детали и начнем с Zero Trust Networking.

Zero Trust Networking

Первое, что стоит учесть при написании сетевых политик, это то, что и Kubernetes, и Calico считают наилучшим подход Zero Trust Networking, то есть по умолчанию запросы из используемой сети всегда считаются враждебными.

Согласно данной концепции существуют следующие требования к контролю доступа:

* Правила применяются ко всем сетевым подключениям (не только к тем, которые пересекают границы защищаемой зоны).
* Идентификация удаленного endpoint всегда основана на нескольких критериях, включая надежные криптографические доказательства идентичности. В частности, идентификаторы сетевого уровня, такие как IP-адрес и порт, сами по себе недостаточны, поскольку могут быть подделаны враждебной сетью.
* Все ожидаемые и разрешенные сетевые подключения явно указаны в белом списке. Любое соединение, явно не занесенное в белый список, отклоняется.
* Трафик от скомпрометированных workload (pod/VM/container) не должен иметь возможности обойти применение сетевых политик.

Во многих Zero Trust Networks также реализуется шифрование всего сетевого трафика. Это не является обязательным требованием (если речь идет не о передаче приватных данных), но для соответствия критериям Zero Trust Networks шифрование должно использоваться для каждого сетевого соединения.

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

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

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

*️⃣1/6: продолжение следует :)

#лонгрид

Из чего состоит Calico

Кратко рассмотрим основные компоненты Calico. Как вы уже, наверное, поняли, Calico — это не один демон, который запущен на каждом хосте, где он управляет сетью, Calico состоит из нескольких элементов, так же как и Kubernetes. В целом он состоит из трех (иногда четырех) компонентов.

Felix

Основной компонент — это демон Felix, он отвечает за построение логики взаимодействия между сетевыми интерфейсами на хосте, и, как уже было сказано выше, за создание и функционирование endpoint на хостах или ВМ. В целом он выполняет следующие функции:

* Управление сетевыми интерфейсами, их создание, проверка их работоспособности и настройка пересылки трафика для управляемых интерфейсов.
* Программирование маршрутизации трафика через FIB (Forwarding Information Base) ядра Linux.
* Программирование ACL на уровне ядра Linux.
* Уведомления о статусе сети, Felix записывает данные о проблемах и ошибках в etcd.

Плагин для оркестратора

В зависимости от того, какой оркестратор вы используйте (например, OpenStack, Kubernetes) Calico предоставляет определенный плагин для наиболее эффективного взаимодействия с оркестратором. В случае Kubernetes — это CNI plugin.

etcd

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

BGP клиент (BIRD)

Calico разворачивает клиент BGP на каждой ноде, на которой размещен Felix. Роль клиента BGP заключается в том, чтобы считывать настройки маршрутизации, которые Felix создает на уровне ядра, и распространять на другие ноды обслуживаемой сети, то есть рассылать на другие клиенты.

BGP повторитель для правил маршрутов (BIRD)

В случае, когда обслуживаемая Calico область достаточно велика при наличии только BGP клиента могут возникнуть проблемы, так как он требует чтобы каждый клиент мог соединиться с каждым клиентом, что может порождать слишком большое количество соединений(N ^ 2). В таких случаях для решения проблемы можно использовать повторитель маршрутов, то есть соответственно настроенный BIRD. Он занимается тем, что, если клиент BGP сообщает ему какую-либо информацию об изменении в маршрутах, он распространяет эту информацию для других BGP-клиентов.

Network Policy

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

Ресурс сетевой политики NetworkPolicy представляет собой упорядоченный набор правил, которые применяются к группе endpoints, соответствующих селектору меток (labels).

Простой пример из официальной документации:

apiVersion: projectcalico.org/v3
kind: NetworkPolicy
metadata:
  name: allow-tcp-6379
  namespace: production
spec:
  selector: role == 'database'
  types:
  - Ingress
  - Egress
  ingress:
  - action: Allow
    protocol: TCP
    source:
      selector: role == 'frontend'
    destination:
      ports:
      - 6379
  egress:
  - action: Allow

Здесь мы разрешаем трафик с подов/контейнеров, у которых есть селектор role == 'frontend' на порт 6379 для доступа к БД.

*️⃣2/6: продолжение следует :)

#лонгрид

Host Endpoint

У каждого хоста (ноды) есть несколько реальных или виртуальных сетевых интерфейсов, с которыми взаимодействует Calico. Чтобы получить возможность применять политики конкретно к определенному интерфейсу необходимо создать для него сущность HostEndpoint. Они могут иметь метки (labels) и эти метки аналогичны меткам для pod’ов, поэтому сетевые политики в равной степени могут применяться и к HostEndpoint, и к endpoints pod’ов.

Предположим, что нам нужно запретить весь входящий трафик из внешней сети, кроме портов 22, 80, 443 на уровне хоста и при этом разрешить весь трафик от других нод кластера. Для этого, для начала, создадим для каждой ноды свой HostEndpoint. К примеру:

apiVersion: projectcalico.org/v3
kind: HostEndpoint
metadata:
  name: node4-ens160
  labels:
    type: production
role: worker
        node: 4
spec:
  interfaceName: ens160
  node: k8s-s4
  expectedIPs:
  - 10.213.0.11
ports:
 - name: http
   port: 80
   protocol: TCP
 - name: https
   port: 443
   protocol: TCP

В данном случае мы добавили также раздел ports, где описали определенные порты и протоколы для взаимодействия с ними. Мы сделали это для того, чтобы обозначить их и дать им названия (http, https), которые в дальнейшем можно использовать в сетевых политиках. interfaceName — название внешнего интерфейса сервера которому соответствует IP-адрес expectedIPs. Указывать порт 22 нет необходимости, так как он разрешен на уровне конфигурации Felix.

Global Network Policy

Теперь, когда почти весь трафик к ноде заблокирован, создадим GlobalNetworkPolicy, которая разрешит весь трафик с других нод кластера, входящий трафик на порты 80/443 и весь исходящий трафик для этого HostEndpoint:

kind: GlobalNetworkPolicy
apiVersion: projectcalico.org/v3
metadata:
  name: allow-s4
spec:
  selector: role==worker
  order: 10
  applyOnForward: true
  types:
  - Egress
  - Ingress
  ingress:
  - action: Allow
    protocol: TCP
    source:
      nets:
            - 10.213.0.0/24
  - action: Allow
    protocol: TCP
    destination:
      ports: [http,https]
  - action: Allow
    protocol: ICMP
  egress:
  - action: Allow

В целом, все параметры GlobalNetworkPolicy аналогичны NetworkPolicy и интуитивно понятны. order — очередность применения политики, чем она меньше, тем раньше будет применено правило.

Однако, для GlobalNetworkPolicyесть несколько интересных параметров, которые предоставляют дополнительные возможности для настройки политик, а именно: preDNAT, doNotTrack и applyOnForward, рассматриваемые ниже.

*️⃣3/6: продолжение следует :)

#лонгрид

Опции applyOnForward, preDNAT и doNotTrack

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

applyOnForward

Параметр applyOnForward отвечает за то, применяется ли данная политика к трафику, который проходит по цепочке iptabels FORWARD. Например, трафик, направленный к pod’у. Так как pod является внешним ресурсом с точки зрения сети хоста (не считается локальным процессом), следовательно, трафик до него проходит по маршруту цепочек PREROUTING – FORWARD – POSTROUTING.

Если applyOnForward имеет значение false, GlobalNetworkPolicy к трафику для локальных workload (контейнер/pod/ВМ, которые имеют свои виртуальные интерфейсы) не применится. Она будет применяться только к трафику для локальных процессов и к трафику, исходящему от них. Пример приведу далее.

Если applyOnForward имеет значение true, GlobalNetworkPolicy также применяется к перенаправленному (forwarded) трафику, такому как:

* Трафик, который поступает через HostEndpoint и перенаправляется в локальные workload.
* Трафик из локальных workload, который перенаправляется черезHostEndpoint.
* Трафик, который поступает черезHostEndpointи пересылается на другой HostEndpoint.

По умолчанию applyOnForward имеет значение false. Для политик, использующих опции doNotTrack и preDNAT, для свойства applyOnForward должно быть установлено значение true, поскольку эти политики применяются ко всему трафику, проходящему через FORWARD.

По умолчанию пересылаемый трафик (FORWARD)разрешен, если к пункту его назначения или направлению не применены какие-либо политики. Иначе говоря: если у вас настроен HostEndpoint, но нет политик с параметром applyOnForward: true для этого HostEndpoint или направления трафика, то пересылаемый трафик будет разрешен. Если существуют политики applyOnForward:true, в которых упоминаются селекторы HostEndpoint или это направление, но никакие правила в политиках не разрешают трафик, трафик отклоняется.

Пример: вы создаете GlobalNetworkPolicy, разрешающую исходящий трафик по протоколу ICMP для данного HostEndpoint с applyOnForward:false. В этом случае, если вы попытаетесь сделать ping 8.8.8.8 из pod’а на данном хосте, вам это удастся, так как forwarded трафик по умолчанию разрешен, хотя GNP применилась только к локальному трафику. Но. Если вы создадите ещё одну политику для этого HostEndpoint, но уже с applyOnForward:true, например, вы разрешаете весь TCP-трафик, то ping 8.8.8.8 изнутри пода не пройдет. Потому что уже существует политика с applyOnForward:true для этого типа трафика (этого HostEndpoint) и этот тип трафика явно не разрешен.

preDNAT

Данная опция отвечает за то, применяется ли политика до прохождения через DNAT (Destination Network Address Translation) или нет.

Это может пригодится, например, если вы используйте NodePorts и хотите контролировать трафик, который приходит извне на эти порты. После того, как трафик извне приходит на NodePort его распределение по факту происходит при помощи DNAT (kube-proxy). Следовательно, для того, чтобы применить политику к трафику, приходящему на NodePort, preDNAT должен быть установлен в true.

Ключевые особенности для таких политик следующие:

* Политики с опцией preDNAT могут иметь правила только для входящего трафика, но не исходящего.
* Политика применяется для всего трафика, проходящего через host endpoint, не только к процессам на хосте, но и к локальным workload (pod/VM/container).
* По умолчанию весь preDNAT трафик разрешен. То есть если существует HostEndpoint, но для него нет preDNAT политик, для него не действует правило “отбрасывать все по умолчанию”.

*️⃣4/6: продолжение следует :)

#лонгрид

doNotTrack

Опция doNotTrack позволяет отключить отслеживание (conntrack) трафика, который попадает под данную политику, причем именно для локальных процессов хоста (не pod / VM / container).

conntrack — это опция ядра из сетевого стека Linux, которая помогает ему отслеживать сетевые потоки, чтобы была возможность обрабатывать пакеты из одного потока одинаково, на основании правила обработки выбранного для первого пакета из потока.

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

* Если вам необходимо одновременно обрабатывать активных соединений больше, чем установленное значение в таблице conntrack (больше 128k по умолчанию).
* Если вам необходимо обрабатывать большое количество коротких соединений в секунду. Так как даже после завершения соединения conntrack продолжает отслеживать соединение в течении некоторого времени (по умолчанию 120с). Например, если в таблице conntrack установлено значение на 128к доступных подключений, и вы пытаетесь обрабатывать 1100 соединений в секунду, лимит будет исчерпан, даже если эти подключения очень кратковременные (128k / 120s = 1092 connections/s ).

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

Так как для активации doNotTrack политика должна примениться в самом начале цепочек OUTPUT и PREROUTING, она действует раньше других (тех, для которых doNotTrack:false), вне зависимости от её order. То есть одна политика без doNotTrack может иметьorder:1, а другая с doNotTrack может иметь order:1000, но раньше подействует политика с doNotTrack. Порядок оrder соблюдается только между политиками данного типа.

*️⃣5/6: продолжение следует :)

#лонгрид