Kubernetes方法论：扩容和可靠性

在第一篇文章里，我们探索了在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将r 加粗文字 equest退信到正确的目的地。

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目前的角色和作用对于编排工具市场是十分有必要的。

http://www.tuicool.com/articles/jABz2yV

https://www.oschina.net/question/2657833_2189615