k8s|k8s摘要 k8s|devops

k8s基础知识

k8s相关知识可以参考k8s官方指导 https://kubernetes.io/zh/docs/home/ 概述 Kubernetes是一个开源的容器编排部署管理平台，用于管理云平台中多个主机上的容器化应用。Kubernetes的目标是让部署容器化的应用简单并且高效（powerful），Kubernetes提供了应用部署、规划、更新、维护的一种机制。
Kubernetes一个核心的特点就是能够自主地管理容器来保证云平台中的容器按照用户的期望状态运行着（比如用户想让apache一直运行，用户不需要关心怎么去做，Kubernetes会自动去监控，然后去重启、新建，总之，让apache一直提供服务。），管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes也系统提升工具以及人性化方面，让用户能够方便的部署自己的应用。

容器与Kubernetes
容器

容器与Docker
容器技术起源于Linux，是一种内核虚拟化技术，提供轻量级的虚拟化，以便隔离进程和资源。尽管容器技术已经出现很久，却是随着Docker的出现而变得广为人知。Docker是第一个使容器能在不同机器之间移植的系统。它不仅简化了打包应用的流程，也简化了打包应用的库和依赖，甚至整个操作系统的文件系统能被打包成一个简单的可移植的包，这个包可以被用来在任何其他运行Docker的机器上使用。
容器和虚拟机具有相似的资源隔离和分配方式，容器虚拟化了操作系统而不是硬件，更加便携和高效。
图1 容器 vs 虚拟机

文章图片

相比于使用虚拟机，容器有如下优点：

更高效的利用系统资源由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销，容器对系统资源的利用率更高。无论是应用执行速度、内存损耗或者文件存储速度，都要比传统虚拟机技术更高效。因此，相比虚拟机技术，一个相同配置的主机，往往可以运行更多数量的应用。
更快速的启动时间传统的虚拟机技术启动应用服务往往需要数分钟，而Docker容器应用，由于直接运行于宿主内核，无需启动完整的操作系统，因此可以做到秒级、甚至毫秒级的启动时间，大大节约了开发、测试、部署的时间。
一致的运行环境开发过程中一个常见的问题是环境一致性问题。由于开发环境、测试环境、生产环境不一致，导致有些问题并未在开发过程中被发现。而Docker的镜像提供了除内核外完整的运行时环境，确保了应用运行环境一致性。
更轻松的迁移由于Docker确保了执行环境的一致性，使得应用的迁移更加容易。Docker可以在很多平台上运行，无论是物理机、虚拟机，其运行结果是一致的。因此可以很轻易的将在一个平台上运行的应用，迁移到另一个平台上，而不用担心运行环境的变化导致应用无法正常运行的情况。
更轻松的维护和扩展 Docker使用的分层存储以及镜像的技术，使得应用重复部分的复用更为容易，也使得应用的维护更新更加简单，基于基础镜像进一步扩展镜像也变得非常简单。此外，Docker团队同各个开源项目团队一起维护了大批高质量的官方镜像，既可以直接在生产环境使用，又可以作为基础进一步定制，大大的降低了应用服务的镜像制作成本。

Docker容器典型使用流程
Docker容器有如下三个主要概念：

镜像：Docker镜像里包含了已打包的应用程序及其所依赖的环境。它包含应用程序可用的文件系统和其他元数据，如镜像运行时的可执行文件路径。
镜像仓库：Docker镜像仓库用于存放Docker镜像，以及促进不同人和不同电脑之间共享这些镜像。当编译镜像时，要么可以在编译它的电脑上运行，要么可以先上传镜像到一个镜像仓库，然后下载到另外一台电脑上并运行它。某些仓库是公开的，允许所有人从中拉取镜像，同时也有一些是私有的，仅部分人和机器可接入。
容器：Docker容器通常是一个Linux容器，它基于Docker镜像被创建。一个运行中的容器是一个运行在Docker主机上的进程，但它和主机，以及所有运行在主机上的其他进程都是隔离的。这个进程也是资源受限的，意味着它只能访问和使用分配给它的资源（CPU、内存等）。

典型的使用流程如图2所示：
图2 Docker容器典型使用流程

文章图片

首先开发者在开发环境机器上开发应用并制作镜像。 Docker执行命令，构建镜像并存储在机器上。
开发者发送上传镜像命令。 Docker收到命令后，将本地镜像上传到镜像仓库。
开发者向生产环境机器发送运行镜像命令。生产环境机器收到命令后，Docker会从镜像仓库拉取镜像到机器上，然后基于镜像运行容器。

Kubernetes

Kubernetes是什么
Kubernetes是一个很容易地部署和管理容器化的应用软件系统，使用Kubernetes能够方便对容器进行调度和编排。
对应用开发者而言，可以把Kubernetes看成一个集群操作系统。Kubernetes提供服务发现、伸缩、负载均衡、自愈甚至选举等功能，让开发者从基础设施相关配置等解脱出来。
Kubernetes可以把大量的服务器看做一台巨大的服务器，在一台大服务器上面运行应用程序。无论Kubernetes的集群有多少台服务器，在Kubernetes上部署应用程序的方法永远一样。
图1 在Kubernetes集群上运行应用程序

文章图片

Kubernetes集群架构
Kubernetes集群包含master节点和node节点，应用部署在node节点上，且可以通过配置选择应用部署在某些特定的节点上。
Kubernetes集群的架构如下所示：
图2 Kubernetes集群架构

文章图片

Master节点
Master节点是集群的控制节点，由API Server、Scheduler、Controller Manager和ETCD四个组件构成。

API Server：各组件互相通讯的中转站，接受外部请求，并将信息写到ETCD中。
Controller Manager：执行集群级功能，例如复制组件，跟踪Node节点，处理节点故障等等。
Scheduler：负责应用调度的组件，根据各种条件（如可用的资源、节点的亲和性等）将容器调度到Node上运行。
ETCD：一个分布式数据存储组件，负责存储集群的配置信息。

在生产环境中，为了保障集群的高可用，通常会部署多个master，如CCE集群的高可用模式就是3个master节点。
Node节点
Node节点是集群的计算节点，即运行容器化应用的节点。

kubelet：kubelet主要负责同Container Runtime打交道，并与API Server交互，管理节点上的容器。
kube-proxy：应用组件间的访问代理，解决节点上应用的访问问题。
Container Runtime：容器运行时，如Docker，最主要的功能是下载镜像和运行容器。 Kubernetes的扩展性
Kubernetes开放了容器运行时接口（CRI）、容器网络接口（CNI）和容器存储接口（CSI），这些接口让Kubernetes的扩展性变得最大化，而Kubernetes本身则专注于容器调度。
CRI（Container Runtime Interface）：容器运行时接口，提供计算资源，CRI隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。
CNI（Container Network Interface）：容器网络接口，提供网络资源，通过CNI接口，Kubernetes可以支持不同网络环境。例如华为云CCE就是开发的CNI插件支持Kubernetes集群运行在华为云VPC网络中。
CSI（Container Storage Interface）：容器存储接口，提供存储资源，通过CSI接口，Kubernetes可以支持各种类型的存储。例如华为云CCE就可以方便的对接华为云块存储（EVS）、文件存储（SFS）和对象存储（OBS）。

文章图片

Pod Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。
Deployment Deployment是对Pod的服务化封装。一个Deployment可以包含一个或多个Pod，每个Pod的角色相同，所以系统会自动为Deployment的多个Pod分发请求。
StatefulSet StatefulSet是用来管理有状态应用的对象。和Deployment相同的是，StatefulSet管理了基于相同容器定义的一组Pod。但和Deployment不同的是，StatefulSet为它们的每个Pod维护了一个固定的ID。这些Pod是基于相同的声明来创建的，但是不能相互替换，无论怎么调度，每个Pod都有一个永久不变的ID。
Job Job是用来控制批处理型任务的对象。批处理业务与长期伺服业务（Deployment）的主要区别是批处理业务的运行有头有尾，而长期伺服业务在用户不停止的情况下永远运行。Job管理的Pod根据用户的设置把任务成功完成就自动退出（Pod自动删除）。
CronJob CronJob是基于时间控制的Job，类似于Linux系统的crontab，在指定的时间周期运行指定的任务。
DaemonSet DaemonSet是这样一种对象（守护进程），它在集群的每个节点上运行一个Pod，且保证只有一个Pod，这非常适合一些系统层面的应用，例如日志收集、资源监控等，这类应用需要每个节点都运行，且不需要太多实例，一个比较好的例子就是Kubernetes的kube-proxy。
Service Service是用来解决Pod访问问题的。Service有一个固定IP地址，Service将访问流量转发给Pod，而且Service可以给这些Pod做负载均衡。
Ingress Service是基于四层TCP和UDP协议转发的，Ingress可以基于七层的HTTP和HTTPS协议转发，可以通过域名和路径做到更细粒度的划分。
ConfigMap ConfigMap是一种用于存储应用所需配置信息的资源类型，用于保存配置数据的键值对。通过ConfigMap可以方便的做到配置解耦，使得不同环境有不同的配置。
Secret Secret是一种加密存储的资源对象，您可以将认证信息、证书、私钥等保存在Secret中，而不需要把这些敏感数据暴露到镜像或者Pod定义中，从而更加安全和灵活。
PersistentVolume（PV） PV指持久化数据存储卷，主要定义的是一个持久化存储在宿主机上的目录，比如一个NFS的挂载目录。
PersistentVolumeClaim（PVC） Kubernetes提供PVC专门用于持久化存储的申请，PVC可以让您无需关心底层存储资源如何创建、释放等动作，而只需要申明您需要何种类型的存储资源、多大的存储空间。

kubectl
kubectl是Kubernetes集群的命令行工具，您可以将kubectl安装在任意一台机器上，通过kubectl命令操作Kubernetes集群

# kubectl cluster-info Kubernetes master is running at https://*.*.*.*:5443 CoreDNS is running at https://*.*.*.*:5443/api/v1/namespaces/kube-system/services/coredns:dns/proxyTo further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.

执行kubectl get nodes可以查看集群中的Node节点信息。

# kubectl get nodes NAMESTATUSROLESAGEVERSION 192.168.0.153Ready7mv1.15.6-r1-20.3.0.2.B001-15.30.2 192.168.0.207Ready7mv1.15.6-r1-20.3.0.2.B001-15.30.2 192.168.0.221Ready7mv1.15.6-r1-20.3.0.2.B001-15.30.2

Kubernetes对象的描述
kubernetes中资源可以使用YAML描述（如果您对YAML格式不了解，可以参考YAML语法），也可以使用JSON。其内容可以分为如下四个部分：

typeMeta：对象类型的元信息，声明对象使用哪个API版本，哪个类型的对象。
objectMeta：对象的元信息，包括对象名称、使用的标签等。
spec：对象的期望状态，例如对象使用什么镜像、有多少副本等。
status：对象的实际状态，只能在对象创建后看到，创建对象时无需指定。

图4 YAML描述文件

文章图片

【k8s|k8s摘要】Pod、Label和Namespace
Pod：Kubernetes中的最小调度对象
什么是Pod
Pod是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。
Pod使用主要分为两种方式：

Pod定义好后就可以使用kubectl创建，如果上面YAML文件名称为nginx.yaml，则创建命令如下所示，-f表示使用文件方式创建。
如果去查询Kubernetes的资源，您会看到还有一个status字段，status描述kubernetes资源的实际状态，创建时不需要配置。这个示例是一个最小集，其他参数定义后面会逐步介绍。

Pod中运行一个容器。这是Kubernetes最常见的用法，您可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。
Pod中运行多个需要耦合在一起工作、需要共享资源的容器。通常这种场景下应用包含一个主容器和几个辅助容器（SideCar Container），如图1所示，例如主容器为一个web服务器，从一个固定目录下对外提供文件服务，而辅助容器周期性的从外部下载文件存到这个固定目录下。图1 Pod
文章图片
实际使用中很少直接创建Pod，而是使用Kubernetes中称为Controller的抽象层来管理Pod实例，例如Deployment和Job。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，Controller会使用Pod Template来创建相应的Pod。

创建Pod
kubernetes中资源可以使用YAML描述（如果您对YAML格式不了解，可以参考YAML语法），也可以使用JSON，如下示例描述了一个名为nginx的Pod，这个Pod中包含一个名为container-0的容器，使用nginx:alpine镜像，使用的资源为100m core CPU、200Mi内存。
apiVersion: v1# Kubernetes的API Version kind: Pod# Kubernetes的资源类型 metadata: name: nginx# Pod的名称 spec:# Pod的具体规格（specification） containers: - image: nginx:alpine# 使用的镜像为 nginx:alpine name: container-0# 容器的名称 resources:# 申请容器所需的资源 limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets:# 拉取镜像使用的证书，在CCE上必须为default-secret - name: default-secret

如上面YAML的注释，YAML描述文件主要为如下部分：
metadata：一些名称/标签/namespace等信息。
spec：Pod实际的配置信息，包括使用什么镜像，volume等。

存活探针（Liveness Probe）
存活探针
Kubernetes提供了自愈的能力，具体就是能感知到容器崩溃，然后能够重启这个容器。但是有时候例如Java程序内存泄漏了，程序无法正常工作，但是JVM进程却是一直运行的，对于这种应用本身业务出了问题的情况，Kubernetes提供了Liveness Probe机制，通过检测容器响应是否正常来决定是否重启，这是一种很好的健康检查机制。
毫无疑问，每个Pod最好都定义Liveness Probe，否则Kubernetes无法感知Pod是否正常运行。
Kubernetes支持如下三种探测机制。

HTTP GET：向容器发送HTTP GET请求，如果Probe收到2xx或3xx，说明容器是健康的。
TCP Socket：尝试与容器指定端口建立TCP连接，如果连接成功建立，说明容器是健康的。
Exec：Probe执行容器中的命令并检查命令退出的状态码，如果状态码为0则说明容器是健康的。

与存活探针对应的还有一个就绪探针（Readiness Probe），将在就绪探针（Readiness Probe）中会详细介绍。
Label：组织Pod的利器
为什么需要Label
当资源变得非常多的时候，如何分类管理就非常重要了，Kubernetes提供了一种机制来为资源分类，那就是Label（标签）。Label非常简单，但是却很强大，Kubernetes中几乎所有资源都可以用Label来组织。
Label的具体形式是key-value的标记对，可以在创建资源的时候设置，也可以在后期添加和修改。
以Pod为例，当Pod变得多起来后，就显得杂乱且难以管理，如下图所示。
图1 没有分类组织的Pod

文章图片

如果我们为Pod打上不同标签，那情况就完全不同了，如下图所示。
图2 使用Label组织的Pod

文章图片

添加Label
Label的形式为key-value形式，使用非常简单，如下，为Pod设置了app=nginx和env=prod两个Label。

apiVersion: v1 kind: Pod metadata: name: nginx labels:# 为Pod设置两个Label app: nginx env: prod spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: - name: default-secret

Pod有了Label后，在查询Pod的时候带上--show-labels就可以看到Pod的Label。

$ kubectl get pod --show-labels NAMEREADYSTATUSRESTARTSAGELABELS nginx1/1Running050sapp=nginx,env=prod

Namespace：资源分组
为什么需要Namespace
Label虽然好，但只用Label的话，那Label会非常多，有时候会有重叠，而且每次查询之类的动作都带一堆Label非常不方便。Kubernetes提供了Namespace来做资源组织和划分，使用多Namespace可以将包含很多组件的系统分成不同的组。Namespace也可以用来做多租户划分，这样多个团队可以共用一个集群，使用的资源用Namespace划分开。
不同的Namespace下面可以有相同的名字，Kubernetes中大部分资源可以用Namespace划分，不过有些资源不行，它们属于全局资源，不属于某一个Namespace，后面会逐步接触到。
通过如下命令可以查询到当前集群下的Namespace。

$ kubectl get ns NAMESTATUSAGE defaultActive36m kube-node-realease Active36m kube-publicActive36m kube-systemActive36m

Namespace的隔离说明
Namespace只能做到组织上划分，对运行的对象来说，它不能做到真正的隔离。举例来说，如果两个Namespace下的Pod知道对方的IP，而Kubernetes依赖的底层网络没有提供Namespace之间的网络隔离的话，那这两个Pod就可以互相访问。
Pod的编排与调度
Deployment
什么是Deployment
在Pod：Kubernetes中的最小调度对象这个章节介绍了Pod，Pod是Kubernetes创建或部署的最小单位，但是Pod是被设计为相对短暂的一次性实体，Pod可以被驱逐（当节点资源不足时）、随着集群的节点崩溃而消失。Kubernetes提供了Controller（控制器）来管理Pod，Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力，其中最为常用的就是Deployment。
图1 Deployment

文章图片

一个Deployment可以包含一个或多个Pod副本，每个Pod副本的角色相同，所以系统会自动为Deployment的多个Pod副本分发请求。
Deployment集成了上线部署、滚动升级、创建副本、恢复上线的功能，在某种程度上，Deployment实现无人值守的上线，大大降低了上线过程的复杂性和操作风险。
创建Deployment
以下示例为创建一个名为nginx的Deployment负载，使用nginx:latest镜像创建两个Pod，每个Pod占用100m core CPU、200Mi内存。

apiVersion: apps/v1# 注意这里与Pod的区别，Deployment是apps/v1而不是v1 kind: Deployment# 资源类型为Deployment metadata: name: nginx# Deployment的名称 spec: replicas: 2# Pod的数量，Deployment会确保一直有2个Pod运行 selector:# Label Selector matchLabels: app: nginx template:# Pod的定义，用于创建Pod，也称为Pod template metadata: labels: app: nginx spec: containers: - image: nginx:latest name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: - name: default-secret

从这个定义中可以看到Deployment的名称为nginx，spec.replicas定义了Pod的数量，即这个Deployment控制2个Pod；spec.selector是Label Selector（标签选择器），表示这个Deployment会选择Label为app=nginx的Pod；spec.template是Pod的定义，内容与Pod中的定义完全一致。
将上面Deployment的定义保存到deployment.yaml文件中，使用kubectl创建这个Deployment。
使用kubectl get查看Deployment和Pod，可以看到READY值为2/2，前一个2表示当前有2个Pod运行，后一个2表示期望有2个Pod，AVAILABLE为2表示有2个Pod是可用的。

$ kubectl create -f deployment.yaml deployment.apps/nginx created$ kubectl get deploy NAMEREADYUP-TO-DATEAVAILABLEAGE nginx2/2224m5s

Deployment如何控制Pod
继续查询Pod，如下所示。

$ kubectl get pods NAMEREADYSTATUSRESTARTSAGE nginx-7f98958cdf-tdmqk1/1Running013s nginx-7f98958cdf-txckx1/1Running013s

如果删掉一个Pod，您会发现立马会有一个新的Pod被创建出来，如下所示，这就是前面所说的Deployment会确保有2个Pod在运行，如果删掉一个，Deployment会重新创建一个，如果某个Pod故障或有其他问题，Deployment会自动拉起这个Pod。

$ kubectl delete pod nginx-7f98958cdf-txckx$ kubectl get pods NAMEREADYSTATUSRESTARTSAGE nginx-7f98958cdf-tdmqk1/1Running021s nginx-7f98958cdf-tesqr1/1Running021s

看到有如下两个名为nginx-7f98958cdf-tdmqk和nginx-7f98958cdf-tesqr的Pod，其中nginx是直接使用Deployment的名称，-7f98958cdf-tdmqk和-7f98958cdf-tesqr是kubernetes随机生成的后缀。
您也许会发现这两个后缀中前面一部分是相同的，都是7f98958cdf，这是因为Deployment不是直接控制Pod的，Deployment是通过一种名为ReplicaSet的控制器控制Pod，通过如下命令可以查询ReplicaSet，其中rs是ReplicaSet的缩写。

$ kubectl get rs NAMEDESIREDCURRENTREADYAGE nginx-7f98958cdf2221m

这个ReplicaSet的名称为nginx-7f98958cdf，后缀-7f98958cdf也是随机生成的。
Deployment控制Pod的方式如图2所示，Deployment控制ReplicaSet，ReplicaSet控制Pod。
图2 Deployment通过ReplicaSet控制Pod

文章图片

如果使用kubectl describe命令查看Deployment的详情，您就可以看到ReplicaSet，如下所示，可以看到有一行NewReplicaSet: nginx-7f98958cdf (2/2 replicas created)，而且Events里面事件确是把ReplicaSet的实例扩容到2个。在实际使用中您也许不会直接操作ReplicaSet，但了解Deployment通过控制ReplicaSet来控制Pod会有助于您定位问题。

$ kubectl describe deploy nginx Name:nginx Namespace:default CreationTimestamp:Sun, 16 Dec 2018 19:21:58 +0800 Labels:app=nginx...NewReplicaSet:nginx-7f98958cdf (2/2 replicas created) Events: TypeReasonAgeFromMessage ------------------------- NormalScalingReplicaSet5mdeployment-controllerScaled up replica set nginx-7f98958cdf to 2

升级
在实际应用中，升级是一个常见的场景，Deployment能够很方便的支撑应用升级。
Deployment可以设置不同的升级策略，有如下两种。

RollingUpdate：滚动升级，即逐步创建新Pod再删除旧Pod，为默认策略。
Recreate：替换升级，即先把当前Pod删掉再重新创建Pod。

Deployment的升级可以是声明式的，也就是说只需要修改Deployment的YAML定义即可，比如使用kubectl edit命令将上面Deployment中的镜像修改为nginx:alpine。修改完成后再查询ReplicaSet和Pod，发现创建了一个新的ReplicaSet，Pod也重新创建了。

$ kubectl edit deploy nginx$ kubectl get rs NAMEDESIREDCURRENTREADYAGE nginx-6f9f58dffd2221m nginx-7f98958cdf00048m$ kubectl get pods NAMEREADYSTATUSRESTARTSAGE nginx-6f9f58dffd-tdmqk1/1Running021s nginx-6f9f58dffd-tesqr1/1Running021s

Deployment可以通过maxSurge和maxUnavailable两个参数控制升级过程中同时重新创建Pod的比例，这在很多时候是非常有用，配置如下所示。

spec: strategy: rollingUpdate: maxSurge: 1 maxUnavailable: 0 type: RollingUpdate

maxSurge：与Deployment中spec.replicas相比，可以有多少个Pod存在，默认值是25%，比如spec.replicas为 4，那升级过程中就不能超过5个Pod存在，即按1个的步伐升级，实际升级过程中会换算成数字，且换算会向上取整。这个值也可以直接设置成数字。
maxUnavailable：与Deployment中spec.replicas相比，可以有多少个Pod失效，也就是删除的比例，默认值是25%，比如spec.replicas为4，那升级过程中就至少有3个Pod存在，即删除Pod的步伐是1。同样这个值也可以设置成数字。

在前面的例子中，由于spec.replicas是2，如果maxSurge和maxUnavailable都为默认值25%，那实际升级过程中，maxSurge允许最多3个Pod存在（向上取整，2*1.25=2.5，取整为3），而maxUnavailable则不允许有Pod Unavailable（向上取整，2*0.75=1.5，取整为2），也就是说在升级过程中，一直会有2个Pod处于运行状态，每次新建一个Pod，等这个Pod创建成功后再删掉一个旧Pod，直至Pod全部为新Pod。
回滚
回滚也称为回退，即当发现升级出现问题时，让应用回到老的版本。Deployment可以非常方便的回滚到老版本。
例如上面升级的新版镜像有问题，可以执行kubectl rollout undo命令进行回滚。

$ kubectl rollout undo deployment nginx deployment.apps/nginx rolled back

Deployment之所以能如此容易的做到回滚，是因为Deployment是通过ReplicaSet控制Pod的，升级后之前ReplicaSet都一直存在，Deployment回滚做的就是使用之前的ReplicaSet再次把Pod创建出来。Deployment中保存ReplicaSet的数量可以使用revisionHistoryLimit参数限制，默认值为10。
StatefulSet
为什么需要StatefulSet
在Deployment中讲到了Deployment，Deployment控制器下的Pod都有个共同特点，那就是每个Pod除了名称和IP地址不同，其余完全相同。需要的时候，Deployment可以通过Pod模板创建新的Pod；不需要的时候，Deployment就可以删除任意一个Pod。
但是在某些场景下，这并不满足需求，比如有些分布式的场景，要求每个Pod都有自己单独的状态时，比如分布式数据库，每个Pod要求有单独的存储，这时Deployment就不能满足需求了。
详细分析下有状态应用的需求，分布式有状态的特点主要是应用中每个部分的角色不同（即分工不同），比如数据库有主备，Pod之间有依赖，对应到Kubernetes中就是对Pod有如下要求：

Pod能够被别的Pod找到，这就要求Pod有固定的标识。
每个Pod有单独存储，Pod被删除恢复后，读取的数据必须还是以前那份，否则状态就会不一致。

Kubernetes提供了StatefulSet来解决这个问题，其具体如下：

StatefulSet给每个Pod提供固定名称，Pod名称增加从0-N的固定后缀，Pod重新调度后Pod名称和HostName不变。
StatefulSet通过Headless Service给每个Pod提供固定的访问域名，Service的概念会在Service中详细介绍。
StatefulSet通过创建固定标识的PVC保证Pod重新调度后还是能访问到相同的持久化数据。

文章图片

Job和CronJob
DaemonSet
亲和与反亲和调度
配置管理

ConfigMap
Secret

Kubernetes网络

容器网络
Service
Ingress
就绪探针（Readiness Probe）
NetworkPolicy

持久化存储

Volume
PV、PVC和StorageClass

认证与授权

ServiceAccount
RBAC

弹性伸缩

弹性伸缩

k8s部署
搭建Kubernetes集群
Kubernetes网站上有多种搭建Kubernetes集群的方法，例如minikube、kubeadm等
我们在这里主要说两种，一种是kubeadm方式，另一种是二次封装的方式，方便后续私有化部署以及容器平台的建设。
kubeadm方式

二次封装--sealos方式

应用容器化
市场上存在各个不同的服务应用，这里介绍几个常用的容器化应用改造
整体应用容器化改造时，一般需要执行如下流程。