В Kubernetes очень легко настраивается работа с SSL, это наверное одна из главных причин почему я и начал им пользоваться, в этой статье я опишу простой сценарий его подключения.
Когда в команде нет DevOps - инженеров, но очень хочется задеплоить приложение в Kubernetes, можно легко это сделать с помощью https://microk8s.io, в данном посте я опишу как это сделать и открыть доступ к приложению на определенном порте.
В этой статье рассмотрим, как можно организовать простое управление секретами для приложений в Kubernetes при использовании GitOps-подхода. Храним секреты в git безопасно и управляем ими из Helm-чарта приложения.
Работая DevOps-инженером, я часто сталкиваюсь с необходимостью глубоко погружаться в механизмы работы контейнерных оркестраторов. Важность хорошего знания архитектуры и оптимизации управления контейнерами трудно переоценить, особенно когда речь идёт о Kubernetes. Эта технология стала неотъемлемой частью моего инструментария благодаря её возможностям в автоматизации развёртывания, масштабирования и управления контейнерными приложениями.
Однако управлять микросервисной архитектурой в Kubernetes бывает весьма сложно. И здесь на помощь приходит Istio — мощная платформа, обеспечивающая сетевое взаимодействие, безопасность и наблюдаемость в кластере Kubernetes. В этой статье мы рассмотрим основы Istio и её начальную настройку.
Каждому твоему разработчику нужна база близко похожая на продакш, но она очень тяжелая, чтобы каждое утро выкачивать её к разработчику в его локальную среду, теперь есть решение - поможет aldaas.
Привет! Я Александр Хренников — руководитель DevOps-юнита в KTS. Первый коммит в репозиторий kubernetes был сделан 10 лет назад, 6 июня 2014 года. За это время kubernetes прошёл большой путь и стал самым популярным средством оркестрации контейнеров.
Предлагаю вам посмотреть, каким он был в то время, и попробовать запустить в нём приложение самостоятельно.
Заодно приглашаем принять участие в челлендже по запуску kubernetes из самого первого коммита. Это продолжение нашего совместного челленджа c Yandex Cloud на KuberConf / 24, где мы запускали приложение без ошибок на инфраструктуре облака.
Если собирать компоненты с нуля желания нет, а запустить их хочется уже сейчас, участвуйте в Kube01 Challenge по запуску k8s v.0.1 на инфраструктуре Yandex Cloud. Принять участие и выиграть мерч с Котзиллой можно по ссылке.
В это нелегкое время, так сложно найти работу, когда первокурсники МИРЭА уже пишут курсовые с микросервисами на 1к рпс, а выпускники каждый по системе на миллиарды пользователей. Видимо старому Java-коту ничего не остается, кроме как беседовать с вечностью и её сестрой бесконечностью. Если не они, то кто поможет коту найти работу?
Статью можно прочесть в формате pdf.
Привет, меня зовут Борис Литвиненко, я занимаюсь SRE и DevOps в Yandex Infrastructure. Такие задачи я решаю уже очень давно, последние 10 лет — в Яндексе.
Естественно, в инфраструктурных подразделениях мы не гнушаемся и разработкой: все описанные в этом материале события происходят в группе разработки сетевой инфраструктуры и мониторинга, где мы делаем всё, что касается сети и какой‑то автоматизации. А как вы понимаете, сетевая инфраструктура большей своей частью не может зависеть от остальных сервисов.
Сегодня я расскажу о нашей специфике обслуживания базовой части инфраструктуры и причинах, которые привели к необходимости всё стандартизировать, а также выбрать облачный подход и запуститься в k8s. Но давайте всё по порядку.
Имея за плечами опыт работы с Kubernetes в различных облачных провайдерах вроде AWS и Yandex Cloud я столкнулся с необходимостью развертывания кластера вне облака на виртуальных машинах.
В статье расскажу про то, как подготовить high-availability кластер, используя инструмент под названием RKE2 - Rancher Kubernetes Engine.
Управление секретами и почему это так важно для нас?
Привет! Меня зовут Евгений, я работаю на позиции Lead DevOps в EXANTE. В этой статье мы разберем жизненный опыт сетапа high availability Hashicorp Vault с gcp storage backend и autounseal в k8s.
Некоторое время назад наша инфраструктура состояла из тысяч виртуальных и железных машин, на которых были размещены наши легаси сервисы. На эти машины, частично руками, частично при помощи chef, распространялись конфигурационные файлы с уже вписанными секретами в открытом виде.
По целому ряду причин, включающих в себя ускорение процессов доставки кода, обеспечение беспрерывности доставки и безопасного хранения секретов, а также ускорение развертывания новых приложений и окружений, было принято решение о смене стратегии компании.
Мы решили сделать наш продукт cloud native, и для этого нужно было изменить подход к разработке и инфраструктуре, провести рефакторинг наших легаси сервисов, начать двигаться в сторону микросервисной архитектуры, разворачивать сервисы в cloud k8s, использовать managed ресурсы (redis, postgres).
В наших реалиях под изменения попасть должно было все – от приложений и инфраструктуры до методов распространения конфигов и секретов. В качестве облачного провайдера был выбран Google, а хранилищем секретов был выбран Hashicorp Vault. На данный момент мы довольно успешно прошли большую часть пути.
Почему Hashicorp Vault?
У нас есть несколько причин:
Сегодня микросервисы требуют постоянного стремления к автоматизации и оптимизации. В этой статье рассмотрим такой инструмент в Kubernetes, как Horizontal Pod Autoscaler или сокращенно HPA.
Kubernetes — самый популярный оркестратор в России. По данным исследования VK Cloud «State of Kubernetes», K8s используют 56% компаний, работающих с оркестраторами (причем из них 53% работают с Kubernetes в облаке). Более того, спрос на работу с технологией увеличивается. Вместе с тем многие компании сталкиваются с недостатком опыта, что приводит не только к техническим сложностям, но и к неоправданным расходам.
Рассказываем, почему работа с Kubernetes может оказаться «тяжелой ношей» для бюджета компании и как этого избежать.
Всем привет! В данной статье хотелось бы рассказать о небольшом исследовании Kubernetes ограничений и рекомендаций, а так же что будет если их нарушить и о том что это может быть в некоторых случаях полезно и даже экономически выгодно. Будет рубрика "Ээээксперименты!", поищем проблемы, попробуем их решить и посмотрим что получиться.
Среда оркестрации контейнеризированных приложений Kubernetes получила в последние годы широкое распространение.
Для этого есть множество причин. Прежде всего это все те преимущества, которые дает использование контейнеров: возможность построения микросервисной архитектуры, когда мы можем разделить приложение на отдельные компоненты, работающие в контейнерах и реализовывать в них нужный нам функционал независимо от других элементов нашего решения. Также, контейнеры позволяют эффективнее использовать оборудование, их удобно применять там, где нужно развернуть несколько идентичных экземпляров приложения, например, при миграции из среды разработки в среду тестирования.
Когда серверов, на которых запущены контейнеры становиться несколько десятков и более, возникает необходимость в использовании инструмента для централизованного управления узлами контейнеризации и здесь на помощь приходит Kubernetes. С его помощью можно развернуть множество экземпляров одного приложения, автоматически поддерживать необходимое их количество, обеспечить прозрачный для пользователей процесс обновления множества микросервисов из которых оно состоит, разграничить доступ к разным экземплярам контейнеров и многое другое.
Таким образом, совершенно очевидно, что Kubernetes является по сути основой для всей инфраструктуры, на которой работает приложение и то, насколько безопасно оно будет работать во многом зависит от того, насколько правильно будет настроена сама среда оркестрации.
Конечно, можно внедрить различные механизмы защиты, например ролевую модель доступа, о которой мы уже говорили ранее, но судить о том, насколько хорошо защищена та или иная система можно только попытавшись пойти по пути хакера, то есть попытаться ее взломать. В реальной жизни эту задачу обычно выполняют так называемые «белые хакеры» – пентестеры. В этой статье мы попробуем посмотреть на безопасность Kubernetes как раз глазами пентестеров.
Привет! Меня зовут Александр, я MLOps-инженер.
JupyterHub — централизованный инструмент для создания Jupyter-ноутбуков для разных пользователей по заранее заданным параметрам, который используется более чем 200 специалистами у нас на проекте с коллегами из Альфа-Банка.
Сейчас множество сервисов Альфа-Банка могут запускаться в Kubernetes, который уже стал стандартом. И JupyterHub не исключение. Есть много статей по его запуску, и в большинстве из них описано, как просто поднять данный сервис и запустить рабочий ноутбук на базе профилей. Каждый профиль представляет собой заранее настроенные параметры для Pod ноутбука.
Однако с ростом числа пользователей возникают различные проблемы, о которых мы поговорим в этой статье.
Apache Airflow — это один из самых популярных ETL-шедулеров. ETL-процессы — это когда мы выбираем интересующие нас данные, приводим их к агрегированному виду и сохраняем для дальнейшего использования. И это присутствует везде, где есть необходимость анализа данных. Соответственно, Airflow предназначен для того, чтобы запускать пайплайны обработки данных.
Сегодня официально выпустили новую версию Kubernetes — 1.31. Среди главных нововведений — VolumeSource, поддерживающий OCI-образы и/или OCI-артефакты и поле SupplementalGroupsPolicy для контроля дополнительных групп, которые присоединяются к первому процессу в контейнере, а также флаг --emulation-version для эмулирования возможностей предыдущих версий Kubernetes и механизм, который позволяет пользователям настраивать, к каким эндпоинтам возможен анонимный доступ.
В марте мы рассказывали, как хакеры ломают банки (за 48 часов!) и какие ИБ-продукты их защищают. Standoff 13 принес нам новые кейсы. Начнем с разбора взлома облачной инфраструктуры хостинг-провайдера Nodenest, который работал в вымышленном Государстве F. Вас ждет история о том, как продукт для защиты контейнерных сред PT Container Security (PT CS) поймал крайне интересный kill chain на уровне рантайма.
Сегодня Kubernetes доминирует на рынке как основное средство для оркестрации контейнеров, что делает тестирование этих систем чрезвычайно важным. Для большинства стандартных тестов достаточно использовать команду kubectl, однако для более глубокого тестирования сертификации версий Kubernetes идеально подходит инструмент Sonobuoy.
Sonobuoy — это инструмент для диагностики и тестирования кластеров Kubernetes. Он используется для проверки соответствия кластера стандартам и спецификациям CNCF (Cloud Native Computing Foundation) и для обнаружения потенциальных проблем в работе кластера.
Sonobuoy запускает серию тестов на кластере Kubernetes, включая тесты из набора End-to-End (E2E) тестов Kubernetes, чтобы проверить, правильно ли настроен и работает ли кластер. Эти тесты включают проверки на соответствие стандартам CNCF, а также могут включать дополнительные плагины для расширенного тестирования.
