Kubernetes 核心概念

Kubernetes 核心资源对象概览：Node、Pod、Service、Ingress、ConfigMap、Secret、Deployment、StatefulSet。

1. 核心资源全景图

┌────────────────────────────────────────────────────────────┐
│                        Kubernetes 集群                       │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐                    │
│  │  Node   │  │  Node   │  │  Node   │   ...              │
│  │ ┌─────┐ │  │ ┌─────┐ │  │ ┌─────┐ │                    │
│  │ │Pod  │ │  │ │Pod  │ │  │ │Pod  │ │                    │
│  │ │┌───┐│ │  │ │┌───┐│ │  │ │┌───┐│ │                    │
│  │ ││容器││ │  │ ││容器││ │  │ ││容器││ │                    │
│  │ │└───┘│ │  │ │└───┘│ │  │ │└───┘│ │                    │
│  │ └─────┘ │  │ └─────┘ │  │ └─────┘ │                    │
│  └─────────┘  └─────────┘  └─────────┘                    │
│       ▲                          ▲                         │
│       └────── Service ───────────┘                         │
│                    │                                        │
│               Ingress                                       │
│                    │                                        │
│              外部流量                                        │
└────────────────────────────────────────────────────────────┘

2. 资源关系速览

3. Node（节点）

一个 Node 就是一个物理机或虚拟机，是 Pod 运行的实际载体。

在简单语境中，“Node” 通常指代 Worker 节点。

4. Pod

Pod 是 K8s 的最小调度单元。

4.1 核心特征

💡 最佳实践：建议每个 Pod 只运行一个容器，以便更好地解耦和独立扩缩容。

4.2 Pod 生命周期

Pending → Running → Succeeded/Failed
              ↓
         Container 崩溃
              ↓
          重启（restartPolicy 控制）

4.3 Sidecar（边车模式）

当为实现某种功能而需要将辅助容器与主容器放在同一个 Pod 中时，这种辅助容器称为 Sidecar。

常见用途：

5. Service

将一组 Pod 封装成一个统一入口的网络服务抽象。

5.1 为什么需要 Service

• Pod IP 是临时的，Pod 重建后 IP 会变
• 多个 Pod 副本需要一个统一的访问入口
• 需要负载均衡能力

5.2 Service 类型

5.3 工作原理

Service 通过 Label Selector（标签选择器）选择一组 Pod 作为后端，流量通过 kube-proxy 转发。

Client → Service(ClusterIP) → kube-proxy(iptables/IPVS) → Pod

6. Ingress

管理从集群外部访问集群内部服务的入口和路由规则。

6.1 能力

6.2 Ingress 与 Service 的关系

外部请求 → Ingress（匹配规则）→ Service → Pod

🚨 注意：Ingress 只适用于 HTTP/HTTPS 流量。其他协议需用 NodePort 或 LoadBalancer 类型的 Service。

7. ConfigMap

将配置信息封装为 K8s 对象，实现配置与镜像解耦。

🚨 安全警告：ConfigMap 以明文存储，绝不放置敏感数据。

🚨 容量限制：单个 ConfigMap 不可超过 1 MiB。超出建议使用独立存储卷或文件服务。

8. Secret

与 ConfigMap 类似，但专门存储敏感数据。

🚨 重要：Base64 是编码而非加密，任何人都可以解码。生产环境需结合 K8s RBAC、静态加密（Encryption at Rest）和外部密钥管理（如 Vault）确保安全。

🚨 注意：以环境变量方式引用的 Secret，修改后不会自动刷新，需要重启 Pod。

9. Deployment

管理无状态应用的控制器，提供副本控制、滚动更新、回滚等能力。

9.1 核心能力

9.2 层级关系

Deployment → ReplicaSet → Pod

Deployment 是对 ReplicaSet 的更高级抽象，通常不直接操作 ReplicaSet。

10. StatefulSet

管理有状态应用的控制器（如数据库、消息队列等需要持久化标识的服务）。

10.1 与 Deployment 的区别

💡 最佳实践：不是所有有状态应用都适合 StatefulSet。对于某些复杂的有状态服务（如大型数据库集群），更推荐将其从 K8s 中抽离出来单独管理。

11. DaemonSet

确保每个节点上运行一个 Pod 副本。节点加入集群时自动创建，节点移除时自动回收。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
spec:
  selector:
    matchLabels:
      app: fluentd
  template:
    metadata:
      labels:
        app: fluentd
    spec:
      containers:
        - name: fluentd
          image: fluentd:latest

与 Deployment 的区别：Deployment 按副本数调度到任意节点，DaemonSet 保证每个节点都有一个。

12. Job

创建一个或多个 Pod 执行一次性任务，任务成功完成后停止。失败可配置重试。

apiVersion: batch/v1
kind: Job
metadata:
  name: db-migration
spec:
  backoffLimit: 4          # 失败重试次数
  completions: 1           # 成功完成的 Pod 数
  parallelism: 1           # 并行运行的 Pod 数
  template:
    spec:
      restartPolicy: Never # Job 必须用 Never 或 OnFailure
      containers:
        - name: migrate
          image: myapp:migrate
          command: ["./migrate.sh"]

常用命令：

kubectl create job my-job --image=busybox -- /bin/sh -c "echo done"
kubectl get job
kubectl logs job/my-job                    # 查看 Job 日志
kubectl delete job my-job

13. CronJob

按 Cron 表达式定时创建 Job。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: db-backup
spec:
  schedule: "0 2 * * *"     # 每天凌晨 2 点
  concurrencyPolicy: Forbid # 禁止并发执行
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: mysql:8.0
              command:
                - /bin/sh
                - -c
                - mysqldump -h db -u root -p$PASS mydb > /backup/db.sql

🚨 注意：CronJob 会创建 Job，Job 会创建 Pod。大量 CronJob 可能产生大量完成的 Job 和 Pod 残留，务必设置历史限制或 TTL 自动清理。

14. 探针（Probes）

Kubelet 使用探针检测容器的健康状态，是生产环境必不可少的配置。

14.1 三种探针

14.2 检测方式

14.3 配置示例

containers:
  - name: myapp
    image: myapp:latest
    ports:
      - containerPort: 8080
    # 启动探针：给应用充足的启动时间
    startupProbe:
      httpGet:
        path: /health
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10
      failureThreshold: 30    # 最多 30 次失败 ≈ 5 分钟启动窗口
    # 存活探针：检测应用是否卡死
    livenessProbe:
      httpGet:
        path: /health
        port: 8080
      periodSeconds: 15
      timeoutSeconds: 3
      failureThreshold: 3     # 连续 3 次失败 → 重启
    # 就绪探针：检测是否可以接流量
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      periodSeconds: 5
      timeoutSeconds: 2
      failureThreshold: 3

💡 最佳实践：

• 慢启动应用务必配置 Startup Probe，避免 Liveness Probe 过早杀死容器
• Liveness Probe 应检查应用是否死锁/卡死，不要检查外部依赖（DB/Redis）——否则外部故障会导致容器循环重启
• Readiness Probe 可检查外部依赖，因为影响的是是否接流量而非是否重启
• 生产环境每个容器都必须配置 Liveness + Readiness

15. 资源命名约定