kubernetes容器化方案验证报告
1、服务器列表
Confluence5.10.8 wiki迁移到简书
图片.png
对于有状态的公共集群，采用虚拟机方式部署。（这些服务也可以容器化部署，但目前技术储备不足，一旦出问题排查麻烦）
图片.png
2、相关信息
kubernetes版本：v1.12.2
docker版本：17.03.1-ce
kubernetes-dashboard：https://10.66.221.92:30443/
traefik负载均衡：http://10.66.221.92:8081/
registry私库地址：http://10.66.221.138:5500/
镜像列表：http://10.66.221.138:5500/v2/_catalog
镜像标签列表：http://10.66.221.138:5500/v2/{镜像路径}/tags/list
dashboard-token令牌：
eyJhbGciOiJSUzI1NiIsImtpZCI6IiJ9.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJhZG1pbi10b2tlbi1nMjl0NyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50Lm5hbWUiOiJhZG1pbiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjIwMGQ0OGNjLWZjM2EtMTFlOC1hYjExLTAwNTA1Njg3MDYxMCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDprdWJlLXN5c3RlbTphZG1pbiJ9.PMEbhFmJwg9Zj62XzrA1hcqHe2CGpqk9Ne6gX8J6B-iMXbHhHtrMLrxA2o6e68HQ2_DToI-cRsMuSwzb1iugslPmJIvgHgJ0kj3yW-tR6NZ4Azi8ua8LMLVg8a2gUCiumNezlmcp4zqmay1leoxaNvrNeLOqmrBoRNkyvMo_tOLYgK28iJrpPeF1OoiVnJN7fghu895ZqWs_0maAd891HiIjArW1_bt30SVy5tU2I6yiCwqiAztLSrM9Jd24EG8jxfov7gCN5Lsp80E-UtRHADQt8H55r0jAnKxxzdfy2NfeDcUteYXiNQtyIPpqgigC-rJHWPbdZw9SEq4X-dgdUQ
3、技术选型和验证
3.1、docker容器管理平台选型
图片.png
图片.png
根据上面2个表格得出:
swarm ：上手最简单，但是目前还不够完善，社区也不活跃， 离生产环境有一定距离。
mesos： 上手复杂，社区也不活跃，超大集群可考虑。
kubernetes：上手较为复杂，有各种成熟方案，但是社区活跃度高， Kubernetes于2017底在容器编排上胜出，目前大量公司都在使用。
rancher：2.0简化了kubernetes部署，但是我在实际使用中第一次没部署成功，资料很少，社区活跃度不高。
综上对比， 我选择了kubernetes作为容器编排工具，并使用官方kubeadm部署方式。
3.2、业务应用部署
只需要准备好k8s deployment等配置文件，就可通过dashboard管理平台执行完成应用部署。
3.3、服务动态扩缩
可直接在dashboard管理平台操作，随时扩容应用运行实例个数。
3.4、服务容器镜像构建方案
3.4.1、k8s镜像私库方式
选择docker官方registry镜像部署。
docker run -d -p 5000:5000 -v /opt/data/registry:/var/lib/registry registry
k8s集群Node节点需要加入镜像白名单：
vim /etc/docker/daemon.json
图片.png
3.4.2、打包发布镜像
图片.png
选择灵雀云平台用于代码打包和镜像构建
- 保持与公司开发流程和构建镜像一致。
- 灵雀云也是基于kubenetes二次开发，部署方式一致，现有容器化的服务不需要特别改造。
- 考虑到本地化环境网络隔离问题，我们交付给本地化部署的是镜像文件。
过程步骤：
开发人员提交代码-->通过灵雀云平台构建镜像-->人工导出服务镜像文件-->人工将镜像导入到本地环境镜像私库
图片.png
3.4.2、k8s部署服务
一个业务服务部署只需要编写Deployment，Service，Ingress 3个yaml配置文件， 通过kubernetes-dashboard管理平台执行即可完成部署。
|
<pre style="margin: 0px; tab-size: 4; white-space: pre-wrap;">apiVersion: apps/v1beta2
kind: Deployment
metadata:
labels:
app: deployment-default-hello-world
name: deployment-tutum-hello-world
namespace: cloud
spec:
selector:
matchLabels:
app: deployment-default-hello-world
replicas: 1
template:
metadata:
labels:
app: deployment-default-hello-world
spec:
containers:
- image: tutum/hello-world
name: tutum-hello-world
ports:
- containerPort: 80
name: web
apiVersion: v1
kind: Service
metadata:
name: service-tutum-hello-world
labels:
app: deployment-default-hello-world
namespace: cloud
spec:
type: NodePort
ports:
- port: 80
targetPort: 80
nodePort: 31000
selector:
app: deployment-default-hello-world
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: traefik-web-ui
namespace: cloud
spec:
rules:
- host: tutum-hello-world.local
http:
paths:- backend:
serviceName: service-tutum-hello-world
servicePort: 80
- backend:
</pre>
|
3.5、负载均衡方案
图片.png
最终选用的是Traefik。
3.5.1、traefik 七层网络负载
图片.png
3.5.1、负载均衡高可用
可指定多个k8s node节点作为负载均衡节点，以DaemonSet方式部署。通过keepalived做热备对外提供VIP。
图片.png
3.6、容器服务日志方案
图片.png
目前灵雀云已做好的基础镜像采用的是第一种方式， 所以保持一致。
3.7、容器网络互通方案:
当前k8s部署采用默认的flannel网络方案，解决了跨主机间容器直接使用自身 IP 进行通信的问题，会对node节点会分配为每一个node节点分配一个唯一的ip/255.255.0.0 网段。（ip网段可以指定）
图片.png
3.7.1、网络互通测试
图片.png
测试结果
图片.png
3.7.2、容器网络互通方案
上述k8s集群外的节点无法访问内部容器网络。
导致的问题：dobbox提供接口的服务部署在容器，dobbox消费接口的服务部署在k8s集群外则调用接口失败。
我们使用 Flannel 作为 k8s 网络组件，Flannel 的特点是每个宿主机上的容器网段是固定的，部署完不会再变，那我们只需要在宿主机的网关设备上添加静态路由即可。
图片.png
（由于是同一个网关，且我没有网关权限，所以测试时我直接在（k8s集群外的服务器）10.66.221.138上添加路由进行测试）。
在10.66.221.138服务器执行以下命令：
ip route add 10.244.1.0/24 via 10.66.221.92
ip route add 10.244.2.0/24 via 10.66.221.93
执行route -n查看：
图片.png
k8s容器我已经提前部署了tutum-hello-world.local，他有3个容器实例。如图：
图片.png
执行以下命令，成功访问k8s集群中tutum-hello-world容器提供的80端口服务。（Node1的容器，Node2的容器）
curl 10.244.1.93:80
curl 10.244.2.5:80
图片.png
3.7.1、执行互通方案后测试互通性
图片.png
4、demo示例服务测试
4.1、测试方案
开发2个测试的应用， 如下表。（以3.0常用应用场景选择测试功能范围）
图片.png
4.2、demo服务测试结果
图片.png
5、性能测试
容器化技术会带来一定网络性能损耗，建议由测试以实际本地化服务器资源进行性能测试。（研发自测的话推荐Locust测试）
6、监控
采用dashboard管理平台监控，能看到节点、Pod的监控（Pod的CPU、内存、网络、磁盘等监控）、kubernetes的各个组件状态。
其他开源监控（prometheus等）如有需求，可单独调研。
7、结论
k8s方式容器化部署测试已通过，能满足3.0本地化服务应用场景，以及各种自动扩容，资源管理，日志收集，复杂网络互通等多种实际场景。
对于网络网段需要规划，避免网段重复。
