Kubernetes 方法论:扩容和可靠性

2016-06-08

在第一篇文章里,我们探索了在Kubernetes中pods和services的概念。现在,我们来理解一下如何用RC来完成弹性扩容以及可靠性。我们也会讨论一下如何将持久化带入布置在Kubernetes上的云本地应用程序。


RC:弹性扩容和管理微服务

如果pods是一个单元,部署和services是抽象层,那么谁来追踪pods的健康状况呢?

于是RC就这样出场了。


在pods被部署之后,他们需要扩容,需要被追踪。RC定义文件有pods数量的基线配置,这些pods在任何给定的点都是可得的。Kubernetes确保了需要的配置选项一直通过追踪pods数量来维护。它会杀死一些pods,又或者是创建一些来满足基线配置。


RC可以追踪pods的健康状况。如果一个pod变得难得到的,那么它就会被杀死,然后一些新的pod会被创建。因为一个RC实质上就是继承了pod的定义,YAML或者JSON清单可能包含重启策略,容器调查和健康检查端点的属性。


Kubernetes支持基于CPU利用率的pod自动弹性扩容,跟EC2自动扩容或者GCE自动扩容有些相似。在运行的时候,RC可以被操作来自动扩容pods,基于特定的CPU利用率阈值。pods的数量的最大值和最小值也可以在同样的命令下规定。


平网络:秘密武器

网络也是容器化过程中面临的复杂挑战之一。将一个容器暴露到外部世界的唯一方法就是通过主机的端口转发。但是扩容容器的时候就会变得复杂。Kubernetes不是将网络配置和集成留给管理员来做,而是自带一个网络模型,这个网络模型十分易于使用。


每个节点,service,pod和容器都有一个IP地址。节点的IP地址由物理路由器分配;结合分配的端口,它会变成端点来访问面向服务。虽然不是可路由的,但是Kubernetes服务也是可以获取IP地址的。所有的通信都是在没有NAT层的基础上产生的,使得网络平面化,透明化。

这个模型会带来一些好处:

  • 所有的容器不需要NAT也可以互相通信
  • 所有的节点不需要NAT也可以跟所有的pods和集群中的容器通信
  • 每个容器跟其他容器一样看到的都是相同的IP地址


关于通过RS来扩容pods最好的一点就是,端口映射是由Kubernetes处理的。所有属于service的pods都是通过相同的端口暴露到每个节点上的。即使没有pod在特定的节点上调度,request也会自动转发到合适的节点。


这个神奇的功能就是通过kube-proxy,iptables和etcd这些网络代理的结合来实现的。当前集群的状态就是用etcd来维护的,这也就意味着在运行的时候通过kube-proxy查询。通过操作在每个节点上的iptables,kube-proxy将request退信到正确的目的地。


Kube-proxy同样也处理services的基础负载均衡。Service端点也是用Docker links通过环境变量来管理。这些变量分解到端口,端口通过service暴露到外面。Kubernetes1.1包括了一个来使用本地iptables的选项,这个选项会带来80%的延迟。这个设计消除了CPU开销,因此提升了效率,也提升了可拓展性。


持久性:将状态带到容器

容器是短暂的。当他们从一个主机转移到另一个主机的时候,他们不包含状态。对于产品负载,持久是一个必须条件。任意有用的应用程序都有一个数据库在背后支持它。


默认设置下,pods也是短暂的。他们每次复活的时候都从空白状态开始。设置在同一个pod中运行的容器所共享的数据卷也是可以的。由emptyDir monilker确认,这个与Docker数据卷有点相似,在这里主机文件系统在容器内被暴露为一个目录。emptyDir数据卷追踪pods的生命周期。当pod 被删除的时候,数据卷也会被删除掉。因为这些数据卷只符合主机的,所以他们在其它节点上不可用。

为了在pods上带来持久性数据,不管他们在哪个节点上被调度,Kubernetes都支持PV和PVC requests。PVC和PV共享关系,就如同pod和节点一样。当一个pod被创建的时候,它可以通过claim联系到特定数据卷。PV可以基于各种各样的插件,比如GCE持久性硬盘,亚马逊弹性快存储(EBS),网络文件系统(NFS),小型计算机系统接口(ISCSI),GlusterFS和RBD。


设置持久化的工作流包括配置底层文件系统或者云数据卷,创建持久性数据卷,最后,创建claim来将pod跟数据卷关联起来。这个解耦方法可以将pod和数据卷完全分离,或者pod不需要知道确切的文件系统或者支持它的持久性引擎。有些文件系统,比如GlusterFS,也可以被容器化,使得配置更加容易,便捷。


结论

容器已经不是一个新型的概念了,谷歌数十年来都将它大部分网络规模的工作负载都放在容器中运行。他们在这个过程中吸取教训,并将这些教训融入Kubernetes的建设中,这些经验教训也可以被移植到其他的编排平台中,也可以移植到其它的编排工具中。Kubernetes早在十年前就已经解决了谷歌SRE面对的难题,这些正在影响着容器编排工具前进的道路。


最重要的是,Kubernetes在容器生态圈已经是一个焦点,对于其它相关服务,它的存在就好像是一个有价值的开源平台。理解Kubernetes目前的角色和作用对于编排工具市场是十分有必要的。

点击体验,开启谷歌级数字化之旅
立即体验
立即咨询