1. 梦飞科技 > 中国IDC > 云计算 > 云技术 >
  2. 关于容器云部署问题(3)

关于容器云部署问题(3)

一、全容器化部署?

目前应该是几乎所有的容器云厂商在容器云交流和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比较合适,支持几百个节点。

(来源:网络)

本站所有文章和图片均由根据搜索引擎转码而来,只为让更多读者欣赏,本站不保存图片及数据,仅作学习展示。遵循互联网避风港原则,如有网站内容疑问,请通知站长

扫描二维码

关注梦飞科技最新资讯