云原生爱好者周刊：有一份 DevOps 修炼指南请您查收！

云原生一周动态要闻：

• Cilium 成为 CNCF 孵化项目
• Argo Rollouts v1.1 发布
• 云原生安全微调查结果公布
• IBM 为 Linux 内核引入 CPU Namespace
• BFE Ingress Controller 正式发布
• 开源项目推荐
• 文章推荐

如果你在学习 DevOps 的过程中感到迷茫，不妨看看国外一位工程师开源的 DevOps 知识图谱。这个图谱包含了非常明确的学习路径，以及不同场景所需的各种可选工具。

想获取高清全图可关注公众号「KubeSphere 云原生」，公众号后台发送暗号 devops 即可获取。

如果你更倾向国内的课程，可以关注 KubeSphere 开源社区联合尚硅谷发布的《云原生实战》系列课程，该课程不仅仅包含了 DevOps，而是对云原生技术栈进行了全面的讲解，课程和资料全部可以免费获取和学习。

云原生动态

Cilium 成为 CNCF 孵化项目

日前，CNCF 技术监督委员会（TOC）投票接受 Cilium 成为 CNCF 的孵化项目。

Cilium 通过充当 CNI 和使用 eBPF 的 Kubernetes 增强网络层，为云原生环境提供网络、安全和可观测性。

Cilium 项目由多个组件和层组成，这些组件和层可以相互独立使用。这允许用户选择特定的功能，或者将 Cilium 与其他 CNI 结合运行。

• 代理：代理在所有 Kubernetes 工作节点和承载工作负载的其他服务器上运行。它提供了核心 eBPF 平台，是所有其他 Cilium 组件的基础。
• 网络插件（CNI）：CNI 插件使组织能够使用 Cilium 为 Kubernetes 集群和其他依赖 CNI 规范的编配系统提供网络连接。
• Hubble：Hubble 是 Cilium 的可观测部分。它提供网络和安全日志、指标、跟踪数据和几个图形用户界面。
• ClusterMesh：ClusterMesh 实现了一个网络或服务网格，它可以跨越多个集群和运行在外部虚拟机或裸金属服务器上的外部工作负载。它提供跨集群和工作负载的连接性、服务发现、网络安全性和可观察性。
• 负载均衡器：负载均衡器可以在集群中运行，实现 Kubernetes 服务，也可以在 Kubernetes 集群前独立运行，提供南北负载均衡。

作为 CNCF 孵化项目，Cilium 已经规划了完整的路线图，并正在积极添加新的功能和特性。该团队将在现有 Envoy Proxy 集成的基础上增加新的服务网格功能，包括对 OpenTelemetry 项目和 L7 负载平衡控制的支持。它们还将包含用于本地部署的其他特性，包括高级 IPAM 模式、多宿主、服务更改和对外部工作负载的增强支持。最后，该团队将通过添加进一步的身份集成、更深入的工作负载可见性以及继续关注基于身份的实施来重点发展安全功能。

详情见

Argo Rollouts v1.1 发布

日前，Argo Rollouts v1.1 推出。Argo Rollouts 是一个 Kubernetes 渐进式交付运营商，提供先进的蓝绿和金丝雀部署策略，具有自动推广、回滚和指标分析功能。尽管只是一个"小"版本，但 v1.1 版本却成了 Argo Rollout 有史以来最大的版本，包含了十几个重要的功能：

• 完全支持通知服务
• 稳定副本集的动态伸缩
• 无需分析的自动回滚
• Kustomize 开放 API 架构
• 推出仪表盘即服务
• 在中止期间控制缩减行为
• ...

Rollouts v1.1 是一个动感十足的版本，解决了来自社区的许多流行的增强请求和可用性建议。可以在 GitHub 页面下载该版本。

详情见

云原生安全微调查：超过 80% 的组织希望使用开源软件构建现代安全系统

在 CNCF 安全技术咨询小组（TAG）的帮助下，CNCF 最近对社区进行了一项微观调查，以了解组织如何管理云原生安全。

总体而言，该报告表明，组织认识到云原生架构中传统安全和现代安全之间的差异，并看到了现代云原生安全的价值。85% 的受访者表示，安全现代化对其组织的云原生部署非常重要。而且没有人表示这不重要。

点击查看微调查的完整结果。该报告包含有关组织最大的担忧、挑战和失误以及边缘云原生安全状态的更多详细信息。

详情见

IBM 为 Linux 内核引入 CPU Namespace

IBM 工程师 Pratik Sampat 发布了 Linux 内核的 CPU Namespace 接口的早期原型。该 CPU Namespace 旨在解决当前查看可用 CPU 资源的方法的一致性问题，以及解决因了解系统上的资源访问/定位而可能产生的安全问题。

IBM 主导的 CPU Namespace 提案追求以下设计：

• 这个原型补丁集引入了一个新的内核 Namespace 机制——CPU Namespace。

• CPU Namespace 通过虚拟化逻辑 CPU ID 并创建相同的加扰虚拟 CPU 映射来隔离 CPU 信息。它锁定在 task_struct 上，并且是被设计为平面层次结构的 CPU 转换，这意味着每个虚拟 Namespace 的 CPU 在创建 Namespace 时映射到物理 CPU。扁平层次结构的优点是翻译是 O(1) 并且子代不需要遍历树来检索翻译。

• 然后，该 Namespace 允许控制和显示接口都能够感知 CPU Namespace 上下文，这样 Namespace 内的任务只能通过虚拟 CPU 映射获得视图并因此控制其可用的 CPU 资源和视图 CPU 资源。

详情见

BFE Ingress Controller 正式发布

BFE Ingress Controller 是基于 BFE 实现的 Kubernetes Ingress Controller，用于支持在 Kubernetes 中使用 Ingress 来暴露服务并进行负载均衡、SSL 终结等，目前已正式发布并可以下载使用。BFE Ingress Controller 采用 Apache-2.0 License。

BFE Ingress Controller 实现了 Kubernetes 原生 Ingress 的功能，并基于 BFE 的能力，扩展了路由规则描述能力和服务间的流量调度能力。主要功能包括：

• HTTP/HTTPS 流量路由
  • 支持根据 Host、Path、Header、Cookie 对请求进行路由
  • 支持 Path 的精确匹配、前缀匹配
  • 支持 Host 的精确匹配、通配符匹配
• 多 Service 之间负载均衡
  • 支持在提供相同服务的多个 Service 之间按权重进行负载均衡
• TLS 终结
• 灰度发布
  • 支持基于 HTTP Header/Cookie 的服务灰度发布

更多信息，见 BFE Ingress Controller 的文档。

详情见

开源项目推荐

Parca

Parca 是一个类似于 Prometheus 的项目，用来针对应用程序和基础设施持续分析 CPU、内存在一段时间内的使用情况，并细化到行数，以帮助我们节省基础设施成本，提高性能，增加可靠性。

它的配置格式几乎完全模仿了 Prometheus，非常容易上手。例如：

debug_info:
  bucket:
    type: "FILESYSTEM"
    config:
      directory: "/tmp"
  cache:
    type: "FILESYSTEM"
    config:
      directory: "/tmp"

scrape_configs:
  - job_name: "default"
    scrape_interval: "1s"
    static_configs:
      - targets: ["127.0.0.1:7070"]

Inspektor Gadget

Inspektor Gadget 是一个 kubectl 插件，用于调试和检查 Kubernetes 集群中的应用。虽然它最初是为 Kinvolk 的开源 Kubernetes 发行版 Lokomotive 设计的，但在其他 Kubernetes 发行版上也可以使用。

StackGres

StackGres 是一个运行在 Kubernetes 之上的 PostgreSQL 全家桶，它的部署方式非常简单，使用 Operator 几分钟内即可部署企业级的 Postgres 及其周边组件。

文章推荐

CNCF Operator 白皮书

随着 Kubernetes Operator 模式的日益流行，CNCF Operator 工作组（TAG 应用交付）创建了一份白皮书，以帮助最终用户和软件供应商采用 Operator 来简化应用交付和运维。

白皮书的目标是在 Kubernetes 和其他容器调度框架的背景下，为云原生应用的 Operator 提供一个清晰定义和全面指南。它概述了：

• Operator 设计模式和未来的新兴模式。
• Operator 应用管理系统的推荐配置、实施和使用案例。
• 最佳实践，包括可观测性和安全性，技术实现，以及 CNCF 维护的代码样本。
• 对希望设计自己的 Operator 的组织的建议。

使用 eBPF 防止数据外泄

安全不仅仅是防止入侵，还要防止数据外泄，只要防范得当，即使攻击者获取了服务器的访问权限，数据也不会外流到未经授权的地方。本文就探讨了如何使用 eBPF 来防止数据外泄。

我们究竟该使用哪个版本的 JDK？

OpenJDK 是 Java SE 规范的开源参考实现，但它仅仅只是源代码。不同的供应商为不同的平台提供了二进制发行版，这些发行版在许可证、商业支持、支持的平台和更新频率方面都有所不同。本文给出了详细的选取 OpenJDK 的参考意见。

本文由博客一文多发平台 OpenWrite 发布！