容器化运维:容器调度和服务编排

简介: 【2月更文挑战第15天】

考虑如何在集群中创建容器,也就是容器如何调度的问题;容器创建后如何运作才能对外提供服务,也就是服务如何编排的问题。

容器调度

容器调度的问题,说的是现在集群里有一批可用的物理机或者虚拟机,当服务需要发布的时候,该选择哪些机器部署容器的问题。


比如集群里只有 10 台机器,并且已经有 5 台机器运行着其他容器,剩余 5 台机器空闲着,如果此时有一个服务要发布,但只需要 3 台机器就行了,这个时候可以靠运维人为的从 5 台空闲的机器中选取 3 台机器,然后把服务的 Docker 镜像下载下来,再启动 Docker 容器服务就算完成发布。但如果集群机器的规模扩大到几十台或者上百台时,要发布的服务也有几十个或者上百个的时候,由于每个服务对容器的要求,以及每台机器上正在运行的容器情况变得很复杂,就不太可能靠人肉运维了。


容器调度要解决的问题如下:

1)主机过滤

主机过滤是为了解决容器创建时什么样的机器可以使用的问题,主要包含两种过滤。

  • 存活过滤。也就是说必须选择存活的节点,因为主机也有可能下线或者是故障状态。
  • 硬件过滤。打个比方,现在你面对的集群有 Web 集群、RPC 集群、缓存集群以及大数据集群等,不同的集群硬件配置差异很大,比如 Web 集群往往用作计算节点,它的 CPU 一般配置比较高;而大数据集群往往用作数据存储,它的磁盘一般配置比较高。这样的话如果要创建计算任务的容器,显然就需要选择 Web 集群,而不是大数据集群。


2)策略调度

调度策略主要是为了解决容器创建时选择哪些主机最合适的问题,一般都是通过给主机打分来实现的。比如 Swarm 就包含了两种类似的策略:spread 和 binpack,它们都会根据每台主机的可用 CPU、内存以及正在运行的容器的数量来给每台主机打分。spread 策略会选择一个资源使用最少的节点,以使容器尽可能的分布在不同的主机上运行。它的好处是可以使每台主机的负载都比较平均,而且如果有一台主机有故障,受影响的容器也最少。而 binpack 策略恰恰相反,它会选择一个资源使用最多的节点,好让容器尽可能的运行在少数机器上,节省资源的同时也避免了主机使用资源的碎片化。

具体选择哪种调度策略,还是要看实际的业务场景,通常的场景有:

  • 各主机的配置基本相同,并且使用也比较简单,一台主机上只创建一个容器。这样的话,每次创建容器的时候,直接从还没有创建过容器的主机当中随机选择一台就可以了。
  • 在某些在线、离线业务混布的场景下,为了达到主机资源使用率最高的目标,需要综合考量容器中跑的任务的特点,比如在线业务主要使用 CPU 资源,而离线业务主要使用磁盘和 I/O 资源,这两种业务的容器大部分情况下适合混跑在一起。
  • 还有一种业务场景,主机上的资源都是充足的,每个容器只要划定了所用的资源限制,理论上跑在一起是没有问题的,但是某些时候会出现对每个资源的抢占,比如都是 CPU 密集型或者 I/O 密集型的业务就不适合容器混布在一台主机上。


服务编排

1)服务依赖

大部分情况下,微服务之间是相互独立的,在进行容器调度的时候不需要考虑彼此。但有时候也会存在一些场景,比如服务 A 调度的前提必须是先有服务 B,这样的话就要求在进行容器调度的时候,还需要考虑服务之间的依赖关系。


Docker Compose 这种通过 yaml 文件来进行服务编排的方式是比较普遍的算法,通过类似 yaml 文件的方式定义了服务扩容的模板,模板除了定义了服务创建容器时的镜像配置、服务池配置以及主机资源配置以外,还定义了关联依赖服务的配置。比如微博的 Feed 服务依赖了 user 服务和 card 服务,假如 user 服务扩容的模板 ID 为 1703271839530000,card 服务扩容的模板 ID 为 1707061802000000,那么 Feed 服务的扩容模板里就会像下面这样配置,它代表了每扩容 10 台 Feed 服务的容器,就需要扩容 4 台 user 服务的容器以及 3 台 card 服务的容器。

{"Sid":1703271839530000,"Ratio":0.4}
{"Sid":1707061802000000,"Ratio":0.3}


2)服务发现

容器调度完成以后,容器就可以启动了,但此时容器还不能对外提供服务,服务消费者并不知道这个新的节点,所以必须具备服务发现机制,使得新的容器节点能够加入到线上服务中去。


比较常用的服务发现机制包括两种,一种是基于 Nginx 的服务发现,一种是基于注册中心的服务发现。

  • 基于 Nginx 的服务发现

这种主要是针对提供 HTTP 服务的,当有新的容器节点时,修改 Nginx 的节点列表配置,然后利用 Nginx 的 reload 机制,会重新读取配置从而把新的节点加载进来。比如基于 Consul-Template 和 Consul,把 Consul 作为 DB 存储容器的节点列表,Consul-Template 部署在 Nginx 上,Consul-Template 定期去请求 Consul,如果 Consul 中存储的节点列表发生变化,就会更新 Nginx 的本地配置文件,然后 Nginx 就会重新加载配置。

  • 基于注册中心的服务发现

这种主要是针对提供 RPC 服务的,当有新的容器节点时,需要调用注册中心提供的服务注册接口。在使用这种方式时,如果服务部署在多个 IDC,就要求容器节点分 IDC 进行注册,以便实现同 IDC 内就近访问。


3)自动扩缩容

容器完成调度后,仅仅做到有容器不可用时故障自愈还不够,有时候还需要根据实际服务的运行状况,做到自动扩缩容。


一个很常见的场景就是,大部分互联网业务的访问呈现出访问时间的规律性。白天和晚上的使用人数要远远大于凌晨的使用人数;而白天和晚上的使用人数也不是平均分布的,午高峰 12 点半和晚高峰 10 点半是使用人数最多的时刻。这个时候就需要根据实际使用需求,在午高峰和晚高峰的时刻,增加容器的数量,确保服务的稳定性;在凌晨以后减少容器的数量,减少服务使用的资源成本。


常见的自动扩缩容的做法是根据容器的 CPU 负载情况来设置一个扩缩容的容器数量或者比例,比如可以设定容器的 CPU 使用率不超过 50%,一旦超过这个使用率就扩容一倍的机器。


要考虑到 Kubernetes 本身的复杂性以及概念理解的门槛,对于大部分中小业务团队来说,在生产环境上使用 Kubernetes 都会显得大材小用,并且还需要部署并运维 Kubernetes 周边的一些基础设施,比如 etcd 等。

相关文章
|
3天前
|
运维 监控 Kubernetes
构建高效自动化运维体系:基于容器技术的持续集成与持续部署(CI/CD)实践
【5月更文挑战第15天】 随着云计算和微服务架构的普及,传统的IT运维模式面临转型压力。为提高软件交付效率并降低运维成本,本文探讨了利用容器技术实现自动化运维的有效策略。重点分析了在持续集成(CI)和持续部署(CD)流程中,容器如何发挥作用,以及它们如何帮助组织实现敏捷性和弹性。通过具体案例研究,文章展示了容器化技术在自动化测试、部署及扩展中的应用,并讨论了其对系统稳定性和安全性的影响。
|
3天前
|
运维 监控 安全
构建高效自动化运维系统:基于容器技术的持续集成与持续部署(CI/CD)实践
【5月更文挑战第14天】 随着DevOps文化的深入人心,持续集成与持续部署(CI/CD)已成为现代软件工程不可或缺的组成部分。本文将探讨如何利用容器技术,尤其是Docker和Kubernetes,构建一个高效、可扩展的自动化运维系统。通过深入分析CI/CD流程的关键组件,我们将讨论如何整合这些组件以实现代码从提交到生产环境的快速、无缝过渡。文章还将涉及监控、日志管理以及安全性策略等运维考量,为读者提供一个全面的自动化运维解决方案蓝图。
|
3天前
|
运维 Kubernetes 持续交付
构建高效自动化运维体系:基于容器技术的持续集成与部署实践
【5月更文挑战第13天】 在现代软件开发周期中,持续集成(CI)和持续部署(CD)已成为提升开发效率、保障产品质量的关键环节。随着云计算和微服务架构的普及,容器技术如Docker和Kubernetes为运维领域带来了革命性的变革。本文旨在探讨如何利用容器技术构建一个高效、可靠的自动化运维体系,实现从代码提交到产品发布的全过程自动化管理。通过深入分析容器化技术的核心原理,结合实际案例,我们将阐述如何优化持续集成流程、确保自动化测试的覆盖率、以及实现无缝的持续部署。
25 2
|
3天前
|
机器学习/深度学习 监控 Kubernetes
【Docker 专栏】Docker 容器内服务的自动扩展与缩容
【5月更文挑战第9天】本文探讨了Docker容器服务的自动扩展与缩容原理及实践,强调其在动态业务环境中的重要性。通过选择监控指标(如CPU使用率)、设定触发条件和制定扩展策略,实现资源的动态调整。方法包括云平台集成和使用Kubernetes等框架。实践中,电商平台和实时数据处理系统受益于此技术。注意点涉及监控数据准确性、扩展速度和资源分配。未来,智能算法将提升扩展缩容的效率和准确性,成为关键技术支持。
【Docker 专栏】Docker 容器内服务的自动扩展与缩容
|
3天前
|
前端开发 API 数据库
【Docker专栏】Docker Compose实战:编排多容器应用
【5月更文挑战第7天】Docker Compose是Docker的多容器管理工具,通过YAML文件简化多容器应用部署。它能一键启动、停止服务,保证开发、测试和生产环境的一致性。安装后,创建`docker-compose.yml`文件定义服务,如示例中的web和db服务。使用`docker-compose up -d`启动服务,通过`docker-compose ps`、`stop`、`down`和`logs`命令管理服务。
【Docker专栏】Docker Compose实战:编排多容器应用
|
3天前
|
运维 Kubernetes Devops
构建高效自动化运维体系:DevOps与容器化技术融合实践
【5月更文挑战第6天】随着企业IT架构的复杂化以及快速迭代的市场需求,传统的运维模式已难以满足高效率和高质量的交付标准。本文将探讨如何通过结合DevOps理念和容器化技术来构建一个高效的自动化运维体系,旨在实现持续集成、持续部署和自动化管理,提升系统的可靠性、可维护性和敏捷性。
|
3天前
|
敏捷开发 运维 测试技术
构建高效自动化运维体系:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】在数字化转型的浪潮中,企业对软件交付速度和质量的要求日益提高。自动化运维作为提升效率、确保稳定性的关键手段,其重要性不言而喻。本文将探讨如何利用容器技术构建一个高效的自动化运维体系,实现从代码提交到产品上线的持续集成(CI)与持续部署(CD)。通过分析现代容器技术与传统虚拟化的差异,阐述容器化带来的轻量化、快速部署及易于管理的优势,并结合实例讲解如何在实际环境中搭建起一套完善的CI/CD流程。
|
3天前
|
运维 Kubernetes 持续交付
构建高效自动化运维系统:基于容器技术的持续集成与持续部署实践
【4月更文挑战第30天】 在快速发展的云计算时代,传统的运维模式已无法满足敏捷开发和快速迭代的需求。本文将介绍如何利用容器技术搭建一套高效自动化运维系统,实现软件的持续集成(CI)与持续部署(CD)。文章首先探讨了现代运维面临的挑战,接着详细阐述了容器技术的核心组件和工作原理,最后通过实际案例展示了如何整合这些组件来构建一个可靠、可扩展的自动化运维平台。
|
3天前
|
运维 Kubernetes 持续交付
构建高效自动化运维体系:基于容器技术的持续集成与持续部署(CI/CD)实践
【4月更文挑战第29天】 随着云计算和微服务架构的兴起,自动化运维已成为提升企业IT效率、确保系统稳定性的关键因素。本文旨在探讨如何利用容器技术构建一套高效的自动化运维体系,实现软件开发过程中的持续集成(CI)与持续部署(CD)。文章首先分析了传统运维模式面临的挑战,然后详细介绍了基于Docker和Kubernetes等容器技术的CI/CD流程设计与实施策略,并通过一个实际案例来展示该方案在提高部署频率、降低人力成本及提升系统可靠性方面的显著优势。
|
3天前
|
敏捷开发 运维 监控
【专栏】微服务架构,以敏捷、灵活著称,通过拆分大型应用为小型自治服务,简化开发运维
【4月更文挑战第27天】微服务架构,以敏捷、灵活著称,通过拆分大型应用为小型自治服务,简化开发运维。本文探讨其基本概念、起源,核心优势(如敏捷开发、高可伸缩性)及挑战(系统复杂度、数据一致性),并分享实施策略(服务划分、技术选型、CI/CD)与实践案例(Netflix、Uber、Spotify),展示微服务如何重塑软件开发,并成为未来复杂应用系统的基础。