容器化实践指南 迈出容器化的第一步：集群管理

原标题：容器化实践指南迈出容器化的第一步：集群管理

随着容器技术日渐成熟以及Kubernetes风靡一时，IT架构容器化已经从前沿技术公司的探索逐渐成为大部分企业IT的发展方向。

最近CNCF（云原生计算基金会）云原生调查反映：在亚洲市场，几乎所有容器管理工具的使用率都有所增长，现成商业解决方案总体增长58%，本土解决方案增长690%，Kubernetes增长11%。Kubernetes集群在生产中的规模也在扩大，运行1-5个生产集群的组织减少37%，而运行11-50个集群的受访者增加 154%。

百度云作为CNCF的金牌会员，同时也是国内容器技术的最早践行者之一，在过去7年的内部容器化实践中积累了大量的经验。本系列文章将从企业容器化场景出发，从不同角度呈现容器化过程中需要理解的概念和常见问题的解决方案，帮助百度云用户更好地使用容器技术，利用云原生的IT架构为业务的高速发展保驾护航。

容器引擎与容器集群技术

容器技术的雏形其实最早在1979年就已经诞生，其初衷是在同一个操作系统中，为不同进程提供相互隔离的运行环境。随着技术发展，容器现在已经成为了一种典型的轻量级虚拟化技术，它依托于操作系统的基础架构之上，为应用程序提供独立的运行环境。由于应用程序的运行只需要与容器交互，因此开发者无需关心底层操作系统的差异，使得容器化应用的部署和迁移变得极为方便，再加上容器本身轻量级的特点，其启停速度远快于传统的虚拟机，让应用程序在分布式架构中的弹性扩展变得更加简单。

谈到容器，我们往往都会直接与Docker关联起来。实际上Docker只是容器引擎技术的一种，由于Docker将容器技术推向了巅峰，因此它已经成为了容器引擎技术的事实标准。作为一项容器引擎技术，Docker解决的问题就是如何在操作系统中生成和运行容器。无论是在物理机、虚拟机或者任何一个厂商的云服务器中，开发者都可以通过Docker快速定义和启动容器环境，并将自身业务运行在其中。

Docker基本架构（图片来源网络）

但是由于容器轻量级的特性，大部分业务系统都无法单独运行在一个容器当中，而是需要多个容器环境协同工作。容器引擎仅仅解决了单个容器如何在操作系统中运行的问题，而无法帮助用户完成大量容器的协同管理和编排，因此容器编排和管理系统也就应运而生。

当用户需要通过容器来运行一个大型应用或者复杂系统时，往往需要启动在多个服务器上的大量容器。容器管理系统可以帮助用户执行大量的复杂任务，包括：定义不同容器的角色和关系、安排容器的资源分配和部署、对容器的健康状况进行检查、当容器出现故障时进行容错处理、在业务量变化时对容器进行弹性伸缩等。

容器管理系统在容器的生产化应用中是必不可少的，在容器技术的探索阶段，许多前沿企业都研发了各自的管理系统，其中也包括百度自研的Matrix。而近几年来，随着开源的容器管理系统Kubernetes（简称K8S）的飞速发展，它已经基本成为容器管理系统的事实标准。百度也在Kubernetes的早期即参与了开源社区的多项工作，并且于2017年在百度云上推出了基于Kubernetes的云容器引擎产品CCE。

百度云CCE产品架构图（图片来源网络）

由于Kubernetes是一个分布式的容器管理系统，因此其往往部署在一个多节点的服务器集群中，Kubernetes本身的各个组件以及用户业务的容器都将部署在该集群的各个节点中。Kubernetes提供了一套用于管理集群节点以及节点间协作的模型，使用者需要遵循这个模型搭建集群的节点、网络和存储架构，同时对集群容量和运行状态进行监控和管理。因此对于企业而言，理解如何创建和管理一个Kubernetes集群就成为了实现容器化架构的第一个挑战。

容器集群的搭建和节点管理

一个Kubernetes集群通常由一组网络上互通的节点组成，节点可以是虚拟机或者物理机器，为Kubernetes组件和用户容器提供了运行所需的资源。用户需要部署一组Master组件对节点进行管理，同时每个节点上需要部署一些必要的服务，用于管理节点上的容器并与Master组件通信。因此搭建一个Kubernetes集群通常分为3个步骤：部署Master组件、创建节点并部署节点服务、将节点注册到Master。

（图片来源网络）

Master组件理论上可以在集群中的任何节点运行，但是为了更方便维护和提供更高的稳定性，通常会使用独立的1个或者多个节点部署所有Master组件，这些节点上不再运行任何用户的容器。最基本的Master组件包括：

kube-apiserver、etcd、kube-controller-manager、cloud-controller-manager、kube-scheduler、addons、Cluster DNS、dashboard 、资源监控组件、集群日志组件等。（对于每个组件具体的工作内容和运行机制，我们未来将会进行详细阐述）

在这些Master组件中，kube-apiserver负责对外暴露Kubernetes API，用于接收用户指令，并且与所有的工作节点进行通讯。kube-apiserver具备水平扩展的能力，因此可以通过部署在多个虚拟或者物理服务器上来提供高可用的架构，此时就需要为kube-apiserver搭建一个单独的负载均衡，用于与外部进行通讯。

在百度云上，用户创建CCE集群时，系统会在用户所购买的工作节点以外，提供额外且免费的多个节点用于搭建高可用的Master，这些Master节点本身对用户不可见（无法直接通过SSH访问），但是系统会提供免费的负载均衡和公网IP地址，让用户可以在本地或者云服务器上通过kubeclt（一个用于执行Kubernetes命令的本地工具）直接与kube-apiserver进行交互，从而控制和管理整个容器集群。

Master组件就绪以后，用户需要对每个集群节点进行部署，必要的节点服务包括：kubelet、kube-proxy、Docker等。其中kubelet用于执行Master对容器的调度，监控和管理节点上所有容器的生命周期，kube-proxy用于维护节点上的网络转发规则，让流量可以访问到正确的容器上，Docker则起到容器引擎的作用，用于启动和运行容器。

除此以外，还有一些采集节点日志和监控信息的组件，也可以运行在节点当中。搭建工作节点除了在每个节点上部署以上服务以外，还需要确保节点组件与Master组件可以互相通讯，通常需要保障工作节点可以访问到Master中的kube-apiserver，并且kube-apiserver也可以访问每个节点中的kubelet组件。

在完成工作节点上的部署且网络连通的情况下，节点将会自动向kube-apiserver注册自己，注册的信息包括节点的IP地址、节点的标签、节点的容量以及一些用于描述节点的元数据等。用户也可以通过在kubelet中设置--register-node=false来关闭自动注册，然后手动提交注册信息。节点被注册到Master之后，会由Master组件中的Node Controller进行管理，该组件将会监控每个工作节点的完整生命周期，对节点的状态进行标记，从而辅助容器调度策略的执行。

工作节点的部署和注册决定了用户容器运行的环境和可使用的资源容量，因此是IT部门维护容器集群的工作重点。

在百度云上，用户可以随时向CCE集群中添加新的节点，只需要选择所需节点的容量大小和操作系统，系统将会自动帮助用户完成节点组件的部署，并且将节点注册到Master，大大降低了节点管理的工作复杂度。同时，在用户业务运行的过程中，CCE也提供了便利的自动扩缩容能力，可以在节点资源不足或者过剩时，自动完成节点的添加或者释放，从而帮助用户最大化利用云上资源。

下期内容预告

在完成容器集群Master和工作节点的搭建后，集群就已经具备启动和调度容器的基本条件了。但是要真正承载企业级业务的稳定和可用性，还需要对集群的网络、存储架构以及如何监控集群进行更加全面的规划。下一期内容我们将继续聚焦在容器集群管理上，介绍如何在云端规划和管理容器集群的网络、存储和监控，帮助您更好地理解和管理自己的容器集群。

关注百度云微信公众号，体验、使用百度云容器引擎CCE。

生成海报

免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。