云原生

Kubernetes核心概念体系深度解析：从Pod到Workload的完整链路

系统解析 Kubernetes 资源对象体系：Pod 设计哲学、Workload 控制器对比、Service 网络层、ConfigMap/Secret 管理、Namespace 资源治理与生产环境最佳实践。

Leeting Yan 12 分钟阅读 5691 字

Kubernetes 的核心设计哲学是声明式配置 + 控制器模式。用户通过 YAML 声明期望状态，控制器持续趋近该状态。理解资源对象体系，是掌握 K8s 的第一步。

目录

1. Pod：最小调度单元

Pod 是 Kubernetes 中最小且最简单的部署单元，不是一个容器，而是一个或多个容器的封装。Pod 内的容器共享：

  • Network 命名空间：相同 IP、端口空间
  • IPC 命名空间：可通过 System V IPC 或 POSIX 消息队列通信
  • UTS 命名空间：共享主机名
  • 存储卷（Volume）：可挂载同一存储
apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
    - name: app
      image: nginx:alpine
      ports:
        - containerPort: 80
    - name: sidecar
      image: fluent/fluent-bit:latest
      volumeMounts:
        - name: logs
          mountPath: /var/log/nginx
  volumes:
    - name: logs
      emptyDir: {}

1.1 Pause 容器与共享命名空间

Pod 中隐藏着一个看不见的 Pause 容器（也称 infra 容器），由 containerd 自动创建，运行 pause 镜像：

┌──────────────────────────────────────────────┐
│                  Pod Network NS              │
│  ┌────────────────┐  ┌──────────────────┐    │
│  │   App Container│  │  Sidecar Container│   │
│  │  (nginx)       │  │  (fluent-bit)    │    │
│  │  eth0: 10.1.2.3│  │  eth0: 10.1.2.3 │    │
│  └────────────────┘  └──────────────────┘    │
│           ↑ Pause Container (holder)          │
│              PID: pause (PID 1)               │
└──────────────────────────────────────────────┘

Pause 容器的作用：

  • 作为所有容器的父进程（PID 1），负责回收僵尸进程
  • 持有 Pod 的网络命名空间，即使应用容器全部崩溃，网络栈仍然保留
  • 实现容器热重启而不丢失网络连接

查看 Pause 容器：

# crictl 查看
sudo crictl ps -a | grep pause
# 或 containerd
sudo ctr -n k8s.io containers list | grep pause

1.2 多容器设计模式

K8s 推崇一个 Pod 一个关注焦点，但在以下场景多容器是合理的设计：

模式作用示例
Sidecar增强主容器功能日志收集（Fluent Bit）、监控代理（Prometheus exporter）
Init启动前准备初始化数据库 Schema、等待依赖就绪
Adapter适配输出格式将应用日志转为统一格式
Ambassador代理外部连接应用直连 localhost，Ambassador 负责分片路由

反模式：将紧密耦合的业务逻辑拆到不同 Pod 中，这违反了服务边界设计原则。

1.3 Init 容器

Init 容器在应用容器启动前顺序执行，全部成功完成后才启动应用容器：

apiVersion: v1
kind: Pod
metadata:
  name: init-demo
spec:
  initContainers:
    - name: init-migrate
      image: myapp:v1
      command: ["python", "manage.py", "migrate"]
    - name: init-check-db
      image: busybox:latest
      command: ['sh', '-c', 'until nc -z postgres 5432; do sleep 2; done']
  containers:
    - name: app
      image: myapp:v1
      ports:
        - containerPort: 8080

Init 容器特点：

  • 按定义顺序串行执行，而不是并行
  • 失败会触发 Pod 重试（遵循 restartPolicy）
  • 资源限制（requests/limits）计入 Pod 总资源，因为它们和应用容器可能同时运行（多个 Init 容器串行，但当前运行的 Init + 已完成的 Init 资源仍会叠加到调度计算）
  • 支持 restartPolicy: OnFailure，适合一次性初始化任务

2. Workload 控制器

控制器是 K8s 的核心抽象，负责维护实际状态趋近期望状态。

2.1 Deployment：无状态应用

Deployment 管理无状态应用，核心能力是声明式滚动更新 + 回滚：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-server
  labels:
    app: api-server
    version: v2.1.0
spec:
  replicas: 3
  # Pod 选择器，必须与 template.metadata.labels 匹配
  selector:
    matchLabels:
      app: api-server
  # 滚动更新策略
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 25%        # 更新时最大超出副本数
      maxUnavailable: 25%  # 更新时最大不可用副本数
  template:
    metadata:
      labels:
        app: api-server
        version: v2.1.0
    spec:
      containers:
        - name: api
          image: registry.example.com/api:v2.1.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 256Mi
            limits:
              cpu: 1000m
              memory: 512Mi
          # 探针配置
          startupProbe:
            httpGet:
              path: /healthz
              port: 8080
            failureThreshold: 30
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            periodSeconds: 10
            failureThreshold: 3
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 5
            failureThreshold: 2

Deployment 关键机制：

机制说明
ReplicaSetDeployment 底层实际管理 Pod 的对象，每次更新创建新 ReplicaSet，保留历史用于回滚
revisionHistoryLimit保留历史 ReplicaSet 数量（默认 10），设为 0 无法回滚
minReadySeconds新 Pod 就绪后等待多久才算成功，用于探测缓慢启动的服务
pausedkubectl rollout pause deployment/api-server 暂停滚动更新，排查问题后继续

滚动更新与回滚：

# 触发更新（修改镜像或配置）
kubectl set image deployment/api-server api=api:v2.2.0

# 查看更新进度
kubectl rollout status deployment/api-server

# 查看历史版本
kubectl rollout history deployment/api-server

# 回滚到上一个版本
kubectl rollout undo deployment/api-server

# 回滚到指定版本
kubectl rollout undo deployment/api-server --to-revision=3

Deployment 使用场景：Web 服务、API 网关、前端服务、缓存层（Redis Sentinel 模式）。

2.2 StatefulSet：有状态应用

StatefulSet 为需要稳定网络标识 + 稳定持久存储的应用设计：

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres-headless
  replicas: 3
  selector:
    matchLabels:
      app: postgres
  podManagementPolicy: OrderedReady  # 或 Parallel
  updateStrategy:
    type: RollingUpdate
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
        - name: postgres
          image: postgres:16-alpine
          env:
            - name: POSTGRES_USER
              value: appuser
            - name: POSTGRES_DB
              value: appdb
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  # 每个 Pod 独立的 PVC 模板
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 100Gi

StatefulSet 与 Deployment 核心差异：

特性DeploymentStatefulSet
Pod 名称随机后缀（如 api-server-7d9b4c2f8）有序序号（如 postgres-0, postgres-1）
网络标识无固定 DNS通过 Headless Service 获得稳定 DNS（postgres-0.postgres-headless）
存储共享或独立 PVC每个 Pod 独立 PVC，由 volumeClaimTemplates 创建
启动/删除顺序并行OrderedReady: 按 0→N-1 启动，N-1→0 删除
更新策略RollingUpdate/RecreateRollingUpdate/OnDelete

适用场景：数据库（PostgreSQL、MySQL）、消息队列（Kafka、RabbitMQ）、分布式共识（ZooKeeper、etcd）、有状态缓存（Redis Cluster）。

2.3 DaemonSet：守护进程

DaemonSet 确保每个（或部分）节点上运行一个 Pod 副本：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: node-exporter
spec:
  selector:
    matchLabels:
      app: node-exporter
  template:
    metadata:
      labels:
        app: node-exporter
    spec:
      # 仅部署到带特定标签的节点
      nodeSelector:
        monitoring: enabled
      hostNetwork: true
      hostPID: true
      containers:
        - name: node-exporter
          image: prom/node-exporter:latest
          ports:
            - containerPort: 9100
              hostPort: 9100

DaemonSet 典型使用场景：

  • 节点级监控：Prometheus Node Exporter、Datadog Agent
  • 日志收集：Fluent Bit、Filebeat（作为 DaemonSet 收集节点日志）
  • 网络代理：CNI 插件（Calico、Cilium 的 DaemonSet 部署）
  • 安全审计：Falco、Auditbeat

控制调度节点：通过 nodeSelector、affinity 或 tolerations 限定。也可用 updateStrategy: RollingUpdate 控制更新行为。

2.4 Job / CronJob：批处理任务

Job 管理一次性任务到完成：

apiVersion: batch/v1
kind: Job
metadata:
  name: data-migration
spec:
  # 并行度控制
  completions: 1      # 需要成功完成的 Pod 数
  parallelism: 1      # 同时运行的 Pod 数
  backoffLimit: 4     # 失败重试次数
  activeDeadlineSeconds: 600  # 最大运行时间
  ttlSecondsAfterFinished: 86400  # 完成后自动清理（需开启 TTL 控制器）
  template:
    spec:
      restartPolicy: OnFailure  # Job 必须设为 OnFailure 或 Never
      containers:
        - name: migrate
          image: data-migrator:latest
          command: ["python", "migrate.py"]

CronJob 在 Job 基础上增加定时调度：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backup-cron
spec:
  schedule: "0 2 * * *"   # Cron 表达式：每天凌晨 2 点
  concurrencyPolicy: Forbid      # Forbid / Allow / Replace
  startingDeadlineSeconds: 3600  # 错过调度的宽限时间
  successfulJobsHistoryLimit: 3  # 保留成功记录数
  failedJobsHistoryLimit: 1      # 保留失败记录数
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
            - name: backup
              image: backup-tool:latest
              command: ["/backup.sh"]

concurrencyPolicy 策略对比：

策略行为适用场景
Allow允许多个 Job 并行运行幂等任务
Forbid若前次未完成，跳过本次不能并行的关键任务
Replace取消前次运行，启动新的只需最新数据的任务

2.5 ReplicaSet 与 ReplicationController

ReplicaSet 是 Deployment 的底层实现，不建议直接使用。

ReplicationController 是 ReplicaSet 的前身（K8s 1.1 之前），除历史遗留系统外应避免使用。二者核心差异：ReplicaSet 支持基于 matchExpressions 的选择器，功能更强。

2.6 控制器选型决策树

应用是否需要持久化状态？
├── 否（无状态） → Deployment ✅
│   └── 是否需要每个节点一个实例？
│       ├── 是 → DaemonSet ✅
│       └── 否 → Deployment
├── 是（有状态） → StatefulSet ✅
│   └── 是否需要定时执行？
│       └── 是 → CronJob ✅
└── 一次性任务 → Job ✅

3. Service：稳定的网络端点

Pod 是临时且不可预测的（IP 随时变），Service 提供稳定的虚拟 IP 和 DNS 名作为访问入口。

3.1 Service 四种类型

# ClusterIP（默认）：仅集群内部访问
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  type: ClusterIP
  selector:
    app: api-server
  ports:
    - port: 80          # Service 端口
      targetPort: 8080  # Pod 端口
      protocol: TCP

---

# NodePort：在每个节点上暴露固定端口
apiVersion: v1
kind: Service
metadata:
  name: api-nodeport
spec:
  type: NodePort
  selector:
    app: api-server
  ports:
    - port: 80
      targetPort: 8080
      nodePort: 30080   # 30000-32767 范围

---

# LoadBalancer：云厂商负载均衡器
apiVersion: v1
kind: Service
metadata:
  name: api-lb
  annotations:
    # 阿里云示例
    service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "internet"
spec:
  type: LoadBalancer
  selector:
    app: api-server
  ports:
    - port: 443
      targetPort: 8080

---

# ExternalName：DNS CNAME 映射（无 selector，无 Endpoint）
apiVersion: v1
kind: Service
metadata:
  name: external-db
spec:
  type: ExternalName
  externalName: prod-db.example.com

类型对比矩阵：

类型访问来源外部暴露适用场景
ClusterIP集群内部❌服务间调用
NodePort集群外部（节点 IP + 端口）✅ 但端口不友好开发测试、无 LB 环境
LoadBalancer外部通过云厂商 LB IP✅生产环境直接暴露（但推荐用 Ingress）
ExternalNameDNS 解析间接外部依赖解耦

生产推荐：对外暴露一律用 Ingress + ClusterIP Service，而非 NodePort 或 LoadBalancer 直接暴露服务。

3.2 Headless Service

设置 clusterIP: None，不分配虚拟 IP，直接返回后端 Pod IP 列表：

apiVersion: v1
kind: Service
metadata:
  name: postgres-headless
spec:
  clusterIP: None       # Headless 关键设置
  selector:
    app: postgres
  ports:
    - port: 5432

Headless Service 用途：

  • StatefulSet 必备：postgres-0.postgres-headless.svc.cluster.local 解析到具体 Pod IP
  • 客户端直连：客户端需要自己负载均衡（如 Kafka Consumer 直连 Broker）
  • DNS 服务发现：nslookup postgres-headless 返回所有 Pod A 记录

3.3 EndpointSlice

K8s 1.21+ 默认使用 EndpointSlice 替代旧的 Endpoints，优势：

  • 单个资源上限 1000 个端点（Endpoints 无上限导致性能问题）
  • 支持拓扑感知路由（将流量路由到同可用区端点）
kubectl get endpointslices -l kubernetes.io/service-name=api-service

3.4 kube-proxy 三种代理模式

kube-proxy 是 Service 的实现机制，存在三种模式：

模式原理性能适用场景
iptables为每个 Service 端口插入 iptables 规则，DNAT 到后端 Pod规则量大时 O(n)，< 1000 Service 可用中小型集群默认
ipvs使用 IPVS 内核模块尽心 LB，O(1) 复杂度高性能，支持多种 LB 算法大型集群（1000+ Service）
nftablesK8s 1.29+ 新特性，使用 nftables 替代 iptables规则更清晰，性能介于两者之间新集群推荐

查看当前模式：

kubectl get configmap kube-proxy -n kube-system -o yaml | grep mode
# 输出：mode: "ipvs" 或 "iptables"

3.5 ExternalTrafficPolicy 优化

当 Service 类型为 NodePort 或 LoadBalancer 时：ExternalTrafficPolicy: Local 保留客户端真实 IP（不经过额外跳），但可能产生流量不平衡。Cluster（默认）会均匀分布，但 SNAT 后丢失源 IP。

spec:
  externalTrafficPolicy: Local

保留源 IP 的替代方案：使用 X-Forwarded-For（HTTP 场景）或在 Ingress Controller 层处理。

4. ConfigMap 与 Secret

4.1 ConfigMap：非敏感配置

创建方式：

# 从字面量创建
kubectl create configmap app-config \
  --from-literal=LOG_LEVEL=info \
  --from-literal=MAX_CONNECTIONS=100

# 从配置文件创建
kubectl create configmap nginx-conf --from-file=nginx.conf

# 从目录创建
kubectl create configmap app-configs --from-file=config/

使用方式：

apiVersion: v1
kind: Pod
metadata:
  name: config-demo
spec:
  containers:
    - name: app
      image: myapp:latest
      # 方式1：环境变量（支持单值和全部导入）
      env:
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: LOG_LEVEL
      envFrom:
        - configMapRef:
            name: app-config   # 导入全部键为 env var
      # 方式2：卷挂载（整个 ConfigMap 作为文件，或 subPath 单个文件）
      volumeMounts:
        - name: config-vol
          mountPath: /etc/app/config.yaml
          subPath: config.yaml
  volumes:
    - name: config-vol
      configMap:
        name: app-config

ConfigMap 大小限制：单个 ConfigMap 最大 1MB（etcd 的 value 限制）。超过需要拆分到多个 ConfigMap 或使用外部配置中心（Consul、Etcd、Nacos）。

热更新行为：

  • 环境变量方式：不会自动更新（需要重启 Pod）
  • 卷挂载方式：会自动更新（Kubelet 定期同步，默认 ~1 分钟）
  • 但应用需要支持配置重载，否则热更新无意义

4.2 Secret：敏感数据

Secret 用来存储密码、Token、TLS 证书等敏感信息，数据以 Base64 编码存储（不是加密！）：

# 创建 TLS Secret
kubectl create secret tls api-cert \
  --cert=api.crt --key=api.key

# 创建通用 Secret
kubectl create secret generic db-password \
  --from-literal=password='S3cr3t!P@ss'

# 从文件创建
kubectl create secret generic app-secrets --from-env-file=secrets.env

Secret 类型一览：

类型用途
Opaque通用（默认），任意键值对
kubernetes.io/tlsTLS 证书和私钥
kubernetes.io/basic-auth用户名密码（HTTP Basic Auth）
kubernetes.io/dockerconfigjsonDocker registry 认证
kubernetes.io/service-account-tokenServiceAccount 自动生成的 Token

4.3 Secret 的局限性

Secret 数据仅经过 Base64 编码，etcd 中明文存储。 攻击者获取 etcd 备份即可读取所有 Secret。生产环境必须启用静态加密：

# kube-apiserver 配置加密
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-32-byte-key>
      - identity: {}  # 回退（不加密）

配置后：新 Secret 会加密存储，旧 Secret 在下次更新时重新加密。

4.4 外部密钥管理方案

方案原理安全性复杂度
HashiCorp Vault独立密钥管理服务，K8s 通过 Auth 方法认证⭐⭐⭐⭐⭐高
Sealed Secrets用集群公钥加密 Secret，可安全存入 Git⭐⭐⭐⭐中
External Secrets Operator同步外部密钥管理器（Vault/ AWS SM / Azure KV）到 K8s Secret⭐⭐⭐⭐⭐中
SOPS + Flux用 GPG/Age 加密 YAML 文件，GitOps 部署时解密⭐⭐⭐⭐中

推荐策略：开发环境用 Sealed Secrets 或 SOPS，生产用 External Secrets Operator + Vault/AWS Secrets Manager。

5. Namespace 与资源治理

5.1 ResourceQuota

限制 Namespace 级别的资源总消耗：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
  namespace: production
spec:
  hard:
    # 计算资源
    requests.cpu: "20"
    requests.memory: 64Gi
    limits.cpu: "40"
    limits.memory: 128Gi
    # 对象数量
    pods: "50"
    services: "20"
    persistentvolumeclaims: "20"
    # GPU（如使用）
    requests.nvidia.com/gpu: "4"

5.2 LimitRange

设置 Namespace 级别的默认值和上下限：

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
  namespace: production
spec:
  limits:
    - default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 100m
        memory: 128Mi
      max:
        cpu: "4"
        memory: 8Gi
      min:
        cpu: 50m
        memory: 64Mi
      type: Container

效果：未设置 resources 的 Pod 自动应用 default/defaultRequest，不可超过 max/min 限制。

5.3 PodDisruptionBudget

确保滚动更新、节点驱逐时保持最小可用副本数：

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
spec:
  minAvailable: 2          # 或 maxUnavailable: 1
  selector:
    matchLabels:
      app: api-server

与 HPA 配合使用：Pod 数量动态变化时，maxUnavailable: 25% 比固定 minAvailable 更灵活。

6. 生产环境最佳实践

安全上下文

spec:
  securityContext:
    runAsNonRoot: true          # 禁止以 root 运行
    runAsUser: 1000             # 指定 UID
    runAsGroup: 1000            # 指定 GID
    fsGroup: 2000               # 卷挂载的组所有权
    seccompProfile:
      type: RuntimeDefault      # 使用默认 seccomp 配置
  containers:
    - name: app
      securityContext:
        allowPrivilegeEscalation: false    # 禁止特权提升
        readOnlyRootFilesystem: true        # 根文件系统只读
        capabilities:
          drop: ["ALL"]                     # 丢弃所有 capabilities
          add: ["NET_BIND_SERVICE"]         # 仅添加必需的

探针设计原则

探针检查内容失败后果设计原则
startupProbe应用是否已启动重启容器启动慢的应用（Java）必须配置，防止 liveness 过早触发
livenessProbe进程是否存活重启容器只检查进程本身，不检查外部依赖
readinessProbe是否准备好接收流量从 Service 摘除检查关键依赖（数据库、缓存）

错误设计：livenessProbe 检查数据库连接 → 数据库故障 → 所有 Pod 同时重启 → 雪崩。

标签与注解规范

metadata:
  labels:
    app.kubernetes.io/name: api-server       # 应用名称
    app.kubernetes.io/instance: prod         # 实例标识
    app.kubernetes.io/version: "2.1.0"       # 版本
    app.kubernetes.io/component: backend     # 组件类型
    app.kubernetes.io/part-of: ecommerce     # 所属系统
    app.kubernetes.io/managed-by: helm       # 管理工具
    tier: api                                # 分层（自定义补充）
    env: production
  annotations:
    # 不可用于选择器的元数据
    prometheus.io/scrape: "true"
    prometheus.io/port: "8080"
    prometheus.io/path: "/metrics"
    description: "订单服务 API"

Pod 生产环境 Checklist

spec:
  # 1. 安全
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  # 2. 资源限制
  containers:
    - resources:
        requests: { cpu: 100m, memory: 128Mi }
        limits: { cpu: 1000m, memory: 512Mi }
      # 3. 探针
      startupProbe:
        httpGet: { path: /healthz, port: 8080 }
        failureThreshold: 30
        periodSeconds: 5
      livenessProbe:
        httpGet: { path: /healthz, port: 8080 }
        periodSeconds: 10
        failureThreshold: 3
      readinessProbe:
        httpGet: { path: /ready, port: 8080 }
        periodSeconds: 5
        failureThreshold: 2
      # 4. 优雅终止
      lifecycle:
        preStop:
          exec:
            command: ["/bin/sh", "-c", "sleep 15"]
  # 5. 调度策略
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels: { app: api-server }
            topologyKey: kubernetes.io/hostname
  # 6. 服务账号
  serviceAccountName: api-server
  automountServiceAccountToken: false   # 不需要 K8s API 访问时禁用
  # 7. DNS 策略
  dnsPolicy: ClusterFirst

7. 总结

对象核心作用生产关键记忆点
Pod最小调度单元合理设计多容器模式（Sidecar/Init），始终设置 resources + probes
Deployment无状态应用管理maxSurge/maxUnavailable 调优，revisionHistoryLimit 保留回滚能力
StatefulSet有状态应用管理volumeClaimTemplates 提供独立存储，PodManagementPolicy 控制启动顺序
DaemonSet节点级守护nodeSelector 限制部署范围，注意 hostNetwork/hostPID 安全风险
Job/CronJob批处理concurrencyPolicy 防重复，ttlSecondsAfterFinished 自动清理
Service稳定网络入口ClusterIP + Ingress 是对外暴露的最佳实践
ConfigMap非敏感配置卷挂载支持热更新，大小限制 1MB
Secret敏感数据必须启用静态加密（EncryptionConfiguration），推荐 External Secrets Operator
ResourceQuota资源配额限制按 Namespace 分配，防止单团队耗尽集群资源
PodDisruptionBudget可用性保证与 HPA 配合时用百分比更灵活

核心理念：K8s 的每个对象都有明确的职责边界，掌握它们之间的协作关系，才能设计出高可用、可扩展、安全的云原生应用架构。

延伸阅读

继续阅读

探索更多技术文章

浏览归档，发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「云原生」更多文章

  1. Kubernetes多集群联邦：Karmada、Crossplane与Istio多集群实战
  2. CNCF云原生技术全景图：从毕业项目到前沿方向
  3. 容器运行时深度解析：从runc到containerd到安全容器