Kubernetes *

Лучшие практики 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.

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

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


Это не DNS
Не может быть что это DNS
Это был DNS

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



TL;DR: один и тот же набор рабочих нагрузок можно запустить на нескольких крупных кластерах (на каждый кластер будет приходиться большое число workload'ов) или на множестве мелких (с малым числом нагрузок в каждом кластере).

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

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

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

Программы под катом.

В ежегодном облачном прогнозе Dave Bartoletti, вице-президент и главный аналитик Forrester, рассказал, что облачный рынок — SaaS, PaaS и IaaS — вырастет до 299,4 млрд долларов в 2020 году. Но что это значит на самом деле и что изменится для бизнеса и IT-специалистов? Команда Mail.ru Cloud Solutions собрала прогнозы экспертов, чтобы разобраться в ситуации.  

Примечание: это не полноценная статья-руководство, а скорее напоминание/подсказка для тех, кто уже пользуется ConfigMap в Kubernetes или только готовит своё приложение для работы в нём.

Предыстория: от rsync к… Kubernetes

Что было раньше? В эпоху «классического администрирования» в простейшем варианте файл конфига размещали прямо рядом с приложениями (или в репозитории, если угодно). Всё просто: делаем элементарную доставку (CD) для нашего кода вместе с конфигом. Даже реализацию на условном rsync можно назвать зачатками CD.

Кажется, тема «зачем нужен Kubernetes», уже раздражает. Хочется сказать: «все кому надо — давно уже поняли», однако я разделил бы технических (и околотехнических) работников на тех, кто «понял и знает как использовать», и тех, кто «понял, но хочет знать, как сделать знания актуальными».

Возможно, вы менеджер, который последние 10 лет работал на одном и том же стеке; возможно, вы разработчик, который поддерживает старое решение или пишет на привычном языке в привычной среде. Возможно, вы просто перешли из технического в организационный менеджмент и вдруг выяснили, что все, что вы знали, больше не актуально, и хочется понять — есть ли какой-то относительно простой сценарий, как это можно догнать. Я постараюсь дать советы, основываясь на собственном опыте, — от человека, который осознал, что, находясь на организационном управлении, скоро будет выражаться словами «Kubernetes — это эффективная технология, мы должны стремиться к ее применению», не вполне понимая, что лежит за этими словами и за всей технической культурой, развившейся в последнее время.

Почему я считаю важным уметь менять парадигму технологического мышления?

Друзья! Компания IBM продолжает вести вебинары. В этом посте вы сможете ознакомиться с датами и темами предстоящих докладов!

Расписание на эту неделю: