随着业务需求的快速发展,“动态”特性仿佛就成了大发5分排列5技术 解决业务刚需的必要条件。

3年前的spring cloud通过注册中心eureka解决了大发5分排列5服务 动态上下线、注册和续约的问题;

近一年,kubernetes则通过其强大的基础对象和平台的动态特性,从运维侧对大发5分排列5产品 的稳定性和扩展性保驾护航!

1.容器化究竟解决了什么问题

作为资深的大发5分排列5互联网 从业者,大发5分排列5我 对于运维人员一直强调的一点就是:

运维人员必须投身到发布环节中,充分了解业务,才能产生价值!

这里的业务,大发5分排列5我 把它分为两块来看:

1>首先,大发5分排列5你 需要去充分了解所辖项目组的业务代码和研发人员共同owner。而不是说,大发5分排列5我 交付给大发5分排列5你 大发5分排列5服务 器,后面的事情大发5分排列5我 就不管了,这是万万不可的:

一方面,大发5分排列5你 完全脱离了业务。

大发5分排列5你 并不知道这个项目组的业务今天上了什么新功能、这个新功能如何回归、如何测试,新代码的配置存在于哪个git仓库的哪个项目的哪个目录中,对其配置的正确性大发5分排列5你 也就无从检查了?(如运维类配置、业务字段的配置等等)

另一方面,对于线上问题的定位会很欠缺。

比如当大发5分排列5大发5分排列5我 们 的一个pc端应用的大发5分排列5搜索 功能出现问题时,大发5分排列5你 能否第一时间怀疑到相关的微大发5分排列5服务 程序?而不是等着研发人员走过来和大发5分排列5你 说:“帮大发5分排列5我 查看一下某几台上面xx程序的日志呢?”

2>其次,就是需要充分了解整个上线流程。比如:大版本如何定义、hotfix流程怎么走、rollback流程怎么走、如何定义紧急两字、什么时候做Code Freeze(代码冻结)、谁来做?等等

只有当大发5分排列5你 切身地投入其中,才能发现、提出和改善业务流转中的问题,这样大发5分排列5你 的价值也就得以体现!

现在大发5分排列5大发5分排列5我 们 再来谈一下上线流程问题

传统架构中,大发5分排列5大发5分排列5我 们 都会碰到一个头疼的问题:

那就是测试环境部署成功、生产环境部署的时候却连连报错?为什么?

那就是环境差异性带来的问题!应用程序和其依赖被没有很好的打包、组装在一起!这也就是容器化解决的根本难题。

2.Kubernetes架构

如果把容器化比作集装箱,其作用是打包程序所依赖的相关插件和库文件;

那么,Kubernetes就好比是一个设施丰富且完善的船坞码头,它复杂管理这些集装箱,如何“堆放”才能更合理、更有效,这就是它需要考虑和做的事情。

接下来,大发5分排列5大发5分排列5我 们 直接来看一下Kubernetes的部署架构

架构图-1
首先引入大家眼帘的是一张大发5分排列5关于 Kubernetes的组件架构图,这是大发5分排列5我 从官网摘录下来的。

如图,大发5分排列5大发5分排列5我 们 可以粗略观察发现,Kubernetes分为Master端和Nodes端,以及一个外接的cloud端。

他们工作逻辑和内部组件,大发5分排列5你 可以参考下面的文字描述:

1.Master节点

又称为控制平面:control plane

包括kube-apiserverkube-schedulerkube-controller-manageretcd四个组件。

①kube-apiserver:

是一个将kubernetes控制平面中的API暴露出来的API大发5分排列5服务 ,用于接收用户端的操作请求,这大发5分排列5服务 是kubernetes控制平面的前端。

它是无状态应用,用户可以运行多个kube-apiserver组件的实例,用于平衡实例的请求流量。

②kube-scheduler:

用于watch监听apiserver的资源变动(增删改查),并调度至合适的后端node节点,从而来创建pod资源。

③kube-controller-manager:

每个控制器都是独立的二进制进程,包括:Node Controller、Replication Controller、Endpoints Controller和Service Account & Token Controllers。

④etcd:

高可用、KV结构的kubernetes的后端数据存储组件。

文档补充:备份方案>>( http://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster )和官方文档 ( http://etcd.io/docs/v3.4.0/ )

⑤cloud-controller-manager:

kubernetes与云厂商提供的大发5分排列5服务 能力对接的关键组件。
又称为kubernetes cloudprovider

2.Node节点

又称为数据平面:data plane

包括kubeletkube-proxyContainer Runtime三个组件。

①kubelet:

运行在集群每个节点的客户端,需要确保相关容器运行在pod中;通过PodSpecs标签,描述容器的运行状态。

②kube-proxy:

是一个运行在集群每个节点的网络代理组件。

③Container Runtime:

支持运行容器底层环境的大发5分排列5软件 ;
支持: Docker, containerd, cri-o, rktlet

3.cloud端

①cloud:

作为集群外部的附加能力,通过与cloud-controller-manager组件对接,扩展kuberntes集群于云上动态扩展的特性

4.Addons(附加组件)

使用Kubernetes resources增加集群功能,如DNSWeb UI (Dashboard)Container Resource MonitoringCluster-level Logging等等

可用Addons请参考:附件大全(http://kubernetes.io/docs/concepts/cluster-administration/addons/)

3.工作流程概述

Master:

用户通过(APIWebUICLI)向APIserver发送请求,kube-scheduler组件监听APIserver的资源变动,同时从Node节点中选取最合适的Node节点开始调度,并把调度结果保存至Etcd中。

Node:

kubelet也会监听APIserver的资源变动,并在符合的Node上通过kubelet调用相关的docker引擎进行后续打包和构建操作。