Дмитрий Шурупов shurup

Кстати, для взаимодействия с Kubernetes в этом проекте его авторы (из Confluent) использовали наш shell-operator:

Перевод очень похожей статьи мы публиковали аж 4 года назад.

Такие сравнения тоже есть в планах.

Сделать оператор как одну из опций (в дополнение к текущей, но не вместо ее) стоит в планах проекта: https://github.com/werf/werf/issues/2612

По терминологии — понятие GitOps нам тоже не очень (но его более-менее "знают"), поэтому придумали Giterminism.

Из инструментов — чат по werf довольно активен и вырос уже до 600+ участников: https://t.me/werf_ru

Ещё не увидел канал https://t.me/devopslibrary

А раз есть про K8s от MCS, то можно было бы и Флант добавить ;-) https://t.me/flant_ru (есть и чат).

Исторически сложилось, что в части кластеров под управлением Deckhouse активно используется flannel …

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

Про железные не сказали как обновили, kubespray playbook переписывали или просто бинари подменили?

Я бы назвал основным недостатком к8с это необходимость обращаться к услугам облачных провайдеров для работы с ним. Так как поднять и главное обслуживать его своими силами просто немыслимо. За что его и любят и всячески продвигают облачные провайдеры. Как следствие второй недостаток. То что каждый облачный провайдер добавляет чуточку своего функционала. Что приводит к несовместимости к8s при миграции с одного облака в другое.

В оригинале там тоже несколько коряво: не так просто переводить подобное, но любым уместным исправлениям (если вдруг такие есть) буду рад.

• OpenAI рассказывали о своем опыте больших инсталляций Kubernetes: Scaling Kubernetes to 2,500 Nodes и Scaling Kubernetes to 7,500 Nodes.
• Была такая статья в блоге Red Hat: OpenShift/Kubernetes Failure Stories at Scale — Lessons Learned from Large and Dense Deployments.
• Сам не смотрел этот доклад, но тоже может быть по теме: «Kubernetes в Booking.com (Иван Круглов, Booking.com)».

Проект интересный и сразу хорошо оформлен на GitHub, за что отдельный плюсик.

Однако из-за того, что он на Java, не думаю, что завоюет большую аудиторию сообщества Kubernetes, которое говорит на других языках.

В любом случае — успеха!

Познакомимся с самыми популярными операторами, которые существуют для работы PostgreSQL внутри Kubernetes.

В данный момент заканчиваются работы по поддержке схем OpenAPI, после чего будет опубликован релиз v1.0.0-rc1.

А вот у авторов недавно был обзор этого решения: https://habr.com/ru/company/proto/blog/530158/

В ней просто и наглядно рассказывается об основных возможностях интерактивного rebase'а, что может стать отличным введением для тех, кто только начинает им пользоваться.

Headlamp я бы вполне отнес к категории этих самых полноценных. Да, компания за ним стоит поменьше, конечно, но это ещё не приговор ;-)

Про что конкретно умеет — можно посмотреть список фич на сайте/гитхабе. Есть много всего по сборке, чтобы сделать её эффективной (быстрой с кэшами, инкрементными пересборками с учётом истории Git и т.п., распределенной). Content-based tagging (писали про его фишки в отдельной статье). Удобные инструменты для отладки и при сборке, и при деплое. Деплой в Kubernetes в духе GitOps (автоматизированное поддержание реального состояния инфраструктуры и приложения в соответствии с тем, что в репе). Умная автоматическая очистка образов (про нее тоже была статья). Главное удобство — что все эти части жизненного цикла управляются из одного места, "склеиваются" в нем и благодаря самому этому факту возможно (можно отслеживать нужные образы, чтобы что-то с ними делать).

Да, основную часть вещей можно сделать другими способами. Однако изначальный посыл, что это будет проще и удобнее, вряд ли тогда сработает. А смотреть на всю историю CI/CD и его реализации надо именно так комплексно, а не один какой-то выбранный кусок.

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

Хорошо, когда есть выбор. А уж как его делать — тема для других статей. Здесь же можно увидеть, что предстоит, если выбрать конкретный путь.

P.S. не упомянута startup проба.

Kubernetes поддерживает пробы готовности и работоспособности для версий ≤ 1.15. Пробы запуска были добавлены в 1.16 в качестве альфа-функции и перешли в бета-версию в 1.18.

You can continue to build and run Docker images locally and in your Kubernetes cluster as this deprecation will not impact that experience.

[..]

Today, and in Kubernetes v1.20, Kubernetes administrators can continue to use docker commands and kubectl commands to manage their Kubernetes clusters.

In a future release of Kubernetes, a few minor releases from now, when support for dockershim is eventually removed, you will no longer be able to use docker commands to inspect your cluster.

Many of these commands have similar commands in kubectl and ctr (the containerd CLI). While the commands to inspect your cluster in Kubernetes may change in the future, Developers will still be able to use Docker tools to docker build, docker push and docker run containers and container images on Kubernetes.

В OpenShift по умолчанию CRI-O (https://www.redhat.com/en/blog/red-hat-openshift-container-platform-4-now-defaults-cri-o-underlying-container-engine), про который мы писали (см. ссылки в конце этого перевода).

It is designed to introduce faults with very little pre-configuration and can support any infrastructure that you might have including K8S, Docker, vCenter or any Remote Machine with ssh enabled.

Кстати, очень интересно, что Gitlab CI внутри себя имеет именно аббревиатуру CI, а не CD.