K8s概念基础（一）

---

---

一、K8S概念与安装

1、云原生的基础概述

1.1 云原生的发展介绍

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

• 2004年：Google开始在内部大规模使用容器技术。
• 2008年：Google将Cgroups技术合并进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 云原生的技术栈

1.3.1 关键技术组成

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

• 容器化：如Docker、containerd，提供应用的轻量级封装和环境一致性。
• 服务网格：例如Istio，管理服务之间的通信、安全性和流量控制。
• 微服务架构：将应用拆解为多个独立的服务，支持灵活扩展和独立部署。
• 不可变基础设施：服务一旦部署，便不再修改，通常使用版本化的镜像来保持一致性。
• 声明式API：通过定义期望的状态，由系统自动管理资源。

1.3.2 云原生公式与各部分说明

云原生 = 容器化（docker+k8s）+ 微服务（Microservices）+ 无服务（Serverless）+ DevOps + Service Mesh（服务网格）+ 云（Cloud），各部分说明如下：

• 容器化（docker+k8s）：微服务的最佳载体，应用之间通过RESTful API通信。
• 微服务（Microservices）：可以被独立的部署、更新、弹性扩缩和重启。
• 无服务（Serverless）：不再着重关注底层的基础架构，更多的注意力可以放在和业务更相关的一些逻辑实现上。
• DevOps：开发、运维协同合作，实现持续交付（CD）和持续部署，快速部署到生产环境，借助自动化发布管道、持续集成（CI）工具。
• Service Mesh（服务网格）：可以让用户更精细、更智能地去管理服务之间的通讯。
• 云（Cloud）：云是云原生的基础。

1.3.3 云元素四要素

• 微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，即康威定律，指导服务怎么切分，核心意思是组织架构决定产品形态；微服务架构的好处是按function切分后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来实施。
• 容器化：Docker是应用最为广泛的容器引擎，在思科、谷歌等公司的基础设施中大量使用，基于LXC技术开发，容器化为微服务提供实施保障，起到应用隔离作用；K8S是容器编排系统，用于容器管理、容器间的负载均衡，由谷歌开发，Docker和K8S都采用Go语言编写。
• DevOps：是“Dev+Ops”的组合词，指开发和运维合体，实际还应包括测试，是一种敏捷思维、沟通文化和组织形式，为云原生提供持续交付能力。
• 持续交付：是不误时开发，不停机更新，小步快跑，不同于传统瀑布式开发模型，要求开发版本和稳定版本并存，需要诸多流程和工具支撑。

1.4 云原生的特征

1.4.1 核心特征

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

1. 符合12因素应用：应用遵循12因素开发原则，确保可扩展性、无状态性、易维护等。
2. 面向微服务架构：应用拆解为独立的、松耦合的服务。
3. 自服务敏捷架构：开发人员可以自主创建和管理云资源，减少对运维的依赖。
4. 基于API的协作：通过API进行服务间的通信。
5. 抗脆弱性：系统具有自愈能力，能够应对不稳定的环境因素。

1.4.2 12因素应用具体原则

1. 基准代码：使用同一代码库进行版本控制，并支持多次部署。
2. 依赖管理：显式声明和隔离各依赖项，确保环境一致性。
3. 配置管理：配置项存储在环境中，避免硬编码。
4. 后端服务：外部服务作为附加资源使用。
5. 构建、发布、运行分离：清晰区分应用构建和运行阶段。
6. 无状态进程：应用以无状态进程运行，便于水平扩展。
7. 端口绑定：通过端口提供服务，确保应用独立性。
8. 并发处理：通过进程模型进行扩展。
9. 快速启动与优雅终止：应用启动迅速，并在终止时确保数据一致性。
10. 开发环境与生产环境一致：确保开发、预发布和生产环境尽量一致。
11. 日志管理：统一收集并展示日志信息，确保可追溯性。
12. 管理进程：管理性任务（如数据备份）应使用与常驻进程相同的运行环境。

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

2、K8S是什么？

2.1 基本定义与起源

• 名称含义：K8S是Kubernetes的简写（K + “ubernetes”中的8个字母 + S），源自希腊语，意为“舵手/导航者”。
• 本质：是一个开源平台，用于自动部署、扩展和管理容器化（containerized）应用程序，可看作负责自动化运维、编排多个容器（如由containerd驱动的容器）的集群管理系统。
• 起源：受Google的Borg系统启发，后使用Go语言重写并捐赠给CNCF。

2.2 官网与版本节奏

• 官网：
  • 英文：https://kubernetes.io
  • 中文：https://kubernetes.io/zh-cn/docs
• 版本节奏：每年约四个发布版本（例如1.12、1.15、1.17…到1.30、1.34等）。

2.3 重要发展节点

• 2014年：Docker & Kubernetes蜜月期。
• 2015~2016年：Kubernetes & RKT vs Docker，最终Docker胜出。
• 2016年：Kubernetes逐渐赢得任务编排的胜利；Kubernetes发布CRI。
• 2017年：rkt和containerd捐献给CNCF；containerd相关发展。
• 2018年5月：k8s支持containerd。
• 2020年12月：kubernetes宣布废弃dockershim，但Mirantis和Docker宣布维护dockershim。
• 2022年5月3日：Kubernetes v1.24正式发布，涉及46项增强功能（14项升级为稳定版，15项进入beta阶段，13项进入alpha阶段，另有2项功能被弃用、2项功能被删除），关键变动是从该版本起，官方移除对Docker的内建支持（即移除dockershim），节点必须使用符合CRI（Container Runtime Interface）的运行时（如containerd、CRI-O等）。

2.4 Docker与K8S版本兼容说明

• 时间线关键节点：开源Docker发布（2013.03）、k8s开源（2014.06）、OCI成立（2015.06）、Docker Swarm发布（2016.06）等。
• 核心变动：Kubernetes从1.20开始宣布弃用内建对Docker的支持，逐步推动移除dockershim；在Kubernetes 1.24中，dockershim被正式移除。

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运行时）

4.3 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。

4.4 Kubernetes工作流程

1. 运维人员进行相关操作，处理Pod清单。
2. kube-apiserver作为集群统一入口，接收请求并传递。
3. kube-controller-manager负责维护集群状态，确保资源符合期望。
4. kube-scheduler负责资源调度，为Pod选择合适节点。
5. etcd作为分布式储存，保存整个集群状态。
6. 节点上的kubelet接收任务，通过Docker Engine创建Pod及容器。
7. kube-proxy在节点上创建网络规则，实现Service功能。

5、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等字段结构

6、Kubernetes核心能力与特性

• 自动伸缩（Horizontal Pod Autoscaler、Vertical Pod Autoscaler等）
• 服务发现 & 负载均衡
• 滚动更新 / 回滚
• 容错 / 自愈
• 集中配置 / 密钥管理（ConfigMap / Secret）
• 存储编排与持久化存储（PV / PVC / StorageClass）
• 批处理 / 定时任务
• 资源隔离 / 配额 / 限制（ResourceQuota、LimitRange等）
• 安全管理机制：如RBAC（基于角色的访问控制）、NetworkPolicy（网络策略）、Pod安全策略 / Pod安全准入（安全设置）

7、部署方式 / 常见部署方案

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

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

8、kubeadm部署k8s

k8s安装文档（见下一文章）

9、Kubernetes操作管理概述

9.1 管理操作分类

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

• 陈述式（命令式）管理方法
• 声明式（配置清单式）管理方法

9.2 陈述式资源管理方法

9.2.1 基本原理

1. Kubernetes集群资源管理的唯一入口是通过调用apiserver的接口。
2. kubectl是官方CLI命令行工具，用于与apiserver通信，将用户命令转化为apiserver能识别的请求，实现集群资源管理。
3. 查看kubectl命令大全：kubectl --help；中文文档参考：http://docs.kubernetes.org.cn/683.html。
4. 对资源的“增、删、查”操作较方便，但“改”操作相对复杂。

9.2.2 基础信息查看命令

• 版本与集群信息：
  • kubectl version：查看版本信息
  • kubectl api-resources：查看资源对象简写
  • kubectl cluster-info：查看集群信息
• 命令自动补全与日志查看：
  • source <(kubectl completion bash)：启用kubectl自动补全
  • journalctl -u kubelet -f：查看node节点日志

9.2.3 基本资源查看命令

• 基本语法：kubectl get [-o wide|json|yaml] [-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 命名空间操作

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

9.2.5 创建Deployment（副本控制器）

• kubectl create deployment nginx-wl --image=nginx -n kube-public
• kubectl create deployment
• kubectl run：自主式的pod，静态
• 描述某个资源的详细信息：
  • kubectl describe deployment nginx-wl -n kube-public
  • kubectl describe pod nginx-wl-d47f99cb6-hv6gz -n kube-public
  • kubectl get pods -n kube-public

9.2.6 登录容器与删除Pod

• 登录容器：kubectl exec -it nginx-wl-d47f99cb6-hv6gz bash -n kube-public
• 删除Pod：kubectl delete pod nginx-wl-d47f99cb6-hv6gz -n kube-public
• 强制删除Pod：若pod无法删除，总是处于terminate状态，则执行kubectl delete pod -n --force --grace-period=0（grace-period表示过渡存活期，默认30s，在删除pod之前允许POD慢慢终止其上的容器进程，从而优雅退出，0表示立即终止pod）

9.2.7 扩缩容与删除

• 扩容：kubectl scale deployment nginx-wl --replicas=2 -n kube-public
• 缩容：kubectl scale deployment nginx-wl --replicas=1 -n kube-public
• 删除Deployment：kubectl delete deployment nginx-wl -n kube-public

10、项目生命周期管理

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

10.1 创建阶段（kubectl create）

• 核心作用：创建并运行一个或多个容器镜像；创建一个deployment或job来管理容器。
• 查看帮助：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）

10.2.1 核心操作

• 作用：将资源暴露为Service
• 查看帮助：kubectl expose --help
• 示例：kubectl expose deployment nginx --port=80 --target-port=80 --name=nginx-service --type=NodePort

10.2.2 Service类型说明

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

10.2.3 扩展端口类型解释

• 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。

10.2.4 查看网络状态与服务端口

• 查看pod网络状态详细信息和Service暴露的端口：kubectl get pods,svc -o wide
  • 示例输出：

    NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
    pod/nginx-cdb6b5b95-fjm2x 1/1 Running 0 44s 172.17.26.3 192.168.80.11 <none>
    pod/nginx-cdb6b5b95-g28wz 1/1 Running 0 44s 172.17.36.3 192.168.80.12 <none>
    pod/nginx-cdb6b5b95-x4m24 1/1 Running 0 44s 172.17.36.2 192.168.80.12 <none>
    NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE SELECTOR
    service/kubernetes ClusterIP <none> 443/TCP 14d <none>
    service/nginx-service NodePort 10.0.0.189 <none> 80:44847/TCP 18s run=nginx
    

• 查看关联后端的节点：kubectl get endpoints
• 查看service的描述信息：kubectl describe svc nginx

10.2.5 负载均衡查看（节点上）

• 在node01节点上操作，安装工具：yum install ipvsadm -y
• 查看负载均衡端口：ipvsadm -Ln
  • 示例输出：

    TCP 192.168.10.21:44847 rr
    -> 172.17.26.3:80 Masq 1 0 0
    -> 172.17.36.2:80 Masq 1 0 0
    -> 172.17.36.3:80 Masq 1 0 0
    TCP 10.0.0.189:80 rr
    -> 172.17.26.3:80 Masq 1 0 0
    -> 172.17.36.2:80 Masq 1 0 0
    -> 172.17.36.3:80 Masq 1 0 0
    

• 测试访问：
  • 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）

• 核心作用：修改容器镜像等现有应用资源信息。
• 查看帮助：
  • kubectl set --help
  • 获取修改模板：kubectl set image --help
• 示例：
  • 设置deployment的nginx容器镜像为’nginx:1.9.1’，busybox容器镜像为’busybox’：kubectl set image deployment/nginx busybox=busybox nginx=nginx:1.9.1
• 实际操作：
  • 查看当前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
  • 动态监听pod状态（滚动更新会先生成新pod，再删除旧pod）：kubectl get pods -w
  • 查看更新后Pod的IP变化：kubectl get pods -o wide

10.4 回滚阶段（kubectl rollout）

• 核心作用：对资源进行回滚管理。
• 查看帮助：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）

• 删除副本控制器：kubectl delete deployment/nginx
• 删除service：kubectl delete svc/nginx-service
• 查看删除结果：kubectl get all

11、发布策略

11.1 金丝雀发布（Canary Release）

11.1.1 核心原理

Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停（pause）”或“继续（resume）”更新操作。等待第一批新的Pod资源创建完成后立即暂停更新过程，此时仅存在一部分新版本的应用，主体部分还是旧版本，再筛选一小部分用户请求路由到新版本的Pod应用，观察运行情况，确定没问题后继续完成余下Pod资源滚动更新，否则立即回滚，这就是金丝雀发布。

11.1.2 实施步骤

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 查看与解释配置清单

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

12.3 修改资源配置清单并应用（离线修改）

1. 导出配置清单：kubectl get service nginx -o yaml > nginx-svc.yaml
2. 修改配置：vim nginx-svc.yaml（例如修改port: 8080）
3. 删除原有资源：kubectl delete -f nginx-svc.yaml
4. 应用新配置：kubectl apply -f nginx-svc.yaml
5. 查看结果：kubectl get svc

注意：当apply不生效时，先使用delete清除资源，再apply创建资源。

12.4 在线修改

• 操作命令：直接使用kubectl edit service nginx在线编辑资源配置清单并保存退出即时生效（如修改port: 888）。
• 注意事项：此修改方式不会对本地yaml文件内容修改。

12.5 删除资源配置清单

• 陈述式删除：kubectl delete service nginx
• 声明式删除：kubectl delete -f nginx-svc.yaml

12.6 总结

Kubernetes提供了两种管理方式：陈述式管理和声明式管理。其中，陈述式适用于简单的命令执行，声明式则更加灵活和可扩展。无论是通过命令行的方式还是通过配置文件管理，Kubernetes都能帮助管理员有效地管理集群资源，支持滚动更新、回滚、金丝雀发布等多种发布策略，确保应用的稳定性和高可用性。