支撑大规模公有云的Kubernetes改进与优化 (1)

2020-06-01 00:00:00 创建 调用 模块 调度 容器

今天飞机晚点了,本来一天一篇的,应该昨天写完的只好凌晨完成,只能先写一部分了。


Kubernetes是设计用来实施私有容器云的,然而容器作为公有云,同样需要一个管理平台,在Swarm,Mesos,Kubernetes中,基于Kubernetes已经逐渐成为容器编排的热主流的平台,网易基于Kubernetes实现了自己的容器公有云,在这个过程中,需要对Kubernetes进行一定的改进与优化。


架构如下:



网易开发了自己的一个容器服务平台,将OpenStack的IaaS层和Kubernetes容器层深度融合起来,从而实现一个完整的公有云体系。从图中可以看出,容器服务平台会调度OpenStack的计算服务Nova来创建KVM虚拟机,然后调用Cinder进行云盘的创建于挂载,调用Neturon进行网络的创建与连接,然后调用Kubernetes进行容器创建,还可以调用NLB挂载负载均衡器。


一、OpenStack架构很复杂


在容器平台之前,网易的IaaS层采用的是OpenStack架构。大家都说OpenStack太复杂了,如下图是OpenStack的一个架构图。



OpenStack主要包括以下的模块:

  • 安全认证模块keystone

  • 计算虚拟化模块Nova

  • 存储虚拟化模块Cinder

  • 网络虚拟化模块Neutron

  • 镜像管理模块Glance

  • 对象存储模块Swift


其中每一个模块都包含很多的子模块,大部分包括api模块,调度模块,以及具体干活的模块。


二、OpenStack创建虚拟机的流程很复杂


OpenStack创建一个虚拟机的流程非常复杂,这里简单概括一下其中的要点。


:AAA,也即我们常说的Authentication,Authorization,Account。


所谓的Authentication认证,就是验证我是不是我,Authorization鉴权就是审核,虽然我是我,但是我都没有这个权利做这个事情。


Authentication一般有两种方式,一个是对称加密的方式,也即用一个Token,客户端和服务端都用这个Token进行加密和解密,一个是非对称加密的方式,也即使用PKI,使用certificate的方式。


AWS也是有这两种方式。



另外Authorization,则常用的是Role based access control。


有用户,角色,租户的概念。


例如AWS里面有


第二: nova-api接受请求


在这里可以干两件事情,rate limit,调用我不能太频繁,quota,控制每个租户多能够创建多少资源。


第三:nova-scheduler进行调度


调度分两个过程,一个是Filtering,先将不符合要求的主机过滤掉,一个是weighting,剩下的根据主机的使用情况进行打分排名,选择一台机器。


第四:nova-compute真正干活的人接收到请求,调用libvirt创建虚拟机



第五:libvirt是真正的创建虚拟机的工具,先要下载虚拟机镜像



第六:libvirt开始定义KVM的启动参数


第七:libvirt开始给KVM创建网络设备


第八:libvirt启动KVM,这里一般会用到Cgroup对KVM的资源使用进行控制


第九:调用Cinder为虚拟机创建存储,后端一般用Ceph


想了解Kubernetes的人是不是看到这里已经烦了,不是讲kubernetes么?怎么讲了这么多OpenStack?


那就再来看张图,这个是aws创建虚拟机的知识图谱,是不是很多类似的概念?



很多学技术的发现技术发展实在太快,从虚拟化,到OpenStack,到Docker,到Kubernetes等,怎么学的过来,其实深入了解会发现,基础的技术非常像,包括接下来解析的Kubernetes。


三、Kubernetes的架构相对简单


很多人喜欢Docker,以及Docker平台,就在于Docker非常简单,没有OpenStack这么复杂的概念,很容易就能启动一个nginx的demo。


而作为容器管理平台,Kubernetes的架构也是比较简单的。



客户请求进来的时候,先进入api层,相当于nova-api,首先先要进行认证和鉴权(Authentication和Authorization),相当于keystone做的事情。


然后创建的对象会保存在etcd里面,如果是OpenStack则在数据库里面。


接着进行Scheduler,将对象调度到一台机器,相当于nova-scheduler要干的事情。


然后每台机器上的kubelet是真正干活的,发现自己被调度到了,需要在自己的机器上创建容器,相当于nova-compute。


kubelet创建容器的时候,先要下载容器镜像,nova-compute也要下载虚拟机的镜像。


nova-compute要调用docker的接口创建容器,相当于nova-compute调用的libvirt创建KVM,docker真正的隔离使用的是cgroup,KVM也要用cgroup,docker还用到了namespace,KVM的网络配置也会用到namespace。


docker创建好了,需要给docker配置网络,配置存储,libvirt也干了这些事情。


四、kubernetes创建pod和service的过程



  • 客户端调用api接口创建pod。

  • api-server将pod创建一个对象,保存在etcd里面。

  • scheduler不断通过api-server查看哪些pod需要调度,然后进行调度,将调度结果返回给api-server

  • api-server将scheduler的调度结果写入etcd中。

  • kubelet不断查看有没有能够调度到自己机器上的pod,有的话调用docker的接口创建容器。



  • 客户端调用api接口创建服务。

  • api-server创建service对象写入etcd。

  • controller不断扫描service对应的pod。

  • controller调用api-server创建对应的访问端点endpoint。

  • api-server将endpoint对象写入etcd。

  • proxy不断发现有没有可以放在自己上面的转发规则,如果有则创建socket监听端口,并且创建相应的iptables规则。


五、kubernetes没有什么?


Kubernetes看起来比OpenStack简单很多,其实缺少了很多的功能。

  • 没有完善租户管理模块,租户隔离性不好,是否需要一个类似keystone的服务?

  • 是不是需要镜像的管理,难道不需要一个类似glance的服务?

  • 镜像存储在哪里,是否需要一个对象存储的服务,类似swift?

  • kubernetes本身不管网络,需要通过插件进行,网络和SDN谁来管理?

  • kubernetes本身不管存储,需要通过插件进行,大部分的存储方案还是通过Ceph搞定。


然而,如果要做一个公有云,至少要搞定上面的部分,如果把这些都加上去,相当于基于kubernetes重造一个OpenStack了,为什么要重复造轮子呢?所以我们选择OpenStack和kubernetes深入融合的解决方案。


今天飞机晚点了,本来一天一篇的,应该昨天写完的只好凌晨完成。


接下来会解析OpenStack和kubernetes融合的方案。


其实作为公有云还有更多的问题:

  • 网络二次虚拟化的问题

  • 公网和浮动IP的问题

  • 一个Kubernetes集群还是多个Kubernetes集群?

  • Kubernetes集群如果做到很大规模?

  • 等等等等


也会在接下来这个系列的文章中详细阐述。


相关文章