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

Примечание.

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

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

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

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

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

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

Требования

Примечание.

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

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

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

Примечание.

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

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

Внимание

Функция Bridge to Kubernetes предназначена для использования только в сценариях разработки и тестирования. Он не предназначен для выполнения с рабочими кластерами или службами Live в активном использовании.

Сведения о текущих возможностях и планах на будущее см. в дорожной карте 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. Этот файл также можно использовать для создания новых переменных среды и подключений томов.

Примечание.

На протяжении всего сеанса подключения к кластеру (и еще 15 минут) расширение Bridge to Kubernetes выполняет на локальном компьютере процесс EndpointManager с разрешениями администратора.

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

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

Файл KubernetesLocalProcessConfig.yaml позволяет реплицировать переменные среды и подключенные файлы, доступные для модулей pod в кластере. Если используется Visual Studio, файл 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 при настройке маршрутизации в вашем пространстве имен.

Примечание.

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

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

• Дублирует весь входящий трафик (включая входящий трафик подсистемы балансировки нагрузки), найденный в пространстве имен, используя 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 направляют этот запрос в исходную службу, а не в удаленный агент.

Внимание

При выполнении дополнительных запросов каждая служба в кластере должна перенаправить заголовок kubernetes-route-as=GENERATED_NAME. Например, когда служба serviceA получает запрос, она делает запрос к службе serviceB, прежде чем вернуть ответ. В этом примере служба serviceA должна перенаправить заголовок kubernetes-route-as=GENERATED_NAME в своем запросе к службе serviceB. Некоторые языки, например ASP.NET, могут предоставлять методы для обработки распространения заголовка.

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

Примечание.

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

kubectl delete deployment routingmanager-deployment -n NAMESPACE
kubectl 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: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bridgetokubernetes-<namespace>
  namespace: development
subjects:
  - 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.io
roleRef:
  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 для функции Bridge to Kubernetes должны быть контейнерами Linux. Контейнеры Windows не поддерживаются.
• Функции Bridge to Kubernetes требуется повышенный уровень разрешений на компьютере разработки для изменения файла hosts.
• Bridge to Kubernetes нельзя использовать в кластерах с включенной службой Azure Dev Spaces.

Следующие шаги

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