Как работает Bridge to Kubernetes

Bridge to Kubernetes— это средство последовательной разработки для создания приложений на базе микрослужб, предназначенных для Kubernetes. Расширение Bridge to Kubernetes доступно для Visual Studio и Visual Studio Code (VSCode).

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

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

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

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

Требования

Чтобы использовать Bridge to Kubernetes, вам потребуется одна из следующих конфигураций:

• VS Code с установленным расширением Bridge to Kubernetes.
• Visual Studio2019 версии16.7 или более поздней версии в Windows10 или более поздней версии. Убедитесь, что установлена рабочая нагрузка ASP.NET и разработка веб-приложений. Установите расширение Bridge to Kubernetes.

Вы можете использовать Bridge to Kubernetes для установки подключения к кластеру Kubernetes. При таком подключении трафик перенаправляется между существующим модулем pod в кластере и компьютером разработки.

В VS Code расширение Bridge to Kubernetes поддерживает все языки, если вы можете запускать их локально. В Visual Studio расширение Bridge to Kubernetes поддерживает .NETCore. Bridge to Kubernetes не поддерживает .NETFramework в Visual Studio, так как для этого требуется поддержка узлов Windows.

Сведения о текущих возможностях и планах на будущее см. в дорожной карте Bridge to Kubernetes.

Установка подключения

Когда расширение Bridge to Kubernetes устанавливает подключение к кластеру, оно выполняет следующие действия:

• Выводит запрос на настройку службы, которую следует заменить в кластере, порта на компьютере разработки, который следует использовать для кода, и задачи запуска для кода. Настройка выполняется один раз.
• Заменяет контейнер в модуле pod в кластере контейнером удаленного агента, который перенаправляет трафик на компьютер разработки.
• Выполняет команду kubectl port-forward на компьютере разработки для перенаправления трафика с компьютера разработки в удаленный агент, запущенный в кластере.
• Собирает сведения о среде из кластера с помощью удаленного агента. Эти сведения включают в себя переменные среды, видимые службы, подключенные тома и подключенные секреты.
• Настраивает среду в Visual Studio так, чтобы служба на компьютере разработки могла получать доступ к переменным так же, как если бы она выполнялась в кластере.
• Обновляет файл hosts, сопоставляя службы в кластере с локальными IP-адресами на компьютере разработки. Эти записи в файле hosts позволяют коду, выполняющемуся на компьютере разработки, совершать запросы к другим службам, работающим в кластере. Чтобы обновить файл hosts, Bridge to Kubernetes требуется доступ с правами администратора на компьютере разработки.
• Начинает выполнять и отлаживать код на компьютере разработки. При необходимости Bridge to Kubernetes освобождает необходимые порты на компьютере разработки, останавливая использующие их службы или процессы.

Использование Bridge to Kubernetes

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

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

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

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

Дополнительная настройка

Файл KubernetesLocalProcessConfig.yaml позволяет реплицировать переменные среды и подключенные файлы, доступные для модулей pod в кластере. Если используется VisualStudio, файл KubernetesLocalConfig.yaml должен находиться в том же каталоге, что и файл проекта для службы. Дополнительные сведения см. в разделе Настройка Bridge to Kubernetes.

Использование возможностей маршрутизации для разработки в изоляции

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

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

При работе в изоляции Bridge to Kubernetes выполняет следующие действия в дополнение к подключению к кластеру Kubernetes:

• Проверяет, что в кластере Kubernetes не включена служба Azure Dev Spaces.
• Реплицирует выбранную службу в кластер в том же пространстве имен и добавляет метку routing.visualstudio.io/route-from=SERVICE_NAME и заметку routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME.
• Настраивает и запускает диспетчер маршрутизации в том же пространстве имен в кластере Kubernetes. Диспетчер маршрутизации использует селектор меток для поиска метки routing.visualstudio.io/route-from=SERVICE_NAME и заметки routing.visualstudio.io/route-on-header=kubernetes-route-as=GENERATED_NAME при настройке маршрутизации в вашем пространстве имен.

При запуске диспетчер маршрутизации выполняет следующие действия:

• Дублирует весь входящий трафик (включая входящий трафик подсистемы балансировки нагрузки), найденный в пространстве имен, используя GENERATED_NAME в качестве поддомена.
• Создает модуль pod – представитель для каждой службы, связанной с повторяющимися входящим трафиком, с поддоменом GENERATED_NAME.
• Создает дополнительный модуль pod-представитель для службы, над которой выполняется работа в изоляции. Эта конфигурация позволяет перенаправлять запросы с поддоменом на компьютер разработки.
• Настраивает правила маршрутизации для каждого модуля pod – представителя, чтобы управлять маршрутизацией для служб с поддоменом.

На следующей схеме показан кластер Kubernetes перед подключением Bridge to Kubernetes к нему:

На приведенной ниже схеме показан тот же кластер с функцией Bridge to Kubernetes, включенной в режиме изоляции. На ней видна дублированная служба и модули pod Envoy, поддерживающие маршрутизацию в режиме изоляции.

Когда кластер получает запрос с поддоменом GENERATED_NAME, он добавляет заголовок kubernetes-route-as=GENERATED_NAME в запрос. Модуль pod– представитель обрабатывает маршрутизацию, которая запрашивает соответствующую службу в кластере. Если запрос направляется в службу, которая работает в режиме изоляции, кластер перенаправляет этот запрос на компьютер разработки с помощью удаленного агента.

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

При отключении от кластера решение Bridge to Kubernetes по умолчанию удаляет все модули pod-представители и дублирующую службу.

kubectl delete deployment routingmanager-deployment -n NAMESPACEkubectl delete service routingmanager-service -n NAMESPACE

Диагностика и ведение журнала

При использовании Bridge to Kubernetes для подключения к кластеру компьютер ведет журнал диагностики. Он сохраняется в папке Bridge to Kubernetes в каталоге TEMP на компьютере разработки.

Авторизация Kubernetes RBAC

Kubernetes предоставляет управление доступом на основе ролей (RBAC) для управления разрешениями пользователей и групп. Дополнительные сведения см. в документации по Kubernetes. Вы можете настроить разрешения для кластера с поддержкой RBAC, создав YAML-файл и используя kubectl для его применения в кластере.

Чтобы задать разрешения в кластере, создайте или измените YAML-файл, например permissions.yml. Используйте пространство имен для <namespace>, а также пользователей и группы, которым требуется доступ.

kind: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: bridgetokubernetes-<namespace> namespace: developmentsubjects: - kind: User name: jane.w6wn8.k8s.ginger.eu-central-1.aws.gigantic.io apiGroup: rbac.authorization.k8s.io - kind: Group name: dev-admin apiGroup: rbac.authorization.k8s.ioroleRef: kind: ClusterRole name: admin apiGroup: rbac.authorization.k8s.io

Примените разрешения с помощью следующей команды:

kubectl -n <namespace> apply -f <yaml file name>

Ограничения

Bridge to Kubernetes имеет следующие ограничения:

• Для успешного подключения с помощью функции Bridge to Kubernetes в модуле pod должен выполняться только один контейнер.
• В настоящее время модули pod для функции BridgetoKubernetes должны быть контейнерами Linux. Контейнеры Windows не поддерживаются.
• Функции Bridge to Kubernetes требуется повышенный уровень разрешений на компьютере разработки для изменения файла hosts.
• Bridge to Kubernetes нельзя использовать в кластерах с включенной службой Azure Dev Spaces.

Дальнейшие действия

Чтобы приступить к использованию функции Bridge to Kubernetes для подключения локального компьютера разработки к кластеру, обратитесь к статье Использование Bridge to Kubernetes (VS) или Использование Bridge to Kubernetes (VSCode).

Videos