Настройка доступа к нескольким кластерам Kubernetes
4 марта 2022 г.Введение
Kubernetes — это система управления контейнерами с открытым исходным кодом, представленная Google. По мере роста использования контейнеров Kubernetes играет ключевую роль в современном технологическом пространстве.
Согласно отчету, опубликованному Forrester, 86% ИТ-руководителей отдают приоритет контейнеризации. Однако загвоздка в том, что, несмотря на расширяемость Kubernetes, большинству предприятий по-прежнему необходимо понимать, как использовать Kubernetes в полной мере. потенциал. Kubernetes изначально может поддерживать консолидацию рабочей нагрузки только для одного кластера; однако для увеличения производительности в нескольких сценариях необходим многокластерный подход. Настройка доступа к нескольким кластерам Kubernetes делает среду Kubernetes сильно распределенной. Этот подход также обеспечивает более безопасную среду для облачных приложений и облегчает управление задачами для операций между отделами и подразделениями внутри организации.
Если вы распределили рабочие нагрузки по нескольким регионам, может быть полезно иметь доступ к нескольким кластерам Kubernetes. Такой параметр позволяет равномерно распределить рабочую нагрузку между несколькими облаками или гибридными облаками с локальным расположением или в рамках одной или нескольких облачных конфигураций. Настройка доступа к нескольким кластерам Kubernetes — это экономичный метод, который делает приложения более эффективными и функциональными. Однако управление этими несколькими кластерами может оказаться непростой задачей.
Таким образом, несмотря на то, что вашей организации нужен Kubernetes для равномерного распределения рабочей нагрузки между приложениями и лучшей организации ваших серверов в центре обработки данных, возможно, вам необходимо управлять несколькими кластерами и постоянно быть начеку. Это руководство поможет вам понять, как вы можете управлять доступом к кластерам Kubernetes в масштабе и как упростить, оптимизировать и организовать этот процесс с помощью Teleport.
Использование нескольких кластеров Kubernetes может помочь управлять рабочими нагрузками в разных регионах, ограничивая радиус возмущения; они также помогают управлять проблемами соответствия, жесткой мультиарендности, безопасности и специализированных решений.
Зачем вам нужно управлять доступом к нескольким кластерам?
Благодаря многокластерному управлению Kubernetes сотрудники могут отслеживать все, что происходит во всех кластерах, и могут выбрать передовой подход. Многокластерные операции Kubernetes облегчают:
· Создание, обновление и удаление кластеров Kubernetes в нескольких средах (например, в центрах обработки данных, частных, гибридных и общедоступных облаках, а также на периферии)
· Обновление плоскости управления и вычислительных узлов
· Управление жизненным циклом приложений в гибридных средах
· Масштабирование, защита и обновление кластеров, даже независимых от провайдера
· Обслуживание и обновление нескольких узлов
· Поиск, обнаружение и изменение нескольких узлов
· Поиск, нахождение и обновление любого ресурса Kubernetes
· Реализация управления доступом на основе ролей (RBAC) к кластерам (например, хотя администратор базы данных может иметь доступ ко всем кластерам, разработчик может иметь доступ только к кластеру разработки.)
· Различные квоты ресурсов также могут быть определены и распределены между кластерами.
· Также можно создать несколько политик бюджета для пакетов.
· Создание политик сети и управления
· Определение пороков и допусков в кластерах
· Сканирование кластеров на наличие рисков и уязвимостей
Популярные поставщики облачных услуг, такие как AWS, Google Cloud и Microsoft Azure, облегчают работу клиентов, помогая им управлять своим главным узлом. Главный узел отвечает за управление кластером и отвечает за поддержание состояния кластера. Для связи с главными узлами можно использовать клиентский инструмент Kubernetes Kubectl. При использовании сервисов Kubernetes, управляемых поставщиком, поставщики облачных услуг используют управляемые ими сервисы Kubernetes, такие как сервис Amazon Elastic Kubernetes, Google Kubernetes Engine или сервис Azure Kubernetes. Клиентам не нужно беспокоиться о предоставлении или управлении главным узлом. Управляемые версии немного отличаются для разных облачных провайдеров. Большинство поставщиков облачных услуг предлагают специальную поддержку, предварительно настроенные среды и хостинг.
К ведущим службам Kubernetes, управляемым провайдером, относятся Google Kubernetes Engine, Amazon Elastic Kubernetes Service и Azure Kubernetes Service. Некоторые из этих сервисов созрели до такой степени, что предприятия могут даже обрабатывать ключи к своим кластерам. Эти службы упрощают автоматическое развертывание, автоматическое масштабирование, оптимизированные соглашения об уровне обслуживания и управление контейнерными и микросервисными приложениями.
Наличие кластера Kubernetes для каждой среды, такой как собственный кластер разработки, тестирования и производства, позволяет вам запускать все экземпляры приложения в пределах определенного окружающая обстановка. Этот подход изолирует все среды друг от друга и особенно важен для рабочей среды. Таким образом, даже если в вашем кластере разработки произойдет некоторая неправильная конфигурация, рабочие версии вашего приложения все равно будут защищены от любого рода хаоса.
Идея виртуализации кластера Kubernetes аналогична виртуализации физической машины. Идея может быть блаженством для разработчиков, и хотя хост-система может использоваться для реальных вычислений, все остальное может быть зеркально отражено.
Виртуальные кластеры раскручивают кластеры Kubernetes внутри существующих кластеров и синхронизируют определенные основные ресурсы между этими двумя кластерами. Кластер узлов запускает фактические модули виртуального кластера и должен быть полностью функциональным кластером Kubernetes. Сам виртуальный кластер состоит только из основных компонентов Kubernetes, таких как сервер API, диспетчер контроллеров и т. д. Виртуальные кластеры могут быть очень полезны для сокращения затрат и усилий вашей команды DevOps. Вместо создания множества небольших независимых кластеров виртуальные кластеры предлагают следующие преимущества:
· Меньше стандартных шаблонов кластера (есть один модуль k3 в кластере с общим хостом вместо полного автономного кластера Kubernetes).
· Этими кластерами проще управлять и управлять их развертыванием или удалением в соответствии с пользовательскими сценариями терраформирования.
· Сокращается время запуска и демонтажа
· Эти кластеры экономичны и лучше изолированы, чем пространства имен.
Команды DevOps могут использовать виртуальные кластеры для тестирования, экспериментов и облачной разработки.
Наличие множества небольших одноразовых кластеров позволяет сотрудникам настраивать отдельные кластеры Kubernetes для каждой единицы развертывания. Таким образом, Kubernetes можно использовать в качестве специализированной среды выполнения приложений для отдельных экземпляров приложений, предлагающей такие преимущества, как уменьшенный радиус взрыва, изоляция и небольшое количество пользователей, что способствует меньшему количеству экземпляров для поломки или хаоса.
Сети доставки контента (CDN) являются отличными примерами таких типов кластеров, предлагающих меньшую задержку и лучшие возможности прямой трансляции. Для удовлетворения потребностей современных прямых трансляций и потокового видео крайне важна низкая задержка. Именно тогда граничные вычисления и CDN становятся критически важными, поскольку они приближают хранение данных и вычисления к конечным пользователям.
Команды DevOps могут использовать виртуальные кластеры для тестирования, экспериментов и облачной разработки.
Наличие множества небольших одноразовых кластеров позволяет сотрудникам настраивать отдельные кластеры Kubernetes для каждой единицы развертывания. Таким образом, Kubernetes можно использовать в качестве специализированной среды выполнения приложений для отдельных экземпляров приложений, предлагающей такие преимущества, как уменьшенный радиус взрыва, изоляция и небольшое количество пользователей, что способствует меньшему количеству экземпляров для поломки или хаоса.
Сети доставки контента (CDN) являются отличными примерами таких типов кластеров, предлагающих меньшую задержку и лучшие возможности прямой трансляции. Для удовлетворения потребностей современных прямых трансляций и потокового видео крайне важна низкая задержка. Именно тогда граничные вычисления и CDN становятся критически важными, поскольку они приближают хранение данных и вычисления к конечным пользователям.
В отличие от этого, существует множество различных кластеров в форме кластера для каждого приложения и кластера для среды. С кластером для каждого приложения у вас может быть отдельный кластер для экземпляров определенного приложения, и вы можете рассматривать это как обобщение кластера для каждой команды, поскольку обычно команда разрабатывает одно или несколько приложений. Такие кластеры можно настроить для приложения. Затем есть кластеры для каждой среды, где у вас есть отдельный кластер для каждой среды. У вас может быть среда разработки, тестирования и производства, и вы можете запускать все экземпляры приложения определенной среды. Такая среда облегчает изоляцию среды prod, настраиваемый кластер для среды и блокирует доступ к кластеру prod. Отсутствие изоляции между приложениями и нелокализованные требования к приложениям могут быть основными лазейками.
Как вы можете управлять доступом к кластеру в масштабе
Настройка многокластерных развертываний Kubernetes и управление ими может оказаться непростой задачей. При использовании многокластерной архитектуры Kubernetes возникает множество неотъемлемых проблем. Начнем с того, что архитектура сложна, и эта сложность проявляется в виде следующих проблем:
а) Безопасность
Безопасность может быть одним из уязвимых аспектов многокластерной архитектуры Kubernetes. Каждый кластер имеет свой собственный набор ролей и сертификатов безопасности для поддержки, которыми необходимо управлять в центрах обработки данных и кластерах. Наличие какой-то многокластерной системы управления сертификатами будет работать. Кроме того, системным администраторам и персоналу службы безопасности придется уделять больше внимания созданию ролей и пользователей на межкластерной основе. Этот порядок необходим для поддержки безопасной многокластерной реализации Kubernetes.
b) Конфигурация брандмауэра
В многокластерной установке Kubernetes маркетологи получают доступ к нескольким серверам API. В таком сценарии вам просто нужно раскрутить новый кластер. Это гарантирует, что у вас есть доступ к серверу API кластера и другим требуемым кластерам через брандмауэр. Это дополнительная и постоянная работа, и действительно, можно добавить интеллекта к сценариям автоматизации для решения проблем с доступом; однако это увеличивает сложность сценариев.
в) Развертывание
Развертывание архитектуры Kubernetes усложняется в мультикластерах. В многокластерной среде риски могут быть значительными. Одна ошибочная регистрация в системе управления исходным кодом (SCM) разработчиком может вывести кластер из строя или когда маркетологи реализовали репликацию между несколькими кластерами.
Все основные сложности многокластерных развертываний связаны с большей сложностью, в основном с точки зрения внедрения и обслуживания. Однако с этой сложностью также связаны преимущества универсальности и отказоустойчивости для крупномасштабных корпоративных приложений, работающих по всему миру.
Многокластерные архитектуры являются квинтэссенцией эволюции Kubernetes и предлагают способы разработки приложений, которые могут работать в множестве центров обработки данных универсальным, но контролируемым образом. Кроме того, многокластерность обеспечивает дополнительную отказоустойчивость для приложений, работающих на уровне предприятия.
Кроме того, многокластерные развертывания Kubernetes помогают оптимизировать работу пользователей. Для поддержки крупномасштабных приложений с тысячами пользователей мультикластеры являются основными компонентами, которые помогают в разработке и оптимизации работы пользователей. Преимущества многокластерной среды включают соблюдение нормативных требований, управление кластерами, изоляцию приложений, повышенную масштабируемость и доступность, а также распределенные приложения.
Чтобы в полной мере воспользоваться преимуществами Kubernetes, архитекторы должны уделить время изучению деталей многокластерных реализаций Kubernetes. Вы можете исследовать инструменты, методы и услуги, которые упрощают работу с многокластерными архитектурами.
Сегментация рабочих нагрузок в Kubernetes
Сегментация рабочих нагрузок в Kubernetes требует запуска разных модулей или настройки разных пространств имен. Для обеспечения оптимального уровня детализации и преимуществ высокой доступности и производительности, которые он может принести, развертывание с несколькими кластерами является наиболее важным.
Мультикластер не обязательно подразумевает наличие нескольких облаков; все кластеры Kubernetes в многокластерном развертывании могут работать в одном облаке или в одном и том же локальном центре обработки данных, если они развернуты вне облака. Одним из ключевых преимуществ, которые предлагает мультикластер, является распределение рабочих нагрузок по более широкой географической области, и такое развертывание распространено в мультиоблачной архитектуре.
Кроме того, многокластерное развертывание не обязательно должно управляться через единую плоскость управления или интерфейс. Технически маркетологи могут создать два разных кластера и управлять ими с помощью совершенно разных инструментов, прежде чем их можно будет назвать многокластерным предприятием. Развертываниями с несколькими кластерами можно управлять с помощью единой платформы. Развертывание с несколькими кластерами может иметь или не иметь несколько мастеров, поэтому его не следует путать с развертыванием с несколькими мастерами или с несколькими арендаторами.
В чем преимущества мультикластерного развертывания
Как обсуждалось выше, развертывание нескольких кластеров Kubernetes может принести вам огромную пользу; однако четыре основных преимущества перечислены ниже:
а) Меньшая задержка
Развернув несколько кластеров, можно развернуть рабочие нагрузки рядом с разными группами пользователей. Например, можно также запустить один кластер в облаке, а другой — в центре совместного размещения, близком к вашему целевому демографическому примеру. Уменьшая географическое расстояние между вашими пользователями и вашими кластерами, вы можете уменьшить задержку.
б) Наличие
Используя несколько кластеров, вы можете повысить доступность своей рабочей нагрузки, а один кластер можно использовать в качестве резервной среды или среды резервного копирования в случае сбоя другого кластера. Распределяя кластеры между разными центрами обработки данных и /облаками, вы можете избежать риска того, что сбой одного центра обработки данных и /облака повлечет за собой, т.е. нарушить работу всех ваших рабочих нагрузок.
в) Масштабируемость
Развертывание нескольких кластеров может оказаться полезным для масштабирования вашей рабочей нагрузки по мере необходимости. Если все выполняется в одном кластере, становится сложнее определить конкретные рабочие нагрузки, требующие большего количества ресурсов или реплик, даже если у вас нет достаточных данных о производительности для конкретных рабочих нагрузок.
Еще одним недостатком развертывания одного кластера является то, что можно легко столкнуться с проблемами «шумных соседей». Для очень больших кластеров могут возникнуть проблемы, когда необходимо хранить данные более 5000 модулей на кластер.
d) Изоляция рабочей нагрузки
Настройка доступа к нескольким кластерам обеспечивает максимально возможную изоляцию между рабочими нагрузками. Рабочие нагрузки в отдельных кластерах не могут потреблять взаимные ресурсы или взаимодействовать друг с другом. Этот подход особенно полезен, если у вас есть несколько команд или отделов, ожидающих развертывания рабочих нагрузок в Kubernetes, и вы не хотите, чтобы вас беспокоили проблемы шумного соседа или конфиденциальности. Этот подход также помогает отделить среду разработки/тестирования от рабочей среды или даже экспериментировать с различными настройками Kubernetes. Имея доступ к нескольким кластерам Kubernetes, вы не рискуете изменить конфигурацию, поскольку облака вызывают проблемы для производственных рабочих нагрузок.
e) Гибкость
Тот, кто запускает несколько кластеров в Kubernetes, получает детальный контроль над настройкой каждого кластера. Например, можно выбрать разные версии Kubernetes для каждого кластера или выбрать другой CNI.
Гибкость конфигурации развертываний с несколькими кластерами выгодна, если у вас есть приложение, которое зависит от определенной настройки или версии инструмента в стеке. Этот подход также полезен, если вы хотите протестировать новую версию Kubernetes в изолированном кластере разработки/тестирования, прежде чем обновлять рабочие кластеры до новой версии.
f) Безопасность и соответствие нормативным требованиям
Многокластерный Kubernetes также дает некоторые преимущества в плане безопасности и соответствия требованиям. Строгая изоляция между рабочими нагрузками снижает риск того, что проблема безопасности в одном модуле перерастет в другие.
Сегментация рабочих нагрузок в разных кластерах обеспечивает максимальную изоляцию. Запуск нескольких кластеров облегчает соблюдение определенных правил соответствия. Например, если необходимо хранить некоторые рабочие нагрузки локально или ключевые данные в определенном географическом регионе из-за нормативных требований, можно развернуть кластер в месте, соответствующем этим требованиям, а другие кластеры запустить в другом месте.
При выборе между развертыванием с одним или несколькими кластерами жизненно важным фактором становится масштаб. В более крупных организациях, как правило, требуется развертывание большего количества приложений, и, следовательно, есть больше шансов получить выгоду от нескольких кластеров.
Подход к разработке/тестированию также становится жизненно важным. Для тех, кто хочет запускать свои приложения для разработки в том же кластере, что и производство, несколько кластеров не имеют большого значения. Напротив, несколько кластеров могут быть хорошей стратегией, если вы планируете изолировать разработку/тестирование от производства.
Рассредоточение ваших пользователей — это то, о чем нужно подумать. Тем, у кого есть пользователи, разбросанные по большой географической территории, необходимо несколько кластеров, чтобы уменьшить задержку и повысить производительность.
Используя инструменты управления Kubernetes, можно эффективно управлять несколькими кластерами. Однако развертывание с несколькими кластерами может создать больше проблем, чем оно того стоит. Те, кто может легко развертывать несколько кластеров и управлять ими, могут воспользоваться максимальными преимуществами многокластерной архитектуры без сложности управления, подрывающей ценность, которую обеспечивает Kubernetes.
Подходы к мультикластерному развертыванию Kubernetes
Существует несколько способов настройки многокластерного развертывания и управления им:
- Настройка нескольких кластеров вручную
Самый простой способ настроить несколько кластеров Kubernetes — это так называемый подход «сделай сам». Этот метод требует оптимальных усилий, но обеспечивает максимальную гибкость в отношении того, где работают кластеры и как ими управлять. Кластеры можно настроить практически в любом облаке или частном центре обработки данных, и вы можете управлять ими с помощью платформ, поддерживающих управление несколькими кластерами, таких как Teleport.
- Использование мультикластерного распределения
Дистрибутив Kubernetes предназначен для поддержки нескольких кластеров. Большинство основных дистрибутивов сейчас делают это:
Anthos: Anthos — это гибридная облачная платформа Google на базе Kubernetes, которая может управлять кластерами, работающими как в нескольких облаках, так и локально. Уровень управления предоставляется GKE, дистрибутивом Google Kubernetes.
EKS Anywhere: недавно анонсированная платформа Amazon EKS Anywhere обладает функциями, позволяющими маркетологам развертывать кластеры и управлять ими как в облаке AWS, так и локально. EKS Anywhere также может поддерживать кластеры в других общедоступных облаках; однако это все еще концепция.
Tanzu: Tanzu — это платформа VMware Kubernetes, которая поддерживает несколько кластеров, работающих в любом общедоступном облаке или локально, при условии, что кластеры соответствуют стандартам CNCF.
Как настроить доступ к нескольким кластерам
После того, как ваши кластеры, пользователи и контексты будут определены в одном или нескольких файлах конфигурации. Также вы можете быстро переключаться между кластерами с помощью следующей команды:
``ямл
контекст использования конфигурации kubectl
Файл, используемый для настройки доступа к кластеру, иногда также называют kubeconfig file. Обычно это общий способ обращения к файлам конфигурации. Это не означает, что файл с именем kubeconfig существует.
Вы должны использовать файлы kubeconfig только из надежных источников. Обычно специально созданный файл kubeconfig может привести к выполнению вредоносного кода или раскрытию файла. Те, кто использует файлы kubeconfig из ненадежных источников, должны сначала тщательно проверить их так же, как они хотели бы проверить сценарий оболочки.
Предварительные требования
Прежде чем начать, необходимо иметь кластер Kubernetes и инструмент командной строки kubectl, который нужно настроить для взаимодействия пользователей со своим кластером. Люди, у которых еще нет кластера Kubernetes, могут создать его с помощью minikube или использовать одну из следующих игровых площадок Kubernetes:
а) Катаконда
б) Играйте с Kubernetes
Чтобы проверить, установлен ли kubectl, нужно запустить kubectl version –client. Версия kubectl должна быть в пределах одной дополнительной версии сервера API вашего кластера.
Определение кластеров, пользователей и контекстов
Предположим, у вас есть два кластера: один для разработки и один для работы с нуля. В кластере разработки ваши разработчики интерфейса работают в пространстве имен, называемом интерфейсом, а разработчики хранилища работают в пространстве имен, называемом хранилищем. В вашем рабочем кластере разработчики работают в пространстве имен по умолчанию или создают вспомогательные пространства имен по мере необходимости. В то время как для доступа к рабочему кластеру требуется аутентификация по сертификату, доступ к рабочему кластеру требует аутентификации по имени пользователя и паролю.
Сначала можно начать с создания каталога с именем config-exercise. В каталоге config-exercise можно создать файл с именем config-demo, используя приведенное ниже содержимое:
``ямл
апиВерсия: v1
вид: Конфигурация
предпочтения: {}
кластеры:
- кластер:
Название: разработка
- кластер:
имя: царапина
пользователи:
- имя: разработчик
- имя: экспериментатор
контексты:
- контекст:
имя: dev-интерфейс
- контекст:
имя: dev-хранилище
- контекст:
Название: exp-scratch
В кластерах файлов конфигурации описываются пользователи и контексты. В файле config-demo есть структура для иллюстрации двух кластеров, двух пользователей и трех контекстов.
Перейдя в каталог config-exercise, вы можете ввести эти команды, чтобы добавить сведения о кластере в файл конфигурации.
``ямл
kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
kubectl config --kubeconfig=config-demo set-clustercrat --server=https://5.6.7.8 --insecure-skip-tls-verify
Кроме того, данные пользователя могут быть добавлены в ваш файл конфигурации:
``ямл
kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
``ямл
kubectl config --kubeconfig=config-demo set-credentials Experimenter --username=exp --password=пароль
Примечание:
- Чтобы удалить пользователя, вы можете запустить kubectl --kubeconfig=config-demo config unset users.<имя>
- Чтобы удалить кластер, вы можете запустить kubectl --kubeconfig=config-demo config unset clusters.
- Чтобы удалить контекст, вы можете запустить kubectl --kubeconfig=config-demo config unset contexts.
Добавьте сведения о контексте в файл конфигурации:
``ямл
kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-scratch --cluster=scratch --namespace=default --user=experimenter
Откройте файл config-demo, чтобы увидеть добавленные детали. В качестве альтернативы вы можете использовать команду config view вместо файла config-demo.
``ямл
kubectl config --kubeconfig=конфигурация-демонстрация
В выходных данных отображаются два кластера, два пользователя и три контекста:
``ямл
апиВерсия: v1
кластеры:
- кластер:
центр сертификации: поддельный-ca-файл
сервер: https://1.2.3.4
Название: разработка
- кластер:
небезопасно-пропустить-tls-проверить: правда
сервер: https://5.6.7.8
имя: царапина
контексты:
- контекст:
кластер: развитие
пространство имен: интерфейс
пользователь: разработчик
имя: dev-интерфейс
- контекст:
кластер: развитие
пространство имен: хранилище
пользователь: разработчик
имя: dev-хранилище
- контекст:
кластер: царапина
пространство имен: по умолчанию
Пользователь: экспериментатор
Название: exp-scratch
текущий контекст: ""
вид: Конфигурация
предпочтения: {}
пользователи:
- имя: разработчик
Пользователь:
клиент-сертификат: поддельный-сертификат-файл
ключ-клиента: поддельный-ключ-файл
- имя: экспериментатор
Пользователь:
пароль: какой-то пароль
имя пользователя: опыт
Описанные выше файлы поддельного ca, поддельный файл сертификата и файл поддельного ключа представляют собой заполнители для путей к файлам сертификатов. Вы должны изменить их на фактические пути к файлам сертификатов в вашей среде.
Иногда вы можете захотеть использовать встроенные данные в кодировке Base64 вместо отдельных файлов сертификатов; в этом случае к ключам необходимо добавить суффикс -данные, например, данные-сертификационного центра, данные-сертификата-клиента, данные-ключ-клиента.
Каждый кластер представляет собой тройку (кластер, пользователь, пространство имен). Например, контекст dev-frontend иллюстрирует: «Используйте учетные данные, которые разработчик использует для доступа к пространству имен внешнего интерфейса кластера разработки».
См. текущий контекст:
``ямл
kubectl config --kubeconfig=config-demo use-context dev-frontend
Вывод демонстрирует информацию о конфигурации, согласованную с контекстом dev –frontend:
``ямл
апиВерсия: v1
кластеры:
- кластер:
центр сертификации: поддельный-ca-файл
сервер: https://1.2.3.4
Название: разработка
контексты:
- контекст:
кластер: развитие
пространство имен: интерфейс
пользователь: разработчик
имя: dev-интерфейс
текущий контекст: dev-интерфейс
вид: Конфигурация
предпочтения: {}
пользователи:
- имя: разработчик
Пользователь:
клиент-сертификат: поддельный-сертификат-файл
ключ-клиента: поддельный-ключ-файл
А что, если вы хотите поработать какое-то время в рабочем кластере? Измените текущий контекст на exp-scratch:
``ямл
kubectl config --kubeconfig=config-demo use-context exp-scratch
Теперь любая введенная вами команда kubectl будет применяться к пространству имен по умолчанию рабочего кластера. Кроме того, команда будет использовать учетные данные пользователя, указанные в контексте exp-scratch.
Вы также можете просмотреть конфигурацию, связанную с новым текущим контекстом, exp-scratch.
``ямл
kubectl config --kubeconfig=config-demo view –minify
Наконец, если нужно какое-то время поработать в пространстве имен хранилища кластера разработки, можно изменить текущий контент на dev-storage:
``ямл
kubectl config --kubeconfig=config-demo use-context dev-storage
Вы также можете просмотреть конфигурацию, связанную с новым текущим контекстом, dev-storage:
``ямл
kubectl config --kubeconfig=config-demo view –minify
Создание второго файла конфигурации
В их каталоге config-exercise вы можете создать файл с именем config-demo-2 со следующим содержимым:
``ямл
апиВерсия: v1
вид: Конфигурация
предпочтения: {}
контексты:
- контекст:
кластер: развитие
пространство имен: рампа
пользователь: разработчик
имя: dev-разгон
Предыдущий файл конфигурации определяет новый контекст с именем dev-ramp-up.
Настройка переменной среды KUBECONFIG
Вам нужно посмотреть, есть ли у вас переменная среды с именем KUBECONFIG. Если это так, сохраните текущее значение вашей переменной среды KUBECONFIG, чтобы вы могли восстановить его позже. Например:
Линукс
``ямл
экспорт KUBECONFIG_SAVED=$KUBECONFIG
Windows PowerShell
``ямл
$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG
$Env:KUBECONFIG=("config-demo;config-demo-2")
В вашем каталоге config-exercise вы можете ввести следующую команду:
``ямл
вид конфигурации kubectl
Вывод показывает объединенную информацию из всех файлов, перечисленных в вашей переменной среды KUBECONFIG. Объединенная информация содержит контекст dev-ramp-up из файла config-demo-2 и три контекста из файла config-demo.
``ямл
контексты:
- контекст:
кластер: развитие
пространство имен: интерфейс
пользователь: разработчик
имя: dev-интерфейс
- контекст:
кластер: развитие
пространство имен: рампа
пользователь: разработчик
имя: dev-разгон
- контекст:
кластер: развитие
пространство имен: хранилище
пользователь: разработчик
имя: dev-хранилище
- контекст:
кластер: царапина
пространство имен: по умолчанию
Пользователь: экспериментатор
Название: exp-scratch
Изучение каталога $HOME/.kube
Те, у кого уже есть кластер, могут использовать kubectl для взаимодействия с кластером. Тогда у вас будет файл с именем config в каталоге $HOME/.kube.
Перейдите в $HOME/.kube и посмотрите, какие файлы доступны. Как правило, это файл с именем config. В этом каталоге могут быть и другие файлы конфигурации. Кратко ознакомьтесь с содержимым этих файлов.
Добавьте $HOME/.kube/cofig в переменную среды KUBECONFIG.
Если у вас есть файл $HOME/.kube/config, и он еще не указан в вашей переменной среды KUBECONFIG, добавьте его в переменную среды KUBECONFIG прямо сейчас. Например:
Линукс
``ямл
экспорт KUBECONFIG=$KUBECONFIG:$HOME/.kube/config
Windows PowerShell
``ямл
$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME.kube\config"
Линукс
``ямл
экспорт KUBECONFIG=$KUBECONFIG_SAVED
Windows PowerShell
``ямл
экспорт KUBECONFIG=$KUBECONFIG_SAVED
Верните исходное значение переменной среды KUBECONFIG. Например:
Линукс
``ямл
экспорт KUBECONFIG=$KUBECONFIG_SAVED
Windows PowerShell
``ямл
экспорт KUBECONFIG=$KUBECONFIG_SAVED
Мультикластер Kubernetes предлагает бесчисленные преимущества, особенно для команд, которым необходимо работать в больших масштабах или которым требуется строгая изоляция между их рабочими нагрузками. Чтобы получить максимальную отдачу от многокластерного подхода, очень важно выбрать платформу управления, которая позволит вам эффективно управлять несколькими кластерами.
Teleport — отличный пример, который обеспечивает доступ к кластерам Kubernetes во всех средах. Платформа облегчает выполнение требований соответствия и обеспечивает полную прозрачность доступа и поведения. Для сред DevOps Teleport легко позволяет любому защитить свои кластеры Kubernetes, используя лучшие практики безопасности. Можно внедрить лучшие отраслевые практики доступа Kubernetes с минимальной конфигурацией. Teleport также позволяет легко применять многофакторную аутентификацию (MFA), управление доступом на основе ролей (RBAC), единый вход (SSO) с использованием недолговечных сертификатов X.509 на основе удостоверений.
Запросы на доступ переходят от учетных записей администраторов благодаря своевременному повышению привилегий Kubernetes, которое включено для административных задач. Запросы на доступ можно одобрить через Slack или другие поддерживаемые плагины. Teleport упрощает маршрутизацию TLS, в которой протокол на основе сертификатов сужает поверхность атаки сети всех ваших кластеров Kubernetes до одного порта TCP/IO и снижает операционные издержки. Вошедшим в систему пользователям также разрешено реализовывать многофакторную авторизацию привилегированных операций.
Доверенные кластеры Teleport были разработаны, чтобы облегчить пользователям подключение к вычислительной инфраструктуре, расположенной за брандмауэрами, без открытых портов TCP. Некоторые из примеров того, как они используются, включают:
а) Поставщики управляемых услуг (MSP) удаленно управляли инфраструктурой своих клиентов.
б) Производители устройств удаленно обслуживают вычислительные устройства, развернутые локально.
в) Крупные поставщики облачного программного обеспечения управляют несколькими центрами обработки данных с помощью общего прокси-сервера.
Заключение
К настоящему моменту вы, должно быть, уже поняли, что многокластерное развертывание Kubernetes дает бесчисленные преимущества с точки зрения производительности (меньшая задержка, доступность, масштабируемость рабочей нагрузки), изоляции рабочей нагрузки, гибкости и безопасности.
Основное преимущество использования Teleport для управления распределением по нескольким кластерам заключается в том, что пользователи не привязаны к конкретным типам конфигураций или инструментов кластера. Teleport позволяет пользователям настраивать каждый кластер по-разному (например, с использованием разных CNI) и может управлять ими централизованно.
Teleport также обеспечивает поддержку нескольких версий и полезен для пользователей, желающих развернуть разные версии Kubernetes в каждом кластере. Таким образом, пользователи получают возможность запускать любую версию или версии Kubernetes, которые им нужны. Это может быть полезно, если вы хотите протестировать одну версию Kubernetes в одном кластере, ограничив ее проверенной версией для ваших производственных кластеров. Teleport позволяет централизованно управлять всеми этими кластерами и версиями, обеспечивая при этом детальный контроль над версиями.
Такая платформа, как Teleport, необходима для получения максимальной отдачи от мультикластерного подхода, поскольку она позволяет эффективно управлять несколькими кластерами, и в этом суть многокластерного Kubernetes. Этот подход может быть исключительно полезен для групп, которым необходимо работать в больших масштабах или которым требуется строгая изоляция между их рабочими нагрузками.
Оригинал