小志：“kubefwd 本地开发的福音啊，本地环境直接连接svc。”
当小志推荐这个工具的时候，我正在Kubecon大会的现场，听着Kubernetes近一年的各种成就和各种新特性。我无法看到微信另一头小志的表情，也许平静，也许跟我现在一样激动。
kubefwd，这是第一次听到这个工具，“本地环境直接连接svc”，openshift的port-fowrward命令就能做到，没什么也不起的吧。
我回复道：“openshift的port-forward，再加个自动更新本地hosts文件”。
小志发来了kubefwd请求流向图。
服务api与服务auth提供的都是80端口，但是它们能够同时被本地访问，这是port-forward无法做到的！我意识到这个工具很不简单，刚才的想法太草率了。
我马上回复：“我刚才理解得不对，它可以做到一个port对应多个service！”
此刻的心情其实已经非常激动了，因为意识到kubefwd这个工具也许解决了困扰我多天的问题。
近一周一直在脑中徘徊的是徐磊老师介绍微软的TFS时的演示：开发人员本地修改代码，可以在开发环境独立的namespace下实时查看代码生效的结果，当时我为之震惊。因为之前想的各种流程，终究是需要开发者提交代码才能进行下一步测试的。
“创建一个环境，让开发者能够以最方便的形式进行开发，这是最直接地提高效率的方式。”
于是我开始寻找一种在openshift/k8s环境下的开源解决方案，测试了openshift-connector，虽然它跟TFS中的代码同步功能有些类似，但是一直没有测试成功，这个插件的关注者很少。后来找了redhat的朋友确认，他告诉我这个项目也许已经停止了。我继续寻找，但终究没有新的收获。
我跟一起参会的小伙伴说：“对我而言，也许这次大会的内容，都不及知道了这个工具。”
晚上回到家，我赶紧做测试。
- 第一个要验证的就是kubefwd对Openshift是否支持，毕竟我们开发测试环境，甚至有些项目的生产环境是在Openshift上。
- 第二个要验证的就是kubefwd是否支持在windows系统上运行，毕竟研发几乎都在windows上做开发。
测试结论
- kubefwd对Openshift完全支持
- kubefwd在windows系统上运行正常
我为什么会如此激动？或者说使用kubefwd带来什么样的改变？
- 开发人员无需在本地模拟一套完整的线上应用环境就能够测试与其他应用的集成效果
- 本地开发应用也能使用远端集群下的中间件，同时使用的配置与集群中的应用完成一样，无需专门做本地访问的配置管理
- 开发人员无需提交代码就能与其他应用集成，查看代码生效后的效果
- 开发环境变成了相对稳定的集成环境，每个开发者本地版本不会互相影响，降低多个应用同时开发的相互干扰
对于kubefwd如何使用，看它的帮助说明就够了，非常简单。
Usage:
kubefwd services [flags]
Aliases:
services, svcs, svc
Examples:
kubefwd svc -n the-project
kubefwd svc -n the-project -l env=dev,component=api
kubefwd svc -n default -l "app in (ws, api)"
kubefwd svc -n default -n the-project
kubefwd svc -n default -d internal.example.com
kubefwd svc -n the-project -x prod-cluster
Flags:
-x, --context strings specify a context to override the current context
-d, --domain string Append a pseudo domain name to generated host names.
--exitonfailure Exit(1) on failure. Useful for forcing a container restart.
-h, --help help for services
-c, --kubeconfig string absolute path to a kubectl config fil (default "/Users/cjimti/.kube/config")
-n, --namespace strings Specify a namespace. Specify multiple namespaces by duplicating this argument.
-l, --selector string Selector (label query) to filter on; supports '=', '==', and '!=' (e.g. -l key1=value1,key2=value2).
-v, --verbose Verbose output.
项目地址
kubefwd https://github.com/txn2/kubefwd
补充
小志还分享了个方便端口转发的应用，“oc port-forward的图形化应用”。地址：https://kube-forwarder.pixelpoint.io/
进一步发现了一个新的工具kt-connect ，一个可以让开发环境访问K8S集群下应用的工具，可以直接访问容器。
$ # 检查依赖环境
$ ktctl check
$ # 1. 安装sshuttle
$ sudo pip install sshuttle -i https://pypi.douban.com/simple
$ # openshift中，先创建一个project
$ oc new-project ktconnect
$ oc adm policy add-scc-to-user anyuid -z default #因为默认kt-connect-daemon需要root用户启动
$ sudo ktctl -n ktconnect connect
11:15AM INF Connect Start At 67595
11:15AM INF Client address 192.168.0.138
11:15AM INF deploy shadow deployment kt-connect-daemon-yuiaq in namespace ktconnect
11:15AM INF pod label: kt=kt-connect-daemon-yuiaq
11:15AM INF pod: kt-connect-daemon-yuiaq-665dd6bc55-tzb74 is running,but not ready
11:15AM INF pod: kt-connect-daemon-yuiaq-665dd6bc55-tzb74 is running,but not ready
11:15AM INF pod: kt-connect-daemon-yuiaq-665dd6bc55-tzb74 is running,but not ready
11:15AM INF pod: kt-connect-daemon-yuiaq-665dd6bc55-tzb74 is running,but not ready
11:15AM INF Shadow pod: kt-connect-daemon-yuiaq-665dd6bc55-tzb74 is ready.
11:15AM INF Fail to get pod cidr from node.Spec.PODCIDR, try to get with pod sample
Forwarding from 127.0.0.1:2222 -> 22
Forwarding from [::1]:2222 -> 22
11:16AM INF port-forward start at pid: 67596
Handling connection for 2222
Warning: Permanently added '[127.0.0.1]:2222' (ECDSA) to the list of known hosts.
client: Connected.
11:16AM INF vpn(sshuttle) start at pid: 67597
11:16AM INF KT proxy start successful