Kubernetes学习记录与实战指南
简介：Kubernetes（简称K8s）是一个用于自动化部署、扩展和管理容器化应用的开源容器编排系统，现已成为云原生应用的核心技术。本学习记录项目详细介绍了Kubernetes的基础概念与核心组件，包括Pod、Service、Deployment、ConfigMap、Secret、Ingress等，并通过实际操作和代码示例帮助学习者掌握Kubectl命令、YAML配置文件编写以及使用Python客户端与Kubernetes API交互。项目内容涵盖集群管理、资源调度、服务发现、自动扩展等关键技能，适合初学者和进阶者系统学习Kubernetes并构建可扩展的云原生架构。
1. Kubernetes基础概念与架构解析
Kubernetes（简称K8s）起源于Google内部的Borg系统，现已成为云原生计算基金会（CNCF）的核心项目。它提供了一种自动化部署、扩展和管理容器化应用的能力。Kubernetes架构由控制平面（Control Plane）和工作节点（Worker Nodes）组成。控制平面负责集群的全局决策，如调度、状态维护；工作节点则运行容器化应用。
核心概念包括：
- Pod ：最小部署单元，包含一个或多个共享资源的容器。
- Service ：定义一组Pod的访问策略，实现服务发现与负载均衡。
- Controller ：确保集群实际状态与期望状态一致，如Deployment、ReplicaSet等。
其在云原生生态中扮演着“操作系统”角色，为微服务、持续交付、弹性伸缩等提供了坚实基础。
2. Kubernetes资源对象管理与编排机制
在 Kubernetes 的生态系统中，资源对象管理与编排机制是实现容器化应用高效调度与自动化运维的核心模块。通过资源对象的定义与控制器的编排策略，Kubernetes 能够实现服务的高可用性、弹性伸缩以及版本更新等功能。本章将深入探讨 Kubernetes 中关键资源对象的生命周期、调度机制、服务发现、状态管理等内容，帮助读者构建对 Kubernetes 资源管理的系统性理解。
2.1 Pod的生命周期与调度策略
Pod 是 Kubernetes 中最小的部署单元，它包含一个或多个共享资源的容器。理解 Pod 的生命周期以及其调度机制是掌握 Kubernetes 资源管理的基础。
2.1.1 Pod的创建、运行与终止流程
Pod 的生命周期由 Kubernetes 控制器（如 Deployment、StatefulSet）或用户直接定义后提交到 API Server，随后经历以下几个阶段：
- Pending ：Pod 已被创建，但尚未被调度到节点上。
- Scheduled ：Pod 被调度器分配到某个节点。
- ContainersCreating ：容器镜像正在拉取，容器初始化中。
- Running ：Pod 中至少一个容器正在运行。
- Succeeded/Failed ：Pod 中所有容器执行完成或失败。
- Unknown ：Pod 状态无法获取，通常由于节点通信问题。
示例：查看 Pod 生命周期状态
# pod-example.yaml
apiVersion: v1
kind: Pod
metadata:
name: lifecycle-pod
spec:
containers:
- name: nginx
image: nginx
执行命令创建 Pod：
kubectl apply -f pod-example.yaml
查看 Pod 状态变化：
kubectl get pod lifecycle-pod -w
输出示例：
NAME READY STATUS RESTARTS AGE
lifecycle-pod 0/1 Pending 0 0s
lifecycle-pod 0/1 Pending 0 2s
lifecycle-pod 0/1 ContainerCreating 0 3s
lifecycle-pod 1/1 Running 0 10s
逐行解读：
-Pending：Pod 已被 API Server 接收，但尚未调度。
-ContainerCreating：调度完成后，容器开始创建。
-Running：容器已成功启动，进入运行状态。
2.1.2 调度器如何影响Pod的节点选择
Kubernetes 调度器（Scheduler）负责将 Pod 分配到合适的节点上运行。调度过程基于一系列预选策略（Predicates）和优选策略（Priorities）。
调度流程图（mermaid）
graph TD
A[Pod创建] --> B[调度器监听事件]
B --> C{节点筛选}
C --> D[预选策略]
D --> E[节点资源是否足够]
D --> F[节点标签是否匹配]
C --> G[优选策略]
G --> H[资源均衡打分]
G --> I[节点负载打分]
G --> J[最终节点选择]
J --> K[Pod绑定到节点]
示例：通过节点选择器调度 Pod
# pod-node-selector.yaml
apiVersion: v1
kind: Pod
metadata:
name: node-pod
spec:
nodeSelector:
disktype: ssd
containers:
- name: main-app
image: nginx
参数说明：
-nodeSelector：用于指定节点标签，Pod 将仅调度到带有disktype=ssd标签的节点上。
执行命令查看节点标签：
kubectl get nodes --show-labels
2.1.3 Pod的重启策略与健康检查机制
Pod 可以通过 restartPolicy 设置容器重启策略，并结合 livenessProbe 和 readinessProbe 实现健康检查。
示例：配置健康检查与重启策略
# pod-health-check.yaml
apiVersion: v1
kind: Pod
metadata:
name: health-pod
spec:
restartPolicy: Always
containers:
- name: web
image: nginx
livenessProbe:
httpGet:
path: /index.html
port: 80
initialDelaySeconds: 15
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready.html
port: 80
initialDelaySeconds: 5
periodSeconds: 5
参数说明：
-restartPolicy:Always表示容器退出后总是重启。
-livenessProbe: 检查容器是否存活，失败则重启容器。
-readinessProbe: 检查容器是否准备好接受流量，失败则从 Service 后端移除。
2.2 Deployment控制器与滚动更新
Deployment 是 Kubernetes 中用于管理无状态应用的控制器之一，支持滚动更新和版本回滚。
2.2.1 Deployment的定义与核心字段解析
Deployment 控制器确保指定数量的 Pod 副本持续运行，并支持版本升级。
示例：Deployment 定义
# deployment-example.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
字段解析：
-replicas: 指定 Pod 副本数。
-selector: 选择器用于匹配 Pod 标签。
-template: 定义 Pod 的模板。
2.2.2 实现无中断的滚动更新策略
Kubernetes 提供了滚动更新（RollingUpdate）策略，确保新版本逐步替换旧版本，避免服务中断。
示例：滚动更新配置
# deployment-rolling.yaml
spec:
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1
参数说明：
-maxSurge: 最多可以创建的额外 Pod 数量。
-maxUnavailable: 最多允许不可用的 Pod 数量。
执行更新命令：
kubectl set image deployment/nginx-deployment nginx=nginx:1.16.1
查看滚动更新状态：
kubectl rollout status deployment/nginx-deployment
2.2.3 版本回滚与状态观察
当新版本出现问题时，可通过 rollout undo 回滚到上一个稳定版本。
示例：版本回滚操作
kubectl rollout history deployment/nginx-deployment
输出示例：
REVISION CHANGE-CAUSE
1 <none>
2 <none>
回滚到版本1：
kubectl rollout undo deployment/nginx-deployment --to-revision=1
查看当前状态：
kubectl describe deployment/nginx-deployment
2.3 Service服务发现与网络模型
Service 是 Kubernetes 中用于实现服务发现与负载均衡的核心资源，支持多种访问类型。
2.3.1 ClusterIP、NodePort与LoadBalancer类型详解
Service 有三种主要类型：
| 类型 | 描述 |
|---|---|
| ClusterIP | 默认类型，仅在集群内部访问 |
| NodePort | 在每个节点的指定端口暴露服务 |
| LoadBalancer | 云厂商提供负载均衡器对外暴露服务 |
示例：定义不同类型的 Service
# service-example.yaml
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
type: NodePort
selector:
app: nginx
ports:
- protocol: TCP
port: 80
targetPort: 80
nodePort: 30080
参数说明：
-type: 指定 Service 类型。
-nodePort: 当类型为 NodePort 时，指定节点暴露端口。
2.3.2 Endpoints机制与服务后端Pod的绑定
Service 通过 Label Selector 与 Pod 绑定，Endpoints 资源记录实际的 Pod IP 地址。
查看 Endpoints：
kubectl get endpoints my-service
输出示例：
NAME ENDPOINTS
my-service 10.244.1.3:80,10.244.2.4:80
2.3.3 CNI网络插件与Pod间通信原理
Kubernetes 使用 CNI（Container Network Interface）插件实现 Pod 之间的通信。常见的 CNI 插件包括 Calico、Flannel、Cilium 等。
网络通信流程图（mermaid）
graph TD
A[Pod A] --> B[本地CNI网桥]
B --> C[网络插件路由]
C --> D[Pod B所在节点]
D --> E[Pod B]
2.4 StatefulSets与有状态应用管理
StatefulSet 是 Kubernetes 中专门用于管理有状态应用的控制器，适用于如数据库、消息队列等需要稳定标识和持久化存储的场景。
2.4.1 StatefulSets与Deployment的异同
| 特性 | Deployment | StatefulSet |
|---|---|---|
| Pod 名称 | 无序 | 有序，如 web-0, web-1 |
| 启动顺序 | 并行 | 串行 |
| 存储 | 一般不绑定 | 支持绑定 PVC |
| 网络标识 | 无 | 有稳定 DNS 名称 |
2.4.2 稳定的网络标识与持久化存储绑定
StatefulSet 为每个 Pod 分配唯一的序号，并结合 Headless Service 提供稳定的 DNS 解析。
示例：定义 StatefulSet
# statefulset-example.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
参数说明：
-volumeClaimTemplates: 定义 PVC 模板，每个 Pod 独享一个 PVC。
-serviceName: 用于绑定 Headless Service。
2.4.3 有状态应用的滚动更新策略
StatefulSet 支持滚动更新，但默认策略为 OnDelete ，即手动删除 Pod 后才会触发更新。
修改更新策略：
spec:
updateStrategy:
type: RollingUpdate
rollingUpdate:
partition: 2
参数说明：
-partition: 指定保留旧版本的 Pod 数量。
执行更新：
kubectl rolling-update statefulset/web --to-replicas=3
本章深入讲解了 Kubernetes 中资源对象的生命周期管理、控制器机制、服务发现与网络通信模型，以及有状态应用的管理方式。通过实际操作与原理分析，读者可以掌握 Kubernetes 资源对象管理的核心机制，为后续的集群管理与应用部署打下坚实基础。
3. Kubernetes配置管理与安全策略
在 Kubernetes 中，配置管理与安全策略是保障系统稳定运行和应用安全的关键环节。Kubernetes 提供了 ConfigMaps、Secrets、Volumes、Namespaces、Ingress 等机制，帮助开发者和运维人员实现配置集中管理、敏感信息加密存储、多租户隔离以及外部访问控制。本章将深入探讨这些核心配置管理机制与安全策略的使用方式、实现原理以及最佳实践。
3.1 ConfigMaps 与 Secrets 的使用场景
ConfigMaps 和 Secrets 是 Kubernetes 中用于管理应用程序配置和敏感信息的两种核心资源对象。它们允许开发者将配置数据与容器镜像分离，从而提高应用的灵活性和安全性。
3.1.1 环境变量注入与配置文件挂载方式
ConfigMaps 可以通过两种方式注入到容器中：
- 环境变量注入 ：将键值对直接注入到容器的环境变量中。
- 配置文件挂载 ：将 ConfigMap 挂载为一个或多个配置文件。
示例：使用 ConfigMap 注入环境变量
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
DB_URL: "mysql://db-host:3306"
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-container
image: my-app:latest
envFrom:
- configMapRef:
name: app-config
逻辑分析：
ConfigMap定义了两个键值对：LOG_LEVEL和DB_URL。- 在
Deployment中，使用envFrom引用该 ConfigMap，将所有键值对作为环境变量注入容器。 - 这样做的好处是配置与代码分离，便于在不同环境中灵活配置。
参数说明：
envFrom：表示从某个 ConfigMap 或 Secret 中注入所有环境变量。configMapRef.name：指定要引用的 ConfigMap 名称。
3.1.2 Secret 的加密存储与访问控制
Secret 用于存储敏感数据，如密码、OAuth token、TLS 私钥等。Kubernetes 会将 Secret 数据以 Base64 编码形式存储，但不提供加密功能，因此建议结合 RBAC 和网络策略进行访问控制。
示例：创建并使用 Secret
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
data:
username: dXNlcgo=
password: cGFzc3dvcmQ=
apiVersion: v1
kind: Pod
metadata:
name: my-secret-pod
spec:
containers:
- name: my-container
image: nginx
env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: app-secret
key: username
- name: DB_PASS
valueFrom:
secretKeyRef:
name: app-secret
key: password
逻辑分析：
Secret的type: Opaque表示这是一个通用的 Secret。data字段的值需要经过 Base64 编码。- 在 Pod 中通过
secretKeyRef引用 Secret 的具体键值作为环境变量。
安全建议：
- 不要将 Secret 以明文方式提交到 Git 仓库。
- 配合 RBAC 策略限制对 Secret 的访问权限。
- 使用加密的 etcd 后端或第三方工具（如 HashiCorp Vault）增强安全性。
3.1.3 ConfigMaps 版本控制与更新策略
ConfigMap 的更新不会自动触发 Pod 的滚动更新，因此需要通过以下方式实现热更新：
- 手动删除 Pod ：Pod 会因 ReplicaSet 控制器重新创建，从而加载最新的 ConfigMap。
- 使用 ConfigMap 的版本号作为注解 ：在 Deployment 中添加
checksum/configMap注解，触发滚动更新。
示例：使用注解触发滚动更新
spec:
template:
metadata:
annotations:
checksum/configmap: {{ hash }}
参数说明：
checksum/configmap：用于记录 ConfigMap 的哈希值，当 ConfigMap 变化时，哈希值变化会触发 Pod 的重建。
3.2 Volumes 持久化存储配置
Kubernetes 提供多种方式实现容器的数据持久化，包括临时卷（emptyDir）、节点本地卷（hostPath）、持久卷（PersistentVolume）和动态卷供应（StorageClass）等。
3.2.1 emptyDir、hostPath 与 PV/PVC 机制对比
| 类型 | 描述 | 生命周期 | 适用场景 |
|---|---|---|---|
| emptyDir | Pod 生命周期内的临时卷 | 临时 | 缓存、临时文件 |
| hostPath | 挂载宿主机文件系统路径 | 永久 | 节点级别数据访问 |
| PV/PVC | 抽象存储资源，支持多种存储后端 | 永久 | 有状态服务、数据库 |
| StorageClass | 动态提供 PV，支持按需分配存储资源 | 永久 | 自动化存储管理 |
示例：使用 PVC 挂载持久卷
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
apiVersion: v1
kind: Pod
metadata:
name: my-pv-pod
spec:
containers:
- name: my-container
image: nginx
volumeMounts:
- name: my-volume
mountPath: /usr/share/nginx/html
volumes:
- name: my-volume
persistentVolumeClaim:
claimName: my-pvc
逻辑分析：
- PVC 申请 1Gi 存储空间，并指定访问模式为
ReadWriteOnce（单节点读写）。 - Pod 通过
persistentVolumeClaim引用 PVC，并将其挂载为容器的/usr/share/nginx/html目录。
3.2.2 StorageClass 与动态卷供应
StorageClass 定义了存储类别的类型和参数，支持动态创建 PV。
示例：定义并使用 StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast
provisioner: kubernetes.io/aws-ebs
parameters:
type: gp2
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-dynamic-pvc
spec:
storageClassName: fast
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
逻辑分析：
provisioner指定由 AWS EBS 插件动态创建卷。- PVC 使用
storageClassName: fast，系统将根据 StorageClass 自动创建 PV。
3.2.3 CSI 插件与外部存储集成
CSI（Container Storage Interface）是一种标准接口，允许 Kubernetes 集成第三方存储系统，如 AWS EBS、Azure Disk、Ceph 等。
示例流程图：CSI 插件工作流程
graph TD
A[Controller Manager] --> B[CSI Controller Plugin]
B --> C[调用外部存储 API 创建 PV]
D[Scheduler] --> E[调度 Pod 到目标节点]
E --> F[Node Plugin]
F --> G[挂载卷到 Pod]
分析：
- CSI 插件分为 Controller Plugin 和 Node Plugin。
- Controller Plugin 负责创建和删除卷。
- Node Plugin 负责挂载和卸载卷。
3.3 Namespaces 与多租户隔离
Namespaces 是 Kubernetes 中实现多租户隔离的核心机制。它可以将集群资源划分为多个逻辑组，便于不同团队或项目的管理。
3.3.1 命名空间的资源隔离机制
Namespaces 提供了以下隔离机制：
- 资源隔离 ：Pod、Service、Deployment 等资源默认只在当前 Namespace 内可见。
- 网络隔离 ：配合 CNI 插件和网络策略实现跨 Namespace 网络通信控制。
- 配额限制 ：通过 ResourceQuota 和 LimitRange 限制资源使用。
示例：创建并使用 Namespace
kubectl create namespace dev
kubectl run nginx --image=nginx --namespace=dev
逻辑分析：
- 使用
--namespace指定资源所属的 Namespace。 - 若未指定，则默认使用
default命名空间。
3.3.2 ResourceQuota 与 LimitRange 配置
ResourceQuota 用于限制整个 Namespace 的资源总量，LimitRange 用于限制单个 Pod 或容器的最小/最大资源请求。
示例：配置 ResourceQuota 和 LimitRange
apiVersion: v1
kind: ResourceQuota
metadata:
name: mem-cpu-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
apiVersion: v1
kind: LimitRange
metadata:
name: mem-cpu-limit-range
namespace: dev
spec:
limits:
- default:
memory: 512Mi
cpu: 500m
defaultRequest:
memory: 256Mi
cpu: 100m
逻辑分析：
ResourceQuota限制 dev Namespace 总共只能申请 1 CPU 和 1Gi 内存。LimitRange设置每个容器默认最大 512Mi 内存和 500m CPU。
3.3.3 基于 RBAC 的权限控制模型
RBAC（Role-Based Access Control）是 Kubernetes 的权限控制模型，通过 Role、RoleBinding、ClusterRole、ClusterRoleBinding 实现精细的权限控制。
示例：为 dev Namespace 配置只读权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: dev
name: dev-reader
rules:
- apiGroups: [""]
resources: ["pods", "services"]
verbs: ["get", "watch", "list"]
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: dev-read-access
namespace: dev
subjects:
- kind: User
name: dev-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: dev-reader
apiGroup: rbac.authorization.k8s.io
逻辑分析：
Role定义了在 dev Namespace 中对 pods 和 services 的只读权限。RoleBinding将 dev-user 用户绑定到该 Role，授予相应权限。
3.4 Ingress 与外部访问控制
Ingress 是 Kubernetes 中用于对外暴露 HTTP/HTTPS 服务的 API 对象，通常与 Ingress Controller（如 Nginx、Traefik）配合使用。
3.4.1 Ingress 控制器与负载均衡器配置
Ingress Controller 是一个独立的 Pod，负责监听 Ingress 规则并配置反向代理服务。
示例：部署 Nginx Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.1.0/deploy/static/provider/cloud/deploy.yaml
逻辑分析：
- 该命令部署了 Nginx Ingress Controller。
- 它会自动创建 Service 并与云平台的负载均衡器绑定。
3.4.2 TLS 加密与基于路径的路由规则
Ingress 支持配置 TLS 加密和基于路径的路由。
示例：配置 TLS 和路径路由
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-ingress
annotations:
nginx.ingress.kubernetes.io/rewrite-target: /
spec:
tls:
- hosts:
- example.com
secretName: example-tls
rules:
- host: example.com
http:
paths:
- path: /api
pathType: Prefix
backend:
service:
name: api-service
port:
number: 80
- path: /web
pathType: Prefix
backend:
service:
name: web-service
port:
number: 80
逻辑分析：
tls字段指定 TLS 证书的 Secret 名称。rules定义了基于路径的路由规则，将/api转发到 api-service，/web转发到 web-service。
3.4.3 Ingress 注解与高级流量控制策略
Ingress 注解用于控制 Ingress Controller 的行为，如重定向、限流、灰度发布等。
示例：使用注解实现限流
annotations:
nginx.ingress.kubernetes.io/limit-rps: "10"
分析：
limit-rps表示每秒请求上限为 10 次。- Ingress Controller 会根据此注解自动配置限流策略。
小结（非总结）
本章深入探讨了 Kubernetes 的配置管理与安全策略，包括 ConfigMaps 与 Secrets 的使用方式、Volumes 的持久化机制、Namespaces 的多租户隔离机制以及 Ingress 的外部访问控制。通过本章内容，读者可以掌握如何在实际环境中灵活运用这些机制，保障应用的配置可维护性与运行安全性。下一章将围绕 Kubernetes 的集群管理与自动化运维展开，进一步提升系统的可观测性与自愈能力。
4. Kubernetes集群管理与自动化运维
Kubernetes 作为云原生领域的核心编排平台，其集群管理能力直接影响系统的稳定性、弹性和资源利用率。本章将深入探讨 Kubernetes 的节点管理、自动扩缩容机制、API Server 交互原理以及控制器管理器与调度器的核心机制。通过本章内容，读者将掌握 Kubernetes 集群运维的核心技能，并理解其底层实现逻辑。
4.1 Nodes节点管理与资源调度
在 Kubernetes 集群中，Node 是承载 Pod 的工作节点。节点的管理涉及资源调度、节点状态监控、资源分配优化等多个方面。有效的节点管理不仅能提升资源利用率，还能增强系统的稳定性和可扩展性。
4.1.1 节点状态与资源容量监控
Kubernetes 使用 kubelet 组件来定期上报节点的状态信息，包括 CPU、内存使用情况、磁盘空间、节点就绪状态等。这些信息存储在 Kubernetes 的 API Server 中，并可通过 kubectl describe node <node-name> 命令查看。
kubectl describe node node-1
输出示例如下：
| 属性 | 值 |
|---|---|
| CPU Capacity | 8 cores |
| Memory Capacity | 32Gi |
| CPU Allocatable | 7.5 cores |
| Memory Allocatable | 30Gi |
| Conditions | Ready, DiskPressure: False |
逻辑分析：
- Capacity 表示节点的总资源容量；
- Allocatable 表示可供 Pod 调度使用的资源；
- Conditions 显示节点的当前状态，如是否 Ready、是否有磁盘压力等。
此外，可以通过 Prometheus + Node Exporter 的方式实现更细粒度的资源监控与告警。
4.1.2 Taints与Toleration机制解析
Taints（污点）和 Tolerations（容忍）机制用于控制 Pod 在节点上的调度策略，防止某些 Pod 被调度到不合适的节点上。
添加 Taint 到节点：
kubectl taint nodes node-1 env=prod:NoSchedule
env=prod是键值对；NoSchedule表示不调度，但已存在的 Pod 仍可运行；- 其他选项包括
NoExecute（不执行新 Pod 且驱逐旧 Pod）和PreferNoSchedule（尽量不调度）。
在 Pod 中添加 Toleration：
tolerations:
- key: "env"
operator: "Equal"
value: "prod"
effect: "NoSchedule"
逻辑分析：
只有具有对应 Toleration 的 Pod 才能被调度到带有该 Taint 的节点上。该机制可用于隔离测试环境与生产环境、控制 GPU 节点的专属调度等。
4.1.3 节点资源分配策略与调度优化
Kubernetes 默认调度器根据资源请求（resources.requests）来分配 Pod。为了优化资源分配，可采取以下策略：
- 资源请求与限制设置：
yaml resources: requests: memory: "512Mi" cpu: "500m" limits: memory: "1Gi" cpu: "1"
requests是调度器决策的依据；limits控制容器运行时的最大资源使用。
- 使用 Node Selector 和 Affinity：
yaml affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: disktype operator: In values: - ssd
逻辑分析：
上述配置表示 Pod 只能被调度到标签为 disktype=ssd 的节点上，从而实现资源调度的精细化控制。
4.2 Horizontal Pod Autoscaler自动扩缩容
Horizontal Pod Autoscaler（HPA）是 Kubernetes 提供的自动扩缩容机制，能够根据 CPU、内存等指标动态调整 Pod 副本数量，从而实现资源的弹性伸缩。
4.2.1 HPA的指标采集与扩缩容逻辑
HPA 默认使用 kubelet 上报的 CPU 使用率进行扩缩容决策，其核心逻辑如下：
kubectl autoscale deployment my-app --cpu-percent=50 --min=2 --max=10
--cpu-percent=50表示当 CPU 使用率超过 50% 时开始扩容；--min=2表示最少保持 2 个副本；--max=10表示最多扩容到 10 个副本。
HPA 工作流程图（Mermaid）：
graph TD
A[HPA Controller] --> B{获取指标}
B --> C[CPU/Memory使用率]
B --> D[自定义指标]
C --> E{是否达到阈值}
D --> E
E -- 是 --> F[调整副本数量]
F --> G[更新Deployment/ReplicaSet]
G --> H[创建/销毁Pod]
E -- 否 --> I[维持当前副本数]
4.2.2 自定义指标与Prometheus集成
除了默认的 CPU 指标，HPA 也支持基于自定义指标的扩缩容，例如请求延迟、QPS 等。
配置步骤：
- 安装 Prometheus + Metrics Server；
- 部署 Adapter（如 prometheus-adapter）用于暴露自定义指标；
- 修改 HPA 配置为使用自定义指标：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: my-app
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: my-app
minReplicas: 2
maxReplicas: 10
metrics:
- type: Pods
pods:
metric:
name: http_requests_per_second
target:
type: AverageValue
averageValue: 100
逻辑分析：
当每秒的 HTTP 请求超过 100 次时，HPA 将自动扩容 Pod 副本数，从而应对高并发场景。
4.2.3 HPA的边界条件与稳定性保障
HPA 的扩缩容行为可能引发震荡（即频繁扩缩容），为避免该问题，Kubernetes 提供了以下机制：
- Stabilization Window（稳定窗口） ：默认为 5 分钟，防止短时间波动；
- Tolerance（容忍度） ：默认容忍 10% 的波动；
- MinReplicas 与 MaxReplicas ：设置上下限，防止资源耗尽或浪费。
behavior:
scaleUp:
stabilizationWindowSeconds: 300
policies:
- type: Pods
value: 4
periodSeconds: 60
scaleDown:
stabilizationWindowSeconds: 300
policies:
- type: Percent
value: 10
periodSeconds: 60
逻辑分析：
- scaleUp 表示扩容策略，每 60 秒最多增加 4 个 Pod；
- scaleDown 表示缩容策略，每 60 秒最多减少当前副本数的 10%。
4.3 Kubernetes API Server交互原理
API Server 是 Kubernetes 集群的核心组件，负责接收客户端请求、处理资源对象、协调集群状态。本节将深入解析其交互机制与核心功能。
4.3.1 API资源的RESTful设计与版本演进
Kubernetes API 遵循 RESTful 设计，资源类型（Kind）与版本（APIVersion）通过 URL 路径进行区分：
GET /apis/apps/v1/namespaces/default/deployments
/apis/apps/v1表示 API 组与版本；/namespaces/default/deployments表示资源路径。
Kubernetes 支持多个 API 版本共存，如 v1beta1 、 v1 ，允许渐进式升级与兼容性维护。
4.3.2 认证、授权与准入控制机制
API Server 的安全机制包括三个阶段：
- 认证（Authentication）： 包括 Token、Bearer Token、X509 客户端证书等；
- 授权（Authorization）： 基于 RBAC 模型控制用户对资源的访问权限；
- 准入控制（Admission Control）： 在资源创建前进行额外校验与修改。
RBAC 配置示例：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
逻辑分析：
上述配置授予用户在 default 命名空间中查看 Pod 的权限。
4.3.3 Watch机制与事件驱动模型
Kubernetes 使用 Watch 机制实现实时事件监听，客户端可通过 Watch 接口监听资源变化：
from kubernetes import client, config, watch
config.load_kube_config()
v1 = client.CoreV1Api()
w = watch.Watch()
for event in w.stream(v1.list_pod_for_all_namespaces):
print("Event: %s %s" % (event['type'], event['object'].metadata.name))
逻辑分析：
该脚本将持续监听所有命名空间中的 Pod 事件（如创建、删除、更新），并打印事件类型与 Pod 名称。
4.4 Controller Manager与调度器机制
Controller Manager 负责运行一系列控制器，确保集群的期望状态与实际状态一致。而调度器则决定 Pod 应该运行在哪个节点上。
4.4.1 ReplicaSet、DaemonSet等控制器实现原理
控制器通过持续监控集群状态，并根据期望状态做出调整。例如：
- ReplicaSet： 确保指定数量的 Pod 副本处于运行状态；
- DaemonSet： 在每个节点上运行一个 Pod；
- StatefulSet： 管理有状态应用，保证 Pod 的有序性与唯一性。
ReplicaSet 示例：
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-rs
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
逻辑分析：
该 ReplicaSet 会确保始终有 3 个 app=nginx 标签的 Pod 在运行。
4.4.2 调度器的优先级与打分机制
Kubernetes 默认调度器采用“过滤 + 打分”两阶段策略：
- 过滤阶段（Predicates）： 筛选满足条件的节点；
- 打分阶段（Priorities）： 对符合条件的节点打分，选择最优节点。
调度策略配置示例：
apiVersion: kubescheduler.config.k8s.io/v1beta1
kind: KubeSchedulerConfiguration
profiles:
- schedulerName: default-scheduler
plugins:
score:
enabled:
- name: NodeResourcesFit
- name: NodeAffinity
逻辑分析：
- NodeResourcesFit 表示根据资源可用性打分；
- NodeAffinity 表示根据节点亲和性打分。
4.4.3 自定义调度器与扩展调度策略
Kubernetes 支持使用自定义调度器，用户可通过 schedulerName 指定使用哪个调度器：
spec:
schedulerName: custom-scheduler
逻辑分析：
Kubernetes 允许部署多个调度器，适用于多租户、异构集群等场景。
本章深入探讨了 Kubernetes 集群管理与自动化运维的核心机制，包括节点管理、自动扩缩容、API Server 交互原理以及控制器与调度器的工作机制。通过本章内容，读者可以掌握如何构建高效、稳定、弹性的 Kubernetes 集群，并具备进一步优化与定制集群的能力。
5. Kubernetes实战与云原生应用部署
5.1 Kubectl命令行工具深度使用
Kubernetes的命令行工具kubectl是开发者和运维人员操作集群的核心工具。熟练掌握kubectl命令不仅能提高操作效率，还能帮助快速定位和解决集群问题。
5.1.1 常用命令与资源操作技巧
kubectl提供了丰富的子命令来操作Kubernetes资源对象。以下是一些常用命令及其用途：
| 命令 | 描述 |
|---|---|
kubectl get pods |
获取默认命名空间下的Pod列表 |
kubectl get pods -n <namespace> |
获取指定命名空间下的Pod |
kubectl describe pod <pod-name> |
查看某个Pod的详细信息 |
kubectl logs <pod-name> |
查看Pod的日志输出 |
kubectl exec -it <pod-name> -- /bin/bash |
进入Pod容器内部执行命令 |
kubectl apply -f <file.yaml> |
应用YAML配置文件部署资源 |
kubectl delete -f <file.yaml> |
删除YAML文件中定义的资源 |
kubectl rollout status deployment/<deployment-name> |
查看Deployment滚动更新状态 |
示例：查看集群节点信息
kubectl get nodes
输出示例：
NAME STATUS ROLES AGE VERSION
control-plane Ready master 1d v1.26.0
worker-node1 Ready <none> 1d v1.26.0
worker-node2 Ready <none> 1d v1.26.0
5.1.2 YAML模板生成与资源配置校验
在部署复杂应用时，手动编写YAML文件容易出错。kubectl提供了一些辅助命令帮助生成和验证YAML配置。
生成YAML模板示例：
kubectl run my-pod --image=nginx --dry-run=client -o yaml
输出：
apiVersion: v1
kind: Pod
metadata:
creationTimestamp: null
labels:
run: my-pod
name: my-pod
spec:
containers:
- image: nginx
name: my-pod
resources: {}
dnsPolicy: ClusterFirst
restartPolicy: Always
status: {}
配置文件校验：
kubectl apply -f my-pod.yaml --dry-run=client
该命令会在不实际执行的情况下验证配置文件的语法和字段是否正确。
5.1.3 Debug与故障排查常用命令集
当Pod无法正常运行时，可以通过以下命令进行排查：
- 查看Pod状态：
kubectl get pods
- 查看Pod事件日志：
kubectl describe pod <pod-name>
- 查看容器日志：
kubectl logs <pod-name>
- 进入容器调试：
kubectl exec -it <pod-name> -- /bin/sh
示例：排查Pending状态的Pod
kubectl describe pod my-pod
可能输出：
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 5s (x10 over 20s) default-scheduler 0/3 nodes are available: 3 node(s) had taints that the pod didn't tolerate.
这说明调度失败，可能是节点有Taint而Pod没有配置对应的Toleration。
5.2 YAML配置文件编写规范与最佳实践
YAML文件是Kubernetes中定义资源的标准方式。编写清晰、规范的YAML文件是部署应用的基础。
5.2.1 配置文件结构与字段说明
一个典型的Deployment YAML文件如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
字段说明：
apiVersion：资源所属的API组和版本kind：资源类型（如Deployment、Service等）metadata：元数据，包括名称、标签等spec：资源的期望状态定义replicas：副本数量selector：选择哪些Pod属于该Deploymenttemplate：Pod模板定义containers：容器定义列表
5.2.2 多环境配置与Helm模板化部署
在不同环境（开发、测试、生产）中部署相同应用时，配置往往不同。使用Helm可以实现模板化部署。
Helm Chart目录结构示例：
mychart/
├── Chart.yaml
├── values.yaml
├── templates/
│ ├── deployment.yaml
│ ├── service.yaml
│ └── _helpers.tpl
values.yaml示例：
replicaCount: 3
image:
repository: nginx
tag: "1.14.2"
service:
type: ClusterIP
port: 80
模板化Deployment示例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: {{ include "mychart.fullname" . }}
spec:
replicas: {{ .Values.replicaCount }}
...
通过 helm install 命令即可部署应用，并通过 --set 参数覆盖特定配置。
5.2.3 配置安全性与敏感信息处理
敏感信息（如密码、API Key）应使用Secret管理。避免在YAML中硬编码明文密码。
创建Secret命令：
kubectl create secret generic my-secret --from-literal=password=mysecretpassword
在Pod中使用Secret：
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: my-secret
key: password
这样可以确保敏感信息不会暴露在配置文件中，提高安全性。
（本章内容将继续在下一节深入探讨Python客户端与Kubernetes API的交互实践。）
简介：Kubernetes（简称K8s）是一个用于自动化部署、扩展和管理容器化应用的开源容器编排系统，现已成为云原生应用的核心技术。本学习记录项目详细介绍了Kubernetes的基础概念与核心组件，包括Pod、Service、Deployment、ConfigMap、Secret、Ingress等，并通过实际操作和代码示例帮助学习者掌握Kubectl命令、YAML配置文件编写以及使用Python客户端与Kubernetes API交互。项目内容涵盖集群管理、资源调度、服务发现、自动扩展等关键技能，适合初学者和进阶者系统学习Kubernetes并构建可扩展的云原生架构。
码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践
更多推荐
16
0- 0
已为社区贡献4条内容
所有评论(0)