摘要：现在，我们来理解一下如何用来完成弹性扩容以及可靠性。结论容器已经不是一个新型的概念了，谷歌数十年来都将它大部分网络规模的工作负载都放在容器中运行。早在十年前就已经解决了谷歌面对的难题，这些正在影响着容器编排工具前进的道路。
在第一篇文章里，我们探索了在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目前的角色和作用对于编排工具市场是十分有必要的。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/32472.html
摘要：我们通过阿里云容器服务控制台创建一个集群，这里以创建台节点集群为例。全方位监控集群接入层的监控是必不可少的，您可以通过阿里云容器服务监控以及阿里云云监控对和进行全方位监控。 摘要： 在Kubernetes集群中，Ingress作为集群流量接入层，Ingress的高可靠性显得尤为重要，今天我们主要探讨如何部署一套高性能高可靠的Ingress接入层。 简介 在Kubernetes集群中，I...
摘要：平台上的微服务架构应用再来看一下我眼中的基于当前最流行的微服务架构的设计是什么样的，即我们平台上要运行的典型应用是什么样的。 showImg(https://segmentfault.com/img/remote/1460000010900878); 8月19日的数人云Container Meetup上，张龙老师做了《基于Kubernetes的PaaS平台的设计和思考》的精彩分享，分别...
摘要：从年以来，谷歌基于容器研发三个容器管理系统，分别是和。这篇论文由这三个容器集群管理系统长年开发维护的谷歌工程师和于近日发表，阐述了谷歌从到这个旅程中所获得的知识和经验教训。和完全是谷歌内部系统相比，是开源的。 从2000年以来，谷歌基于容器研发三个容器管理系统，分别是Borg、Omega和Kubernetes。这篇论文由这三个容器集群管理系统长年开发维护的谷歌工程师Brendan Bu...
摘要：下需要为每个单独进行采集配置采集日志目录，采集规则，存储目标等，不易维护。日志服务的日志架构实践我们提出基于阿里云日志服务的日志处理架构，用以补充社区的方案，来尝试解决场景下日志处理的一些细节体验问题。 摘要： 在Kubernetes服务化、日志处理实时化以及日志集中式存储趋势下，Kubernetes日志处理上也遇到的新挑战，包括：容器动态采集、大流量性能瓶颈、日志路由管理等问题。本文...
阅读 1460·2021-11-22 14:44
阅读 2842·2021-11-16 11:44
阅读 3205·2021-10-13 09:40
阅读 1979·2021-10-08 10:04
阅读 2362·2021-09-24 10:28
阅读 2908·2021-09-06 15:02
阅读 2956·2019-08-30 15:52
阅读 2391·2019-08-30 13:20
