Kubernetes *

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



Это ненаучный обзор решений для хранения данных для Kubernetes. Постановка задачи: требуется возможность создания Persistent Volume на дисках узла, данные которого будут сохранны в случае повреждения или перезапуска узла.

Мотивация для проведения этого сравнения — потребность миграции серверного парка компании со множества выделенных bare metal-серверов в кластер Kubernetes.

Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate
Лучшие практики Kubernetes. Маппинг внешних сервисов

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

Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов
Лучшие практики Kubernetes. Корректное отключение Terminate

Если вы похожи на большинство людей, то, скорее всего используете ресурсы, функционирующие за пределами вашего кластера. Возможно, вы используете API Taleo для отправки текстовых сообщений или анализируете изображения с помощью API Google Cloud Vision.

Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness
Лучшие практики Kubernetes. Настройка запросов и лимитов ресурсов



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

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



Например, возникает потребность подключиться со своей локальной машины к сервису memcached.staging.svc.cluster.local. Мы предоставляем такую возможность с помощью VPN внутри кластера, к которому подключается клиент. Для этого анонсируем подсети pod'ов, сервисов и push'им кластерные DNS клиенту. Таким образом, когда клиент пытается подключиться к сервису memcached.staging.svc.cluster.local, запрос уходит в DNS кластера и в ответ получает адрес данного сервиса из сервисной сети кластера или адрес pod'а.

K8s-кластеры мы настраиваем с помощью kubeadm, где по умолчанию сервисная подсеть — 192.168.0.0/16, а сеть pod'ов — 10.244.0.0/16. Обычно всё хорошо работает, но есть пара моментов:

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

Вступление

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

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

11 часов, начало рабочего дня. В системе мониторинга не хватает части сообщений от одного из приложений.

Привет, Хабр! 25 и 26 мая будет РИТ++. Это большая онлайн-конференция для всех, кто делает интернет. В обычных условиях мы бы встретились на стенде Авито в зале мероприятия, но 2020 перевернул всё с ног на голову. Так что общение переносится в Зум, где 11 наших инженеров из разных команд ответят на вопросы про базы данных, перформанс, мониторинг, микросервисную архитектуру и многое другое.

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

Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен
Лучшие практики Kubernetes. Проверка жизнеспособности Kubernetes с помощью тестов Readiness и Liveness

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

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

Запросы Requests и ограничения Limits — это механизмы, которые Kubernetes использует для управления такими ресурсами, как, например, процессор и память. Requests — это то, в результате чего контейнер гарантированно получает запрашиваемый ресурс. Если контейнер запрашивает ресурс, то Kubernetes запланирует его только на том узле, который способен его предоставить. Ограничения Limits контролируют, что ресурсы, запрашиваемые контейнером, никогда не превысят определенного значения.

В данной HOWTO мы исправим баг в древней версии nginx ingress controller v0.20.0 и научимся работать с зависимостями Go старых версий через dep + vendor.

Лучшие практики Kubernetes. Создание небольших контейнеров
Лучшие практики Kubernetes. Организация Kubernetes с пространством имен



Распределенными системами бывает трудно управлять по причине того, что в них имеется множество подвижных изменяемых элементов, и все они должны нормально работать для обеспечения функциональности системы. Если один из элементов выйдет из строя, то система должна его обнаружить, обойти и исправить, причем все это нужно делать автоматически. В этой серии «Kubernetes Best Practices» мы узнаем, как настраивать тесты Readiness и Liveness для проверки жизнеспособности кластера Kubernetes.

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

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

Лучшие практики Kubernetes. Создание небольших контейнеров

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

Давайте рассмотрим, как пространство имен namespace облегчает управление ресурсами Kubernetes. Итак, что же такое пространство имен? Namespace можно рассматривать как виртуальный кластер внутри вашего кластера Kubernetes. Вы можете иметь несколько изолированных друг от друга пространств имен внутри одного кластера Kubernetes. Они реально могут помочь вам и вашим командам с организацией, безопасностью и даже производительностью системы.



В большинстве дистрибутивов Kubernetes кластер «выходит из коробки» с пространством имен, имеющим название «default». На самом деле существует три пространства имен, с которыми Kubernetes имеет дело: default, kube-system и kube-public. В настоящее время Kube- public используется не так уж часто.

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

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

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

Использование review-окружений в CI/CD может быть весьма полезным, причём как для разработчиков, так и для системных инженеров. Давайте для начала синхронизируем общие представления о них:

1. Review-окружения могут создаваться из отдельных веток в Git-репозитории, определяемых разработчиками (так называемые feature-ветки).
2. Они могут иметь отдельные экземпляры СУБД, обработчиков очередей, кэширующих сервисов и т.п. — в общем, всё для полноценного воспроизведения production-окружения.
3. Они позволяют вести параллельную разработку, значительно ускоряя выпуск новых функций в приложении. При этом каждый день могут потребоваться десятки подобных окружений, из-за чего скорость их создания критична.

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

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

В данной статье я расскажу как настроить source-based и policy-based routing для внешней сети вашего кластера.

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

Во многих компаниях стоит задача быстрого развертывания кластеров Kubernetes. Хорошо, когда создание кластера происходит автоматически. Но ещё лучше, когда пользователь, например, разработчик может создать кластер и потом управлять им «по кнопке», не привлекая для этого devops’ов. В своей облачной лаборатории мы посмотрели, как с созданием кластера Kubernetes справляется платформа управления гибридным облаком Morpheus: автоматизировали развертывание и оценили возможности управления и масштабирования кластера.

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

Мы представляем команду платформы компании Exness. Ранее наши коллеги уже писали статью про Production-ready images for k8s. Сегодня мы хотим поделиться опытом миграции сервисов в Kubernetes.

Привет, меня зовут Дмитрий Краснов. Уже более пяти лет я занимаюсь администрированием кластеров Kubernetes и построением сложных микросервисных архитектур. В начале этого года мы запустили сервис по управлению кластерами Kubernetes на базе Containerum. Пользуясь поводом расскажу, что представляет собой этот самый Kubernetes и чем интеграция с вендором отличается от open source.

Для начала, что такое Kubernetes. Это система для управления контейнерами на большом количестве хостов. С греческого, кстати, переводится как «пилот» или «рулевой». Изначально разработана Google, после чего в качестве технологического вклада передана Cloud Native Computing Foundation, международной некоммерческой организации, которая объединяет ведущих мировых разработчиков, конечных пользователей и поставщиков контейнерных технологий.

Эта статья, которая поможет разобраться в том, как устроена балансировка нагрузки в Kubernetes, что происходит при масштабировании долгоживущих соединений и почему стоит рассматривать балансировку на стороне клиента, если вы используете HTTP/2, gRPC, RSockets, AMQP или другие долгоживущие протоколы. 

Всем привет. В мае OTUS запускает практикум по мониторингу и логированию, как инфраструктуры так и приложений с помощью Zabbix, Prometheus, Grafana и ELK. В связи с этим традиционно делимся полезным материалом по теме.

---

Blackbox экспортер для Prometheus позволяет реализовать мониторинг внешних сервисов через HTTP, HTTPS, DNS, TCP, ICMP. В этой статье я покажу вам, как настроить мониторинг HTTP/HTTPS с помощью Blackbox экспортера. Запускать Blackbox экспортер будем в Kubernetes.

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

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