Istio Ambient service mesh 于 2022 年 9 月在实验分支中推出，引入了一种新的数据平面模式，可以在没有 sidecar 的情况下使用 Istio。 Istio 社区通过与 Google、Solo.io、Microsoft、Intel、Aviatrix、华为、IBM 等合作，如今 Istio Ambient service mesh 已经从实验分支毕业，合并到 Istio 的主分支中！这是 Ambient service mesh 的重要里程碑！这也正如我在之前文章中预测的一样，此功能将在 Istio v1.18 中发布，并为在未来的 Istio 发布版本中默认安装铺平了道路。

Ambient service mesh 旨在简化操作、扩大应用兼容性，并降低基础设施成本。 Ambient 的最终目标是对应用程序透明化，并对 ztunnel 和 waypoint 组件进行了一些更改，使其更简单、更轻量化。

ztunnel 组件已从头开始进行了重写，以提高其速度、安全性和轻量化。请参阅《Introducing Rust-Based Ztunnel for Istio Ambient Service Mesh》以获取更多信息。
简化了 waypoint 代理的配置，以提高其可调试性和性能。
添加了 istioctl x waypoint 命令，以帮助用户方便地部署 waypoint 代理，以及 istioctl pc workload 命令，以帮助用户查看工作负载信息。
让用户能够明确绑定 Istio 策略，例如 AuthorizationPolicy，到 waypoint 代理而不是选择目标工作负载。

如果对此有兴趣的小伙伴可以使用如下文档来先行体验：Istio Prelim 1.18 / Getting Started with Ambient Mesh

containerd 1.7.0-rc.1 发布

按计划 containerd v1.7 将会是 containerd v1.x 的最后一个大版本，后续就会往 v2.0 演进了。不过看目前的情况，可能还有很长的路要走。毕竟现在 v1.5 和 v1.6 还是主流版本。

这个版本中包含了很多实验性的特性，但整体仍然是符合 containerd 的兼容性承诺的。主要的特性包括以下内容：

Sandbox API (experimental)

Sandbox API 提供了一种新的方式来管理 containerd 的 shim，为 Pod 和虚拟机等多容器环境提供更多的灵活性和功能性。

这个 API 让更高级别的容器组的管理更加容易，并且为 shim 实现和客户端提供了新的扩展点。主要通过 Sandbox API (#6703) 和 CRI Sandbox API Implementation (#7228) 实现。

Transfer Service (experimental)

Transfer Service 是一个简单而灵活的服务，可用于在源和目标之间传输工件对象。灵活的 API 允许传输接口的每个实现确定源和目标之间的传输是否可行。这使得可以直接通过实现添加新功能，而无需对 API 进行版本控制或要求其他实现处理接口更改。

传输服务基于 libchan 项目提出的核心思想构建，即具有二进制流和数据通道作为一等对象的 API 更加灵活，可以在不需要不断更新协议和 API 的情况下打开更广泛的用例。为了实现这一目标，传输服务利用流服务，使得在使用 grpc 和 ttrpc 时，二进制流和对象流可以被传输对象访问。

在这个版本中，这是实验性的，以便进一步插件开发和集成到现有插件中。

NRI (experimental)

Node Resource Interface（NRI）是将扩展插件插入 OCI 兼容容器运行时的通用框架。它提供了基本机制，使插件能够跟踪容器的状态，并对其配置进行有限的更改。

NRI 本身对任何容器运行时的内部实现细节是不可知的。它提供了一个适配库，运行时使用它来与 NRI 和插件进行集成和交互。原则上，任何 NRI 插件都应该能够与支持 NRI 的运行时一起工作。

此版本引入了 NRI v0.3.0，其中包括更新的插件接口，以涵盖各种用例。

其他

支持了在 FreeBSD 上运行 Linux 容器；
增加对 CDI 设备注入的支持 (#6654)
支持 cgroups blockio (#5490)
增加增强型重启管理器的重启策略 (#6744)
初步支持 gRPC shim

更多关于此版本的详细信息请参考其 ReleaseNote

Rook v1.11.0 正式发布

Rook 的这个版本中有一些需要关注的点：

支持的最低 Kubernetes 版本是 v1.21。
支持的最低 Ceph-CSI 驱动程序版本是 v3.7。
已删除对 MachineDisruptionBudgets 的支持，包括从 CephCluster CR 中删除的 manageMachineDisruptionBudgets 和 machineDisruptionBudgetNamespace
在开发过程中支持的 golang 版本为 v1.19 和 v1.20。

这都是一些破坏性变更，升级的时候请参考 Rook Upgrades - Rook Ceph Documentation

Trivy v0.38.0 正式发布

Trivy 越来越完善了，也正在被更广泛的采用。我个人还是比较喜欢这个工具的。这个版本中增加了一些比较不错的特性：

完善了 Docker CIS Benchmark 的支持

Docker CIS Benchmark 是一个针对 Docker 容器的安全基准，旨在提供一组标准的安全配置和建议，以帮助组织更好地保护其Docker容器环境。该基准由CIS（Center for Internet Security）组织制定。

该基准包括一系列安全配置建议，以确保Docker容器环境的安全。这些建议包括关于Docker主机的安全配置、Docker容器和图像的安全配置、Docker网络和存储的安全配置等。此外，该基准还提供了评估和监控Docker环境安全性的方法。

完整的Docker CIS Benchmark是一份包含所有建议配置和实施步骤的详细文档，可以帮助组织评估其Docker容器环境的安全性，并根据需要进行必要的更改和改进。

$ trivy image --compliance docker-cis my-image
...

Summary Report for compliance: CIS Docker Community Edition Benchmark v1.1.0
┌──────┬──────────┬─────────────────────────────────────────────────────────────────────────┬────────┬────────┐
│  ID  │ Severity │                              Control Name                               │ Status │ Issues │
├──────┼──────────┼─────────────────────────────────────────────────────────────────────────┼────────┼────────┤
│ 4.1  │   HIGH   │ Ensure a user for the container has been created                        │  FAIL  │   1    │
│ 4.2  │   HIGH   │ Ensure that containers use trusted base images (Manual)                 │   -    │   -    │
│ 4.3  │   HIGH   │ Ensure unnecessary packages are not installed in the container (Manual) │   -    │   -    │
│ 4.4  │ CRITICAL │ Ensure images are scanned and rebuilt to include security patches       │  PASS  │   0    │
│ 4.5  │   LOW    │ Ensure Content trust for Docker is Enabled (Manual)                     │   -    │   -    │
│ 4.6  │   LOW    │ Ensure HEALTHCHECK instructions have been added to the container image  │  FAIL  │   1    │
│ 4.7  │   HIGH   │ Ensure update instructions are not use alone in the Dockerfile          │  PASS  │   0    │
│ 4.8  │   HIGH   │ Ensure setuid and setgid permissions are removed in the images (Manual) │   -    │   -    │
│ 4.9  │   LOW    │ Ensure COPY is used instead of ADD in Dockerfile                        │  FAIL  │   1    │
│ 4.10 │ CRITICAL │ Ensure secrets are not stored in Dockerfiles (Manual)                   │  FAIL  │   2    │
│ 4.11 │  MEDIUM  │ Ensure verified packages are only Installed (Manual)                    │   -    │   -    │
└──────┴──────────┴─────────────────────────────────────────────────────────────────────────┴────────┴────────┘

添加了对 Kubernetes 废弃和删除 API 的检查

这个功能比较实用，不需要用户自己去记忆，或者特别的关注每个 API 的版本变化。

$ trivy config ~/data/input.json  --k8s-version=1.22.0
2023-02-08T18:00:49.111+0200  INFO  Misconfiguration scanning is enabled
input.json (kubernetes)

Tests: 145 (SUCCESSES: 144, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (UNKNOWN: 0, LOW: 1, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

LOW: apiVersion 'batch/v1beta1' and kind ‘CronJob' should be replaced with the new API 'batch.v1.CronJob'
See https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/api/batch/v1beta1/zz_generated.prerelease-lifecycle.go
════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════════
apiVersion 'batch/v1beta1' and kind 'CronJob' has been deprecated on: 'v1.21' and planned for removal on:'v1.25'

See https://github.com/kubernetes/kubernetes/tree/master/staging/src/k8s.io/api/batch/v1beta1/zz_generated.prerelease-lifecycle.go
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 input.json:1-5
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
   1 ┌ {
   2 │     "apiVersion": "batch/v1beta1",
   3 │     "kind": "CronJob",
   4 │     "metadata": {
   5 └         "name": "pi"
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

对 Go 依赖树和 license 的支持

使用方式如下：

$ trivy fs --scanners vuln --dependency-tree ./go.mod

我两年前写过一篇文章，介绍了另一个获取 Go 依赖的方法，感兴趣的小伙伴可以看看从 Go 的二进制文件中获取其依赖的模块信息 | MoeLove

上游进展

In-place Pod Vertical Scaling feature by vinaykul · Pull Request #102884 · kubernetes/kubernetes

经过4年的规划和至少两年的开发，现在终于推出了 Pod 的就地资源缩放的第一版。这个PR实现了核心缩放功能和一些相关的API处理。主要功能非常简单，现在可以在现有容器上编辑 resources 配置，而不会导致 API 错误。

在看到缩放请求后，Kubelet 会立即采取行动并检查节点是否有足够的资源来满足新的请求。如果是这样，它将 Status.Resize 字段设置为 InProgress，并继续进行 CRI 调用和其他内部更新。

如果新的大小不合适，将启动其他状态流，但总体目标相同，即尝试在可能的情况下提供请求的更改。还有一个新的 per-resource 缩放策略字段，可以设置为 RestartNotRequired（默认值）表示不需要重新启动（但某些运行时仍然可能需要这样做），或设置为 Restart 以强制关闭和重新启动容器（例如具有需要重新计算-Xmx 堆大小标志的 Java 应用）。

现在缺少一个显著的特性是基于缩放的驱逐。目前，Kubelet 不会自动处理它，但如果外部系统执行 Pod 删除，它将适当地作出反应。

尽管现在还处于比较早期的阶段，但至少我们看到了它的变化，期待后续的演进。

欢迎订阅我的文章公众号【MoeLove】

TheMoeLove

K8S 生态周报| Kubernetes In-place Pod 垂直伸缩的功能已合并

相关文章：