Ключевые цели платформы:

1. Стандартизация и максимальное переиспользование компонентов:
Cтремиться к унификации и максимальному переиспользованию всех компонентов, как в пределах платформы, так и вне её. Этот подход исключает вендорлок, минимизирует настройки и активно практикует обмен знаниями.

2. Использование свободных технологий и инструментов:
На данный момент все компоненты платформы основаны на широко известных и признанных в сообществе свободных инструментах и технологиях. Мне нравится такой подход и я хотел бы сохранить его в будущем.

3. Сотрудничество с проектами:
Как в случае проекта KubeVirt, если функция, разрабатываемая для платформы, может быть полезной вышестоящему проекту, с большой вероятностью она будет передана непосредственно в апстрим, вместо того чтобы реализовавать её внутри платформы.

4. Функциональность и обновления:
Основная задача платформы — предоставить оптимальную конфигурацию компонентов, создав готовый, протестированный дистрибутив, готовый для мгновенного внедрения в продакшн, а также безпроблемные обновления всех компонентов, включая операционную систему, ядро и саму платформу.

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

6. API как приоритет:
Несмотря на то, что у платформы будет графический интерфейс, его основная цель — обеспечить быстрое погружение и наглядную демонстрацию функций платформы.
Мне хочется верить, что пользователи по достоинству оценят удобный API платформы и предпочтут описывать свою инфраструктуру как код, вместо кликания мышкой в веб-интерфейсе.

Grafana-operator становится частью Grafana
https://github.com/grafana-operator/grafana-operator/discussions/1324

97-й выпуск подкаста

Глупые вопросы про Git и системы контроля версий

Слушать:
YouTube
Яндекс.Музыка
mave
Apple
Castbox
Google Podcasts
VK


Содержание выпуска
— Что такое системы контроля версий и для чего они нужны. Какие VCS существуют и чем они различаются.
— История VCS: когда появились первые системы, какие они были и как развивались.
— Как появление систем контроля версий, и в частности Git, повлияло на IT-индустрию.
— Что такое Git и почему он стал самой популярной VCS.
— Как связаны Git и GitHub.
— Краткий ликбез по основным компонентам и концепциям Git: репозитории, ветки, коммиты и так далее.
— Как устроен Git изнутри: что представляет собой версия документа, где и в каком виде хранятся данные о версиях.
— В чём разница между git merge, squash и rebase? И когда что использовать.
— Мастхэв-набор команд и действий в Git для любого разработчика.
— Что такое GitOps.
— Как выглядит Git workflow в разных компаниях.
— Какие ошибки совершают новички при работе с Git.
— Про графические инструменты для работы с Git.
— Существуют ли альтернативные способы разработки, без использования систем контроля версий.
— VCS — это только про разработку или их используют ещё где-то?
— Что почитать, посмотреть и послушать про Git.

Гость. Андрей Квапил. Архитектор решений Kubernetes. Эксперт по SDS, SDN, облачным платформам и автоматизации дата-центров. Developer Advocate и активный член комьюнити. Опыт в IT — 10 лет.

Полезные ссылки:
— Git How To https://githowto.com/
— GitHub flow https://docs.github.com/en/get-started/quickstart/github-flow
— GitLab Flow https://about.gitlab.com/topics/version-control/what-is-gitlab-flow/
— Доклад Андрея про GitOps https://www.youtube.com/watch?v=FpjCuslco74

talos-bootstrap - скрипт, который позволяет легко раскатать отказоустойчивый Kubernetes кластер в Talos OS в духе интерактивного установщика Debian

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

Это наш дебютный проект на GitHub, подписывайтесь, дальше будет интереснее

democratic-csi - выглядит как идеальный ZFS-драйвер для Kubernetes. Поддерживает как локальный ZFS, так и ZFS over NFS/SMB/iSCSI/NVMe-oF с автоматической нарезкой томов на хранилище по SSH

https://github.com/democratic-csi/democratic-csi

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

Мы продолжаем развиваться, и помимо инфраструктурных решений, DevOps становится нашим вторым основным направлением.

Ждем новых клиентов и будем рады вашим сообщениям: @kvaps @gecube

Ну всё, 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, какому решению вы бы отдали приоритет?

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