Kubernetes *

Вчера мы провели первый ознакомительный вебинар «Вечерней школы Слёрма».

Всего записалось на курс 5 015 человек. В первом вебинаре поучаствовало более 3 800 человек. Спасибо всем, кто был с нами. Это было здорово — особенно атмосфера в рабочем чате.

На ознакомительном вебинаре мы затронули такие вопросы:

• Зачем разработчикам и администраторам изучать Кубернетес.
• Какие задачи решает Кубернетес и какой ценой.
• Как устроено обучение в Вечерней школе.
• Что входит в бесплатную теорию и платную практику.

Запись вебинара и основные тезисы ниже:

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

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


О спикере: Александр Хаёров (allexx) 10 лет занимается разработкой, в основном веб-проектами, связанными с инфраструктурой, а сейчас руководит разработкой в Chainstack. В этой должности приходится примерять на себя самые разные роли и заниматься всем: от классической разработки до принятия технических решений и управления людьми. Это позволяет исследовать разные темы, в том числе ту, о которой пойдет речь в статье — далее от первого лица.

Всем привет. OTUS открыл набор в новую группу по курсу «Инфраструктурная платформа на основе Kubernetes», в связи с этим мы подготовили перевод интересного материала по теме.

---

Возможно, вы один из тех, кто использует terraform для Infrastructure as a Code, и вам интересно, как использовать его продуктивнее и безопаснее. В общем-то, последнее время, это многих беспокоит. Мы все пишем конфигурацию и код, используя разные инструменты, языки и тратим значительное количество времени на то, чтобы сделать его более читабельным, расширяемым и масштабируемым.


Может быть, проблема в нас самих?

Написанный код должен создавать ценность или решать проблему, а также быть пригодным для повторного использования с целью дедупликации. Обычно такого рода дискуссии заканчиваются “Давайте использовать модули”. Мы все используем модули terraform, верно? Я мог бы написать множество историй с проблемами из-за чрезмерной модульности, но это совсем другая история, и я не буду.

С 7 апреля российский офис IBM начинает серию еженедельных вебинаров от ведущих российских и европейских экспертов. Мы подготовили для вас много полезного материала на разные темы с практическими примерами из бизнеса: ИИ, облачные технологии, блокчейн, data science, распознавание изображений, контейнеры, чат-боты и пр. Каждый вторник и четверг в 15:00 (по Москве) такие встречи будут проходить в онлайн-формате для всех желающих…

По пятницам в 14:00 мы планируем углубленные онлайн-семинары с практическими работами по облачным технологиям.

Участие в вебинарах и онлайн-семинарах абсолютно бесплатное, всем зарегистрировавшимся будет доступна запись.

Расписание на ближайшую неделю:

• 7 апреля — Модернизация приложений JEE -> Microservices [запись]
• 9 апреля — Строим современную интеграционную платформу
• 10 апреля — Практический семинар "Анализ изображений дронов для выявления повреждённых от огня домов" (на английском языке)

Более подробную программу и запись на вебинары можно найти по ссылке: https://ibm.biz/workshops

Kube-scheduler является неотъемлемым компонентом Kubernetes, который отвечает за планирование подов по нодам в соответствии с заданными политиками. Зачастую, в процессе эксплуатации Kubernetes-кластера нам не приходится задумываться о том, по каким именно политикам происходит планирование подов, так как набор политик дефолтного kube-scheduler’a подходит для большинства повседневных задач. Однако встречаются ситуации, когда нам важно тонко управлять процессом распределения подов, и для выполнения этой задачи есть два пути:

В современном мире Kubernetes-облаков, так или иначе, приходится сталкиваться с ошибками в программном обеспечении, которые допустил не ты и не твой коллега, но решать их придется тебе. Данная статья, возможно, поможет новичку в мире Golang и Kubernetes понять некоторые способы отладки своего и чужого софта.


Меня зовут Виктор Ягофаров, я занимаюсь развитием Kubernetes-облака в компании ДомКлик, и сегодня хочу рассказать о том как мы решили проблему с одним из ключевых компонентов нашего production k8s (Kubernetes) кластера.

В нашем боевом кластере (на момент написания статьи):

• запущено 1890 pod'ов и 577 сервисов (количество реальных микросервисов тоже в районе этой цифры)
• Ingress-контроллеры обслуживают около 6k RPS и примерно столько же идёт мимо Ingress сразу в hostPort.

Слёрму полтора года. Шесть интенсивов только по базовому курсу Kubernetes, плюс Мега, DevOps, SRE и Agile — более тысячи участников.

7 апреля стартует «Вечерняя школа Слёрма: базовый курс по Kubernetes», рассчитанная на 4 месяца занятий по вечерам (бесплатные вебинары по теории и платная практика). В мае пройдет седьмой Слёрм по Kubernetes (онлайн-интенсив, «как офлайн, только онлайн»). Будет всё «по-оффлайновому»: с голосовым чатом, видеосвязью, «курилкой» в зуме, групповой работой, выделенными наставниками и техподдержкой.

Мы заявляем, что Слёрм открывает путь к проектам на Kubernetes и росту зарплаты. Так ли это на самом деле?

Мы задали этот вопрос выпускникам Слёрмов. Полтора года — достаточный срок, чтобы стали заметными изменения в карьере, зарплате, работе и сфере задач.

Что важно понимать про этот опрос? Тут есть «ошибка выжившего»: нам ответили те, кто следит за чатом своего Слёрма и готов общаться. Наверняка есть те, кому Слёрм оказался бесполезен, и они молчат об этом. Жизнь меняется: те, кто начал работать с Kubernetes год назад, были в другом положении, чем те, кто начинает сейчас. Это работает в обе стороны: стать архитектором решений сейчас куда сложнее, а найти место джуниора куда проще.

Тем не менее, ответы вполне показательны. По ним можно понять, ради чего стоит проходить Слёрмы.

Карантин — хороший повод поинтересоваться, как там дела в других бункерах на Пустошах, кто какие технологии использует вместе с Kubernetes, что собирается изучать ещё и в какую сторону двигается, не вставая с кресла. Quarantine. Quarantine Never Changes.

Практически каждый инженер, практикующий DevOps, в какой-то момент сталкивается с задачей настройки правил доступа для своих проектов. В данной статье мы рассмотрим примеры настройки сетевых политик Kubernetes-кластера, в котором используется плагин Calico и осветим некоторые интересные моменты. Предполагаем, что у вас уже имеется кластер k8s, где в качестве сетевого плагина используется Calico.

Вчера, 25 марта, состоялся очередной релиз Kubernetes — 1.18. По сложившейся для нашего блога традиции, мы рассказываем о наиболее значимых изменениях в новой версии.



Информация, использованная для подготовки этого материала, взята из официального анонса, таблицы Kubernetes enhancements tracking, CHANGELOG-1.18, обзоров от SUSE и Sysdig, а также соответствующих issues, pull requests, Kubernetes Enhancement Proposals (KEP)…

В интернете много справочной литературы, но иногда самыми ценными становятся самые простые советы. Команда Kubernetes aaS от Mail.ru перевела подборку из десяти хитростей и советов, которые автор статьи собрала после года работы с Kubernetes. Советы не отсортированы по важности, но думаем, что каждый найдет что-то полезное для себя.

Год назад я понял, что хочу создать собственный кластер Kubernetes. Я — разработчик программного обеспечения. Обычно я либо использую локальный кластер, состоящий из одного узла, либо применяю удалённый многоузловой кластер для тестирования своих проектов. В случае работы с кластером, состоящим из одного узла, я обычно полагаюсь на Minikube, хотя тут есть и другие решения, вроде проекта Kind, который может эмулировать наличие в кластере нескольких узлов. Поддержка нескольких узлов может появиться и в Minikube.

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



Уже написано множество замечательных руководств, посвящённых созданию многоузловых кластеров Kubernetes с использованием одноплатных компьютеров. Во многих из таких руководств в роли SBC применяется Raspberry Pi. Я, видя это, решил пойти по пути наименьшего сопротивления и тоже остановил свой выбор на этом компьютере. Платформа Raspberry Pi зарекомендовала себя как недорогое и доступное решение.

Надо отметить, что выбор этой платформы предусматривает некоторые компромиссы. Например, Broadcom и Raspberry Pi Foundation не лицензировали криптографические расширения ARMv8 (это нужно для аппаратного ускорения поддержки AES). Ещё одним неоднозначным решением является использование microSD-карт в виде стандартного носителя информации, с которого загружается операционная система.

Анализируя существующие руководства по созданию кластеров на одноплатных компьютерах, я не нашёл ни одного, в котором описывалось бы решение, удовлетворяющее моим требованиям. Рассказ о созданном мной кластере я начну именно с них.

werf — наша GitOps CLI-утилита с открытым кодом для сборки и доставки приложений в Kubernetes. Как и обещали, выход версии v1.0 знаменовал начало добавления в werf новых возможностей и пересмотра привычных подходов. Теперь мы рады представить релиз v1.1, который является большим шагом в развитии и заделом на будущее сборщика werf. Версия доступна на данный момент в канале 1.1 ea.

Основа релиза — это новая архитектура хранилища стадий и оптимизация работы обоих сборщиков (для Stapel и Dockerfile). Новая архитектура хранилища открывает возможности к реализации распределенных сборок с нескольких хостов и параллельных сборок на одном хосте.

У компании «Флант» есть ряд Open Source-разработок, преимущественно для Kubernetes, и loghouse — одна из самых популярных. Это наш инструмент для централизованного логирования в K8s, который был представлен более 2 лет назад.



Как мы упоминали в недавней статье про логи, он требовал доработки, и актуальность её со временем только росла. Сегодня мы рады представить новую версию loghouse — v0.3.0. Подробности о ней — под катом.

Сетевой плагин Calico предоставляет широкий набор сетевых политик с унифицированным синтаксисом для защиты хостов на железе, виртуальных машин и pod’ов. Эти политики могут применяться в рамках namespace или быть глобальными сетевыми политиками, применимыми к host endpoint (для защиты приложений, работающих непосредственно на хосте — хостом может быть непосредственно сервер или виртуальная машина) или к workload endpoint (для защиты приложений, работающих в контейнерах или виртуальных машинах, размещенных на хосте). Политики Calico позволяют применить меры безопасности для различных точек пути пакетов с помощью таких параметров, как preDNAT, untracked и applyOnForward. Понимание того, как эти опции работают, может помочь повысить безопасность и производительность системы в целом. В этой статье объясняется суть данных параметров политик Calico (preDNAT, unraracked и applyOnForward), применяемых к host endpoints, с акцентом том, что происходит в путях обработки пакетов (цепочек iptabels).

Прим. перев.: Американский DevOps-инженер Sid Palas, пользуясь недавним анонсом Google Cloud как инфоповодом, провёл сравнение стоимости услуги Managed Kubernetes (в разных конфигурациях) от ведущих мировых облачных провайдеров. Дополнительным плюсом его работы стала публикация соответствующего Jupyter Notebook, позволяющего (при наличии минимальных знаний Python) подкорректировать производимые расчёты под свои нужды.

TL;DR: Azure и Digital Ocean не взимают плату за вычислительные ресурсы, используемые для управляющего слоя (control plane), что делает их подходящим выбором для развертывания множества небольших кластеров. Для запуска малого количества крупных кластеров лучше всего подходит GKE. Кроме того, можно серьезно сократить затраты, используя спотовые/вытесняемые/низкоприоритетные узлы или «подписавшись» на длительное использование одних и тех же узлов (это касается всех платформ).

Если вы используете Docker, следующим логичным шагом кажется переход на Kubernetes, он же K8s, правильно? Ну, предположим. Однако решения, предназначенные для 500 инженеров-программистов, одновременно разрабатывающих одно приложение, достаточно сильно отличаются от решений для 50 человек. А решение для команды из 5 программистов — это и вовсе другая история.

Если вы работаете в маленькой команде, Kubernetes, вероятнее всего, не для вас. Он принесет вам много боли в обмен на крайне скромные преимущества.
Давайте разберемся, почему это может произойти.

Привет, Хаброжители! Kubernetes – один из ключевых элементов современной облачной экосистемы. Эта технология обеспечивает надежность, масштабируемость и устойчивость контейнерной виртуализации. Джон Арундел и Джастин Домингус рассказывают об экосистеме Kubernetes и знакомят с проверенными решениями повседневных проблем. Шаг за шагом вы построите собственное облачно-ориентированное приложение и создадите инфраструктуру для его поддержки, настроите среду разработки и конвейер непрерывного развертывания, который пригодится вам при работе над следующими приложениями.

• Начнете работу с контейнерами и Kubernetes с азов: никакого специального опыта для изучения темы не требуется. • Запустите собственные кластеры или выберете управляемый сервис Kubernetes от Amazon, Google и др. • Примените Kubernetes для управления жизненным циклом контейнера и расхода ресурсов. • Оптимизируете кластеры по показателям стоимости, производительности, устойчивости, мощности и масштабируемости. • Изучите наилучшие инструменты для разработки, тестирования и развертывания ваших приложений. • Воспользуетесь актуальными отраслевыми практиками для обеспечения безопасности и контроля. • Внедрите в компании принципы DevOps, чтобы команды разработчиков стали действовать более гибко, быстро и эффективно.

Четвертая версия OpenShift вышла сравнительно недавно. Актуальная на текущий момент версия 4.3 доступна с конца января и все изменения в ней — это или нечто совершенно новое, чего в третьей версии не было, или крупное обновление того, что появилось в версии 4.1. Все, что мы сейчас расскажем, нужно знать, понимать и учитывать тем, кто работает с OpenShift и планирует переходить на новую версию.

С выпуском версии OpenShift 4.2 Red Hat упростила работу с Kubernetes. Появились новые инструменты и плагины для создания контейнеров, CI/CD-конвейеров и serverless-развертываний. Нововведения дают разработчикам возможность сосредоточиться на написании кода, а не на разбирательствах с Kubernetes.

Собственно, что нового в версиях OpenShift 4.2 и 4.3?

Расскажем, как использовать CRD Kubernetes, чтобы автоматизировать безопасность и обеспечить защиту ваших приложений.

Перевод от команды журнала «Завтра облачно» Mail.ru Cloud Solutions. Источник: Niteen Kole How to Automate Container Security by Using CRDs to Get Security Policy as Code с дополнениями.

Типовое условие при реализации CI/CD в Kubernetes: приложение должно уметь перед полной остановкой не принимать новые клиентские запросы, а самое главное — успешно завершать уже существующие.



Соблюдение такого условия позволяет достичь нулевого простоя во время деплоя. Однако, даже при использовании очень популярных связок (вроде NGINX и PHP-FPM) можно столкнуться со сложностями, которые приведут к всплеску ошибок при каждом деплое…