Kubernetes *

Существует множество альтернатив для доступа к модулю извне кластера. Шлюз API - это определенно новинка этой области, и потому выбран темой этой статьи.

Ранее мы описывали несколько способов доступа к модулям Kubernetes. Так, например, доступ к модулю pods можно получить через его IP-адрес, но важно учитывать, что поды по своей сути являются временными. Штатный способ - настроить Service: в этом случае IP-адрес стабилен, а задача Kubernetes - обеспечивать мапироание между Service и соответствующими ей подами. В настоящий момент доступны различные виды сервисов: только внутренние, NodePort, позволяющий открыть доступа извне кластера, и LoadBalancer, который полагается на сторонний компонент - обычно это на облачный провайдер. Не будем забывать и об Ingress, обеспечивающем маршрутизацию.

Ну а API-шлюз, как новинку в этой области, мы оставили на десерт, решив посвятить ему целый пост.

В погоне за лучшей или, правильнее сказать, удобной жизнью я начал искать решение, которое помогало бы писать чарты для Kubernetes и лучше разбираться в зависимостях — что, куда и откуда подставляется в созданных чартах. Так я наткнулся на программу под названием Monokle. В ее описании сказано: «Вы сможете составлять чарты, быстро находить какие либо несовместимости или неправильный код, а также деплоить ваши чарты сразу в K8s». Глаза загорелись, я приступил к установке.

Из этой статьи вы узнаете, зачем нужны моки для модульного тестирования операторов Kubernetes и как их писать. Эти концепции применимы к операторам на разных языках и фреймворках. Здесь мы будем использовать Golang, controller-runtime и библиотеку testify.

На самом деле почти никто не знает, что такое GitOps. Я тоже заблуждался, пока не начал готовить доклад, а потом статью по этой теме. Самое распространенное определение GitOps — это «хранение состояния в Git», но оно не единственное и не самое главное. Это звучное словечко  придумали в Weaveworks, но его название несколько разнится с его реальным пониманием. Созвучие с DevOps — скорее, маркетинговый ход, чем реальное отражение сущности. Основная идея GitOps в том, что помимо хранения состояния в Git, у нас есть непрерывный процесс его синхронизации с реальным миром, то есть, что у вас Kubernetes-кластере или где либо ещё в вашем окружении.

Меня зовут Андрей Квапил. Я работал в чешском хостинге WEDOS. Он не сильно популярен в России, но это крупнейший хостинг на территории Чехии (просто Чехия маленькая).  Сейчас я работаю во Фланте, но именно на примере европейского хостинга WEDOS, хочу рассказать историю имплементации GitOps.

Хочу рассказать об интересном эксперименте, суть которого заключалась в развертывании и настройке Kubernetes на двух старых ноутбуках — один из них, кроме того, был с процессором на архитектуре i386. В качестве теоретической основы использовалось руководство Kubernetes The Hard Way, которое по ходу дела пришлось немного доработать, а в качестве системы на хостах — Gentoo (да, вам не показалось). Давайте погрузимся в этот увлекательный хардкор!

Введение

Кто-нибудь из вас когда-нибудь слышал о теории “Чёрный лебедь”? Если говорить вкратце, то данная теория рассматривает труднопрогнозируемые события, которые несут за собой огромные последствия для всей системы. К примеру, ваш кластер k8s располагается в ДЦ в конкретно взятом регионе. Всё было прекрасно, но с берега пришло цунами и его затопило, вследствие чего все сервера стали недоступны и ваше приложение не работает. Так кто же в этом будет виноват? Карма? Подводные землетрясения? Ответ прост - вы сами.

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

Стоявшая передо мной задача: улучшить инфраструктуру и качество работы приложения, успевшего вырасти из MVP и стенда для одного клиента в популярный SaaS. Отсутствие отказоустойчивости и масштабируемости компонентов сервиса начало ощутимо мешать пользователям. Настала пора адаптировать приложение под кластерный режим.

Приложение работало в контейнерах, а оркестрация осуществлялась с помощью Docker Compose. Компоненты приложения не задумывались готовыми к запуску в кластерном режиме, что, разумеется, нормальная ситуация для раннего этапа многих проектов: бизнес требует быстрой доставки новых функций, и на преждевременную оптимизацию не всегда можно и нужно тратить время. Но в какой-то момент именно стабильность и быстродействие становятся самыми важными функциями. 

Каково мигрировать приложение с уже сформированным техническим стеком и базой пользователей? Какие есть варианты решения, подводные камни? Как оценить есть ли смысл в таких трудозатратах? В этой статье я поделюсь своим опытом переноса приложения из Docker Compose в Kubernetes.

Представим, что мы маленькая компания. Мы хотим перенести рабочие нагрузки в Kubernetes, но нас очень волнует вопрос безопасности. Мы уже создали кластеры, опираясь на рекомендации по безопасности из официальной документации Kubernetes. Бизнес растёт, и нам нужно что-то изменить, чтобы защитить среду Kubernetes и в то же время управлять действиями конечных пользователей в кластере. Мы используем встроенные возможности Kubernetes, вроде управления доступом на основе ролей (RBAC), политик безопасности pod’ов, политик сети, управления secret’ами и т. д.

В какой-то момент мы понимаем, что нам нужны более детальные настройки. Например, мы хотим запретить развёртывание pod’ов, если образ поступает из ненадёжного реестра. Встроенных функций нам уже не хватает, и мы начинаем обдумывать собственные политики, удовлетворяющие нашим требованиям.

Допустим, мы сформулировали политики. Как теперь легко и быстро применить их в среде Kubernetes? В статье мы ответим на этот вопрос.

Статья продолжает наш обзорный цикл о PostgreSQL-операторах для Kubernetes. В первой части мы рассматривали операторы Stolon, Crunchy Data и Zalando. Во второй — KubeDB и StackGres, а также объединили все пять операторов в сравнительную таблицу. В этот раз разбираем решение CloudNativePG, его возможности и особенности, а заодно актуализируем таблицу.

Сложные серверные приложения могут включать десятки и сотни микросервисов, которые могут как предоставлять точки подключения для клиентов, так и взаимодействовать между собой и своими хранилищами данных. Естественным образом при развертывании таких приложений приходится решать две задачи: как поддерживать сервисы в работоспособном состоянии (здесь может помочь Kubernetes или любая другая система оркестрации) и как их регистрировать и связывать с префиксами или адресами публикации для внешних клиентов? Также весьма остро встает вопрос мониторинга взаимодействия микросервисов и организации нагрузочных тестов как на отдельные сервисы, так и на целые группы.

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

OPA можно интегрировать практически куда угодно, включая Kubernetes. Из этого материала вы узнаете, как интегрировать OPA в Kubernetes, и на примерах рассмотрите преимущества этой интеграции. В Kubernetes мы развертываем OPA как контроллер доступа. 

Kubernetes последовательно захватывает все новые ниши для декларативного описания ожидаемого состояния и теперь ресурсами Kubernetes можно управлять облачными провайдерами (например, через Crossplane), создавать и масштабировать функции (KNative) и многим другим. И кажется интересной идея конфигурирования через Kubernetes физических устройств, имеющих механизм удаленного управления и отправки информации о текущем состоянии. В CNCF был зарегистрирован проект (сейчас находится в sandbox) Akri, который предлагает модель унифицированного управления устройствами умного дома и в этой статье мы рассмотрим основные аспекты конфигурирования Akri на примере udev и OPC UA.

При деплое в Kubernetes часто требуется выкатывать ресурсы в определённом порядке, а иногда и дожидаться готовности сторонних ресурсов. Например, нужно сначала запустить БД, дождаться создания динамического Secret’а сторонним оператором, потом выполнить инициализацию или миграции БД, а уже затем запустить само приложение. 

Рассмотрим, как решать такие задачи с помощью Helm, а также сравним с более быстрым и удобным вариантом, который предлагает Open Source-утилита werf.

Преимуществом Kubernetes является его расширяемость. Одним из способов расширения Kubernetes является написание собственных кастомных контроллеров (custom controllers). Вы можете написать кастомные контроллеры, которые обрабатывают встроенные объекты Kubernetes, такие как Deployment, Service, или вы можете добавить новые кастомные ресурсы в Kubernetes и написать кастомный контроллер для их обработки.

Недавно мы разрабатывали Custom Resource Definition (CRD) для Postgres. В процессе разработки CRD была изучена библиотека client-go в Kubernetes. Она содержит различные механизмы, которые вы можете использовать при разработке своих кастомных контроллеров. Эти механизмы определены в папке tools/cache библиотеки.

Мы подготовили наглядную иллюстрацию, показывающую, как работают различные компоненты библиотеки client-go и их взаимодействие с кодом кастомного контроллера, который вы напишете.

Доброго времени суток, дорогой читатель!

Последние несколько лет в решении бизнес задач прогрессирует тренд использования Искусственного Интеллекта. Перед специалистами, отвечающими за инфраструктуру встают вопросы о том, какие решения они могут предложить ML-специалистам для закрытия их потребностей в отказоустойчивой и гибкой инфраструктуре с учетом специфических потребностей сферы ML. В том числе растет число инструментов и фич, которые они предоставляют, и многие задаются вопросом: как собрать свой MLOps-стек, чтобы он был удобный, (желательно) бесплатный и закрывал большинство распространенных потребностей.

В сегодняшней статье рассмотрим способы реализации model serving, то есть инструментов, которые нужны для того, чтобы подготовить модель к деплою и запустить в Kubernetes.

Накопить за 7 лет терабайты данных в монолите и решить, что пора оптимизировать систему и разбивать её на микросервисы — страшный сон для айтишника. Добавим сюда ещё база на решениях от 1С и необходимость обеспечить непрерывность процесса. Стало страшно? А для нас — возможность показать экспертность и решить нетривиальную задачу. О том, как «кролик» помог сдвинуть гору рассказал архитектор 1С компании «Автомакон» Виталий Осиповский.

С 2013 года ВкусВилл проводил внутреннюю автоматизацию с использованием программ на базе 1С. За годы активного развития и эксплуатации база увеличилась до нескольких терабайт, кратно выросло количество операций, что спровоцировало большой объем работы для администраторов, оптимизаторов и команды разработчиков. Например, тяжелые алгоритмы планирования, закрытий, генерации документов могли негативно влиять на работу всей базы.

Любые сбои и простои были неадекватно затратны и влияли на все компоненты системы в целом. А сама система не годилась для быстрого масштабирования бизнеса. Поэтому уже в 2020 году приняли решение о поэтапном разделении монолита на отдельные программные компоненты.