Kubernetes 1.28：Sidecar 容器、Job和Proxy的新功能

Kubernetes 1.28 现已发布，具有 44 项新的或改进的增强功能！此版本包含许多主要功能，例如对 sidecar 容器的内置支持、作业优化和更好的代理。这些新功能可以帮助您提高 Kubernetes 集群的性能、效率和安全性。

在这篇博文中，我们将仔细研究 Kubernetes 1.28 的一些关键功能。我们还将讨论如何使用这些功能来改进 Kubernetes 部署。

边车容器：

Sidecar 容器是一种向 Kubernetes Pod 添加功能的流行模式。它们通常用于服务网格、收集指标和获取机密等任务。然而，实施 Sidecar 容器并不容易。

到目前为止，还没有办法告诉 Kubernetes 容器是 sidecar 容器。这意味着边车容器可能会在主容器完成之前被杀死，或者它们可能会在搞乱工作后继续存活。

现在，您可以将 init 容器上的 restartPolicy 字段设置为“始终”。这告诉 Kubernetes 将容器视为 sidecar 容器。 Kubernetes 处理 sidecar 容器的方式与处理常规容器不同：

kubelet 不会等待容器完成。它只会等到启动完成。
如果 sidecar 容器在启动过程中失败，则会重新启动，除非 pod 的 restartPolicy 为 Never。在这种情况下，整个 Pod 都会失败。
只要主容器正在运行，边车容器就会继续运行。
一旦所有常规容器完成，边车容器将被终止。这确保了边车容器不会阻止主容器完成后作业的完成。

以下是如何使用 restartPolicy 字段创建 sidecar 容器的示例：

kind: Pod
...
spec:
  initContainers:
  - name: vault-agent
    image: hashicorp/vault:1.12.1
  - name: istio-proxy
    image: istio/proxyv2:1.16.0
    args: ["proxy", "sidecar"]
    restartPolicy: Always
  containers:
  ...

Jobs优化

在此版本中，Kubernetes 中的作业受到了很多关注。

Kubernetes 中的作业可以一次启动大量重复的并行任务，这对于机器学习工作负载来说是理想的选择。由于对作业等工具的不断改进，Kubernetes 正在成为该领域的主要参与者。

我们已经讨论了 Sidecar 容器功能。此功能为作业用户带来了一些惊喜，例如确保 sidecar 不会阻止作业完成。

作业的可重试和不可重试 Pod 故障以及索引作业的每个索引的退避限制增强功能将为处理作业故障提供更精细的粒度。有些失败是暂时的或预期的，以不同的方式处理它们可以防止整个作业失败。

最后，作业控制器中完全终止后允许重新创建 Pod 为处理已完成的作业提供了更多控制选项。这可以帮助避免一些边缘情况和竞争条件。

Kubernetes 工作再次随着每个版本的发布而不断改进，这表明了社区（机器学习）对此功能的兴趣。

社区基础设施上的 Kubernetes 软件包：

Kubernetes 项目正在将其包存储库转移到社区拥有的基础设施中。这是为了将该项目与谷歌的基础设施脱钩，并使其更具弹性和可持续性。

新的存储库是 pkgs.k8s.io。它添加到现有存储库 apt.kubernetes.io 和 yum.kubernetes.io。旧的存储库将在将来的某个时候被弃用。

Kubernetes 团队将发布一篇博客文章，其中包含有关如何在发布前后迁移到新存储库的说明。

支持 Pod 中的用户命名空间：

SIG group: sig-node

Stage: Graduating to Alpha

Feature Gate: UserNamespacesStatelessPodsSupport Default: false

用户命名空间是一项 Linux 功能，允许您使用与主机不同的用户在 pod 中运行进程。这可以通过限制受损 pod 造成的损害来提高 Kubernetes 集群的安全性。

例如，您可以在容器中使用 root 用户运行 pod，但在主机中以非特权用户身份运行。这样，如果 Pod 受到损害，攻击者将只能拥有非特权用户的权限。

要在 Kubernetes 中使用用户命名空间，您需要：

至少 Linux 6.3 内核。

支持 idmap 的文件系统（即 ext4、btrfs、xfs、fat 等）。
支持 idmap 的容器运行时（即 CRI-O 1.25、containerd 1.7）

为动态和静态分配保留 NodePort 范围：

SIG group: sig-network

Stage: Graduating to Beta

Feature Gate: ServiceNodePortStaticSubrange Default: true

使用 NodePort 服务时，您可能需要静态分配端口，手动定义在服务节点端口范围（默认 30000-32767）内使用哪个端口。

但是，您可能会发现您的端口已动态分配给另一个服务。

此新功能保留服务节点端口范围中的第一个端口进行静态分配。

保留端口的数量由以下公式定义：min(max(16, nodeport-size / 32), 128)，该公式返回 16 到 128 之间的数字。

例如，对于默认范围 (30000-32767)，它返回 86 个端口。范围 30000-30085 将保留用于静态分配，其余的用于动态分配。

滚动升级：

三项新的增强功能将使升级更加可靠，并减少停机时间。对于管理员来说，这绝对是一种实时改进的质量，对于他们来说，将应用程序置于维护模式是一个很大的恐惧。

使用#4020未知版本互操作性代理，可以更好地处理集群组件的滚动升级。滚动升级意味着并非所有相同的组件都会立即升级，而是一个一个地升级，从而保持新旧共存。在这种情况下，当流量发送到已关闭的 Kubernetes 组件时，它将被重定向到准备就绪的对等点。

最后，#3836 Kube-proxy 改进了入口连接可靠性，#1669 代理终止端点将减少滚动升级时被终止的连接数量。当一个 Pod 被终止以便为新版本留出空间时，它的所有连接也会被终止，这会让客户不高兴。通过这些增强功能，这些连接将不再受到影响，让 Pod 优雅地终止。

Kube-proxy 改进了Ingress 连接可靠性：

SIG group: sig-network

Stage: Net New to Alpha

Feature Gate: KubeProxyDrainingTerminatingNodes Default: false

此增强功能为 kube-proxy 添加了一些功能，以更好地管理连接的运行状况。

尤其：

一旦节点终止，kube-proxy 不会立即终止所有连接，而是让它们正常终止。
添加了新的 /livez 路径，供应商和用户可以在其中定义 livenessProbe 来确定 kube-proxy 的运行状况。此方法比仅检查节点是否正在终止更具体。
为供应商提供实施这些健康检查的指南（将它们调整为标准不是现阶段的目标）。