01痛点

在我们团队将产品的部署形态迁移到kubernetes上之后，在研发过程中，开发和联调代码的过程非常的痛苦，决定寻找在k8s环境下的云原生时代的打通本地和开发环境的解决方案。

回顾一下，过去的开发过程，我们的进程一共有2种模式，即k8s无关进程和依赖了k8s的进程。

02分析

- k8s无关进程 -

• 由于项目依赖了oracle连接库，安装oracle驱动，在团队中既有window，unbuntu，和mac的情况下，团队成员的本地开发环境的搭建非常复杂
• 进程依赖的环境变量非常多，如果开发环境的ip换掉，配置环境变量非常麻烦
• 进程内依赖了一些二进制bin文件，格式是ELF的，这些文件在windows和mac的环境上是无法执行的

- 依赖了k8s的进程 -

• 需要复制开发环境上kubeconfig文件到本地，一个人如果同时开发多个环境，切换kubeconfig文件非常繁琐
• 本地开发无法将开发环境上的流量导到本地，需要打包替换环境上镜像来完成联调

03现状

因此日常的开发流程便是：

1. 配置环境变量和kubeconfig
2. 使用postman等其他工具进行本地开发
3. 提交代码、跑 CI 流程，出镜像
4. 替换环境上镜像
5. 自测

显然，为了保证在本地开发的代码，在环境上真实运行的效果完全一致，带来了很大的工作效率问题，本地编码2分钟，上环境自测5分钟

04需求

因此我们急需一种便捷的，学习成本低的，基于配置的，一劳永逸的，团队统一的解决方案来打通本地和开发环境，节省本地开发环境的搭建和配置的时间，节省团队成员联调的时间，提高团队效率

05方案选型

Telepresence

参考

https://docs.microsoft.com/zh-cn/visualstudio/bridge/overview-bridge-to-kubernetes?view=vs-2022

介绍

Telepresence是一款为Kubernetes微服务框架提供快速本地化开发功能的开源软件。Telepresence在Kubernetes集群中运行的Pod中部署双向网络代理，该Pod将Kubernetes环境（如TCP连接，环境变量，卷）中的数据代理到本地进程。本地进程透明地覆盖其网络，以便DNS调用和TCP连接通过代理路由到远程Kubernetes集群，能够获取

特性

• 基于在本地计算机使用docker，fuse/sshfs 和流量转发技术，来将本地和远程之间的流量和文件系统打通，以在本地使用ide进行调试
• 本地访问远端的服务，跨namespace
• 本地服务可以完全访问远程群集中的其他服务
• 本地服务可以完全访问Kubernetes的环境变量，Secrets和ConfigMap
• K8S中运行的远程服务也可以完全访问本地服务
• 通过在本地使用docker来运行本地代码，并和远程k8s服务通信，本支行承担了类似kubelet的角色

缺陷

• 不支持ide插件
• 不能将本地代码同步到远端进行调试
• 没有做隔离，进入调试模式后，服务的可用性取决于本地服务
• 只能使用命令操作，操作不能配置化，操作繁琐

Bridge to kubernetes

参考

https://docs.microsoft.com/zh-cn/visualstudio/bridge/overview-bridge-to-kubernetes?view=vs-2022

介绍

Bridge to Kubernetes 可重定向已连接的 Kubernetes 群集与开发计算机之间的流量。Kubernetes 群集中的本地代码和服务可以像在同一 Kubernetes 群集中一样进行通信。

Bridge to Kubernetes插件只可用于Visual Studio和VS Code，支持其他ide的计划还在官方的RoadMap上没有开始

工作原理

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

特性

• 打通本地和远程k8s环境的流量
• 将环境信息包括环境变量、service、volume，secret，configmap克隆到本地
• 通过自动修改/etc/hosts文件，将集群上的服务映射到开发计算机上的本地 IP 地址

缺陷

Bridge to Kubernetes 具有以下限制：

1. 要使 Bridge to Kubernetes 成功连接，一个 pod 只能有一个容器在该 pod 中运行，但是现实中有很多多容器的pod。
2. 目前，Bridge to Kubernetes pod 必须是 Linux 容器。Windows容器。
3. 如果k8s环境是集群环境，若要更新 /etc/hosts 文件  ，Bridge to Kubernetes计算机上需要管理员访问权限

Nocalhost

参考

https://nocalhost.dev/zh-CN/docs/introduction

介绍

Nocalhost 是一款开源的基于 IDE 的云原生应用开发工具：

• 直接在 Kubernetes 集群中构建、测试和调试应用程序
• 提供易于使用的 IDE 插件（支持 VS Code 和 JetBrains），即使在 Kubernetes 集群中进行开发和调试，Nocalhost 也能保持和本地开发一样的开发体验
• 使用即时文件同步进行开发： 即时将您的代码更改同步到远端容器，而无需重建镜像或重新启动容器。

Nocalhost 的野心相比 Bridge to Kubernetes 和 Telepresence 更大，具有开发环境的管理体系。深度整合 vscode / IntelliJ IDEA 实现了一键部署上云，一键远程 debug 等式开发的贴心功能。

其设计的核心就是自动同步：

• 自动同步和热加载代码
• 文件
• 终端

Nocalhost 目前是完全开源的，并已进入 CNCF Landscape:

支持goland, idea，pycharm, vscode

工作原理

Nocalhost 由单个二进制 CLI 和 IDE 插件组成。理想情况下，您可以直接将它与您熟悉的 IDE 一起使用。

Nocalhost 不需要服务器端组件，因为它通过 KubeConfig 直接与您的 Kubernetes 集群通信，就像 kubectl 一样。

特性

- 实时线上编码 -

Nocalhost 预配置为与你喜欢的 IDE 配合使用，你可以一键连接到任何 Kubernetes 集群，开始享受在集群内进行编码，摆脱烦人的本地环境配置。

- 实时同步 -

Nocalhost 可以在你每次进行修改时自动将代码同步到 K8s 容器中。这样能免去了镜像提交、构建和推送等步骤，极大提速了开发的反馈循环。因此代码修改可以实现秒级生效。

- 易于协作 -

• Nocalhost 可帮助你的团队实现标准化开发工作流程，而无需让团队中的每个人都成为 Kubernetes 专家
• 团队中的 Kubernetes 和 DevOps 专家可以通过 Nocalhost Server 配置和管理集群、应用程序、DevSpace 和用户。阅读有关 Nocalhost Server 的更多信息
• 开发人员无需成为 Kubernetes 专家，即可轻松查看项目并即时在 Kubernetes 集群中开始编码和调试

使用方式

Nocalhost 由单个二进制 CLI 和 IDE 插件组成。理想情况下，您可以直接将它与您熟悉的 IDE 一起使用。

为什么使用Nocalhost？

构建 Kubernetes 应用并不简单，尤其对于大型开发团队来说更具挑战。Nocalhost 提供了最高效的方式来构建云原生应用程序。

使用 Nocalhost 直接在 Kubernetes 中进行开发的优势有：

• 生产环境相似性 - 开发环境与你的生产环境非常相似，让你更有信心在发布新功能时一切都将在生产环境中正常工作。
• 提速反馈循环 - 通过文件同步，你所有代码更改可以在容器中立即生效，而无需重建镜像或重新部署容器。
• 灵活的扩展性 - 开发人员无需再担心本地资源不足。
• 降低成本 - 更有效地使用资源并降低 IT 设施成本。

在下述环境里，在 Kubernetes 集群中进行开发很有用：

• 本地资源的限制
• 由于环境的特殊性，在本地无法搭建能够运行的环境
• 想要在类似生产环境中测试你的应用
• 想要调试在本地计算机上难以重现的问题
• 应用程序需要访问集群内部服务 (例如集群 DNS)

对比PK

三者比较来看Nocalhost是特性最多，支持的场景最多，支持IDE的插件最多，并且用户体验最好。完胜其他两位，是其他两个工具支持特性的超集，因此我们选择了Nocalhost，让基于云原生的开发更高效。