Русский
Русский
English
Статистика
Реклама

Kubernetes

Как изменился поиск черной кошки в темном Kubernetes

10.12.2020 08:11:12 | Автор: admin

Немного (в)водной


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


Как и у любой системы, сложности с Kubernetes возникают уже на этапе настройки безопасной конфигурации и обслуживания: интерфейсы CRI, CNI, CSI, точки встраивания и изменения, CRD, кастомные операторы и контроллеры, различные версии API и т.д. При этом далеко не все команды разработки в полной мере знают, как все работает внутри инфраструктуры.


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


Незащищен по умолчанию


В Kubernetes существует множество механизмов безопасности: RBAC, NetworkPolicy, PodSecurityPolicy (seccomp, AppArmor, SeLinux) и т.д. Но они по умолчанию отключены. Сделано это для того, чтобы первый опыт использования платформы был удачным, а запуск или перенос приложений не был ничем усложнен. При миграции в новое окружение дополнительные ограничения создают проблемы в работе приложений, которые могут сказаться на процессах всей компании.


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


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



Если ИБ-специалист отвечает за безопасность всей инфраструктуры, то атакующему стоит найти всего один изъян и уделить внимание одной конкретной области, чтобы скомпрометировать всю систему.


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


Черная кошка в темном Kubernetes


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


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


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


Подходы к безопасности облачных технологий


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


Выделим подходы, которые стоит рассмотреть при работе с инфраструктурой Kubernetes:


  • Подход Zero Trust (нулевое доверие) модель безопасности, при которой нет доверия ни к кому и ни к чему, т.е. все пользователи и устройства должны подтверждать свои данные каждый раз, когда они запрашивают доступ к какому-либо ресурсу внутри или за пределами сети;
  • Графовая модель модель безопасности и представления данных, основанная на графе, который показывает все возможные последовательности действий или отношения между процессами. Согласно специалистам ИБ из Microsoft, сейчас безопасность думает списками, а нападающий графами, и пришло время использовать против злоумышленников их же оружие;
  • Безопасность Runtime технология безопасности, которая обнаруживает и блокирует аномалии в приложениях в реальном времени с помощью добавления функций защиты в среду исполнения;
  • Поиск аномалий, которые связаны не только с атаками, но также с проблемами некачественно написанного кода или неправильной конфигурацией.

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


Luntry подойдет вашей компании, если вам нужна удобная и эффективная платформа для работы подразделений ИТ и ИБ, при этом не требующая уникальных навыков от специалистов, работающих с ней.


Выводы и напутствия


Каждая инфраструктура Kubernetes уникальна, а следовательно, уникальны поверхность атаки и модель угроз. Значит, подход к вопросам обеспечения безопасности в каждом случае будет иметь свою специфику. Инфраструктура K8s сложная, но это утверждение не должно быть оправданием.


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


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

Подробнее..

DevOps-дайджест от Рексофт

09.12.2020 16:05:25 | Автор: admin

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

Предлагаем подборку свежих статей, подкастов, докладов и грядущих событий для DevOps-специалистов от команды Рексофт. Собрали всё самое интересное за последние несколько недель.

Статьи

1. Обзор инструментов для chaos engineering в Kubernetes

Материал в двух частях от специалистов из компании Флант. Они описывают и сравнивают Open Source-утилиты для запуска управляемого хаоса в кластере Kubernetes. В первой части специалисты рассказали о появлении самой дисциплины chaos engineering, а также рассмотрели kube-monkey, chaoskube и Chaos Mesh.

Читать первую часть

Во второй статье список пополнится обзором Litmus Chaos, Chaos Toolkit, мини-подборкой из хаос-игр и пятью другими вариантами, заслуживающих внимания инженеров, заинтересованных в проверке инфраструктуры на устойчивость.

Читать вторую часть

2. Не паникуйте: Kubernetes и Docker

Начиная с версии v1.20, Kubernetes отказывается от Docker как от исполняемой среды контейнеров. Но не паникуйте. Не все так страшно, как представляется на первый взгляд. Перевод статьи, которая призвана ответить на шумиху вокруг грядущего релиза K8s, в котором поддержка Docker будет объявлена устаревшей.

Читать перевод

3. Red Hat борются с системной несправедливостью и расизмом в коде и документации

Red Hat продолжают бороться с использованием в коде и документации неполиткорректных или оскорбляющих слов. Вендор выпустил специальный фреймоворк, чтобы помочь другим компаниям выявлять у себя такие слова. В частности, рекомендовано заменить термины master/slave и blacklist/whitelist.

Конечно, в IT есть проблемы и посерьезнее, да и вообще, для русскоязычного сегмента, новость может выглядеть комично. Однако, похоже, что инициатива будет только расширяться и влиять на всю отрасль. К движению уже присоединились IBM, Linux Foundation, Cisco и ряд других крупных компаний.

Читать новость (на английском)

4. DevOps и SRE технологии и инструменты 2021 года

Небольшая, но очень ёмкая подборка технологий и инструментов, на которые DevOps и SRE-специалистам необходимо обратить пристальное внимание в 2021 году.

Читать подборку (на английском)

Подкасты

1. SRE vs DevOps

Кто такой Site Reliability Engineer (SRE), зачем он нужен и чем отличается от DevOps или простого системного администратора? Как SRE взаимодействуют внутри команды и вне её, как работает эта культура в разных странах? На эти и многие другие вопросы отвечают эксперты SRE Google и и другие спикеры в очередном выпуске подкаста Linkmeup.

Слушать подкаст

2. Зачем IT в благотворительности

Казалось бы, в благотворительности нет места разработке, да и бюджеты на IT там не предусмотрены. Однако именно технологический подход помогает фонду Нужна помощь собирать по миллиону рублей в день на решение социальных проблем. Технический директор фонда и тимлид проекта Если быть точным рассказали, как в фонде создают IT-инфраструктуру для благотворительности по всей России, и что происходит с разработкой, если о твоем сайте упомянул Иван Ургант.

Слушать подкаст

События

Вебинар Docker Swarm vs K8s. Уйти нельзя остаться. Когда, кому и зачем переходить на Kubernetes со Swarm

10 декабря Mail.ru Cloud Solutions проведут вебинар, на котором сравнят функциональность и ограничения Docker Swarm и Kubernetes. Спикеры разберутся почему лучше перейти на K8s или наоборот, остаться на Swarm. Расскажут, как упростить свой путь в овладении технологией Kubernetes с помощью облачных сервисов с гарантированной доступностью, которые автоматизируют операции Life Cycle. В конце вебинара на вопросы ответит ведущий DevOps Mail.ru Cloud Solutions.

Зарегистрироваться на вебинар

Доклады

DevOps без полномочий

Видео и расшифровка доклада с DevOps Moscow 2020. Спикеры рассказали, как простой исполнитель без больших полномочий может положительно влиять на энтерпрайзные процессы между Dev и Ops. Что кому говорить, как мотивировать и как работать с возражениями. За час выступления спикеры рассмотрели все возможные способы влияния без реальных полномочий, пожалуй, кроме парапсихологических практик и гипноза.

Читать материал и смотреть видео

Подробнее..

IntelliJ IDEA 2020.3

28.12.2020 16:18:38 | Автор: admin
Привет Хабр!

Представляем последнее большое обновление IntelliJ IDEA в этом году. Версию 2020.3 можно скачать с нашего сайта, установить через приложение Toolbox, обновиться прямо в IDE или, если вы пользуетесь Ubuntu, с помощью snap-пакетов.


IntelliJ IDEA 2020.3 несет в себе множество полезных функций: интерактивные подсказки в отладчике, поддержку Git-стейджинга, расширенную поддержку записей и запечатанных классов из Java 15. В новой версии проще работать с окном Endpoints, фреймворками и профилировщиком. Мы также обновили начальный экран, улучшили сортировку вариантов автодополнения на основе машинного обучения и расширили возможности спелл-чекера.


Подробно ознакомиться с новыми функциями вы можете на сайте.




Вот главные улучшения, вошедшие в версию 2020.3:


Редактор


  • Новые параметры переименования предлагают три опции: переименовать объект в комментариях, строках или в текстовых вхождениях.
  • Теперь можно переносить вкладки в разные области экрана и таким образом делить его по вертикали и по горизонтали. А с помощью действия Open in Right Split можно разделить редактор вертикально при открытии файла.
  • Закреплять вкладки стало проще: добавляйте файлы перетаскиванием. Также можно собрать все закрепленные вкладки в отдельном ряду.
  • Вы можете выбрать IntelliJ IDEA в качестве стандартного приложения для открытия файлов.
  • Теперь можно добавить шаблон, который создает сразу несколько файлов. Внутри шаблона вы можете ввести паттерн для создания имени файла и пути.
  • Мы улучшили форматирование Markdown, синхронизировали прокрутку превью и редактора, а также добавили поддержку Mermaid.js.

Взаимодействие с IDE


  • На начальном экране теперь четыре вкладки: для управления проектами, настройки интерфейса IDE, установки плагинов и быстрого доступа к справке и обучающим материалам.
  • Со вкладки Learn IntelliJ IDEA на экране приветствия можно перейти к интерактивным курсам, которые познакомят вас с возможностями IntelliJ IDEA на реальных примерах кода.
  • Теперь можно синхронизировать тему IDE с системными настройками.
  • Мы добавили новый режим чтения для файлов библиотек и файлов, предназначенных только для чтения. В таких файлах удобнее читать комментарии.
  • Чтобы открывать файлы в режиме LightEdit, используйте команду -e(edit). В окне LightEdit можно активировать режим IDE, чтобы использовать все функции IntelliJ IDEA.
  • При нажатии Alt+Enter IDE показывает варианты исправления ошибок правописания. Кроме того, для проверки стиля и грамматики мы начали использовать новую версию движка LanguageTool, который поддерживает более десятка новых языков.
  • В диалоге Search Everywhere можно искать Git-сообщения, теги и ветки, а также использовать его в качестве калькулятора.
  • Теперь по клику на файл его содержимое можно увидеть во вкладке предпросмотра.
  • IntelliJ IDEA сообщит вам о выходе обновления JDK и предложит его установить.
  • Мы добавили панель со смайлами для Linux.

Отладчик


  • В режиме отладки нажмите на переменную, чтобы получить подсказку с указанием связанных полей, значения которых можно изменить.
  • Мы добавили новый тип watch expressions, которые связаны с определенным контекстом и отображаются прямо в редакторе.
  • Во время работы отладчика доступны новые функции профилирования: Show referring objects и Calculate retained size.
  • Теперь на каждый сеанс отладки для задачи Gradle открывается только одна вкладка. В ней отображаются фреймы, переменные, а также вывод консоли.

VCS


  • В новой версии появилась поддержка Git-стейджинга. Теперь вы можете добавлять файлы на стейджинг прямо из IDE. В окне Commit вы увидите две новые секции Staged и Unstaged.
  • Меню VCS называется по имени системы контроля версий, которую вы используете. Еще мы убрали из него все действия, кроме самых актуальных.
  • IntelliJ IDEA автоматически исправляет недопустимые символы в именах веток. А в контекстном меню текущей ветки добавились новые связанные действия.

Java


  • IntelliJ IDEA сортирует варианты автодополнения на основе технологии машинного обучения.
  • Мы добавили новое действие для преобразования записей (records) в классы.
  • В этой версии анализ кода, рефакторинги и автодополнение поддерживают запечатанные классы.
  • Если в ваших файлах используется механизм шебанг, IntelliJ IDEA автоматически определит это и откроет их как надо.
  • Мы упростили извлечение Java-методов: IDE сразу же выполняет рефакторинг без промежуточных диалогов.
  • Добавили новые инспекции и intention-действия для Java, а также улучшили автодополнение.
  • Плагин для Lombok теперь встроен в IDE.

Совместная разработка


  • IntelliJ IDEA 2020.3 поддерживает Code With Me (EAP) наш новый сервис для парного программирования и совместной разработки.

Конфигурации запуска


  • Мы изменили интерфейс конфигураций запуска/отладки и разместили наиболее часто используемые настройки на одном экране. Кроме того, вы можете добавлять дополнительные параметры, если необходимо.

Профилировщик


  • Теперь в окне Profiler можно присоединить профилировщик к работающему приложению и быстро получить доступ к ранее созданным снэпшотам.
  • Открыть любой файл .jfr или .hprof теперь можно несколькими способами: перетащить его в редактор, использовать меню File | Open или дважды кликнуть по файлу на панели Project.

Поддержка фреймворков


  • В этой версии мы значительно улучшили окно Endpoints. Теперь в вы можете фильтровать результаты поиска веб-сервисов и удобно расположить их в IDE. Для каждого веб-сервиса есть доступ к документации, специальному HTTP-клиенту и Open API.
  • Можно экспортировать HTTP-запросы в cURL.
  • Автодополнение URL-адресов стало более информативным: отображаются иконки фреймворков, HTTP-методы и расположение исходных классов и файлов. URL-адреса, объявленные как deprecated, перечеркнуты.
  • Нажав на новый значок глобуса рядом с URL-адресом, вы быстро перейдете к доступным действиям.
  • Теперь анализ кода работает для Spring API: MVC Functional Routing, RestOperations, WebTestClient и Reactive WebClient.
  • HTTP-запросы в старом формате легко преобразовать в новый формат.
  • Мы улучшили анализ кода Swagger и добавили поддержку Swagger Hub.
  • При импорте Quarkus и Micronaut проектов автоматически создаются конфигурации запуска.
  • В IntelliJ IDEA работает автодополнение для имен методов-запросов в Micronaut Data репозиториях. Мы также добавили поддержку SQL и JPQL языков в аннотации Micronaut @Query.

Kubernetes


  • Вы можете загружать логи подов на свой компьютер и быстро удалять ресурсы Kubernetes.
  • Теперь можно автоматически загружать CRD-схемы из активного кластера.
  • Мы добавили действия Open Console и Run Shell.

Kotlin


  • Даты выхода обновлений плагина Kotlin теперь синхронизированы с выпуском новых версий IntelliJ IDEA.
  • Inline-рефакторинг возможен для элементов, объявленных в Java. При инлайне код автоматически конвертируется в Kotlin.
  • Также можно использовать inline-рефакторинг для элементов из библиотек с приложенными исходниками, в том числе для scope-функций also, let, run, with и apply.
  • При inline-рефакторинге улучшена обработка лямбда-выражений.
  • Мы добавили поддержку структурного поиска и замены (SSR) для Kotlin.

Инструменты для работы с базами данных


  • Теперь можно использовать SQL для запросов к MongoDB.
  • IntelliJ IDEA поддерживает сервис Couchbase Query.
  • Добавлены два новых формата экспорта: One-row и SQL-Insert-Multirow.

JavaScript


  • Мы интегрировали TypeScript language service с окном Problems и перенесли действия из окна TypeScript в специальный виджет в строке состояния.
  • Если у вас есть нереализованный React-компонент, IntelliJ IDEA создаст необходимую конструкцию кода за вас.
  • Теперь можно переходить к различным элементам JavaScript- и TypeScript-файлов с панели навигации.

Scala


  • Сервер компиляции Scala теперь компилирует независимые модули параллельно.
  • Мы добавили диаграммы компиляции, чтобы помочь вам оптимизировать структуру модулей проекта и параметры виртуальной машины на сервере компиляции.
  • Scala-плагин теперь может комбинировать префиксы пакетов IntelliJ IDEA с цепочками предложений пакетов и относительными импортами Scala.
  • Добавлена поддержка MUnit со всей привычной функциональностью.
  • Scala-плагин понимает новый синтаксис методов main.

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


Программируйте с удовольствием!

Подробнее..

Перевод Тестирование инфраструктуры как кода Terraform анализ модульных тестов и сквозной разработки путем тестирования поведен

16.12.2020 20:13:35 | Автор: admin


Для будущих студентов курса Infrastructure as a code in Ansible и всех интересующихся подготовили перевод полезного материала.

Также приглашаем записаться на открытый урок по теме Управление Kubernetes при помощи Kubespray.





С возвращением! Это очередная техническая статья из серии заметок о terraform и kubernetes на тему инфраструктуры как кода, подготовленных компанией Contino.

TL;DR
Размер команды не имеет значения. В любом случае реализация хорошего анализа конфигурации инфраструктуры на базе terraform и сквозного тестирования ее разумности не обязательно должна быть длительным и сложным процессом.

Мне подвернулась интереснейшая задача: изучить, разработать и представить подходящую платформу тестирования с открытым кодом для базы кода terraform в рамках конвейера выпуска инфраструктуры. Принцип контроль качества во всем далеко не нов. Но его реализация зависит от зрелости инфраструктуры организации и допустимого уровня риска до стадии выхода на [сколь-либо] готовый продукт.

Свежий взгляд на сферу тестирования кода для инфраструктуры позволил мне познакомиться с новейшими тестовыми платформами и обновить свои знания.

image

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

В конце концов, Hashicorp Terraform имеет достаточные функциональные возможности без дополнительной настройки для проверки и валидации вашей базы кода.

  • Контроль качества кода terraform fmt -check и terraform validate.
  • Предварительный просмотр terraform plan.
  • Построение TFLOG=debug terraform apply для дотошной проверки.

Средства статического анализа кода Terraform


Прочесывание Google выявило весьма обширный перечень потенциально пригодных средств тестирования terraform.

Но сначала пройдемся по списку наших требований.

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

* Отсутствие экземпляров ec2, открытых миру 0.0.0.0/0, и так далее.

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

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

  • Поддержка сообщества важна, когда дело касается программного обеспечения с открытым исходным кодом. Ну и самое последнее, любые выбранные платформы должны быть написаны на распространенном языке программирования, таком как Go или Python. Если понадобится углубиться в платформу и написать собственные методы, найти инженера с опытом работы с одним языком будет, пожалуй, проще, чем с двумя. Любой предыдущий опыт работы с подобными инструментами, который может быть у имеющихся сотрудников группы и организации в целом, также будет полезен. Итак, теперь я готов отправиться на поиски правильного средства тестирования и платформ для выполнения этой работы.

Подборка: анализ и сравнение средств и платформ тестирования Terraform

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



Выбранные средства тестирования


Подытожим. Я старался найти стандартизированный модульный тест для компонентов ресурсов terraform и более настраиваемый набор тестов, которые берут конфигурацию ресурсов для валидации по результатам terraform plan.

Рассмотрев преимущества и недостатки каждой платформы, я остановил свой выбор на инструменте checkov и платформе с очень подходящим названием terraform-compliance обе они написаны на python. Они удовлетворяли всем моим описанным выше требованиям.

Конвейер выпуска инфраструктуры как кода в общих чертах выглядит примерно так.

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

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


Модульное тестирование Checkov от BridgeCrew


www.checkov.io

Checkov это инструмент статического анализа кода для инфраструктуры как кода.

Он сканирует облачную инфраструктуру, подготовленную с помощью Terraform, Cloudformation, Kubernetes, Serverless или шаблонов ARM, и выявляет неправильную конфигурацию с точки зрения безопасности и соблюдения нормативных требований.

Есть несколько модульных тестов, выполняемых по умолчанию при сканировании репозитория кода terraform, которые показывают отклонения от передовых методов например, когда согласно конфигурации безопасности у вас есть виртуальная машина на порту 22, открытом миру (0.0.0.0/0).

Все тесты можно найти по этой ссылке на GitHub.

Начать работать с платформой очень просто.

  • Установите двоичный файл.
  • Инициализируйте каталог terraform командой terraform init.
  • Запустите chechov для этого каталога.

Список всех модульных тестов, выполняемых по умолчанию, можно вывести в командной строке. Кроме того, при работе checkov платформа по умолчанию выдает все пройденные и непройденные модульные тесты. Очень удобно, начать использовать просто. Передовые методы terraform проверяются, но не все. Это фундаментальное отличие.

Chechov с радостью оценит ТОЛЬКО ваш код terraform. Платформа может работать сразу после terraform init. Ей нет дела до вашего terraform plan со всеми преимуществами и недостатками. Платформа выполняет то, что заявлено, а именно статический анализ кода. Помните о возможных последствиях, а также любых соображениях относительно логики для ваших ресурсов.

image

image

Вывод после работы checkov с указанием пройденных и непройденных проверок.


Если вы готовы заниматься углубленной разработкой на Python, то сможете написать дополнительные модульные тесты. Язык разработки платформы входил в число моих требований, поскольку иногда мне приходится анализировать базу кода тестов, чтобы прикинуть, насколько трудно будет [при необходимости] создать подобные дополнительные методы. Этот момент в сочетании с вопросами обслуживания для группы в целом стал основным фактором выбора этой платформы вместо альтернативной, позволяющей получить такой же результат.

Резюмируя, в области статического анализа кода платформа checkov просто великолепна. В частности, если мне нужно, чтобы изначально определенный IP-адрес подсети был помещен в белый список. Но такой вариант не годится для тестов e2e, нуждающихся в отдельной платформе тестирования.

С другой стороны, в качестве решения я могу реплицировать модульный тест и жестко прописать параметры моей подсети/IP-адреса. А что тогда делать, если у меня несколько экземпляров и проектов, пропускать этот тест, даже если он нужен? Может быть. А может и нет.

Вот здесь-то в игру и вступает вторая платформа тестирования terraform-compliance.

Terraform-compliance


terraform-compliance.com

Terraform-compliance это облегченная платформа тестирования, предназначенная для проверки безопасности и соблюдения нормативных требований в terraform для обеспечения совместимости вашей инфраструктуры как кода с отрицательным тестированием.

Предыстория


Еще раз отмечу, сквозная разработка через тестирование поведения (BDD) стала использоваться как платформа тестирования недавно, подчеркнув потребность в универсальной платформе тестирования. Но это не единственная польза.Простота.

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

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

Cucumber.io это не просто язык, это система, упрощающая работу по тестированию за счет применения подхода WYSIWYG к созданию тестов, пониманию их работы и обслуживанию. Эти примеры определяются до начала разработки и используются в качестве критериев приемки.

Они являются частью определения.

Тестирование с помощью Terraform-Compliance


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

Вот пример такого теста, разработанного с помощью платформы terraform-compliance с применением BDD. Он позволяет выполнять достаточно сложное сквозное тестирование.

Платформа terraform-compliance использует вывод terraform plan. В результате это позволяет формировать полные планы выпусков и тщательно тестировать их. Например, контролировать использование правильной пары ключей шифрования [для вашего поставщика облачных услуг] для учетной записи, среды и т.п. У вас будет большая свобода для творчества, и самое важное работать с платформой очень просто.

Просто ознакомьтесь с приведенными ниже действиями и примерами.

  • Шаг 1. Инициализируйте каталог terraform:# terraform init
  • Шаг 2. Можно быстро сформировать terraform plan следующей командой: #terraform plan -out=plan.out
  • Шаг 3. Напишите несколько тестов. Дело нехитрое уже есть папка с примерами. Давайте пройдемся по моим собственным примерам тестов, приведенным ниже, написанным на основе моего вывода terraform plan.

Это фрагмент плана terraform конфигурации terraform, которая создает EKS с указанной группой запуска. Давайте удостоверимся, что в нашем коде инфраструктуры terraform не применяется instancetype, а используется одобренный вариант a1.xlarge или a1.2xlarge.

Теперь я намеренно изменю его на t2.small, чтобы имитировать непрохождение теста.

Напишем тест, чтобы обеспечить успешную валидацию этого требования.

  • Шаг 4. Давайте заставим terraform-compliance оценить плат с использованием тестовых сценариев: #terraform-compliance -p plan.out -f ./<test-cases-folder>


Выполнение тестов


Пример результата с прохождением и непрохождением

image

Если в нашем коде инфраструктуры Terraform используется правильный instancetype, то все результаты будут зелеными SUCCESS.

Если же наш код инфраструктуры Terraform нарушает требование из-за наличия неправильного instancetype, то результаты будут красными FAIL.

Давайте напишем еще больше тестов

image

Еще несколько простых тестов, взятых из каталога примеров:

image

Если одна ситуация с непрохождением в этом случае пользователь увидит фактическое_значение, которое извлекается и показывается в целях справки и отладки.

Результаты тестов


После выполнения всех тестов отображается удобная итоговая сводка по всем пройденным и непройденным тестам, в которой также указываются пропущенные тесты. Она мне нравится тем, что позволяет написать длинный список тщательных тестов, а также найти в конце четкие сведения о том, какие тесты не были пройдены и когда. Кроме того, в случае непрохождения некоторые тесты могут быть пропущены с указанием тега @warning, как показано в примере ниже.
habrastorage.org/getpro/habr/upload_files/c22/910/cb9/c22910cb95fb4ccc7555d44bd8b5436b

Итоги


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

Я получил удовольствие, рассматривая обе эти платформы, и был особенно удивлен простотой интеграции checkov, а также потрясающей валидацией e2e terraform plan и вариантами нестандартного тестирования, которые предлагает terraform-compliance.

Последняя напоминает мне поведение behave, еще одной великолепной платформы тестирования BDD e2e kubernetes, с которой я работал в прошлом.

Полностью написанные на Python платформы тестирования упрощают общий обмен знаниями Python между платформами и сокращают объем интеллектуального труда для обслуживания и разработки тестов в будущем.

Если вам требуется проверка конфигурации на соответствие передовым методам, когда не требуется terraform plan, то, возможно, checkov это то, что вам нужно. В иных случаях ответом может быть платформа terraform-compliance, имеющая более богатый набор функций для валидации terraform plan. Лучше всего то, что, будучи платформой BDD, terraform-compliance очень проста в освоении.

Модульное тестирование прежде всего. Проще простого. Платформа Checkov от bridgecrewio позволяет выполнять проверку соответствия передовым методам без дополнительной настройки.

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

P.S. В компании Contino реализуется порядочное количество фантастических проектов. Если вам хотелось бы поработать над суперсовременными инфраструктурными проектами или вы ищете серьезные задачи свяжитесь с нами! Мы нанимаем персонал и ищем светлые умы на всех уровнях. Мы в компании Contino гордимся тем, что разрабатываем передовые проекты по трансформации облачных систем, предназначенные как для компаний среднего размера, так и для крупных предприятий.
Узнать подробнее о курсе Infrastructure as a code in Ansible.

Записаться на открытый урок по теме Управление Kubernetes при помощи Kubespray.

Подробнее..

HelmWave v0.5.0 GitOps для твоего Kubernetes

14.12.2020 22:19:31 | Автор: admin

preview


Helm, как и Docker стал де-факто стандартом в индустрии. Когда мы обсуждаем Kubernetes (52%). И новость, что Docker is deprecated вызвало волну обсуждений в сообществе. Настолько все привыкли к Docker.


Для Docker есть замечательный по своей простоте docker-compose, в котором мы можем декларативно описать, что мы хотим от Docker.


Для Kubernetes набор yaml-tpl файлов упаковывается в архив. И затем этот архив называется Helm-чартом. Но как это часто бывает приложение не может быть описано лишь одним Helm чартом. Требуется как-то управлять/композить/настраивать/шаблонизировать такие сеты.


Одним из подходов по управлению является Umbrella Chart. Это helm chart который объединяет в себе все другие чарты.


Очевидные минусы данного решения:


  • Требуется поддерживать дополнительный чарт
  • Новый слой согласования имен values переменных.
  • Umbrella-chart это все тот же чарт, поэтому о шаблонизации values и декларативном разделении на контуры (Окружения) не может быть и речи.
  • Когда обновляется саб-чарт, нужно идти в umbrella и обновлять еще версию umbrella чарта.

Helmwave возник, как инструмент для декларативного описания всех чартов в одном yaml.
Этот пост покажет как можно решить основные проблемы (use-cases) с помощью helmwave.


Что такое HelmWave?


  • Это бинарь, который устанавливает helm release из helmwave.yml.
  • Кладешь helmwave.yml в git и применяешь его через CI.
  • Можно шаблонизировать все c помощью (Go template), начиная от helmwave.yml до values.
  • Helmwave понимает какие helm-repositories ему понадобятся для деплоя. И вытесняет лишние.

Порядок комманд



graph TD;    Start(helmwave.yml.tpl) --render--> helmwave.yml;    helmwave.yml --planfile--> .helmwave;    .helmwave --sync--> Finish(Releases have been deployed!)

Быстрый старт


helmwave.yml.tpl имеет следующий вид


project: my-projectversion: 0.5.0repositories:  - name: bitnami    url: https://charts.bitnami.com/bitnami.options: &options  install: true  namespace: my-namespacereleases:  - name: redis-a    chart: bitnami/redis    options:      <<: *options  - name: redis-b    chart: bitnami/redis    options:      <<: *options

$ helmwave deploy

Поздравляю, вы задеплоили с помощью helmwave!


$ helm list -n my-namespaceNAME       NAMESPACE       REVISION     STATUS      CHART             APP VERSIONredis-a    my-namespace    1            deployed    redis-11.2.3      6.0.9      redis-b    my-namespace    1            deployed    redis-11.2.3      6.0.9  $ k get po -n my-namespace                                                                                                                         NAME               READY   STATUS    RESTARTS   AGEredis-a-master-0   1/1     Running   0          64sredis-a-slave-0    1/1     Running   0          31sredis-a-slave-1    1/1     Running   0          62sredis-b-master-0   1/1     Running   0          59sredis-b-slave-0    1/1     Running   0          32sredis-b-slave-1    1/1     Running   0          51s

Переменные окружения


$ helmwave help

  • $HELMWAVE_TPL_FILE отвечает за путь к входному файлу для шаблонизации (helmwave.yml.tpl).
  • $HELMWAVE_FILE указывает путь выходного файла после операции шаблонизации (helmwave.yml).
  • $HELMWAVE_PLAN_DIR указывает путь к папке, в которой хранится или будет хранится план (.helmwave/).
  • $HELMWAVE_TAGS массив строк, на основании которого будет проводится планирование.
  • $HELMWAVE_PARALLEL включает/выключает многопоточность (рекомендуется включать).
  • $HELMWAVE_LOG_FORMAT позволяет выбрать один из предустановленных форматов вывода.
  • $HELMWAVE_LOG_LEVEL позволяет управлять детализацией вывода.
  • $HELMWAVE_LOG_COLOR включает/выключает цвета для вывода.

Use-Cases


Примеры будут производиться, опираясь на gitlab-ci. Но это не помешает вам встроить helmwave в любой другой CI-инструмент.


Чем ниже, тем сложнее будут примеры.


Git tag > Docker tag


Допустим вы написали какой-то helm чарт для нашего приложения. Его values.yaml по умолчанию имеет вид:


image:  repository: registry.gitlab.local/example/app  tag: master

Необходимо чтобы image.tag брался из переменной CI


Приступим, создадим 2 файла.


. helmwave.yml.tpl values.yml

helmwave.yml.tpl


project: my-project # Имя проектаversion: 0.5.0 # Версия helmwavereleases:  - name: my-release    chart: my-chart-repo/my-app    values:      - values.yml    options:      install: true      namespace: my-namespace

values.yml


image:  tag: {{ env "CI_COMMIT_TAG" }}

Git commit --> PodAnnotations


Требуется чтобы deployment обновлялся только если у нас есть новый коммит.


deployment имеет примерно этот вид:


    ...    metadata:        {{- with .Values.podAnnotations }}        annotations:          {{- toYaml . | nindent 8 }}        {{- end }}    ...

Поэтому мы можем легко расширить предыдущий пример values.yml


image:  tag: {{ requiredEnv "CI_COMMIT_TAG" }}podAnnotations:    gitCommit: {{ requiredEnv "CI_COMMIT_SHORT_SHA" | quote }}

Контуры, окружения, environments


Структура каталога


. helmwave.yml.tpl values     _.yml     prod.yml     stage.yml

helmwave.yml.tpl


project: my-project  version: 0.5.0  releases:    - name: my-release      chart: my-chart-repo/my-app      values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/{{ env "CI_ENVIRONMENT_NAME" }}.yml      options:        install: true        namespace: {{ env "CI_ENVIRONMENT_NAME" }}

values/_.yml Будет запускаться для любого окружения


image:  tag: {{ requiredEnv "CI_COMMIT_TAG" }}podAnnotations:    gitCommit: {{ requiredEnv "CI_COMMIT_SHORT_SHA" | quote }}

values/prod.yml Будет запускаться только для prod


replicaCount: 6

values/stage.yml Будет запускаться только для stage


replicaCount: 2

Используем внешний yaml и .Release.Store


Store это просто хранилище, которое можно задавать в helmwave.yml и передавать дальше в шаблонизацию values.


Допустим мы хотим связать путь к секрету в vault и путь к проекту в gitlab или вы хотите переопределять путь к image.repository. Это можно удобно сделать через Store.


. helmwave.yml.tpl values    _.yml vars     my-list.yaml

values/_.yml


vault: secret/{{ .Release.Store.path  }}/{{ requiredEnv "CI_ENVIRONMENT_NAME"  }}image:  repository: {{ env "CI_REGISTRY" | default "localhost:5000" }}/{{ .Release.Store.path }}

Добавим произвольный yaml файл.


vars/my-list.yaml


releases:  - name: adm-api    path: main/product/adm/api  - name: api    path: main/product/api

helmwave.yml.tpl


project: my-projectversion: 0.5.0.options: &options  install: true  wait: true  timeout: 5mreleases:  {{- with readFile "vars/my-list.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  - name: {{ $v | get "name" }}    chart: my-project/{{ $v | get "name" }}    options:      <<: *options    store:      path: {{ $v | get "path" }} # Set .Release.Store.path    tags:      - {{ $v | get "name" }}      - my    values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/{{ env "CI_ENVIRONMENT_NAME" }}.yml  {{ end }}  {{- end }}

Запускаем!


$ CI_ENVIRONMENT_NAME=stage helmwave planfile

Появится helmwave.yml и папка .helmwave


$ tree .helmwave.helmwave planfile values     _.yml.adm-api@.plan     _.yml.api@.plan$ cat .helmwave/values/_.yml.api@.plan                            vault: secret/main/product/api/stage                                                               image:  repository: localhost:5000/main/product/api$ cat .helmwave/values/_.yml.adm-api@.plan                                  vault: secret/main/product/adm/api/stageimage:  repository: localhost:5000/main/product/adm/api

helmwave.yml


project: my-projectversion: 0.5.0.options: &options  install: true  wait: true  timeout: 5mreleases:  - name: adm-api    chart: my/adm-api    options:      <<: *options    store:      path: main/product/adm/api    tags:      - adm-api      - my    values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/stage.yml  - name: api    chart: my/api    options:      <<: *options    store:      path: main/product/api    tags:      - api      - my    values:        # Default        - values/_.yml        # For specific ENVIRONMENT        - values/stage.yml

Отделяем продукты от инфраструктуры


Структура проекта


Создадим в папке values 2 папки


  • product здесь будут values для продуктов
  • infrastructure здесь будет инфарструктурные values

values/infrastructure


  • adminer веб морда для подключения к базе, полезна в основном только в dev-контурах
  • postgresql база данных
  • ns-ready здесь LimitRange, ResourcseQuota, Secrets, NetworkPolicy, etc
  • rabbitmq общая шина между chat и api

values/product
Приложение состоит из 3 микросервисов


  • api
  • chat
  • frontend

И еще нам понадобятся 2 отдельных файла описывающие массив product и массив infrastructure.


Структура проекта:


. helmwave.yml.tpl values    infrastructure       adminer          _.yml          dev.yml          stage.yml       ns-ready          _.yml       postgresql          _.yml          dev.yml       rabbitmq           _.yml           dev.yml           stage.yml    product        _           _.yml           dev.yml           prod.yml           stage.yml        api           _.yml           dev.yml           prod.yml           stage.yml        chat           _.yml        frontend            _.yml            dev.yml            prod.yml            stage.yml vars     infrastructure.yaml     products.yaml

vars/infrastructure.yaml


releases:  - name: postgresql    repo: bitnami    version: 8.6.13  - name: adminer    repo: cetic    version: 0.1.5  - name: rabbitmq    repo: bitnami    version: 7.6.6  - name: ns-ready    repo: my-project    version: 0.1.1

vars/products.yaml


releases:  - name: adm-api    path: rdw/sbs/adm/api  - name: frontend    path: my-project/internal/frontend  - name: api    path: my-project/internal/api  - name: chat    path: my-project/internal/chat

helmwave.yml.tpl


project: my-projectversion: 0.5.0repositories:  - name: bitnami    url: https://charts.bitnami.com/bitnami  - name: cetic    url: https://cetic.github.io/helm-charts.options: &options  install: true  wait: true  timeout: 5m  atomic: false  maxhistory: 10  namespace: {{ requiredEnv "HELM_NS" }}releases:  {{- with readFile "vars/products.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  - name: {{ $v | get "name" }}    chart: my-project/{{ $v | get "name" }}    options:      <<: *options    store:      path: {{ $v | get "path" }}    tags:      - {{ $v | get "name" }}      - product    values:      # all products & all envs      - values/product/_/_.yml      # all products & an env      - values/product/_/{{ requiredEnv "CI_ENVIRONMENT" }}.yml      # a product & all envs      - values/product/{{ $v | get "name" }}/_.yml      # a product & an env      - values/product/{{ $v | get "name" }}/{{ requiredEnv "CI_ENVIRONMENT" }}.yml  {{ end }}  {{- end }}  {{- with readFile "vars/infrastructure.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  - name: {{ $v | get "name" }}    chart: {{ $v | get "repo" }}/{{ $v | get "name" }}    options:      <<: *options      chartpathoptions:        version: {{ $v | get "version" }}    tags:      - {{ $v | get "name" }}      - infrastructure    values:      # a svc & all envs      - values/infrastructure/{{ $v | get "name" }}/_.yml      # a svc & an env      - values/infrastructure/{{ $v | get "name" }}/{{ requiredEnv "CI_ENVIRONMENT" }}.yml  {{ end }}  {{- end }}

Контуры в Store


Допустим у нас есть 2 окружения dev и prod.
И в prod'e нам не нужна база данных


vars/infrastructure.yaml


releases:  - name: rabbitmq    repo: stable    version: 6.18.2    envs:      - _ # all environments    tags:      - queue  - name: postgresql    repo: bitnami    version: 8.6.13    envs:      - dev # only dev    tags:      - db

# vim: set filetype=yaml:{{- $env := requiredEnv "CI_ENVIRONMENT" }} # Look at this firstproject: insiderversion: 0.5.0repositories:  - name: stable    url: https://kubernetes-charts.storage.googleapis.com  - name: bitnami    url: https://charts.bitnami.com/bitnami.options: &options  install: true  wait: true  force: false  timeout: 5m  atomic: false  maxhistory: 10  namespace: {{ requiredEnv "HELM_NS" }}releases:  {{- with readFile "vars/infrastructure.yaml" | fromYaml | get "releases" }}  {{- range $v := . }}  {{- $envs := $v | get "envs" }}  {{- if or (has "_" $envs) (has $env $envs) }}  - name: {{ $v | get "name" }}    chart: {{ $v | get "repo" }}/{{ $v | get "name" }}    options:      <<: *options      chartpathoptions:        version: {{ $v | get "version" }}    tags:      - {{ $v | get "name" }}      - infrastructure      {{- if $v | hasKey "tags" }}      - {{ $v | get "tags" | toYaml }}      {{- end }}    values:      # a svc & all envs      - values/infrastructure/{{ $v | get "name" }}/_.yml      # a svc & an env      - values/infrastructure/{{ $v | get "name" }}/{{ $env }}.yml  {{ end }}  {{- end }}  {{- end }}

База по умолчанию выключена


$ helmwave planfile

Чтобы postgresql включился


$ CI_ENVIRONMENT=dev helmwave planfile

Giltab-CI Pipelines


Рассмотрим шаблон gitlab-ci с использованием helmwave из проекта g-ci


variables:  HELMWAVE_LOG_LEVEL: debug.helmwave-deploy:  stage: deploy  environment:    name: ref/$CI_COMMIT_REF_SLUG  image:    name: diamon/helmwave:0.5.0    entrypoint: [""]  script:    - helmwave deployhelmwave deploy:  extends: .helmwave-deploy

С использованием include


include: https://gitlab.com/g-ci/deploy/-/raw/master/helmwave.ymlhelmwave deploy:  environment:    name: prod

P.S.


Helmwave source: https://github.com/zhilyaev/helmwave/
G-CI: https://gitlab.com/g-ci
Приходите к нам в telegram с любыми вопросами!

Подробнее..
Категории: Kubernetes , Git , Devops , Helm , Gitops

Микросервисы на монолите

15.12.2020 12:20:26 | Автор: admin

Всем привет!

Скажу сразу, эта статья не про очередное переписывание монолита на микросервисы, а о применении микросервисных практик в рамках существующего проекта с использованием интересных, как мне кажется, подходов. Наверное, уже нет смысла объяснять, почему многие проекты активно используют микросервисную архитектуру. Сегодня в IT возможности таких инструментов как Docker, Kubernetes, Service Mesh и прочих сильно меняют наше представление об архитектуре современного приложения, вынуждая пересматривать подходы и переписывать целые проекты на микросервисы. Но так ли это необходимо для всех частей проекта?

В нашем проекте есть несколько систем, которые писались в те времена, когда преимущества микросервисного подхода были не столь очевидны, а инструментов, позволяющих использовать такой подход, было очень мало, и переписывать системы полностью просто нецелесообразно. Для адаптации к новой архитектуре мы решили в части задач использовать асинхронный подход, а также перейти к хранению части данных на общих сервисах. Само приложение при этом осталось на Django (API для SPA). При переходе на k8s деплой приложения был разбит на несколько команд: HTTP-часть (API), Celery-воркеры и RabbitMQ-консьюмеры. Причем было именно три развёртывания, то есть все воркеры, как и консьюмеры, крутились в одном контейнере. Быстрое и простое решение. Но этого оказалось недостаточно, так как это решение не обеспечивало нужный уровень надежности.

Начнем с RabbitMQ-консьюмеров. Основная проблема была в том, что внутри контейнера стартовал воркер, который запускал много потоков на каждый консьюмер, и пока их было пару штук, всё было хорошо, но сейчас их уже десятки. Решение нашли простое: каждый консьюмер вывели в отдельную команду manage.py и деплоим отдельно. Таким образом, у нас несколько десятков k8s-развёртываний на одном образе, с разными параметрами запуска. Ресурсы мы тоже выставляем для каждого консьюмера отдельно, и реальное потребление у консьюмеров достаточно невысокое. В результате для одного репозитория у нас десятки реальных отдельных сервисов в k8s, которые можно масштабировать, и при этом разработчикам намного удобнее работать только с одним репозиторием. То же самое и для развёртываний Сelery.

Если решение с воркерами достаточно простое и очевидное, то с HTTP-частью было немного сложнее. В нашей системе внешний межсервисный API и внутренний для фронтенда были в одном развёртывании с большим лимитом ресурсов и большим количеством инстансов.

Вроде бы рабочее решение? Да, но ДомКлик большой сложный механизм с сотнями сервисов, и иногда выход одного стороннего (вне конкретной системы) сервиса, который используется в одном единственном API-методе, может привести к пробке на сервере uwsgi. К чему это приводит, надеюсь, объяснять не нужно, всё встает или тормозит. В такие моменты должен приходить Кэп и говорить что-то вроде: Нужно было делать отдельные микросервисы и тогда упал бы только тот, что связан с отказавшим внешним сервисом. Но у нас-то монолит.

В Kubernetes есть такой сервис, как Ingress Controller, его основная задача распределять нагрузку между репликами. Но он, по сути, nginx, а значит Ingress Controller можно использовать для того, чтобы роутить запросы на разные сервисы.

Примерно вот так выглядит схема:

Проанализировав наш API, мы разбили его на несколько групп:

  • Внешний API (методы для других сервисов).

  • Внутренний API (методы для фронтенда).

  • Некритичные API-методы, которые зависимы от внешних сервисов, но не влияют на работу системы (статистика, счетчики и т. п.)

Таким образом можно легко создавать новые сервисы. Управлять ресурсами для каждого из них, масштабировать те методы, которые несут большую нагрузку, и получать другие преимущества. Если один из методов перестанет отвечать из-за каких-то внешних причин, то его можно изолировать в отдельное развёртывание и снизить нагрузку на другие части системы.

В конечном итоге наша система, имея один репозиторий и Django под капотом, раздроблена благодаря Kubernetes на 42 сервиса, 5 из которых делят HTTP-трафик, а остальные 37 консьюмеры и Celery-задачи. И в таком виде она может быть актуальна еще пару лет, несмотря на использование относительно старого стека технологий.

Подробнее..

Перевод k0s Kubernetes в одном бинарном файле

22.12.2020 20:16:02 | Автор: admin
В нашей новой переводной статье даем краткий обзор на новый дистрибутив Kubernetes. Надеемся, статья окажется интересной для читателей Habr'a.

Пару дней назад друг рассказал мне о новом дистрибутиве Kubernetes от Mirantis под названием k0s. Все мы знаем и любим K8s, не так ли? Нас также покорил K3s, легкий Kubernetes, разработанный Rancher Labs и переданный CNCF некоторое время назад. Пришло время открыть для себя новый дистрибутив k0s!



После краткого знакомства с k0s мы создадим кластер из трех нод, выполнив следующие действия:

  • Подготовка трех виртуальных машин (Multipass в действии)
  • Установка k0s на каждой из них
  • Настройка простого файла конфигурации кластера k0s
  • Инициализация кластера
  • Получение доступа к кластеру
  • Добавление рабочих узлов
  • Добавление пользователя

Что такое k0s?


k0s это новейший дистрибутив Kubernetes. Текущий релиз 0.8.0. Он был опубликован в декабре 2020 года, а первый коммит всего проекта произошел в июне 2020 года.

k0s поставляется как единый двоичный файл без каких-либо зависимостей от ОС. Таким образом, он определяется как дистрибутив Kubernetes с характеристиками zero-friction/zero-deps/zero-cost (легкость конфигурации / отсутствие зависимостей / бесплатный).

Последний релиз k0s:

  • Поставляет сертифицированный (получивший аттестацию центра интернет-безопасности) Kubernetes 1.19
  • Использует containerd как среду выполнения контейнера по умолчанию
  • Поддерживает архитектуры Intel (x86-64) и ARM (ARM64)
  • Использует внутрикластерный etcd
  • По умолчанию использует сетевой плагин Calico (тем самым активируя сетевые политики)
  • Включает контроллер доступа политик безопасности Pod
  • Использует DNS с CoreDNS
  • Предоставляет метрики кластера через Metrics Server
  • Позволяет использовать горизонтальное автомасштабирование подов (HPA).

В будущих релизах появится много крутых функций, в том числе:

  • Среда выполнения компактных виртуальных машин (очень жду возможности протестировать эту функцию)
  • Обновление кластера с нулевым временем простоя
  • Резервное копирование и восстановление кластера

Впечатляет, не правда ли? Далее мы рассмотрим, как использовать k0s для развертывания кластера из 3 нод.

Подготовка виртуальных машин


Для начала мы создадим три виртуальные машины, каждая из которых будет являться узлом в нашем кластере. В этой статье я пойду быстрым и легким путем и воспользуюсь прекрасным инструментом Multipass (обожаю его) для подготовки локальных виртуальных машин на MacOS.

Следующие команды создают три экземпляра Ubuntu на xhyve. Каждая виртуальная машина имеет 5 ГБ диска, 2 ГБ оперативной памяти и 2 виртуальных процессора (vCPU):

for i in 1 2 3; do
multipass launch -n node$i -c 2 -m 2G
done


Затем мы можем отобразить список виртуальных машин, чтобы убедиться, что все они работают нормально:

$ multipass list
Name State IPv4 Image
node1 Running 192.168.64.11 Ubuntu 20.04 LTS
node2 Running 192.168.64.12 Ubuntu 20.04 LTS
node3 Running 192.168.64.13 Ubuntu 20.04 LTS


Далее мы установим k0s на каждый из этих узлов.

Установка последнего релиза k0s


Последний релиз k0s можно скачать из репозитория GitHub.

У него есть удобный скрипт установки:

curl -sSLf get.k0s.sh | sudo sh

Мы используем этот скрипт, чтобы установить k0s на все наши узлы:

for i in 1 2 3; do
multipass exec node$i --bash -c "curl -sSLf get.k0s.sh | sudo sh"
done


Указанный скрипт устанавливает k0s в /user/bin/k0. Чтобы получить все доступные команды, нужно запустить двоичный файл без аргументов.


Доступные команды k0s

Можем проверить текущую версию:

$ k0s version
v0.8.0


Некоторые команды мы будем использовать и на следующих этапах.

Создание файла конфигурации


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

ubuntu@node1:~$ k0s default-config
apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
- 192.168.64.11
extraArgs: {}
controllerManager:
extraArgs: {}
scheduler:
extraArgs: {}
storage:
type: etcd
kine: null
etcd:
peerAddress: 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12
provider: calico
calico:
mode: vxlan
vxlanPort: 4789
vxlanVNI: 4096
mtu: 1450
wireguard: false
podSecurityPolicy:
defaultPolicy: 00-k0s-privileged
workerProfiles: []
extensions: null
images:
konnectivity:
image: us.gcr.io/k8s-artifacts-prod/kas-network-proxy/proxy-agent
version: v0.0.13
metricsserver:
image: gcr.io/k8s-staging-metrics-server/metrics-server
version: v0.3.7
kubeproxy:
image: k8s.gcr.io/kube-proxy
version: v1.19.4
coredns:
image: docker.io/coredns/coredns
version: 1.7.0
calico:
cni:
image: calico/cni
version: v3.16.2
flexvolume:
image: calico/pod2daemon-flexvol
version: v3.16.2
node:
image: calico/node
version: v3.16.2
kubecontrollers:
image: calico/kube-controllers
version: v3.16.2
repository: ""
telemetry:
interval: 10m0s
enabled: true


Помимо прочего, это позволяет нам определить:

  • Параметры запуска сервера API, диспетчера контроллеров и планировщика
  • Хранилище, которое можно использовать для сохранения информации о кластере (etcd)
  • Сетевой плагин и его конфигурацию (Calico)
  • Версию образов контейнеров с компонентами управления
  • Некоторые дополнительные схемы управления, которые следует развернуть при запуске кластера

Мы могли бы сохранить эту конфигурацию в файл и адаптировать ее под свои нужды. Но в этой статье мы воспользуемся очень простой конфигурацией и сохраним ее в /etc/k0s/k0s.yaml.

apiVersion: k0s.k0sproject.io/v1beta1
kind: Cluster
metadata:
name: k0s
spec:
api:
address: 192.168.64.11
sans:
- 192.168.64.11
network:
podCIDR: 10.244.0.0/16
serviceCIDR: 10.96.0.0/12


Примечание: Так как мы инициализируем кластер на узле node1, этот узел будет обслуживать сервер API. IP-адрес этого узла используется в api.address и api.sans (альтернативные имена субъектов) в приведенном выше файле конфигурации. Если бы у нас были дополнительные главные узлы и балансировщик нагрузки над ними, мы бы также использовали в настройках api.sans IP-адрес каждого узла и балансировщика нагрузки (или соответствующее доменное имя).

Инициализация кластера


Сначала мы создаем systemd unit на node1 для управления k0s.

[Unit]
Description="k0s server"
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/bin/k0s server -c /etc/k0s/k0s.yaml --enable-worker
Restart=always


Основная команда здесь указана в ExecStart; она запускает сервер k0s с той конфигурацией, которую мы сохранили в наш файл на предыдущем этапе. Мы также указываем параметр --enable-worker, чтобы этот первый главный узел также функционировал как рабочий.

Затем мы копируем этот файл в /lib/systemd/system/k0s.service, перезагружаем systemd и запускаем недавно созданную службу.

ubuntu@node1:~$ sudo systemctl daemon-reload
ubuntu@node1:~$ sudo systemctl start k0s.service


Ради любопытства можно проверить процессы, запущенные сервером k0s:

ubuntu@node1:~$ sudo ps aux | awk {print $11} | grep k0s
/usr/bin/k0s
/var/lib/k0s/bin/etcd
/var/lib/k0s/bin/konnectivity-server
/var/lib/k0s/bin/kube-controller-manager
/var/lib/k0s/bin/kube-scheduler
/var/lib/k0s/bin/kube-apiserver
/var/lib/k0s/bin/containerd
/var/lib/k0s/bin/kubelet


Из выходных данных выше мы видим, что все основные компоненты запущены (kube-apiserver, kube-controller-manager, kube-scheduler и т. д.), а также компоненты, общие для главных и рабочих узлов (containerd, kubelet). k0s отвечает за управление всеми этими компонентами.

Теперь мы имеем кластер из 1 ноды. На следующем этапе мы увидим, как получить к нему доступ.

Получение доступа к кластеру


Сначала нам необходимо получить файл kubeconfig, сгенерированный во время создания кластера; он был создан на node1 в /var/lib/k0s/pki/admin.conf. Этот файл нужно использовать для настройки kubectl на локальной машине.

Сначала получаем kubeconfig кластера из node1:

# Get kubeconfig file
$ multipass exec node1 cat /var/lib/k0s/pki/admin.conf > k0s.cfg


Далее заменяем внутренний IP-адрес на внешний IP-адрес node1:

# Replace IP address
$ NODE1_IP=$(multipass info node1 | grep IP | awk '{print $2}')
sed -i '' "s/localhost/$NODE1_IP/" k0s.cfg


Затем выполняем конфигурацию нашего локального клиента kubectl для связи с сервером k0s API:

export KUBECONFIG=$PWD/k0s.cfg

Наверняка одной из первых команд, которые мы запускаем при входе в новый кластер, является та, которая отображает список всех доступных узлов, давайте попробуем:

$ kubectl get no
NAME STATUS ROLES AGE VERSION
node1 Ready <none> 78s v1.19.4


Здесь нет ничего удивительного. Ведь node1 является не только главным, но и рабочим узлом нашего первого кластера благодаря флагу --enable-worker, который мы указали в команде запуска. Без этого флага node1 был бы только рабочим и не отображался бы в списке узлов здесь.

Добавление рабочих узлов


Чтобы добавить в кластер node2 и node3, сначала нам нужно создать токен соединения из node1 (это довольно распространенный этап, так как он используется в кластерах Docker Swarm и Kubernetes, созданных с помощью kubeadm).

$ TOKEN=$(k0s token create --role=worker)

Вышеуказанная команда генерирует длинный (очень длинный) токен. Используя его, мы можем присоединить к кластеру node2 и node3:

ubuntu@node2:~$ k0s worker $TOKEN
ubuntu@node3:~$ k0s worker $TOKEN


Примечание: В реальном кластере мы бы использовали systemd (или другой супервизор) для управления процессами k0s для рабочих узлов, как мы сделали для главного узла.

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

$ kubectl get no
NAME STATUS ROLES AGE VERSION
node1 Ready <none> 30m v1.19.4
node2 Ready <none> 35s v1.19.4
node3 Ready <none> 32s v1.19.4


Мы также можем проверить поды, работающие во всех пространствах имен:


Список подов, работающих в кластере во всех пространствах имен

Здесь следует отметить несколько моментов:

  • Как обычно, мы видим поды kube-proxy, поды сетевых плагинов (на основе Calico), а также под для CoreDNS.
  • Поды api-server, scheduler и controller-manager не отображаются в этом списке, поскольку они выполняются как обычные процессы, а не внутри подов.

Добавление пользователя


Версия k0s 0.8.0 содержит подкоманду user. Это позволяет создать kubeconfig для дополнительного пользователя/группы. Например, следующая команда создает для нового пользователя файл kubeconfig с названием demo, который находится внутри имитированной группы (imaginary group) с названием development.

Примечание: В Kubernetes пользователи и группы управляются администратором вне кластера, то есть в K8s нет ресурса пользователь-не-группа.

$ sudo k0s user create demo --groups development > demo.kubeconfig

Для лучшего понимания мы извлечем сертификат клиента из этого файла kubeconfig и декодируем его из представления base64:

$ cat demo.kubeconfig | grep client-certificate-data | awk '{print $2}' | base64 --decode > demo.crt

Затем мы используем команду openssl чтобы получить содержимое сертификата:

ubuntu@node1:~$ openssl x509 -in demo.crt -noout -text
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
71:8b:a4:4d:be:76:70:8a:...:07:60:67:c1:2d:51:94
Signature Algorithm: sha256WithRSAEncryption
Issuer: CN = kubernetes-ca
Validity
Not Before: Dec 2 13:50:00 2020 GMT
Not After : Dec 2 13:50:00 2021 GMT
Subject: O = development, CN = demo
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
RSA Public-Key: (2048 bit)
Modulus:
00:be:87:dd:15:46:91:98:eb:b8:38:34:77:a4:99:
da:4b:d6:ca:09:92:f3:29:28:2d:db:7a:0b:9f:91:
65:f3:11:bb:6c:88:b1:8f:46:6e:38:71:97:b7:b5:
9b:8d:32:86:1f:0b:f8:4e:57:4f:1c:5f:9f:c5:ee:
40:23:80:99:a1:77:30:a3:46:c1:5b:3e:1c:fa:5c:


  • Свойство issuer это kubernetes-ca, который является центром сертификации нашего кластера k0s.
  • Subject это O = development, CN = demo; эта часть важна, так как именно здесь появляется имя и группа пользователя. Так как сертификат подписан центром сертификации кластера, подключаемый модуль на api-server может аутентифицировать пользователя/группу по общему имени (CN) и организации (O) в теме сертификата.

Сначала мы даем команду kubectl использовать контекст, определенный в этом новом файле kubeconfig:

$ export KUBECONFIG=$PWD/demo.kubeconfig

Затем еще раз отображаем список узлов перечисляем узлы кластера:

$ kubectl get no
Error from server (Forbidden): nodes is forbidden: User demo cannot list resource nodes in API group at the cluster scope


Это сообщение об ошибке было ожидаемым. Даже если api-server идентифицировал пользователя (сертификат, отправленный вместе с запросом пользователя, был подписан центром сертификации кластера), он не имеет права выполнять какие-либо действия в кластере.

Дополнительные права можно легко добавить, создав Role/ClusterRole и привязав их к пользователю при помощи RoleBinding/ClusterRoleBinding, но эту задачу я оставляю в качестве упражнения для читателя.

Заключение


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

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

Перевод Headlamp новый GUI для работы с Kubernetes

23.12.2020 12:19:27 | Автор: admin
Прим. перев.: месяц назад компания Kinvolk выпустила свой интерфейс для управления Kubernetes-кластерами. Новый Open Source-проект, пополнив уже немалочисленные ряды подобных решений, сочетает в себе классический подход к дизайну интерфейсов, возможность запуска локально и внутри кластера, а также высокую расширяемость, что вместе с достаточно богатым набором функций делает его интересным хотя бы для первичного знакомства. В этом анонсе его авторы рассказывают, почему Headlamp стал именно таким.



Читая материалы по Kubernetes, вы наверняка неоднократно сталкивались с примерами различных kubectl-команд и хитрых конфигов на YAML. У людей, хорошо разбирающихся в K8s, такой подход, без сомнения, не вызывает никакого отторжения. Но в век повсеместного распространения веб-интерфейсов его нельзя назвать дружественным к обычным пользователям. Он усложняет процесс познания для новичков и выступает барьером для тех, кто не особо хорошо знаком с Kubernetes.

Конечно, существуют различные графические интерфейсы для K8s, в том числе Kubernetes Dashboard, являющийся частью самого upstream Kubernetes. (Прим. перев.: О многих из существующих решений мы уже рассказывали в этом сравнении.) Однако, исследуя все многообразие вариантов, мы не сумели подобрать решение, которое бы полностью нас устраивало. Хотелось, чтобы интерфейс:

  • был на 100% Open Source;
  • активно поддерживался сообществом;
  • являлся универсальным в том смысле, что не был привязан к дистрибутиву Kubernetes конкретного поставщика;
  • был модульным и расширяемым;
  • имел опрятный и современный внешний вид;
  • был реализован на стеке, хорошо знакомом нашим разработчикам (Go, JavaScript/TypeScript, React);
  • являлся интерактивным (т.е. не только собирал данные, но и позволял проводить определенные действия с кластером);
  • поддерживал мульти-кластерный режим.

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

Представляем Headlamp


Сегодня я с гордостью объявляю о широкой доступности нового пользовательского интерфейса для Kubernetes под названием Headlamp.

Headlamp универсальный и расширяемый пользовательский интерфейс к Kubernetes, удовлетворяющий критериям выше. Конечно же, являясь детищем Kinvolk, он на 100% Open Source. Мы надеемся, что многие участники сообщества Kubernetes не только по достоинству оценят Headlamp, но и внесут свой вклад в проект.

Давайте вкратце рассмотрим его основные характеристики.

Расширяемый UI


Мы стремимся к тому, чтобы Headlamp подходил для как можно большего числа сценариев использования. Целевой аудиторией проекта являются не только новички в Kubernetes, но и опытные администраторы, а также вендоры K8s с весьма различными потребностями. Часто (особенно это касается UI-проектов) подобное разнообразие сценариев применения реализуется за счет создания большого числа форков, каждое из которых обслуживается своей downstream-командой. Но поддерживать форки в актуальном состоянии тем сложнее, чем масштабнее в них изменения.

Система плагинов позволяет решить эту проблему. Именно поэтому Headlamp поддерживает out-of-tree плагины к UI. Они представляют собой JavaScript-файлы, подгружаемые бэкендом Headlamp и передаваемые клиенту, который динамически их загружает.

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

Механизм плагинов Headlamp открывает широкие возможности для сообщества. И мы готовы сотрудничать со всеми, кто желает поучаствовать в разработке новых плагинов для Headlamp, и развивать сам механизм, приспосабливая его для новых сценариев использования.

Traceloop


Чтобы продемонстрировать всю мощь механизма плагинов (да и самого инструмента), мы разработали Headlamp-плагин для гаджета traceloop, входящего в проект Inspektor Gadget (набор инструментов для инспекции и отладки приложений в Kubernetes прим. перев.).

После установки Inspektor Gadget и включения гаджета traceloop тот начинает записывать все системные вызовы из pod'а в кольцевой буфер. Этот буфер можно просматривать в реальном времени в процессе работы pod'а. Другими словами, traceloop позволяет заглянуть в то, что pod делает прямо сейчас. Кроме того, данные в буфере сохраняются для pod'ов, завершивших работу. Так можно установить причину сбоя уже после того, как он произошел, этакий черный ящик для приложений Kubernetes.



Избирательный UI


Проблема со многими пользовательскими CRUD-интерфейсами состоит в том, что они ничего не знают о внутренней организации контроля доступа. Например, присутствие кнопок для редактирования/удаления вводит пользователя в заблуждение, если у него на самом деле нет прав на изменение ресурса. Headlamp проверяет RBAC-настройки Kubernetes и показывает только элементы управления для тех действий, которые доступны пользователю. Например, если у пользователя нет права редактировать ресурс, то и кнопка редактировать не будет показана.

Все это чрезвычайно благоприятно сказывается на пользовательском опыте: ведь оператор сразу видит, какие действия ему доступны с учетом текущих прав. Это отлично подходит для ситуаций, когда предоставляются ограниченные по времени полномочия (например, временное разрешение на удаление ресурса).


Доступные кнопки для действий с pod'ом, когда у пользователя есть права на изменение/удаление


Доступные кнопки, когда у пользователя нет прав на изменение/удаление

Дизайн / Пользовательский интерфейс


Мы стремились сделать дизайн Headlamp максимально лаконичным и современным, при этом придерживаясь традиционного Kubernetes UI или стиля панели управления. Например, мы убеждены, что привычный табличный вид отлично подходит для работы, и надеемся, что другие типы визуализации (например, представление кластера в виде графов) могут быть реализованы с помощью плагинов.

Фронтенд реализован на React с библиотекой Material UI (она современна, аккуратна и поддерживается обширным сообществом пользователей). Плюс ко всему, она входит в технологический стек другого нашего проекта Nebraska (менеджер обновлений для Flatcar Container Linux прим. перев.), позволяя нам обмениваться опытом и ресурсами и обеспечивая единообразие UI во всех продуктах.

Локально или в кластере


Большинство пользовательских интерфейсов для Kubernetes делятся на две группы: удаленные (бэкенд часто находится в кластере) вроде Kubernetes Dashboard или локальные (приложение установлено на компьютер) как Octant от VMware.

У каждого из этих подходов имеются свои преимущества и недостатки. Например, в случае удаленного приложения очень просто поделиться URL с другими пользователями и реализовать их вход через OIDC. Оно доступно везде, и его легко поддерживать в актуальном состоянии. Наоборот, в случае десктоп-версии нет необходимости задумываться о размещении UI. Этот подход обеспечивает лучшую изоляцию, однако забота о поддержании приложения в актуальном состоянии ложится на плечи пользователей.

С Headlamp больше не нужно выбирать между этими двумя подходами: они оба поддерживаются. Headlamp можно легко разместить в кластере, воспользовавшись нашими YAML-файлами (и адаптировав их под себя), или установить локально на машину под управлением Linux, macOS или Windows.

Мульти-кластерный режим


Большинство Kubernetes deployment'ов состоят из нескольких кластеров (хотя бы для того, чтобы разделить dev- и prod-окружения). Headlamp обеспечивает доступ во все эти кластеры: конкретный метод зависит от того, запускаете ли вы его локально или удаленно.

При локальном запуске Headlamp будет считывать kubeconfig'и и отображать доступные там контексты, позволяя пользователю изменять их при необходимости, просто устанавливая локальную переменную среды на соответствующий кластер.

Мульти-кластерный режим устроен очень просто: для каждого настроенного кластера создается прокси, и запросы от UI (с вызовами к Kubernetes API) перенаправляются на адрес нужного кластера. Здесь следует упомянуть проект K8dash, модули для управления запросами/API которого мы использовали при разработке Headlamp.

Этот подход также можно совместить с запуском in-cluster, однако для этого кластеру, в котором работает приложение, потребуется API-доступ к другим заданным кластерам.



Связь с Lokomotive Kubernetes


Как вам, вероятно, известно, у нас также есть свой дистрибутив Kubernetes Lokomotive. Мы используем Headlamp в Lokomotive по его прямому назначению, но хотим подчеркнуть, что это самостоятельные и независимые проекты. Мы не собираемся привязывать Headlamp к какому-либо поставщику услуг K8s, и разрабатываем его так, чтобы он работал в любом типичном кластере Kubernetes.

Попробуйте Headlamp в своем кластере!


Сделать это очень просто: разверните deployment в своем кластере и перейдите в браузере по соответствующему адресу, или скачайте и установите десктоп-версию для Windows, macOS или Linux. Подробности в документации.

Headlamp инструмент с полностью открытым исходным кодом, выпущенный на условиях лицензии Apache 2.0. Как упоминалось выше, мы сделали его независимым от поставщиков услуг Kubernetes и универсальным в плане применения (охватывающим большое число сценариев использования). Сегодня мы приглашаем всех желающих принять участие в развитии проекта! Для этого, пожалуйста, ознакомьтесь с соответствующими рекомендациями.

Надеемся, Headlamp вам понравится!



P.S. от переводчика


Читайте также в нашем блоге:

Подробнее..

7 вещей, которые нужно проработать, прежде чем запускать OpenShift в продакшн

24.12.2020 16:21:15 | Автор: admin
Взрывной рост использования контейнеров на предприятиях впечатляет. Контейнеры идеально совпали с ожиданиями и потребностями тех, кто хочет снизить затраты, расширить свои технические возможности и продвинуться вперед по пути agile и devops. Контейнерная революция открывает новые возможности и для тех, кто подзадержался с обновлением ИТ-систем. Контейнеры и Kubernetes это абсолютно и принципиально новый способ управления приложениями и ИТ-инфраструктурой.



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

Многие решают ускорить переход на контейнеры с помощью Red Hat OpenShift Container Platform, ведущей отраслевой Kubernetes-платформы для корпоративного сектора. Это решение автоматически берет на себя множество задач первого дня и предлагает лучшую Kubernetes-экосистему на базе единой, тщательно протестированной и высоко защищенной платформы. Это наиболее комплексное и функциональное решение для предприятий, которое содержит всё необходимое для начала работы и устраняет массу технических барьеров и сложностей при построении Kubernetes-платформы.

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

1. Стандартизация правил именования и метаданных


В компьютерных науках есть только две трудные вещи: аннулирование кэша и именование сущностей.
Фил Карлтон (Phil Karlton)

У всякой сущности в OpenShift и Kubernetes есть свое имя. И у каждого сервиса должно быть свое DNS-имя, единственное ограничение здесь правила именования DNS. А теперь представьте, что монолитное приложение разложилось на 100500 отдельных микросервисов, каждый с собственной базой данных. И да, в OpenShift всё является либо иерархическим, связанным, либо должно соответствовать шаблону. Так что именовать придется массу и массу всего. И если заранее не подготовить стандарты, это получится настоящий Дикий Запад.

Вы уже распланировали схему реализации сервисов? Допустим, это будет одно большое пространство имен, например, databases, в котором все будут размещать свои базы данных. OK, и даже допустим, что все так и будут делать, но потом-то они начнут размещать свои кластеры Kafka в своих собственных пространствах имен. Да, а нужно ли заводить пространство имен middleware? Или лучше назвать его messaging? И как обычно, в какой-то момент появляются ребята, которые всегда идут своим путем и считают себя особенными, и говорят, что им нужны собственные пространства имен. И слушайте, у нас же в организации 17 подразделений, может надо приделать ко всем пространствам имен наши стандартные префиксы подразделений?

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

Другая мегаполезная вещь это метаданные. Стандартизируйте, какие активы хотите отслеживать, и убедитесь, что на соответствующих ресурсах прописаны нужные метаданные. Начните с рекомендованных меток. Например, аннотация support_email в метаданных пространства имен может сэкономить драгоценное время при выходе на техподдержку второго уровня в случае серьезного отказа. Кроме того, метаданные можно использовать, чтобы сократить имена ресурсов до вменяемой длинны, а не прописывать туда всю необходимую информацию через дефис. Привлеките всех, от архитекторов приложений до ИТ-эксплуатантов, устройте мозговой штурм и просчитайте наперед, что может здесь понадобиться, чтобы иметь продуманные стандарты к моменту запуска OpenShift.

2. Стандартизация корпоративных базовых образов


Одна из ключевых фишек контейнеров это возможность миксовать и подбирать все составляющие программного стека. Можно, конечно, взять любимую разновидность ОС и строить все на ней, но действуя подобным образом организация упускает огромные возможности. Ведь что по-настоящему круто в контейнерных образах? Многослойность. Вы можете снять с разработчиков массу критичных задач и решать их за счет стандартизации образов.

Возьмем, к примеру, базовое java-приложение. Ваши разработчики вряд ли ошибутся с выбором OpenJDK, а вот с управлением уязвимостями, обновлением библиотек и прочими вопросами ИТ-гигиены вполне могут. Мы все знаем, что бизнес-задачи зачастую решаются ценой технических компромиссов, вроде намеренного использования старых версий Java. К счастью, такие задачи легко автоматизируются и управляются на уровне предприятия. Вы по-прежнему может использовать базовые образы вендора, но одновременно задавать и контролировать свои циклы обновления, создавая собственные базовые образы.

Возвращаясь к примеру выше, допустим, разработчикам нужна Java 11, а вам, соответственно, надо, чтобы они всегда использовали самую последнюю версию Java 11. Тогда вы создаете корпоративный базовый образ (registry.yourcompany.io/java11), используя в качестве отправной точки базовый образ от вендора ОС (registry.redhat.io/ubi8/openjdk-11). А когда этот базовый образ обновляется, вы автоматом помогаете разработчикам задействовать последние обновления. К тому же, таким образом реализуется уровень абстракции, позволяющий бесшовно дополнять стандартный образ необходимыми библиотеками или Linux-пакетами.

3. Стандартизация проверок работоспособности и готовности


Контроль исправности, он нужен практически везде. Считается, что для человека достаточно ежегодного медосмотра. Исправность приложений надо проверять, понятно, гораздо чаще, и контролировать две ключевые вещи:

  • Запущено ли приложение (health check работоспособность).
  • Готово ли приложение (readiness check готовность).

Существует масса и других метрик, чтобы облегчить мониторинг приложений, но вот эти две это основа основ не только мониторинга, но и масштабирования. Работоспособность обычно определяется наличием сетевого подключения и способностью узла, на котором выполняется приложение, отозваться на запрос. Что касается готовности, то здесь уже каждое приложение должно реагировать на запросы по своим стандартам. Например, запуск приложения с очень низкими задержками может сопровождаться длительным обновлением кэша или прогревом JVM. И соответственно, пауза между ответами Запущено и Готово может достигать нескольких минут. А вот, например, для stateless REST API с реляционной базой данных эти ответы будут приходить одновременно.

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

Второй аспект таких проверок это стандартизация. Как проверить готовность? Если у вас нет стандартов, то даже такой простой вопрос может стать настоящим кошмаром для мониторинга. Просто сравните, как разошлись друг от друга стандарты Quarkus и стандарты Spring Boot. А ведь никто этого не хотел, но со стандартами всегда так. Единственная разница в том, что теперь ваша организация сама имеет власть разрабатывать и вводить стандарты.
Примечание на полях. Не изобретайте свои стандарты. Просто найдите и используйте какой-нибудь готовый.

4. Стандартизация логов


Продолжая тему мониторинга, отметим, что сочетание недорогих хранилищ и решений класса big data породило на предприятиях нового монстра тотальное журналирование. Раньше это были неструктурированные и архаичные консольным логи, которые жили недолго и создавались от случая к случаю. Теперь норовят запротоколировать всё подряд и выстроить датасайнс с машинным обучением, чтобы самым революционным образом оптимизировать операции и мониторинг. Увы, надо признать очевидное: любые попытки начать собирать логи сотен приложений, не имея при этом абсолютно никаких стандартов и даже не задумываясь о них, неизменно приводят к бессмысленным и непомерным тратам на инструменты для управления логами и трансформации данных лишь для того, чтобы только начать работу. То есть еще до того, как вы поймете, что сообщения Выполнен переход или Этот блок сработал вряд имеют хоть какое-то отношение к вашим операциям.

Стандартизировать надо структуру. Повторимся: целостность стандартов важнее их правильности. Вы должны быть способы написать отдельный лог-парсер для каждого приложения, которое есть на предприятии. Да, это будут сугубо штучные, не тиражируемые вещи. Да, у вас будет куча исключений, которые нельзя контролировать, особенно для коробочных приложений. Но не выплескивайте ребенка вместе с водой, уделите внимание деталям: например, временная метка в каждом логе должна отвечать соответствующему стандарту ISO; сам вывод должен быть в формате UTC с точностью до 5-го знака в микросекундах (2018-11-07T00:25:00.07387Z). Уровни журнала должны быть оформлены CAPS-ом и там должны быть элементы TRACE, DEBUG, INFO, WARN, ERROR. В общем, задайте структуру, а уже затем разбирайтесь с подробностями.

Стандартизация структуры заставит всех придерживаться одних правил и использовать одни и те же архитектурные шаблоны. Это верно для логов как приложений, так и платформ. И не отклоняйтесь от готового решения без крайней нужды. EFK-стек (Elasticsearch, Fluentd и Kibana) платформы OpenShift должен быть в состоянии обработать все ваши сценарии. Он ведь вошел в состав платформы не просто так, и при ее обновлении это еще одна вещь, о которой не надо беспокоиться.

5. Переход на GitOps


Одна из главных прелестей OpenShift заключается в том, что здесь всё буквально: всё в конечном является либо конфигурацией, либо кодом, а значит, может контролироваться через систему управления версиями. Это позволяет революционизировать способы доставки и избавиться от бюрократии при запуске в продакшн.

В частности, традиционную схему на основе тикетов можно полностью заменить на модель с pull-запросами git. Допустим, владелец приложения хочет подкорректировать выделяемые приложению ресурсы после реализации в нем новых функций, например, увеличить память с 8 до 16 ГБ. В рамках традиционной схемы разработчику для этого надо создать тикет и ждать, пока кто-то другой выполнит соответствующую задачу. Этим кем-то другим чаще всего оказывается ИТ-эсплуатант, который лишь вносит ощутимую задержку в процесс реализации изменений, никак не повышая ценность этого процесса, или хуже того, навешивая на этот процесс лишние дополнительные циклы. В самом деле, у эсплуатанта есть два варианта действий. Первое: он рассматривает заявку и решает ее выполнить, для чего входит в продакшн-среду, вносит затребованные изменения вручную и перезапускает приложение.
Помимо времени на проведение самой работы здесь возникает и дополнительная задержка, поскольку у эксплуатанта, как правило, всегда есть целая очередь заявок на выполнение. Кроме того, возникает риск человеческой ошибки, например, ввод 160 ГБ вместо 16 ГБ. Второй вариант: эксплуатант ставит заявку под сомнение и тем самым запускает цепную реакцию по выяснению причин и последствий запрашиваемых изменений, да так, что иногда уже приходится вмешиваться начальству.

Теперь посмотрим, как это делается в GitOps. Запрос на изменения попадает в репозиторий git и превращается в pull-запрос. После чего разработчик может выставить этот pull-запрос (особенно, если это изменения в продакшн-среде) для утверждения причастными сторонами. Таким образом, специалисты по безопасности могут подключиться уже на ранней стадии, и всегда есть возможность отследить последовательность изменений. Стандарты в этой области можно внедрять программно, используя соответствующие средства в инструментальной цепочке CI/CD. После того, как его утвердили, pull-запрос версионируется и легко поддается аудиту. Кроме того, его можно протестировать в среде pre-production в рамках стандартного процесса, полностью устранив риск человеческой ошибки.

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

6. Схемы приложений (Blueprints)


Переход от монолитных приложений к микросервисам усиливает роль шаблонов проектирования (паттернов) приложений. В самом деле, типичное монолитное приложение не особо поддается классификации. Как правило, там есть и REST API, и пакетная обработка, и событиями оно управляется. HTTP, FTP, kafka, JMS и Infinispan? Да пожалуйста, а еще оно одновременно работает с тремя разными базами данных. И как прикажете создавать схему, когда здесь намешана целая куча шаблонов интеграции корпоративных приложений? Да никак.

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

  • REST API для управления данными в СУБД.
  • Пакетная обработка, которая проверят FTP-сервер на предмет обновления данных и отправляет их в топик kafka.
  • Camelадаптер, берущий данные из этого kafka-топика и отправляющий их в REST API
  • REST API, которые выдают обобщенную информацию, собираемую из Data Grid, которая действует как конечный автомат.

Итак, теперь у нас есть схемы, а схемы уже можно стандартизировать. REST API должны отвечать стандартам Open API. Пакетные задания будут управляться как пакетные задания OpenShift. Интеграции будут использовать Camel. Схемы можно создавать для API, для пакетных заданий, для AI/ML, для multicast-приложений, да для чего угодно. А затем уже можно определять, как развертывать эти схемы, как их конфигурировать, какие шаблоны использовать. Имея такие стандарты, не надо будет каждый раз изобретать колесо, и вы сможете лучше сфокусироваться на действительно важных задачах, вроде создания нового бизнес-функционала. Проработка схем может показаться пустой тратой времени, но затраченные усилия сторицей вернутся в будущем.

7. Подготовьтесь к API


Вместе с микросервисной архитектурой приходят и API. Ими тоже придется управлять и лучше подготовиться к этому заранее.

Во-первых, здесь опять понадобятся стандарты. В качестве отправной точки можно взять стандарты Open API, но придется углубиться в дебри. Хотя здесь важно соблюсти баланс и не впасть в чрезмерную зарегламентированность с кучей ограничений. Посмотрите на эти вопросы: когда новая сущность создается с помощью POST, что надо возвращать, 201 или 200? разрешается ли обновлять сущности с помощью POST, а не PUT? В чем разница между 400-ми и 500-ми ответами? примерно такой уровень детализации вам нужен.

Во-вторых, понадобится сервисная сетка service mesh. Это реально сильная вещь и со временем она станет неотъемлемой частью Kubernetes. Почему? Потому что трафик рано или поздно превратится в проблему, и вам захочется управлять им как внутри дата-центра (т.н. трафик восток-запад), так и между дата-центром и внешним по отношению к нему миром (север-юг). Вам захочется вытащить из приложений аутентификацию и авторизацию и вывести их на уровень платформы. Вам понадобятся возможности Kiali по визуализации трафика внутри service mesh, а также сине-зеленые и канареечные схемы развертывания приложений, или, к примеру, динамический контроль трафика. В общем, service mesh без вопросов входит в категорию задач первого дня.

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

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

Однако, надежда есть, и она заключается в автоматизации. Любой из перечисленных выше стандартов можно внедрить с помощью автоматизации. Процесс GitOps может проверять, что во всех соответствующих yaml-файлах присутствуют все требуемые метки и аннотации. Процесс CI/CD может контролировать соблюдение стандартов на корпоративные образы. Все может быть кодифицировано, проверено и приведено в соответствие. Кроме того, автоматизацию можно доработать, когда вы вводите новые стандарты или меняете существующие. Безусловное преимущество стандартизации через автоматизацию заключается в том, что компьютер не избегает конфликтов, а просто констатирует факты. Следовательно, при достаточной проработанности и инвестициях в автоматизацию, платформа, в которую вы вкладываете столько средств сегодня, может принести гораздо больший возврат инвестиций в будущем в виде повышения производительности и стабильности.
Подробнее..

Перевод Решение проблем связанности микросервисов с помощью сетевых журналов

25.12.2020 14:07:02 | Автор: admin


Сеть является основой для распределенных приложений. Распределенное приложение имеет несколько микросервисов, каждый из которых работает в наборе Подов, часто расположенных на разных Нодах. Проблемные области в распределенном приложении могут быть на уровне сети (Flow, сетевые журналы), или на уровне недоступности ресурсов приложения (Метрики) или недоступности компонентов (трассировка).

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



Сетевые Журналы Имеют Несколько Сценариев Использования


Сетевые журналы могут использоваться для выполнения уникальных требований различных команд (DevOps, SecOps, Platform, Network). Ценность сетевых журналов Kubernetes заключается в собранной информации, такой как подробный контекст о конечной точке / endpoint (например, поды, метки, пространства имен) и сетевые политики, развернутые при настройке соединения. В ИТ-среде команды DevOps, SecOps, Network и Platform могут использовать сетевые журналы для своих сценариев использования, которые полезны в их домене знаний. Ниже мы покажем несколько примеров.



Генерирование Политик и Обнаружение Угроз с Помощью Журналов Потоков Данных в Calico Enterprise.


Calico Enterprise генерирует контекстные журналы сетевых потоков при каждом подключении к поду. Журнал сохраняется в файл на ноде, который затем обрабатывается агентом fluentd и отправляется в настроенное место назначения.



Как показано на приведенной выше диаграмме, журналы по умолчанию отправляются в движок Elasticsearch, который поставляется с Calico Enterprise. Вы можете настроить пересылку журналов потоков на вашу SOC платформу. Мы рекомендуем Вам иметь единую платформу для всех ваших журналов. Журналы это важнейший инструмент мониторинга и анализа для команды эксплуатации, которая уже имеет четко определенные процессы, построенные на централизованной платформе журналирования. Это важно для вашего планирования.

Характеристики Журнала Потока Данных


Журналы потоков имеют много накладных расходов на хранение. По умолчанию, Calico Enterprise хранит только данные за последние семь дней. Это позволяет Calico Enterprise предоставлять функции, специально предназначенные для упрощения разработки политик и устранения неполадок подключения практически в режиме реального времени.

  • Предлагаемые рекомендации для создания политик позволяют разработчикам автоматически генерировать сетевые политики для защиты своих сервисов
  • Рабочий процесс для политик (рекомендации, предварительный просмотр, поэтапные политики) позволяет командам SecOps и DevOps эффективно создавать политики и развертывать их ненавязчивым образом
  • Обнаружение угроз позволяет командам SecOps отследить каждый flow по определенному IP-адресу или домену и выявить угрозы


Стандартный журнал потока в Calico Enterprise содержит в себе всю необходимую контекстную информацию:

  • Контекст Kubernetes (под, пространство имен, метки, политики)
  • IP-адрес отправителя для внешних источников, если он доступен через ingress
  • Start_time, end_time, action, bytes_in, bytes_out, dest_ip, dest_name, dest_name_aggr, dest_namespace, dest_port, dest_type, dest_labels, reporter, num_flows, num_flows_completed, num_flows_started, http_requests_allowed_in, http_requests_denied_in, packets_in, packets_out, proto, policies, source_ip, source_name, source_name_aggr, source_namespace, source_port, source_type, source_labels, original_source_ips, num_original_source_ips


Журнал DNS агрегируется для каждого пода с течением времени и содержит следующую информацию:

  • Start_time, end_time, type, count, client_ip, client_name, client_name_aggr, client_namespace, client_labels, qname, qtype, qclass, rcode, rrsets, servers


Записи журналов доступны в Kibana в виде индексов Elasticsearch. Вы полностью контролируете параметры индексации, время хранения и хранилище. Сохранение настроек по умолчанию хорошо подходит для большинства развертываний.

Сократите операционные расходы за счет оптимизации хранилища журнала потоков



Calico Enterprise собирает различные журналы (network / flow, audit, DNS). Журналы потоков являются самыми дорогими с точки зрения хранения, занимая более 95% общего объема хранилища. Нередко на каждую полностью загруженную ноду приходится 5k flow в секунду При скромных 200 байтах на flow это превращается в 1 МБ/с (мегабайт). Суточная потребность в хранилище для каждой ноды составляет 86 ГБ для журналов потоков. Для кластера из 100 узлов ежедневное требование к журналу потоков становится 8 ТБ+!!! Очевидно, что это не масштабируется. И что еще более важно, действительно ли вам нужно хранить так много данных? Как правило, ценность данных, содержащихся в журналах, экспоненциально уменьшается с течением времени и имеет значение только для устранения неполадок и обеспечения соответствия требованиям.

По этой причине Calico Enterprise имеет по умолчанию агрегацию, которая снижает требования к хранению журнала потоков более чем в 100 раз! Мы делаем это без ущерба для данных (видимость, мониторинг, поиск и устранение неисправностей), которые получают наши клиенты из журналов потоков. Журналы агрегируются по порту назначения в течение определенного периода времени. Таким образом, вам не нужно беспокоиться о стоимости хранения журналов потоков при использовании настроек по умолчанию в Calico Enterprise. Еще один способ, которым Calico Enterprise может помочь вам снизить требования к объему хранилища, это исключение. Вы можете легко настроить определенные пространства имен или инсталляции, которые будут исключены из создания журналов потоков.

Заинтересованы в детальном изучении журналов потоков?


Журналы потоков включены по умолчанию. Обратитесь к следующей документации для детальной настройки:

Подробнее..

Шифрование передаваемых данных в Calico Enterprise

25.12.2020 18:10:30 | Автор: admin


Мы рады сообщить, что Calico Enterprise, ведущее решение для сетей Kubernetes, безопасности и видимости в гибридных и мультиоблачных средах, теперь включает в себя шифрование передаваемых данных.

Calico Enterprise известен своим богатым набором средств сетевой безопасности для защиты контейнерных рабочих нагрузок путем ограничения трафика К и ОТ доверенных источников. Они включают в себя, но не ограничиваются, внедрением существующих практик контроля безопасности в Kubernetes, контролем egress с помощью DNS политик, расширением межсетевого экрана на Kubernetes, а также обнаружением вторжений и защитой от угроз. Однако по мере развития Kubernetes мы наблюдаем потребность в еще более глубоком подходе к защите конфиденциальных данных, который подпадает под требования нормативно-правового соответствия / compliance.

Не все угрозы исходят снаружи компании. По данным Gartner, почти 75% нарушений происходят из-за действий персонала внутри компании: сотрудников, бывших сотрудников, подрядчиков или деловых партнеров, которые имеют доступ к внутренней информации о средствах безопасности компании, данных и компьютерных системах. Такой уровень уязвимости данных неприемлем для организаций, которые имеют строгие требования к их защите и соблюдению нормативных требований. Независимо от того, откуда исходит угроза, доступ к зашифрованным данным есть только у законного владельца ключа шифрования, что обеспечивает защиту данных в случае попытки несанкционированного доступа.

Некоторые нормативные стандарты устанавливают требования к защите данных и соблюдению требований к организациям и указывают на использование средств шифрования, в том числе SOX, HIPAA, GDPR и PCI. Например, стандарт безопасности данных индустрии платежных карт (PCI DSS) применяется к организациям, которые работают с фирменными кредитными картами, и был создан для усиления контроля за данными держателей карт с целью сокращения случаев мошенничества. PCI DSS требует от организаций шифрования номеров счетов кредитных карт, хранящихся в их базах данных, и обеспечения безопасности данных при передаче. Проверка соответствия проводится ежегодно или ежеквартально.



Calico Enterprise решает эту проблему, используя WireGuard для внедрения шифрования передаваемых данных. WireGuard согласуется с подходом Tigera batteries-included" к сетям Kubernetes, безопасности и наблюдаемости. WireGuard работает в качестве модуля ядра Linux и обеспечивает лучшую производительность и более низкую загрузку процессора, чем протоколы туннелирования IPsec и OpenVPN. Независимые тесты производительности Kubernetes CNI показали, что Calico с включенной функцией шифрования работает в 6 раз быстрее, чем любое другое решение на рынке.

WireGuard работает как модуль внутри ядра Linux и обеспечивает лучшую производительность и более низкую загрузку процессора, чем протоколы туннелирования IPsec и OpenVPN. Включить шифрование передаваемых данных на Calico Enterprise очень просто все, что вам нужно это развернутый на операционной системе хоста кластер Kubernetes с WireGuard. Полный список поддерживаемых операционных систем и инструкции по установке вы найдете на веб-сайте WireGuard.

Тесты производительности CNI


Являясь отраслевым стандартом для сетей Kubernetes и сетевой безопасности, Calico обеспечивает работу более миллиона нод Kubernetes каждый день. Calico единственный CNI, имеющий возможность поддерживать три data plane из одной, унифицированой контрольной панели. Независимо от того, что вы используете eBPF, Linux или Windows data plane; Calico обеспечивает невероятно высокую производительность и исключительную масштабируемость, что подтверждают последние бенчмарк-тесты.

Последний бенчмарк сетевых плагинов Kubernetes (CNI) по сети 10 Гбит/с опубликовал Алексис Дюкастель, CKA/CKAD Kubernetes и основатель InfraBuilder. Тест основывался на версиях CNI, которые были актуальны и обновлены по состоянию на август 2020 года. Были протестированы и сравнены только те CNI, которые можно настроить с помощью одного yaml-файла, включая:

  • Antrea V. 0. 9. 1
  • Calico v3. 16
  • Canal v3.16 (сетевые политики Flannel + Calico)
  • Cilium 1.8.2
  • Flanel 0.12.0
  • Kube-router последняя версия (2020-08-25)
  • WeaveNet 2.7.0

Среди всех протестированных CNI Calico стал явным победителем, продемонстрировав превосходство практически во всех категориях и получив превосходные результаты, которые приведены в таблице ниже. Фактически, Calico является предпочтительным выбором CNI в случаях первичного использования, представленных автором в резюме отчета.



Ознакомьтесь с полными результатами последних бенчмарк-тестов Kubernetes CNI. Вы также можете запустить бенчмарк на собственном кластере, с помощью инструмента Kubernetes Network Benchmark Tool от InfraBuilder.
Подробнее..

Перевод Go-приложение с бессерверной архитектурой на Kubernetes с Knative

29.12.2020 20:14:34 | Автор: admin
Автор нашей новой переводной статьи утверждает, что Knative лучшее, что только могли придумать во Вселенной! Вы согласны?

Если вы уже используете Kubernetes, то, вероятно, слышали о бессерверной архитектуре (serverless). Хотя обе платформы, Kubernetes и Knative, являются масштабируемыми, именно бессерверная архитектура делает всё возможное, чтобы предоставлять разработчикам работающий код и не беспокоить их проблемами инфраструктуры. Кроме того, такая архитектура сокращает расходы на инфраструктуру за счет виртуального масштабирования экземпляров приложения с нуля.


С другой стороны, вы можете использовать преимущества Kubernetes без ограничений, следуя традиционной модели хостинга и продвинутым методам управления трафиком. Благодаря этому, нам открываются различные возможности, например, сине-зеленый деплой (blue-green deployments) и A/B-тестирование.

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

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

Кроме того, Knative позволяет разработчикам писать слабо связанный (loosely coupled) код со своим фреймворком обработки событий, который обеспечивает универсальную подписку, доставку и управление событиями. Это означает, что вы можете объявить возможность подключения к событиям, и ваши приложения могут подписаться на определенные потоки данных.

Возглавляемая Google, данная open-source платформа была включена в Cloud Native Computing Foundation. Это подразумевает отсутствие привязки к вендору, что в противном случае является существенным ограничением текущих облачных бессерверных решений FaaS. Вы можете запустить Knative в любом кластере Kubernetes.

Для кого Knative?


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



Инженеры могут сосредоточиться на управлении кластером Kubernetes, а также на установке и обслуживании экземпляров Knative с помощью kubectl, а разработчики занимаются созданием и развертыванием приложений с использованием интерфейса Knative API.

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

Почему Knative стоит использовать?


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

Kubeless помогает разработчикам упростить выполнение своего кода без необходимости слишком много знать о том, что происходит под капотом Kubernetes.

Кластер Kubernetes занимает ресурсы инфраструктуры, так как требует, чтобы у всех приложений был хотя бы один запущенный контейнер. Knative управляет этим аспектом за вас и заботится об автоматическом масштабировании контейнеров в кластере с нуля. Это позволяет администраторам Kubernetes упаковать множество приложений в один кластер.

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

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

Кроме того, он довольно хорошо интегрируется с движком Eventing и упрощает задачу в проектировании несвязанных систем. Код приложения может оставаться полностью свободным от какой-либо конфигурации конечной точки, и вы можете публиковать и подписываться на события, объявляя конфигурации на уровне Kubernetes. Это значительное преимущество для сложных микросервисных приложений!

Как Knative работает?


Knative предоставляет интерфейс kn API с помощью операторов Kubernetes и CRD. Используя их, вы можете развертывать приложения с помощью командной строки. В фоновом режиме Knative создаст все необходимое в Kubernetes (развертывание, сервисы, входящие данные и т. д.) для запуска приложений, и вам не придется об этом беспокоиться.

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



Knative предоставляет конечные точки приложения с использованием собственного домена в формате [app-name].[namespace].[custom-domain].

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

Knative это объединение множества продуктов CNCF и продуктов с открытым исходным кодом, таких как Kubernetes, Istio, Prometheus, Grafana, и движков потоковой передачи событий, таких как Kafka и Google Pub/Sub.

Установка Knative


Knative имеет разумную модульную структуру, и вы можете установить только необходимые компоненты. Knative предлагает компоненты событий, обслуживания и мониторинга. Установить их можно, применив пользовательские CRD.

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

Установка Knative довольна сложна и достойна рассмотрения в отдельной статье. Но для демонстрации давайте начнем с установки обслуживающего компонента.

Для этого вам потребуется работающий кластер Kubernetes.

Установите Service CRD и основные обслуживающие компоненты (serving core components):

kubectl apply -f
https://github.com/knative/serving/releases/download/v0.17.0/serving-crds.yaml

kubectl apply -f
https://github.com/knative/serving/releases/download/v0.17.0/serving-core.yaml


Установите Istio для Knative:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.7.0 sh && cd istio-1.7.0 && export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo
kubectl label namespace knative-serving istio-injection=enabled

Подождите, пока Istio будет готов, проверив, выделил ли Kubernetes внешний IP-адрес шлюзу Istio Ingress:

kubectl -n istio-system get service istio-ingressgateway


Определите собственный домен и настройте DNS, чтобы он указывал на IP-адрес шлюза Istio ingress:

kubectl patch configmap/config-domain --namespace knative-serving --type merge -p "{\data\:{\"$(kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}').xip.io\":\"\"}}"
kubectl apply -f https://github.com/knative/net-istio/releases/download/v0.17.0/release.yaml
kubectl apply -f https://github.com/knative/serving/releases/download/v0.17.0/serving-default-domain.yaml

Установите надстройку Istio HPA:

kubectl apply -f
https://github.com/knative/serving/releases/download/v0.17.0/serving-hpa.yaml

Установка Knative CLI


Установить Knative CLI просто. Необходимо загрузить последнюю версию бинарного файла Knative CLI в папку bin или указать соответствующий путь.

sudo wget https://storage.googleapis.com/knative-nightly/client/latest/kn-linux-amd64 -O /usr/local/bin/kn
sudo chmod +x /usr/local/bin/kn
kn version

Запуск приложения Hello, World!


А теперь давайте запустим наше первое Hello, World! приложение, чтобы понять, насколько просто оно разворачивается с помощью Knative.

Воспользуемся образцом приложения Hello, World! на Go для демонстрации. Это простой REST API, который возвращает Hello $TARGET, где $TARGET это переменная среды, которую вы можете установить в контейнере.

Выполните следующую команду, чтобы начать:

$ kn service create helloworld-go --image gcr.io/knative-samples/helloworld-go --env TARGET="World" --annotation autoscaling.knative.dev/target=10Creating service 'helloworld-go' in namespace 'default':0.171s Configuration "helloworld-go" is waiting for a Revision to become ready.  6.260s ...  6.324s Ingress has not yet been reconciled.  6.496s Waiting for load balancer to be ready  6.637s Ready to serve.Service 'helloworld-go' created to latest revision 'helloworld-go-zglmv-1' is available at URL:http://helloworld-go.default.34.71.125.175.xip.io


kubectl get podNo resources found in default namespace.


Запустим сервис helloworld.

$ curl http://helloworld-go.default.34.71.125.175.xip.io
Hello World!

И через некоторое время мы получаем ответ. Давайте посмотрим на поды.

$ kubectl get podNAME                                               READY   STATUS    RESTARTS   AGEhelloworld-go-zglmv-1-deployment-6d4b7fb4f-ctz86   2/2     Running   0          50s


Итак, как вы можете видеть, Knative развернул под в фоновом режиме за одно движение. Получается, что мы буквально масштабировали с нуля.

Если мы дадим немного времени, мы увидим, что под начинает завершаться. Давайте посмотрим, что происходит.

$ kubectl get pod -wNAME                                               READY   STATUS    RESTARTS   AGEhelloworld-go-zglmv-1-deployment-6d4b7fb4f-d9ks6   2/2     Running   0          7shelloworld-go-zglmv-1-deployment-6d4b7fb4f-d9ks6   2/2     Terminating   0          67shelloworld-go-zglmv-1-deployment-6d4b7fb4f-d9ks6   1/2     Terminating   0          87s


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

Давайте пройдем еще немного дальше. Если вы посмотрите на аннотации, мы ограничили каждый под обработкой до 10 одновременных запросов. Итак, что произойдет, если мы загрузим наши функции сверх этого? Сейчас выясним!

Мы воспользуемся утилитой hey для нагрузки на приложение. Следующая команда отправляет 50 одновременных запросов к конечной точке в течение 30 секунд.

$ hey -z 30s -c 50 http://helloworld-go.default.34.121.106.103.xip.io  Average:      0.1222 secs  Requests/sec: 408.3187Total data:   159822 bytes  Size/request: 13 bytesResponse time histogram:  0.103 [1]     |  0.444 [12243] |  0.785 [0]     |  1.126 [0]     |  1.467 [0]     |  1.807 [0]     |  2.148 [0]     |  2.489 [0]     |  2.830 [0]     |  3.171 [0]     |  3.512 [50]    |Latency distribution:  10% in 0.1042 secs  25% in 0.1048 secs  50% in 0.1057 secs  75% in 0.1077 secs  90% in 0.1121 secs  95% in 0.1192 secs  99% in 0.1826 secsDetails (average, fastest, slowest):  DNS+dialup:   0.0010 secs, 0.1034 secs, 3.5115 secs  DNS-lookup:   0.0006 secs, 0.0000 secs, 0.1365 secs  req write:    0.0000 secs, 0.0000 secs, 0.0062 secs  resp wait:    0.1211 secs, 0.1033 secs, 3.2698 secs  resp read:    0.0001 secs, 0.0000 secs, 0.0032 secsStatus code distribution:  [200] 12294 responses


Теперь посмотрим на поды.

$ kubectl get podNAME                                                READY   STATUS    RESTARTS   AGEhelloworld-go-thmmb-1-deployment-77976785f5-6cthr   2/2     Running   0          59shelloworld-go-thmmb-1-deployment-77976785f5-7dckg   2/2     Running   0          59shelloworld-go-thmmb-1-deployment-77976785f5-fdvjn   0/2     Pending   0          57shelloworld-go-thmmb-1-deployment-77976785f5-gt55v   0/2     Pending   0          58shelloworld-go-thmmb-1-deployment-77976785f5-rwwcv   2/2     Running   0          59shelloworld-go-thmmb-1-deployment-77976785f5-tbrr7   2/2     Running   0          58shelloworld-go-thmmb-1-deployment-77976785f5-vtnz4   0/2     Pending   0          58shelloworld-go-thmmb-1-deployment-77976785f5-w8pn6   2/2     Running   0          59s


Как мы видим, Knative масштабирует поды по мере увеличения нагрузки на функцию и замедляет ее, когда нагрузки больше нет.

Заключение


Knative сочетает в себе лучшие характеристики бессерверной архитектуры и возможности Kubernetes. Он постепенно движется к стандартному способу реализации FaaS. Поскольку Knative входит в CNCF и вызывает всё больший интерес среди технических специалистов, возможно, скоро мы обнаружим, что облачные провайдеры внедряют Knative в свои бессерверные продукты.

Спасибо, что прочитали мою статью! Надеюсь, она вам понравилась.
Подробнее..

Жизнь .NET приложения в Kubernetes

03.01.2021 20:22:24 | Автор: admin

Поддержка в рабочем состояние заданного набора контейнеров является одним из главных преимуществ использования Kubernetes

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

Чтобы начать экспериментировать, мне понадобится кластер Kubernetes. Я буду использовать тестовое окружение, предоставляемое Docker Desktop. Для этого всего лишь потребуется активировать Kubernetes в настройках

Как установить Docker Desktop в Windows 10 можно узнать из первой части этой статьи

Создание Web API

Для дальнейших экспериментов я создам простой веб-сервис на основе шаблона ASP.NET Core Web API

Новый проект с названием WebApiLivenessНовый проект с названием WebApiLiveness

Добавлю через Package Manager пакет для генерации случайного текста командой Install-Package Lorem.Universal.Net -Version 3.0.69

Изменю файл Program.cs

using Microsoft.AspNetCore.Hosting;using Microsoft.Extensions.Hosting;using System;namespace WebApiLiveness{    public class Program    {        private static int _port = 80;        private static TimeSpan _kaTimeout = TimeSpan.FromSeconds(1);        public static void Main(string[] args)        {            CreateAndRunHost(args);        }        public static void CreateAndRunHost(string[] args)        {            var host = Host                .CreateDefaultBuilder(args)                .ConfigureWebHostDefaults(webBuilder =>                {                    webBuilder                        .UseKestrel(options =>                         {                            options.ListenAnyIP(_port);                            options.Limits.KeepAliveTimeout = _kaTimeout;                        })                        .UseStartup<Startup>();                })                .Build();            host.Run();        }    }}

Добавлю в проект класс LoremService, который будет возвращать случайно сгенерированный текст

using LoremNET;namespace WebApiLiveness.Services{    public class LoremService    {        private int _wordCountMin = 7;        private int _wordCountMax = 12;        public string GetSentence()        {            var sentence = Lorem.Sentence(_wordCountMin, _wordCountMax);            return sentence;        }    }}

В классе Startup зарегистрирую созданный сервис

public void ConfigureServices(IServiceCollection services){    services.AddSingleton<LoremService>();    services.AddControllers();}

Заменю созданный автоматически контроллер на LoremController

using Microsoft.AspNetCore.Mvc;using System;using System.Net;using WebApiLiveness.Services;using Env = System.Environment;namespace WebApiLiveness.Controllers{  [ApiController]  [Route("api/[controller]")]  public class LoremController : ControllerBase  {    private readonly LoremService _loremService;    public LoremController(LoremService loremService)    {        _loremService = loremService;    }    //GET api/lorem    [HttpGet]    public ActionResult<string> Get()    {      try      {          var localIp = Request.HttpContext.Connection.LocalIpAddress;          var loremText = _loremService.GetSentence();          var result =            $"{Env.MachineName} ({localIp}){Env.NewLine}{loremText}";          return result;      }      catch (Exception)      {          return new StatusCodeResult(            (int)HttpStatusCode.ServiceUnavailable);      }    }  }}

И наконец, добавлю файл Dockerfile с инструкциями для создания образа с приложением. За основу взят образ, оптимизированный для запуска приложений ASP.NET с версией .NET 5

FROM mcr.microsoft.com/dotnet/aspnet:5.0-buster-slimCOPY bin/Release/net5.0/linux-x64/publish/ App/WORKDIR /AppENTRYPOINT ["dotnet", "WebApiLiveness.dll"]

В результате у меня получилась следующая структура

Структура проектаСтруктура проекта

Создание и публикация образа

Подготовлю релиз приложения dotnet publish -c Release -r linux-x64

Создам образ, используя ранее подготовленный Dockerfile. Выполню команду из папки, где непосредственно находится этот файл docker build -t sasha654/webapiliveness .

И наконец, отправлю образ в Docker Hub docker push sasha654/webapiliveness

Я разместил образ в общедоступном репозитории и теперь его можно получить с любого устройства. Но если вы собираетесь проделать то же самое в своем репозитории Docker Hub, то очевидно, необходимо подставить вместо префикса sasha654 свой Docker ID, полученный при регистрации

Прежде чем разворачивать приложение в кластере Kubernetes, я проверю, что на данном этапе все сделано правильно и запущу контейнер из созданного образа непосредственно через Docker docker run -p 8080:80 -d sasha654/webapiliveness

И отправлю запрос curl http://localhost:8080/api/lorem

Отлично! Теперь остановлю и удалю этот, уже ненужный, контейнер

Запуск приложения в Kubernetes

Основной единицей развертывания в Kubernetes, является Pod это группа, состоящая из одного (чаще) или нескольких (гораздо реже) контейнеров

Поды почти никогда не создаются в кластере вручную. И в данном примере я создам другой ресурс Kubernetes ReplicaSet, который в свою очередь будет создавать поды и следить за ними

Манифест для ReplicaSet содержит инструкции для запуска 3 экземпляров подов на основе ранее опубликованного образа sasha654/webapiliveness. Созданным экземплярам будет присвоена метка api: loremapi

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: myrsspec:  replicas: 3  selector:    matchLabels:      api: loremapi  template:    metadata:      labels:        api: loremapi    spec:      containers:      - name: webapiliveness        image: sasha654/webapiliveness

Применю команду kubectl create -f kuber-rs.yaml, а после выведу на экран информацию о созданных ресурсах командами kubectl get rs и kubectl get pods --show-labels

Чтобы получить доступ к работающим приложениям извне кластера, я создам ресурс типа Service LoadBalancer с помощью следующего манифеста. Здесь важно отметить, что служба будет предоставлять доступ к подам на основе селектора, указанного в разделе spec

apiVersion: v1kind: Servicemetadata:  name: mylbspec:  type: LoadBalancer  selector:    api: loremapi  ports:  - port: 8080    targetPort: 80

Информация о созданном сервисе kubectl get svc

Теперь через браузер или Postman можно посылать запросы на адрес службы http://localhost:8080/api/lorem. А служба будет перенаправлять запрос к одному из относящихся к ней подов

Здесь я бы хотел рассказать о сохранение сессий. При первом запросе к службе выбирается случайный под с которым устанавливается постоянное подключение. Соответственно все последующие запросы, принадлежащие этому подключению, будут отправляться в этот же под. И так до тех пор, пока подключение не будет закрыто. А для того чтобы убедиться, что каждый запрос все таки отправляется на случайно выбранный под, я установил в файле Program.cs значение для свойства KeepAliveTimeout равное 1 секунде, вместо 2 минут, принятых по умолчанию. В итоге, если отправлять запросы реже одной секунды, то каждый раз подключение будет принудительно закрываться, тем самым для обработки каждого нового запроса будет происходить новый выбор пода

Теперь если произойдет сбой главного процесса в каком-либо из контейнеров, например, из-за ошибки в приложении, которая время от времени приводит к падению, то Kubernetes перезапустит его. Если Pod пропадет, например, из-за возникшей неисправности узла кластера, то Kubernetes создаст новый Pod

Так, если я удалю вручную один из подов kubectl delete pod myrs-jqjsp, то почти сразу будет создан автоматически новый, тем самым будет восстановлен баланс между желаемым и фактическим количеством экземпляров

Удалю все ресурсы из кластера kubectl delete all --all

Таким образом, даже не делая ничего в самом приложение, Kuberntes значительно повышает выживаемость

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

На сколько мне известно, есть 3 таких способа

  • Проверка выполнения произвольной команды с помощью инструкции exec. Если команда по завершение возвращает 0, то все в порядке

  • Проверка открытия TCP-порта. Если подключение установлено, то все в порядке

  • Проверка отправкой GET-запроса по указанному маршруту. Если ответ получен и код ответа не указывает на ошибку, то, как вы уже догадались, все в порядке

Поскольку в примере используется веб-приложение, я исследую проверку с помощью GET-запроса. Но перед тем как идти дальше я зафиксирую текущий образ на Docker Hub с тегом 1, т.к. совсем скоро я изменю веб-приложение и сделаю 2 версию образа

Для следующей демонстрации я изменю код класса LoremService таким образом, чтобы после пяти запросов к API, приложение становилось неисправным, тем самым провоцируя Kubernetes перезапускать под с этим приложением

using LoremNET;using System;namespace WebApiLiveness.Services{    public class LoremService    {        private int _wordCountMin = 7;        private int _wordCountMax = 12;        private int _numRequestBeforeError = 5;        private int _requestCounter = 0;        public LoremService()        {            IsOk = true;        }        public bool IsOk { get; private set; }        public string GetSentence()        {            if (_requestCounter < _numRequestBeforeError)            {                _requestCounter++;                var sentence = Lorem.Sentence(                    _wordCountMin, _wordCountMax);                return sentence;            }            else            {                IsOk = false;                throw new InvalidOperationException(                    $"{nameof(LoremService)} not available");            }        }    }}

Добавлю новый контроллер HealthController, который на GET-запрос будет возвращать состояние приложения

using Microsoft.AspNetCore.Mvc;using System.Net;using WebApiLiveness.Services;namespace WebApiLiveness.Controllers{    [ApiController]    [Route("api/[controller]")]    public class HealthController    {        private readonly LoremService _loremService;        public HealthController(LoremService loremService)        {            _loremService = loremService;        }        //GET api/health        [HttpGet]        public StatusCodeResult Get()        {            if (_loremService.IsOk)            {                return new OkResult();            }            else            {                return new StatusCodeResult(                    (int)HttpStatusCode.ServiceUnavailable);            }        }    }}

Как было описано ранее, опубликую новую версию и зафиксирую образ на Docker Hub, но уже с тегом 2

Создам новый манифест ReplicaSet с проверкой состояния. В основном, этот манифест отличается от предыдущего тем, что будет создаваться всего 1 экземпляр пода, а также новым разделом livenessProbe, где указан путь по которому будет обращаться Kubernetes для проверки живости приложения

apiVersion: apps/v1kind: ReplicaSetmetadata:  name: myrsspec:  replicas: 1  selector:    matchLabels:      api: loremapi  template:    metadata:      labels:        api: loremapi    spec:      containers:      - name: webapiliveness        image: sasha654/webapiliveness:2        livenessProbe:          httpGet:            path: /api/health            port: 80          initialDelaySeconds: 10          periodSeconds: 3

Манифест службы оставлю без изменений. Как и ранее, создам ресурсы ReplicaSet и Service

После выполню более 5 запросов http://localhost:8080/api/lorem и тогда получу результат с ошибкой

Через некоторое время единственный под будет перезапущен и снова будет готов обрабатывать запросы

Взгляну подробнее на отчет, полученный командой kubectl describe pod myrs-787w2

Этот простой пример проверки жизни показал насколько это мощное и полезное средство для обеспечения восстановления и устойчивости приложений в целом

Я не буду рассматривать подробно, но упомяну еще об одной важной проверке, которую может выполнять Kebernetes - проверка готовности (Readiness). Иногда я не хочу, чтобы только что запущенное приложение немедленно начинало принимать запросы, т.к. в некоторых сценариях для корректной работы необходимо выполнить загрузку больших данных из внешнего источника или выполнять какую-либо другую длительную операцию. На основе периодической проверки готовности определяется, должен ли конкретный под получать клиентские запросы на обработку или нет. Но в отличие от проверки на живость, если под не проходит проверку готовности, Kubernetes не убивает и не перезапускает его.

В завершении упомяну, что ASP.NET предоставляет ПО промежуточного слоя Microsoft.AspNetCore.Diagnostics.HealthChecks, упрощающее создание сценариев проверки. В частности имеются функции, которые позволяют проверить внешние ресурсы, например, СУБД SQL Server или удаленный API

Здесь находится репозиторий с проектом

Подробнее..
Категории: Kubernetes , Net , Liveness

Почему JVM это ОС и больше чем Кубер

05.01.2021 08:15:09 | Автор: admin

Я давно работаю с платформой Java и прекрасно знаю её сильные и слабые стороны. В этой статье я хочу рассказать, как могла бы повернуться история, если бы не бы. Ведь мы могли бы вместо докер-систем использовать ява-машину. А сама ява-машина вполне могла целиком заменить ОС.

Это обзорная статья, я лишь изложу несколько соображений. Полный их разбор занял бы очень много места.

Итак Ява-машина это ОС. Даже круче чем ОС местами. На самом деле это не такое уж заявление из ряда вон. Ведь всем прекрасно известен пример полноценной ОС, значительно основанной (изначально) на Ява Андроид. Кроме того, существуют и ОС в классическом понимании полностью на базе JVM.

Итак, какие признаки ОС мы имеем у JVM? Управление памятью - несомненно. Управление потоками - да, но как правило на базе существующих местных потоков базовой ОС. Тем не менее, потоки являются важной неотъемлемой и очень развитой подсистемой машины, предоставляя гораздо больше сервисных средств, чем базовые потоки ОС.

Ввод-вывод также очень развит, если иметь в виду всю инфраструктуру Ява, со всеми серверами и библиотеками. В этом смысле ввод-вывод базовой ОС - примерно как старый Биос для последней, осуществляет низкоуровневые операции.

У Ява есть философия. Если в Юникс - всё файл, то в Ява всё (почти) есть объект.

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

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

Во-первых, JVM управляемая (managed) среда. Это не только означает безопасность исполнения кода. Это также модель разграничения, аналогичная выделению ядра в большинстве ОС в отдельный контекст привилегированного исполнения. Т.н. нативный контекст исполнения, в котором работает сама машина - прямой аналог реального (или подобного) режима исполнения процессором ядра ОС. Сама машина имеет полный контроль над всеми процессами внутри неё. Байткоду достается уже сильно ограниченная, защищённая среда. Степень свободы загружаемого байткода определяется Ява-машиной и её рантайм-библиотекой. Более того, сам механизм загрузки байткода (классов в первую очередь) иерархичен и подразумевает разделение прав и ответственности ветвление прав. Это ветвление достигается за счёт применения отдельных загрузчиков классов. При этом создаётся иерархия областей видимости, код, загруженный в одном контексте не имеет доступа к другому независимому контексту. При этом нельзя получить указатель на произвольную область памяти, нет доступа к произвольным полям объектов, даже через механизм рефлексии, даже к целым отдельным объектам. Этот механизм встроен в язык (ключевые слова private, protected и т.п.) и в платформу уже названные загрузчики и конечно менеджеры безопасности, о которых тоже не забудем. Такие механизмы обеспечивают разделение контекстов выполнения аналогично процессам классических ОС. Я бы даже сказал более строгое и надёжное разделение.

Загрузчики классов совместно с менеджерами безопасности (SecurityManager) обеспечивают полный контроль над тем, что может попасть внутрь среды исполнения Ява, а что не может. Механизм этот необычайно гибкий. При этом, в отличие от нативного кода, загружаемый байткод проходит полную проверку на валидность (он не может затем вызвать непредсказуемый сбой) и безопасность - так как возможные варианты поведения ограничены теми же загрузчиком+менеджером безопасности. Вы слышали когда-нибудь о вирусах на Яве?

Для больших систем вышеописанный механизм хорошо согласуется с модульностью и плагинным подходом. При этом, как я уже сказал, эта плагинная система значительно защищённее аналогов, т.к. плагины могут вести себя как отдельные приложения. Яркий пример - OSGi.

Здесь стоит отметить, что все вышеуказанные черты существуют в рамках всего одного процесса. Это позволяет не использовать сложные, рискованные и дорогие механизмы межпроцессного взаимодействия. С другой стороны есть один из главных недостатков ява-машины, до последнего времени неслабо портивший бочку мёда большая общая куча со сборкой мусора. Но новое поколение сборщиков почти полностью устранило этот недостаток, позволяя запускать Ява машины с кучей в десятки гигабайт.

Круче чем докер

Почему Ява-машина круче чем докер? Потому что, как я уже сказал, она позволяет создавать множество независимых изолированных контекстов читай пространств имён на базе общего ядра Ява-машины и рантайм-библиотеки. И эти пространства могут настраиваться более гибко, обеспечивая различные уровни изоляции (доступа). Они могут дополнительно компоноваться. Отличным примером этого являются мощные сервера приложений. Они предлагают всё то, что обещает нам докер и его оркестраторы отказоустойчивость, балансировка нагрузки, отличная модульность (суть микросервисности), сервисы и вебсервисы и даже самые микро и нано-модули лямбды в виде супер легковесных ejb, решение проблем совместимости версий библиотек, удалённый вызов процедур в качестве альтернативы protoBuf & gRPC RMI и его развития Corba + rmi-iiop. И это всё в виде стандартов и множества реализаций

Единственное, чего не хватает - красивых картинок и графиков (хотя тут от реализации зависит) и развертывания инфраструктуры из нарисованной диаграммки. Но последнее и в коробку с Кубером никто бесплатно не положит.

И для иллюстрации посмотрим на стандартную модульность сервера приложений. Есть иерархия загрузки: система -> сервер -> приложение -> модуль приложения.

Что ж, на этом пока всё. Порадуемся выходу очередной версии Jakarta EE 9 и пожелаем им успехов.

Подробнее..

Kubernetes или с чего начать чтобы понять что это и зачем нужно

12.01.2021 18:23:11 | Автор: admin

Данная статья рассчитана на новичков. Если вы опытный ниндзя, просто вспомните о том, как когда-то подобная информация могла быть полезной и для вас ;-)


Предположим вы уже перешли на ты с технологией контейнеризации, разобрались с технологией непрерывной поставки ПО и пришло понимание всех минусов жизни с обычными контейнерами. Что же с этим делать и как перекрыть такие минусы? Тут на помощь нам приходит контейнерная оркестрация и Kubernetes.

Давайте вспомним как работают контейнеры на примере Docker. Основные понятия это namespaces, cgroups, UnionFS, RunC.

Namespaces это про изолирование окружения и про то что каждый контейнер работает со своими namespaceами и namespace закрывается, если PID 1 умер.

  • pid : Изоляция процессов (PID: Process ID)

  • net : Изоляция сетей (NET: Networking)

  • ipc : Изоляция IPC (IPC: InterProcess Communication)

  • mnt : Изоляция файловой системы (MNT: Mount)

  • uts : Изоляция UTS (UTS: Unix Timesharing System)

  • user: Изоляция пользователей

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

Union File Systems дает разделение по слоям и возможность их переиспользования.

А что же такое слои?

Управление образами, например в Docker, происходит с помощью внешнего драйвера хранилища. Есть несколько поддерживаемых драйверов - AUFS, BTRFS и наложения.

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

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


Каждый слой очень легкий. Преимуществом слоев является совместное использование слоев.

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

После того как разобрались с базовыми понятиями контейнеризации стоит вспомнить что же такое оркестрация.

Оркестрация это:

  • управление кластером хостов;

  • планирование и распределение задач;

  • автоматизация.

А теперь от оркестрации плавно перейдем к тому по какой же концепции DevOps будет происходить модель обслуживания.


Одна из основных концепций DevOps - это <Cattle, NOT pets>.

Модель обслуживания Домашние животные(pets) описывает тщательно ухоженные сервера, за которыми с любовью ухаживают и им дают имена, как если бы они были верными домашними животными. Когда с ними что то случается, то вы тщательно восстанавливаете их здоровье, помогаете им вырасти и время от времени делаете блестящими и новыми.

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

Потребность в автоматизации и координации настройки и развертывания привела к появлению таких инструментов, как Salt Stack, Ansible и Terraform. Эти инструменты дали разработчикам и DevOps инженерам возможность программно развертывать инфраструктуру, необходимую для поддержки ваших приложений. Этот процесс теперь известен как Инфраструктура как код.

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

Управление конфигурацией vs оркестрация контейнеров

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

Ansible и Terraform также являются обязательными навыками.

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

Все это и более детальное рассмотрение архитектуры и основных концепций Kubernetes, на равне с такими интересными темами как кластеризация, highload web, администрирование СУБД, виртуализация и контейнеризация, оркестрация вы сможете изучить на курсе Administrator Linux. Advanced.

Также вы сможете получить ответы на такие вопросы как организовано сетевое взаимодействие в Kubernetes, как опубликовать приложение и как работает DNS в Kubernetes.

Ну и как же без такого важного вопроса как хранение данных, мониторинг и Kubernetes secrets Hashicorp Vault.

А прямо сейчас мы приглашаем всех желающих на бесплатный демо-урок по теме "Кластерная файловая система Lustre". В рамках урока рассмотрим архитектуру и компоненты файловой системы Lustre. Разберем области применения файловой системы и ее особенности. Ответим на вопросы как используется file striping и что такое сетевой транспортный уровень LNET. На практической части установим и сконфигурируем файловую систему вручную. Посмотрим пример работы графической пользовательского интерфейса Integrated Manager for Lustre (IML)

Подробнее..

Kubernetes или с чего начать, чтобы понять что это и зачем он нужен

13.01.2021 14:06:06 | Автор: admin

Данная статья рассчитана на новичков. Если вы опытный ниндзя, просто вспомните о том, как когда-то подобная информация могла быть полезной и для вас ;-)





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

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

Давайте вспомним что такое контейнеры.

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

Все было бы отлично, но есть одно но - container runtime API (API среды запуска контейнера) хорошо подходит для управления отдельными контейнерами, но совершенно не подходит для управления приложениями на сотне контейнеров и на большом количестве хостов.

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

Вот для такого и нужен Kubernetes.

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

Kubernetes по сути является не просто системой оркестрации. Технически оркестрация это про выполнение определенного рабочего процесса: сначала сделай A, затем B, затем C.

Kubernetes же устраняет прямую необходимость в этом. В нем есть процессы управления, что по факту независимы и компонуемы. Главная задача процессов управления перевести текущее состояние к нужному состоянию. Теперь нам неважно какой будет маршрут от А до С, что исключает централизованный контроль.
Благодаря этому система теперь более проста в использовании, мощная, надежная, а также устойчивая и расширяемая.

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

Сделать это только с помощью контейнеров не получится. А вот в Kubernetes это можно достичь с помощью Pods (подов).

Pod (под) - это группа из одного или более контейнера с общим хранилищем/сетевыми ресурсами и спецификацией как запускать контейнеры. Так же это отдельный инстанс приложения. Размещая контейнеры таким образом, Kubernetes устраняет соблазн втиснуть слишком много функций в один образ контейнера.

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

Kubernetes, согласно официальной документации, так же сможет предоставить вам:

  • Используя имя DNS или собственный IP-адрес мониторинг сервисов и распределение нагрузки Kubernetes может обнаружить контейнер. При высоком трафике в нем Kubernetes сбалансирует нагрузку и распределить сетевой трафик так, что развертывание будет стабильным.

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

  • Автоматическое развертывание и откаты.

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

  • Автоматическое распределение нагрузки.

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

  • Самоконтроль.

    Если в работе контейнеров что-то пошло не так, то Kubernetes сам перезапускает, заменяет и завершает работу контейнеров, которые не проходят проверку работоспособности.

  • Управление конфиденциальной информацией и конфигурацией.
    Пароли, OAuth-токены и ключи SSH могут храниться и управляться Kubernetes без изменений образов контейнеров и не раскрывая конфиденциальную информацию в конфигурации стека.

Как видим на рисунке, это наглядная демонстрация того что есть внутри Kubernetes на примере одной мастер ноды (Master node) и одной воркер ноды (Worker node).

На Master node находится Kubernetes Control Plane (kube-scheduler, kube-controller-manager, kube-apiserver, etcd), с помощью которой происходит управление всем кластером Kubernetes.

На Worker node находятся container runtime (среда запуска контейнера), kubelet и kube-proxy.

Сontainer runtime это то на чем будет запущен ваш Под (например Docker, Container D, Rocket и т.д.).

Kubelet это основной агент узла, который работает на каждой ноде. Гарантирует, что контейнеры в Pod(поде)работают и исправны. Не управляет контейнерами, которые не были созданы Kubernetes.

Kube-proxy это демон на каждой ноде, управляет правилами iptable на хосте для достижения балансировки нагрузки службы (одна из реализаций) и следит за изменениями Service и Endpoint.

Более детальное рассмотрение архитектуры, основных концепций Kubernetes в теории и главное на практике, наравне с такими интересными темами как кластеризация, highload web, администрирование СУБД, виртуализация и контейнеризация, оркестрация вы сможете изучить на курсе Administrator Linux. Advanced.

Также вы сможете получить ответы на такие вопросы как организовано сетевое взаимодействие в Kubernetes, как опубликовать приложение и как работает DNS в Kubernetes.

Ну и как же без такого важного вопроса как хранение данных, мониторинг и Kubernetes secrets Hashicorp Vault.

А прямо сейчас мы приглашаем всех желающих на бесплатный демо-урок по теме "Кластерная файловая система Lustre". В рамках урока рассмотрим архитектуру и компоненты файловой системы Lustre. Разберем области применения файловой системы и ее особенности. Ответим на вопросы как используется file striping и что такое сетевой транспортный уровень LNET. На практической части установим и сконфигурируем файловую систему вручную. Посмотрим пример работы графической пользовательского интерфейса Integrated Manager for Lustre (IML)

Подробнее..

Изучаем Bash путем написания интерактивой игры, создаем культуру DevOps, а также шпаргалка по MariaDB и MySQL

14.01.2021 16:09:15 | Автор: admin

Начинаем 2021 год с нового дайджеста полезных материалов. Собрали много инсайтов, записей важных вебинаров, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Начни новое:

  • 5 тенденций гибридного облака, на которые стоит обратить внимание в 2021 году

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

    Вкратце: главный архитектор Red Hat Эмили Бренд (Emily Brand) и другие эксперты делятся советами с ИТ-руководителям.

  • Удаленная работа: 3 способа взбодрить свою команду в 2021 году

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

    Вкратце: главный технический специалист Red Hat по работе с публичным сектором Дэвил Эгтс (David Egts) рассказывает о виртуальных комнатах отдыха и других подобных вещах.

Почитать на досуге:

Скачать:

  • Шпаргалка по MariaDB и MySQL

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

Еще полезное:

  • Запускаем Kubernetes на Raspberry Pi

    Каждую главу этой электронной книги можно читать как самостоятельную единицу или как часть общего руководства по запуску Kubernetes на Raspberry Pi.

  • Шпаргалка по Kubectl

    9 критически важных команд kubectl для устранения неполадок и управления при администрировании кластера Kubernetes.

  • Шпаргалка по Emacs

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

Подробнее..

Изучаем Bash путем написания интерактивной игры, создаем культуру DevOps, а также шпаргалка по MariaDB и MySQL

14.01.2021 18:11:53 | Автор: admin

Начинаем 2021 год с нового дайджеста полезных материалов. Собрали много инсайтов, записей важных вебинаров, книжек и шпаргалок. Оставайтесь с нами станьте частью DevNation!

Начни новое:

  • 5 тенденций гибридного облака, на которые стоит обратить внимание в 2021 году

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

    Вкратце: главный архитектор Red Hat Эмили Бренд (Emily Brand) и другие эксперты делятся советами с ИТ-руководителям.

  • Удаленная работа: 3 способа взбодрить свою команду в 2021 году

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

    Вкратце: главный технический специалист Red Hat по работе с публичным сектором Дэвил Эгтс (David Egts) рассказывает о виртуальных комнатах отдыха и других подобных вещах.

Почитать на досуге:

Скачать:

  • Шпаргалка по MariaDB и MySQL

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

Еще полезное:

  • Запускаем Kubernetes на Raspberry Pi

    Каждую главу этой электронной книги можно читать как самостоятельную единицу или как часть общего руководства по запуску Kubernetes на Raspberry Pi.

  • Шпаргалка по Kubectl

    9 критически важных команд kubectl для устранения неполадок и управления при администрировании кластера Kubernetes.

  • Шпаргалка по Emacs

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

Подробнее..

Фирма 1С приглашает вас принять участие в нашей первой конференции для системных разработчиков

15.01.2021 12:16:15 | Автор: admin
Всем добрый день!

Фирма 1С приглашает вас принять участие в нашей первой конференции для системных
разработчиков, которая пройдет 23 января в онлайн-формате.

Наверное, вы сейчас думаете да 1С это ж бухгалтерия, какая системная разработка?

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

Например, знаете ли Вы, что среди технологий 1С есть высоконагруженный кластер, с
продвинутой балансировкой нагрузки и обеспечением отказоустойчивости?

Или зачем нам вдруг понадобилось использовать NoSQL DB при разработке собственной IDE? (Да-да, у нас есть собственная IDE, да не одна, а целых три!)

Чем же мы на самом деле занимаемся
Если же говорить, чем же мы на самом деле занимаемся наш ключевой продукт это фреймворк для создания бизнес-приложений 1С: Предприятие. Написан он на C++, Java, и JS. Умеет работать на разных платформах (Windows, Linux, MacOS, Android, iOS), в вебе, поддерживает разные СУБД и многое другое. Да и не просто работать, а инкапсулировать особенности каждой СУБД и выглядеть одинаково на разных платформах (интерфейсы генерируются автоматически про это, кстати, будет отдельный доклад).

Платформа 1С: Предприятие, на самом деле, двойственна она объединяет в себе как инструменты разработки, так и среду исполнения в различных вариантах (локальном, клиент-серверном, кластерном, мобильном, облачном, распределенном). Да, кстати, про облака тоже будет без них сейчас никуда.

Почему мы вдруг решили, что нам есть, что рассказать миру? Потому что более 5 млн.
пользователей работают в приложениях, написанных на платформе 1С: Предприятие, ежедневно, и не просто разок запустить а целый рабочий день. И нам пришлось решить много сложных системных задач, чтобы добиться этого!

Еще немного спойлеров:

  • Расскажем, зачем нам понадобился GraalVM
  • Как заставить Xtext эффективно работать с миллионами строк программного кода?

Так что приходите, очень ждем!
Программа конференции и регистрация по ссылке.
Ну и на сладкое какая конференция без машинного обучения? Расскажем о нашем собственном механизме распознавания документов (и покажем детали)!
Подробнее..

Перевод Как сократить время сборки образов Docker в GitLab CI

18.01.2021 02:05:59 | Автор: admin

Делаем контейнерные CI среды по-настоящему практичными, ускорив сборку образов Docker.

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

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

Локальная упаковка приложения

В качестве примера мы возьмем достаточно простое приложение Python Flask:

from flask import Flaskapp = Flask(__name__)@app.route('/')def hello_world():    return 'Hello, World!'

Написание Dockerfile

Давайте напишем соответствующий Dockerfile:

FROM python:3.7-alpine as builder# установка зависимостей, необходимых для сборки пакетов pythonRUN apk update && apk add --no-cache make gcc && pip install --upgrade pip# настройка venv и загрузка или сборка зависимостейENV VENV="/venv"ENV PATH="${VENV}/bin:${PATH}"COPY requirements.txt .RUN python -m venv ${VENV} \    && pip install --no-cache-dir -r requirements.txtFROM python:3.7-alpine# настройки venv с зависимостями с этапа компоновкиENV VENV="/venv"ENV PATH="${VENV}/bin:$PATH"COPY --from=builder ${VENV} ${VENV}# копирование файлов приложенияWORKDIR /appCOPY app .# запуск приложенияEXPOSE 5000ENV FLASK_APP="hello.py"CMD [ "flask", "run", "--host=0.0.0.0" ]

Здесь вы можете наблюдать классический многоступенчатый процесс сборки:

  • Мы начинаем с легкого базового образа, в который мы устанавливаем инструменты сборки и загружаем или компилируем зависимости в виртуальную среду Python.

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

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

Запуск и тестирование образа.

Убедитесь, что все работает должным образом:

docker build -t hello .docker run -d --rm -p 5000:5000 hellocurl localhost:5000Hello, World!

Если вы запустите команду docker build во второй раз:

docker build -t hello ....Step 2/15 : RUN apk update && apk add --no-cache make gcc && pip install --upgrade pip ---> Using cache ---> 24d044c28dce...

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

Отправка образа

Давайте опубликуем наш образ во внешнем реестре и посмотрим, что произойдет:

docker tag hello my-registry/hello:1.0docker push my-registry/hello:1.0The push refers to repository [my-registry/hello]8388d558f57d: Pushed 77a59788172c: Pushed 673c6888b7ef: Pushed fdb8581dab88: Pushed6360407af3e7: Pushed68aa0de28940: Pushedf04cc38c0ac2: Pushedace0eda3e3be: Pushedlatest: digest: sha256:d815c1694083ffa8cc379f5a52ea69e435290c9d1ae629969e82d705b7f5ea95 size: 1994

Обратите внимание, как каждый из промежуточных слоев идентифицируется хэшем. Мы можем насчитать 8 слоев, потому что у нас есть ровно 8 docker команд в Dockerfile поверх нашей последней инструкции FROM.

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

С локальной сборкой все достаточно просто, давайте теперь посмотрим, как это будет работать в CI среде.

Сборка образа Docker в контексте CI конвейера

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

Тестовая CI среда

Мы реализуем CI среду, используя:

Последний пункт важен, потому что наши CI задачи будут выполняться в контейнерной среде. Учитывая это, каждая задача создается в виде пода Kubernetes. Каждое современное CI решение использует контейнерные задачи, и при создании Docker контейнеров все они сталкиваются с одной и той же проблемой: вам нужно заставить Docker команды работать внутри Docker контейнера.

Чтобы все прошло гладко, у вас есть два пути:

  • Забиндить /var/run/docker.sock, который слушает демон Docker, сделав демон хоста доступным для нашего контейнера задач.

  • Использовать дополнительный контейнер, запускающий Docker in Docker (также известный как dind) вместе с вашей задачей. Dind - это особый вариант Docker, работающий с привилегиями и настроенный для работы внутри самого Docker ?

Для нашего примера мы будем использовать второй вариант.

Реализация GitLab конвейера

В GitLab конвейере обычно вы создаете служебные контейнеры, такие как DinD, с помощью ключевого слова service.

В приведенном ниже фрагменте конвейера и задача docker-build, и служебный dind контейнер будут выполняться в одном и том же поде Kubernetes. Когда в сценарии задачи используется docker, он отправляет команды вспомогательному dind контейнеру благодаря переменной среды DOCKER_HOST.

stages:  - build  - test  - deployvariables:  # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""  # адрес localhost используется как контейнером задачи, так и dind контейнером (поскольку они используют один и тот же под)  # Таким образом, при выполнении команд Docker эта конфигурация делает службу dind нашим демоном Docker   DOCKER_HOST: "tcp://localhost:2375"services:  - docker:stable-dinddocker-build:  image: docker:stable  stage: build  script:      - docker build -t hello .      - docker tag my-registry/hello:${CI_COMMIT_SHORT_SHA}      - docker push my-registry/hello:${CI_COMMIT_SHORT_SHA}

Запуск конвейера

Этот конвейер должен работать нормально. Запустив его один раз и проверив вывод задачи, мы получим:

docker build -t hello .Step 1/15 : FROM python:3.7-alpine as builder...Step 2/15 : RUN apk update && apk add --no-cache make gcc && pip install --upgrade pip---> Running in ca50f59a21f8fetch http://dl-cdn.alpinelinux.org/alpine/v3.12/main/x86_64/APKINDEX.tar.gz...

Поскольку мы впервые создаем наш контейнер, каждый слой создается путем выполнения команд. Общее время выполнения задачи составляет около 1 минуты.

Если вы запустите конвейер во второй раз, ничего не меняя, вы должны увидеть то же самое: каждый слой перестраивается! Когда мы запускали наши команды сборки локально, кэшированные слои использовались повторно. А здесь - нет. Для такого простого образа это на самом деле не имеет значения, но в реальной жизни, где для создания некоторых образов могут потребоваться десятки минут, это может стать настоящей проблемой.

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

Как же нам получить выгоду от кэширования и по-прежнему использовать Dind-контейнер?

Использование кэша Docker вместе с Docker in Docker

Первое решение: Pull/Push танцы

Первое решение довольно простое: мы будем использовать наш удаленный реестр (тот, в который мы пушим) в качестве удаленного кэша для наших слоев.

Если быть точнее:

  • Мы начинаем с извлечения (pull) самого актуального образа (т. е. последнего) из удаленного реестра, который будет использоваться в качестве кэша для последующей docker команды сборки.

  • Затем мы создаем образ, используя извлеченный образ в качестве кэша (аргумент --cache-from), если он доступен. Мы помечаем эту новую сборку в качестве последней и коммитим SHA.

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

stages:  - build  - test  - deploy    variables:   # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""  DOCKER_HOST: "tcp://localhost:2375"services:  - docker:stable-dinddocker-build:  image: docker:stable  stage: build  script:    - docker pull my-registry/hello:latest || true    - docker build --cache-from my-registry/hello:latest -t hello:latest .    - docker tag hello:latest my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker tag hello:latest my-registry/hello:latest    - docker push my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker push my-registry/hello:latest

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

Все слои из базового образа компоновщика пересобираются. Только первые 2 слоя (8 и 9) заключительного этапа используют кэш, но последующие слои перестраиваются.

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

Затем, когда наш финальный образ собран (шаги с 8 по 15), первые два слоя присутствуют в образе, который мы извлекли и использовали в качестве кэша. Но на шаге 10 мы получаем зависимости образа компоновщика, которые изменились, поэтому все последующие шаги также строятся заново.

Подводя итог, можно сказать, что использование кэша в значительной степени ограничено: только 2 шага из 15 используют кэш! Чтобы исправить это, нам нужно отправлять образ промежуточного компоновщика в удаленный реестр, чтобы сохранить его слои:

stages:  - build  - test  - deploy    variables:    # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""  DOCKER_HOST: "tcp://localhost:2375"services:  - docker:stable-dinddocker-build:  image: docker:stable  stage: build  script:    - docker pull my-registry/hello-builder:latest || true    - docker pull my-registry/hello:latest || true    - docker build --cache-from my-registry/hello-builder:latest --target builder -t hello-builder:latest .    - docker build --cache-from my-registry/hello:latest --cache-from my-registry/hello-builder:latest -t hello:latest .    - docker tag hello-builder:latest my-registry/hello-builder:latest        - docker tag hello:latest my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker tag hello:latest my-registry/hello:latest    - docker push my-registry/hello-builder:latest    - docker push my-registry/hello:${CI_COMMIT_SHORT_SHA}    - docker push my-registry/hello:latest

Мы создаем промежуточный этап нашего сборщика в качестве образ докера, используя опцию target. После этого мы пушим его в удаленный реестр, в конечном итоге извлекая его в качестве кэша для создания нашего финального образа. При запуске конвейера наше время сократилось до 15 секунд!

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

Второе решение: внешняя служба dind

Нам нужно запустить службу dind для выполнения нашей сборки docker. В нашем предыдущем решении dind был встроен в каждую задачу и разделял ее жизненный цикл, что делало невозможным создание надлежащего кэша.

Почему бы не сделать Dind гражданином первого класса, создав службу Dind в нашем кластере Kubernetes? Она будет работать с подключенным PersistentVolume для обработки кэшированных данных, и каждая задача может отправлять свои docker команды в эту общую службу.

Создать такую службу в Kubernetes достаточно просто:

apiVersion: v1kind: PersistentVolumeClaimmetadata:  labels:    app: docker-dind  name: dindspec:  accessModes:    - ReadWriteOnce  resources:    requests:      storage: 500Gi---apiVersion: apps/v1kind: Deploymentmetadata:  labels:    app: docker-dind  name: dindspec:  replicas: 1  selector:    matchLabels:      app: docker-dind  template:    metadata:      labels:        app: docker-dind    spec:      containers:        - image: docker:19.03-dind          name: docker-dind          env:            - name: DOCKER_HOST              value: tcp://0.0.0.0:2375            - name: DOCKER_TLS_CERTDIR              value: ""          volumeMounts:            - name: dind-data              mountPath: /var/lib/docker/          ports:            - name: daemon-port              containerPort: 2375              protocol: TCP          securityContext:            privileged: true # Требуется для работы dind контейнера.      volumes:        - name: dind-data          persistentVolumeClaim:            claimName: dind            ---apiVersion: v1kind: Servicemetadata:  labels:    app: docker-dind  name: dindspec:  ports:    - port: 2375      protocol: TCP      targetPort: 2375  selector:    app: docker-dind

Затем мы немного изменим наш исходный GitLab конвейер, чтобы он указывал на эту новую внешнюю службу, и удалим встроенные dind службы:

stages:  - build  - test  - deploy    variables:   # отключаем проверку Docker TLS  DOCKER_TLS_CERTDIR: ""   # здесь имя хоста dind разрешается как dind служба Kubernetes с помощью kube dns  DOCKER_HOST: "tcp://dind:2375"docker-build:  image: docker:stable  stage: build  script:    - docker build -t hello .    - docker tag hello:latest my-registry/hello:{CI_COMMIT_SHORT_SHA}    - docker push my-registry/hello:{CI_COMMIT_SHORT_SHA}

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

И последний вариант: использование Kaniko

Последним вариантом может быть использование Kaniko. С его помощью вы можете создавать образы Docker без использования демона Docker, делая все, что мы сейчас делали, без особых проблем.

Однако обратите внимание, что при этом вы не можете использовать расширенные BuildKit опции, такие как, например, внедрение секретов при создании образа. По этой причине я сконцентрировался на другом решении.

Заключение

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


А прямо сейчас приглашаем ва ознакомиться с программой супер-интенсива"CI/CD или Непрерывная поставка с Docker и Kubernetes", а таже записаться надень открытых дверей.


Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru