203 lines
6.8 KiB
Markdown
203 lines
6.8 KiB
Markdown
---
|
||
tags: [kubernetes, pod, deployment, probe, container-orchestration]
|
||
create time: 2026-05-18 00:30
|
||
---
|
||
|
||
# K8s 核心概念与 Deployment — 教程
|
||
|
||
## 概述
|
||
|
||
本文档带你从零理解 Kubernetes 的核心对象模型，并掌握 Deployment 这个最常用的工作负载控制器。更多进阶主题（资源配置、服务发现、调度）分散在后续章节中。总览和决策矩阵见 [[../02-Kubernetes]]。
|
||
|
||
## K8s 架构全景
|
||
|
||
```mermaid
|
||
graph TB
|
||
subgraph CONTROL["控制面 Control Plane"]
|
||
APISERVER["API Server<br/>唯一入口"]
|
||
SCHEDULER["Scheduler<br/>调度决策"]
|
||
CMGR["Controller Manager<br/>状态协调"]
|
||
ETCD["etcd<br/>分布式 KV 存储"]
|
||
|
||
APISERVER --> SCHEDULER
|
||
APISERVER --> CMGR
|
||
APISERVER --> ETCD
|
||
CMGR --> ETCD
|
||
end
|
||
|
||
subgraph WORKER["工作节点 Worker Node"]
|
||
N1["Node A<br/>kubelet + kube-proxy"]
|
||
N2["Node B<br/>kubelet + kube-proxy"]
|
||
end
|
||
|
||
APISERVER -.->|监听变动| N1
|
||
APISERVER -.->|监听变动| N2
|
||
|
||
style CONTROL fill:#e3f2fd
|
||
style ETCD fill:#c8e6c9
|
||
style WORKER fill:#fff3e0
|
||
```
|
||
|
||
> [!question] 为什么 K8s 需要这么多组件？
|
||
>
|
||
> 因为"声明式 API"的设计哲学——用户告诉 K8s **想要什么状态**（比如"我要 3 个订单服务实例"），控制面负责让实际状态持续逼近目标状态。任何偏离都会被自动修复，这也就是自愈能力的来源。
|
||
|
||
### 核心对象速查表
|
||
|
||
| K8s 对象 | 用途 | 类比 |
|
||
|---------|------|------|
|
||
| **Pod** | 最小部署单元，包含一个或多个容器 | 应用实例 |
|
||
| **Deployment** | 管理 Pod 的副本数和滚动更新 | 应用的"模板" |
|
||
| **Service** | 稳定的网络入口，负载均衡 | 内部 VIP → [[03-网络与服务发现]] |
|
||
| **ConfigMap** | 配置注入（明文） → [[02-配置管理]] |
|
||
| **Secret** | 敏感配置注入（base64）→ [[02-配置管理]] |
|
||
| **HPA** | 根据指标自动扩缩容 → [[04-扩缩容与有状态应用]] |
|
||
| **StatefulSet** | 有状态应用的有序管理 → [[04-扩缩容与有状态应用]] |
|
||
| **NetworkPolicy** | L3/L4 网络安全策略 → [[06-资源与安全管控]] |
|
||
|
||
## Deployment 详解
|
||
|
||
### 完整示例
|
||
|
||
```yaml
|
||
apiVersion: apps/v1
|
||
kind: Deployment
|
||
metadata:
|
||
name: order-service
|
||
labels:
|
||
app: order
|
||
version: v1.2.3
|
||
spec:
|
||
replicas: 3 # 期望副本数
|
||
strategy:
|
||
type: RollingUpdate
|
||
rollingUpdate:
|
||
maxSurge: 1 # 最多超额 1 个 Pod
|
||
maxUnavailable: 0 # 滚动更新期间不允许不可用
|
||
|
||
selector:
|
||
matchLabels:
|
||
app: order
|
||
|
||
template: # Pod 模板
|
||
metadata:
|
||
labels:
|
||
app: order
|
||
version: v1.2.3
|
||
spec:
|
||
containers:
|
||
- name: order-service
|
||
image: registry.example.com/order:v1.2.3
|
||
ports:
|
||
- containerPort: 8080
|
||
|
||
# ========== 资源配置 ==========
|
||
resources:
|
||
requests: # 调度依据：保证至少有这些
|
||
cpu: "250m"
|
||
memory: "256Mi"
|
||
limits: # 硬上限：超过则 OOMKill/CPU Throttle
|
||
cpu: "500m"
|
||
memory: "512Mi"
|
||
|
||
# ========== 探针 ==========
|
||
livenessProbe:
|
||
httpGet:
|
||
path: /healthz
|
||
port: 8080
|
||
initialDelaySeconds: 15
|
||
periodSeconds: 10
|
||
failureThreshold: 3 # 连续失败 3 次才重启
|
||
|
||
readinessProbe:
|
||
httpGet:
|
||
path: /ready
|
||
port: 8080
|
||
initialDelaySeconds: 5
|
||
periodSeconds: 5
|
||
failureThreshold: 3
|
||
|
||
startupProbe:
|
||
httpGet:
|
||
path: /healthz
|
||
port: 8080
|
||
failureThreshold: 30 # 最长等待 300s (慢启动友好)
|
||
|
||
# ========== 环境变量 & 挂载 ==========
|
||
envFrom:
|
||
- configMapRef:
|
||
name: order-service-config
|
||
- secretRef:
|
||
name: order-service-secrets
|
||
|
||
lifecycle:
|
||
preStop:
|
||
exec:
|
||
command: ["sh", "-c", "sleep 15"] # 优雅退出，给 LB 摘流时间
|
||
```
|
||
|
||
### Probe 选择指南
|
||
|
||
| 探针类型 | 触发条件 | 动作 | 适用场景 |
|
||
|---------|---------|------|---------|
|
||
| **Liveness** | `/healthz` 返回非 2xx | 重启容器 | 死锁、无法恢复的崩溃 |
|
||
| **Readiness** | `/ready` 返回非 2xx | 摘除 Service 流量 | 依赖未就绪、热加载中 |
|
||
| **Startup** | 首次成功前持续失败 | 不重启，只等待 | 大模型/JVM 冷启动 |
|
||
|
||
> [!warning] 常见陷阱：Liveness 误杀导致 CrashLoopBackOff
|
||
>
|
||
> 如果 Liveness Probe 因为 DB 连接超时而返回 503，K8s 会认为容器挂了并反复重启它。正确做法：让 `/healthz` 做降级判断（DB 不可用时返回 200），用 `/ready` 来摘除流量。
|
||
|
||
### Deployment 更新策略
|
||
|
||
```yaml
|
||
strategy:
|
||
type: RollingUpdate # 逐步替换旧 Pod
|
||
rollingUpdate:
|
||
maxSurge: 1 # 新 Pod 数量可以超出期望值 1
|
||
maxUnavailable: 0 # 更新时不允许有空缺
|
||
|
||
# 另一种策略：先全部新建再销毁旧的（零停机但需 2x 资源）
|
||
# type: Recreate # ❌ 全量替换，会有短暂不可用
|
||
```
|
||
|
||
> [!tip] 如何安全地回滚 Deployment？
|
||
>
|
||
> ```bash
|
||
> kubectl rollout undo deployment/order-service -n production # 回到上一版本
|
||
> kubectl rollout undo deployment/order-service -n production --to-revision=3 # 回退到指定版本
|
||
> kubectl rollout status deployment/order-service -n production # 查看进度
|
||
> kubectl rollout history deployment/order-service -n production # 历史版本对比
|
||
> ```
|
||
>
|
||
> K8s 自动保留每次 Deployment 变更后的 PodTemplateSpec，因此回滚是瞬时的，不需要手动备份 YAML。
|
||
|
||
### Pod 生命周期简述
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> Pending: Pod 被创建
|
||
Pending --> ContainerCreating: 调度成功，拉取镜像
|
||
ContainerCreating --> Running: 容器就绪
|
||
Running --> Waiting: Probe 失败或手动暂停
|
||
Waiting --> Running: 探针恢复
|
||
Running --> Terminating: 删除/更新触发
|
||
Terminating --> (*): 完全终止
|
||
|
||
state Waiting {
|
||
CrashLoopBackOff
|
||
ImagePullBackOff
|
||
}
|
||
|
||
note right of CrashLoopBackOff: Liveness 连续失败\n或进程异常退出
|
||
note right of ImagePullBackOff: 镜像不存在或仓库认证失败
|
||
```
|
||
|
||
## 关联笔记
|
||
|
||
- [[../02-配置管理]] — ConfigMap / Secret 的配置注入
|
||
- [[../03-网络与服务发现]] — Service / Ingress 网络路由
|
||
- [[../04-扩缩容与有状态应用]] — HPA / StatefulSet
|
||
- [[../hhs/MS/05-部署运维/01-容器化]] — Docker 镜像是 Pod 的基础单元
|
||
- [[../hhs/MS/05-部署运维/03-CICD与GitOps]] — GitOps ArgoCD 操作 K8s manifest
|