共计 5278 个字符，预计需要花费 14 分钟才能阅读完成。
云原生一周动静要闻：
- 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
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 的益处是易于应用、稳固且平安。
本文由博客一文多发平台 OpenWrite 公布！