容器应用与集群管理

容器应用与集群管理

思考：单容器实例能否支撑企业级应用？

之前，小陈已经能够采用Docker在单容器上完成WordPress网站的构建、发布和运行了。经过公司评估后，计划让小陈把WordPress网站部署到生产环境上，正式上线运营。小陈觉得这个任务重大，由于缺少经验，决定找大刘请教。

小陈：师傅，我刚在容器上搭建过公司网站，现在要在生产环境中搭建公司网站，我感觉只用容器来搭建恐怕不行吧？

大刘：是会有些问题。设想一下，如果容器所在的宿主机出现故障，或者网站应用需要停机升级，又或者用户访问量超过了单个容器的处理能力，会怎样？

小陈：网站可能会无法提供服务，导致业务无法开展。应该如何解决呢？

大刘：一个好汉三个帮咯。这就需要运行多个相同应用的容器，并构成一个跨服务器的容器集群，对外提供统一的访问地址。如此，当一个容器发生异常或其应用需要升级时，由于其他容器未受影响，整个集群可以照常提供服务。容器集群可提供远超单实例的处理能力，还可以根据业务负载的变化，相应调整集群中的容器数量，实现业务的弹性。

小陈：明白了。那么，管理容器集群会很复杂吗？

大刘：这个问题问得好。随着容器技术的普及，容器集群技术也在飞速发展，现在已经很成熟了，容器集群的管理自动化、智能化程度很高，大大节省了运维人员的时间精力，比如我们常说的Kubernetes技术就是这样。

小陈：哦，好像听过这个名字，那我先去了解下容器编排技术。

容器集群的必要性

单个容器的应用可以满足简单应用场景或者少量用户访问，但随着应用越来越复杂、访问量越来越大，单个容器的性能慢慢不支，就需要不断增加更多容器来提高应用的处理能力。但随着容器越来越多，就引发了一系列问题：

• 如何跨主机部署成百上千个容器？
• 如何协调和调度大量的容器？
• 如何在升级应用程序时不会中断服务？
• 如何监视应用程序的运行状况？

由于容器本质上是轻量级且短暂存在的，因此在生产环境中运行和管理大量容器，所需工作量巨大。遇到业务访问量特别大的时候，可能需要同时运行数百甚至数千个容器。如果手动管理这些容器，会显著增加管理复杂性。

所以，当大规模使用容器时，人工管理已经不可行，不得不考虑容器调度、部署、跨节点访问、自动伸缩等问题，这就需要容器集群技术了。

容器集群技术是如何发展的？

容器出现后，容器集群技术是近些年容器技术演进发展的重点领域之一。容器集群发展的里程碑事件如下：

添加图片注释，不超过 140 字（可选）

2013年7月：Mesosphere发布了Marathon的开源项目。它的设计宗旨是让用户在同一组服务器上，更智能地运行多种程序和服务。 2014年6月：Google开源了Kubernetes。其目标是成为“跨集群的应用级别容器部署、部署和运维自动化平台”。 2015年4月：CoreOS公司推出了容器网络接口规范（CNI），它规定了一个容器runtime和网络插件之间的标准接口协议。 2015年5月：Docker发布了容器网络模型 （CNM）。它是Docker主导的网络方案，提供了IP地址管理和网络插件功能。 2015年7月：Google主导成立了云原生计算基金会（CNCF）。CNCF对云原生最初的定义，包含了三个方面：应用容器化，面向微服务架构，应用支持容器的编排调度。 2016年3月：Google将Kubernetes项目捐赠给CNCF基金会。 2016年6月：Swarm内置到Docker中。 2017年7月：Open Container Initiative（OCI）发布了容器运行时和镜像规范1.0版本 2017年12月：标准化容器存储接口规范（CSI：Container Storage Interface）发布。CSI的主要目的是使得存储提供商只需要编写一个插件，就能在大部分的容器编排系统上工作。 2018年3月：Kubernetes项目毕业 2018年8月：Prometheus项目毕业 2018年之后：Kubernetes 逐渐成为业界通用流行的容器编排技术，各大厂商纷纷宣布支持 Kubernetes 作为容器编排的方案。

从容器集群发展历程中，我们看到了Mesos、Swarm和Kubernetes项目，这三个项目都是实现跨集群的应用级别容器部署、管理和运维的自动化平台，这种平台技术一般可以称为容器编排技术。

容器编排是指自动化容器的部署、管理、扩展和联网。通过容器编排，可以构建跨多个容器的应用服务、跨集群调度容器、扩展这些容器，并持续管理它们的健康状况。容器编排给容器技术带来了巨大的价值，包括：

• 自动化部署：支持根据副本数量，回滚，重启等策略自动部署容器。
• 服务发现与负载均衡：自动发现增加的容器，并进行流量的负载均衡。
• 自动化容器恢复：自动对容器进行健康检查，并根据策略进行重启。
• 弹性伸缩：支持工作节点、容器的自动扩缩容。

一个容器编排平台的核心功能：首先可以自动生成容器实例，并且生成的容器可以跨服务器的，帮助提高可用性和性能，同时还有健康检查、容错、可扩展、网络、服务发现、滚动升级等功能，可以很好地解决需求与资源的匹配编排问题。

容器编排平台的市场竞争曾经非常激烈，主流的有三个：Docker Swarm、Mesos Marathon和Kubernetes。它们各有特点，但同时满足上面上述能力的，只有Kubernetes。

添加图片注释，不超过 140 字（可选）

Kubernetes简化了集群范围内相关容器被共同调度管理的复杂性，能够相对容易地支持更强大、更复杂的容器调度算法。随着Kubernetes 越来越成熟，越来越受到市场青睐，最终成为了容器调度的事实标准。

思考：如何快速掌握容器编排技术？

小陈学了一段时间的Kubernetes知识，发觉可以基于Kubernetes来搭建公司网站容器集群。但是Kubernetes涉及的概念太多，千头万绪，学习不得要领，还是找大刘请教。

小陈：师傅，我看了一些Kubernetes的资料。

大刘：哦？已经开始学习Kubernetes了，不错。学得怎么样？

小陈：Kubernetes概念好多、涉及很多知识点，看了一些材料，还是一头雾水。

大刘：嗯，这是正常的。从容器到Kubernetes，无论是技术的广度和深度都增加了很多。Kubernetes概念、组件、技术点很多，如果没领会Kubernetes的设计理念，那就是只抓住了皮毛，没有抓住灵魂，学习Kubernetes就会很困难。

小陈：什么是Kubernetes的设计理念呢？

大刘： Kubernetes是一个面向终态的编排系统。用户按照Kubernetes提供的带有编排逻辑的工作负载模版，向Kubernetes声明期望的应用容器的状态，随后Kubernetes会创建对应的工作负载。Kubernetes的调度器一直在监听各种请求，一旦发现创建了对应的应用容器，立马根据计算节点的情况与预定的策略，把容器调度到最适合的计算节点。计算节点也在监听是否有与自己有关的应用容器创建，如果有，立即拉取用户想要的镜像并运行，并向Kubernetes报告应用容器的状态。工作负载的控制器也在不断监听容器集群的状态是否与用户的预期一致，如果不一致，会按照工作负载控制器的编排逻辑进行处理。容器镜像都创建后，计算节点也会自动发现服务并进行业务负载。

小陈：听起来好神奇。感觉用户只要提交自己想要的工作负载的状态，Kubernetes就会自动工作，最后给到用户期望的。对吧？

大刘：的确如此。这就是Kubernetes强大的地方，基于面向终态的工作机制，可以轻松实现自动部署、服务发现、自动愈合、弹性伸缩等功能。

小陈：师傅一席话，真是让我豁然开朗。那么，怎么学习可以效率高一些呢？

大刘：抓住Kubernetes设计理念后，以单个容器为起点，了解单个容器如何走向一组容器，以及容器集群从创建到运行的整个过程，最好结合实际应用创建部署的过程来进行学习，理论结合实践，这样会快一些，你可以试试。

小陈：好的。我学习中有问题，我再来请教您吧。

大刘：没问题。

Kubernetes是什么？

添加图片注释，不超过 140 字（可选）

Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。想象一艘载满集装箱的轮船，轮船在大海上航行，把集装箱送到它们该去的地方。集装箱的英文单词是container，container的另一个翻译就是“容器”。 Kubernetes的英文原意是指用来操纵和控制船舶航向的船舵。大海航行靠舵手，借着这个寓意，Kubernetes希望成为运送集装箱的一个轮船，来管理这些集装箱，也就是管理这些容器。这也是为什么Kubernetes的Logo是一张船舵的图片。

添加图片注释，不超过 140 字（可选）

Kubernetes 这个单词是希腊语，它的中文翻译是“舵手”或者“飞行员”。在一些常见的资料中也会看到“ks”这个词，也就是“k8s”，它是通过将中间8个字母“ubernete ”替换为“8”而形成的一个缩写。

在Kubernetes中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要开发和运维人员进行复杂的手工配置和处理。

Kubernetes核心概念

Kubernetes简称K8s，是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。

为什么需要Kubernetes？容器是打包和运行应用程序的好方式。在生产环境中，往往需要管理运行着应用程序的容器，并确保服务不会下线。如果一个容器发生故障，则需要启动另一个容器，类似这样的行为可以交由Kubernetes 来处理。Kubernetes 会满足用户的扩展要求、故障转移你的应用、提供部署模式等。

对于容器和Kubernetes的关系，为了便于理解，可以做个类比：Kubernetes就好比一个操作系统，而容器就好比操作系统上运行的一个进程。

Kubernetes中涉及到的关键名词包含以下这些，他们重要但很抽象，建议您先记住这些名词和概念，在本课程中我们将结合后续实际操作步骤为您展开介绍。

• Pod（容器组）：Pod是一个逻辑概念，是一组紧密关联的容器的集合。
• Controller（控制器）：控制器通过控制循环监控集群状态，将当前状态转变为期望状态。控制器包含节点控制器、命名空间控制器、工作负载控制器等多种。
• Workload（工作负载）：工作负载是在 Kubernetes 上运行的应用程序，分为无状态、有状态、任务、定时任务等多种类型。

思考：如何低门槛的使用容器集群技术？

通过大刘的指导，以及自身的不断钻研，小陈进步很快，已经初步掌握Kubernetes的基本概念和简单使用了。依小陈来看，搭建Kubernetes集群，维护集群的更新，是一件专业性比较强、且复杂繁琐的事情，有一定的学习门槛。

小陈：师傅，谢谢您的指点，我总算初步了解了Kubernetes。但问题是要基于容器集群搭建公司网站，Kubernetes平台建设和维护对我来说有点过于复杂了，好像不是很容易上手？

大刘：的确，Kubernetes对专业技能要求有一定的门槛，而且，仅仅搭建一套Kubernetes环境还不够，还需要有与之配套的监控、日志分析等功能。这些生态软件都自己建、自己管太费时间和精力了。其实可以选择云服务商提供的成熟的容器服务，如阿里云（Aliyun.com）的容器服务，它是基于Kubernetes云原生技术，根据云的特点进行优化改进，同时经过大量项目验证，可以直接使用，相比于自建Kubernetes，会轻松便捷许多

小陈：哦原来还有这种方式，那我先研究下阿里云的容器服务吧。

大刘：针对不同的用户需求场景，阿里云提供了几种类型的容器服务。先不着急下结论，你先了解一下，再来找我讨论。如何？

小陈：好的。

阿里云容器服务ACK

阿里云容器服务ACK（Alibaba Cloud Container Service for Kubernetes）是全球首批通过Kubernetes一致性认证的服务平台，提供高性能的容器应用管理服务，支持企业级Kubernetes容器化应用的生命周期管理，可以轻松高效地在云端运行Kubernetes容器化应用。

ACK具有如下特点：

• 基于Kubernetes云原生技术；
• 整合阿里云虚拟化、存储、网络和安全能力；
• 提供高性能可伸缩的容器应用管理能力；
• 简化集群的搭建和扩容等工作。

ACK的产品形态

阿里云容器服务ACK产品有三种形态：专有版Kubernetes、托管版Kubernetes、ACK Serverless。三个版本比较如下：

le data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

ACK三个版本的适用人群各有区分：

• 专有版ACK：懂技术、有运维K8S的能力、资源规划明显、Master节点定制、完全自营、成本不敏感
• 托管版ACK：Kubernetes能上手、不关心Master节点、只部署应用、降低成本
• Serverless版（ACK Serverless）：批量任务、突发扩容、开箱即用、零运维、按量付费、不关注基础设施

思考：选择容器服务的哪个版本更合适？

小陈学习并了解了ACK的三个版本之后，心里已经初步有了答案。按照之前和大刘的约定，再找大刘讨论一下。

小陈：师傅，阿里云容器服务的三个版本我都了解过了，在我看来，三个版本都很成熟。对于我们来说，考虑到现在业务上线、发布都还忙不过来，暂时不会去考虑自己去探索Kubernetes的功能特性，没那个时间、也没那个精力，我觉得应该把精力集中在我们的业务开发和管理上。所以，我觉得选择ACK Serverless可能更合适。

大刘：赞同，这个选择很明智。我也觉得ACK Serverless完全够用，免运维，开箱可用，就冲这一点，就能解放我们的手脚，不再受底层基础设施的牵绊。况且，按照公司业务发展迅猛的势头，公司网站访问量必定会不断突破，还有棘手的营销活动带来的突发访问问题，这些都可以放心交给ACK Serverless处理。咱们可以把精力聚焦在自己的业务上。

小陈：是的。那我再深入学习下ACK Serverless，到后面开始搭建应用的时候，再来找师傅给我一些建议。

大刘：好的。

容器服务Serverless版 ACK Serverless

ACK Serverless是阿里云推出的Serverless版Kubernetes容器服务。用户无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划，根据应用配置的CPU和内存资源量按需付费。ACK Serverless集群提供完善的Kubernetes兼容能力，同时降低了Kubernetes使用门槛，让用户更专注于应用程序，而不是管理底层基础设施。

添加图片注释，不超过 140 字（可选）

ACK Serverless集群与ACK集群的对比

集群中的Pod基于弹性容器实例ECI运行在安全隔离的容器运行环境中。

对于开发者而言，还有一项新用户福利：满足条件的阿里云用户，可以通过阿里云试用中心免费领取容器服务Serverless版 ACK Serverless：

提示：具体领用规则以试用中心页面的《试用规则》说明为准。

您可以访问阿里云免费试用页面：https://free.aliyun.com/

• 单击页面右上方的登录/注册按钮，并根据页面提示完成账号登录（已有阿里云账号）、账号注册（尚无阿里云账号）或实名认证（根据试用产品要求完成个人实名认证或企业实名认证）。
• 成功登录后，在产品类别下选择容器 > Serverless容器服务ACK Serverless，只要符合试用规则，单击立即试用即可完成领用。提示：用户须在领取时确认规格、地域等相关信息，领取成功后将不支持更改。
• 领取完成后，可以登录ACK Serverless管理控制台，即可找到并开始体验刚刚申领到的ACK Serverless资源。

添加图片注释，不超过 140 字（可选）

通过试用中心免费领用阿里云容器服务Serverless版 ACK Serverless

延伸阅读：弹性容器实例ECI

ACK Serverless底层基于弹性容器实例（ECI）来运行Pod，弹性容器实例ECI（Elastic Container Instance）是面向容器的无服务器弹性计算服务， 是跟 云服务器ECS 同级别的计算资源类产品，针对云原生时代的需求进行了针对性的改进和优化。

添加图片注释，不超过 140 字（可选）

• ECI是面向容器的无服务器弹性计算服务
• ECI提供免运维、强隔离、快速启动的容器运行环境
• 使用ECI无需购买和管理底层ECS服务器，让用户更加关注在容器应用而非底层基础设施的维护工作。

ACK Serverless主要特点

1、虚拟节点：ACK Serverless集群基于虚拟节点创建Pod，虚拟节点实现了Kubernetes与弹性容器实例ECI的无缝连接，让Kubernetes集群获得极大的弹性能力，而不必关心底层计算资源容量。

2、安全隔离：ACK Serverless集群中的Pod基于ECI运行在安全隔离的容器运行环境中，底层通过轻量级虚拟化安全沙箱技术完全强隔离，容器实例间互不影响；同时实例在调度时尽可能分布在不同的物理机上，进一步保障了高可用性。

3、Pod配置：支持原生的Kubernetes Pod功能，支持执行命令kubectl logs访问容器日志和执行kubectl exec进入容器，ECI支持多种规格配置的方式申请资源和计费。

4、应用负载管理：支持Deployment、StatefulSet、Job/CronJob、Pod、CRD等原生Kubernetes负载类型。

思考：基于ACK Serverless搭建企业网站主要工作有哪些？

准备开始基于ACK Serverless搭建WordPress企业网站了，小陈再去找大刘探讨，希望在网站搭建实践上能获得一些指导，少走一些弯路。

小陈：师傅。我马上要用ACK Serverless容器服务搭建公司网站了，这项任务的核心工作有哪些呢？

大刘：从大的方向上来看，主要是三项主要工作，1）创建ACK Serverless集群，并进行资源准备；2）在ACK Serverless集群上部署应用；3）对创建后的集群和应用进行查看和管理。

小陈：愿闻其详。

大刘：先说第一步。在阿里云控制台创建并生成ACK Serverless集群，然后要准备好部署应用所需要的资源，包括准备好WordPress网站所需的数据库、确定公司网站镜像可用、并准备好存放网站站点目录所需的持久存储。对了，你认为公司网站站点目录应该放到哪里？

小陈：应该放到容器集群之外吧，比如文件存储NAS？

大刘：是的，用NAS没问题。那么，接下来开始做第二步工作，即在ACK Serverless集群上部署应用。部署应用时要注意，创建的应用类型是无状态的，还要设置副本数量，副本数量需要根据前期评估的访问量进行设置。前面提到需要用NAS作为持久化存储，那么在ACK Serverless中要如何使用文件存储NAS呢？

小陈：首先需要创建PV和PVC，让PV要指向对应的NAS，才能把PVC给到应用集群使用。我理解对吗？

大刘：没错。是这样的。另外，还要创建服务，并开通负载均衡，让用户可以通过负载均衡访问服务。

小陈：明白了。到这里，第二步就做完了。后面还要做什么吗？

大刘：还有，在应用部署完成后，就开始第三步，应用集群的管理。从ACK Serverless控制台，熟悉并查看集群、无状态、容器组、服务等信息，查看容器日志，管理集群，还可以设置相应的监控和告警。

小陈：好的。

大刘：要注意一下，重点关注容器日志及监控情况。并持续观察一段时间容器组、日志、监控的信息及变化，了解信息中的含义，便于以后出现问题时，能知道在哪儿查，看什么信息。

小陈：好的，谢谢师傅！

构建和运行企业网站应用的主要步骤

基于ACK Serverless搭建公司网站应用，一共分为三大步骤，分别是：

1）创建ACK Serverless集群和准备资源；

2）部署与配置网站应用；

3）应用运维与集群管理。

我们将基于这三个步骤逐一展开介绍。

添加图片注释，不超过 140 字（可选）

基于ACK Serverless构建和运行网站应用的主要步骤

在这一步中，我们主要完成ACK Serverless容器集群的创建，同时准备好网站应用所需的NAS存储资源和数据库资源等。

添加图片注释，不超过 140 字（可选）

创建ACK Serverless集群

1. 创建ACK Serverless集群。

在这里我们可以看到阿里云容器服务ACK的不同版本，本次任务我们选择ACK Serverless集群进行资源创建。

添加图片注释，不超过 140 字（可选）

1. 配置组件（本次任务暂且不涉及），直接创建生成集群。

添加图片注释，不超过 140 字（可选）

容器集群的管理节点

大刘：考考你，之前应该学习过，Kubernetes是由控制平面的一个或多个管理节点（Master Node）和计算平面的多个工作节点（Worker Node）组成的。那么，刚创建的ACK Serverless集群相当于Kubernetes架构中的哪部分呢？

小陈：我理解ACK Serverless集群对应的应该是多个管理节点组成的控制平面吧。

大刘：没错。一个管理节点包含四个主要组件：API Server、Controller Manager、Scheduler 及 etcd，他们之间存在一定的协作关系，可以结合实践操作学习温顾一下。

小陈：好嘞。

添加图片注释，不超过 140 字（可选）

• API Server：Kubernetes集群的统一服务入口，负责资源的认证、鉴权以及CRUD（增删改查）等操作，提供Restful API接口，提供其他模块之间数据交互和通信的枢纽，API Server接收客户端发起的控制资源对象的API请求，将期望状态存储到etcd中。
• Controller Manager：所有资源对象的自动化控制中心，完成对集群内Node、Pod、Service等资源状态的管理，确保集群始终处于预期的工作状态；
• Scheduler：Pod资源对象的调度服务。将待调度的 Pod 按照一定的调度算法和策略绑定到合适的Node节点上，并将绑定信息写入到 etcd 中；
• etcd：是一个分布式的存储系统，所有Kubernetes资源对象的数据，都放置在 etcd 中，etcd 本身是一个高可用系统。

准备资源

1. 准备公司网站WordPress的应用镜像；

提前构建好WordPress网站应用的镜像，并上传到镜像服务ACR中。现在直接基于镜像部署应用，选择位于ACR仓库中的WordPress网站应用镜像。

添加图片注释，不超过 140 字（可选）

ACR是阿里云容器镜像服务，可以用于镜像的托管和全生命流程管理。关于如何制作应用容器镜像及托管至ACR服务，可以回顾上一阶段的课程《基于容器搭建企业级应用》。

1. 创建用于存放公司网站WordPress站点目录的NAS；

通过文件存储NAS的控制台，选择通用型NAS，配置NAS的协议类型NFS等参数，完成创建。

添加图片注释，不超过 140 字（可选）

NAS创建完成后，记录其挂载点地址，后续ACK Serverless存储卷的挂载点将使用该地址。

1. 创建用于保存企业网站WordPress结构化数据的云数据库MySQL；

WordPress网站的数据库独立于ACK Serverless集群，由于公司网站业务的访问存在明显的波动特征，为了让数据库也能匹配业务波动，我们选择了免运维、计算资源能自动弹性扩缩容的RDS MySQL Serverless实例。

添加图片注释，不超过 140 字（可选）

至此，第一步集群创建和资源准备的工作就完成了。

在这一步中，我们主要基于ACK Serverless集群进行网站应用的部署，同时准备好网站应用所需的NAS存储资源和数据库资源等。

添加图片注释，不超过 140 字（可选）

容器组与Pod

小陈：好了，现在已经创建完ACK Serverless集群，接下来就可以开始部署网站应用了吧？

大刘：是的，不过在此之前，先巩固一下理论知识。考考你，我们的网站应用运行在容器里，那怎么来调度容器资源呢？

小陈：之前学Kubernetes的时候有一个Pod的概念，Pod里面包含一组容器，它是Kubernetes调度资源的原子单位。可是……Pod在哪儿呢，好像没看到？

大刘：没错，你看ACK Serverless界面的左侧，有一个标签叫容器组，它就对应Kubernetes中的Pod。

小陈：哦，原来是这样，多谢师傅提醒。

在操作系统中，进程并不是"孤苦伶仃"的运行，而是以进程组的方式、"有原则的"组织在一起运行，一个进程组内的进程可以共享文件和资源。Kubernetes借鉴了操作系统中"进程组" 的概念，并抽象出一个逻辑概念Pod。Pod是一组紧密关联的容器集合，也可以称为容器组。Pod是Kubernetes中操作和资源调度的基本单元。为了便于理解，我们可以做个类比，Kubernetes就是一个操作系统，就像Linux；Pod就是一个进程组，就像Linux线程组；容器就是一个进程，就像Linux线程。

添加图片注释，不超过 140 字（可选）

容器组Pod的组成

在ACK Serverless中部署应用

1. 创建存储卷，指向之前创建的NAS，同时创建对应的存储声明，提供给容器组（Pod）使用。

添加图片注释，不超过 140 字（可选）

ACK Serverless中的存储卷就就对应前面学习过的Kubernetes中的PV（Persistent Volume）， PV是一种持久化的存储，独立于集群而存在，与Pod容器组的生命周期无关。

PV不能与Pod直接关联，而是用来和存储对接的，用于绑定后端存储，比如NAS文件系统就是一种常见的后端存储类型，写入PV的数据最终都是存放在后端存储上。Kubernetes通过PVC即存储声明的方式来管理和使用PV存储卷。PVC可以直接被Pod挂载，同时可以绑定PV，从而让Pod使用PV；PVC与挂载它的Pod隶属于同一个命名空间Namespace。下图表示了Pod与PVC、PV的关系。

添加图片注释，不超过 140 字（可选）

1. 在ACK Serverless控制台工作负载的无状态标签下，使用镜像创建无状态应用。

添加图片注释，不超过 140 字（可选）

【延伸阅读】工作负载 Workload

这里的工作负载就对应前面Kubernetes中工作负载 Workload的概念。工作负载通常有如下几种类型：

• 无状态（Deployment）：表示对Kubernetes集群的一次更新操作，用于运行完全独立、功能相同应用的场景。
• 有状态（StatefulSet）：支持应用部署、扩容、滚动升级时有序进行。如使用有状态来管理使用了持久存储的应用。
• 任务（Job）：它创建出来的Pod只要完成任务就立即退出，用于执行一次性任务。可以使用Job以并行的方式运行多个 Pod。
• 定时任务（CronJob）：它创建的Pod会周期性的执行，用于执行周期性任务。
• 自定义资源（Custom Resource Definitions，CRD）：可以通过CRD添加第三方工作负载资源。

本次任务中采用无状态的工作负载类型来承载网站应用。

a）设置应用基本信息：设置应用名称、副本数量、类型为无状态等。

添加图片注释，不超过 140 字（可选）

本次采用无状态工作负载部署应用，选择default的命名空间Namespace。通常，我们会构建开发、测试、准生产、生产等多套应用环境，每套环境中都会创建一个ACK Serverless集群，几套环境中的无状态工作负载、容器组、服务名字都相同，而ACK Serverless集群中要求这些资源名称要唯一。这就需要这些环境创建时，通过命名空间进行资源的有效隔离。

这里的“副本数量”其实就对应Kubernetes里ReplicaSet的副本数，是因为无状态工作负载（Deployment）是通过控制ReplicaSet，来实现对Pod数量的控制。

b）容器配置：设置镜像名称、镜像Tag、所需资源的CPU和内存、新增端口并指定容器端口、数据卷增加云存储声明并指定容器路径；

添加图片注释，不超过 140 字（可选）

这里选择的镜像名称，就是我们已经提前准备好的，存放于ACR镜像服务中的WordPress公司网站应用的镜像。

下图增加PVC，这里PVC也是前面准备好的，通过PV绑定了文件存储的挂载点。

添加图片注释，不超过 140 字（可选）

c）高级配置：创建服务，类型为负载均衡，外部流量策略为Cluster，设置服务端口并映射到容器端口。这里的服务就对应前面提到过的Kubernetes中的Service。

添加图片注释，不超过 140 字（可选）

【延伸阅读】容器集群的访问

Service解决了服务发现和负载均衡的问题，但外部用户直接访问Service并不是最佳的方案，原因如下：

• Service提供的是IP+端口的访问服务，需要访问对应的NodeIP:Port，对于已经习惯了使用域名的用户不是特别友好。
• 由于NodePort的访问方式，需要指定Node节点的端口，一旦服务多起来，多个端口难以管理。
• Service本身也可能被销毁重建，从而使得Service的地址也会发生变化。

为了解决上述问题，这里通过搭建外部负载均衡，并将流量转发到Service上来解决。Service与负载均衡搭配后的访问流程如下：

添加图片注释，不超过 140 字（可选）

1. 完成应用的创建，ACK Serverless将先后完成无状态工作负载和服务的创建。

添加图片注释，不超过 140 字（可选）

容器集群的工作（计算）节点

大刘：再问你一个问题，之前学习过，Kubernetes由管理节点和工作节点构成。但你注意到了吗，在刚刚创建ACK Serverless集群以及部署应用的过程中，并没有直接创建工作节点。

小陈：是的呢，我也发现了，这是为什么？

大刘：这是因为我们选择了ACK Serverless服务，ACK Serverless是容器服务的Serverless版本，Serverless的优点就是无需购买节点、无需对集群进行节点维护和容量规划，可以直接使用。ACK Serverless会按需、自动的创建好工作节点资源，所以我们不需要手动创建工作节点。

小陈：原来如此，确实方便了很多呀。

我们先来回忆一下工作节点的知识，工作节点是Kubernetes的工作负载节点，主要包含三个组件：kubelet、kube-proxy、Container Runtime。

添加图片注释，不超过 140 字（可选）

• kubelet：负责管理节点上容器的创建、删除、启停等任务，与管理节点通信。
• kube-proxy：负责Kubernetes服务的通信及负载均衡服务。
• Container Runtime：负责容器的基础管理服务，接收kubelet组件的指令。

ACK Serverless是容器服务Serverless版，无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划。ACK Serverless通过虚拟节点直接管理ECI，每个ECI对应一个Pod，而不是像自建Kubernetes那样需要采用ECS作为工作节点。ACK Serverless与自建Kubernetes工作节点的架构比较如下：

添加图片注释，不超过 140 字（可选）

配置网站应用信息

1. 获取应用访问地址，通过浏览器访问。

添加图片注释，不超过 140 字（可选）

1. 访问应用完成配置：创建数据库账号，给数据库账号赋权，初始化WordPress页面配置，并访问网站管理等。

添加图片注释，不超过 140 字（可选）

创建数据库账号，并赋权数据库账号；获取数据库的账号信息，配置到应用配置中；最后，完成网站应用的安装与配置。

添加图片注释，不超过 140 字（可选）

完成网站应用的部署之后，在这一步中，我们体验一下通过ACK Serverless可以如何对应用容器集群进行基本的运维和管理。

添加图片注释，不超过 140 字（可选）

查看应用集群

1. 查看集群

在ACK Serverless控制台点击集群名称，可以查看容器集群信息、无状态应用信息、服务信息、容器组信息等。

添加图片注释，不超过 140 字（可选）

查看集群的基本信息，我们还可以查看连接信息、集群资源、集群日志、集群任务等信息。如下图：

添加图片注释，不超过 140 字（可选）

可以查看工作负载无状态的情况。我们还可以查看容器组（Pod）、访问方式、事件、容器伸缩、历史版本、日志、触发器等信息。如下图：

添加图片注释，不超过 140 字（可选）

1. 查看容器日志

可以在ACK Serverless控制台观察容器的日志信息，并可根据关键字检索日志信息。

添加图片注释，不超过 140 字（可选）

集群管理与监控

1. 安装并查看Prometheus监控

Prometheus是一个开源的系统监控和报警系统，在kubernetes中常常会搭配Prometheus进行监控，Prometheus性能足够支撑上万台规模的集群。ACK Serverless中集成了Prometheus服务，可以安装Prometheus，完成对ACK Serverless集群的监控。

添加图片注释，不超过 140 字（可选）

查看Prometheus的情况，可查看监控概况、核心组件监控、应用监控等其他监控。

添加图片注释，不超过 140 字（可选）

1. 管理集群。

通过手动删除Pod，模拟一个Pod上的应用异常下线的情形，体验ACK Serverless的自动恢复功能，并观察Pod恢复过程中的状态变化。

添加图片注释，不超过 140 字（可选）

删除一个Pod后，容器组会自动自愈，下图是观察ACK Serverless恢复过程的情况。

添加图片注释，不超过 140 字（可选）

至此，我们通过ACK Serverless完成了企业网站应用的创建和部署，并了解ACK Serverless对于容器集群的基础管理和运维监控能力。

本课程的关键知识点总结：

1. 容器编排是指自动化容器的部署、管理、扩展和联网。通过容器编排，可以构建跨多个容器的应用服务、跨集群调度容器、扩展这些容器，并持续管理它们的健康状况。
2. Kubernetes是一个开源的容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。Kubernetes由负责管理和控制的一个或多个Master节点，及多个负责工作负载的Worker节点构成。Kubernetes的原子调度单位是Pod，Pod是一个逻辑概念，是一组紧密关联的容器的集合，也叫容器组。Kubernetes就像一个操作系统，Pod就像一个进程组，容器就像一个进程。
3. Kubernetes有如下基本概念：

• Pod（容器组）： Pod是一个逻辑概念，是一组紧密关联的容器的集合。
• Controller（控制器）：控制器通过控制循环监控集群状态，将当前状态转变为期望状态。控制器包含节点控制器、命名空间控制器、工作负载控制器等多种。
• Workload（工作负载）：工作负载是在 Kubernetes 上运行的应用程序，分为无状态、有状态、任务、定时任务等多种类型。
• Service（服务）：将运行在一个或一组Pod上的应用程序公开为网络服务的方法，是真实应用服务的抽象。
• PV、PVC（存储卷及存储声明）：PV是存储卷，是集群内的存储资源，PV独立于Pod的生命周期。PVC是存储卷声明，是资源的使用者。Pod挂载PVC，PVC消耗PV资源。
• Namespace（命名空间）：命名空间为容器集群提供虚拟的隔离作用。
• etcd：etcd是一个分布式、一致且高可用的键值存储系统，用作Kubernetes所有集群数据的后台数据库。

1. ACK是阿里云推出的容器服务，是全球首批通过Kubernetes一致性认证的服务平台，提供高性能的容器应用管理服务，支持企业级Kubernetes容器化应用的生命周期管理，让用户轻松高效地在云端运行Kubernetes容器化应用。ACK包含专有版、托管版和Serverless版（ACK Serverless）三种形态。
2. ACK Serverless是阿里云容器服务Serverless版。用户无需购买节点即可直接部署容器应用，无需对集群进行节点维护和容量规划，根据应用配置的CPU和内存资源量按需付费。
3. 基于ACK Serverless搭建企业网站，包含三个主要步骤：

• 创建ACK Serverless集群：创建ACK Serverless集群，不配置额外组件。
• 部署应用：基于镜像创建无状态工作负载，配置存储，通过负载均衡提供服务。
• 查看和管理集群：查看集群、容器组等信息、配置监控并管理集群。

通过本课程，我们基于ACK Serverless构建了公司网站的容器集群，完成了网站应用的上线。但如果要进一步运营好公司网站，仍然面临网站应用升级等一系列实际使用的问题，比如：

• 如何实现网站应用的版本更新
• 在应用更新和发布过程中需要关注哪些问题
• 基于容器的应用更新发布最佳实践

在后续课程中，我们将继续介绍这些方面的内容，欢迎持续关注和学习。

本节为课程延伸学习内容，对Kubernetes的设计思想、核心概念和机制进行介绍，以便帮助您更好的理解容器集群与编排技术。

Kubernetes 设计思想

Kubernetes 基于API管理一切的思想，采用声明式即“面向结果”的API，围绕 etcd（分布式存储与协调数据库） 构建出来的一套 “面向终态” 的编排体系。

当用户向 Kubernetes 提交了一个 API 对象（Kubernetes Object）的期望状态（Spec）之后，Kubernetes 会负责保证整个集群里各项资源的当前状态（Status），都与 API 对象描述的需求相一致。更重要的是，这个保证是一项 “无条件的”、“没有期限” 的承诺：对于每个保存在 etcd 里的 API 对象，Kubernetes 都通过启动一种叫做 “控制器模式”（Controller Pattern）的无限循环，不断对 etcd 里的 API 对象的变化进行监视（Watch），然后执行控制器（Controller）里定义的编排动作的响应逻辑，进行调谐，最后确保整个集群的状态与 API 对象的描述一致。

添加图片注释，不超过 140 字（可选）

为了实现“面向终态”的管理，支持自动化部署、扩缩和管理容器应用，Kubernetes采用了控制平面和计算平面分离的架构。控制平面是整个集群的大脑，负责控制、调度集群资源；计算平面负责运行容器化应用，是控制平面调度的对象，通过增加或减少工作节点实现容器集群处理能力的扩缩。控制平面由至少一个管理节点（Master节点）组成，通常会采用三个管理节点组成高可用集群（一个管理节点提供服务，剩下两个管理节点为备用节点，当管理节点不可用时，从备用节点中自动选举一个出来成为管理节点）。计算平面则由多个工作节点（Node节点）组成。

添加图片注释，不超过 140 字（可选）

1.Master节点

Master节点（管理节点）主要负责管理和控制整个Kubernetes集群，对集群做出全局性决策，相当于整个集群的“大脑”。集群所执行的所有控制命令都由Master节点接收并处理。它在集群中主要负责如下任务：

• 集群的“大脑”，负责管理所有Node节点。
• 负责调度Pod在哪些节点上运行。
• 负责控制集群运行过程中的所有状态。

一个管理节点包含四个主要组件：API Server、Controller Manager、Scheduler 及 etcd。

2.Node节点

Node节点（工作节点）是Kubernetes集群中的工作节点，Node节点上的工作由Master节点进行分配，比如当某个Node节点宕机时，Master节点会将其上面的工作转移到其他Node节点上。Node节点在集群中主要负责如下任务：

• 负责管理所有容器（Container）。
• 负责监控/上报所有Pod的运行状态。

一个Node节点主要包含三个组件：kubelet、kube-proxy、Container Runtime。

Controller是什么？

工作负载是一种Controller，在Kubernetes中还有Node Controller等其他多种控制器。每种控制器都是一个智能系统，通过API Server提供的(List-Watch)接口实时监控集群中资源对象的变化，当资源对象因某些原因发生状态变化时，Controller会执行相应逻辑使其最终状态调整到期望状态。比如：某个Node意外宕机时，Node Controller会及时发现此故障并执行自动化修复流程，确保集群始终处于预期的工作状态。

每种Controller都负责一种特定的资源控制器，Controller Manager是Kubernetes中各种Controller的管理者，是集群内部的管理控制中心，也是Kubernetes自动化功能核心。

添加图片注释，不超过 140 字（可选）

Kubernetes中如何实现多个环境的隔离？

在Kubernetes容器集群中，同一类型的资源名称是唯一的。在实际中，我们往往需要将不同业务、不同的项目、不同的环境进行隔离管理，这就需要通过命名空间Namespace进行分区管理。

Namespace 是用来做集群内部的逻辑隔离的，它包括鉴权、资源管理等。Kubernetes 的每个资源，比如 Pod、Deployment、Service，都属于一个 Namespace，同一个 Namespace 中的资源命名唯一，不同的 Namespace 中的资源可以重名。在一个Kubernetes集群中可以拥有多个命名空间，它们在逻辑上彼此隔离。

不过，Kubernetes也有一些资源隶属于集群级别的，如Node、Namespace和Persistent Volume等，不属于任何名称空间，所以这些资源对象的名称必须全局唯一。

Kubernetes的原子调度单位Pod

在操作系统中，进程不是"孤苦伶仃"的运行，而是以进程组的方式，"有原则的"组织到一起运行。一个进程组内的进程可以共享文件和资源。Kubernetes借鉴了操作系统的"进程组" 的概念，并抽象出一个逻辑概念Pod。由于Pod是一组紧密关联的容器集合，也叫它容器组。Pod是Kubernetes中操作的基本单元。为了便于理解，我们可以做个类比，Kubernetes就是一个操作系统，就像Linux；Pod就是一个进程组，就像Linux线程组；容器就是一个进程，就像Linux线程。

添加图片注释，不超过 140 字（可选）

Kubernetes把Pod作为原子调度单位，主要有两个原因：

1. 有的业务需要多个容器一起协作才能完成，如业务容器产生日志，并通过日志采集容器将日志传输到日志系统中进行分析。这两个容器构成一个容器组，密切协作，不能拆分。如果没有Pod，这两个容器就可能被分别调度到不同的Node节点上，导致无法正常工作。需要注意的是，Pod中只会有一个主容器，其他容器只能是辅助容器。
2. 若Kubernetes直接管理容器，由于容器销毁就没法跟踪了，难以了解容器的真实状态。通过Pod作为调度单位，因其支持健康检查，可以了解容器存活状况。

在创建无状态工作负载过程中，Kubernetes都做了哪些事情呢？

延伸阅读：无状态Pod的创建流程

我们知道无状态工作负载Deployment创建容器组，是通过控制ReplicaSet来实现的，下面我们了解下ReplicaSet创建Pod 的详细流程。

添加图片注释，不超过 140 字（可选）

图中有三个 List-Watch，分别是 Controller Manager（运行在 Master），Scheduler（运行在 Master），kubelet（运行在 Node）。它们在进程一启动就会监听（Watch）API Server 发出来的事件。我们来看下创建的12个步骤。

1. 用户通过 kubectl 或其他 API 客户端，提交请求给 API Server 来建立一个 Pod 对象副本（ReplicaSet）。
2. API Server 将 Pod 对象的相关元信息存入 etcd 中，待写入操作执行完成，API Server 即会返回确认信息至客户端。
3. 当 etcd 接受创建 Pod 信息以后，会发送一个 Create 事件给 API Server。
4. 由于 Controller Manager 一直在监听（Watch，通过http的8080端口）API Server 中的事件。此时 API Server 接收到了 Create 事件，又会发送给 Controller Manager。
5. Controller Manager 在接到 Create 事件以后，调用其中的 ReplicaSet（简称RS）来保证 Node 上面需要创建的副本数量。一旦副本数量少于 RS 中定义的数量，RS 会自动创建副本。总之它是保证副本数量的 Controller（扩容缩容的担当）。
6. 在 Controller Manager 创建 Pod 副本以后，API Server 会在 etcd 中记录这个 Pod 的详细信息。例如 Pod 的副本数，Container 的内容是什么。
7. 同样， etcd 会将创建 Pod 的信息通过事件发送给 API Server。
8. 由于 Scheduler 在监听（Watch）API Server，并且它在系统中起到了“承上启下”的作用，“承上”是指它负责接收创建的 Pod 事件，为其安排 Node；“启下”是指安置工作完成后，Node 上的 kubelet 进程会接管后继工作，负责 Pod 生命周期中的“后半生”。 换句话说，Scheduler 的作用是将待调度的 Pod 按照调度算法和策略绑定到集群中 Node 上。
9. Scheduler 调度完毕以后会更新 Pod 的信息，此时的信息更加丰富了。除了知道 Pod 的副本数量，副本内容。还知道部署到哪个 Node 上面了。并将上面的 Pod 信息更新至 API Server，由 API Server 更新至 etcd 中，保存起来。
10. etcd 将更新成功的事件发送给 API Server，API Server 也开始反映此 Pod 对象的调度结果。
11. kubelet 是在 Node 上面运行的进程，它也通过 List-Watch 的方式监听（Watch，通过https的6443端口）API Server 发送的 Pod 更新的事件。kubelet 会尝试在当前节点上调用容器运行时启动Pod，并将 Pod 以及容器的结果状态回送至 API Server。
12. API Server 将 Pod 状态信息存入 etcd 中。在 etcd 确认写入操作成功完成后，API Server将确认信息发送至相关的 kubelet，事件将通过它被接受。

注意：在完成Pod的创建之后，kubelet 还会一直保持监听，为什么？原因很简单，客户可能有新的请求，如kubectl 发出命令要求扩充 Pod 副本数量，那么上面的流程又会触发一遍，kubelet 会根据最新的 Pod 的部署情况调整 Node 的资源。又或者 Pod 副本数量没有发生变化，但是其中的镜像文件升级了，kubelet 也会自动获取最新的镜像文件并且加载。

Pod内如何实现数据共享？

Volume是Pod中能够被多个容器访问的共享目录，通过Volume可以让容器的数据写到宿主机上或者写文件到网络存储中。

添加图片注释，不超过 140 字（可选）

Kubernetes中的Volume与Docker的Volume相似，但不完全相同。

• Kubernetes的Volume定义在Pod上，然后被一个Pod中的多个容器挂载到具体的文件目录下。
• Kubernetes的Volume与Pod生命周期相关，而与容器的生命周期无关，即容器挂掉，数据不会丢失。但是Pod挂掉，数据则会丢失。

Kubernetes的Volume使用方法，是先在Pod上声明一个Volume，然后容器引用该Volume并Mount到容器的某个目录。

Volume有emptyDir和hostPath两种类型。emptyDir是在Pod分配到Node时创建，初始内容为空，无须指定宿主机上对应的目录文件，由Kubernetes自动分配一个目录，当Pod被删除时，对应的emptyDir数据会永久删除。hostPath则是在Pod上挂载宿主机上的文件或目录，与Pod的销毁无关。

Kubernetes的数据如何持久存储？

Kubernetes是通过PV和PVC来实现集群数据的持久化的。

• PV即Persistent Volume ，是集群中由管理员配置的一段网络存储，是集群的全局资源，不属于任何命名空间。PV生命周期独立于使用PV的任何单个Pod，不和Pod有生命周期牵扯，独立存活。
• PVC即Persistent Volume Claim ，是由用户进行存储的请求。也就是说，PVC就是调用PV，访问储存。Pod不能直接使用PV，必须挂载PVC，在PVC绑定PV，Pod才能访问存储。PVC和PV是一一对应的，PVC与挂载它的Pod隶属于同一个命名空间。

工作负载（Workload）是什么？

为了减轻用户的使用负担，通常不需要用户直接管理每个 Pod。 而是使用工作负载资源来替用户管理一组Pod，比如启动指定数量的Pod或实现容器应用的滚动升级。工作负载是在 Kubernetes 上运行的应用程序，是一种控制器。

添加图片注释，不超过 140 字（可选）

工作负载是管理Pod的中间层，使用了工作负载之后，只需要告诉它，想要多少个、什么样的Pod就可以了，它就会创建出满足条件的Pod，并确保每一个Pod处于用户期望的状态，如果Pod在运行中出现故障，控制器会基于指定策略重启或者重建Pod。

Kubernetes集群应用的访问

通过工作负载我们创建了一组Pod出来，由于Pod会被销毁后重启，或者会增加新的Pod。用户怎么能访问这些Pod呢？ Pod地址是变化的，不能直接访问。能否提供一个固定的访问Pod的入口，不用关心Pod地址的变化呢？

Kubernetes通过Service为一组功能相同的pod提供稳定的访问地址，Service是一个抽象的概念，它定义了Pod的逻辑分组和一种可以访问它们的策略，这组Pod能被Service访问。Service是如何识别这些Pod的呢？通过选择器Selector来识别成员Pod。需要注意的是，Service后端不一定是Pod，可能是Kubernetes集群外的物理机，如MySQL数据库。

添加图片注释，不超过 140 字（可选）

Service是通过Selector选择的一组Pods的服务抽象，提供了服务的负载均衡和反向代理的能力。实现 Service 负载均衡和反向代理功能，是通过kube-proxy实现的。kube-proxy 运行在每个节点上，监听 API Server 中服务对象的变化，通过管理 iptables 来实现网络的转发。

添加图片注释，不超过 140 字（可选）

Service的负载均衡实现的过程共分为五步，如下：

1. 运行在每个Node节点的kube-proxy会实时的watch Service和Endpoints（IP+端口）对象， 当用户在Kubernetes集群中创建了含有Label的Service之后，同时会在集群中创建出一个同名的Endpoints对象，用于存储Service下的Pod IP。
2. 当每个Node节点的kube-proxy感知到Service和Endpoints的变化之后，会在各自的Node节点上打开代理端口，并设置相关的iptables或IPVS转发规则。
3. 客户端访问Service的ClusterIP。
4. 客户端请求会经过iptables/IPVS，会被重定向到kube-proxy的代理端口。IPVS模式的调度由IPVS完成，其他功能仍是iptables实现。
5. kube-proxy将请求发送到真实的后端Pod。

Service的访问方式

Service的访问方式有多种，如下：

• ClusterIP： 默认类型，自动分配一个仅Cluster内部可以访问的虚拟IP
• NodePort： 在ClusterIP基础上为Service在每台机器上绑定一个端口，这样就可以通过NodeIP:Port方式来访问该服务
• LoadBalancer: 在NodePort基础上，接触cloud provider创建一个外部负载均衡器，并将请求转发到NodeIP:Port

由于Service只提供了四层服务，若要通过Http/Https的七层访问方式访问服务，则需要通过LoadBalancer的方式，将访问流量转发到Service上来实现。

点击如下链接，进入实验练习环节：

教学练习实验

如果您已经完成课程学习和实验练习，可以进入以下页面激活认证流程：

激活认证流程

激活认证流程后，进入个人中心完成考试：

认证考试

添加图片注释，不超过 140 字（可选）