「K8S 生态周报」内容次要蕴含我所接触到的 K8S 生态相干的每周值得举荐的一些信息。欢送订阅知乎专栏「k8s 生态」。
Trivy v0.17 正式公布
Trivy 是一款由 Aqua Security 开源的镜像破绽平安扫描程序,在之前的周报中我曾经介绍过它很屡次了,特地方便使用!(吃我安利!)本周 Trivy 公布了 v0.17 版本,咱们一起来看看本次值得关注的变更。
破坏性变更
Trivy 在之前的版本中,容许为 --skip-dirs
参数通过逗号(,)宰割,设定多个目录。自此版本中,将遵循大多数软件的默认行为,通过屡次传递--skip-dirs
来传递多个值,每个参数只解决一个目录。
v0.17 版本之前:
trivy image --skip-dirs "/usr/lib/ruby/gems,/etc" fluent/fluentd:edge
v0.17 版本及之后:
trivy image --skip-dirs /usr/lib/ruby/gems --skip-dirs "/etc" fluent/fluentd:edge
如果有在应用此个性的小伙伴,在降级时须要分外留神!免得影响到本人的工作流.
新增个性
- 能够反对 Go 二进制文件扫描了。次要实现形式能够参考我之前写的文章《逆向 Go 二进制文件,获取其依赖信息》
- 能够反对 JAVA 相干归档文件的破绽扫描了,比方 JAR,WAR 和 EAR 等格局。
但请留神:此性能目前无奈在离线环境中应用,须要发送 HTTP 申请以便拿到更多信息。所以如果网络环境较差,可能此过程会耗时久一些,能够通过减少--timeout
参数来管制超时工夫。 - 新增了 Plugin 机制 ,应用相似 kubectl 和 Helm 的 Plugin 机制。 发问:如果 trivy 集成了 kubectl 作为 plugin,而 kubectl 又用 trivy 做了 plugin 那会怎么样呢? 欢送留言探讨~
- Sprig 函数能够在 trivy 的自定义模板中应用了。有没有很眼生?之前的周报中介绍过 Helm 3.5 也反对了同样的内容。
更多对于此版本的详细信息请参考其 ReleaseNote
Alertmanager v0.22.0-rc.0 公布
应用 Prometheus 的小伙伴对 Alertmanager 应该都不生疏,此版本中减少了很多实用的个性:
- 有了新的创立 Silence 的模式,新日历;
- Routes 能够按工夫进行设置了,这也就能够解决很多“非工作工夫,不对测试环境报警”之类的需要了;
- 在界面上筛选的时候,能够反对“非”的匹配条件了,比方咱们能够间接做如下操作:“非生产环境,都敞开”;
- Web 界面原生反对 TLS 和 basic auth;
- 减少了 OAuth2.0/OIDC 反对;
- 苹果 M1 反对;
更多对于此版本的详细信息,请参考其 ReleaseNote
Rancher Desktop v0.1.0 公布
Rancher 最近推出了一个基于 electron 构建的桌面工具,用于在 Windows 和 macOS 等桌面环境下治理 Kubernetes 和容器等。它的外围个性如下:
- 反对自选 Kubernetes 版本(通过 k3s 提供反对);
- 可测试 Kubernetes 版本升级时,利用负载的变动(也通过 k3s 提供);
- 容器镜像的 build/pull/push 等(通过 kim 和 BuildKit 等实现);
- 反对本地端口映射(通过 kubectl port-forward 实现);
这里简略来聊聊我对这个工具的认识吧。从下面的介绍来看,其实很容易就能发现,这是奔着 Docker Desktop 的市场来的。到目前为止,市面上所有工具中,能齐全涵盖和替换 Docker Desktop 的还没有。无论说容器 & 镜像治理,镜像平安扫描,内置 k8s 集群等这些工具都能为开发者提供极大的便利性。这也是 Docker 依然能在开发者工具中占有大量市场的一个次要起因。
其次,咱们来看看这个工具推出的机会。最近 Docker Desktop 因为在新版本中将“敞开更新揭示”的性能设置成了付费用户可用,而受到了大量的批评。这个工具抉择在此时公布第一个版本,兴许是凑巧,兴许就恰好给一些人多了个抉择。
额定多说一点,Docker Desktop 新版本中那个性能变更的事件,其实在各大社交媒体 / 论坛上都有过很多探讨了,就我集体而言,我感觉这个决定是正当的,也是 Docker Inc. 必须得做的。这个公司在开源方面曾经做了足够多了,如果在本人的闭源产品上,也不做些策略,那就真的危险了。
上游停顿
- #101093 · kubernetes/kubernetes 在今年年初的 #98571 中为了在 Pod 优雅退出时候进行 probe 所以引入了非预期行为。此 PR 中对其进行了修复。该问题的场景是 Pod 在重启后
startupProbe
不能失常的执行。
欢送订阅我的文章公众号【MoeLove】