Немного занимательных аналогий из мира Kubernetes
...для тех, кто программировал сервера еще до контейнеров

Container - процесс (или несколько связанных процессов).

Pod - "виртуальная машина" как группа процессов (т.е. контейнеров) разделяющих общие ресурсы (disk, RAM, CPU, network, etc) доступная по некоторому IP адресу. Такие "машины" недолговечны, при перезапуске создается новая идентичная машина с новым IP адресом.

Service - логическая группа "виртуальных машин" с постоянным адресом (IP и DNS). В до-kubernetes эре сервисом бы мог считаться виртуальный server какого-нибудь Nginx reverse proxy (или VirtualHost в Apache сервере) прячущий за своим upstream группу виртуалок переменной численности.

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

Service discovery - модное название для задачи нахождения по имени (или IP адресу) сервиса IP адреса конкретной машины из группы машин этого сервиса.

Load balancing - сделай свою service discovery так, чтобы ни один из IP адресов машин сервиса не оказался перегружен запросами.

Service proxy - это как reverse proxy, только тонко размазанный по стороне клиента. Клиенты общаются с конкретными машинами сервисов через service proxy. Service proxy работают локально и распределенно. Условно говоря, сколько клиентов, столько и service proxy-ей. Как и reverse proxy, технология решает задачу service discovery и load balancing.

Kube-proxy - процесс, который превращает каждую ноду кластера в L3/L4 service proxy. Что-то вроде envoy, но на уровне операционной системы (iptables или IPVS). Для каждого контейнера нода, на которой он запущен, является его service proxy.

Это свершилось! Kubernetes отказывается от поддержки Docker в качестве container runtime.

И это на самом деле здорово. Docker - это огромная экосистема с прицелом на удобство использования контейнеров именно человеками (а после покупки их Mirantis'ом и отказа от дальнейшей разработки swarm'а, developer experience стало по факту их единственным фокусом). Kubernetes'у же от container runtime'а нужно буквально три команды - запусти контейнер, покажи статус контейнера, да пошли ему сигнал (утрирую конечно). Поэтому по факту использовать полноценный dockerd смысла очень было мало. Но так уж исторически сложилось... К счастью, еще в далеком 2016 требования Kubernetes'а к container runtime формализовали в виде Container Runtime Interface (CRI); и containerd (то, что на самом деле запускает контейнеры позади dockerd) быстренько добавил поддержку CRI, а RedHat запилили свой аналог - cri-o. Но вот код Kubernetes до сих пор был вынужден поддерживать и милый сердцу CRI и legacy интеграцию с Docker'ом. И вот, настала пора большой чистки.

Fear not, с точки зрения разработчиков ничего не поменялось. Все благополучно продолжат писать свои Dockerfile'ы и запускать контейнеры на любимых маках в старом добром Docker. Стандартизация - сила!

Сказ о том, как в Kubernetes'е работа с сетью устроена

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

На мой взгляд, удобно различать следующие "уровни" ответственности:

1. Container networking в рамках одного сервера (ноды). По факту о том, как сделать так, чтобы каждый Pod видел отдельный изолированный network stack и чтобы Pod'ы, расположенные на одной ноде могли общаться между собой "по-сети". В основном решается средствами Linux по виртуализации сети (network namespaces, veth, Linux bridge, вот это все).

2. Pod to Pod networking между разными нодами. Kubernetes классно придумал, что все Pod'ы должны быть адресуемыми по их IP и чтобы никакого "видимого" NAT'а (а если точнее - sNAT'а). Т.е. получатель пакетов от Pod'а видит в source IP тот же самый адрес, что и сам отправитель видит при условном ip addr show на своей стороне. Только вот Kubernetes забыл придумать, как это все организовать. Ну точнее не забыл, а справедливо решил, что сеть у каждого п̶р̶е̶д̶п̶р̶и̶я̶т̶и̶я̶ enterprise устроена на свой манер и поэтому пусть каждый по-своему и добивается нужной адресации. Тут на помощь приходят всякие проекты по виртуализации сети вроде flannel, calico, weave net и т.п.

3. Уровень Service'ов. Kubernetes из коробки предоставляет возможность объединять Pod'ы в логические группы, суть - микросервисы. Но что еще более приятно, задачи service discovery и load balancing решаются тоже из коробки, спасибо kube-proxy.

4. Уровень х̶а̶й̶п̶а̶ service mesh. Несмотря на то, что Service'ы все такие классные прямо из коробки, остается еще очень много нерешенных проблем, общих для каждого из приложений, которые также было бы здорово решить на уровен инфраструктуры. А именно - retry & timeouts, request tracing и прочая observability, mTLS и прочая security, и т.п. И оказывается, что уровень Service'ов вполне себе расширяемый, чему Linkerd и Istio яркое подтверждение.

5. Уровень Ingress. Уровни с 1 по 4 - это в основном о том, как трафик гонять внутри кластеров. А вот заводить трафик из внешнего мира внутрь кластера помогает Ingres. По факту это условный Nginx, который по динамически обновляемым правилам умеет (только) HTTP(S) запросы отправлять нужному Service'у.

Собственно, все. Дальше берем, и по каждому уровню проводим свое собственное расследование. Ах да, чуть не забыл. Работать с сетью в Linux из кода - то еще удовольствие. И поэтому добрые люди написали стандартизованные обертки (CNI) вокруг всяких сетевых комманд вроде iptables. Вот здесь можно посмотерть полный список.

Тред https://twitter.com/iximiuz/status/1337810082587963392

Я тут как-то уже писал про Cloud Native Landscape. Это такая крутая интерактивная визуализация всех CNCF проектов. В какой-то момент я даже поверил, что эта визуализация придает некоторый смысл зонтику CNCF. Но потом передумал и продолжил ломать голову над тем, почему вдруг мы получили такой взрывной рост каких-то cloud-native проектов (да, мутный термин). И тут недавно мне напомнили одну вещь про... микросервисы! Ни для кого не секрет, что на самом деле микросервисы пытаются решать организационные проблемы, а не технические. Типа как код и зоны ответственности поделить между командами и сделать так, чтобы никто не толкался. Конечно, разрезать все на микросервисы! Фишка в том, что это похоже создает целый пласт новых технических проблем. Большие монолиты были дофига сложными, писать код в shared environment было тоже сложно. А теперь вдруг сервисы стали маленькими и никто, кроме твоих товарещей по команде твой код не ломает! То есть жизнь стала вроде как проще. Но похоже есть в природе закон сохранения сложности. И вся эта сложность написания кода для монолита переползла на уровень инфраструктуры. И теперь мы должны думать, как эффетивный RPC уровень замутить, как HTTP запросы трейсить, как логи собирать с сотен контейнеров, service mesh всякие мутить и т.п. Так что похоже, что именно эти технические проблемы, появившиеся из-за перехода на микросервисы, и решают CNCF проекты.

https://iximiuz.com/en/posts/making-sense-out-of-cloud-native-buzz/

TIL: Оказывается, у понятия Cloud Native есть официальное определение! Да еще и переведенное на много-много языков! Вот вариант на русском:

Нативные облачные (Cloud native) технологии позволяют организациям создавать и запускать масштабируемые приложения в современных динамических средах, таких как публичные, частные и гибридные облака. Контейнеры, сервисные сита (service meshes), микросервисы, неизменяемая инфраструктура и декларативные API являются примером такого подхода.

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

Cloud Native Computing Foundation ставит целью адаптировать эту парадигму, развивая и поддерживая экосистему проектов, с открытым исходным кодом, независимую от их поставщиков. Мы демократизируем современные модели, чтобы сделать эти инновации доступными для всех.

https://github.com/cncf/toc/blob/master/DEFINITION.md

Не знаю, кто как провёл выходной, а я - рисовал 🙈

https://twitter.com/iximiuz/status/1353045442087571456?s=21

В опасное время живем, товарищи!

https://blog.google/threat-analysis-group/new-campaign-targeting-security-researchers/

Восхищаюсь людьми, которые имеют смелость разворачивать не-managed Kubernetes кластеры для своего production. Со стороны мне всегда казалось, что в этом cloud native зоопарке слишком много moving parts чтобы спасть спокойно. Не столько с технической точки зрения (это наоборот весело, как LEGO собираешь), сколько с точки зрения безопасности. Без выделенной (большой и опытной) команды для поддержки инфраструктуры, обычным dev командам путь только в облака - EKS или GKE, а лучше Fargate или Cloud Run.

Иначе получится что-то вроде этого:

https://twitter.com/iximiuz/status/1358392288708349952

И в продолжение темы веселых взломов...

https://twitter.com/iximiuz/status/1359599798278647808

Что-то я давно сюда ничего не писал... Отчасти потому, что последний месяц был по уши в работе над серией статей про Computer Networking для самых маленьких (с картинками).

https://iximiuz.com/en/posts/computer-networking-101/

TIL: nibble - 4 бита, aka полубайт!

bite - укус
nibble - что-то вроде покусывания


struct bpf_insn {
__u8 code; // <-- байт
__u8 dst_reg:4; // <-- полубайт
__u8 src_reg:4; // <-- еще один полубайт
...
};