小志：“kubefwd 本地开发的福音啊，本地环境直接连接 svc。”
当小志推荐这个工具的时候，我正在 Kubecon 大会的现场，听着 Kubernetes 近一年的各种成就和各种新特性。我无法看到微信另一头小志的表情，也许平静，也许跟我现在一样激动。
kubefwd，这是第一次听到这个工具，“本地环境直接连接 svc”，openshift 的 port-fowrward 命令就能做到，没什么也不起的吧。
我回复道：“openshift 的 port-forward，再加个自动更新本地 hosts 文件”。
小志发来了 kubefwd 请求流向图。

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 如何使用，看它的帮助说明就够了，非常简单。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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 集群下应用的工具，可以直接访问容器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
$ # 检查依赖环境
$ 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