江苏龙网

  1. 主页 > 生活百科 > >

Kubernetes 1.28发布，包含45项增强功能！( 三 )

Kubernetes


10.Sidecar 容器的 API 感知（alpha）
Kubernetes 1.28 为 init 容器引入了一个 alpha restartPolicy 字段 ， 并用它来指示 init 容器何时也是 Sidecar 容器 。它将按照定义的顺序与其他 init 容器一起启动 ， 并设定 restartPolicy 为 Always 。kubelet 会在启动 Pod 的主容器前仅等待 Sidecar init 容器启动 。
启动完成的条件是启动探针成功（或未定义启动探针）且 postStart 处理程序已完成 。该条件用 ContainerStatus 类型的字段 Started 表示 。
对于 init 容器 ， 可以省略重启策略字段 ， 或将其设置为 Always 。省略该字段意味着你想要一个真正的 init 容器 ， 在应用启动前完成 。
Sidecar 容器不会阻止 Pod 的完成：如果所有常规容器都已完成 ， 该 Pod 中的 Sidecar 容器也将终止 。
对于 Sidecar 容器 ， 重启行为比 init 容器更复杂 。在重启策略设置为 Never 的 Pod 中 ， 在 Pod 启动过程中失败的 Sidecar 容器不会被重启 ， 整个 Pod 将被视为失败 。如果 Pod 的 restartPolicy 是 Always 或 OnFailure ， 则会重试启动失败的 Sidecar 容器 。
一旦 Sidecar 容器启动（进程正在运行、postStart 成功且任何配置的启动探针都已通过） ， 然后出现故障 ， 即使 Pod 的整体重启策略为 Never 或 OnFailure ， Sidecar 容器也会重新启动 。此外 ， 即使在 Pod 终止期间 ， 也会重启（在失败或正常退出时）Sidecar 容器 。
要了解更多信息 ， 请阅读：
https://kubernetes.io/docs/concepts/workloads/pods/init-containers/#api-for-sidecar-containers
11.自动、追溯性地为默认的 StorageClass 赋值现已稳定
如果没有提供值 ， Kubernetes 会自动为 PersistentVolumeClaim （PVC） 设置一个 StorageClassName 。对于那些没有定义 storageClassName 的现有 PVC ， 控制平面也会自动设置一个 StorageClass 。Kubernetes 以前的版本也有这种行为；Kubernetes v1.28 则是自动的 ， 并且始终处于激活状态；该功能已升级到稳定版（一般可用性） 。
要了解更多信息 ， 请阅读：
https://kubernetes.io/docs/concepts/storage/storage-classes/
12.Job 的 Pod 替换策略（alpha）
Kubernetes 1.28 为作业 API 添加了一个新字段 ， 允许你指定是希望控制平面在之前的 Pod 开始终止时立即创建新 Pod（现有行为） ， 还是仅在现有 Pod 完全终止时才创建新 Pod（新的可选行为） 。
许多常见的机器学习框架（如 Tensorflow 和 JAX）都要求每个索引有唯一的 Pod 。在旧的行为中 ， 如果属于索引 Job 的 Pod 进入终止状态（由于抢占、驱逐或其他外部因素） ， 会创建一个替换 Pod ， 但由于与尚未关闭的旧 Pod 冲突 ， 替换 Pod 会立即无法启动 。
在前一个 Pod 完全终止之前出现一个替代 Pod ， 也会给资源稀缺或预算紧张的集群带来问题 。这些资源可能很难获得 ， 因此只有在现有 Pod 终止后 ， Pod 才能找到节点 。如果启用了群集自动分级器 ， 提前创建替代 Pod 可能会产生不希望的扩展 。
【Kubernetes 1.28发布，包含45项增强功能！】要了解更多信息 ， 请阅读：
https://kubernetes.io/docs/concepts/workloads/controllers/job/#delayed-creation-of-replacement-pods
13.每个索引的 Job 重试后退限制（alpha）
此功能扩展了 Job API ， 支持索引任务 ， 在索引 Job 中 ， 重试限制是按索引计算的 ， Job 可以在部分索引失败的情况下继续执行 。
目前 ， 索引 Job 的索引共享一个延迟限制 。当作业达到这个共享的延迟限制时 ， 作业控制器会将整个作业标记为失败 ， 并清理资源 ， 包括尚未运行完成的索引 。
因此 ， 现有的实现并没有涵盖这种情况 ， 即工作负载真正地令人尴尬地并行：每个索引都完全独立于其他索引 。
例如 ， 如果索引 Job 被用作一套长期运行的集成测试的基础 ， 那么每次测试运行只能发现一个测试失败 。
更多信息 ， 请阅读：
https://kubernetes.io/docs/concepts/workloads/controllers/job/#handling-pod-and-container-failures
14.没有 cAdvisor 的 CRI 容器和 Pod 统计信息
这包括两项相关工作（修改 kubelet 的 /metrics/cadvisor 端点和改进替换摘要 API） 。
消费者主要使用两个 API 来收集有关正在运行的容器和 Pod 的统计数据：summary API 和 /metrics/cadvisor 。Kubelet 负责实现 summary API ， cAdvisor 负责实现 /metrics/cadvisor 。


推荐阅读


上一篇：何时使用Elasticsearch，而不是MySQL？

下一篇：未来人工智能会代替人工？金融行业可不在这个范围里