Kubernetes 桥接的工作原理

项目
10/17/2023

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 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 在 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 在隔离模式下进行开发，从而避免中断群集中的其他流量。

以下动画显示了两个开发者独立处理同一群集：

Animation shows isolation, with two developers working with the same cluster.

启用隔离工作模式后，除了连接到 Kubernetes 群集，Bridge to 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 群集：

Diagram of cluster without Bridge to Kubernetes.

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

Diagram of cluster with Bridge to Kubernetes enabled.

当群集收到的请求包含 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 连接到群集时，计算机会记录诊断。它会将诊断存储在开发计算机的 Bridge to Kubernetes 文件夹中的 TEMP 目录中。

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 具有以下限制：

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

后续步骤

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