准备好使用新更新的K8S

Kubernetes 引入了众多旨在提升交通分配、资源管理和安全性的新特性。这次更新将使用户的 Kubernetes 使用体验更可靠、更高效。

AppArmor 支持: 通过为 pod 和容器强制执行安全配置来保护您的应用免受潜在的漏洞侵害。

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    securityContext:
      apparmorProfile: "restricted"  # 或自定义配置文件

PodDisruptionBudget (PDB) 带有不健康 Pod 驱逐策略: 使用此策略，用户可以保持 Pod 的可用性，同时定义针对健康但未就绪 Pod 的操作。它提供了更精确控制 Pod 驱逐过程的能力。

    apiVersion: policy/v1beta1  
    kind: PodDisruptionBudget  
    metadata:  
      name: my-pdb  
    spec:  
      minAvailable: 1  
      selector:  
        matchLabels:  
          app: my-app  
      unhealthyPodEvictionPolicy: "Condition"  # （从 1.31 版本开始）

Pod 级资源限制: 通过为特定的 Pod 设置资源使用的上限，实现资源分配的更精确控制。

apiVersion: v1
kind: Pod  # Pod是Kubernetes中的一个基本单元
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: my-image
    resources:
      limits:
        cpu: "2"  # CPU限制
        memory: "2Gi"  # 内存限制
  limits:
    cpu: "4"  # Pod级别的CPU限制
    memory: "4Gi"  # Pod级别的内存限制

例如，my-container 在容器层面设定了资源限制，而整个 pod 还设定了额外的资源限制。无论各个容器如何使用资源，整个 pod 的总资源使用不能超出规定的限制。

多个服务CIDR： 为了在更大的IP地址范围内实现负载均衡，可以将多个CIDR块分配给服务。利用新的服务字段，配置流量在多个后端之间的分配，或实施高级路由策略。

    apiVersion: v1  
    kind: Service  
    metadata:  
      name: my-service  
    spec:  
      selector:  
        app: my-app  
      clusterIP: None  # 用于负载均衡模式  
      loadBalancerIP: 10.0.0.1  # 指定的静态 IP  
      serviceCidrBlock: "10.10.0.0/16,10.20.0.0/16"  # 指定的 CIDR 块，从 1.31 版本开始新增

apiVersion: v1  
kind: Service  
metadata:  
  name: my-service  
spec:  
  selector:  
    app: my-app  
  trafficPolicy: "Local"  # 可选；新增于 1.31 版本  
  # 在此定义流量路由规则

Kubernetes v1.30 还处于试验阶段引入了 Kubernetes Service 中的 spec.trafficDistribution 字段。通过这样做，您可以指定服务端点流量路由的偏好。流量分布使您可以表达偏好（例如路由到拓扑上更近的端点），而流量策略则更注重严格的语义保证，如确保特定的性能或可靠性。这有助于降低成本、提高可靠性和优化性能。启用 ServiceTrafficDistribution 特性门控后，您可以在集群及其所有节点上使用此字段。在 Kubernetes v1.30 中，支持以下字段值

PreferClose: 表达了希望流量路由到拓扑上接近客户端的端点的愿望。不同的实现可能会以不同的方式解释“拓扑接近”，它可能指的是属于同一节点、机架、地域甚至地域内的端点。

可以使用 VolumeRestriction 插件来限制 pod 中可使用的卷类型。由于对插件的支持进行了改进，从 Kubernetes 1.31 版本开始，Kube-scheduler 现在支持 VolumeRestriction 插件的调度提示。这意味着现在可以给调度器提供关于所需卷类型的建议。调度器将根据这些提示尝试将 pod 调度到具有相应卷类型的节点上。

在这个情况下，pod 正在请求一个持久卷声明资源。调度器将根据此提示，尝试将 pod 调度到有可用持久卷声明资源的节点上。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  schedulerName: default-scheduler
  # 提示：这里的 type 表示 PersistentVolumeClaim 类型
  volumeSchedulingHints:
  - type: PersistentVolumeClaim

在 Kubernetes 的早期版本中，ReplicaSets 使用了一种确定性的方法来选择在缩容时要移除的 pod。这常常导致 pod 分布不均的问题，某些节点上的 pod 数量明显较少。这最终可能会影响资源利用率和集群性能。

在 Kubernetes 1.31 版本中引入了一种随机选择机制，从一组符合条件的节点中随机选择。这样可以避免 pod 亲和性问题，从而整体提高集群的利用率。

虽然 Kubernetes 控制器管理器实现了随机选择 pod 的过程，用一个更简单的例子来帮助理解这个概念也是很有帮助的。这里有一个使用 Python 模拟随机选择 pod 的简单例子，其中“pod”可以保持为原文或使用“容器实例”。

    import random  
    def random_pod_selection(pods):  
      """从一个pod对象的列表中随机选择一个pod进行终止。  
      参数:  
        pods: 一个pod对象的列表。  
      返回:  
        选中的pod。  
      """  
      if not pods:  
        return None  
      return random.choice(pods)

当与 PV 相关联的 PVC 被删除时，会发生什么取决于回收策略。回收策略在 Kubernetes 1.31 中进行了改进。
以下是一些可用的回收策略：

保留: PVC 被删除后，PV 会被保留。
循环利用: 在再次使用之前，PV 会被清理并循环利用。
删除: 随着 PVC 的删除，PV 也会被删除。
在 Kubernetes 1.31 中，回收策略得到了增强，其中包括：

终结器: 终结器可以添加到PV中，在满足一组要求之前防止其被删除。
回收策略的验证: 为了防止错误，必须对回收策略进行更严格的验证。

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce (只读写一次)
  persistentVolumeReclaimPolicy: 保留
  nfs:
    path: /export/path
    server: 192.168.1.10
    # NFS (网络文件系统)

• 持久卷最后阶段转换时间: 为了帮助调试和生命周期管理，跟踪持久卷在其最后一个阶段（如已释放状态）中所花费的时间。
• 具有可重试与不可重试的 Pod 失败的作业: 在作业中识别可恢复与不可重试的 Pod 失败，以实现更智能的作业管理。
• 弹性索引的作业: 弹性索引的作业可以根据外部索引进行扩展或缩小，允许动态调整工作负载。
• 增强的 Ingress 连接性: 通过改进的 kube-proxy 管理增强 Ingress 连接的可靠性。
• 考虑因缩放而终止的 Pod 部署: 现在部署包括一个新的注释，可以让你表明 Pod 可能因缩放而终止的情况。
• 声明式的节点维护: 通过使用节点对象来声明性地管理计划中的节点维护，可以简化该过程。

从 Kubernetes 1.31 版本开始要求内核版本为 5.13 或更高，以及 nft 版本为 1.0.1 或更高，以使 kube-proxy 能正常工作。kube-proxy 使用 nft 命令行工具为网络流量的管理配置 Netfilter。由于 kube-proxy 需要一些在内核版本 5.13 中引入的新功能，因此需要更新内核版本。在安装 Kubernetes 1.31 之前，如果您使用的是较旧版本，则必须将内核或 kube-proxy 更新到受支持的版本。

来，让我帮你 ;)_translated_from_source_withsuggestions

    # 升级nft命令行工具  
    apt-get update && apt-get install nft -y  

    # 升级内核  
    uname -r # 查看当前的内核版本  
    # 下载并安装最新的内核  
    wget https://cdn.kernel.org/v5.13/linux-5.13.19.tar.xz  
    tar -xvf linux-5.13.19.tar.xz  
    cd linux-5.13.19  # 切换到解压后的内核源码目录  
    make install  
    # 更新grub以引导新的内核版本  
    update-grub

Version字段 — 在Kubernetes v1.31版本中，Nodes的.status.nodeInfo.kubeProxyVersion字段被弃用，并将在后续版本中删除。弃用的原因是该字段的值不准确，且这种不准确性一直持续。此字段由kubelet设置，因此无法提供可信的kube-proxy版本信息，甚至无法确认kube-proxy是否正在运行。从v1.31版本开始，kubelet将不再尝试为相关的节点设置.status.kubeProxyVersion字段，同时，DisableNodeKubeProxyVersion特性门控将默认启用。

Kubernetes 1.31的最大改动之一是移除了树内云服务商的代码。此举意在以促进外部云服务商的发展，使Kubernetes更加不受供应商限制。

apiVersion: cloudprovider.k8s.io/v1beta1  # API版本
kind: CloudConfig  # 配置类型
metadata:  
  name: config  # 配置名称
spec:  
  controllerManagerConfig:  
    aws:  
      region: us-west-2  # AWS区域

确保要

请根据上下文添加剩余部分的翻译。做到。

• 识别你当前正在使用的已弃用的API。
• 在Kubernetes文档中查找并使用推荐的替代API。
• 更新你的代码以使用推荐的替代API。
• 彻底测试所做的更改。

了解更多详情，请访问Kubernetes 停用指引

这篇博客文章只是一个起点，来了解 Kubernetes 1.31 的变更记录。想要详细了解每个变更，我强烈建议你读一下整个变更记录。你可以直接访问变更记录找到更多信息。

• Kubernetes 1.31 版本更新日志: https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md
• Kubernetes 停用策略: https://kubernetes.io/docs/reference/using-api/deprecation-policy/