Kubernetes 方法论：扩容和可靠性

[caicloud2015]

在第一篇文章里，我们探索了在 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 目前的角色和作用对于编排工具市场是十分有必要的。

（如果需要转载，请联系我们，尊重知识产权人人有责）