关于容器云部署的一些问题云计算

来源:互联网 / 作者:SKY / 2018-06-12 18:03 / 点击:
目前应该是几乎所有的容器云厂商在容器云交流和PoC时都强调所有组件都容器化。这样实施安装部署相对容易,一键部署、半小时搭建容器云平台。

目前应该是几乎所有的容器云厂商在容器云交流和PoC时都强调所有组件都容器化。这样实施安装部署相对容易,一键部署、半小时搭建容器云平台。但我们在PoC测试中也发现了一些问题,比如容器资源分配的问题,Kubernetes多集群部署问题,控制节点高可用部署问题,镜像仓库定位和部署问题,中间件和不同的环境部署和定位问题等;也发现容器云平台容器异常,新的容器创建,旧的依然在,导致很多无用的容器占用资源,也带来一些理解上的困难。虽然是平台自身实现的问题,但明显是在设计时一些问题没考虑到。

关于容器云部署问题

二、环境管理

全容器化部署的好处是可以快速的构建一致性的环境,这也是实现DevOps的一个重要方面。所以在开发测试环境全容器化部署是没有问题的。因为这些环境需求变化快,传统维护开发测试环境需要花费大量的时间和人力,如果采用容器化方式,可以快速构建一个开发测试环境域,用于完成服务的测试。主要完成功能性方面的测试,对于可能涉及到性能测试,我们建议放到UAT环境来做。UAT和生产环境保持软硬件和部署架构一致。UAT和生产环境容器云基础组件建议部署到虚拟机或物理机上,比如集中日志、监控、服务注册发现、服务网关等组件。这样部署的目的一方面是为了更好的利用容器云的轻量化特性,另一方面也是基于安全、运维管理等考虑。

我们也一直说要用简单的方式解决复杂的问题,基于容器云基础设施,我们希望建设企业级服务中台,一家企业只需要维护一套日志系统,一套监控系统,没必要每次都重复建设。这些组件相对固定,并不需要经常改变,而且数据需要保证绝对的安全。通常集中日志系统、监控系统等都需要集群化部署,不是一台机器一个实例能满足需求的。所以在开发测试环境是为了利用容器的快速构建特性,在UAT、生产环境则要保持稳定、安全。采用容器云在环境管理环境部署方面可以有所差别。

各个环境保持独立而又通过镜像仓库联系起来,镜像是联系各个环境的标准交付物。

三、镜像仓库

镜像仓库在容器云平台如何定位?在DevOps中起什么样的价值?这是我们考虑采用容器云平台过程中也一直考虑的问题。以前的讨论中我们提到过,考虑把镜像仓库作为开发测试和生产之间的媒介,开发测试都止于镜像仓库,生产起于镜像仓库。镜像作为标准交付物,在各个环境间传递,镜像仓库通过镜像的安全检查等机制保证镜像安全。也就是DevOps持续集成止于镜像仓库,镜像仓库是部署运营的起点。

镜像仓库要不要部署于容器?其实这个在我们看来不是很重要。首先镜像仓库是基础组件,不会经常需要更改变化,所以其实更适合稳定的部署。另外公共镜像和私有镜像会需要很多的磁盘空间,IO能力会成为一个因素。镜像仓库可以作为镜像的分发中心,也就是我们所说的各环境之间的媒介,或者不同集群之间的媒介。从这个角度来说,镜像仓库可以作为一个独立的部分,只是为容器云平台提供镜像分发服务和镜像管理服务。它可以独立部署,不依赖于容器云平台。物理机或虚拟机部署或许更合适一点,当然,部署于容器也不是不可以。

镜像仓库高可用部署是需要考虑的,这也是很多容器云厂商宣传的一个重要的功能点。如果有充足的资源,我们还是建议镜像仓库部署高可用,毕竟这样可以多一份保障,减少一些意外,但高可用节点不是越多越好,通常主备节点就可以了。不部署高可用通常也不会有太大问题,只要数据不丢失,很快的恢复,没有大的影响。

四、集群部署

Kubernetes理论上可以管理成千上万的节点,但现实总会有不小的差距。有测试显示Kubernetes集群节点数超过500就会出现超时,增加Kube Master节点并不能真的解决问题,所以每个Kubernetes集群节点数有一定的限制,在达到500左右时就需要考虑优化措施,或者按业务条线分集群部署。

通常我们这样的传统企业,节点数也不会很快达到500以上,单一集群一定时间内也可以满足需求。随着节点数的增加,Kube Master节点数也需要增加。其实最初我们考虑只要Kubernetes能保证在Master节点宕机时不影响到业务应用的正常运行,Kubernetes集群的管理工作我们可以忍受一段时间的中断,所以我们没考虑Master节点高可用,但节点数的增加可能必须部署Master节点的高可用,否则可能无法支持kubectl的正常操作。随着节点数的增加master节点数也需要增加。但master节点数超过10就也会带来一些问题,所以通常master节点数是3、5或7比较合适,支持几百个节点。

所以初始情况下,可以用简单的方式,化繁为简,化大为小,采用按业务条线多集群部署方式。这样每个集群确保不会有超过500以上的节点。超过的话考虑新建集群进行拆分。但有些情况下可能需要很大的集群,这个目前采用Mesos可能是更好的方案,从《scaling kubernetes to 2500 nodes》一文中我们了解到Kubernetes可能需要采取不少的优化措施。我们还远未达到这样的集群数量,也没有条件进行测试,所以目前还不能确切知道是否可行。也不知道是否有什么潜在的问题,厂商似乎在这方面也没有太多经验。所以如果可能的话,把大集群拆分为多个小集群,按业务条线、或者按区域等划分,应该是一个可行的方案。

五、控制节点

控制节点就是我们说的master节点,是集群中的大脑和中枢神经,控制和指挥着整个集群的运转。控制节点不可用,整个集群就会陷入瘫痪。最初我们考虑,是否有必要占用那么多的资源来部署控制节点高可用,对我们来说我们可以忍受一段时间内控制节点不可用,只要能及时恢复。部署并不是每时每刻发生,只要部署的业务服务能正常运行,业务不受影响,控制节点暂时的不可用是不会有太大的影响。所以最初我们只考虑部署一个控制节点,不考虑高可用部署。这也是基于我们ESB运维的经验。ESB的控制监控节点故障,不影响业务服务,所以我们有充足的时间来调试恢复ESB控制监控节点。不过Kubernetes跟ESB不同的是,随着节点数的增加,可能需要部署更多控制节点,实现控制节点高可用部署。

Kubernetes控制节点有多个组件,包括kube-apiserver、kube-controller、kube-scheduler和etcd等,这些组件是分开部署还是一个节点上部署?随着集群节点数的增加,可能也是一个不得不考虑的问题。Etcd应该需要单独部署,不同的场景选择合适的磁盘,以及是否使用不同的etcd集群,比如配置中心如果使用etcd,是否和平台合用同一个etcd还是新建一个,需要根据具体节点数量等情况来确定。从《scaling kubernetes to 2500 nodes》文中我们知道,etcd使用了串行 I/O, 导致 I/O 之间的延迟叠加,在节点数超过500的时候延迟就增加很多,导致Kubectl操作超时,所以etcd在改用本地SSD磁盘后,etcd终于正常了。另外Kubernetes Events 也可以存储在一个单独的 etcd 集群里,这样对 Events 的操作就不会影响到主 etcd 集群的正常工作。但这也带来了更多的资源投入,以及管理的复杂度。

六、基础组件部署

阅读延展

1
3