Notice: Constant WP_DEBUG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 12

Notice: Constant WP_DEBUG_LOG already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 13

Notice: Constant WP_DEBUG_DISPLAY already defined in /var/www/html/wordpress/wp-content/plugins/changyan/sohuchangyan.php on line 14
【转载】Kubernetes 1.3 的现在和未来 – zoues

LOADING

Follow me

【转载】Kubernetes 1.3 的现在和未来
六月 15, 2017|DockerPaaS

【转载】Kubernetes 1.3 的现在和未来

【转载】Kubernetes 1.3 的现在和未来

本文主要讨论Kubernetes 1.3 版本的一些新功能以及对未来功能的展望。阅读本文需要读者对kubernetes的基本结构有所了解。

支持更多类型的应用


Init container

Init container是1.3中的alpha feature,目的是支持一类需要在启动Pod“普通容器”前,先进行Pod初始化的应用。执行该初始化任务的容器被成为“初始化容器”(init container)。例如,在启动应用之前,初始化数据库,或等待数据库启动等。下图是一个包含init container的Pod:

Kubernetes 1.3 的现在和未来

对于此类Pod,kubernetes的运行策略如下:

  • 初始化容器按顺序依次执行,即图中容器1->2

  • 若其中某一个初始化容器运行失败,则整个Pod失败

  • 当所有初始化容器运行成功,启动普通容器,即图中容器A和B

在alpha版本中使用init container需要用annotation,下图是来自k8s的一个例子(略有裁剪):


Kubernetes 1.3 的现在和未来

可以看到,我们在启动nginx普通容器之前,先用init container来获取index.html,之后访问nginx就会直接返回该文件。当init container功能稳定后,k8s会直接在pod.spec内加上initContainers字段,如下所示:

Kubernetes 1.3 的现在和未来

init container看起来是一个小功能,但是在实现上还是需要考虑不少问题,比如几个比较重要的点:

资源问题:当调度存在init container的Pod时,应该怎样计算所需要的资源?两个极端情况:如果对init container和regular container所需要的资源求和,那么当init container成功初始化Pod之后,就不会再使用所请求的资源,而系统认为在使用,会造成浪费;反之,不计算init container的资源又会导致系统不稳定(init container所使用的资源未被算入调度资源内)。目前的方法是取折中:由于初始化容器和普通容器不会同时运行,因此Pod的资源请求是两者中的最大值。对于初始化容器,由于他们是依次运行,因此选择其中最大值;对于普通容器,由于是同时运行,选择容器资源和。

Pod Status:目前,Pod有Pending, Running, Terminating等状态。对于有初始化容器的Pod,如果仍然使用Pending状态,则很难区分Pod当前在运行初始化容器还是普通容器。因此,理想情况下,我们需要增加一个类似于Initializing的状态。在alpha版本中暂时还未添加。

健康检查及可用性检查:有了init container之后,我们该如何检查容器的健康状态?alpha版本将两个检查都关闭了,但init container是会在node上实实在在运行的容器,理论上是需要进行检查的。对于可用性检查,关闭掉是一个可行的办法,因为init container的可用性其实就是当它运行结束的时候。对于健康检查,node需要知道某个Pod是否处在初始化阶段;如果处在初始化阶段,那么node就可以对init container进行健康检查。因此,kubernetes很有可能在添加类似Initializing的Pod状态之后,开启init container的健康检查。

围绕init container的问题还有很多,比如QoS,Pod的更新等等,其中不少都是有待解决的问题,这里就不一一展开。

PetSet

PetSet应该算是社区期待已久的功能,其目的是支持有状态和集群化的应用,目前也是alpha阶段。PetSet的应用场景很多,包括类似zookeeper、etcd之类的quorum leader election应用,类似Cassandra的Decentralized quorum等。PetSet中,每个Pod都有唯一的身份,分别包括:名字,网络和存储;并由新的组件PetSet Controller负责创建和维护。下面依次看一看kubernetes是如何维护Pod的唯一身份。

名字比较容易理解,当我们创建一个RC之后,kubernetes会创建指定副本数量的Pod,当使用kubectl获取Pod信息时,我们会得到如下信息:

Kubernetes 1.3 的现在和未来

其中,5个字符的后缀为kubernetes自动生成。当Pod重启,我们会得到不同的名字。对于PetSet来讲,Pod重启必须保证名字不变。因此,PetSet控制器会维护一个identityMap,每一个PetSet中的每个Pod都会有一个唯一名字,当Pod重启,PetSet控制器可以感知到是哪个Pod,然后通知API server创建新的同名Pod。目前的感知方法很简单,PetSet控制器维护的identityMap将Pod从0开始进行编号,然后同步的过程就像报数一样,哪个编号不在就重启哪个编号。 

Kubernetes 1.3 的现在和未来

此外,该编号还有另外一个作用,PetSet控制器通过编号来确保Pod启动顺序,只有0号Pod启动之后,才能启动1号Pod。

网络身份的维护主要通过稳定的hostname和domain name来维护,他们通过PetSet的配置文件指定。例如,下图是一个PetSet的Yaml文件(有裁剪),其中metadata.name指定了Pod的hostname前缀(后缀即前面提到的从0开始的索引),spec.ServiceName指定了domain name。

Kubernetes 1.3 的现在和未来

通过上面的Yaml文件创建出来两个Pod:web-0和web-1。其完整的域名为web-0.nginx.default.svc.cluster.local,其中web-0为hostname,nginx为Yaml中指定的domain name,剩下的部分与普通service无异。当创建请求被下发到节点上时,kubelet会通过container runtime设置UTS namespace,如下图所示(省略了部分组件如apiserver)。

Kubernetes 1.3 的现在和未来

此时,hostname已经在容器层面设置完成,剩下还需要为hostname增加集群层面的解析,以及添加domain name的解析,这部分工作理所当然就交给了kube dns。了解Kubernetes的读者应该知道,要添加解析,我们需要创建service;同理,这里也需要为PetSet创建service。不同的是,普通的service默认后端的Pod是可替换的,并采用诸如roundrobin,client ip的方式选择后端的Pod,这里,由于每个Pod都是一个Pet,我们需要定位每一个Pod,因此,我们创建的service必须要能满足这个要求。在PetSet中,利用了kubernetes headless service。Headless service不会分配cluster IP来load balance后端的Pod,但会在集群DNS服务器中添加记录:创建者需要自己去利用这些记录。下图是我们需要创建的headless service,注意其中的clusterIP被设置为None,表明这是一个headless service。

Kubernetes 1.3 的现在和未来

Kube dns进行一番处理之后,会生成如下的记录:

Kubernetes 1.3 的现在和未来

可以看到,访问web-0.nginx.default.svc.cluster.local会返回pod IP,访问nginx.default.svc.cluster.local会返回所有Pet中的pods IP。一个常见的方式是通过访问domain的方式来获取所有的peers,然后依次和单独的Pod通信。

存储身份这块采用的是PV/PVC实现,当我们创建PetSet时,需要指定分配给Pet的数据卷,如下图:

Kubernetes 1.3 的现在和未来

这里,volumeClaimTemplates指定每个Pet需要的存储资源。注意目前所有Pet都得到相同大小和类型的数据卷。当PetSet控制器拿到请求时,会为每一个Pet创建PVC,然后将每个Pet和对应的PVC联系起来:

Kubernetes 1.3 的现在和未来

之后的PetSet只需要确保每个Pet都与相对应的PVC绑定在一起即可,其他工作,类似于创建数据卷,挂载等工作,都交给其他组件。

通过名字,网络,存储,PetSet能够cover大多数的案例。


但是,目前还存在很多需要完善的地方,感兴趣的读者可以参考https://github.com/kubernetes/kubernetes/issues/28718

Scheduled Job

Scheduled Job本质上是集群cron,类似mesos chronos,采用标准的cron语法。遗憾的是在1.3中还并未达到发布的标准。Scheduled Job其实在很早就提出来过,但当时kubernetes的重点还在API层面,并且即使有很大需求,也计划在Job(1.2GA)之后实现。当scheduled job在之后的版本发布之后,用户可以用一条简单的命令在kubernetes上运行Job,

例如:

kubectl run cleanup -image=cleanup –runAt=”0 1 0 0 *” – /scripts/cleanup.sh

一些关于scheduled job的更新可以参考:https://github.com/kubernetes/kubernetes/pull/25595

Disruption Budget

Disruption Budget的提出是为了向Pod提供一个反馈机制,确保应用不会被集群自身的变动而受影响。例如,当集群需要进行重调度时,应用可以通过Disruption Budget来说明Pod能不能被迁移。Disruption Budget只负责集群自身发起的变动,不负责突发事件比如节点突然掉线,或者应用本身的问题比如不断重启的变动。Disruption Budget同样没有在1.3中发布。

 

与kubernetes大多数资源类似,我们需要通过Yaml文件创建一个PodDisruptionBudget资源,例如,下图所示的Disruption Budget选中了所有带有app:nginx标签的pod,并且要求至少有3个Pod在同时运行。

Kubernetes 1.3 的现在和未来

Controller manager内有一个新的组件DisruptionBudget Controller,来负责维护所有Budget的状态,例如上图中的status表明当前共有4个健康的Pod(currentHealthy),应用要求至少有3个(desiredHealthy),总共有5个Pod(expectedPods)。为了维护这个状态,DisruptionBudget Controller会遍历所有的Budget和所有的Pod。有了Budget的状态,需要改变Pod状态的组件都要先查询之。若其操作导致最小可用数低于应用要求,则操作会被拒绝。

Disruption Budget与QoS联系很紧密。例如,如果一个QoS level很低的应用有着非常严格的Disruption Budget,系统应该如何处理?目前,kubernetes还没有严格的处理这个问题,一个可行的办法是对Disruption Budget做优先级处理,确保高优先级的应用拥有高优先级的Disruption Budget;此外,Disruption Budget可以加入Quota系统,高优先级的应用可以获得更多Disruption Budget Quota。


关于Disruption Budget的讨论可以参考:https://github.com/kubernetes/kubernetes/issues/12611

支持更好的集群管理


Cascading Deletion

在kubernetes 1.2之前,删除控制单元都不会删除底层的资源。例如,通过API删除RC之后,其管理的Pod不会被删除(使用kubectl可以删除,但kubectl里面有reaper逻辑,会依次删除底层的所有Pod,本质上是客户端逻辑)。另外一个例子,当删除下图中的Deployment时,ReplicaSet不会被自动删除,当然,Pod也不会被回收。

Kubernetes 1.3 的现在和未来

Cascading deletion指的就是在删除控制单元后,将被管理单元也同时回收。但是,kubernetes 1.3中的cascading deletion并不是简单地讲kubectl中的逻辑复制到server端,而是做了更高层次的工作:垃圾回收。简单来讲,garbagecollector controller维护了几乎所有集群资源的列表,并接收资源修改的事件。controller根据事件类型更新资源关系图,并将受影响的资源放入Dirty Queue或者Orphan Queue中。


具体实现可以参考官方文档和garbagecollector controller实现:https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/garbage-collection.md 

Kubernetes 1.3 的现在和未来

Node eviction

Node/kubelet eviction指的是在节点将要超负荷之前,提前将Pod剔除出去的过程,主要是为了内存和磁盘资源。在kubernetes 1.3之前,kubelet不会“提前”感知节点的负荷,只会对已知的问题进行处理。当内存吃紧时,kubernetes依靠内核OOM killer;磁盘方面则定期对image和container进行垃圾回收。但是,这种方式有局限性,OOM killer本身需要消耗一定资源,并且时间上有不确定性;回收容器和镜像不能处理容器写日志的问题:如果应用不断写日志,则会消耗掉所有磁盘,但不会被kubelet处理。

Node eviction通过配置kubelet解决了以上问题。当启动kubelet时,我们通过指定memory.available, nodefs.available, nodefs.inodesFree等参数来确保节点稳定工作。例如,memory.available < 200Mi 表示当内存少于200Mi时,kubelet需要开始移除Pod(可以配置为立即移除或者延迟移除,即hard vs soft)。kubernetes 1.3中,node eviction的特性是opt-in,默认关闭,可以通过配置kubelet打开相关功能。

尽管node eviction是kubelet层面采取的措施,我们也必须考虑与整个集群的交互关系。其中最重要的一点是如何将这个问题反馈给scheduler,不然被剔除的Pod很有可能会被重新调度回来。为此,kubernetes添加了新的node condition:MemoryPressure, DiskPressure。当节点的状态包含其中任意一种时,调度器会避免往该节点调度新的Pod。这里还有另外一个问题,即如果节点的资源使用刚好在阈值附近,那么节点的状态可能会在Pressure和Not Pressure之间抖动。防抖动的方法有很多种,例如平滑滤波,即将历史数据也考虑在内,加权求值。k8s目前采用较为简单的方法:即如果节点处于Pressure状态,为了转变成Not Pressure状态,资源使用情况必须低于阈值一段时间(默认5分钟)。这种方法会导致false alarm,比如,若一个应用每隔一段时间请求一块内存,之后很快释放掉,那么可能会导致节点一直处于Pressure状态。但大多数情况下,该方法能处理抖动的情况。

说到eviction pod,那么另外一个不得不考虑的问题就是找一个倒霉的Pod。这里kubernetes定义了不少规则,总结下来主要是两点:1. 根据QoS来判断,QoS低的应用先考虑;2. 根据使用量判断,使用量与总请求量比例大的Pod优先考虑。


具体细节可以参考:https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/kubelet-eviction.md

Network Policy

Network policy的目的是提供Pod之间的隔离,用户可以定义任意Pod之间的通信规则,粒度为端口。例如,下图的规则可以解释成:拥有标签“db”的Pod,只能被拥有标签“frontend”的Pod访问,且只能访问tcp端口6379。

Kubernetes 1.3 的现在和未来

Network policy目前处于beta版本,并且只是API。也就是说,kubernetes不会真正实现网络隔离:如果我们将上述Yaml文件提交到kubernetes,并不会有任何反馈,kubernetes只是保存了这个Policy内容。真正实现policy功能需要其他组件,比如calico实现了一个controller,会读取用户创建的Policy来实现隔离,可以参考:https://github.com/projectcalico/k8s-policy/。


关于Network Policy的细节,可以参考:https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/network-policy.md

Federation

Federation cluster翻译成中文叫“联合集群”,即将多个kubernetes集群联合成一个整体,并且不改变原始kubernetes集群的工作方式。根据kubernetes官方设计文档,federation的设计目的主要是满足服务高可用,混合云等需求。在1.3版本之前,kubernetes实现了federation-lite,即一个集群中的机器可以来自于相同cloud的不同zone;1.3版本中,federation-full的支持已经是beta版本,即每个集群来自不同的cloud(或相同)。

Federation的核心组件主要是federation-apiserver和federation-controller-manager,以Pod形式运行在其中一个集群中。如下图所示,外部请求直接与Federation Control Panel通信,由Federation分析请求并发送至kubernetes集群。 

Kubernetes 1.3 的现在和未来

在应用层面,Federation目前支持federated services,即一个应用跨多个集群的访问。


具体细节可以参考:http://blog.kubernetes.io/2016/07/cross-cluster-services.html 以及http://kubernetes.io/docs/admin/federation/

结束语

kubernetes 1.3带来了非常多的特性,这里只cover了其中一部分。在安全方面,kubernetes已经支持RBAC,实现更好的权限控制;PodSecurityContext也进入beta版本,支持运行部分需要特权的Pod等。在性能方面,由于protocol buffere serialization的引入,是性能提高了几倍,并且正在酝酿中的etcd3会将性能提升更进一步。相信之后的版本会带给我们更多的惊喜。

作者简介:邓德源,才云 CTO,曾为美国谷歌(Google)集群管理组核心成员(Cluster Management Team)。在谷歌期间作为核心成员参加了开发基于容器集群的谷歌开源项目(Kubernetes)。


想了解更多内容,请扫描微信 知识库


Kubernetes 1.3 的现在和未来

no comments
Share