Ну всё, Cisco покупает Isovalent (разработчика Cilium)
https://isovalent.com/blog/post/cisco-acquires-isovalent/

🗜 Смотрите какой клёвый pastebin сервис, работающий по SSH и доступный как в tui, так и в веб-морде... https://snips.sh/

А ещё, всё это можно развернуть на собственном сервере, судя по всему:

https://github.com/robherley/snips.sh

#tui #pastebin #ssh

Разбираемся с cluster-api Kubernetes

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

Мы помним что Kubernetes - это single tenant приложение, а соотвественно по хорошему нам бы иметь отдельный кластер на каждые проект/команду разработки.
Подразумевается что у вас есть один отдельный management Kubernetes кластер и вы используете его для того чтобы управлять всеми остальными.

Так вот, Cluster API есть понятие провайдеров, всего их три типа:

- infrastructure-provider - используется для создная хостов, которые будут использоваться для провиженинга воркеров и возможно control-plane.
- control-plane-provider - используется для создания control-plane для Kubernetes, который может быть создан в виртуалках контейнерах или где-либо ещё.
- bootstrap-provider - метод провиженинга кластера (почти всегда это kubeadm)

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

Главный ресурс, знаменующий кластер, так и называется kind: Cluster, все ресурсы на которые он ссылается становятся его потомками
- controlPlaneRef - указывает на ресурс обслуживающий controlPlane
- infrastructureRef - указывает на ресурс под которым создаются все виртуалки/хосты или, если выражаться правильно, машины.

Машины управляются infrastructure-провайдером с помощью ресурсов MachineDeployment, MachineSet и непосредственно Machine.

Вот набор YAML'ов которые нужно положить в кластер чтобы получить control-plane в контейнерах (для этого используется проект Kamaji), и запускать воркеров в виртуалках KubeVirt:

https://github.com/clastix/cluster-api-control-plane-provider-kamaji/blob/master/docs/providers-kubevirt.md

Когда создаётся объект Cluster он ждёт доступности ресурса указанного в controlPlaneRef.
Контракт такой: Control-plane-controller-manager должен иницииализировать новый Kubernetes control-plane и записать кондишен ControlPlaneInitialized в объект кластера.

Kubeadm controller-manager, например, создаёт ещё пачку секретов:

test-ca
test-etcd
test-kubeconfig
test-proxy
test-sa
test-sptdz
test-sptdz-userdata
test-ssh-keys

Которые в дальнейшем используются infrastucture-провайдером для того чтобы забутстрапить воркеров.

Что насчёт CCM (cloud-controller-manager) он же cloud-provider.
Это компонент, который отвечает за синхнонизацию Kubernetes-кластера с облаком.

Тем не менее задач у него немного:

1. При создании сервиса типа LoadBalancer CCM выполняет логику чтобы заказать облачный балансер, который начнёт слать трафик в ваш куб.
2. При удалении ноды из облака, CCM удалит её так же из вашего Kubernetes-кластера.
3. При добавлении ноды в кластере с работающим CCM, kubelet вешает на неё таинт node.cloudprovider.kubernetes.io/uninitialized, когда нода успешно проинициализированна CCM эту аннотацию снимает.

Работать и запускаться CCM может быть как внутри, так и снаружи кластера. В зависимости от логики облака.

Конкретно cloud-provider-kubevirt устанавливается снаружи, в родительском кластере.
Сервисы типа LoadBalancer созданные в пользовательском кластере, создаются также и в родительском кластере, а трафик шлётся прямо на виртуалки воркеров.

Кстати, помимо облачных балансировщиков, есть также и те, которые работают прямо на bare metal.
Все мы прекрасно знаем metallb и kube-vip, а с недавних пор даже cilium обзавёлся таким функционалом.

Но мало кто знает про LoxiLB, тем не менее в отличие от вышеупомянутых балансировщиков, этот умеет устанавливаться отдельно от Kubernetes.
Для того чтобы это работало он как раз имплементирует интерфейс CCM провайдера.

й

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

Если в кратце, то есть
csi-controller - часть, которая отвечает за связь с облачным API и используется для создания/удаления, аттача/детача и ресайза томов.
csi-node - часть, которая запускается на ноде и с которой общается kubelet чтобы примаунтить полученный волюм к поду.

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

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

Из коробки поддерживается возможность запустить cloud-provider, cluster-autoscaler и CSI-controller для KubeVirt прямо на стороне управляющего кластера.

Данный подход позволяет полностью скрыть внутреннее API вашего облака от конечного пользователя, предоставив ему интерфейс только в виде сущностей Kubernetes.
Никаких контроллеров в пользовательском кластере, а соответсвенно и дырок для доступа в ваш management кластер. Красиво, Секьюрно, Удобно.

Кстати, мы тут рассматриваем возможность поддержки Proxmox в качестве альтернативного гипервизора, основной сейчас - KubeVirt.

Не смотря на то, что Proxmox в действительности не является облачной платформой, а в основном используется для запуска традиционных виртуальных машин (pets) с настройкой вручную, мы знаем что в комьюнити Proxmox полюбился многим, и потому спрашиваем у вас:

Если бы у вас был выбор между запуском Kubernetes кластеров в полностью управляемой платформе на базе Talos Linux+KubeVirt или менее управляемым, но более понятном Proxmox, какому решению вы бы отдали приоритет?

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

talos-bootstrap научился обновлять уже забутстрапленные ноды в кластере, а так же выводить красивый дашборд для Talos Linux

https://github.com/aenix-io/talos-bootstrap/

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

Например etcd кластер и monitoring hub могут быть общими для нескольких Kubernetes-кластеров. Потому что пользователь захочет зайти в единую графану и увидеть метрики сразу со всех своих кластеров.

Реализация была позаимстована у неймспейсов ядра Linux.

При создании нового тенанта, вы можете указать должен ли этот тенант иметь отдельные etcd, monitoring и ingress. А все приложения устанавливаемые в пространстве для этого тенанта автоматически унаследуют эти параметры, например:

- если тенант имеет свой monitoring hub: будут использовать его
- если не имеет: будут использовать monitoring hub родительского тенанта

Кого-то настолько достали финалайзеры в Kubernetes, что решил написать весьма полезную тулзу)
https://github.com/ibuildthecloud/finalizers

https://www.tomshardware.com/networking/amazons-aws-new-charge-for-using-ipv4-is-expected-to-rake-in-up-to-dollar1b-per-year-change-should-speed-ipv6-adoption

the time has come 🙂

Мы рады представить первый публичный релиз платформы Cozystack 🎉🎉🎉
Платформу уже можно установить и потыкать. Будем рады получить любой фидбек.
А также мы всегда готовы помочь советом в нашем комьюнити канале

https://github.com/aenix-io/cozystack

Пожалуйста насыпьте нам звёзд ⭐
(это очень поможет развитию проекта)

Weaveworks обанкротились, а на HN разгорелась очень жаркая дискуссия 🔥

скандалы, интриги, расследования

https://news.ycombinator.com/item?id=39262650

Mirrord позволяет зеркалировать трафик из удалённого Kubenretes в локальный дев, так и наоборот

https://github.com/metalbear-co/mirrord

Приветы,

как же мы скучали и готовились к нашей новой встрече 🎉

И вот, новый выпуск с
Георгом Гаалом @gecube и
Андреем Квапилом @kvaps

За это время друзья запустили свой open source проект и готовы о нем рассказать уже сегодня вечером, всем нашим пятничным друзьям)

🕗 В 20:00
💬 в @kubernetes_ru

Вашему вниманию:
Как построить платформу для managed Kubernetes и DB-as-a-Service

Опыт построения платформы Cozystack.
Почему Talos Linux - это лучший выбор для вендора.
Возможна ли мультитенантность в Kubernetes?
Запуск кластеров по кнопке, без OpenStack и какой-то матери.
Паттерн Kubernetes-in-Kubernetes и его практическая реализация с KubeVirt и Cluster API.

Технологии о которых пойдёт речь:
- Talos Linux
- Flux CD
- KubeVirt
- Cluster API
- Kube-OVN
- Kamaji

У проекта есть канал @aenix_io
и комьюнити @cozystack

Ведущие сегодня:
Крылов Александр, достопочтенный @darkbenladan
Фиделина, деятельная @fidelina_ru

При поддержке:
@devops_ru
@itstand_org

DevOps Backstage: Как построить платформу для managed Kubernetes и DB-as-a-Service с Георгом Гаалом и Андреем Квапилом

После покупки VMware, Broadcom решил перестать предоставлять ESXi Free hypervisor

https://www.theregister.com/2024/02/13/broadcom_ends_free_esxi_vsphere/

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

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

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

Как оказалось Buildx, как в целом и сам Docker, умеет билдить удалённо, подключаясь прямо по SSH.

Настраивается мега-просто, если у вас похожая проблема, очень советую:

https://dustinrue.com/2021/12/using-a-remote-docker-engine-with-buildx/

Вышел Cozystack v0.1.0 с поддержкой ZFS

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

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

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

Мне RedHat тут бесплатно книжки раздаёт