说明：Kubernetes 1.32 预计于2025年下半年正式发布。本文基于1.32版本的公开特性规划和Alpha/Beta功能撰写，部分功能在正式版中可能有调整。发布时间（2025年2月）该版本尚未正式发布，文中内容仅供提前学习参考。

K8s 1.32+配置详解：从基础到高级

Kubernetes 1.32版本带来了不少新特性和改进，对于运维和开发人员来说，了解这些变化并掌握正确的配置方法非常重要。

这篇文章，我会从基础到高级，详细讲解K8s 1.32+的核心配置。不管你是刚入门的新手，还是有经验的运维，都能从中找到有用的内容。

K8s 1.32的主要变化

先说说1.32版本有哪些主要变化。

第一个变化是，更多功能进入稳定版。每个K8s版本都会有一些功能从Alpha升级到Beta，从Beta升级到稳定版（GA）。1.32版本中，有几个值得关注的功能进入了稳定版，包括一些存储相关的增强、网络策略的改进、以及调度器的优化。

第二个变化是，废弃了一些旧的API和功能。K8s在不断演进，一些旧的API会被标记为废弃，在未来的版本中移除。1.32版本废弃了一些旧版本的API，比如某些早期的beta版本资源。升级之前，一定要检查自己的配置是否使用了废弃的API。

第三个变化是，安全性增强。每个版本都会有安全性的改进，1.32也不例外。包括默认启用的安全策略、更严格的权限控制、以及对容器运行时安全的增强。

第四个变化是，性能优化。1.32版本在调度性能、网络性能、存储性能等方面都有优化，尤其是在大规模集群中，性能提升比较明显。

了解了这些变化，我们来看看具体的配置。

基础配置一：Pod和容器

Pod是K8s中最基本的调度单元，所有的应用都运行在Pod中。

一个最基本的Pod配置如下：

apiVersion: v1
kind: Pod
metadata:
  name: my-app
  labels:
    app: my-app
spec:
  containers:
  - name: my-app
    image: nginx:1.25
    ports:
    - containerPort: 80
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 500m
        memory: 512Mi

在K8s 1.32中，Pod配置有几个需要注意的地方。

第一，资源配置是必须的。虽然K8s不强制要求配置resources，但在生产环境中，一定要给每个容器配置requests和limits。requests是调度时的参考，limits是运行时的上限。不配置limits的容器，可能会占用节点上的所有资源，影响其他容器。

第二，镜像标签要具体。不要用latest标签，要用具体的版本号，比如nginx:1.25，而不是nginx:latest。用latest标签，每次部署可能拉到不同的镜像，导致不可预测的行为。

第三，健康检查要配置。包括livenessProbe（存活探针）和readinessProbe（就绪探针）。livenessProbe用来检测容器是否还活着，如果失败，K8s会重启容器。readinessProbe用来检测容器是否准备好接收流量，如果失败，K8s会把容器从Service的后端列表中移除。

livenessProbe:
  httpGet:
    path: /health
    port: 80
  initialDelaySeconds: 10
  periodSeconds: 5
readinessProbe:
  httpGet:
    path: /ready
    port: 80
  initialDelaySeconds: 5
  periodSeconds: 3

第四，安全上下文要配置。在1.32中，推荐配置securityContext，以非root用户运行容器，限制容器的权限。

securityContext:
  runAsNonRoot: true
  runAsUser: 1000
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true

基础配置二：Deployment和ReplicaSet

在生产环境中，我们很少直接创建Pod，而是通过Deployment来管理。

Deployment管理ReplicaSet，ReplicaSet管理Pod。Deployment提供了滚动更新、回滚、扩缩容等功能。

一个基本的Deployment配置：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:1.0.0
        ports:
        - containerPort: 80

在1.32中，Deployment配置有几个要点。

第一，滚动更新策略要合理配置。maxSurge表示滚动更新时最多可以多出多少个Pod，maxUnavailable表示最多可以有多少个Pod不可用。如果想要零停机更新，设置maxUnavailable: 0，maxSurge: 1。这样更新时，先启动一个新Pod，等新Pod就绪后，再杀掉一个旧Pod，逐步替换。

第二，replicas数量要根据实际需求设置。不要盲目设置很多副本，浪费资源。也不要只设一个副本，没有高可用。一般来说，生产环境至少3个副本，确保一个节点挂了还有其他副本在运行。

第三，使用PDB（Pod Disruption Budget）保护应用。PDB可以确保在节点维护、集群升级等情况下，至少有一定数量的Pod在运行。

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-app-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: my-app

基础配置三：Service

Service是K8s中用来暴露应用的抽象。它为一组Pod提供一个稳定的访问入口。

Service有几种类型：ClusterIP（集群内部访问）、NodePort（通过节点端口访问）、LoadBalancer（通过云厂商负载均衡器访问）、ExternalName（映射到外部域名）。

一个基本的Service配置：

apiVersion: v1
kind: Service
metadata:
  name: my-app
spec:
  type: ClusterIP
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP

在1.32中，Service配置有几个注意点。

第一，selector要和Pod的label匹配。Service通过selector来选择后端Pod，如果selector不匹配，Service后面就没有端点，访问会失败。

第二，端口配置要正确。port是Service暴露的端口，targetPort是Pod上的端口。如果targetPort和containerPort不一致，要确保targetPort指向正确的端口。

第三，生产环境推荐用Ingress来暴露HTTP服务，而不是NodePort或LoadBalancer。Ingress提供了更丰富的路由功能，比如基于域名和路径的路由、TLS终止、限流等。

中级配置一：ConfigMap和Secret

ConfigMap用来存储非敏感的配置数据，Secret用来存储敏感数据，比如密码、密钥、证书。

ConfigMap的配置：

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-app-config
data:
  app.properties: |
    server.port=8080
    app.name=my-app
    log.level=info
  database.url: jdbc:mysql://localhost:3306/mydb

Secret的配置：

apiVersion: v1
kind: Secret
metadata:
  name: my-app-secret
type: Opaque
data:
  username: YWRtaW4=
  password: cGFzc3dvcmQ=

在1.32中，有几个改进值得关注。

第一，Secret的默认加密。在1.32中，etcd中的Secret静态加密更加完善，推荐启用加密配置，确保敏感数据在存储时是加密的。

第二，推荐使用外部密钥管理系统。对于生产环境，推荐使用外部的密钥管理系统（比如Vault、云厂商的KMS），而不是把Secret直接存在K8s中。可以通过External Secrets Operator来同步外部密钥到K8s。

第三，ConfigMap和Secret的热更新。默认情况下，挂载到容器的ConfigMap和Secret更新后，K8s会自动更新容器中的文件（有一定延迟）。但应用需要支持重新加载配置，否则需要重启Pod才能生效。

中级配置二：Ingress

Ingress是K8s中用来管理外部访问的API对象，提供了HTTP和HTTPS的路由功能。

一个基本的Ingress配置：

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

在1.32中，Ingress配置有几个要点。

第一，必须指定ingressClassName。在较早的版本中，可以通过annotation来指定Ingress控制器，但现在推荐使用ingressClassName字段。如果不指定，Ingress可能不会被任何控制器处理。

第二，TLS配置要正确。HTTPS是必须的，要配置TLS证书。证书可以通过cert-manager自动申请和续期，非常方便。

第三，利用annotation来配置高级功能。比如限流、重写、跨域、认证等，都可以通过annotation来配置。不同的Ingress控制器支持的annotation不同，要参考对应的文档。

中级配置三：资源管理和配额

在多租户的集群中，资源管理非常重要。K8s提供了ResourceQuota和LimitRange来控制资源的使用。

ResourceQuota用来限制命名空间的总资源使用：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-namespace-quota
spec:
  hard:
    requests.cpu: "10"
    requests.memory: 20Gi
    limits.cpu: "20"
    limits.memory: 40Gi
    pods: "50"
    services: "10"

LimitRange用来限制命名空间内每个容器的默认资源和最大最小资源：

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

在1.32中，资源管理有一些改进。比如，更精细的资源计量、对临时存储的配额支持、以及对扩展资源（比如GPU）的更好支持。

高级配置一：网络策略

NetworkPolicy用来控制Pod之间的网络访问，实现微服务之间的网络隔离。

一个基本的网络策略：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-app-network-policy
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: my-frontend
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: my-database
    ports:
    - protocol: TCP
      port: 3306

在1.32中，网络策略有一些增强。比如，对更多协议的支持、更灵活的规则匹配、以及性能优化。

需要注意的是，网络策略需要网络插件的支持，比如Calico、Cilium等。如果集群的网络插件不支持NetworkPolicy，配置了也不会生效。

高级配置二：调度策略

K8s的调度器负责把Pod调度到合适的节点上。通过调度策略，可以控制Pod的调度行为。

常见的调度策略包括：

第一，nodeSelector：通过标签选择节点。

nodeSelector:
  disktype: ssd

第二，亲和性和反亲和性：更灵活的调度规则。

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: disktype
          operator: In
          values:
          - ssd
  podAntiAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
    - weight: 100
      podAffinityTerm:
        labelSelector:
          matchLabels:
            app: my-app
        topologyKey: kubernetes.io/hostname

第三，污点和容忍：节点上的污点（Taint）会排斥没有对应容忍（Toleration）的Pod。

tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "gpu"
  effect: "NoSchedule"

在1.32中，调度器有一些性能优化和新功能，比如更智能的调度决策、对异构资源的更好支持、以及调度插件的增强。

高级配置三：HPA自动扩缩容

HPA（Horizontal Pod Autoscaler）可以根据CPU、内存或自定义指标，自动调整Pod的副本数。

一个基本的HPA配置：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80

在1.32中，HPA有一些改进。比如，更稳定的扩缩容算法、对更多指标类型的支持、以及和KEDA（Kubernetes Event-driven Autoscaling）的更好集成。

配置HPA的时候，要注意设置合理的minReplicas和maxReplicas，避免扩缩容太频繁。可以通过behavior字段来控制扩缩容的速度。

升级到1.32的注意事项

最后，说说升级到1.32的注意事项。

第一，检查废弃的API。升级之前，用kubectl api-resources和kubectl convert检查配置中是否使用了废弃的API，及时替换。

第二，备份数据。升级之前，一定要备份etcd数据和重要的配置，以防升级失败可以回滚。

第三，逐步升级。不要一次性升级所有节点，先升级控制平面，再逐步升级工作节点。升级过程中，密切关注集群的状态和应用的运行情况。

第四，测试验证。升级完成后，要全面测试集群的功能，确保所有应用都正常运行。

第五，阅读发布说明。每个版本的发布说明都详细列出了新特性、废弃功能、已知问题，升级之前一定要仔细阅读。

写在最后

Kubernetes 1.32带来了很多新特性和改进，掌握正确的配置方法，才能充分发挥这些特性的优势。

这篇文章从基础到高级，覆盖了Pod、Deployment、Service、ConfigMap、Secret、Ingress、资源管理、网络策略、调度策略、HPA等核心配置。希望能帮助你更好地使用K8s 1.32+。

当然，K8s的内容非常多，一篇文章不可能覆盖所有细节。在实际使用中，还是要多参考官方文档，多实践，多总结。

容器编排是一个不断演进的领域，保持学习，才能跟上技术的步伐。