云原生爱好者周刊（VMware Tanzu 社区办发布，无任何限制！）云计算

云原生一周动态要闻：

VMware Tanzu 推出社区版

Kubernetes Cluster API 1.0 版已生产就绪

Linkerd 2.11 发布

Cartografos 工作组推出云原生成熟度模型

OpenEBS 3.0 发布

开源项目推荐

文章推荐

云原生动态 VMware Tanzu 推出社区版
世界正在向基于 Kubernetes 构建的云原生基础设施发展。这就是 VMware 创建 VMware Tanzu 的原因。但是，仅有技术本身是不够的，如果没有开发人员、基础设施和平台操作员、站点可靠性工程师以及其他拥有使用技术所需知识和技能的人，即使有再好的技术也无济于事。
Tanzu 社区版包含了利用 Kubernetes 实现端到端应用交付自动化所需的所有开源技术，以及定制平台的能力。这意味着你可以从小事做起，然后随着你的需求增长，随时轻松地增加新的功能。而且，无论未来你走到哪里，你用 Tanzu 社区版开发的知识、技能和工件都可以随身携带，并且可以完全转移到 Tanzu 的商业产品中。

文章图片

Tanzu 社区版是免费的开源软件，不受使用限制或功能限制的影响。
详情见
Kubernetes Cluster API 1.0 版已生产就绪
Cluster API v1.0 已准备好投入生产并正式迁移到 v1beta1 API。Cluster API 是一个 Kubernetes 项目，它为 Kubernetes 启用声明式管理，使用 API 轻松创建、配置和更新集群。它是一种端到端的方法，可以简化 Kubernetes 生命周期的重复性任务，同时在统一的基础架构中保持一致性和可重复性。
Cluster API 的主要目标是使集群生命周期管理变得枯燥。API 和可扩展性模型有一个成熟的生产记录；随着时间的推移，Cluster API 的目标是进一步巩固基础，并建立抽象，以简化终端用户的体验。
详情见
Linkerd 2.11 发布
Linkerd 2.11 发布，此版本标志着 Linkerd 向前迈进了一大步。Linkerd 2.11 引入了“策略”，这是一项期待已久的功能，允许用户控制允许哪些服务相互连接和发送请求。此版本还引入了许多改进和性能增强，包括 gRPC 调用的重试、容器启动顺序问题的一般修复、更小的代理、更小的控制平面等等。

授权策略
Linkerd 的新服务器授权策略(server authorization policy)功能使您可以细粒度控制允许哪些服务相互通信。这些策略直接建立在 Linkerd 的自动 mTLS 功能提供的安全服务身份上。与 Linkerd 的设计原则保持一致，授权策略以可组合的 Kubernetes 原生方式表达，这种方式只需最少的配置，就可表达广泛的行为。
重试带有正文的 HTTP 请求
重试失败的请求是 Linkerd 提高 Kubernetes 应用程序可靠性能力的关键部分。到目前为止，出于性能原因，Linkerd 只允许重试无正文请求，例如 HTTP GET。在 2.11 中，Linkerd 还可以重试带有 body 的失败请求，包括 gRPC 请求，最大 body 大小为 64KB。
容器启动排序解决方法
Linkerd 2.11 现在默认确保 linkerd2-proxy 容器在 Pod 中的任何其他容器初始化之前准备就绪。这是 Kubernetes 对容器启动顺序缺乏控制的一种解决方法，并解决了一大类棘手的竞争条件，即应用程序容器在代理准备就绪之前尝试连接。
更小、更快、更轻
- 控制平面减少到只有 3 个部署。
- 由于高度活跃的 Rust 网络生态系统，Linkerd 的数据平面“微代理”更小、更快。
- SMI 功能大部分已从核心控制平面中删除，并移至扩展中。
- Linkerd 镜像现在使用最少的“distroless”基础镜像。

详情见
Cartografos 工作组推出云原生成熟度模型
Cartografos 工作组的第一个项目是创建云原生成熟度模型。这个小组的成员都围绕着云原生和 Kubernetes 的发展历程，分别撰写了成熟度模型。其目标是将这些模型结合起来，形成一个涵盖整个云原生生态系统的全方位模型。
随着成熟度模型的建立，该小组很快就发现，这个过程并不局限于技术。围绕人、流程和政策有明确的主题，因为每一个主题都在采用云原生技术方面发挥着巨大的作用。
云原生成熟度的 5 个阶段：
第 1 级：构建。你有一个基线的云原生实施，并处于预生产状态。
第 2 级：运营。云原生的基础已经建立，你正在转向生产。
第 3 级：规模。你的能力正在增长，你正在为规模化定义流程。
第 4 级：改进。你正在改善整个环境的安全性、政策和治理。
第 5 级：优化。你正在重新审视先前的决定，并监测应用程序和基础设施的优化。
详情见
OpenEBS 3.0 发布
OpenEBS 3.0（请参阅发行说明）是旨在为更轻松地加入和接受社区贡献奠定基础的努力的结晶，使每个引擎运营商为未来的 Kubernetes 版本做好准备，从而轻松管理和排除各种引擎的故障。
该版本功能增强包括：

CStor 和 Jiva 的 CSI 驱动程序以及将卷迁移到更新的 CSI 驱动程序的工具。3.0.0 已弃用旧版供应商，用户需要尽快迁移到相应的 CSI 驱动程序。
对现有 LocalPV 风格的若干增强和新类型 LocalPV 的引入。
Mayastor 的新控制平面正在开发中，其设计更能处理规模和弹性。
还包括用于 OpenEBS 的 kubectl 插件的初始版本和用于管理 OpenEBS 存储和卷的 prometheus grafana mixin。

详情见
开源项目推荐 Otomi
Otomi 是一个开源的基于 Kubernetes 的平台，它提供了类似于 Linux 桌面环境的用户界面，你可以像部署 Linux 中的软件包一样部署 Kubernetes 中的应用。默认已经集成了 Istio、Knative、Prometheus、Harbor、Keycloak、Nginx ingress、External-DNS、Cert-manager、Hashicorp Vault、Gatekeeper、Drone、Gitea 等项目，开箱即用。

文章图片

Damon
【云原生爱好者周刊（VMware Tanzu 社区办发布，无任何限制！）】Damon 是 Nomad 的一个终端用户界面（TUI），可以用来管理 Nomad 的 Jobs、Deployments 和 Allocations 等资源。该项目目前还在持续增加新功能中。

文章图片

Kdigger
kdigger是 "Kubernetes digger" 的简称，是一个用于 Kubernetes 渗透测试的上下文发现工具。这个工具集成了多种插件，每个插件负责发现不同的上下文信息。例如：

$ kdigger dig dev ### DEVICES ### Comment: 16 devices are available. +-------------+-------+----------------------+-----------------+ |MODE| ISDIR |MODTIME|NAME| +-------------+-------+----------------------+-----------------+ | Lrwxrwxrwx| false | 2021-10-11T07:32:14Z | core| | Lrwxrwxrwx| false | 2021-10-11T07:32:14Z | fd| | Dcrw-rw-rw- | false | 2021-10-11T07:32:14Z | full| | dtrwxrwxrwx | true| 2021-10-11T07:31:54Z | mqueue| | Dcrw-rw-rw- | false | 2021-10-11T07:32:14Z | null| | Lrwxrwxrwx| false | 2021-10-11T07:32:14Z | ptmx| | drwxr-xr-x| true| 2021-10-11T07:32:14Z | pts| | Dcrw-rw-rw- | false | 2021-10-11T07:32:14Z | random| | dtrwxrwxrwx | true| 2021-10-11T07:31:54Z | shm| | Lrwxrwxrwx| false | 2021-10-11T07:32:14Z | stderr| | Lrwxrwxrwx| false | 2021-10-11T07:32:14Z | stdin| | Lrwxrwxrwx| false | 2021-10-11T07:32:14Z | stdout| | -rw-rw-rw-| false | 2021-10-11T07:32:14Z | termination-log | | Dcrw-rw-rw- | false | 2021-10-11T07:32:14Z | tty| | Dcrw-rw-rw- | false | 2021-10-11T07:32:14Z | urandom| | Dcrw-rw-rw- | false | 2021-10-11T07:32:14Z | zero| +-------------+-------+----------------------+-----------------+$ kdigger dig authorization ### AUTHORIZATION ### Comment: Checking current context/token permissions in the "default" namespace. +---------------------------------+-----------------+----------------+----------+ |RESOURCES| NONRESOURCEURLS | RESSOURCENAMES |VERBS| +---------------------------------+-----------------+----------------+----------+ | selfsubjectaccessreviews.author | []| []| [create] | | ization.k8s.io|||| | selfsubjectrulesreviews.authori | []| []| [create] | | zation.k8s.io|||| || [/api/*]| []| [get]| || [/api]| []| [get]| || [/apis/*]| []| [get]| || [/apis]| []| [get]| || [/healthz]| []| [get]| || [/healthz]| []| [get]| || [/livez]| []| [get]| || [/livez]| []| [get]| || [/openapi/*]| []| [get]| || [/openapi]| []| [get]| || [/readyz]| []| [get]| || [/readyz]| []| [get]| || [/version/]| []| [get]| || [/version/]| []| [get]| || [/version]| []| [get]| || [/version]| []| [get]| | apiservices| []| []| [list]| | namespaces| []| []| [list]| | apiservices.apiregistration.k8s | []| []| [list]| | .io|||| | namespaces.apiregistration.k8s. | []| []| [list]| | io|||| +---------------------------------+-----------------+----------------+----------+

Istio 运维实战
通过将微服务中原本在 SDK 中实现的应用流量管理、可见性、通信安全等服务治理能力下放到一个专门的“服务网格”基础设施中，Istio 解开了微服务的服务治理需求和业务逻辑之间的代码、编译、部署时机等的耦合，让微服务真正做到了承诺的“按需选择开发语言”，“独立部署升级”等能力，提升了微服务开发和部署的敏捷性，释放了微服务模式的生产力。
然而，“服务网格”这一基础设施的引入也给整个微服务的运维技术栈带来了新的挑战。对于运维同学来说，Istio 和 Envoy 的运维存在着较陡的学习曲线。TCM（Tencent Cloud Mesh）团队是业内最早一批接触服务网格技术的人员之一，有着大量 Istio/Envoy 故障排查和运维经验。本电子书记录了 TCM 团队从大量实际案例中总结出来的 Istio 运维经验，以及使用 Istio 的最佳实践，感兴趣的可以拜读一下。
文章推荐粘性会话是如何破坏 K8s 中的弹性伸缩的
通常我们认为，弹性伸缩和负载均衡是几乎没有关联的，但本文作者偶然发现了 AWS 应用负载平衡器（ALB）的问题，粘性会话会影响到负载均衡和弹性伸缩之间的关系。本文探讨了背后的原因及其解决方案。
使用 eBPF 破解 Linux 内核
本文旨在从一个漏洞开发人员的角度对 eBPF 进行详细介绍。简单地说，eBPF 为用户模式的应用程序提供了一种在内核中运行代码的方法，无需编写内核模块。相比于内核模块，使用 eBPF 的好处是易于使用、稳定且安全。