Хочу рассказать об интересном эксперименте, суть которого заключалась в развертывании и настройке Kubernetes на двух старых ноутбуках — один из них, кроме того, был с процессором на архитектуре i386. В качестве теоретической основы использовалось руководство Kubernetes The Hard Way, которое по ходу дела пришлось немного доработать, а в качестве системы на хостах — Gentoo (да, вам не показалось). Давайте погрузимся в этот увлекательный хардкор!
Статья продолжает наш обзорный цикл о PostgreSQL-операторах для Kubernetes. В первой части мы рассматривали операторы Stolon, Crunchy Data и Zalando. Во второй — KubeDB и StackGres, а также объединили все пять операторов в сравнительную таблицу. В этот раз разбираем решение CloudNativePG, его возможности и особенности, а заодно актуализируем таблицу.
При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, нужно сначала запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию или миграции БД, а уже затем запустить само приложение.
Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf.
Этой ночью представят новую версию Kubernetes. Среди главных изменений на первое место разработчики поставили стабилизацию функции CSI Migration — отказ от внутренних плагинов хранилищ в пользу CSI-драйверов. Также в этой версии устаревший контроллер PodSecurityPolicy заменен на новый PodSecurity Admission.
По традиции в обзоре рассказываем обо всех новых функциях (alpha), а также упоминаем те, что перешли на уровень выше (beta, stable).
Не так давно мы решили добавить в нашу Kubernetes-платформу Deckhouse поддержку Cilium. Однако в процессе разработки модуля cni-cilium неожиданно столкнулись со сложностями, для преодоления которых пришлось даже обращаться к авторам проекта. Теперь, когда модуль успешно доведен до рабочего состояния, можно перевести дух и поделиться ощущениями от полученного опыта и использования этого продукта в целом.
Туториалы делятся на две больших категории: либо "как нарисовать сову", либо подробно расписанные тысячи шагов в формате "напиши туториал для дурака - и только дурак захочет его читать".
Как какой из двух категорий относится эта статья — решать вам.
В этой статье вы увидите пошаговое создание cloud-native микросервиса на Amazon AWS, пригодное для "чтения с листа". Чтобы понять, что здесь происходит, не нужно разворачивать проект - достаточно обладать живым воображением и прочитать текст по диагонали. Если же вы всё-таки захотите повторить шаги, вам будут жизненно нужны знания вида, как создавать классы в IDE и что такое Spring.
Вначале мы напишем пару простых микросервисов на Spring Boot, докеризуем их, зальём в AWS, настроим красивые доменные имена и HTTPS, прикрутим логирование и мониторинг, Prometheus и Grafana. Это небольшое путешествие по всем кругам ада, из которого вы не вернетесь прежним.
Текст написан на основе текстов и демо-проекта microservice-customer за авторством @kamaruzzaman. Если вы потеряли нить повествования, всегда можно зайти на GitHub и найти весь код в пригодном для запуска виде. Если захочется закопаться в тему, то бро Дима Чуйко (@Teapot) написал вам ещё две части статьи "Микросервисы: от CRUD до Native Image" (раз, два).
Последняя важная оговорка. В этом гайде будут использоваться технологии Amazon и обычные дистрибутивы OpenJDK. Автор осознает, что мы живём в России, и возможно, вместо Amazon куда лучше подойдет что-то вроде SberCloud или MTS Cloud, а вместо обычного OpenJDK - Axiom JDK с сертификацией по ФСТЭК. Особенности российских технологий - тема для отдельной статьи. Если вы захотите таковую после чтения этого гайда - отметьтесь в комментариях.
В июне я выступил на объединенной конференции DevOpsConf & TechLead Conf 2022. Доклад был посвящен LINSTOR — Open Source-хранилищу от компании LINBIT (разработчики DRBD). Основной идеей выступления было показать [на примере Kubernetes], как работает и устроен LINSTOR, какие проблемы решает, как его правильно настроить и использовать. Эта статья — основная выжимка из доклада (его полное видео см. в конце).
yaml). В предыдущих постах по этой теме я познакомил читателей с фреймворком и рассказал об использовании библиотеки cdk8s-plus для дальнейшего расширения базовых возможностей функций библиотеки cdk8s. В этом посте мы ещё больше расширим границы возможностей cdk8s.cdk8s. Мы начнём с простого примера Nginx, а затем используем комбинацию CRD проекта Strimzi вместе с Go cdk8s для описания и развёртывания кластера Kafka на Kubernetes!С появлением snapshot-controller в Kubernetes появилась возможность создавать снапшоты для совместимых с ними CSI-драйверов и облачных провайдеров.
Как и всё в Kubernetes, имплементация API является универсальной и не зависит от какого-либо вендора, что позволяет нам рассмотреть данный функционал в общем порядке. Как же устроены снапшоты и какую пользу они могут принести пользователям Kubernetes?
Всем привет! Меня зовут Аня, я строю и развиваю инфраструктуру мониторинга в платформе телеметрии Ozon. Моя команда не только помогает настроить мониторинг, но и разрабатывает различные сервисы и инструменты, чтобы упростить жизнь разработчикам компании.
В прошлом году я рассказывала, как мы организовали мониторинг Kubernetes CronJob на основе kube-state-metrics, Thanos Receive и Thanos Ruler. За год мы нашли ответ на вопрос, почему же крон может не запускаться. И в этой статье я хочу рассказать об основных причинах и проблемах, о которых мы узнали.
Спойлер: многие не задумываются о том, как устроен и управляется CronJob.
Kubernetes — это быстроразвивающийся opensource проект, позволяющий управлять контейнерами Linux как единой системой. Мы с лёгкостью можем запускать сложные системы, используя при этом yaml-конфигурации. Для управления системой применяются декларативные ресурсы. Иерархическая система ресурсов позволяет создавать большие системы с минимумом конфигов. Именно поэтому всё больше и больше людей переносит свою инфраструктуру внутрь Kubernetes, причём не только stateless-, но и statefull-приложения. Так зачем отказывать себе в удобстве и не использовать Tarantool внутри Kubernetes?
Привет, меня зовут Костя, и сегодня я расскажу про то, с чем мы столкнулись при разработке Tarantool Kubernetes Operator, Enterprise для Kubernetes / Openshift. Кому интересно — добро пожаловать под кат.
В продолжение наших статей про Chaos Engineering расскажу про недавний опыт проверки на прочность приложений в кластере Kubernetes с помощью Open Source-оператора Chaos Mesh.
Использование того или иного продукта в проекте - это всегда попытка найти лучшее решение, балансируя между ограниченным бюджетом, возможностями роста практически по любому сценарию и высотой "порога входа". Существует много продуктов, которые связаны с контейнерами, что выбрать подходящий инструмент становится всё сложнее и сложенее, а community с "промытыми мозгами" и мышлением "ёжиков жрущих кактус" только добавляет сложности (хотя в противовес оным есть хейтеры, которые наоборот обгадят решение, просто потому что в своё время оно им не подошло).
В целом, чтобы выбрать нужное решение чаще всего приходится поднять лабу, которая покроет 90% задач, чтобы понять насколько решение подходящее, а это значит пройти какую-то боль, потратить время и деньги. Но ещё помогают статьи, в которых рассматриваются частные случаи внедрения и подбор инструментов, чтобы научиться на чужих ошибках через объективный взгляд со стороны. Надеюсь, эта статья о том, почему и как мы пришли к решению с werf, поможет кому-то подобрать инструмент для своих нужд.
В этой статье мы рассмотрим подход, при котором разработка приложений ведется непосредственно в кластере Kubernetes, а отдельные операции сборки и деплоя оказываются не нужны. Такую возможность предоставляет сервис Okteto Cloud и одноименная Open Source-утилита от его разработчиков. Идея проекта — сэкономить много времени и сосредоточиться на программировании, не забивая голову подготовкой и настройкой окружения.
GitLab – это мощный и в то же время простой инструмент для организации проектов. Как и любой крупный и самодостаточный продукт, GitLab постоянно развивается и дорабатывается. И сегодня хотелось бы обсудить новый функционал, который пока ещё находится в разработке, но уже доступен для использования. Речь идёт о поддержке размещения Helm-чартов в GitLab Package Registry. Для простоты далее я буду называть его GitLab Helm repo.
Зачастую основой для описания инфраструктуры, запускаемой в Kubernetes, являются Helm-чарты. Поэтому при работе команды инженеров с большим количеством проектов невольно приходят мысли о стандартизации подходов работы с этими чартами. С появлением GitLab 14.1 появилась возможность настраивать хранение общих чартов для всех проектов, с которыми ведется работа.
Сегодня трудно себе представить более переоцененный подход к созданию архитектуры программных решений, чем микросервисы. В сети доступно огромное количество статей и видеолекций, в которых авторы рассказывают о том, что такое микросервисы и зачем они нужны. С чем, в общем, справляются довольно успешно, раскрывая их преимущества и недостатки. Так что эта статья рискует стать очередным пересказыванием очевидных вещей. Поэтому я сосредоточусь на том, чтобы сформулировать и донести до вас то, как я понимаю эту тему, основываясь на опыте тех проектов, в которых имел честь принимать участие. И том совокупном коллективном опыте, что медленно, но верно накапливается в IT индустрии.
Эта статья является моим авторским текстом и не является переводом. Если вы со мной не согласны, желаете дополнить или поделиться своим мнением, я буду рад обсудить вашу взвешенную и аргументированную позицию в комментариях.