近日，OpenStack基金会宣布了第九次用户调查结果。 OpenStack用户调查是迄今为止全球

4月22日，由K8S技术社区、Linux中国联合主办的K8S GeekGathering 2017吸引了国内容器领域关注者100+人到场参与，以下是IBM 软件架构师马达的演讲实录整理：

IBM 软件架构师马达

大家好，我今天分享的主题是资源管理和资源调度，我所在的是IBM，CSL，我们做分布式资源管理，分布式资源调度，从大概九几年就做了，国际的投行，包括一些产品，迪斯尼做模拟的时候也用了我们的产品，我们主要做的是在资源管理和资源调度这块，我们会把好多的数据用在里面，主要在K8S流程这块做得多一些。

1

Kubernetes总体架构

这是目录，K8S的主体架构，这是因为整体架构跟我们后面看到的调度，包括和cmecsos的比较。1.7里面会涉及到一些，包括之前百度同事讲的如何多个资源共享，具体的还没有定，具体的可能是DIF，写出来就行了，我们也希望各个厂商基于我们定好的去做不同的调度，看一下总体架构，想说的是K8S有这么多的，可以发现，controller manage，他们整体围绕kube apiserver，对不同的操作，kube apiserver，所有的东西都把数据写在ITC里面，跟我们原来做的产品是不一样的，包括cmecsos也是，对外拿不到空间和数据，我们自己产品做的时候也是拿到。这里看到K8S通过源数据驱动来做，这个带来的好处是里面的任何东西可以被代替掉。

2

Kubernetes调度流程

这些东西都可以去掉，经常有人说K8S可以像搭积木一样建设你想要的平台，最主要的一点是基于原数据驱动整个系统的运作。如果不想用这些，完全可以替掉。可以通过kube controll去掉。但是你没有它丰富的站点。所以这个时候，包括在社区里面画的时候。这个会通过API拿到判定的作业，完全可以把它转过去。这里面数据相当于数据变更了，这时候相应的，比如说kubelet数据，所以基本是在api里面的状态，基本是按照共享数据做这样的数据。

这是mesos的调度流程，我们做的时候跟mesos比较像，这个调度的话，从下面到上面，这个是中间会有一些数据，这些数据你都不知道，你知道的都是内部数据，出去的时候是一套做的，这个事情对我们来讲，像我们产品跟这个也是一样的。有多个angent做这个事情，这个架构一旦定下来之后，你想改它，彼此的通信协议是蛮复杂的事情，包括我们下一代做交互的时候，因为我们产品有将近20年的产品，包括从通讯协议，都不太敢动。上层有不同的应用场景，对我们来讲是蛮大的差异。

现在来看K8S的结构好一点。现在我们也不太确定，所以这个只是一种模式的事情，刚才说到流程，当你创建ctl的时候，这种架构其实有很多东西，当你创建ctl的时候，流程居然什么都没有做，控制管理者就都做了，在每台机器上创建一个pot，写到这里面，就有刚才的逻辑做这个事情，你对单独的ctl来说没有什么问题，但是你有其他rc来说，你会发现，kube流程和管理者都可以调动这个资源。

1.7讨论的时候，要把管理者调动的部分拿到流程来做。暂时做成单流程的东西。其实这里涉及到另外的问题，一说调度的时候，很多人会把谷歌的那篇文章出来，告诉你三种调度的模型，现在来看，前两种还有得玩，无论是调度也好，中性化也好，这个事情可以做，可以上生产线，我们自己的产品有中性化的，这个东西都验证过了，目前来看，没有人真正能做出来，并且我在跟去年的时候跟谷歌聊过，那个项目在谷歌内部有被叫停了。

至少我个人提到一点是说当我们现在两个流程对整个集群都有资源的使用权的时候，现在没有最好的解决方案，当你的集群规模比较大，请求比较复杂的时候，当你资源发过来的时候，会再检查一遍，他们三个在一起去操作那个基本元素的时候，对调度的蛮大，所以我们在1.7的时候，大部分，要把ctl功能全部挪到流程里面，会达到中性化的调度，让他们俩做这件事情，但是中性化这个有一个问题，就是中性化流程会做得越来越复杂，而且这个流程做了很多比较，所以它的性能，会是个问题，刚才我们看到说有一个地方没有特别细讲，是在流程怎么转，就变成像一个从前到后跑一遍，所有的节点过完这一部分之后。

第二步关于做scheduler，这个大家现在没开使用，基本是只有几个公司用，将来mesos会用，因为kub mesos有自己的资源，另外promit进来以后，会根据你的配置排序，选择最高的node，再走刚才的目标机器写到这个里面去。所以这个能做的，像这个会检查你机器上有多少，image的大小是多少，把前五十个发上来，会在这里做前五十个。比较常用的是这些多一些，在社区里面看到他们对这个问题提得比较多。里在多台机器的时候，证明ICE比较稳定。

3

Kubernetes 1.6 （sig-scheduling, released）

K8S1.6做了四件事情，规则scheduler，把集群中的pot划组，这个scheduler可以在里面单独调度，每个scheduler走的流程还是刚才的流程，这里也是涉及到刚才的事情，scheduler调度的时候一定有那个冲突，但是那台机器没有资源了，最后用不了，现在这个冲突是在那个时候解决了，那个是最准的点，它也有权检查所有的人，在那儿检查有一点问题就是说比如做pot的affinty的时候，有问题，你是基于rank的，比如你这台机器上有，这台机器上有pod，你不知道其他机器有没有这个pod，所以你可能把它接受掉了，去年华为人讲了关于scheduler，他们想在那个做一些功能，做一些前期的检测，有单点的控制，有集群的资源和集群的请求，在那点做成单点的控制，所以这是mart scheduler。

另外做得比较多是把机器打成标签，其他人就不能用这台机器了，就是这样的一个功能，这块还有一个事情是它分了scheduler等两个阶段，如果你打了这个标签会把你这个东西杀掉，这个事情也跟taint tolerant，还是走那套东西，再之后就加了一些code覆盖。后面做得比较简单的功能就是priority和preemption，还有batchjob，这个和之前的同事说的，基于他们俩的比较的模式，那种只能做成三个，这个可以自定义多级的，比如priority，定义成多少个等级，在起来的时候，告诉你优先级多少，对RC来说好一点，对纯Pod比较麻烦，对preemption，不会把整个的pod都删除掉，这是一个加强。然后这块的功能是通过这个做得比较多，那天来的时候，他们整个是基于priority做的。

另外一个就是batchjob。我们现在的K8S做资源划分的时候，是静态划分，那个里面有上限，你不能超，假设有两个用户，设里两个code，如果有一个已经超了，比如它本身想要请求一百个，但是你的code设成50，超不了，创建不出来，有另外一个，另外50个完全可以给别人用。还有人说我把两个的资源code超过，当超过了之后，彼此之间没有比例，基本按照先服务，之前的经验在用户那儿做的时候，在这里看到这是batchjob的概念，这里面的object可以填任何的东西，可以写自己的，可以加crud的操作。

这个创建了以后，会有新的batchjob，会根据它的名字进入里面，或者其他的我们自己有它的mds，这里有另外的scheduler，现在想的是定义的能分到多少资源，这个资源分完以后可以更新到configmap里面去，当这个以后，是创建不出来的，所以这块整个转起来的时候，在这块会有专门资源调度的功能，这个现在到最后做完之后，你会发现它除了K8S本身的功能以外，包含了像mesos的能力。这个案例也是在去年做的时候，谷歌和红帽做了一个项目，在现在的功能都是说K8S给你几个机器或者给你几个pod，在那个里面搭一个自己的就完了，很多人说是资源共享，很多资源之前的那个很难定义出来。

比如我给你十台机器的空间，你很难保证它永远跑得那么满，峰值可能不够，这是资源调度解决的问题，那里会有另外一个问题，我能不能让K8S作为资源的管理者，不是简单定死给你多少，这是简单的观点，这个会根据分给它的在这个基础上分给它的资源创建，这块的时候你会发现，当你有了framwork，其他可以更多的，这里当你资源满的时候，一人分了一百个CPU，他俩都分一百个的时候，最开始大家讨论得没有问题，这个请求有150，这里的scheduler会供它调整，所以它会动态地改这个，这样的话，资源就可以共享出来。从而提高你整个资源的效率。

4

Kubernetes 1.7（sig-scheduling）

因为这个控制，可以用户自己来写，所以这个没有定下来。还有其他的scheduler，这个是在1.7要这样做的事情，这个做完以后，可以考虑通过K8S用来运行多个，资源可以动态调整，资源可以动态共享，当你如果用单个集群很难动态调整，这块有几个模型，这是将来我们要考虑和控制的事情。现在用得比较多，比如说调度请求的时候，要这么大，这块中间的任务不一定都跑满，资源是收不回去的，比如CPU没有问题。

这是第一种案例，第二个事情就是说，这是另外一个模式，我一个Executor跑一个任务，这个资源率会提高，因为像刚才那种，只剩一个的任务，这个资源可以让出来，这个是分情况的，这个情况要占用相同的任务比较多，比如在好多任务可以复用，这样你的资源使用率比较高。我们有产品大概是这样的架构，这个使用率能够达到70%以上，这是一个，另外一种就是说，这是我们需要考虑的事情，之前有人问关于MPI的事情，MPI作业有一些需求，两个最基本的需求是第一个，启的时候要拿到所有资源才能启，而且它自己有彼此之间会有通信，像现在的K8S里面没有这个功能，当你创建的时候，一个循环，往上扔就行了，能启多少启多少，你有可能这面你先起了三个，那面两个，可能守在那儿了。一定要拿到所有的资源。

另外一个案例比较简单的是，我收到任务以后，就访问结果就行了。最简单的就是这种并行的时候，K8S现有的这种，它有job的功能，比较相似，就是把这个东西往上跑，非常非常简单。你不知道当前的任务会分到哪块工作，检查一些功能，我不需要跟别人通信，我抓一些数据，会变成那样，那样是最简单的事情。会考虑这三种的需求，至少在一些版本里面，早期的版本里面支持案例一和案例二，会加上更多的东西，满足并行作业的一些特定的东西。关于1.7里面batchjob是讨论最多的东西，下面一些相关的问题，第一个就是关于管理多个问题，这个是去年在那儿提的事情，这个基于K8S的想法，它希望做这样的事情，在整个集群里面，你是基于当前的需求做的调度，你过了一天以后，有的人可能会停掉，比如死了以后重启等等这样的功能，所以你启动以后，整体的功能可能是最多的，过了一段时间以后，我重新算整个里面的资源情况，然后根据需要达到最优解，它是定期解决这样的问题。像这些batchjob作业就没有太大的作用。那个跑好几周都是可以接受的，关于scheduler就介绍这么多，后续还会有机会，把batchjob的细节讲一下，因为讲起来太多了。

标签：这个,第九次,调度,用户,scheduler,时候,OpenStack,K8S,资源
来源： https://blog.51cto.com/15077561/2584827