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

gistfile1.txt

Disclaimer: в этом посте я не ругаю какие-либо технологии, я, скорей, делюсь некоторым совокупным видением по данным вопросам, которые размазаны по достаточно большому количеству материалов, которые включают в себя, но не исчерпываются:
- бесчисленное количество материалов по bazel (включая исходный код и прямое общение с его разработчиками)
- книгу terraform up & runniner
- книгу kubernetes app & running
- официальную документацию kubernetes
- исходный код kubernetes

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

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

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

Возможно, эта информация будет вам полезна, возможно, нет.
Возможно, вы дополните моё понимание, возможно, укажите на ошибке.

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

Исходно я хотел расскаать про конкретные особенности приземления kubernetes в AWS, но потом я понял, что эта крайне фрагментарная картина и мне таки нужно создать некоторый определённый контекст, что такое AWS и зачем он вообще нужен (или не нужен)

Итак, поехали.

AWS (минусы)
------------

Про amazon слышали все, но для большей части пользователей он остаётся просто запускалкой co-located виртуальных серверов, которые, к тому же, сильно over-priced.
Многие коллеги по цеху рассказывают про толстые железяки, Настоящие IBM Сервера Серьезных Мужчин, про полки с дисками на сотни терабайт и прочие крайне манящие слух и глаз сущности.
С таким углом зрения AWS действительно выглядит каким-то over-priced hosting, непонятно зачем нужный.

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

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

С другой стороны, учитывая GDPR подобые проблемы испытывают все пользователи AWS, но в Европе у AWS есть аж четыре датацентра: Ирландия, Лондон, Франкфурт и Париж

С третьей стороны, некоторые из сервисов, например, EKS, доступны лишь в части регионов, конкретно EKS - лишь us-east-1 (США, Северная Вирджиния) и us-west-2 (США, Орегон)

С четвертой стороны, в некоторых специфичных азиатских регионах AWS стоит не просто денег, а совершенно конских денег.

В общем, с очень многих точек зрения AWS использовать не 

Как люди живут без AWS и вообще облаков
---------------------------------------

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

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

Там есть разработчики, сисадмины и датацентры, в датацентрах стоят сервера (компьютеры), и организацию занимается тем, что на эти сервера устанавливает какой-то софт, софтом пользуются люди, платят косвенно (просмотром рекламы) или напрямую (покупая сервисы или digital content) за это деньги, на эти деньги сотрудники получают зарплату, а компания - прибыль (либо убыток).

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

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

Деятельность включает в себя:
- (тут пропущена куча важных этапов типа постановки задач, product development и еще куча всего)
- разработчики создают некоторую новую версию продукта
- продукт упаковывается в некоторые артефакты вроде deb/rpm пакетов, docker images, архивов, файлов
- системные администраторы производят установку и настройку новой версию софта

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

Схема хороша с очень многих точек зрения, но есть два существенных минуса:
- расширение аппаратной базы (новые серверы, более толстые сервера, GPU карточки для машинного обучения запущенного недавно в компании) производится относительно медленно, в лучшем случае - несколько месяцев (цикл переговор о покупке, закупке, вводе в эксплуатацию), в плохом случае несколько лет (если это привязано с операционным циклом компании, вроде разработки под ключ, либо если циклы закупок производятся раз в год)
- цикл time-to-market по доставке софта в эксплуатацию достаточно длинный - в лучшем случае несколько часов, часто - дней.

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

Зачем же нужные все эти новомодные bazel, terraform, kubernetes, AWS?

AWS
---

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

Команда хочется сервера СЕЙЧАС, а не через месяц.
Нагрузка выросла СЕЙЧАС, а не после завершения финансового года и новых циклов закупки.
Изменить настройки нужно СЕЙЧАС, а не когда сисадмин придет на работу.

В этот момент времени хочется заменить людей API или командной строкой, набрать в ней что-то типа "хочу новые сервера с Nvidia TESLA о 200 гигабайт оперативной памяти и SDD дисками на 4 терабайта" и спустя несколько минут получить их в доступ.

В целом, AWS это как раз такая командная строка, которая делает именно это, а за удобство и низкий time-to-market берет с вас достаточно внушительный ценник.
К слову, ценник внушительных лишь поначалу, начиная с некоторого объема закупок ценник роняют ниже прайса, кроме того там есть разные опции вроде reserved instances, dedicated instances и spot instances. 
В целом можно существенно снизить косты и даже почти приблизиться к классическому хостингу, но смысла в этом мало.

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

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

Сила сервисов в их ИНТЕГРАЦИИ друг с другом.

Например, вы можете купить домен и настраивать его записи его в route53.
В соседнем ACM вы (бесплатно, между прочим) можете создать кучу ssl сертификатов и через route53 потвердить их владение
Сертификаты ACM и route53 вы можете использовать в ALB либо ELB (что-то типа софтового-аппаратного load balancer) просто ссылаясь на них по ARN
ARN - Amazon Resource Name - https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html - универсальный идентификатор ЧЕГО УГОДНО в aws.

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

ALB вы дальше можете приземлить на EC2 instances - это те самые over-priced виртуалки.
Их там очень много на разный вкус и цвет, с разным типом проца, типом памяти, с наличием всяких GPU.
Можете из интереса посмотреть на x1.32xlarge - такие "простые", "виртуалки" есть далеко не у каждого server provider'а

К виртуалками прилагаются EBS (Elastic Block Storage) - что-то типа SCSI дисков, которые резиново масштабируются и, опять же, доступны по ARN.
К ним еще сбоку идет Glacier для бэкапов на магнитную ленту, но это уже другая история

EC2 машины живут не сами по себе, они живут внутри VPC.
VPC - приватная сетка, что-то типа выделенного dmz.
В ней есть subnets (подсетки), security groups (что-то вроде аппаратного firewall), route tables (L2 routing), internet gateway / NAT gateway (по названию понятно, что это), elastic ip (белые ip-адреса), в том же самом EC2 живут те самые балансеры, про которые я писал выше.

Вы еще не забыли, что всем этим великолепием вы управляете через API и command-line инструменты?

Кроме того, вся эта штука еще покрыта IAM - Identity и Access Management.
Если вы построите внутрь внимательно, то вы охренеете - это не просто какой-то там LDAP, это система которая позволяет:
- быть Identity Provider (дает возможность кому-то извне, типа AD аутентицировать своих пользователей через AWS)
- потреблять Identity Provider (аутентицировать пользователей AWS через внешнюю систему, в AWS они известны как federated useres)
- настраивать пользователей, роли, группы, и политики прав доступа для всех них
- предоставляет sudo (он называется assume role)
- IAM привязывается ВООБЩЕ КО ВСЕМ РЕСУРСАМ AWS
- IAM позволяет сколько угодно гранулярно разрешить операцию вообще либо операцию над КОНКРЕТНЫМ РЕСУРСОМ ДЛЯ КОНКРЕТНОГО ПОЛЬЗОВАТЕЛЯ ИЛИ РОЛИ
- IAM пользователяет навесить роль на EC2 instance, т.е. СОФТ ИМЕННО С ЭТОГО ХОСТА ИМЕЕТ ПРАВО СОВЕРШИТЬ КАКУЮ-ТО ОПЕРАЦИЮ В AWS (!!!)

Если погрузиться в IAM поплотней, ты внезапно начинаешь чувствовать, что вообще всю жизнь потратил зря, администрируя куча различных доступов в сто-пиццот админок. 
Как вам возможность Login By Facebook в console?

Но это лишь самое начало.

Все эти сервисы еще умеют дружить с такой штукой, как Server-Less Application - аля AWS Lambda.
Пишите функции, засовываете их в ALB, через route53 и ACM навешиваете сверху доменное имя и сертификат, и вуаля - вот у вас приложение вообще без единого процесса или машины

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

Еще раз: не нужны HA Proxy, не нужен IP masquarading и прочий привычный вам треш, вы просто вставляете ALB на несколько availility zones, вешаете между ними сетку (без единого VLAN, точнее, VLAN там под капотом вам сделают) и дальше уходить спать

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

Кроме того, всё это счастье еще умеет АВТОМАТИЧЕСКИ МАСШТАБИРОВАТЬСЯ ПО CloudWatch метрикам
Вы настраиваете один раз, как оно работает, и оно автоматически разрастается когда у вас на сервис набегает 100500 пользователей, а когда они уходят оно само съеживается назад.

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

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

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

Ну, на закуску, я еще должен упомянуть SES (для отправки писем, тоже умеет в route53), KMS для автоматического управления ключами и паролями, а также их ротацией, S3 который по сути представляет из себя такую кластеризованную NFS, на которой без единого nginx можно собрать статический сайт, автоматически геолоциораванный по всему миру (вместо CDN) и, между прочим, который умеет писать про доступ к себе в другой соседний S3 бакет для аудита.

И, разумеется, нужно упомянуть про CloudTrail, в которой можно складывать access log'и к этому всему великолепию.

И я буду сильно неправ, если забуду сказать про Aurora - как вам автоматически вертикально масштабируемая по CPU, RAM и Storage MySQL либо PostgreSQL автоматически зарезервированная в нескольких датацентах, контролируемая через IAM и KSM, с бэкапами в S3 и Glacier, автоматическим failover и switchover и хранимками, которые вызывают AWS Lambda?
Да, я тоже сильно охренел когда увидел, и еще сильней охренел когда понял, что оно правда существует и работает. 

Правда, описанное выше существенно отличается от просто over-priced виртуалок?

Terraform / CloudFormation
--------------------------

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

Например, всего за несколько дней я смог собрать внушительного размера инфраструктуру, которая в голом аккаунте примерно за 15 минут раскатывает в нуля всю инфраструктуру в голом AWS аккаунте, включая пользователей и все перечисленные выше сервисы
Собственно, 10 минут из этих 15 раскатывается kubernetes control plane, а так бы я даже не успевал покурить пока идёт весь этот процесс

Terraform это такая система, которая:
- позволяет управлять выделенным набором AWS ресурсов (ну, не только AWS, но я мало о нем слышал в отрыве от AWS)
- управление это выглядит декларативно - через описание target state, дальше оно само жрет с AWS статус ресурсов и строит план модификации current state в target state.

К сожалению, не без проблем
https://github.com/hashicorp/terraform/issues/14477

Товарищи из terraform, с моей точки зрения, не проектировали языков програмирования, и потому там есть достаточно смешные и банальные проблемы, которые едва ли сделает человек прочитавший
https://www.amazon.com/Design-Concepts-Programming-Languages-Press/dp/0262201755

Несмотря на эти проблемы с count'ом и крайне убогий язык мета-программирования, при помощи просто скрипта на питоне меньше чем на тысячу строчек кода я усилил terraform недостающими меня возможностями, причем скрипт отрабаывает один раз на старте, выплевает пачку terraform файлов и дальше работает обычный pure terraform, который в остальным аспектах работает практически идеально.

Cloud Formation - аналог от AWS, появился позже. Куда боле вербосный, но в отличие от terraform в нем нету многих смешных болячек. Пощупать его я пока не успел, но обязательно восполню этот пробел в ближайшем будущем

Packer
------

Выше мы расссмотрели, какие задачи позволяет решить AWS и Terraform (либо Cloud Formation) и уволили большую часть системных администраторов, дальше нужно понять, как уволить почти всех остальных.
Для этого нужно понять, как в наш кластер поставить нужные нам артефакты

Для доставки артефактов внутрь EC2 машинки можно использовать Packer - родственный Terraform продукт, который собирает файлики с вашей машине в AMI (Amazon Machine Image).

В определенном смысле слова AMI это что-то типа Cobbler образа http://cobbler.github.io/ или образа виртуалки, а Packer - это его сборщик

Container Images
----------------

Разумеется, войдя во вкус вас категорически не устраивает новую версию софта собирать packer и ждать пока оно все приедет куда надо. Это занимает не меньше 15 минут, что сильно лучше ручного администрирования, но сильно хуже имеющихся альтернатив.

Потому разработички собирают docker images, а docker images можно запушить в AWS ECR registry (что-то типа приватного docker hub)

Разумеется, ECR имеет ARN, и через IAM и assume-role можно гранулярно настроить, кому какие репозитории можно или нельзя читать, обновлять или администрировать.


kubernetes
----------

Наверное, про kubernetes в последнее время не слышал только ленивый, и очень многие испытывают аллергию при этом слове.
Например, я очень долго смотрел на kubernetes волком.

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

Да что там далеко ходить - многие kubernetes админы не могут ответить на достаточно простые вопросы "как оно работает"

Нужно понимать простую штуку - kubernetes - это просто стандартизированный способ работать с cgroups и virtual ip switch, он не может больше, чем могут они, и единственная его ценность в том, что он НОРМИРУЕТ ДЕЯТЕЛЬНОСТЬ.

Вы можете ставить софт rpm и настраивать конфиги руками.
Вы можете делать тоже самое ansible.
Вы можете заменить rpm на docker images, а сам docker - на rkt, и всё тоже будет работать.
Вы можете притащить docker compose или его аналоги для упрощения администрирования виртуалок.

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

В чем же вообще смысле kubernetes?

В принципе, он делает с этим всем всё тоже самое, что делает AWS с железом, а terraform - c AWS
kubernetes дает вам некоторые декларативные описания target state софта, который вы хотите видеть в итоге.

Если откинуть хайп и прочитать книгу kubernetes up & running, немного почитать про admission control webhooks и разобраться с ingress и как он вообще вяжется с конкретным cloud provider (GCE, KOPS, EKS), то вы понимаете абсурдную его простоту и перестаёте понимать весь этот хайп вокруг. 
kubernetes не превносит ничего нового, он просто дает некоторый (весьма специфичный, на мой вкус) workflow по управлению cgroups и virtual ip switch.
Всё, больше он не делает ничего.

Под капотом он устроен примерно так:
- берете некоторые количество рабочих машинок, называете из worker nodes, вешаете на них labels, ставите специальный софт.
- взгромождаете поверх своей сети так называемый control plane, который состоит из управляющих сервисов (между прочим, это самая большая боль в его установке, и EKS, который автоматически это всё расскатывает за 10 минут вызвал такой бешеный интерес не просто так)
- на всех тачках должен быть docker (и больше всех docker ненавидят разработчики и админы kubernetes, инфа 100% - потому что разработчики docker обожают постоянно ломать API, делать новые баги, или не осилить за три подхода написать правильно файловую систему)
- control plane получает запросы по API, командует worker nodes, коммутирует virtual ip switch
- worker nodes качают из docker registry образы, запускают контейнеры, втыкают их в virtual switch.

Собственно, всё

С точки зрения своих описаний kubernetes говорит, что у тебя есть:
- Pod, это что-то типа группы контейнеров, запущенных на одной тачке. Что-то типа одного docker compose файла. Они имеют шаренный ip адрес и пространство портов, они могут шарить друг с другом volumes с данными и видят друг друга как будто процессы запущенные на одной машине. Что-то типа виртуальной машины запущенном на одной worker nodes, с контейнерами вместо процессов (а внутри контейнера могут быть свои процессы)
- ReplicaSet, это такая стайка одинаковых pod, которые имеет дубли и которых всегда столько, сколько говорит ReplicaSet
- DaemonSet, это такие Pods, которые запущены не где попало, а по одной штуке на каждой worker node. Например, чтобы логи собирать локально на каждой тачке.

Все эти сущности могут получать так называние labels и annotations.

Labels - это что-то типа тэгов, где ключем у тебя является FQDN-compible string длиной не более 63 символов (ЕМНИП) а значение просто строка. Причем label key может быть просто строка, которая начинается и заканчивается с буквы или цифры, в середине имеет буквы, цифры и минут, и все буквы в маленьком регистре - это тоже валидный FQDN (помните про localhost? тоже ведь fqdn)
Annotations - это просто метки без ограничений на формат

К Labels прилагаются label selectors, по которым можно находить группы объектов, например, группы pods или группы worker nodes (помните про labels для worker nodes? Вот это они)

Если написать label selectors и назвать именем, вы получите kubernetes Service.

Вот тут возникает та хайповая штука, на которую у всех аллергия и которая называется Service Discovery.

С моей деформированной точки зрения Service Discovery - это просто виртуальный ip адрес для сервиса, который в соответствии с настройками балансит tcp/ip сессии между всеми объектами, которые находят label selectors данного Service.
Нахрена и чем плох DNS? Да ничем, кроме того что DNS lookup:
- берет один ip адрес из списка и кеширует его
- забивает на TTL и не обновляет его.
Так не везде, но во много клиентском софте, особенно софте написанном студентом на выходных за 100 баксов

Потому в kubernetes такие DNS имена превращаются в ровно один ip адрес, а обращения к этому ip адрес перехватываются и балансятся между всеми сущностями, что попадают под label selectors сервиса.

Ну, в принципе, я вам про весь kubernetes только что расказал.

Для полноты картины нужно упомянуть про ConfigMap и SecretMap - это такое хранилище файликов (публичных как ConfigMap и секретных как SecretMap), который можно смонтировать внутрь контейнера внутри pod'а, чтобы софт внутри мог их прочитать

Все эти объекты можно сгруппировать в коробочки под названием namespace.

Кроме того, поверх этого есть еще RBAC / ABAC политики доступа, и Admission Control для тонкой настройки прав.

Конкретно EKS (на самом деле - heptio, который под капотом) еще умеет отображать роли и пользователей kubernetes на IAM, а то, что я очень люблю IAM вы уже поняли из статьи выше

Ну и последняя недостающая запчасть - это ingress.

Ingress
-------

Вообще говоря, это наиболее зубодробительная часть kubernetes, потому что манаулы для миллениалов с клиповым сознанием дают достаточно фрагментарную картинку, которая не позволяет понять, что вообще происходит за кулисами, что оно может, а что не может
Чтобы с ним разобраться, мне пришлось проштудировать
- официальную документацию GCE
- документацию и исходный код https://github.com/kubernetes-sigs/aws-alb-ingress-controller
- документацию и исходный код https://github.com/kubernetes/ingress-nginx
- документацию и исходный код https://github.com/nginxinc/kubernetes-ingress/tree/master/nginx-controller
- документацию и исходный код https://github.com/zalando-incubator/kube-ingress-aws-controller
- различные статьи и мануалы рассыпанные по куче блогов


Одна из самых полезный статей - это https://www.dcine.com/2018/07/27/amazon-eks-ingress-guide/

Если коротко, ingress вам нахрен не нужен до тех пор, пока вы свои контейнеры бороздящие просторы worker nodes (которыми могут быть EC2 instances, которые развернул вам terraform) не решили вытащить наружу.

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

Что такое Ingress? Что такое Ingress Controller? Нахрена их столько разных? Как domain name привязать? Как статический IP получить? Сертификат куда складывать?

Можно, конечно, бездумно пройтись по какому-то мануалу и что-то даже будет работать, но как именно, зачем так сложно и как, например, дружить это с AWS?

Если коротко - Ingress это просто костыль в данной стройной концепции kubernetes.
Пацаны из kubernetes не придумали (точнее, не стали, я уже даже начал подозревать почему) как красиво делать expose кластера наружу, и оставили эту штуку на усмотрение так называемого cloud provider.

Cloud Provider - это то, что вам предоставляет kubernetes кластер.
Например, GCE от гугла или EKS от AWS, или KOPS - сторонняя штука, работающая поверх AWS, или там Azure от Microsoft.

Ingress - это такая плагин, которому kubernetes говорит что и как хочется видеть, а тот идет к cloud provider и просит его это предоставить.

Если коротко, Ingress приземляет внутренности кластера на что-то внешнее, например, на AWS ALB (Application Load Balancer) заказывая его у AWS через AWS API.

Таким занимается не только Ingress, например, external-dns умеет прописыват внутренние адреса сервисов в Route53, но делает это медленно (несколько минут)

Но external-dns стороняя штука, а Ingress - core component.

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

Если работать по манаулам куба и вставлять по Ingress на каждый namespace, вы можете неприятно удивиться счету в конце месяца, вся куба и ноды для неё могут оказаться дешевле, чем все все эти сетевые интерфейсы и ELB которые подымаются вместе с каждым ingress

Правильней, конечно, говорить про Ingress Controller. Ingress Controller - как раз такой плагин, что говорит с cloud provider и под каждый Ingress выделяет нужные ему ресурсы и коммутирует к нему доступ

Собственно, статья Dan Mass это суммирует и предлагает гибридную схему, в которой у вас существует один-единственный внешний ALB, на котором терминируют внешний траффик + сертификаты (и тут работают мои любимые Route53 / ACM в связки с ним) который приземляется на один Ingres внутри kubernetes, а он рероутит эти все штуки на маленькие ingress-nginx, которые наружу сами не экспозятся

Таким образом, вы в кубу ставите два ingress контроллера, тот который с alb в названии коммутируется на AWS ALB и рероутит траффик, а второй взлетает по заказу индивидуальных namespace, и уже осуществляет внутренний роутинг внутри них между сервисами

Bazel
-----

Мы уже почти закончили рассмотрение всех этих безумных штук, что напридумывали хипстеры, но я буду неполон, если не упомяну про bazel.

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

Вот для сборки софта и docker images выезжает bazel.

По сути это такой make 21 века, который развивает его идеи.

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

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

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

Кроме того, bazel приносит с собой на машину по заказу весь toolchain, включая компиляторы и внешние библиотеки.
Ну, хорошо, java и плюсовый компилятор он таки хочет хостовые.

Кроме собственно сборки, он собранное еще умеет запускать и тестировать

Запускать - это собрать артефакт и сделать на него execute.

Например, rules которые работают с docker image, при "запуске" экспортируют образ в локальный докер.
rules, которые работают с kubernetes засовывают образа в docker registry и потом делают kubectl apply на объекты-yaml файлы, собранные, опять же, bazel.

Тесты - это такие групповые запуски executable таргетов, которые по зависимостям пересобираются, запускаются и на их основе exit codes делается вывод, прошел тест успешно или нет


Заключение
----------

Выше я длинным образом описал, по сути, простую штуку - как запустить один скрипт и уйти курить на 15 минут, а по возвращению получить готовую инфраструктуру для работы в AWS, которая, к тому же, еще умеет автоматически горизонтально масштабироваться (а в случае базы - еще и вертикально)

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

Дальше я в terraform докидываю +1 доменное имя, нажимаю кнопку, и через две минуты оно пролезло через весь AWS где надо
Аналогично любые другие задачи, типа раздачи прав или настройки чего угодно - правка кода, запуск команды, и вот у вас всё взлетело

Потому я правлю в коде баг или принимаю PR от разработчика, нажимаю в bazel одну кнопку, и через несколько секунд оно уехало в kubernetes cluster, и доступно всем для использования

Надеюсь, вам было интересно.

Спасибо, было интересно.