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

В основе этого списка — мой личный опыт, и чтобы избежать предвзятости, я расскажу и об альтернативных инструментах, чтобы вы могли всё сравнить и принять решение, исходя из своих потребностей. Постараюсь дать информацию сжато и привести источники, чтобы при желании вы могли изучить всё самостоятельно. Описывая инструменты для различных задач разработки ПО, я хотел ответить на вопрос: «Как я могу сделать X в Kubernetes?»

Немецкая компания SUSE известна в Open Source-сообществе своими дистрибутивами Linux. Но этим ее деятельность не ограничивается. В конце прошлого года SUSE представила новый проект с открытым кодом — гиперконвергентное решение Harvester. Как говорит компания, Harvester — это альтернатива существующим гиперконвергентным платформам enterprise-уровня типа VMware vSAN и Nutanix HCI, адаптированная к cloud native-среде, к тому же полностью бесплатная.

В статье сделаем небольшой обзор Harvester: посмотрим на компоненты, возможности, сильные и слабые стороны.

Привет, Хабр! Сергей Бондарев, архитектор Southbridge и спикер в Слёрме, недавно провёл вебинар «Kubernetes'22: выбор между self-hosted и managed-решением». Сегодня публикуем текстовую версию вебинара.

Некоторое время назад я получил довольно непростую задачу написать техническое задание для нашей службы поддержки на тему OpenID Connect (OIDC).

Тут же я понял, что хоть я и знаком с OAuth и SAML, я не знал практически ничего об OpenID Connect (кроме того, что благодаря этому Pokemon Go получает сведения о моем профиле сразу после авторизации в Google+).

К счастью, мои коллеги подробно посвятили меня во все детали и снабдили необходимыми ресурсами для ознакомления. Хотя, честно говоря, ни одно из объяснений не показалось мне достаточно хорошим и качественным. Поэтому представляю моё видение данного процесса.

Хабр, привет.

Меня зовут Аркадий и я сетевой инженер в одном из сервис провайдеров.  Кому интересны основные отличия VXLAN от Geneve и Overlay протоколы добро пожаловать под кат. Избегая выстрела в ногу, хочу отметить, что основа статьи – это выжимки из RFC и открытой информации WMware.

В NSX-T VMware уходит от Overlay на базе VXLAN в пользу Geneve. Внедрение Geneve лоббируется помимо VMWare такими компаниями как : Intel, Microsoft, Red Hat. Маркетинг в свою очередь называет следующую причину перехода к Geneve : "Geneve сочетает в себе лучшее от протоколов VXLAN (Virtual Extensible LAN), NVGRE(Network Virtualization using Generic Routing Encapsulation), and STT(Stateless Transport Tunneling)." Разберем отличия нового Overlay протокола и почему ему отдано предпочтение ведущими вендорами виртуализации.

Привет, Хабр!

Эта статья - расшифровка доклада с QIWI Server Party

Многие знают, что такое микросервисы и как их оркестрировать. А вот как обеспечить их безопасность, это отдельный вопрос, достойный обсуждения. Потому что если достаточно глубоко не разобраться в том, что и как работает в вашей Kubernetes-инфраструктуре, вашим незнанием могут воспользоваться хакеры или недобропорядочные сотрудники. 

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

В основном взломы происходят по недосмотру конфигурации оборудования, операционных систем и ПО. Хакеры, пользуясь случаем, ловят личную информацию и деньги с банковских счетов. Противостоят им добрые дяди из отдела безопасности, которые защищают приложения и кластера. Я бы хотел включиться в роль такого доброго дяди и подробно рассказать, как обеспечить внутреннюю и внешнюю безопасность Kubernetes и приложений, находящихся в нем.

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

Так сложилось что недавно я поставил себе Home Assistant (далее HA) для управления всем моим зоопарком устройств из одного места, что оказалось довольно удобно. Но без ложки дегтя никуда и нашлось все таки одно устройство, интеграции для которого в HA не было, а привязать его хотелось. Было решено написать собственную интеграцию. Если интересно, что из этого вышло, добро пожаловать под кат.

В Kubernetes есть такая сущность, как secrets, или секреты. Из названия понятно, что эти данные не могут быть общедоступными, и их нужно как-то защищать и особым образом доставлять в кластеры Kubernetes. В статье разберём, что такое secrets и в чём особенности их хранения и доставки. А также рассмотрим два популярных инструмента для работы с секретами: Hashicorp Vault и Helm Secrets.

Home Assistant-это open-source платформа для автоматизации, работающая на Python 3. Позволяет отслеживать и контролировать все устройства в доме и автоматизировать действия. Идеально может работать на одноплатном компьютере Raspberry PI.

RBAC (Role-based access control) — это система распределения прав доступа к различным объектам в кластере Kubernetes.

Объекты в кластере Kubernetes — это YAML-манифесты, а права доступа определяют, какому пользователю можно только просматривать манифесты, а кто может их создавать, изменять или даже удалять.

Рассказываем, как устроен RBAC.

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

Здесь мы посмотрим, как получить доступ к кластеру Kubernetes с помощью GitLab CI/CD и зачем это нужно, если вы взяли курс на GitOps.

Итак, у вас есть кластер Kubernetes, а для проброса внешнего трафика сервисам внутри кластера вы уже настроили Ingress-контроллер NGINX, ну, или пока только собираетесь это сделать. Класс!

Я тоже через это прошел, и поначалу все выглядело очень просто: установленный NGINX Ingress-контроллер был на расстоянии одного helm install. А затем оставалось лишь подвязать DNS к балансировщику нагрузки и создать необходимые Ingress-ресурсы.

Спустя несколько месяцев весь внешний трафик для всех окружений (dev, staging, production) направлялся через Ingress-серверы. И все было хорошо. А потом стало плохо.

Все мы отлично знаем, как это бывает: сначала вы заинтересовываетесь этой новой замечательной штукой, начинаете ей пользоваться, а затем начинаются неприятности.

Home Assistant — это популярная система умного дома, которая автоматизирует привычные бытовые процессы и работает на YAML файлах. В этой статье я расскажу, как настроить Home Assistant (далее HA), и что конкретно я использую в повседневной жизни. Это поможет вам избежать ошибок и быстрее продвинуться в изучении HA.

На Хабре уже есть статьи о HA (раз, два, три), но здесь я хочу рассказать об установке и настройке системы от начала до конца. От первого запуска сервера до полноценно работающей системы, которую потом можно улучшать и дорабатывать для себя.