kubernetes лучшие практики pdf

Лучшие практики Kubernetes. Организация Kubernetes с пространством имен

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

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

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

Не трогать пространство имен kube – хорошая идея, особенно в такой управляемой системе, как Google Kubernetes Engine. Она использует пространство имен «default» как место, в котором создаются ваши сервисы и приложения. В нем нет абсолютно ничего особенного, за исключением того, что Kubernetes «из коробки» настроен на его использование, и вы не можете его удалить. Это отлично подходит для начала работы и систем с небольшой производительностью, но я бы не рекомендовал использовать default namespace в больших prod-системах. В последнем случае одна команда разработчиков может легко переписать чужой код и нарушить работу другой команды, даже не осознавая этого.

После ее выполнения вы увидите три встроенных пространства имен и новое пространство имен под названием «test». Давайте рассмотрим простой YAML-файл, предназначенный для создания pod. Можно заметить, что в нем нет никакого упоминания о пространстве имен.

Если примените kubectl для запуска этого файла, он создаст модуль mypod в текущем активном пространстве имен. Это будет пространство имен по умолчанию, пока вы его не измените. Существует 2 способа сообщить Kubernetes, в каком пространстве имен вы хотите создать свой ресурс. Первый способ — это использование флага пространства имен при создании ресурса.

Второй способ заключается в указании пространства имен в декларации YAML.

Если вы укажете пространство имен в YAML, то ресурс всегда будет создаваться в этом пространстве. Если вы попытаетесь использовать другое пространство имен при использовании флага пространства имен, то команда завершится ошибкой. Теперь, если вы попытаетесь найти свой pod, то не сможете этого сделать.

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

Из коробки ваше активное пространство имен носит название default. Если вы не уточните пространство имен в YAML ресурса, то все команды Kubernetes будут использовать это активное default namespace. К сожалению, попытка управлять активным пространством имен с помощью kubectl может окончиться неудачей. Однако существует очень хороший инструмент под названием Kubens, который намного упрощает этот процесс. Когда вы запускаете команду kubens, то видите все пространства имен с подсвеченным активным пространством имен.

Это означает, что вам не нужен флаг пространства имен, чтобы увидеть pod в пространстве имен test.

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

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

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

Как правило, вам просто нужно имя сервиса, и DNS автоматически определит полный адрес.

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

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

Если же вы хотите подключиться к базе данных сервиса в пространстве имен prod, вы используете database.prod.

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

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

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

Представьте, что вы являетесь частью небольшой команды, которая работает над разработкой 5-10 микросервисов и вы легко можете собрать всех разработчиков в одной комнате. В данной ситуации имеет смысл запускать все prod-сервисы в пространстве имен default. Конечно, для большего простора действий вы можете использовать 2 пространства имен — отдельно для prod и dev. И вероятнее всего, вы тестируете свою разработку на локальном компьютере с помощью чего-то наподобие Minikube.

Предположим, что условия поменялись и теперь у вас имеется быстро растущая команда, которая одновременно работает над более чем 10 микросервисами. Наступает момент, когда необходимо использовать несколько кластеров или пространств имен, отдельно для prod и dev. Можно разбить команду на несколько подгрупп так, чтобы у каждой из них были свои собственные микросервисы и каждая из этих команд могла бы выбрать свое собственное пространство имен для облегчения процесса управления разработкой и выпуском ПО.

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

В крупных компаниях разработчики вообще не знают, кто конкретно над чем работает. Команды общаются с помощью сервисных контрактов или используют технологию Service mesh, которая добавляет над сетью уровень абстракции, типа инструмента конфигурации Istio. Попытка запустить весь стек локально просто невозможна.Я настоятельно рекомендую использовать в Kubernetes такую платформу непрерывной доставки (CD), как Spinnaker. Итак, наступает момент, когда каждой команде определенно нужно собственное пространство имен. Каждая команда даже может выбрать несколько пространств имен для среды dev и среды prod.

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

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

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

Немного рекламы 🙂

Источник

Введение в лучшие практики по безопасности Kubernetes

С быстрым распространением облачных вычислений методы развертывания ПО, такие как контейнеры, стали обычной практикой. По данным CIO.com, в ближайшие несколько лет ожидается, что 70% крупных компаний будут одновременно запускать несколько приложений с использованием контейнерной инфраструктуры, такой как Kubernetes. Но по мере того, как Kubernetes становится все более распространенным, растут и уязвимости, присущие контейнеризации. Согласно статье Forbes за 2019 год, только в начале 2019 года в Kubernetes было выявлено не менее 7000 уязвимостей. Добавьте к этому тот факт, что количество кибератак, связанных с контейнеризацией, с 2018 года увеличилось на целых 240%, и вы поймете ценность безопасности, если ваша компания будет использовать такое решение, как Kubernetes, для контейнерной оркестрации.

Что вызывает нарушения безопасности Kubernetes?

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

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

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

Рекомендации по безопасности Kubernetes

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

Позаботьтесь о своих образах

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

Убедитесь, что ваши секреты остаются в секрете

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

Сохраняйте систему обновленной с помощью сканирования и исправлений безопасности

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

Воспользуйтесь возможностью настройки для определения пользовательских ролей и доступа

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

Сохраняйте Kubernetes простым и безопасным

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

Подведем итог

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

Мы будем очень благодарны

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

Источник

Книга «Kubernetes: Лучшие практики»

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

Важно понимать: это не введение в Kubernetes. Мы исходим из того, что вы уже имеете общее представление об API и инструментарии данной платформы и знаете, как создавать и администрировать кластеры на ее основе. Познакомиться с Kubernetes можно, в частности, прочитав книгу Kubernetes: Up and Running (O’Reilly) (https://oreil.ly/ziNRK).

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

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

Несмотря на столь четкое разделение, некоторые темы будут встречаться вам на протяжении всей книги. Разработке приложений в Kubernetes посвящено сразу несколько глав. Глава 2 описывает рабочий процесс. В главе 5 обсуждаются непрерывная интеграция и тестирование. В главе 15 речь идет о построении на основе Kubernetes высокоуровневых платформ, а в главе 16 рассматривается управление stateless- и stateful-приложениями. Управлению сервисами в Kubernetes также отводится несколько глав. Глава 1 посвящена подготовке простого сервиса, а глава 3 — мониторингу и метрикам. В главе 4 вы научитесь управлять конфигурацией, а в главе 6 — версиями и релизами. В главе 7 описывается процесс глобального развертывания приложения.

Другая обширная тема — работа с кластерами. Сюда относятся управление ресурсами (глава 8), сетевые возможности (глава 9), безопасность pod (глава 10), политики и управляемость (глава 11), управление несколькими кластерами (глава 12), а также контроль доступа и авторизацию (глава 17). Кроме того, есть полностью самостоятельные главы, посвященные машинному обучению (глава 14) и интеграции с внешними сервисами (глава 13).

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

Сервисы в Kubernetes

Благодаря базовым правилам организации сети в Kubernetes и сетевым дополнениям, реализующим эти правила, развертываемые pod могут взаимодействовать только внутри одного кластера. Некоторые дополнения CNI назначают pod IP-адреса в одном адресном пространстве с узлами, поэтому теоретически, зная данный IP, вы можете подключиться к pod напрямую из-за пределов Kubernetes. Но это не самый эффективный способ доступа к сервисам, поскольку pod в Kubernetes по своей природе непостоянны. Представьте, что у вас есть функция или система, которой нужно обратиться к API, доступному в pod. Какое-то время схема может работать нормально, однако рано или поздно возникнет добровольное или принудительное прерывание, в результате которого данный pod исчезнет. Kubernetes, вероятно, создаст ему замену с новыми именем и IP-адресом, поэтому очевидно, что для его поиска нужен некий механизм. Здесь вам пригодится API для работы с сервисами.

Данный API позволяет назначать конечным точкам сервиса постоянные IP-адрес и порт в пределах кластера и автоматически привязывать их к подходящим pod. Этот магический процесс основан на упомянутых выше механизмах iptables и IPVS, работающих на уровне узлов Linux; он привязывает IP-адрес и порт сервиса к реальным IP-адресам конечной точки или pod. Контроллер, который отвечает за это, называется kube-proxy; он выполняется на каждом узле кластера, управляя правилами iptables.

При определении объекта Service необходимо указать тип сервиса. От этого зависит, где будет доступна конечная точка: только внутри кластера или за его пределами. Существует четыре основных типа сервисов, которые мы кратко обсудим в следующих подразделах.

Тип сервисов ClusterIP

Если не указать в спецификации сервиса его тип, то по умолчанию будет использоваться ClusterIP. Сервисам данного типа назначаются IP-адреса из выделенного диапазона CIDR. Эти адреса действительны на протяжении всего жизненного цикла сервисов и привязываются к IP-адресам и портам клиентских pod с помощью поля selector. Но, как вы увидите сами, в некоторых случаях селектор использовать нельзя. В спецификации сервиса также указывается его доменное имя. На этом основан механизм обнаружения внутри кластера, позволяющий рабочим заданиям с легкостью обращаться к другим сервисам в том же кластере, используя DNS-запросы. Например, если у вас есть спецификация сервиса, представленная ниже, и вам нужно сделать HTTP-вызов к этому сервису из другого pod внутри того же кластера, то вы можете использовать адрес web1-svc (при условии, что клиент и сервис находятся в одном пространстве имен):

При отсутствии в определении сервиса селектора для него можно определить API с конечными точками. В результате сервис будет доступен по заданным IP-адресу и порту, и для этого не требуется атрибут selector, который автоматически обновляет конечные точки из pod, соответствующих селектору. Это может пригодиться в ряде ситуаций, если у вас есть база данных, предназначенная для тестирования, но находящаяся за пределами кластера, и вы хотите, чтобы ваш сервис использовал вместо нее другую БД, развернутую в Kubernetes. Такие сервисы иногда называют неуправляемыми (headless), поскольку они, в отличие от обычных, не управляются контроллером kube-proxy, но позволяют работать с конечными точками напрямую, как показано на рис. 9.4

Тип сервисов NodePort

Тип сервисов ExternalName

Сервисы типа ExternalName редко применяются на практике, но могут пригодиться для привязки постоянных внутренних доменных имен кластера к сервисам с внешними доменными именами. Типичный пример — внешняя база данных облачного провайдера с уникальным доменным именем, таким как mymongodb.documents.azure.com.

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

Тип сервисов LoadBalancer

LoadBalancer — специальный тип сервисов, позволяющих автоматизировать взаимодействие с облачными провайдерами и другими программируемыми сервисами облачной инфраструктуры. С их помощью можно развернуть механизм балансировки нагрузки, предоставляемый облаком, в котором размещен кластер Kubernetes. Это означает, что в большинстве случаев сервис LoadBalancer будет работать примерно так же, как публично доступный балансировщик нагрузки от AWS, Azure, GCE, OpenStack и т.д. Однако каждый облачный провайдер предоставляет собственные аннотации для поддержки дополнительных возможностей, таких как сугубо внутреннее распределение нагрузки, установка параметров конфигурации для AWS ELB и т.д. В спецификации сервиса можно вдобавок указать IP-адрес балансировщика и допустимые диапазоны. Пример этого показан в следующем листинге и на рис. 9.6.

Объекты и контроллеры Ingress

Формально спецификация Ingress не считается типом сервиса, но это важный механизм для направления трафика к рабочим заданиям в Kubernetes. API сервисов поддерживает базовое распределение нагрузки на транспортном и сетевом уровнях (Layer 3/4). Но в реальности многие сервисы, которые развертываются в Kubernetes и не хранят свое состояние, нуждаются в управлении трафиком на более высоком, прикладном уровне — в частности, на уровне протокола HTTP.

API Ingress, по сути, представляет собой HTTP-маршрутизатор, позволяющий направлять запросы к отдельным клиентским сервисам с помощью правил на основе доменных имен и путей. Представьте, что сайт с доменным именем www.evillgenius.com имеет два пути, /registration и /labaccess, обслуживающиеся двумя разными сервисами, развернутыми в Kubernetes, reg-svc и labaccess-svc. Вы можете определить правило доступа, согласно которому запросы к www.evillgenius/registration будут передаваться сервису reg-svc и соответствующим pod; точно так же подходящие конечные точки сервиса labaccess-svc могут получать запросы, направленные к www.evillgenius.com/labaccess. API Ingress также поддерживает маршрутизацию на уровне узлов, позволяя указывать разные серверы в одном и том же правиле доступа. Кроме того, вы можете создать объект Secret с информацией о сертификатах для работы с TLS на порте 443. На случай, если путь не указан, обычно предусматривают обработчик по умолчанию, который возвращает нечто более полезное, чем стандартная страница с ошибкой 404.

Деталями конфигурации конкретных TLS-путей и обработчика по умолчанию занимается так называемый контроллер Ingress. Этот контроллер отделен от API Ingress и позволяет системным администраторам развертывать разные реализации, такие как NGINX, Traefik, HAProxy и т.д. В отличие от других контроллеров Kubernetes, он не является частью системы; это сторонний механизм, который работает с динамической конфигурацией через API Ingress. Самая распространенная реализация контроллера Ingress, NGINX, частично поддерживается проектом Kubernetes, но имеет множество аналогов, как открытых, так и коммерческих:

Рекомендации по использованию сервисов и контроллеров Ingress

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

Брендан Бернс — известный инженер Microsoft Azure и соучредитель открытого проекта Kubernetes. Занимается созданием облачных приложений уже больше десяти лет.

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

Дейв Штребель работает архитектором глобальных облачных систем в Microsoft Azure и занимается открытыми облачными технологиями и Kubernetes. Он принимает активное участие в открытом проекте Kubernetes, помогая с релизами новых версий и возглавляя группу SIG-Azure.

Лахлан Эвенсон — руководитель команды контейнерных вычислений в Microsoft Azure. Его практические уроки и выступления на конференциях помогли огромному количеству людей перейти на Kubernetes.

Для Хаброжителей скидка 25% по купону — Kubernetes

По факту оплаты бумажной версии книги на e-mail высылается электронная книга.

Источник