Kubernetes 十大核心知识点

以下是 Kubernetes 十大核心知识点的详细解析，涵盖原理、应用场景与实现方式：

1. Pod 生命周期

原理

Pod 是 K8s 最小调度单元，其生命周期由 kubelet 管理，经历以下阶段：

Pending：已提交到 API Server，但镜像正在拉取或调度未完成
Running：至少一个容器已启动
Succeeded：所有容器正常退出（Job 类）
Failed：所有容器终止且至少一个异常退出
Unknown：kubelet 无法上报状态

容器内部还有 PostStart、PreStop 钩子，以及 livenessProbe（存活检测）、readinessProbe（就绪检测）。

应用

需要优雅终止（Graceful Shutdown）的微服务
有启动依赖顺序的应用（如先启动数据库再启动业务）

实现

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: app
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'started' >> /var/log/lifecycle.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "sleep 10; nginx -s quit"]  # 优雅退出
    livenessProbe:
      httpGet:
        path: /health
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:
      httpGet:
        path: /ready
        port: 80
      initialDelaySeconds: 5

2. Deployment 滚动更新与回滚

原理

Deployment 通过 ReplicaSet 管理 Pod 副本。更新时：

创建新 ReplicaSet，按 maxSurge（可超出的副本数）和 maxUnavailable（最大不可用数）逐步替换旧 Pod
旧 ReplicaSet 缩容，新 ReplicaSet 扩容
历史 ReplicaSet 保留（默认 10 个版本），用于回滚

应用

业务版本迭代，零停机发布
新版本异常时快速回滚到稳定版

实现

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1          # 更新时最多多出 1 个 Pod
      maxUnavailable: 1    # 更新时最多 1 个 Pod 不可用
  template:
    spec:
      containers:
      - name: web
        image: nginx:1.25

命令操作：

# 更新镜像
kubectl set image deployment/web-app web=nginx:1.26

# 查看滚动状态
kubectl rollout status deployment/web-app

# 查看历史版本
kubectl rollout history deployment/web-app

# 回滚到上一版本
kubectl rollout undo deployment/web-app

# 回滚到指定版本
kubectl rollout undo deployment/web-app --to-revision=2

3. Service 与 Ingress

原理

Service：通过 Label Selector 绑定一组 Pod，提供稳定的虚拟 IP（ClusterIP），实现负载均衡。类型有 ClusterIP、NodePort、LoadBalancer、ExternalName。
Ingress：基于 HTTP/HTTPS 规则的七层路由，依赖 Ingress Controller（如 Nginx、Traefik）实现。将外部域名/路径映射到内部 Service。

应用

Service：集群内微服务互相发现与调用
Ingress：统一外部入口，SSL 终止、路径重写、限流

实现

# Service
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api
  ports:
  - port: 80
    targetPort: 8080
  type: ClusterIP

# Ingress
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx
  rules:
  - host: shop.example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80

4. ConfigMap / Secret

原理

ConfigMap：存储非敏感配置（如数据库地址、日志级别），以键值对形式注入 Pod（环境变量或挂载卷）。
Secret：存储敏感数据（密码、Token、证书），数据以 Base64 编码存储（注意：非加密，需配合 RBAC 限制访问），支持 Opaque、tls、docker-registry 等类型。

应用

环境分离：开发/测试/生产使用不同 ConfigMap
安全合规：密码不直接写镜像或代码中

实现

# ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DB_HOST: "mysql"
  LOG_LEVEL: "info"

# Secret
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
stringData:  # 用 stringData 自动 base64 编码
  password: "MyP@ssw0rd"

# Pod 中使用
apiVersion: v1
kind: Pod
spec:
  containers:
  - name: app
    image: myapp
    envFrom:
    - configMapRef:
        name: app-config
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-secret
          key: password
    volumeMounts:
    - name: config-vol
      mountPath: /etc/config
  volumes:
  - name: config-vol
    configMap:
      name: app-config

5. PV / PVC 存储

原理

PV（PersistentVolume）：集群层面的存储资源，由管理员预先创建或动态供给（StorageClass）。
PVC（PersistentVolumeClaim）：用户层面的存储申请，声明需要的容量和访问模式。
StorageClass：定义动态供给的模板（如 AWS EBS、NFS、Ceph）。

绑定流程：PVC 提交 → 匹配满足条件的 PV（或动态创建）→ 绑定后 Pod 通过 PVC 挂载。

应用

数据库（MySQL、PostgreSQL）数据持久化
共享文件存储（NFS 多 Pod 读写）

实现

# StorageClass（动态供给示例）
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-ssd
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3

# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast-ssd
  resources:
    requests:
      storage: 20Gi

# Deployment 中使用
spec:
  template:
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: mysql-pvc

6. HPA 自动扩容

原理

Horizontal Pod Autoscaler 根据指标自动调整 Pod 副本数：

默认基于 CPU/内存利用率（通过 Metrics Server 采集）
支持自定义指标（如 QPS、消息队列长度，需 Prometheus Adapter）

算法：desiredReplicas = ceil[currentReplicas * (currentMetricValue / targetMetricValue)]

应用

电商大促期间流量激增，自动扩容应对峰值
夜间流量低谷自动缩容，节省资源

实现

# 安装 Metrics Server
kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

# HPA 配置
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # CPU 超 70% 扩容
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300  # 缩容冷却期 5 分钟

7. Harbor 私有仓库

原理

Harbor 是 CNCF 开源的企业级 Docker Registry，在原生 Registry 基础上增加了：

RBAC：基于角色的权限控制（项目级隔离）
镜像复制：跨 Harbor 实例同步
漏洞扫描：集成 Trivy/Clair 扫描镜像安全
镜像签名：Notary/Cosign 保障镜像可信

K8s 使用私有仓库时，需要创建 imagePullSecret 供 kubelet 拉取镜像时认证。

应用

企业内部镜像管理，避免公网暴露
生产环境仅允许扫描通过的镜像部署

实现

# 1. 在 Harbor 创建用户和项目

# 2. 生成 docker-registry Secret
kubectl create secret docker-registry harbor-secret \
  --docker-server=harbor.company.com \
  --docker-username=admin \
  --docker-password=Harbor12345 \
  --docker-email=admin@company.com

# 3. Pod 中引用
apiVersion: v1
kind: Pod
spec:
  imagePullSecrets:
  - name: harbor-secret
  containers:
  - name: app
    image: harbor.company.com/project/myapp:v1.0

配合 ServiceAccount 自动注入（免每个 Pod 写 imagePullSecrets）：

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "harbor-secret"}]}'

8. Prometheus + Grafana 监控

原理

Prometheus：时序数据库，通过 ServiceMonitor/PodMonitor 抓取 metrics 端点（Pull 模式），支持 PromQL 查询。
Grafana：可视化面板，对接 Prometheus 数据源展示图表。
kube-prometheus-stack：Helm Chart 一键部署 Prometheus Operator + Grafana + Alertmanager。

核心监控指标：

节点级：CPU、内存、磁盘、网络
Pod 级：容器资源使用、重启次数
应用级：自定义业务指标（请求量、延迟、错误率）

应用

实时观察集群健康状态
配置告警规则（如 Pod 内存超 90% 发钉钉/邮件）

实现

# 使用 Helm 安装
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm install kube-prometheus-stack prometheus-community/kube-prometheus-stack \
  --namespace monitoring --create-namespace

# ServiceMonitor 自动发现监控目标
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-monitor
  labels:
    release: kube-prometheus-stack
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: metrics
    path: /actuator/prometheus
    interval: 15s

Grafana 面板访问：

kubectl port-forward svc/kube-prometheus-stack-grafana 3000:80 -n monitoring
# 默认账号 admin / prom-operator

9. EFK / Loki 日志平台

原理

方案	组件	特点
EFK	Elasticsearch + Fluentd/Fluent-bit + Kibana	功能全、资源占用高、适合大规模
PLG	Promtail + Loki + Grafana	轻量、与 Prometheus 标签一致、成本低

Fluent-bit/Fluentd：DaemonSet 部署在每个 Node，采集容器标准输出（/var/log/containers/*.log）和文件日志
Loki：只索引标签，不索引日志内容，存储成本远低于 ES
Grafana：同时查指标和日志，实现"监控-日志"联动

应用

业务故障排查：根据 Pod 名快速检索日志
安全审计：追踪 API 访问记录

实现（Loki 方案）

helm repo add grafana https://grafana.github.io/helm-charts
helm install loki grafana/loki-stack \
  --namespace logging --set grafana.enabled=true

Fluent-bit 配置片段（DaemonSet 采集）：

[INPUT]
    Name tail
    Path /var/log/containers/*.log
    Parser docker
    Tag kube.*

[FILTER]
    Name kubernetes
    Match kube.*
    Kube_URL https://kubernetes.default.svc:443
    Merge_Log On

[OUTPUT]
    Name loki
    Match *
    Url http://loki:3100
    Labels job=fluentbit

Grafana 查询示例：

{namespace="default", pod_name=~"order-.*"} |= "error"

10. K8s 故障排查

常见状态与原理

状态	根因	排查命令
CrashLoopBackOff	容器启动后崩溃，kubelet 反复重启。原因：应用报错、启动命令错误、依赖服务不可达	`kubectl logs --previous` `kubectl describe pod`
ImagePullBackOff	镜像拉取失败。原因：镜像不存在、私有仓库无认证、网络不通	`kubectl describe pod` 看 Events
Pending	调度失败。原因：资源不足、节点污点、PVC 未绑定、亲和性不满足	`kubectl describe pod` `kubectl get nodes`
OOMKilled	内存溢出被系统 Kill。原因：内存 limit 设置过低、内存泄漏	`kubectl describe pod` 看 Last State
Evicted	节点资源耗尽（磁盘/内存），Pod 被驱逐	`kubectl get pod -o wide` 看 Node 状态

排查实战流程

# 1. 看 Pod 状态和事件
kubectl get pod <pod-name> -o wide
kubectl describe pod <pod-name>

# 2. 看日志
kubectl logs <pod-name> --tail=100 -f
kubectl logs <pod-name> --previous  # 崩溃前的日志

# 3. 进入容器排查
kubectl exec -it <pod-name> -- /bin/sh

# 4. 看节点资源
kubectl top node
kubectl describe node <node-name>

# 5. 看网络（Service/DNS）
kubectl get svc
kubectl run -it --rm debug --image=busybox:1.28 --restart=Never -- nslookup kubernetes.default

典型场景修复

OOMKilled 修复：

resources:
  limits:
    memory: "512Mi"   # 调大 limit
  requests:
    memory: "256Mi"

ImagePullBackOff 修复：

# 确认镜像存在
docker pull harbor.company.com/project/app:v1.0

# 检查 Secret
kubectl get secret harbor-secret
# 重新创建或 patch ServiceAccount

Pending 修复（资源不足）：

# 查看节点资源
kubectl describe node | grep -A 5 "Allocated resources"

# 清理无用 Pod 或扩容节点
kubectl top pod
kubectl delete pod <old-pod>

总结速查表

知识点	一句话核心
Pod 生命周期	调度→启动→探针检测→优雅终止
Deployment	通过 ReplicaSet 实现滚动更新与版本回滚
Service/Ingress	四层负载均衡 + 七层路由网关
ConfigMap/Secret	配置与敏感数据解耦，注入环境变量或挂载
PV/PVC	声明式存储抽象，支持动态供给
HPA	基于指标自动扩缩 Pod 副本
Harbor	企业级私有镜像仓库，含安全扫描
Prometheus+Grafana	指标采集 + 可视化监控
EFK/Loki	日志采集、存储与检索
故障排查	`describe` 看事件，`logs` 看输出，`exec` 进容器

配合一个 真实项目（如电商微服务）完整走一遍：从 Harbor 推送镜像 → 编写 Deployment/Service/Ingress → 配置 ConfigMap/Secret/PVC → 启用 HPA → 部署 Prometheus/Loki 监控日志，这样能将这 10 个知识点全部串联起来。

分享