问题的产生
引入K8S后，开发过程中会产生以下几个问题：
- 服务以POD的方式启动，无法进行重启操作；
- 微服务开发，往往会有依赖开发，需要连接集群中其他服务；
- K8S内部微服务不对外暴露（如果需要可以使用nodeport的方式暴露出来，但是调试需要修改源码或服务发现配置）
开发过程可能会使用最容易理解，最废的开发流程：
走一遍这样的流程的人，我愿意称之为勇士，一直走这样流程的人，我想问问云原生如果降低开发效率，那大家推荐Kubernetes做啥？
演进方案一 telepresence
在公司落地K8S过程中，我对所有项目进行容器化改造后，我就带着这个疑问进行网上冲浪；果然Kubernetes官方文档中有对开发方式进行推荐（telepresence）；
开始使用，简直大大的提高了开发效率，具体提供以下两个功能：
- 本地微服务需要访问kubernetes内部服务时，telepresence能够将对应流量引入到K8S中，完成调用（可以使用FQDN，clusterIP进行调用）
- 能够拦截微服务流量，将kubernetes流量引入本地；
在这基础上，可以减少编译调试，更换镜像的操作；但在此基础上又带来了新的问题：
- 多人同时开发服务A，同时需要测试，那么在同一个K8S集群内拦截服务会造成冲突；
- 新人上手的时候，需要部署自己的开发机器，因为公司为内部网络需要配置多个代理源来下载依赖包；
基于以上问题，因为单兵作战肯定无法向互联网大厂那样开发平台解决；所以引入okteto工具+istio完成流量染色的开发模式；
演进二 流量染色开发模式
对外部进入的流量进行标记，通过istio路由到同一服务的不同版本:
环境中标准环境由专人维护，开发人员需要开发服务A时，拉取出对应的服务A-gray版本；并使用okteto工具将服务A-gray的deployment进行整体替换（使用自己的基础镜像），能够实现在windows本地编写代码，实时将代码同步到k8s内部进行调试。
这样开发的优势也很明显：
- 基础镜像封装好所有编译语言的依赖项，新人直接能上手；并且无需再让新人配置自己的编译环境；
- 一套K8S环境专人维护，服务可实现多分支开发；
- 基于okteto的功能，可实现：
-
- 在windows上远程调试go，python等代码；
- 将pod内部端口映射到windows指定端口，调试直接可使用localhost即可；
- 代码实时上传；
大大的提升了开发人员在K8S上编码的效能；后续的演进思路需要做个研发平台来，可以界面化的配置istio路由，部署服务，根据新服务克隆数据库等等；
