一、前言

K8S经过多年的发展，构建了云原生的基石，成为了云原生时代的统治者。我将用三个博客系列全面，循序渐进的介绍K8S相关知识。

初级入门系列，主要针对K8S初学者，以及希望对K8S有所了解的研发人员，重点介绍K8S的使用，包括核心概念，yaml文件等，并配合一些简单的案例进行练习，能达到了解K8S的目标。

中级原理系列，主要针对K8S有一定研究的架构师，开发人员等，深度剖析K8S核心架构组件以及实现原理，能达到理解K8s的目标。

高级实战系列，主要针对K8S的架构，研发，运维人员，结合周边产品，构建整体的K8S生态体系，将相关知识点运用到实践，能达到掌握和使用K8S的目标。

千里之行，始于足下，Let's go！

二、云计算发展历史

在讲K8S之前，我们先了解下整个云计算的发展历史，这样有助于更加全面的了解和认识K8S的前生今世。计算的设施经历了物理机，虚机以及目前的云原生时代。

1、物理机时代

物理机时代，所有的服务都直接部署到物理机上。其架构示意图如下：

这种模式部署简单，对于早期的单体应用来说，能基本满足要求。但这种模式最大的问题是资源无法有效利用，无法"平民化"。

2、虚机时代

随着互联网的兴起，一方面线上流量呈指数级增长，另一方面对于初创的互联网企业，没有足够的资金购买大量的设备资源，如何利用技术解决成本问题，成为各厂商面临的主要问题。这个时期内，诞生了诸如分布式技术，虚拟化技术等等。

虚拟化（英语：Virtualization）是一种资源管理技术，是将计算机的各种实体资源，如服务器、网络、内存及存储等，予以抽象、转换后呈现出来，打破实体结构间的不可切割的障碍，使用户可以比原本的组态更好的方式来应用这些资源。这些资源的新虚拟部分是不受现有资源的架设方式，地域或物理组态所限制。虚拟化技术就是把物理资源(服务器，网络，硬件，CPU)进行隔离的技术。

在计算机的系统中，从底层至高层依次可分为硬件层、操作系统层、函数库层、应用程序层，每一层都可以实现虚拟化，这里主要是指硬件层的虚拟化，又称系统级虚拟化。系统级虚拟化从类型上又可以分为完全虚拟化和类虚拟化。

完全虚拟化，完全虚拟化的虚拟平台和现实平台是一样的，客户机操作系统察觉不到是运行在一个虚拟平台上，这样的虚拟平台可以运行现有的操作系统，无须对操作系统进行任何修改，因此这种方式被称为完全虚拟。在当前的系统级虚拟化解决方案中，完全虚拟化技术应用非常普遍，典型的有知名的产品有VirtualBox、KVM、VMware Workstation和VMware ESX（它在其4.0版，被改名为VMware vSphere）、Xen（也支持全虚拟化）。
类虚拟化，这样的虚拟平台需要对所运行的客户机操作系统进行或多或少的修改使之适应虚拟环境，因此客户机操作系统知道其运行在虚拟平台上，并且会去主动适应。这种方式被称为类虚拟化，有时也称作半虚拟化。这种虚拟技术以Xen为代表，微软的Hyper-V所采用技术和Xen类似，也可以把Hyper-V归属于半虚拟化。

其架构模型示意图如下：

VMM(Virtual Machine Manager)首先可以被看做是一个完备的操作系统，不过和传统操作系统不同的是，VMM是为虚拟化而设计的，因此还具备虚拟化功能。从架构上来看，首先，所有的物理资源如处理器、内存和I/O设备等都归VMM所有，因此，VMM承担着管理物理资源的责任；其次，VMM需要向上提供虚拟机用于运行客户机操作系统，因此，VMM还负责虚拟环境的创建和管理。

接下来我们来认识下重要的虚拟化的产品。

(1)VMware

VMware是x86 虚拟化软件的主流广商之一，提供一系列的虚拟化产品，其产品的应用领域从服务器到桌面。下面是VMware主要产品的简介，包括VMware ESX、VMware Server和VMware Workstation。

VMware ESX Server是VMware的旗舰产品，后续版本改称VMware vSphere。ESX Server基于Hypervisor模型，在性能和安全性方面都得到了优化，是一款面向企业级应用的产品。VMware ESX Server支持完全虚拟化，可以运行Windows 、Linux、Solaris和Novell Netware等客户机操作系统。VMware ESX Server也支持类虚拟化，可以运行Linux 2. 6. 21 以上的客户机操作系统。

VMware Server之前叫VMware GSX Server，是VMware面向服务器端的入门级产品。宿主机操作系统可以是Windows或者Linux。VMware Server的功能与ESX Server类似，但是在性能和安全性上与ESX Server有所差距。

VMware Workstation是VMware面向桌面的主打产品。宿主机操作系统可以是Windows或者Linux。专门针对桌面应用做了优化，如为虚拟机分配USB设备，为虚拟机显卡进行3D加速等。

(2)Xen

Xen是一款基于GPL授权方式的开源虚拟机软件。Xen起源于英国剑桥大学Ian Pratt领导的一个研究项目，之后，Xen独立出来成为一个社区驱动的开源软件项目。

它是运行在裸机上的虚拟化管理程序(Hypervisor)。它支持全虚拟化和半虚拟化，Xen支持hypervisor和虚拟机互相通讯，而且提供在所有Linux版本上的免费产品，包括Red Hat Enterprise Linux和SUSE Linux Enterprise Server。Xen最重要的优势在于半虚拟化，此外未经修改的操作系统也可以直接在xen上运行(如Windows)，能让虚拟机有效运行而不需要仿真，因此虚拟机能感知到hypervisor，而不需要模拟虚拟硬件，从而能实现高性能。

(3)KVM

KVM(Kernel-based Virtual Machine)，也是一款基于GPL授权方式的开源虚拟机软件。KVM 最早由Qumranet公司开发，在2006年出现在Linux内核的邮件列表上，并于2007年被集成到了Linux 2.6.20内核中，成为内核的一部分。

它集成到Linux内核的Hypervisor，是X86架构且硬件支持虚拟化技术(Intel VT或AMD-V)的Linux的全虚拟化解决方案。它是Linux的一个很小的模块，利用Linux做大量的事，如任务调度、内存管理与硬件设备交互等。

KVM还可以结合QEMU来提供设备虚拟化。

(4)QEMU

QEMU是一套由Fabrice Bellard所编写的模拟处理器的自由软件。它与Bochs，PearPC近似，但其具有某些后两者所不具备的特性，如高速度及跨平台的特性。经由kqemu这个开源的加速器，QEMU能模拟至接近真实电脑的速度。

QEMU本身可以不依赖于KVM，但是如果有 KVM的存在并且硬件(处理器)支持比如Intel VT功能，那么QEMU在对处理器虚拟化这一块可以利用KVM提供的功能来提升性能。换言之，KVM缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具，所以它借用了QEMU的代码并加以精简，连同KVM一起构成了一个完整的虚拟化解决方案，不妨称之为：KVM+QEMU。

（5）OpenStack

不同于前面的几个产品，Openstack是一个云管平台项目，由美国国家航空航天局和Rackspace在2010年末合作研发的开源项目，旨在打造易于部署、功能丰富且易于扩展的云计算平台。OpenStack项目的首要任务是简化云的部署过程并为其带来良好的可扩展性，企图成为数据中心的操作系统，即云操作系统。

OpenStack覆盖了网络、虚拟化、操作系统、服务器等各个方面。其核心的组件如下：

计算（Compute）：Nova。一套控制器，用于为单个用户或使用群组管理虚拟机实例的整个生命周期，根据用户需求来提供虚拟服务。负责虚拟机创建、开机、关机、挂起、暂停、调整、迁移、重启、销毁等操作，配置CPU、内存等信息规格。自Austin版本集成到项目中。
对象存储（Object Storage）：Swift。一套用于在大规模可扩展系统中通过内置冗余及高容错机制实现对象存储的系统，允许进行存储或者检索文件。可为Glance提供镜像存储，为Cinder提供卷备份服务。自Austin版本集成到项目中。
镜像服务（Image Service）：Glance。一套虚拟机镜像查找及检索系统，支持多种虚拟机镜像格式（AKI、AMI、ARI、ISO、QCOW2、Raw、VDI、VHD、VMDK），有创建上传镜像、删除镜像、编辑镜像基本信息的功能。自Bexar版本集成到项目中。
身份服务（Identity Service）：Keystone。为OpenStack其他服务提供身份验证、服务规则和服务令牌的功能，管理Domains、Projects、Users、Groups、Roles。自Essex版本集成到项目中。
网络&地址管理（Network）：Neutron。提供云计算的网络虚拟化技术，为OpenStack其他服务提供网络连接服务。为用户提供接口，可以定义Network、Subnet、Router，配置DHCP、DNS、负载均衡、L3服务，网络支持GRE、VLAN。插件架构支持许多主流的网络厂家和技术，如OpenvSwitch。自Folsom版本集成到项目中。
块存储 (Block Storage)：Cinder。为运行实例提供稳定的数据块存储服务，它的插件驱动架构有利于块设备的创建和管理，如创建卷、删除卷，在实例上挂载和卸载卷。自Folsom版本集成到项目中。
UI 界面 (Dashboard)：Horizon。OpenStack中各种服务的Web管理门户，用于简化用户对服务的操作，例如：启动实例、分配IP地址、配置访问控制等。自Essex版本集成到项目中。
测量 (Metering)：Ceilometer。像一个漏斗一样，能把OpenStack内部发生的几乎所有的事件都收集起来，然后为计费和监控以及其它服务提供数据支撑。自Havana版本集成到项目中。
部署编排 (Orchestration)：Heat。提供了一种通过模板定义的协同部署方式，实现云基础设施软件运行环境（计算、存储和网络资源）的自动化部署。自Havana版本集成到项目中。
数据库服务（Database Service）：Trove。为用户在OpenStack的环境提供可扩展和可靠的关系和非关系数据库引擎服务。自Icehouse版本集成到项目中。

其分层架构如下:

3、云原生时代

云计算发展就是能力不断下沉到基础设备，应用开发者不断得到解放的过程。

这个过程可以类比社会的发展，从封建主义社会的自给自足，到资本主义社会的按劳分配，再到共产主义社会的按需分配。云原生时代就可以看做社会主义社会阶段，大部分工作已经被底层设施完成，应用开发者仅关注业务自身逻辑。

什么是云原生？2015年成立的CNCF基金会(Cloud Native Computing Foundation)在2018年对云原生做了如下定义(中英文对照)

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

译文：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

译文:这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

关于什么是云原生现在还在争论中，可谓百家争鸣，笔者认为云原生是一种设计理念，一切有利于提升云上资源利用率以及应用交付效率的行为或方式，都可以看做云原生，如容器化，ServiceMesh，Serverless，K8S等技术。

云原生的设计理念如下:

面向分布式设计（Distribution）：容器、微服务、API 驱动的开发；
面向配置设计（Configuration）：一个镜像，多个环境配置；
面向韧性设计（Resistancy）：故障容忍和自愈；
面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
面向交付设计（Delivery）：自动拉起，缩短交付时间；
面向性能设计（Performance）：响应式，并发和资源高效利用；
面向自动化设计（Automation）：自动化的 DevOps；
面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
面向安全性设计（Security）：安全端点、API Gateway、端到端加密；

云原生起始于容器化技术，前面在讲虚拟化时，我们说到，计算机系统的每一层都可以虚拟化，其中操作系统虚拟化，又称之为容器化。

容器技术属于轻量级的虚拟化，它不需要虚拟出整个操作系统，只需要虚拟一个小规模的环境（类似“沙箱”）。与虚拟化技术比较：

特性	虚拟机	容器
隔离级别	操作系统级别	进程级别
隔离策略	Hypervisor	GGroups
系统资源	5%～15%	0%～5%
启动时间	分钟	秒
镜像存储	GB~TB	KB~MB
集群规模	上百	上万
高可用策略	备份，容灾，迁移	弹性，负载，动态

容器技术与虚拟机技术并不是互斥的，而是互补的。大部分的方案是在物理机上虚化一层，然后再进行容器化。

总之，容器技术在性能，弹性，可维护性方面的优势，成为云原生的基础。

(1)Docker

Docker是容器化技术的佼佼者，甚至是容器的代名词，其实它仅是容器化技术的一个项目产品，其类似的产品包括LXC，Rocket等。Docker项目最初是由一家名为DotCloud的平台即服务厂商所打造，其后该公司更名为Docker。Docker在起步阶段使用LXC，而后利用自己的Libcontainer库将其替换下来。

对于容器技术，大家的方案差不多，采用了Cgroup+NameSpace技术，实现了进程级别的隔离。那为什么Docker会脱颖而出，其杀手锏是采用一套高效的分层式容器镜像模型，实现了高效的部署。

以ubuntu 为例，分为只读层和读写层，示意图如下：

rootfs由多个 image 来构成，ubuntu版本之间差异由之前的rootfs，变成粒度更小的images，对于ubuntu的不同版本来说，大部分的images是可以共用的，仅下载由变动的images就可以完成容器的创建和迁移，大大提升了效率。

rootfs作为只读层，是基石，不可以被改变的。那么Docker又在其上增加读写层，作为增量的修改。通过AUFS实现 rootfs 与 read-write filesystem 的合并，形成一个完整的ubuntu系统。

Docker容器是云原生技术的奠基石，开启了轰轰烈烈的云原生时代。

(2)CNCF

CNCF(Cloud Native Computing Foundation,云原生基金会)成立于2015年12月11日，是一个开源软件基金会。CNCF的成立对于云原生是个里程碑式的事件，其致力于推动云原生技术的可持续发展以及帮助开发人员快速构建出色的云原生的产品。

CNCF的全景图(原图请见：GitHub - cncf/landscape: 🌄The Cloud Native Interactive Landscape filters and sorts hundreds of projects and products, and shows details including GitHub stars, funding or market cap, first and last commits, contributor counts, headquarters location, and recent tweets.)

其路线路包含十个步骤，也涵盖了云原生技术栈。

容器化。目前最流行的容器化技术是Docker，你可以将任意大小的应用程序和依赖项，甚至在模拟器上运行的一些程序，都进行容器化。随着时间的推移，你还可以对应用程序进行分割，并将未来的功能编写为微服务。
CI/CD（持续集成和持续发布）。创建CI/CD环境，从而使源代码上的任意修改，都能够自动通过容器进行编译、测试，并被部署到预生产甚至生产环境中。
应用编排（Kubernetes）。Kubernetes是目前市场上应用编排领域被最广泛应用的工具，Helm Charts可以用来帮助应用开发和发布者用于升级Kubernetes上运行的应用。
监控和分析。在这一步中，用户需要为平台选择监控、日志以及跟踪的相关工具，例如将Prometheus用于监控、Fluentd用于日志、Jaeger用于整个应用调用链的跟踪。
服务代理、发现和治理。CoreDNS、Envoy和LInkerd可以分别用于服务发现和服务治理，提供服务的健康检查、请求路由、和负载均衡等功能。
网络。Calico、Flannel以及Weave Net等软件用于提供更灵活的网络功能。
分布式数据库和存储。分布式数据库可以提供更好的弹性和伸缩性能，但同时需要专业的容器存储予以支持。
流和消息处理。当应用需要比JSON-REST这个模式更高的性能时，可以考虑使用gRPC或者NATS。gRPC是一个通用的RPC（远程调用）框架（类似各种框架中的RPC调用），NATS是一个发布/订阅和负载均衡的消息队列系统。
容器镜像库和运行环境。Harbor是目前最受欢迎的容器镜像库，同时，你也可以选择使用不同的容器运行环境用于运行容器程序。
软件发布。最后可以借助Notary等软件用于软件的安全发布。

目前(截止2022年10月)已有18个项目从CNCF毕业，分别是Kubernetes、Prometheus、Envoy、CoreDNS、Containerd、TUF、Jaeger、Fluentd、Vitess，Helm，Etcd，Harbor，Linked，Open Policy Agent，Rook，spiffe，spire，Tikv。

(3)K8S

写到这，我们的主角终于闪亮登场了。Docker技术完美的解决了应用的部署和迁移一致性以及高效性的问题，但是还得有人告诉它如何部署和迁移，这就是容器的编排和调度，也就是K8S的职责所在，同时它提供了存储，网络，权限等一套API，已经成为事实意义上的云操作系统，是云原生的霸主，统治者。

K8S(Kubernetes) 是 Google 于 2014 年 6 月基于其内部使用的Brog系统开源出来的容器编排调度引擎，2018年经过CNCF的孵化，成为第一个毕业的项目。实际上，K8S的霸主之路并非一帆风顺，它的问世给如日冲天的Docker形成了威胁，遭到多方的绞杀，经过与Swarm、Mesos 的混战之后，最终胜出。其中的原因是多方面的，笔者认为主要有两方面。一方面是谷歌的背书，自带光环，其技术的领先性以及产品的稳定性都得到了很好的保障；另一方面，K8S作为开源项目，坚持公正，公平，赢得了广大开发者的支持，要知道K8S的服务对象就这这群开发者，得人心者得天下。

关于K8S的技术架构，我们稍后将详细介绍。

(4) Serverless

Serverless(无服务器技术)并不是突然兴起的时髦概念，早在2014年，AWS就推出Lamada服务，这就是早期商用的FAAS(函数即服务)。随着容器和K8S技术的成熟，使得Serverless发展走上了快车道。

Serverless并不是说不需要服务器，而是包括服务器，操作系统，环境等基础设备完全对于开发者屏蔽了，更进一步，部署，运维等工作也不需要开发者介入，开发者唯一要做的是，把业务逻辑代码写好，生产力真正得到了解放。

从架构上理解，Serverless=FAAS+事件驱动+BAAS

FAAS，Function as a Service,函数即服务，应用由诸多个独立的函数组成，每个函数实现各自的业务逻辑。
事件驱动，通过事件触发的形式去完成函数的调用，处理请求和响应(如定时任务/http请求...)。
BAAS，Backend as a Service 后端即服务，后端能力封装成了服务，并以接口的形式提供给FaaS，如数据库的增删改查等。

Serverless降低了开发，运营成本，其良好的扩展能力，使得按需弹性算力，这些优势使得Serverless被认为是云计算未来十年的趋势。各家大厂也纷纷布局，包括基于K8S的Serverless平台Knative，OpenWhisk等。

算力像水电一样，成为老百姓平常生活的必须品，这个时代已经肉眼可见了。云计算技术也必将改变人类的未来，置身于时代洪流之中，"同流合污"，拥抱变革，才能实现自身价值。

三、K8S的功能

我们再回到主角K8S，容器的编排和调度是K8S基本功能，除此之外，K8S还包括应用部署，维护，服务注册，负载均衡，弹性扩缩容，扩展机制等一系列的功能套件。现在我们来逐一了解下:

1、服务编排，K8S通过YAML文件，声明式描述服务间的关系(亲和或者互斥)，使得应用程序部署变得更高效。

2、Pod的调度，pod是K8S调度的最小单位，也是容器依赖的执行环境，根据调度策略，将pod调度到合适的节点上运行。

3、服务发现，服务运行在集群中不同的节点上，Service对象对外提供统一的访问IP，并转发到服务。

4、负载均衡，访问的流量通过kube proxy负载均衡转发请求到后端容器。

5、应用健康检查，容器内服务可能进程堵塞无法处理请求，可以设置监控检查策略保证应用健壮性。

6、资源监控，Node节点组件集成cAdvisor资源收集工具，可通过Heapster汇总整个集群节点资源数据。

7、弹性伸缩，根据资源的收集数据，并通过指定的指标(CPU利用率，指定副本数)自动缩放Pod副本数。

8、滚动更新，更新服务不中断，一次更新一个Pod，而不是同时删除整个服务，确保服务的不中断。

9、数据卷，Pod中容器之间共享数据，可以使用数据卷。

10、认证和授权，支持属性访问控制（ABAC）、角色访问控制（RBAC）认证授权策略。

总体而言，K8S统一了云数据中心基础设施层的API，成为云操作系统。我们来和单机的linux操作系统做个比较。

对比项	Linux	Kubernetes
隔离单元	进程	Pod
硬件	单机	数据中心
并发	线程	容器
资源管理	进程内存&CPU	内存、CPU Limit/Request
存储	文件	ConfigMap、Secret、Volume
网络	端口绑定	Service
终端	tty、pty、shell	kubectl exec
网络安全	IPtables	NetworkPolicy
权限	用户、文件权限	ServiceAccount、RBAC

四、K8S概念

下面我们认识K8S一些重要的概念,这里有个初步印象即可，后续的章节将详细介绍。

1、Node(节点)

Node(节点)是kubernetes集群中的工作负载节点，提供物理网络，存储，算力等资源。每个node都会被master分配一些工作负载（docker容器）。当某个node节点宕机，其上面的工作负载会被master自动转移到其他的节点上。

Node可以是物理机也可以是虚拟机。K8S集群就是有Master节点和Node节点组成的Master-Node架构，后面详细介绍。

2、Pod

Pod是最基础也是最重要的对象，是在 Kubernetes 集群中运行部署应用或服务的最小单元。它与Node以及容器之间的关系如下:

那么Node为什么不直接部署容器，而中间需要有个Pod对象，这就涉及到Pod支持多容器的设计理念。同一个Pod的一组容器可以共享网络和文件系统，通过进程间通信和文件共享这种简单高效的方式组合完成服务，对于一些强依赖的应用，可以编排到一个Pod中，在部署的时候组合成一个微服务对外提供服务。

比如运行一个操作系统发行版的软件仓库，一个 Nginx 容器用来发布软件，另一个容器专门用来从源仓库做同步，这两个容器的镜像由两个团队开发，但是它们一块儿工作才能提供一个微服务，这种就符合Pod的多容器理念。

Pod 是 Kubernetes 集群中所有业务类型的基础，可以看作运行在 Kubernetes 集群中的小机器人，不同类型的业务就需要不同类型的小机器人去执行。但需要注意的是，Pod是虚拟的概念，并不是实际的物理组件。

3、NameSpace(命名空间)

当两个Pod划分到不同的NameSpace下，它们之间默认情况下是无法访问的，形成逻辑上的隔离和分组。NameSpace主要作用是用来实现多套环境的资源隔离或者多租户的资源隔离。

Kubernetes 集群初始有两个命名空间，分别是默认命名空间 default 和系统命名空间 kube-system，除此以外，管理员可以可以创建新的命名空间满足需要。

4、Replication Controller(RC,副本控制器)/Replication Set(RS,副本集)

RC(副本控制器)是 Kubernetes 集群中最早的保证 Pod 高可用的 API 对象，根据指定Pod的副本个数，并监控运行过程中实际的副本数，两者进行比较，实现动态的扩缩容。

RC(副本集)可以认为是RC的升级版，相比于RC，能支持更多种类的Pod匹配模式。副本集对象一般不单独使用，而是作为 Deployment 的理想状态参数使用。

5、Deployment(部署)

部署是K8S集群对于服务的更新操作，可以是新建，也可以是升级。K8S的部署采用滚动的模式，即旧版本的RS逐渐减少到0，新版本的RS逐渐增加到指定数的过程。

部署过程中，还支持终止和回退到指定版本。

6、Service(服务)

服务部署并运行后，对外提供访问服务，由于Pod的IP和端口是不确定的(弹性扩缩容会导致pod对象的增删)，就需要一个对象提供稳定的服务发现和负载均衡功能，该对象就是Service。

在 K8 集群中，客户端需要访问的服务就是 Service 对象，每个 Service 会对应一个集群内部有效的虚拟 IP，集群内部通过虚拟 IP 访问一个服务。

Service配合Kube proxy组件实现流量的负载均衡。

7、Job(任务)

根据服务运行的周期，可以分为长服务和短服务，长服务是需要一直在线的，比如web服务，短服务是有头有尾，任务完成后可以结束的，比如一次性的调用，用完就可以销毁掉。Job 是 Kubernetes 用来控制批处型任务(短服务)的 API 对象，任务完成后就自动退出。

8、DaemonSet(后台支撑服务集)

有些服务是和Node节点绑定的，节点创建后，就需要启动并运行某类pod，和业务pod没有关系，比如监控，日志，存储等。K8S为这类服务提供了DaemonSet控制器。

9、StatefulSet(有状态服务集)

服务可以分为有状态和无状态，无状态是指没有上下文数据的，新建的服务实例与其他的服务实例之间没有差异，可以相互替代，比如web服务；有状态是指带有上下文数据的，服务实例之间是有差异的，典型的就是数据库实例，比如Mysql服务，分库1实例与分库2实例之间是有差异的，无法相互替代。

StatefulSet是K8S为解决有状态服务而提供的管理对象。

10、Persistent Volume(PV,持久存储卷)/Persistent Volume Claim(PVC,持久存储卷声明)

如果服务需要存储支撑，那么在声明该服务容器的时候，需要申明所需要的存储资源，这些资源的规格，类型，甚至位置都有不同的要求。对于开发者来说，这些工作已经超过其认知范围，也不会关心这些基础设施的信息，这些显然是运维的工作范畴。

K8S通过PV和PVC分离了在存储配置过程中开发和运维的工作，运维人员根据存储资源配置PV，如存储规格的划分，访问路径等；开发人员根据服务，申请所需的的存储资源即可(即PVC)，比如需要50GB的存储空间，而不需关系这些资源在哪。PV与PVC的适配就交由K8S实现了。

11、Secret(密钥对象)

Secret 是用来保存和传递密码、密钥、认证凭证这些敏感信息的对象。使用 Secret 的好处是可以避免把敏感信息明文写在配置文件里。在 Kubernetes 集群中配置和使用服务不可避免的要用到各种敏感信息实现登录、认证等功能，例如访问 AWS 存储的用户名密码。为了避免将类似的敏感信息明文写在所有需要使用的配置文件中，可以将这些信息存入一个 Secret 对象，而在配置文件中通过 Secret 对象引用这些敏感信息。

12、User Account(用户账户)/Service Account(服务帐户)

用户帐户为人提供账户标识，而服务账户为计算机进程和 Kubernetes 集群中运行的 Pod 提供账户标识。用户帐户和服务帐户的一个区别是作用范围；用户帐户对应的是人的身份，人的身份与服务的 namespace 无关，所以用户账户是跨 namespace 的；而服务帐户对应的是一个运行中程序的身份，与特定 namespace 是相关的。

后续的系列课程将围绕这些概念展示，逐一进行详细介绍。

五、K8S架构

K8S的系统架构图如下：

K8S整体上采用的是Master-Node架构，Master是控制面，整个集群的中枢，Node为执行面，负责应用的具体执行，两者通过信息交互，完成协作。

1、Master

Mater是整个K8S集群的大脑，负责管理所有的Node,调度Pod，控制运行过程中的状态。

(1)API Server

API Server组件可以认为是这个大脑的办事大厅,一方面对外提供统一的访问接口，另一方面，各个组件之间不相互通讯，都是通过API Server实现信息交互。

这种设计的好处是可以收敛统一请求，进行认证、授权以及访问控制。由于API server是一个集中点，也可能出现网络风暴将其击穿的风险，这一点其实不用担心，API server在设计的时候就考虑到弹性伸缩的问题，其无状态特性决定了可以快速的扩容，避免上述情况的发生。

总体来说，API Server具有以下特性：

将Kubernetes系统中的所有资源对象都封装成RESTful风格的API接口进行管理。
可进行集群状态管理和数据管理，是唯一与Etcd集群交互的组件。
拥有丰富的集群安全访问机制，以及认证、授权及准入控制器。
提供了集群各组件的通信和交互功能。

(2) Etcd

Etcd可以认为是大脑的信息仓库。是兼具一致性和高可用性的键值数据库，在K8S集群中，它负责数据的存储，包括所有Kubernetes资源对象信息、集群节点信息，运行状态信息等。

(3)Control Manager

Control Manager 是大脑的总管。弹性扩缩容是云计算的核心诉求，control manager(控制器管理)负责监控Node，Pod等资源运行的状态与期望状态之间的差异，当年状态发生偏差，就会尝试修复到期望状态。这种偏差的原因，有服务配置的变更(比如改配置 yaml 文件中的参数)，也有可能是系统异常(节点宕机)。

K8S中内置了很多类型的控制器，比如前面介绍的Deployment，ReplicaSet 等，后面我们详细介绍。

Control Manager组件本身也具备高可用，和API Server无状态不同，由于其"控制器"的决策特性，无法让所有运行的实例同时参与实际工作，必须要有个Leader的实例，负责控制逻辑，其他的实例称之为Candidate节点，作为备份，当Leader实用于处理单个主机子网划分并向外部世界公开服务。它跨集群中的各种隔离网络将请求转发到正确的 pod/容器。例出现异常后，Candidate节点则通过领导者选举机制参与竞选，成为Leader节点继续工作。

(4)Schedule

Schedule是大脑的办事员，control manager负责监控差异，但是调整差异到到期望状态，并不是它的责任，而是由Schedule(调度器)完成，它负责在Kubernetes集群中为一个Pod资源对象找到合适的节点并在该节点上运行。

Schedule的调度算法分为预选和优选两种，预选选择符合Pod运行的节点列表，而优选则是从列表中挑选出最优的节点。

Schedule的高可用方案与Control Manager是类似的。

2、Node

Node是物理节点，应用运行的实体载体，其上组件包括:

(1)Kubelet

Kubelet是管理节点的组件，是节点的运行的代理，一方面接受API server下发的任务指令并完成执行，当Master节点的Schedule完成节点选择后，Pod在节点上的创建工作则是由Kubelet完成；另一方面，监控所在节点资源的使用状态，并上报给API Server组件，为调度策略提供数据支撑。