K8S 概念、安装与核心工作机制详解

前言

1、云原生的基础概述

云原生的定义

1.1 云原生的发展介绍

1.2 云原生的定义

1.3 云原生的技术栈

1.4 云原生的特征

12因素应用的具体原则：

2. K8S 是什么？

3. 为什么要用 K8S？

4. Kubernetes 集群架构与组件

4.1 控制平面（Master / Control Plane）组件

4.2 工作节点（Node / Worker）组件

关于 Docker / dockershim 与 containerd 的变动

5. Kubernetes 核心工作机制：工作流程与数据流向

5.1 Pod 创建与管理流程（微观流程）

5.2 应用发布与更新流程（宏观流程）

5.3 核心数据流向总结

6. Kubernetes 核心概念与资源对象

7. Kubernetes 核心能力与特性

8. 部署方式 / 常见部署方案

9. Kubernetes 操作管理概述

9.1 管理操作分类

9.2 陈述式资源管理方法

9.2.1 基本原理

9.2.2 基础信息查看命令

9.2.3 基本资源查看命令

9.2.4 命名空间操作

9.2.5 创建 Deployment

9.2.6 登录容器与删除 Pod

9.2.7 扩缩容与删除

10. 项目生命周期管理

10.1 创建阶段（kubectl create）

10.2 发布阶段（kubectl expose）

10.3 更新阶段（kubectl set）

10.4 回滚阶段（kubectl rollout）

10.5 删除阶段（kubectl delete）

11. 发布策略

11.1 金丝雀发布（Canary Release）

12. 声明式资源管理方法

12.1 基本原理

12.2 查看与解释配置清单

12.3 修改资源配置清单并应用

12.4 删除资源配置清单

总结

前言

在云原生成为现代应用架构主流的今天，Kubernetes（K8S）作为容器编排领域的事实标准，已成为开发者必须掌握的核心技术。

然而，复杂的架构概念和抽象的工作机制让许多学习者望而却步。为此，我们编写了这份指南，旨在：

• 厘清核心概念：从云原生基础到K8S核心组件，构建清晰知识体系

• 解析工作机制：深入剖析Pod创建、应用发布等关键流程的数据流向

• 衔接理论实践：提供从集群部署到日常运维的完整操作指南

无论您是初探容器世界的新手上，还是希望深化理解的开发者，本书都将为您提供一条清晰的学习路径，助您真正掌握Kubernetes的运行精髓。

1、云原生的基础概述

云原生的定义

1.1 云原生的发展介绍

云原生技术的主要发展历程如下：

• 2004年：Google开始在内部大规模使用容器技术。

• 2008年：Google将Cgroup技术合并进Linux内核，为容器化技术奠定基础。

• 2013年：Docker项目正式发布，推动容器技术进入开源领域。

• 2014年：Kubernetes项目正式发布，成为容器编排的行业标准。

• 2015年：Google、Redhat、微软等共同发起成立CNCF（云原生计算基金会），推进云原生技术的开源生态。

• 2017年：CNCF成员达到170个，基金项目数量为14个。

• 2018年：CNCF迎来三周年，成员数达195个，基金项目19个。

1.2 云原生的定义

云原生技术帮助企业在公有云、私有云和混合云等动态环境中构建和运行可弹性扩展的应用。

• 公有云：公有云是一种云计算服务，其基础设施由云服务提供商在互联网上公开提供。与私有云不同，公有云上的资源是共享的，用户可以按需使用和付费，无需拥有或管理基础设施。公有云服务通常提供存储、计算、网络和应用程序服务等资源。常见的公有云服务提供商包括亚马逊云、微软Azure、谷歌云等。

• 私有云：私有云是指一种云计算模式，是企业或组织在自己的数据中心中搭建的基于云计算技术的自有云平台。与公有云不同，私有云完全由企业自己拥有和控制，可以提供更高的安全性和灵活性，因为企业可以根据自身需求对云计算环境进行定制和管理，同时也不需要担心基础设施和数据被外部访问。因此，私有云通常被用于托管企业核心应用程序和敏感数据，以满足严格的规定和监管要求

• 混合云：混合云（Hybrid Cloud）是指由多个云计算架构、不同的云服务提供商或多种云计算部署模式组成的一个集成的云计算环境。混合云将公有云、私有云、本地IT基础设施和第三方云服务有机地结合起来，以满足企业不同的应用场景和需求。

1.3 云原生的技术栈

云原生技术栈包括以下关键技术：

• 容器化：如Docker、containerd，提供应用的轻量级封装和环境一致性。

• 服务网格：例如Istio，管理服务之间的通信、安全性和流量控制。

• 微服务架构：将应用拆解为多个独立的服务，支持灵活扩展和独立部署。

• 不可变基础设施：服务一旦部署，便不再修改，通常使用版本化的镜像来保持一致性。

• 声明式API：通过定义期望的状态，由系统自动管理资源。

云元素的四要素

• 微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是最底层，指导服务怎么切分，很玄乎，凡是能称为理论定律的简单明白不了，不然就成没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无系。微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。

• 容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，含歌搞的，Docker和K8S都采用Go编写，都是好东西。

• DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

• 持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。

1.4 云原生的特征

云原生系统具备以下特征，确保其适应现代云计算环境的需求：

1. 符合12因素应用：应用遵循12因素开发原则，确保可扩展性、无状态性、易维护等。

2. 面向微服务架构：应用拆解为独立的、松耦合的服务。

3. 自服务敏捷架构：开发人员可以自主创建和管理云资源，减少对运维的依赖。

4. 基于API协作：通过API进行服务间的通信。

5. 抗脆弱性：系统具有自愈能力，能够应对不稳定的环境因素。

12因素应用的具体原则：

1. 基准代码：使用同一代码库进行版本控制，并支持多次部署。

2. 依赖管理：显式声明和隔离各依赖项，确保环境一致性。

3. 配置管理：配置项存储在环境中，避免硬编码。

4. 后端服务：外部服务作为附加资源使用。

5. 构建、发布、运行分离：清晰区分应用构建和运行阶段。

6. 无状态进程：应用以无状态进程运行，便于水平扩展。

7. 端口绑定：通过端口提供服务，确保应用独立性。

8. 并发处理：通过进程模型进行扩展。

9. 快速启动与优化维护：应用启动迅速，并在终止时确保数据一致性。

10. 开发环境与生产环境一致：确保开发、预发布和生产环境尽量一致。

11. 日志管理：统一收集并展示日志信息，确保可追溯性。

12. 管理进程：管理任务（如数据备份）应使用与常驻进程相同的运行环境。

通过遵循这些原则，云原生应用能够在云环境中灵活、安全且高效地运行。

---

2. K8S 是什么？

• K8S 是 Kubernetes 的简写（K + "ubernetes" 中的 8 个字母 + 5）

• Kubernetes 是一个开源平台，用于 自动部署、扩展和管理容器化（containerized）应用程序

• 它可以看作一个负责自动化运维、编排多个容器（如由 containerd 驱动的容器）的集群管理系统

• 源起：Kubernetes 受 Google 的 Borg 系统启发，后使用 Go 语言重写并捐赠给 CNCF

• 名称含义：源自希腊语，意为"舵手 / 导航者"

官网：

• 英文：https://kubernetes.io

• 中文：https://kubernetes.io/zh-cn/docs

版本节奏：每年约四个发布版本（例如 1.12、1.15、1.17 … 到 1.30、1.34等）

发展历程：

• 2014年 Docker & Kubernetes蜜月期

• 2015~2016年 Kubernetes & RKT vs Docker,最终Docker胜出

• 2016年 Kubernetes逐渐赢得任务编排的胜利

• 2017年rkt和containerd 捐献给CNCF

• 2020年kubernetes宣布废弃dockershim，但 Mirantis和 Docker宣布维护dockershim

• 2022年5月3日，Kubernetes v1.24正式发布，此版本提供了很多重要功能。该版本涉及46项增强功能:其中14项已升级为稳定版，15项进入beta阶段，13项则刚刚进入alpha阶段。此外，另有2项功能被弃用、2项功能被删除。

关键变动：从 Kubernetes 1.24 起，官方移除对 Docker 的内建支持（即移除 dockershim），节点必须使用符合 CRI（Container Runtime Interface）的运行时（如 containerd、CRI-O 等）

3. 为什么要用 K8S？

Kubernetes 的设计初衷是解决传统部署方式在扩展、管理、容错等方面的困难。

以下是它主要解决的问题和带来的好处：

• 自动化运维：无须人工干预，实现一条命令或声明式方式完成部署、更新、扩容、缩容、删除等

• 弹性伸缩：依据指标（CPU、内存、自定义指标等）自动扩展或缩减 Pod 副本数

• 容灾 / 自愈：当某个节点或容器失败时，K8S 会自动重建或迁移 Pod，保证副本数量和期望状态

• 服务发现与负载均衡：通过 Service 为 Pod 提供稳定的访问入口，并自动分发请求

• 滚动升级与回滚：支持渐进式升级，一旦出错可以回滚到之前版本

• 集中配置与密钥管理：通过 ConfigMap 、Secret 等资源集中管理配置与敏感数据

• 存储编排：支持将外部存储（NFS、Ceph、云存储等）纳入集群资源管理

• 批处理 / 定时任务：支持 Job 、CronJob 用于一次性或定时任务

---

4. Kubernetes 集群架构与组件

Kubernetes 采用 控制平面 + 工作节点 的主从架构，控制平面负责调度与管理，节点负责运行实际的应用负载。

4.1 控制平面（Master / Control Plane）组件

组件	主要职责
kube-apiserver	集群的 API 接口入口，负责接收所有资源操作请求（增删改查、Watch）
kube-controller-manager	运行多种控制器（Node 控制器、ReplicaSet 控制器、Service 控制器等），确保资源状态符合期望
kube-scheduler	对尚未调度的 Pod 选择合适的节点，基于预选（predicates）与优选（priorities / scoring）策略
etcd	分布式键值存储，用于持久化保存所有 Kubernetes 资源的状态数据

高可用建议：在生产环境中，控制平面组件建议部署为多实例、高可用配置，避免单点故障。

4.2 工作节点（Node / Worker）组件

组件	主要职责
kubelet	节点上的代理，负责接收控制平面下发的 Pod 任务，监控、执行、汇报节点与 Pod 状态
kube-proxy	在节点上实现 Service 的网络规则与负载转发，通常通过 iptables、ipvs 或其他网络模型
container runtime (containerd 或 CRI-O 等)	负责容器镜像拉取、容器启动/停止、资源隔离等底层行为（在 Kubernetes ≥1.24 中为必选 CRI 运行时）

关于 Docker / dockershim 与 containerd 的变动

• Kubernetes 从 1.20 开始宣布弃用内建对 Docker 的支持，逐步推动移除 dockershim

• 在 Kubernetes 1.24 中，dockershim 被正式移除，节点必须使用 CRI 兼容的运行时（如 containerd、CRI-O 等）

• 虽然 Docker 的引擎不再被 Kubernetes 直接使用（即不作为 CRI 运行时），但其构建的镜像仍然兼容，因为镜像符合 OCI 标准

• containerd 是当前主流的轻量级 CRI 运行时，性能稳定、社区活跃

在你安装的是 K8S 1.28 的环境中，默认或者推荐的运行时就是 containerd 或 CRI-O，而不是 Docker。

---

5. Kubernetes 核心工作机制：工作流程与数据流向

Kubernetes 的核心工作流程基于一条核心原则：监听期望状态，驱动当前状态向期望状态无限接近。这个过程主要由控制平面的各个组件协同完成，是一个持续的 "调谐循环"。

5.1 Pod 创建与管理流程（微观流程）

这个流程描述了一个 Pod 从定义到在节点上正常运行的全过程，清晰地展示了各组件如何协作。

步骤与数据流向：

1. 提交期望状态

   • 用户操作：用户通过 kubectl 提交 YAML 文件

   • 数据流向：kubectl → Kube-Apiserver

   • 动作：Apiserver 进行认证、授权和校验

2. 持久化存储

   • 数据流向：Kube-Apiserver → etcd

   • 动作：Apiserver 将资源对象的期望状态持久化存储到 etcd

3. 控制器监控与协调

   • 监听：相关控制器通过 Apiserver 持续监视 etcd 中资源的状态变化

   • 检测差异：控制器发现期望状态与实际状态不符

   • 执行调谐：控制器通过 Apiserver 创建 Pod 资源定义

4. 调度器分配节点

   • 监听：Kube-Scheduler 监视未调度的 Pod

   • 调度决策：执行预选和优选策略，选择合适的工作节点

   • 绑定：通过 Apiserver 更新 Pod 定义，写入 nodeName 字段

5. 节点执行

   • 监听：目标节点上的 Kubelet 监视被调度到本节点的 Pod

   • 调用运行时：Kubelet 通过 CRI 接口调用 Container Runtime

   • 运行业务容器：拉取镜像并启动容器

6. 状态上报

   • 数据流向：Kubelet → Kube-Apiserver → etcd

   • 动作：Kubelet 监控 Pod 状态并报告当前状态

7. 服务发现与负载均衡

   • 监听：Kube-Proxy 监视 Service 和 Endpoints 变化

   • 更新规则：在节点上更新 iptables 或 ipvs 规则

5.2 应用发布与更新流程（宏观流程）

这个流程展示了应用的生命周期管理，是多个 Pod 创建流程的集合与策略控制。

步骤与数据流向：

1. 创建

   • 用户提交 Deployment 清单，流程同 Pod 创建流程

2. 发布

   • 用户创建 Service 资源

   • Apiserver 将其存入 etcd

   • Endpoints Controller 更新与 Service 关联的 Endpoints

   • Kube-Proxy 配置负载均衡规则

3. 更新（滚动更新）

   • 触发：用户执行 kubectl set image

   • 数据变更：Deployment 的 Pod 模板更新，存入 etcd

   • 控制器驱动：创建新 ReplicaSet，逐步替换旧 Pod

4. 回滚

   • 触发：用户执行 kubectl rollout undo

   • 数据变更：Pod 模板回滚到历史版本

   • 控制器驱动：扩容旧版本，缩容新版本

5.3 核心数据流向总结

组件	主要数据流入源	主要数据流出目标	核心职责
kubectl	用户、YAML文件	Kube-Apiserver	客户端命令行工具
Kube-Apiserver	kubectl、所有组件	etcd、所有组件	集群网关，所有API请求的入口/出口
etcd	Kube-Apiserver	Kube-Apiserver	唯一的数据持久化存储
Controller Manager	Kube-Apiserver/etcd	Kube-Apiserver	驱动状态协调
Kube-Scheduler	Kube-Apiserver/etcd	Kube-Apiserver	决策Pod与节点的绑定
Kubelet	Kube-Apiserver/etcd	Kube-Apiserver、Container Runtime	节点代理，Pod生命周期管理
Kube-Proxy	Kube-Apiserver/etcd	节点网络（iptables/ipvs）	Service负载均衡
Container Runtime	Kubelet	镜像仓库、OS内核	底层容器操作执行

黄金三角数据流： 整个系统的核心数据流是一个 "监听-判断-操作" 的循环： 控制器/调度器/Kubelet --(监听)--> Apiserver/etcd --(判断差异)--> 控制器/调度器/Kubelet --(执行操作)--> Apiserver --(更新状态)--> etcd。

---

6. Kubernetes 核心概念与资源对象

下面是 Kubernetes 中常见的、你需要掌握的核心概念和资源类型：

概念 / 资源	含义与用途
Pod	Kubernetes 中最小的可调度单位。可包含一个或多个容器，这些容器共享网络、存储等资源。
控制器 (Controller)	用来确保一定数量的 Pod 在运行、自动修复、扩缩、升级等。典型的控制器有：• Deployment（管理无状态应用）, • ReplicaSet（维持 Pod 副本数）, • StatefulSet（有状态服务）, • DaemonSet（每节点运行一个 Pod）, • Job / CronJob（批处理 / 定时任务）
Service	为一组 Pod 提供稳定且可达的访问入口，具有负载均衡功能。Service 通过标签选择器关联 Pod。
Ingress	在 HTTP/HTTPS 层面上管理外部访问路由，将外部流量导入集群内的 Service。
Label / Annotation / Selector	Label 是资源的键值对标签，用于标识、组织和筛选资源；Annotation 是用于存放非标识性、较大元数据的字段；Selector 用于根据 Label 选择资源。
Namespace（命名空间）	用于将一个 Kubernetes 集群逻辑上划分为多个隔离空间，以实现资源隔离、权限管理等。
资源定义结构	Kubernetes 资源通常以 YAML/JSON 定义，具有 apiVersion、kind、metadata、spec、status 等字段结构。

7. Kubernetes 核心能力与特性

• 自动伸缩（Horizontal Pod Autoscaler, Vertical Pod Autoscaler 等）

• 服务发现 & 负载均衡

• 滚动更新 / 回滚

• 容错 / 自愈

• 集中配置 / 密钥管理（ConfigMap / Secret）

• 存储编排与持久化存储（PV / PVC / StorageClass）

• 批处理 / 定时任务

• 资源隔离 / 配额 / 限制（ResourceQuota, LimitRange 等）

• 安全管理机制：如 RBAC（基于角色的访问控制）、NetworkPolicy（网络策略）、Pod 安全策略 / Pod 安全准入（安全设置）

8. 部署方式 / 常见部署方案

部署方式	主要适用场景
Minikube	在本地启动单节点 Kubernetes，适合实验、学习、演示
kubeadm	官方推荐的快速部署工具，适合中小型集群
二进制 / 源码部署	手动控制所有组件、TLS 证书等细节，适合高可控的生产环境
云托管服务（如 GKE / EKS / AKS / 阿里 ACK 等）	云厂商管理控制平面、节点、升级等，适合企业生产环境

对于你自己搭建 K8S 1.28 的环境，选择 kubeadm + containerd 或者 二进制部署 + containerd 更能兼顾灵活性与稳定性。

---

9. Kubernetes 操作管理概述

9.1 管理操作分类

Kubernetes 的管理操作分为两大类：

• 陈述式（命令式）管理方法

• 声明式（配置清单式）管理方法

9.2 陈述式资源管理方法

9.2.1 基本原理

1. Kubernetes 集群资源管理的唯一入口是通过调用 apiserver 的接口。

2. kubectl 是官方 CLI 命令行工具，用于与 apiserver 通信，将用户命令转化为 apiserver 能识别的请求，实现集群资源管理。

3. 查看 kubectl 命令大全：kubectl --help

4. 对资源的"增、删、查"操作较方便，但"改"操作相对复杂。

9.2.2 基础信息查看命令

版本与集群信息

bash

kubectl version       # 查看版本信息
kubectl api-resources # 查看资源对象编写
kubectl cluster-info  # 查看集群信息

命令自动补全与日志查看

bash

source <(kubectl completion bash) # 启用kubectl自动补全
journalctl -u kubelet -f         # 查看node节点日志

9.2.3 基本资源查看命令

bash

kubectl get <resource> [-o widelysomlyam1] [-n namespace]
# -n 指定命名空间
# -o 指定输出格式
# --all-namespaces: 显示所有命名空间
# --show-labels: 显示所有标签
# -l app=nginx: 筛选指定标签的资源
​
kubectl get componentstatuses    # 查看 master 节点状态
kubectl get namespace            # 查看命名空间
kubectl get all -n default       # 查看default命名空间的所有资源

9.2.4 命名空间操作

bash

kubectl create ns app    # 创建命名空间
kubectl delete namespace app    # 删除命名空间

9.2.5 创建 Deployment

bash

kubectl create deployment nginx-w1 --image=nginx -n kube-public
​
# 描述某个资源的详细信息
kubectl describe deployment nginx-w1 -n kube-public
kubectl describe pod nginx-w1-d47f99cb6-hv6gz -n kube-public
kubectl get pods -n kube-public

9.2.6 登录容器与删除 Pod

bash

kubectl exec -it nginx-w1-d47f99cb6-hv6gz bash -n kube-public
kubectl delete pod nginx-w1-d47f99cb6-hv6gz -n kube-public
​
# pod无法删除，总是处于terminate状态，则要强行删除pod
kubectl delete pod <pod-name> -n <namespace> --force --grace-period=0
# grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而使雅退出，0表示立即终止pod

9.2.7 扩缩容与删除

bash

kubectl scale deployment nginx-w1 --replicas=2 -n kube-public
kubectl scale deployment nginx-w1 --replicas=1 -n kube-public
kubectl delete deployment nginx-w1 -n kube-public

---

10. 项目生命周期管理

项目的生命周期包括： 创建 → 发布 → 更新 → 回滚 → 删除

10.1 创建阶段（kubectl create）

• 创建并运行一个或多个容器镜像。

• 创建一个 deployment 或 job 来管理容器。

bash

kubectl create --help
​
# 启动 nginx 实例，暴露容器端口 80，设置副本数 3
kubectl create deployment nginx --image=nginx:1.14 --port=80 --replicas=3
kubectl get pods
kubectl get all

10.2 发布阶段（kubectl expose）

将资源暴露为 Service

bash

kubectl expose --help
​
kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

Service 类型：

类型	说明
ClusterIP	集群内部访问（默认）
NodePort	集群外部访问，端口范围 30000-32767
LoadBalancer	云平台负载均衡
externalName	映射到外部域名

扩展端口类型

• port：k8s 集群内部访问Service的端口，即通过 clusterIP: port 可以从 Pod 所在的 Node 上访问到 service

• nodePort：外部访问 k8s 集群中 service 的端口，通过 nodeIP: nodePort 可以从外部访问到某个 service

• targetPort：Pod 的端口，从 port 或 nodePort 来的流量经过 kube-proxy 反向代理负载均衡转发到后端 Pod 的 targetPort 上，最后进入容器

• containerPort：Pod 内部容器的端口，targetPort 映射到 containerPort

查看网络状态与服务端口

bash

# 查看pod网络状态详细信息和 Service暴露的端口
kubectl get pods,svc -o wide
​
# 查看关联后端的节点
kubectl get endpoints
​
# 查看 service 的描述信息
kubectl describe svc nginx
​
# 负载均衡查看（节点上）
yum install ipvsadm -y
ipvsadm -ln
​
curl 10.0.0.189
curl 192.168.10.20:44847
​
# 在master01操作 查看访问日志
kubectl logs nginx-cdb6b5b95-fjm2x
kubectl logs nginx-cdb6b5b95-g28wz
kubectl logs nginx-cdb6b5b95-x4m24

10.3 更新阶段（kubectl set）

修改容器镜像：

bash

kubectl set --help
​
# 获取修改模板
kubectl set image --help
​
# 查看当前 nginx 的版本号
curl -I http://192.168.10.20:44847
curl -I http://192.168.10.21:44847
​
# 将nginx 版本更新为 1.15 版本
kubectl set image deployment/nginx nginx=nginx:1.15
kubectl get pods -w # 处于动态监听 pod 状态，由于使用的是滚动更新方式，所以会先生成一个新的pod，然后删除一个旧的pod，往后依次类推
kubectl get pods -o wide # 再看更新好后的 Pod 的 ip 会改变

10.4 回滚阶段（kubectl rollout）

bash

# 对资源进行回滚管理
kubectl rollout --help
​
# 查看历史版本
kubectl rollout history deployment/nginx
​
# 执行回滚到上一个版本
kubectl rollout undo deployment/nginx
​
# 执行回滚到指定版本
kubectl rollout undo deployment/nginx --to-revision=1
​
# 检查回滚状态
kubectl rollout status deployment/nginx

10.5 删除阶段（kubectl delete）

bash

# 删除副本控制器
kubectl delete deployment/nginx
​
# 删除service
kubectl delete svc/nginx-service
​
kubectl get all

---

11. 发布策略

11.1 金丝雀发布（Canary Release）

Deployment控制器支持自定义控制更新过程中的滚动节奏，如"暂停(pause)"或"继续(resume)"更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定该问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

步骤：

bash

# (1) 更新deployment的版本，并配置暂停deployment
kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx
kubectl rollout status deployment/nginx # 观察更新状态
​
# (2) 监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl get pods -w
curl [-I] 10.0.0.189
curl [-I] 192.168.10.20:44847
​
# (3) 确保更新的pod没问题了，继续更新
kubectl rollout resume deployment/nginx
​
# (4) 查看最后的更新情况
kubectl get pods -w
curl [-I] 10.0.0.189
curl [-I] 192.168.80.11:44847

---

12. 声明式资源管理方法

12.1 基本原理

1. 适合于对资源的修改操作

2. 声明式资源管理方法依赖于资源配置清单文件对资源进行管理 资源配置清单文件有两种格式：yaml（人性化，易读），json（易于api接口解析）

3. 对资源的管理，是通过事先定义在统一资源配置清单内，再通过陈述式命令应用到k8s集群里

4. 语法格式：kubectl create/apply/delete -f xxxx.yaml

12.2 查看与解释配置清单

bash

# 查看资源配置清单
kubectl get deployment nginx -o yaml
​
# 解释资源配置清单
kubectl explain deployment.metadata
​
kubectl get service nginx -o yaml
kubectl explain service.metadata

12.3 修改资源配置清单并应用

离线修改： 修改yaml文件，并用 kubectl apply -f xxxx.yaml 文件使之生效 注意：当apply不生效时，先使用delete清除资源，再apply创建资源

bash

kubectl get service nginx -o yaml > nginx-svc.yaml
vim nginx-svc.yaml    # 修改port: 8080
kubectl delete -f nginx-svc.yaml
kubectl apply -f nginx-svc.yaml
kubectl get svc

在线修改： 直接使用 kubectl edit service nginx 在线编辑资源配置清单并保存退出即时生效（如port: 888） PS：此修改方式不会对yaml文件内容修改

12.4 删除资源配置清单

陈述式删除：

bash

kubectl delete service nginx

声明式删除：

bash

kubectl delete -f nginx-svc.yaml

---

总结

本文系统性地介绍了 Kubernetes 的核心概念、架构、工作流程和实际操作。Kubernetes 的强大之处在于其声明式API和自动化的控制循环 - 用户只需声明期望状态，系统便会通过精密的组件协作，自动、持续地将期望状态变为现实，并在出现偏差时进行自我修复。理解其工作流程和数据流向，是掌握 Kubernetes 运维和故障排查的关键。