运维笔记：容器化与云原生

原创已于 2025-07-24 11:05:49 修改 · 601 阅读

12 ·

CC 4.0 BY-SA版权

文章标签：

#运维 #笔记 #云原生

于 2025-07-24 10:45:38 首次发布

虚拟化与云原生专栏收录该内容

3 篇文章

订阅专栏

一、容器化技术基础

1.1 容器化概念与优势

容器化是一种轻量级虚拟化技术，通过隔离应用及其依赖，实现 “一次构建，到处运行”。与传统虚拟机相比，容器具有以下优势：

轻量高效：容器共享主机操作系统内核，无需单独加载操作系统，启动时间毫秒级，资源占用低（通常仅需 MB 级内存）。

环境一致性：消除 “开发环境能运行，生产环境跑不起来” 的问题，容器镜像包含应用所需的所有依赖（库、配置、运行时）。

快速部署：基于镜像的部署方式，可在秒级完成应用实例创建，支持弹性扩缩容。

隔离性：通过 Linux Namespace（PID、Network、Mount 等）实现进程、网络、文件系统的隔离，通过 cgroups 限制 CPU、内存等资源。

可移植性：支持在物理机、虚拟机、公有云、私有云等多种环境中运行，兼容主流操作系统（Linux、Windows）。

1.2 Docker 核心架构

Docker 采用客户端 - 服务器（C/S）架构，核心组件包括：

Docker Client：用户与 Docker 交互的命令行工具（docker命令）或 API 客户端，负责向 Docker Daemon 发送请求。

Docker Daemon：运行在主机上的后台进程（dockerd），负责管理镜像、容器、网络和存储。

Docker Image：只读模板，包含运行应用的代码、运行时、库、环境变量和配置文件，采用分层存储（UnionFS），每层可复用。

Docker Container：镜像的可运行实例，在镜像层之上添加可写层（Copy-on-Write），容器销毁时可写层数据丢失（除非挂载外部存储）。

Docker Registry：存储和分发镜像的仓库，如公共仓库 Docker Hub、私有仓库 Harbor，支持镜像版本管理和访问控制。

Docker Objects：包括网络（Network）、卷（Volume）、插件（Plugin）等，用于扩展 Docker 功能。

二、Docker 高级特性

2.1 镜像分层与构建优化

分层原理：每个 Dockerfile 指令对应一个镜像层，如FROM、RUN、COPY等，上层依赖下层，修改某层仅重建该层及以上层，提高构建效率。

多阶段构建：通过FROM指令创建多个构建阶段，仅将生产环境所需文件复制到最终镜像，减小镜像体积。示例（Go 应用构建）：

# 构建阶段
FROM golang:1.20-alpine AS builder
WORKDIR /app
COPY . .
RUN go mod download && go build -o myapp .

# 运行阶段
FROM alpine:3.18
WORKDIR /app
COPY --from=builder /app/myapp .
EXPOSE 8080
CMD ["./myapp"]

构建缓存利用：将不常变更的指令（如安装依赖）放在 Dockerfile 前面，充分利用缓存。示例：

# 先复制依赖文件，利用缓存
COPY package.json package-lock.json ./
RUN npm ci

# 再复制代码，代码变更不影响依赖层缓存
COPY . .
RUN npm run build

2.2 容器网络高级配置

网络模式：

- bridge（默认）：容器连接到默认网桥，通过 NAT 访问外部网络。

- host：容器共享主机网络命名空间，性能好但隔离性差。

- none：禁用网络，适合无网络需求的容器。

- container:<name/id>：与指定容器共享网络命名空间。

- overlay：跨主机容器通信，用于 Swarm 或 Kubernetes 集群。

自定义网桥：创建隔离的网络环境，docker network create --driver bridge mynet，运行容器时指定网络：docker run -d --name app --network mynet nginx。

端口映射进阶：docker run -p 8080:80/tcp -p 8443:443/tcp nginx（指定协议）；docker run -p 127.0.0.1:8080:80 nginx（仅绑定本地回环地址）。

DNS 配置：docker run --dns 114.114.114.114 --dns-search example.com nginx（指定 DNS 服务器和搜索域）。

2.3 数据持久化方案

Volume：Docker 管理的持久化存储，独立于容器生命周期。

- 创建卷：docker volume create myvol。

- 使用卷：docker run -d -v myvol:/data nginx（将 myvol 挂载到容器 /data 目录）。

- 查看卷：docker volume ls；检查卷详情：docker volume inspect myvol。

Bind Mount：将主机目录直接挂载到容器，docker run -d -v /host/path:/container/path:ro nginx（ro表示只读）。

tmpfs Mount：临时文件系统，数据存储在内存中，docker run -d --tmpfs /tmp:size=100m nginx（限制大小 100MB）。

存储驱动：不同存储驱动（如 overlay2、devicemapper）影响容器性能和功能，overlay2 是目前推荐的驱动，支持分层存储和 Copy-on-Write。

2.4 Docker Compose 进阶

环境变量与配置文件：

- 使用.env文件定义环境变量，docker-compose自动加载：

DB_HOST=db
DB_PORT=5432

- 在docker-compose.yml中引用：

services:
  app:
    environment:
      - DATABASE_URL=postgres://${DB_USER}:${DB_PASS}@${DB_HOST}:${DB_PORT}/${DB_NAME}
    env_file:
      - ./app.env  # 加载额外环境变量文件

依赖顺序与健康检查：

services:
  db:
    image: postgres
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      timeout: 5s
      retries: 5
  app:
    image: myapp
    depends_on:
      db:
        condition: service_healthy  # 等待db健康检查通过才启动

扩展与覆盖：使用docker-compose -f docker-compose.yml -f docker-compose.prod.yml up（后者覆盖前者配置）；docker-compose up -d --scale app=3（启动 3 个 app 实例）。

2.5 Docker Swarm 容器编排

基本概念：Docker 原生的集群管理工具，包含 Manager 节点（管理集群）和 Worker 节点（运行容器）。

初始化集群：docker swarm init --advertise-addr 192.168.1.100（Manager 节点），Worker 节点加入集群：docker swarm join --token <token> 192.168.1.100:2377。

部署服务：docker service create --name web --replicas 3 -p 80:80 nginx。

服务更新：docker service update --image nginx:alpine web（滚动更新镜像）；docker service scale web=5（调整副本数）。

滚动更新配置：docker service create --name api --replicas 5 --update-delay 10s --update-parallelism 2 myapi（每次更新 2 个副本，间隔 10 秒）。

三、Kubernetes 核心技术

3.1 架构深度解析

控制平面组件：

- kube-apiserver：所有操作的统一入口，提供 RESTful API，支持认证、授权、准入控制。

- etcd：分布式键值存储，保存集群所有状态，需高可用部署。

- kube-scheduler：根据节点资源、亲和性、污点 / 容忍等策略，为 Pod 选择合适的节点。

- kube-controller-manager：运行多种控制器进程，如节点控制器（Node Controller）、副本控制器（ReplicaSet Controller）、端点控制器（Endpoint Controller）等。

- cloud-controller-manager：与云服务提供商集成，管理云资源（如负载均衡、节点）。

节点组件：

- kubelet：在每个节点运行，确保容器按照 Pod 规范（Spec）运行，与 apiserver 通信。

- kube-proxy：维护节点网络规则，实现 Service 的负载均衡（通过 iptables 或 IPVS）。

- 容器运行时（Container Runtime）：如 containerd、CRI-O，负责运行容器，需支持 CRI（Container Runtime Interface）。

3.2 核心资源对象详解

Pod：

- 最小部署单元，包含一个或多个容器，共享网络和存储。

- 示例：

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: nginx:1.23
    ports:
    - containerPort: 80
    resources:
      requests:  # 资源请求（调度依据）
        cpu: 100m
        memory: 128Mi
      limits:  # 资源限制
        cpu: 500m
        memory: 256Mi
    livenessProbe:  # 存活探针（检测容器是否运行）
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 10
      periodSeconds: 5
    readinessProbe:  # 就绪探针（检测容器是否可提供服务）
      httpGet:
        path: /
        port: 80
      initialDelaySeconds: 5
      periodSeconds: 3
  restartPolicy: Always  # 重启策略（Always/OnFailure/Never）

Service：

- 为 Pod 提供稳定的网络访问点，实现 Pod 的负载均衡和服务发现。

- 类型：

- - ClusterIP（默认）：仅集群内部访问。

- - NodePort：在每个节点开放静态端口，外部通过节点IP:NodePort访问。

- - LoadBalancer：通过云服务提供商的负载均衡器暴露服务。

- - ExternalName：将 Service 映射到外部域名（通过 CNAME）。

- 示例（NodePort 类型）：

apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx  # 匹配标签为app:nginx的Pod
  ports:
  - port: 80  # Service端口
    targetPort: 80  # Pod端口
    nodePort: 30080  # 节点端口（30000-32767）
  type: NodePort

Deployment：

- 声明式管理 Pod 和 ReplicaSet，支持滚动更新、回滚、扩缩容。

- 示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  replicas: 3  # 副本数
  selector:
    matchLabels:
      app: nginx
  strategy:
    type: RollingUpdate  # 滚动更新策略
    rollingUpdate:
      maxSurge: 1  # 最多可超出期望副本数的数量
      maxUnavailable: 0  # 更新过程中最多不可用的副本数
  template:  # Pod模板（与Pod定义一致）
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.23
        ports:
        - containerPort: 80

3.3 配置与存储管理

ConfigMap：存储非敏感配置数据，示例：

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  app.properties: |
    env=production
    log_level=info
  max_connections: "100"

挂载到 Pod：

spec:
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

Secret：存储敏感信息（密码、令牌），数据 Base64 编码：

apiVersion: v1
kind: Secret
metadata:
  name: db-credentials
type: Opaque
data:
  username: YWRtaW4=  # 解码后为admin
  password: cGFzc3dvcmQxMjM=  # 解码后为password123

作为环境变量使用：

spec:
  containers:
  - name: db-client
    image: mysql-client
    env:
    - name: DB_USER
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: username
    - name: DB_PASS
      valueFrom:
        secretKeyRef:
          name: db-credentials
          key: password

持久卷（PV）与持久卷声明（PVC）：

- PV：集群级别的存储资源，由管理员创建。

- PVC：用户对存储资源的请求，与 PV 动态绑定。

- 示例（PV 使用 HostPath，仅用于测试）：

# PV
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce  # 仅允许单节点读写
  hostPath:
    path: /data/mypv
---
# PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi  # 请求5Gi存储

- 在 Pod 中使用 PVC：

spec:
  containers:
  - name: app
    image: myapp
    volumeMounts:
    - name: data-volume
      mountPath: /data
  volumes:
  - name: data-volume
    persistentVolumeClaim:
      claimName: mypvc

3.4 部署策略与滚动更新

滚动更新（RollingUpdate）：逐步替换旧版本 Pod，确保服务不中断（Deployment 默认策略）。

- 操作：kubectl set image deployment/nginx-deploy nginx=nginx:1.24（更新镜像）。

- 查看更新状态：kubectl rollout status deployment/nginx-deploy。

蓝绿部署：部署新版本（绿环境），测试通过后切换流量（通过 Service selector 切换标签）。

- 示例：先部署nginx-v2，验证后将 Service selector 从version: v1改为version: v2。

金丝雀部署：将少量流量导入新版本，逐步扩大比例，如通过 Ingress 控制权重。

- 示例（使用 NGINX Ingress）：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-ingress
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 10%流量到金丝雀版本
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: nginx-canary
            port:
              number: 80

回滚操作：kubectl rollout undo deployment/nginx-deploy（回滚到上一版本）；kubectl rollout history deployment/nginx-deploy（查看历史版本）；kubectl rollout undo deployment/nginx-deploy --to-revision=2（回滚到指定版本）。

四、云原生架构与实践

4.1 云原生定义与原则

定义：云原生是一种构建和运行应用的方法，充分利用云计算的弹性和分布式特性，使应用更具韧性、可扩展性和可管理性。

核心原则：

- 微服务架构：将应用拆分为独立部署的小型服务，通过 API 通信。

- 容器化：应用及其依赖打包为容器，保证环境一致性。

- DevOps 文化：开发与运维紧密协作，自动化流程。

- 持续交付：通过 CI/CD 流水线实现频繁、可靠的部署。

- 基础设施即代码（IaC）：用代码定义和管理基础设施（如 Terraform、CloudFormation）。

- 可观测性：通过监控、日志、追踪了解系统状态。

- 容错设计：通过冗余、限流、熔断等机制应对故障。

4.2 微服务架构实践

服务拆分策略：按业务领域（DDD 领域驱动设计）、按职责（如订单服务、支付服务）拆分，避免过细或过粗。

服务通信：

- 同步：REST API（简单易用）、gRPC（高性能二进制协议，适合内部服务）。

- 异步：消息队列（Kafka、RabbitMQ），解耦服务，提高容错性。

服务发现：Kubernetes Service 或专门的服务发现工具（如 Consul），解决服务地址动态变化问题。

配置中心：集中管理微服务配置（如 Spring Cloud Config、Apollo），支持动态更新。

4.3 服务网格（Service Mesh）

概念：专门处理服务间通信的基础设施层，负责流量管理、安全、可观测性，透明接入应用（无需修改代码）。

Istio 架构：

- 数据平面：由 Envoy 代理组成，部署为 Sidecar 容器，拦截服务进出流量。

- 控制平面：istiod（合并 Pilot、Galley、Citadel 功能），负责配置分发、证书管理、服务发现。

核心功能：

- 流量管理：A/B 测试、金丝雀发布、超时重试、熔断（通过 VirtualService 和 DestinationRule 配置）。

- 安全：自动 mTLS 加密服务通信，基于 RBAC 的访问控制。

- 可观测性：收集 metrics（如请求延迟、错误率）、分布式追踪（Jaeger/Zipkin）、访问日志。

Istio 配置示例（VirtualService）：

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: myservice
spec:
  hosts:
  - myservice
  http:
  - route:
    - destination:
        host: myservice
        subset: v1
      weight: 90
    - destination:
        host: myservice
        subset: v2
      weight: 10  # 10%流量到v2版本

4.4 云原生监控与可观测性

监控指标（Metrics）：

- 工具链：Prometheus（采集存储）+ Grafana（可视化）。

- 核心指标：遵循 RED 方法（Rate 请求率、Errors 错误率、Duration 请求持续时间）和 USE 方法（Utilization 利用率、Saturation 饱和度、Errors 错误）。

- Kubernetes 监控：使用kube-state-metrics采集集群资源指标，node-exporter采集节点指标。

日志（Logs）：

- 工具链：ELK Stack（Elasticsearch+Logstash+Kibana）或 EFK Stack（Elasticsearch+Fluentd+Kibana）。

- 最佳实践：结构化日志（JSON 格式），包含时间戳、服务名、级别、请求 ID 等字段。

分布式追踪（Tracing）：

- 工具：Jaeger、Zipkin，跟踪请求在微服务间的传播路径，定位性能瓶颈。

- 实现：通过 instrumentation（代码埋点）生成追踪数据，如 OpenTelemetry 规范统一埋点接口。

可观测性平台：Grafana Loki（轻量级日志）、Thanos（Prometheus 长期存储）、Grafana Tempo（分布式追踪），构建统一可观测性平台。

4.5 云原生安全

容器安全：

- 镜像安全：扫描镜像漏洞（Trivy、Clair），使用精简基础镜像（如 Alpine），避免特权用户运行容器。

- 运行时安全：限制容器权限（securityContext），如runAsNonRoot: true、capabilities: drop: ["ALL"]。

集群安全：

- 网络策略（NetworkPolicy）：限制 Pod 间通信，默认拒绝所有流量，按需开放。

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

- RBAC 权限控制：通过 Role、ClusterRole 定义权限，RoleBinding、ClusterRoleBinding 绑定到用户或 ServiceAccount。

- Secrets 管理：使用外部密钥管理系统（如 Vault），避免明文存储敏感信息。

合规与审计：启用 Kubernetes 审计日志（Audit Log），记录 API 操作；定期安全扫描和渗透测试。

五、云原生工具链

5.1 容器镜像构建工具

Buildah：无守护进程的镜像构建工具，兼容 Dockerfile，支持多阶段构建，buildah bud -t myapp:latest .（类似docker build）。

Kaniko：在容器或 Kubernetes 中构建镜像，无需特权，适合 CI/CD 流水线，kaniko --context=git://github.com/myproject --destination=myregistry/myapp:latest。

img：快速、安全的镜像构建工具，结合 Buildah 和 Skopeo 功能，支持并行构建。

5.2 Kubernetes 部署与管理工具

Helm：Kubernetes 包管理器，通过 Chart 打包应用资源，简化部署和版本管理。

- 安装 Chart：helm install myapp stable/nginx。

- 自定义配置：helm install myapp stable/nginx -f values.yaml。

- 查看发布：helm list；升级：helm upgrade myapp stable/nginx；回滚：helm rollback myapp 1。

Kustomize：通过 YAML 配置覆盖实现环境差异化，无需模板，kustomize build overlays/prod | kubectl apply -f -。

kubectl 插件：kubectx/kubens（快速切换集群 / 命名空间）、kube-ps1（终端显示当前集群 / 命名空间）、k9s（终端 UI 管理工具）。

5.3 云原生存储方案

分布式存储：

- Rook：基于 Ceph 的 Kubernetes 存储编排，提供块存储（RBD）、文件存储（CephFS）、对象存储（S3 兼容）。

- Longhorn：轻量级分布式块存储，简单易用，支持备份、快照。

对象存储：MinIO（S3 兼容，可部署在 Kubernetes），用于存储非结构化数据（日志、图片）。

临时存储：EmptyDir（Pod 生命周期内的临时存储）、tmpfs（内存存储）。

5.4 serverless 与云原生应用平台

Knative：基于 Kubernetes 的 Serverless 平台，简化无服务器应用部署，自动扩缩容（包括缩容到 0）。

- 组件：Serving（处理 HTTP 请求）、Eventing（事件驱动）。

- 部署应用：

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: helloworld
spec:
  template:
    spec:
      containers:
      - image: gcr.io/knative-samples/helloworld-go
        env:
        - name: TARGET
          value: "Knative"

云厂商 Serverless 服务：AWS Lambda、Google Cloud Functions、阿里云函数计算，与 Kubernetes 结合实现混合云 Serverless。

云原生 PaaS：OpenShift（基于 Kubernetes 的企业级 PaaS）、Cloud Foundry，提供更上层的应用管理抽象。

六、Kubernetes 高级特性

6.1 高级调度策略

节点亲和性与反亲和性：

- 节点亲和性（NodeAffinity）：让 Pod 调度到满足特定条件的节点上，如节点标签为env=production。

spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:  # 硬亲和性，必须满足
        nodeSelectorTerms:
        - matchExpressions:
          - key: env
            operator: In
            values:
            - production
      preferredDuringSchedulingIgnoredDuringExecution:  # 软亲和性，尽量满足
      - weight: 100
        preference:
          matchExpressions:
          - key: instance-type
            operator: In
            values:
            - c5.large

- 节点反亲和性：避免 Pod 调度到特定节点，如避免调度到disk=hdd的节点。

Pod 亲和性与反亲和性：根据已运行 Pod 的标签决定调度，用于将相关 Pod 部署在同一节点（如应用与缓存）或分散部署（如分布式数据库副本）。

spec:
  affinity:
    podAffinity:  # 与指定Pod在同一节点
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values:
            - backend
        topologyKey: kubernetes.io/hostname
    podAntiAffinity:  # 与指定Pod不在同一节点
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 100
        podAffinityTerm:
          labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - database
          topologyKey: kubernetes.io/hostname

污点（Taint）与容忍（Toleration）：

- 污点：节点设置污点，拒绝不匹配容忍的 Pod 调度，kubectl taint nodes node1 key=value:NoSchedule（NoSchedule 表示新 Pod 不调度，NoExecute 表示已有 Pod 将被驱逐）。

- 容忍：Pod 设置容忍，允许调度到有对应污点的节点。

spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "value"
    effect: "NoSchedule"

6.2 自动扩缩容

Horizontal Pod Autoscaler（HPA）：根据 CPU、内存使用率或自定义指标自动调整 Pod 副本数。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-deploy
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # CPU使用率70%触发扩容
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80  # 内存使用率80%触发扩容

Vertical Pod Autoscaler（VPA）：自动调整 Pod 的 CPU 和内存请求与限制，适合无法水平扩展的应用（如数据库）。

Cluster Autoscaler：与云厂商集成，当节点资源不足且 HPA 无法扩容时，自动增加节点；当节点资源长期空闲时，自动缩减节点。

6.3 状态 fulSet 与有状态应用

StatefulSet 特性：用于部署有状态应用（如数据库、分布式系统），与 Deployment 的区别在于：

- 固定的 Pod 名称（<statefulset-name>-<ordinal-index>，如mysql-0、mysql-1）。

- 稳定的网络标识（通过 Headless Service 实现，DNS 名称为<pod-name>.<service-name>）。

- 有序部署和扩展（依次创建 0→1→2，缩容时反向）。

- 稳定的存储（每个 Pod 挂载独立的 PVC，删除后重建仍使用原 PVC）。

StatefulSet 示例（MySQL 集群）：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql  # Headless Service名称
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mysql-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:  # PVC模板，自动为每个Pod创建PVC
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

6.4 动态准入控制

准入控制器（Admission Controller）：在 Pod 创建或更新时对请求进行拦截和修改，实现安全策略、资源限制等，如NamespaceLifecycle（防止在不存在的 Namespace 创建资源）、ResourceQuota（确保不超过资源配额）。

ValidatingAdmissionWebhook 与 MutatingAdmissionWebhook：

- MutatingWebhook：修改请求（如自动添加标签、注入 Sidecar 容器）。

- ValidatingWebhook：验证请求是否符合规则（如禁止运行特权容器），不通过则拒绝。

示例场景：通过 Webhook 自动为所有 Pod 添加app.kubernetes.io/team: ops标签，禁止使用latest标签的镜像。

七、云原生应用部署与运维实践

7.1 应用部署最佳实践

环境隔离：使用 Namespace 隔离开发、测试、生产环境，kubectl create namespace production，部署时指定-n production。

资源限制：为所有 Pod 设置 CPU 和内存的 requests 和 limits，避免资源争抢和节点过载。

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

健康检查：除了 livenessProbe 和 readinessProbe，还可使用 startupProbe 检测应用启动是否完成（适合启动慢的应用）。

startupProbe:
  httpGet:
    path: /health
    port: 8080
  failureThreshold: 30
  periodSeconds: 10  # 最多等待30*10=300秒启动

配置管理：优先使用 ConfigMap 和 Secret 存储配置，避免硬编码；敏感配置（如数据库密码）必须使用 Secret，且考虑使用外部密钥管理系统（Vault）。

7.2 日志与监控实践

集中式日志收集：在 Kubernetes 中通过 DaemonSet 部署 Fluentd/Fluent Bit，收集所有容器日志，输出到 Elasticsearch。

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: fluentd
  namespace: kube-system
spec:
  selector:
    matchLabels:
      name: fluentd
  template:
    metadata:
      labels:
        name: fluentd
    spec:
      containers:
      - name: fluentd
        image: fluent/fluentd-kubernetes-daemonset:v1.14
        volumeMounts:
        - name: varlog
          mountPath: /var/log
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

监控指标暴露：应用程序通过/metrics端点暴露 Prometheus 兼容的指标（如使用 Prometheus 客户端库），部署 ServiceMonitor（Prometheus Operator）配置采集。

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: app-monitor
spec:
  selector:
    matchLabels:
      app: myapp
  endpoints:
  - port: http
    path: /metrics
    interval: 15s

7.3 灾备与恢复策略

ETCD 备份与恢复：ETCD 存储集群所有状态，定期备份etcdctl --endpoints=https://127.0.0.1:2379 --cacert=/etc/kubernetes/pki/etcd/ca.crt --cert=/etc/kubernetes/pki/apiserver-etcd-client.crt --key=/etc/kubernetes/pki/apiserver-etcd-client.key snapshot save backup.db，恢复时使用snapshot restore。

应用数据备份：结合 Velero（前身为 Heptio Ark）备份 PVC、Deployment 等资源到对象存储（如 S3），支持跨集群恢复。

- 安装 Velero：velero install --provider aws --bucket velero-backups --secret-file credentials-velero。

- 创建备份：velero backup create app-backup --include-namespaces production。

- 恢复：velero restore create --from-backup app-backup。

跨区域容灾：在多个区域部署 Kubernetes 集群，通过异步数据复制（如 MySQL 主从跨区域复制）保持数据同步，使用全球负载均衡（如 AWS Route 53）实现故障转移。

7.4 成本优化

资源_right-sizing：根据实际使用情况调整 Pod 的资源 requests 和 limits，避免过度分配（如将 CPU limit 从 2 核降至 1 核，内存从 4GB 降至 2GB）。

自动扩缩容：非高峰期自动缩减 Pod 数量（如夜间将 Web 服务副本从 10 减至 2），结合 Cluster Autoscaler 调整节点数量。

Spot 实例：在云环境中使用 Spot 实例（竞价实例）运行无状态应用，降低成本（比按需实例便宜 50%-90%），通过 Pod 反亲和性避免所有实例同时被回收。

存储优化：使用适合的存储类型（如非关键数据使用标准存储而非高性能存储），定期清理无用的 PVC 和快照。

八、云原生生态工具深度解析

8.1 服务网格进阶（Istio）

流量管理高级配置：

- 超时与重试：设置服务调用超时时间和重试次数，避免请求长时间阻塞。

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: product-service
spec:
  hosts:
  - product-service
  http:
  - route:
    - destination:
        host: product-service
        subset: v1
    timeout: 5s  # 超时时间
    retries:
      attempts: 3  # 重试3次
      perTryTimeout: 2s  # 每次重试超时

- 熔断：当服务错误率过高时，暂时停止调用，保护服务。

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: product-service
spec:
  host: product-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 100
        maxRequestsPerConnection: 10
    outlierDetection:  # 熔断配置
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s

安全策略：

- mTLS 强制：为特定 Namespace 或服务启用双向 TLS 加密。

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: production
spec:
  mtls:
    mode: STRICT  # 强制使用mTLS