Однажды, в ходе планового обновления кластера Kubernetes, мы обнаружили, что почти все POD'ы (около 500 из 1000) на новых(обновленных) узлах не смогли запуститься. Минуты ожидания быстро превратились в часы. Мы активно искали первопричину...3 hours later... Спустя три часа POD'ы всё ещё находились в состоянии ContainerCreating.
Пользоваться общей инфраструктурой Docker очень удобно. Тысячи готовых образов, доступных вам через одну команду в консоли, в любом месте, где есть интернет. Ничего удивительного в том, что это вошло в обиход большого числа разработчиков. Но образы контейнеров занимают много места, и качать некоторые из них довольно долго. Зачастую хочется иметь свой или хотя бы локальный реестр. Да и безопаснее это... Наверное?
Зная, что в Docker private registry отсутствует авторизация, я решил разобраться, как легким способом можно блокировать различные действия для клиентов и разрешать все админам. Мне нужно было ограничить получение какой-либо информации по репозиториям, находящимся в реестре, выгрузку образов из реестра, а также запретить загрузку репозиториев, которые уже существуют в реестре. Начнем с основы основ — загрузки и выгрузки образов с помощью API v2.
Привет, всем! В данной статье мы расскажем о Highly Available исполнении CI/CD платформы Gitorion. В данном случае платформа размещается в двух дата центрах. При отказе любого из дата центров команда разработчиков может продолжить непрерывную интеграцию и доставку в выжившем дата центре.
Каждый, кто работал с Helm чартами, сталкивался с необходимостью валидации values.yaml. Стандартный подход с использованием JSON Schema работает, но часто становится громоздким и ограниченным. В этой статье я хочу представить Helm CEL — плагин, который позволяет использовать Common Expression Language (CEL) от Google для валидации конфигурации Helm чартов.
В данной статье будет показан процесс установки и настройки Mattermost (team-edition) и Jitsi (с авторизацией по JWT токену) в Kubernetes кластер.
В статье на примере приложения Podinfo показывается, как Kubernetes с помощью iptables управляет трафиком, предназначенным для этого приложения. Вместе с автором вы развернёте Podinfo, включите трейсинг iptables и проанализируете его вывод. Это поможет разобраться в сетевой инфраструктуре кластера и понять, как работают Kubernetes Services.
Привет, Хабр! Меня зовут Сулейман, и я Senior Software Engineer более чем с 10 годами опыта в программировании. Я разрабатываю сложные веб-сервисы, способные масштабироваться и выдерживать высокие нагрузки, а также активно участвую в open source проектах, публикую статьи, связанные с разработкой, и видео по решению алгоритмических задач. Я являюсь сертифицированным Kubernetes Application Developer (CKAD), и мой опыт охватывает различные сферы разработки: от бэкенда и фронтенда до DevOps и разработки Android-приложений. Больше моих статей можно найти в меди вАЙТИ.
OpenShift и Kubernetes (K8s) выбирают чаще всего для оркестровки контейнеров. Эти инструменты сложно сравнивать напрямую, поскольку Kubernetes — открытое решение (open source), а OpenShift — продукт (дистрибутив) на основе Kubernetes. В этой статье рассмотрены их основные функции и отличия, модели развёртывания и пригодность для различных вариантов использования.
Статья будет полезна тем, кто пока не знаком с этими инструментами и хочет узнать о них больше.
Kubernetes сейчас массово используют в ЦОДах и облачных решениях. Какие заслуги у Кубера, что было до него и почему сейчас он едва ли не стандарт отрасли. А ещё, как понять, что Кубер вам ни к чему.
Привет, Хабр! Сегодня мы попробуем развернуть простой сервис в Kubernetes на примере KaaS в облачной платформе Рег.ру. В качестве самого сервиса будем использовать imgproxy — минималистичный сервис подготовки изображений для web с предельно простым API.
Этот гайд будет полезен новичкам, которые только начинают работу с Kubernetes. Рассмотрим, как настраивать среду и управлять ей, и освоим принципы работы с контейнерами. Кроме того, развертывание imgproxy в качестве примера поможет научиться обрабатывать изображения с помощью Kubernetes простым и удобным способом.
Есть колоссальная разница между тем, чтобы поднять на коленке небольшой кластерок Kubernetes на 5 воркеров для небольшого отдела разработчиков и внедрить его в виде полноценной платформы в большой компании. В домашней лаборатории или небольшом отделе вы почти не сталкиваетесь с вынужденно тяжеловесными бизнес-процессами и необходимостью заставить корректно работать вместе не только ПО разных версий, но и множество людей.
Когда мы в Газпромбанке ввязались в цифровую трансформацию, то сразу почувствовали, что в финале это будет даже близко не «Кубером с аутентификацией», как кажется многим с опытом небольших внедрений.
Если вы тоже поняли, что большие монолиты и сложные релизы не дают вам меняться с нужной скоростью, то наша история может оказаться полезной. Я попробую рассказать, на каком стеке мы выстраивали нашу платформу, про боль и унижение Open Source и о том, как работали с командой.
Узнайте о ключевых изменениях в Deckhouse Kubernetes Platform за последние четыре релиза. Внедрение Grafana 10, поддержка Windows для Deckhouse CLI, автоматическая изоляция проблемных узлов с помощью Fencing, отказоустойчивый egress gateway и другие изменения, которые помогут улучшить управление кластерами.
Привет, Хабр!
Сегодня поговорим о Volume Snapshots — штуке, которая позволяет создать мгновенный «снимок» данных в Kubernetes, практически как Ctrl+S, только для объёмов дисков.
Volume Snapshot — это снимок данных на уровне диска, позволяющий сохранить текущее состояние PersistentVolume или его клон. В основном это полезно для бэкапов и восстановления, а также для таких задач, как миграция данных или клонирование систем.
Привет, меня зовут Всеволод, я разработчик в Yandex Infrastructure — команде, которая создаёт платформу для разработчиков Яндекса. Последние 12 лет я занимаюсь внутренним облаком и за это время писал самые разные его компоненты: от базовой инфраструктуры хостов и до Control Plane.
Сегодня расскажу про то, как мы организуем для наших пользователей единое управление всей инфраструктурой и как добились на этом пути надёжности, скорости разработки, простоты поддержки и масштабируемости — хоть и нарушили при этом некоторые руководства и лучшие практики Kubernetes.
Привет, Хабр!
Сегодня у нас на повестке дня тема миграции данных в Kubernetes. Kubernetes — это как швейцарский нож в разработке: умеет всё и сразу. Он не только управляет контейнерами, но и отлично справляется с данными.
Меня зовут Максим Набоких, и я один их тех, кто участвовал в разработке Structured Authentication Config. Это крупнейшее изменение в системе аутентификации в Kubernetes за последние годы, которое появилось в версии 1.29. В статье я расскажу о предпосылках появления нового аутентификатора и покажу сценарии, в которых он полезен.
Совсем недавно разработчики, применяющие сканер образов Trivy, столкнулись с ошибкой TOOMANYREQUESTS. Она произошла из-за достижения максимального количества пользователей инструмента и предельной скорости по загрузкам из Container Registry (CR) ghcr.io.
Меня зовут Алиса Кириченко, я занимаюсь разработкой контейнерной платформы «Штурвал». Мы вовсю используем Trivy, но совсем не хотим зависеть от доступности сторонних сервисов. Иначе заказчики не поймут. Поэтому базы у нас свои, и обновляются они каждую ночь.
Если лень дальше читать, то вот, берите:
Trivy DB: public.shturval.tech/trivy-db
Trivy Java DB: public.shturval.tech/trivy-java-db
Детали — под катом.
Привет, Хабр! Расскажу про единый деплой для всех приложений в кластер K8s и поделюсь, как нам удаётся жить без OPA rules и не допускать дичи некорректных манифестов в кластере.
В современной инфраструктуре нет недостатка в решениях для балансировки и межсервисных коммуникаций. Почти все используют nginx, HAProxy, есть адепты Treafik, а публичные облака предлагают Load Balancer как сервис. Но что делать, если инструменты не справляются с ростом масштабов и необходимо автоматизируемое cloud-native-решение?
Я Дмитрий Самохвалов, архитектор в K2 Cloud. В этой статье поделюсь, как мы из-за ограничений старых систем для динамической конфигурации перешли с работающих решений nginx и HAProxy на модный Envoy. Расскажу, почему сочли это решение подходящим, какие возможности есть у Envoy, каким был опыт внедрения и оставлю рекомендации для эффективного перехода. Будет полезно разработчикам cloud-native-приложений и инфраструктуры, а также всем, кто хочет создать единое платформенное решение для взаимодействия сервисов и инфраструктуры.
