每到年终岁尾，历史上受到过中国文化影响的国家和地区都有评选当年年度汉字的传统，比如：2016年马来西亚年度汉字为“贪”，鬼子国日本年度汉字为“金”，中国台湾地区年度汉字为“苦”，而大陆地区的年度汉字据说是“规”。其实每个人心中都有一个自己的年度汉字，2016年，我个人的年度汉字为“变”。

一、离职

其实，这两年我求变的步伐一直没有停歇，只是今年迈出了实质性的一步。2016年4月末，就是在参加完GopherChina大会后，我就义无反顾的离开了工作10年多的老东家（也许很多人对于我的忠诚程度感觉很惊讶^0^），加盟了本地另外一家以IDC为基础、追求成为东北地区一流数据和基础设施服务商的初创企业。

我的新的直属领导是公司的技术VP，很牛逼的一个人，也是一名互联网老兵。据说他几乎以一人之力将公司IDC从无到有的建立起来（从商务采购谈判到IDC技术），并组建团队，打造公司云基础设施平台。当时我怀揣的极大的热情希望能在这样的一个新环境下，在公司的重点技术领域：云计算（基于OpenStack的公有云平台）、大数据技术、容器平台（与Rancher公司合作开发容器管理平台）等方向深入下去。但事情的发展往往是这样的套路：你越是期待的，结果却事与愿违。

当时正值公司刚刚确定了新的一年的几个重点战略方向，其中一个就是面向Goverment的智慧城市建设方向，我们戏称:”To G业务”。公司大老板希望我能以一个技术架构师的角色，对公司整个面向智慧城市的技术架构、产品和服务进行梳理，形成公司对应To G方向的核心产品套件和方法论。当时的我对于什么是智慧城市基本上是小白一个，无奈老板发话，只能硬着头皮上。

在后续若干个月的梳理过程中，我渐渐发现这个工作中技术绝对不是主要的因素，重要的是对智慧城市的深入理解。而智慧城市建设的纷繁芜杂，加上没有实战经验，驾驭起来又岂能是短短几个月的事情？输出的成果物我自己感觉都很苍白无力。那个阶段，我在各方面是备受煎熬：工作量是庞大的，老板要求也高，关键是还没有什么成就感。并且渐渐地我发现大老板似乎希望我能继续在smart city这个领域继续钻研下去，甚至成为专家型选手。这显然与我对自己的定位和规划不符，我没有成为智慧城市专家的愿望和热情，自觉也没有这方面的能力。于是在工作了大致五个月的时候，在输出了近六本成果物之后（没错，我这几个月的成果物就是一本本薄薄的书，如果你在市面上能有幸看到署有我的名字的关于智慧城市的著作，也不要惊讶哦^0^，不过看不到的可能性更大），我选择了离开。

这次跳槽从一般意义来说，也许是失败的。但个人觉得这几个月我还是有很多收获的。Hard模式让我个人也有了更快的成长，尤其是在内心抗压上。同时，在其他方面也有不少收获，这些收获不是在技术层面，而是在格局、眼界以及接触的人的圈子方面：由于角色的原因，接触到很多外部公司的相对级别较高的人，和他们一起交流，增长了许多见识。

二、蛰伏

离开的时候其实有几个机会，但是考虑到东北当前经济环境下的创业企业的情况，于是决定先回到老东家，不过这次换到了另外一个部门（以前的老领导负责的一个部门，这里感谢老领导收留^0^），我也从新回归技术兼部分技术管理，我把这个阶段称为蛰伏。一方面，将当前团队的产品打磨好，一方面等待下一次“变”的机会。

顺便简要说一下当前所做的事情。当前团队规模不大，5 dev + 1美工美女，致力于制作一个相对通用的互联网产品运营平台，一个类APaaS平台，与国内主流运营渠道能力对接（比如：微信等），简化商家在产品营销和运营时应用开发、部署和运维的门槛，为应用提供支持负载均衡和快速弹性伸缩的环境，以保障应用在业务波峰也可以正常运作。平台的底层采用的是Kubernetes，这也是10月份以来我为何发表大量有关容器和Kubernetes博文的原因。团队目前也在摸着石头过河，无论是对方向的把握还是对技术的探索。

团队采用了一些较新的小众流行的“技术栈“，包括：golang、vue.js 2.0等。目前团队还在招前后端开发，沈阳的朋友有意者可以留言联系。

三、小目标

优秀是一种习惯。反过来，不是所有习惯都能让你优秀，比如那些众所周知的“坏毛病”。

2017，从现在开始，我要改掉如下的一些“坏毛病”：

• 不吃垃圾食品，比如方便面、KFC等；
• 不躺着床上看书，除非是为了入眠^_^；
• 拖延症，或多或少还是有一点的。

总是告诉女儿：活到老学到老！作为爸爸，必须带头身体力行，2017自然不能忘记学习。除了当前工作涉及到的golang、docker、k8s的应用和深入之外，目前考虑到的可能学习和实践的方向还包括：

• AI：近两年大热的方向，特别是机器学习这一支。如果不跟上，就要落伍了。不过进入AI领地不是那么容易。要学的太多，而且很有难度。
• Blockly：在国外，尤其是主流欧美国家，“编程一小时”活动开展的如火如荼，无论成人还是未成年的儿童少年，对于编程的兴趣与日俱增。我相信这一趋势将来也必将在国内“蔓延”开来。而Google开源的Blockly作为很多编程网站开发编程activity的基础是值得学习、研究和实践的。

图：女儿在接受编程思维训练

四、自我寄语

新一年，风险与机遇并存。
但我心中那团火，永不熄！

此文为《使用Kubeadm安装Kubernetes》的第二部分。文章第一部分在这里可以看到。

五、weave network for pod

经过上面那么多次尝试，结果是令人扫兴的。Weave network似乎是最后一颗救命稻草了。有了前面的铺垫，这里就不详细列出各种命令的输出细节了。Weave network也有专门的官方文档用于指导如何与kubernetes集群集成，我们主要也是参考它。

1、安装weave network add-on

在kubeadm reset后，我们重新初始化了集群。接下来我们安装weave network add-on：

# kubectl apply -f https://git.io/weave-kube
daemonset "weave-net" created

前面无论是Flannel还是calico，在安装pod network add-on时至少都还是顺利的。不过在Weave network这次，我们遭遇“当头棒喝”:(:

# kubectl get pod --all-namespaces -o wide
NAMESPACE     NAME                                   READY     STATUS              RESTARTS   AGE       IP             NODE
kube-system   dummy-2088944543-4kxtk                 1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   etcd-iz25beglnhtz                      1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   kube-apiserver-iz25beglnhtz            1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   kube-controller-manager-iz25beglnhtz   1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   kube-discovery-1769846148-pzv8p        1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   kube-dns-2924299975-09dcb              0/4       ContainerCreating   0          42m       <none>         iz25beglnhtz
kube-system   kube-proxy-z465f                       1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   kube-scheduler-iz25beglnhtz            1/1       Running             0          42m       10.47.217.91   iz25beglnhtz
kube-system   weave-net-3wk9h                        0/2       CrashLoopBackOff    16         17m       10.47.217.91   iz25beglnhtz

安装后，weave-net pod提示:CrashLoopBackOff。追踪其Container log，得到如下错误信息：

# docker logs cde899efa0af
time="2016-12-28T08:25:29Z" level=info msg="Starting Weaveworks NPC 1.8.2"
time="2016-12-28T08:25:29Z" level=info msg="Serving /metrics on :6781"
Wed Dec 28 08:25:29 2016 <5> ulogd.c:843 building new pluginstance stack: 'log1:NFLOG,base1:BASE,pcap1:PCAP'
time="2016-12-28T08:25:29Z" level=fatal msg="ipset [destroy] failed: ipset v6.29: Set cannot be destroyed: it is in use by a kernel component\n: exit status 1"

2、解决ipset destroy错误

从上述的错误日志来看，似乎某些内核组件占用了一些IP资源，没有释放。ipset(administration tool for IP sets)这个工具以前从来没有接触过。在node上利用apt-get install 一个ipset工具，手工执行以下命令：

# ipset destroy
ipset v6.29: Set cannot be destroyed: it is in use by a kernel component

这个错误输出与container中的error log一模一样。试着用ipset看看哪些ip资源没有释放，这一招让我们看到了蛛丝马迹：

在minion node上执行：

# ipset list
Name: felix-calico-hosts-4
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 1048576
Size in memory: 224
References: 1
Members:
123.56.200.187
59.110.67.15

Name: felix-all-ipam-pools
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 1048576
Size in memory: 448
References: 1
Members:
192.168.0.0/16

Name: felix-masq-ipam-pools
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 1048576
Size in memory: 448
References: 1
Members:
192.168.0.0/16

我们看到了calico字样。原来是calico的“残留势力”在作祟啊。进一步我们发现calico创建的一个network device依旧存在于两个Node上：

47: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1
    link/ipip 0.0.0.0 brd 0.0.0.0
    inet 192.168.91.0/32 scope global tunl0
       valid_lft forever preferred_lft forever

我们试图删除它，但最终都以失败告终：

# ip tunnel show
tunl0: ip/ip  remote any  local any  ttl inherit  nopmtudisc

 #ip tunnel del tunl0
delete tunnel "tunl0" failed: Operation not permitted

无奈只能把它down掉：

#ip -f inet addr delete 192.168.91.0/32  dev tunl0

47: tunl0@NONE: <NOARP,UP,LOWER_UP> mtu 1440 qdisc noqueue state UNKNOWN group default qlen 1
    link/ipip 0.0.0.0 brd 0.0.0.0

# ifconfig tunl0 down

47: tunl0@NONE: <NOARP> mtu 1440 qdisc noqueue state DOWN group default qlen 1
    link/ipip 0.0.0.0 brd 0.0.0.0

但依旧无法删除它。我们通过ipset del命令将上面ipset占用的ip entry逐个删除掉（比如ipset del felix-calico-hosts-4 123.56.200.187）。但即便全部清空，ipset destroy依然失败。

无奈之下，决定重启一下两个Node试试。重启后，calico创建的这个tunnel居然消失了。

3、再遇路由冲突错误

重启ECS实例后，我们重新从头来创建cluster。不过在执行“kubectl apply -f https://git.io/weave-kube” 后我们发现weave-net pod依旧没有起来，这次的错误是“路有冲突”：

#docker logs 80383071f721
Network 10.32.0.0/12 overlaps with existing route 10.0.0.0/8 on host.

查看当前路由表：

netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         123.56.203.247  0.0.0.0         UG        0 0          0 eth1
10.0.0.0        10.47.223.247   255.0.0.0       UG        0 0          0 eth0
10.47.216.0     0.0.0.0         255.255.248.0   U         0 0          0 eth0
100.64.0.0      10.47.223.247   255.192.0.0     UG        0 0          0 eth0
123.56.200.0    0.0.0.0         255.255.252.0   U         0 0          0 eth1
172.16.0.0      10.47.223.247   255.240.0.0     UG        0 0          0 eth0
192.168.0.0     0.0.0.0         255.255.240.0   U         0 0          0 docker0

的确weave-net默认要使用的 10.32.0.0/12与 10.0.0.0/8 存在交集。对此，weave net官方是给出解决方案了的。

我们先将https://git.io/weave-kube对应的yaml文件下载到本地：weave-daemonset.yaml。修改该文件，为container增加IPALLOC_RANGE环境变量：

containers:
        - name: weave
          env:
            - name: IPALLOC_RANGE
              value: 172.30.0.0/16

更新weave net pod：

# kubectl delete -f weave-daemonset.yaml
daemonset "weave-net" deleted

# kubectl apply -f weave-daemonset.yaml
daemonset "weave-net" created

不过依然存在路有冲突。原来路由表里已经存在了一条这样的路由：

172.16.0.0      10.28.63.247    255.240.0.0     UG    0      0        0 eth0

这条路由应该没有什么用，也许是之前折腾时被某个network addon加进去的。于是用route命令将其删除：

# route del -net 172.16.0.0 netmask 255.240.0.0 gw 10.28.63.247

再次更新weave net pod并查看cluster status：

# kubectl delete -f weave-daemonset.yaml
daemonset "weave-net" deleted

# kubectl apply -f weave-daemonset.yaml
daemonset "weave-net" created

# kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                   READY     STATUS    RESTARTS   AGE       IP             NODE
kube-system   dummy-2088944543-93f4c                 1/1       Running   0          21m       10.47.217.91   iz25beglnhtz
kube-system   etcd-iz25beglnhtz                      1/1       Running   0          21m       10.47.217.91   iz25beglnhtz
kube-system   kube-apiserver-iz25beglnhtz            1/1       Running   0          20m       10.47.217.91   iz25beglnhtz
kube-system   kube-controller-manager-iz25beglnhtz   1/1       Running   0          21m       10.47.217.91   iz25beglnhtz
kube-system   kube-discovery-1769846148-wbc7h        1/1       Running   0          21m       10.47.217.91   iz25beglnhtz
kube-system   kube-dns-2924299975-206tg              4/4       Running   0          21m       172.30.0.2     iz25beglnhtz
kube-system   kube-proxy-n2xmf                       1/1       Running   0          21m       10.47.217.91   iz25beglnhtz
kube-system   kube-scheduler-iz25beglnhtz            1/1       Running   0          20m       10.47.217.91   iz25beglnhtz
kube-system   weave-net-h38k5                        2/2       Running   0          18s       10.47.217.91   iz25beglnhtz

这回weave-net pod running了。taint master node并且minion node join后cluster依旧是ok的：

# kubectl get pods --all-namespaces -o wide
NAMESPACE     NAME                                   READY     STATUS    RESTARTS   AGE       IP             NODE
kube-system   dummy-2088944543-93f4c                 1/1       Running   0          23m       10.47.217.91   iz25beglnhtz
kube-system   etcd-iz25beglnhtz                      1/1       Running   0          23m       10.47.217.91   iz25beglnhtz
kube-system   kube-apiserver-iz25beglnhtz            1/1       Running   0          22m       10.47.217.91   iz25beglnhtz
kube-system   kube-controller-manager-iz25beglnhtz   1/1       Running   0          23m       10.47.217.91   iz25beglnhtz
kube-system   kube-discovery-1769846148-wbc7h        1/1       Running   0          23m       10.47.217.91   iz25beglnhtz
kube-system   kube-dns-2924299975-206tg              4/4       Running   0          23m       172.30.0.2     iz25beglnhtz
kube-system   kube-proxy-377zh                       1/1       Running   0          8s        10.28.61.30    iz2ze39jeyizepdxhwqci6z
kube-system   kube-proxy-n2xmf                       1/1       Running   0          23m       10.47.217.91   iz25beglnhtz
kube-system   kube-scheduler-iz25beglnhtz            1/1       Running   0          22m       10.47.217.91   iz25beglnhtz
kube-system   weave-net-9tf1d                        2/2       Running   0          8s        10.28.61.30    iz2ze39jeyizepdxhwqci6z
kube-system   weave-net-h38k5                        2/2       Running   0          2m        10.47.217.91   iz25beglnhtz

4、测试weave net跨节点pod连通性

这回我们依旧启动my-nginx service，在任意一个节点curl localhost:30062，我们发现被调度到minion node上的my-nginx container也收到了request并成功回复response：

172.30.0.1 - - [30/Dec/2016:03:14:47 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.47.0" "-"

Weave net初步测试ok！

六、小结

虽然过程坎坷，但最终在Weave net的帮助下，我们还是初步调通了一个使用kubeadm安装的kubernetes cluster。后来我发现，在K8s官方博客中有一篇名为《Kubernetes: How we made Kubernetes insanely easy to install》的文章，其使用的pod network add-on也是weave network。

这是一个试验环境。后续我们还是要进一步探究如何用上Flannel的。同时，Kubernetes 1.5带来的诸多新特性，比如：Master HA等还需要进一步试验证明。

为了满足我们的production环境要求，之前实践的Ceph RBD为K8s提供存储卷、k8s从private registry拉取image、k8s集群的安全配置等还要在新集群上进一步试验，直到满足我们的要求。