Kubernetes Deployment：深度解析与应用实践（上）-编程知识

🐇明明跟你说过：个人主页

🏅个人专栏：《Kubernetes航线图：从船长到K8s掌舵者》 🏅

🔖行路有良友，便是天堂🔖

一、引言

1、Kubernetes简介

2、Deployment的概念

3、Deployment如何管理Pod

二、Deployment基础

1、Deployment资源定义与组成

2、Deployment与Pod、ReplicaSet的关系

三、Deployment进阶

1、Deployment更新策略

2、Deployment回滚机制

3、Deployment扩缩容操作

一、引言

1、Kubernetes简介

Kubernetes（通常缩写为K8s）是一个开源的容器编排平台，用于自动部署、扩展和管理容器化应用程序。它最初由Google开发，并于2014年发布为开源项目，现在由云原生计算基金会（CNCF）进行维护和发展。

2、Deployment的概念

Deployment是Kubernetes中的一种资源对象，它主要用于声明应用的期望状态，并通过控制器确保集群的实际状态与这个期望状态保持一致。在Deployment中，可以定义应用程序的期望状态，如Pod副本数量、Pod模板等，而Kubernetes会以受控的速率更改实际状态以匹配这个期望状态。

3、Deployment如何管理Pod

Deployment通过控制器（Controller）来管理Pod的创建、更新和删除，实现应用程序的自动化部署和管理。

创建Pod： 当创建一个Deployment资源时，控制器会根据Deployment规格中定义的模板创建Pod。模板中包含了容器镜像、环境变量、存储卷等配置信息，控制器会根据这些信息创建相应的Pod副本。
更新Pod： 当Deployment的规格发生变化（如副本数量变化、容器镜像更新等），或者应用程序需要进行更新时，控制器会自动地根据更新策略进行Pod的更新。通常情况下，Deployment会采用滚动更新（Rolling Update）策略，逐步替换旧版本的Pod副本，确保应用程序的可用性。
删除Pod： 当Deployment资源被删除时，或者由于其他原因需要删除Pod时，控制器会负责删除与该Deployment关联的所有Pod副本，以确保资源的清理和释放。
监控和维护Pod状态： 控制器会定期检查Deployment的状态，并根据实际情况更新Pod的状态信息。这包括正在运行的副本数量、可用副本数量、更新进度等。控制器会根据这些信息来保证Deployment的期望状态和实际状态一致，确保应用程序的健康运行。

二、Deployment基础

1、Deployment资源定义与组成

Deployment资源在Kubernetes中主要用于控制Pod的副本数量、更新和回滚等操作。它是Kubernetes中最常用的资源对象之一，为ReplicaSet和Pod的创建提供了一种声明式的定义方法。

在Deployment对象中，用户描述一个期望的状态，Deployment控制器则会按照一定的控制速率把实际状态改成期望状态。具体来说，通过定义一个Deployment控制器，会创建一个新的ReplicaSet控制器，再通过ReplicaSet来创建Pod。如果删除Deployment控制器，那么它下面对应的ReplicaSet控制器和Pod资源也会被删除。

Deployment资源的定义与组成主要包括以下几个方面：

标签选择器：用于选择需要管理的Pod。标签选择器可以基于Pod的标签进行筛选，确保Deployment只作用于特定的Pod集合。
期望副本数量：定义了希望集群中运行的Pod副本数量。Deployment控制器会确保这个数量的Pod处于运行状态，如果实际数量少于期望数量，则会创建新的Pod；如果实际数量多于期望数量，则会删除多余的Pod。
Pod模板：定义了Pod的配置信息，包括容器镜像、端口映射、环境变量等。Deployment控制器使用这个模板来创建新的Pod实例。

示例：

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:latestports:- containerPort: 80

apiVersion: apps/v1: 指定了使用的Kubernetes API版本，这里是apps/v1，表示使用Deployment资源的v1版本。
kind: Deployment: 定义了资源类型为Deployment，表明这是一个Deployment对象。
metadata: 包含了资源的元数据，包括名称（name）和标签（labels）。这里的名称是nginx-deployment，并且有一个标签app: nginx。
spec: 定义了Deployment的规格，包括了副本数量（replicas）、Pod选择器（selector）和Pod模板（template）。
replicas: 3：指定了希望创建的Pod副本数量为3个。
selector：用于选择要控制的Pod副本。这里指定了匹配标签app: nginx的Pod。
template：定义了Pod的模板，包括了Pod的元数据和规格。
metadata.labels: Pod模板中的标签，用于标识Pod属于哪个应用程序。这里的标签是app: nginx。
spec.containers: 定义了容器的规格，包括了容器的名称、镜像和端口等信息。
name: nginx：容器的名称为nginx。
image: nginx:latest：使用的容器镜像为最新版的NGINX。
ports.containerPort: 80：暴露容器的80端口，用于接收外部请求。

2、Deployment与Pod、ReplicaSet的关系

Deployment、Pod和ReplicaSet之间的关系可以看作是层层递进的管理关系。用户通过Deployment定义应用程序的期望状态，Deployment则通过管理ReplicaSet来实现这个状态，而ReplicaSet则负责具体管理Pod的创建、删除和更新操作。

Pod：

Pod是Kubernetes中可以创建和管理的最小可部署的计算单元。
一个Pod可以包含一个或多个容器，这些容器共享存储、网络、以及怎样运行这些容器的声明。
Pod中的内容是并置的，即它们总是在同一个节点上调度和运行，共享相同的上下文环境。

ReplicaSet：

ReplicaSet是Pod类控制器的一种实现，它的主要目标是确保在任何时候集群中都有特定数量的Pod副本运行。
根据用户定义的期望Pod数量和当前集群中实际运行的Pod数量，ReplicaSet会相应地创建或删除Pod，以确保满足期望状态。
除了确保Pod数量，ReplicaSet还负责确保Pod的健康运行。如果检测到某个节点上的Pod运行出错或无法提供服务，ReplicaSet会请求调度器在其他节点上创建新的Pod。

Deployment：

Deployment是Kubernetes中用于声明式地管理Pod和ReplicaSet的高级资源对象。
用户通过Deployment定义应用程序的期望状态，包括Pod模板和期望的副本数量等。
Deployment不直接管理Pod，而是管理ReplicaSet，再由ReplicaSet去管理Pod。这种方式提供了更高级别的抽象和更多的功能，如滚动更新和回滚。
当Deployment的期望状态发生变化时（例如，更新了Pod模板或改变了副本数量），Deployment控制器会相应地更新ReplicaSet，再由ReplicaSet去创建或删除Pod，以实现期望状态。

三、Deployment进阶

1、Deployment更新策略

Kubernetes中的Deployment控制器支持两种主要的更新策略：滚动更新（RollingUpdate）和删除式更新（Recreate），也被称为单批次更新。默认情况下，Deployment使用的是滚动更新策略。

滚动更新（RollingUpdate）：

滚动更新策略允许在更新过程中一次仅更新一批Pod。当更新的Pod就绪后，再更新另一批，直到全部更新完成为止。
这种策略实现了不间断服务的目标，因为总会有一定数量的Pod在提供服务。然而，在更新过程中，不同客户端得到的响应内容可能会来自不同版本的应用，导致新老版本共存的状态。
滚动更新可以通过设置Deployment对象中的maxUnavailable和maxSurge字段来控制更新过程中的Pod数量。maxUnavailable表示在更新过程中允许的最大不可用Pod数量，而maxSurge则表示可以超过期望副本数的最大Pod数量。

删除式更新（Recreate）：

当更新策略设定为Recreate时，更新过程会先删除现在正在运行的Pod，等待它们完全终止后，再基于新的Pod模板创建新的ReplicaSet，并启动对应的Pod。
这种更新方式会造成服务在一段时间内无法提供服务，因为所有的旧Pod都会被删除，而新的Pod还未就绪。
由于其服务中断的弊端，删除式更新在生产环境中较少使用。

示例：

apiVersion: apps/v1
kind: Deployment
metadata:name: example-deployment
spec:replicas: 3selector:matchLabels:app: exampletemplate:metadata:labels:app: examplespec:containers:- name: example-containerimage: nginx:lateststrategy:type: RollingUpdaterollingUpdate:maxSurge: 1maxUnavailable: 1

在上面的例子中，使用了 RollingUpdate 策略，并且定义了 maxSurge 和 maxUnavailable 参数来控制滚动更新过程中新旧 Pod 的数量。

strategy：指定了部署的更新策略。
type: RollingUpdate：选择了滚动更新策略，即通过逐步更新来保证服务的可用性。
rollingUpdate：定义了滚动更新的参数。
maxSurge: 1：指定了允许的最大超出副本数，在更新过程中最多可以同时创建的额外副本数。这里设置为 1，表示允许超出副本数的最大数量为 1。
maxUnavailable: 1：指定了允许的最大不可用副本数，在更新过程中最多可以同时不可用的副本数。这里设置为 1，表示允许不可用的最大数量为 1。

2、Deployment回滚机制

Kubernetes中的Deployment控制器提供了回滚机制，允许在更新应用程序版本后出现问题时，快速回退到先前的版本。这一机制确保了应用程序的稳定性和可靠性。

回滚操作主要依赖于Deployment控制器记录的历史版本信息。当执行更新操作时，Deployment控制器会保存更新前的状态作为历史版本。如果更新后的版本出现问题，可以通过回滚操作将Deployment和Pod的状态恢复到之前的历史版本。

Deployment的回滚机制可以按照以下步骤进行：

查看历史版本：使用kubectl命令行工具可以查看Deployment控制器的历史版本信息。通过执行命令 kubectl rollout history deployment <deployment-name>，可以列出指定Deployment的所有历史版本记录。
选择回滚目标：根据历史版本信息，选择一个要回滚到的目标版本。可以选择最近的版本，或者指定一个特定的历史版本。
执行回滚操作：使用kubectl命令行工具执行回滚操作。可以通过 kubectl rollout undo deployment <deployment-name> --to-revision=<revision> 命令来回滚到指定的历史版本。其中，<revision>是要回滚到的目标版本的版本号。

在执行回滚操作时，Deployment控制器会根据所选择的目标版本信息，将Pod的状态和配置回滚到该版本的状态。这包括Pod的镜像、环境变量、卷挂载等配置。回滚操作会逐步替换当前运行的Pod，以确保服务的连续性。

3、Deployment扩缩容操作

Deployment扩缩容操作主要涉及到调整应用程序的副本数量，以满足不同场景下的需求。在Kubernetes中，可以通过编辑Deployment的配置文件或使用kubectl命令行工具来实现扩缩容操作。

手动扩缩容

手动扩缩容通常涉及编辑Deployment的YAML配置文件。可以通过修改replicas字段来调整期望的Pod副本数量。例如，如果想要将副本数量从3扩展到5，可以编辑Deployment的YAML文件，将replicas字段的值从3更改为5，然后应用这个更改。

示例：

apiVersion: apps/v1  
kind: Deployment  
metadata:  name: my-deployment  
spec:  replicas: 5 # 修改这里来调整副本数量  selector:  matchLabels:  app: my-app  template:  metadata:  labels:  app: my-app  spec:  containers:  - name: my-container  image: my-image:latest

应用更改后，Kubernetes将根据新配置创建或删除Pod，以达到期望的副本数量。

自动扩缩容

除了手动扩缩容外，Kubernetes还支持基于HorizontalPodAutoscaler（HPA）的自动扩缩容。HPA可以根据Pod的CPU利用率或其他自定义指标来自动调整Deployment的副本数量。

要启用自动扩缩容，需要创建一个HPA资源对象，并指定目标Deployment、最小副本数、最大副本数以及扩缩容的阈值。HPA控制器会定期检查Pod的指标，并根据当前指标与阈值的比较结果来调整Deployment的副本数量。