Как мог бы выглядеть Kubernetes 2.0

[YaDr]

По замене yaml/json на HCL

1. yaml/json - языки описывающие объекты, конвертируются друг в друга легко и непринужденно, внешние вызовы "не умеют". Хочешь динамическое значение - рендери тот же YAML чем-то снаружи. HCL же вообще из другой области и представляет собой DSL с вызовами, для задач кубера не подходит примерно никак. Если предлагается хранить голый HCL в etcd, с его "random_string" и ко - то придется тащить аналог terraform state в тот же etcd, что бред по многим причинам. Если рендерить HCL в что-то статичное (да тот же yaml) - то это и сегодня можно сделать. Резюмируя - идея бредовая.

2. etcd прекрасно работает от 1й ноды and up. Скейлится мощнейще. Посмотрел на домашнем кластере из 3х нод etcd - суммарное потребление 3х инстансов = 108m cpu, 1208Mi ram. Весьма скромно. Не совсем понятно о каком lower-end k8s experience он говорит - кластер из трех Raspberry pi 4?.. Так даже они начинаются с 8гб рамы теперь... Просто так прикручивать альтернативы - классическое "решение, ищущее проблему".

3. Helm да, стал стандартом при этом имея тонну лютых недостатков. Заменить его было бы очень хорошо.

4. IPv6 "в дефолте" - зачем? Дебаг усложнить? Приведенные проблемы решены текущим дизайном куба с самого начала.
   4.1) Общаться "pod-pod по внутренним айпи между кластерами" - бред, специально для этого созданы сервисы и ингрессы. IPv6 проблему "мы выдали две одинаковых серых сети двум кластерам и хотим в нарушение всех концептов k8s общаться pod-pod между кластерами, но у нас внутренние ip пересекаются" не решит никак.
   4.2) NAT в кубе, в общем-то, простейший. Один на входе в сервис, если у того 'internalTrafficPolicy: Cluster' стоит. Конкретный случай он не описал, а каких-то широкоизвестных "NAT-проблем" у кубера и нет.
   4.3) Так и IPv6 можно выдать /116 на весь кластер и так же внезапно "кончатся адреса". Вопрос планирования.

Вообще через весь его спич про IPv6 сквозит "я хочу роутиться к подам напрямую, мимо сервисов и ингрессов, но нормально спланировать это не могу".

Резюмируя - три откровенно бредовых идеи и одна нормальная. Meh.

[slonopotamus]

IPv6 "в дефолте" - зачем?

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

[SlavikF]

Я не специалист по сетям. Но представляют себе так, что хоть с IPv4, хоть с IPv6 - в любом случае Кубернетусу нужны дополнительные хопы, - LoadBalancer, Ingress. И поэтому в общем-то без разницы - IPv4/v6 с НАТ или без...

Хотя от ограничений по IP диапазонам IPv6 поможет.

[lantonov]

Согласен на фига городить nat если можно просто прописать статичные адреса pod и все делать на прямую так быстрее данные ходить будут а конфигурации iptabels у очень кривые и надо делать правильно а если нужна изоляция то делать сети которые вообще не доступны для пользователей так сказать служебные сети для служебного трафика

[mayorovp]

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

[YaDr]

Так это отдельный объект в etcd, этот secret. На сам-то кубовый обьект и взаимодействие куба с этим объектом он не влияет. А если HCL тащить в куб - то будет как, обьект deployment, состояние которого неизвестно если secret не прочитать?

[mayorovp]

Так же как сейчас helm работает. HCL отдельно, сгенерированный deployment отдельно.

[YaDr]

Так уже можно отрендерить HCL в yaml/json и положить в куб + секрет рядом. Автор изначальной статьи хотел именно HCL унести в куб. что бы kubectl get pod -o hcl возвращал hcl. И что есть бред.

[M0rdecay]

Всё описанное очень сильно похоже на... Nomad. Всё описывается в HCL нативно (ну ещё бы), пакетный менеджер из коробки (Nomad Pack), всё состояние хранится в распределенном Consul KV.

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

[slonopotamus]

пакетный менеджер из коробки (Nomad Pack)

Вы пробовали им пользоваться? Там не хватает кучи самых базовых вещей.

[M0rdecay]

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

[olku]

К сожалению, выбор оркестратора невелик - Nomad, Swarm, K8S. Кубер монструозный, Сворм заброшен хотя ему совсем немного не хватило, Номад так и не стал популярным. CNCF сформировал экосистему Кубера, HashiCorp с ними тягаться не может.

[aim]

и слава б-гу
с уходом хаши из корпа, сменой лицензии и покупкой великим межделмашем...
в общем вы понели...

[olku]

Хм, только зашифрованное слово "бог".

[lantonov]

4.1) Общаться "pod-pod по внутренним айпи между кластерами" - бред, специально для этого созданы сервисы и ингрессы. IPv6 проблему "мы выдали две одинаковых серых сети двум кластерам и хотим в нарушение всех концептов k8s общаться pod-pod между кластерами, но у нас внутренние ip пересекаются" не решит никак.

Вопрос простой а нафига так делать если вы делаете 2 разных кластера то и сети должны быть разные в идеале можно попробовать сделать чтобы адреса были с 32 маской тем самым можно будет обратиться к ним напрямую и самое главное если это кластер просто сделать динамическую маршрутизацию между ними и все никаких проблем не будет и ipv6 ещё проще организовать канал между ними самое главное сделать нормальный способ регистрации имени в dns чтобы он был общий для обоих кластеров и все сети надо пропитывать заранее а не придумывать проблемы на том что не смогли поменять сети