Bridge to Kubernetes 的工作原理

项目
02/12/2025

注意

Bridge to Kubernetes 将于 2025 年 4 月 30 日停用。有关停用和开源替代项的详细信息，请参阅 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 集群中的环境变量和挂载的卷复制到您的开发计算机中。通过访问环境变量和已装载卷，可以处理代码而无需复制这些依赖项。

要求

说明

Bridge to Kubernetes 不适用于 Docker for Desktop Kubernetes 群集。若要使用 Bridge to Kubernetes，需要以下任一配置：

已安装 Bridge to Kubernetes 扩展的 VS Code。
在 Windows 10 或更高版本上运行的 Visual Studio 2019 版本 16.7 或更高版本。请确保已安装 ASP.NET 和 Web 开发 工作负荷。将 Bridge 安装到 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 不支持 Visual Studio 中的 .NET Framework，因为它需要 Windows 节点支持。

谨慎

Bridge to Kubernetes 仅用于开发和测试方案。它不适合或支持在活动使用中与生产群集或实时服务一起使用。

有关当前功能和未来计划，请参阅 Bridge to Kubernetes 路线图。

建立连接

当 Bridge to Kubernetes 建立与群集的连接时，它将执行以下操作：

提示你在群集上配置要替换的服务，在开发计算机上配置用于代码的端口，并将代码的启动任务配置为一次性操作。
将集群中 Pod 的容器替换为一个将流量重定向到开发计算机的远程代理容器。
在开发计算机上运行 kubectl port-forward，将流量从开发计算机转发到群集中运行的远程代理。
使用远程代理从群集收集环境信息。此环境信息包括环境变量、可见服务、卷装载和机密装载。
在 Visual Studio 中配置环境，以便开发计算机上的服务可以像在群集上运行时一样，访问相同的变量。
更新主机文件，将群集上的服务映射到开发计算机上的本地 IP 地址。这些主机文件条目允许开发计算机上运行的代码向群集中运行的其他服务发出请求。若要更新主机文件，Bridge to Kubernetes 需要在开发计算机上获得管理员访问权限。
开始在开发计算机上运行和调试代码。如有必要，Bridge to Kubernetes 通过停止当前使用这些端口的服务或进程释放开发计算机上的所需端口。

使用 Bridge to Kubernetes

与群集建立连接后，在计算机上以本机方式运行和调试代码，而无需容器化。代码与群集交互。远程代理接收的任何网络流量将重定向到连接期间指定的本地端口。本机运行的代码可以接受和处理该流量。群集中的环境变量、卷和机密可供开发计算机上运行的代码使用。

Bridge to Kubernetes 会将主机文件条目和端口转发添加到开发人员计算机。代码可以使用群集中的服务名称将网络流量发送到群集上运行的服务。该流量会转发到群集中运行的服务。在整个连接期间，流量在开发计算机和群集之间路由。

此外，Bridge to Kubernetes 还提供了一种方法，通过 KubernetesLocalProcessConfig.yaml 文件复制开发计算机中可用于群集中 Pod 的环境变量和已装载的文件。还可以使用此文件创建新的环境变量和卷装载。

说明

在连接到群集期间（加上 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 检查是否已在 Kubernetes 群集上启用 Azure Dev Spaces。它提示你先禁用 Azure Dev Spaces，然后才能使用 Bridge to Kubernetes。

路由管理器在启动时执行以下操作：

使用子域的 GENERATED_NAME 复制在命名空间中找到的所有流入量（包括负载均衡器流入量）。
使用 GENERATED_NAME 子域为与复制的流入量关联的每个服务创建 envoy pod。
为正在隔离处理的服务创建另一个 envoy pod。此配置允许将子域的请求路由到开发计算机。
为每个 envoy Pod 配置路由规则，以处理具有子域的服务的路由。

下图显示了在 Bridge to Kubernetes 连接到您的 Kubernetes 集群之前的集群状态：

没有 Bridge to Kubernetes 的群集关系图。

下图显示了在隔离模式下启用了 Bridge to Kubernetes 的同一群集。从该图中，你可以看到复制服务和支持独立路由的 envoy pod。

启用了 Bridge to Kubernetes 的群集关系图。

当群集收到具有 GENERATED_NAME 子域的请求时，它会向请求添加 kubernetes-route-as=GENERATED_NAME 标头。 envoy Pod 负责将请求路由到集群中相应的服务。对于正在隔离处理的服务的请求，群集会通过远程代理将请求重定向到开发计算机。

当群集收到没有 GENERATED_NAME 子域的请求时，它不会向请求添加标头。 Envoy pod 负责将该请求路由到群集中的相应服务。对于针对所替换的服务的请求，Pod 会将请求路由到原始服务而不是远程代理。

重要

在发出额外请求时，集群上的每个服务都必须转发 kubernetes-route-as=GENERATED_NAME 标头。例如，当 serviceA 收到请求时，它会在返回响应之前向 serviceB 发出请求。在此示例中，serviceA 需要将其请求中的 kubernetes-route-as=GENERATED_NAME 标头转发到 serviceB。某些语言（如 ASP.NET）可能具有处理标头传播的方法。

默认情况下，从群集断开连接时，Bridge to Kubernetes 会删除所有 envoy Pod 和重复服务。

注意

路由管理器部署和服务仍在命名空间中运行。若要删除部署和服务，请对命名空间运行以下命令。

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

诊断和日志记录

使用 Bridge to Kubernetes 连接到群集时，计算机会记录诊断。它将它们存储在开发计算机的 TEMP 目录中的 Bridge to Kubernetes 文件夹中。

Kubernetes RBAC 授权

Kubernetes 提供基于角色的访问控制（RBAC）来管理用户和组的权限。有关信息，请参阅 Kubernetes 文档。可以通过创建 YAML 文件并使用 kubectl 将其应用到群集来设置启用 RBAC 的群集的权限。

若要设置群集的权限，请创建或修改 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 具有以下限制：

一个 Pod 只能有一个容器在其中运行，以便 Bridge to Kubernetes 能成功连接。
目前，Bridge to Kubernetes Pod 必须是 Linux 容器。不支持 Windows 容器。
Bridge to Kubernetes 需要提升的权限才能在开发计算机上运行，以便编辑主机文件。
无法在启用了 Azure Dev Spaces 的群集上使用 Bridge to Kubernetes。

后续步骤

若要开始使用 Bridge to Kubernetes 将本地开发计算机连接到群集，请参阅使用 Bridge to Kubernetes（VS）或使用 Bridge to Kubernetes（VS Code）。

通过