云原生生态周报 Vol.2

本文涉及的产品
应用实时监控服务ARMS - 应用监控,每月50GB免费额度
可观测监控 Prometheus 版,每月50GB免费额度
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 本周作者:傅伟,敖小剑,张磊,临石,南异,王夕宁,长虑  编辑:木环业界要闻近日,世界上最大的域名托管公司 Godaddy 公司,正式宣布并详细解读了其开源的 K8s 外部 Secrets 管理项目:Kubernetes External Secrets,简称 KES。

本周作者:傅伟,敖小剑,张磊,临石,南异,王夕宁,长虑  
编辑:木环

业界要闻

  1. 近日,世界上最大的域名托管公司 Godaddy 公司,正式宣布并详细解读了其开源的 K8s 外部 Secrets 管理项目:Kubernetes External Secrets,简称 KES。这个项目定义了 ExternalSecrets API,让开发者可以在 K8s 内部以和使用内部 Secret 相似的方式使用外部系统提供的 Secrets,大大简化了开发者为了让应用获取外部 Secrets 所需要的工作量。从安全的角度,这个方案降低了使用外部Secret时候的攻击面(外部 Secret 是通过一个 K8s API 暴露的,而不是之前的每个应用自己实现),也降低了应用在适配外部 Secret 时候的难度。另外,Kubernetes KMS plugin 开源插件 ,采用信封加密的方式与密钥管理能力结合,对进行 K8s secret 的存储加密。建议安全相关技术人员重点关注。
  2. CNCF 官方宣布为中国开发者提供免费的云原生技术公开课。这些课程将专注于云原生技术堆栈,包括技术深度探索与动手实验课程,旨在帮助和指导中国开发人员在生产环境中使用云原生技术,并了解其用例和优势。此前,著名社区 Stackoverflow 发布了 2019 年开发者调研报告,报告有近九万人参与,Top 3 最受热爱开发平台是分别是Linux(83.1%)、Docker(77.8%)和Kubernetes(76.8%)。

相关链接:
https://www.tuicool.com/articles/Jfaeqy2
/>
https://github.com/godaddy/kubernetes-external-secrets
/>
https://github.com/AliyunContainerService/ack-kms-plugin
/>
https://mp.weixin.qq.com/s/y2V3PwOK5qbdmjFsuNTGkg

上游重要进展

Kubernetes 项目

  1. [重要性能优化] 2X performance improvement on both required and preferred PodAffinity. (#76243, @Huang-Wei) 这是一个重要的性能优化。这个提交将 PodAffinity 调度的效率实现了两倍的提高。要知道,PodAffinity/Anti-affinity 调度规则是目前 K8s 默认调度器最大的性能瓶颈点,这次修复很值得关注。
  2. [重要安全增强] KEP: Node-Scoped DaemonSet: K8s 项目现在提供一种叫 Node-Scoped DaemonSet。这种 DaemonSet 的独特之处,在于它拥有、并且只能拥有自己所在的节点 kubelet 相同的权限,并且遵循同 kubelet 相同的鉴权流程。这种设计,避免了以往 DaemonSet 权限泛滥的问题(比如:我们现在就可以让 DaemonSet 只能访问到属于该 Node 的 API 资源)。这个特性发布后, DaemonSet 一直以来都 是K8s 集群里最优先被黑客们关照的尴尬局面有望从根本上得到缓解。
  3. [重要功能补丁] KEP: Add kubelet support lxcfs: 一直以来,容器里面通过 /proc 文件系统查看 CPU、内存等信息不准确都是一个让人头疼的问题,而挂载 lxcfs 则是这个问题的最常见解决办法。现在, K8s 上游正在提议将 lxcfs 作为默认支持,如果得以合并的话,那对于开发者和运维人员来说,都是个喜闻乐见的事情。不过,lxcfs 本身是一个需要额外安装的软件,很可能会成为这个阻碍设计的 blocker。

相关链接:
#76243:https://github.com/kubernetes/kubernetes/pull/76243
/>@Huang-Wei:
https://github.com/Huang-Wei
/>
https://github.com/kubernetes/enhancements/pull/944
/>
https://github.com/kubernetes/enhancements/pull/953

Knative 项目

  1. Knative serving API 准备升级到 v1beta1 版本,其目标之一是使用标准的 PodSpec,以便更方便的从 K8s Deployment 迁移过来。这个版本和 v1alpha1 对比主要变更有:去掉了 runLatest,缺省默认就是 runLatest;Release 模式可以通过配置 traffic 实现,可以指定各个版本的流量比例;取消 Manual 模式;提供 revision 生成名字的控制;停用 Serving 内置的 Build。
  2. Triggers don't use Istio VirtualServices:Knative Eventing 原有的实现,依赖于 Istio 的 VirtualService 来重写 Host Header,使得接下来 Broker 可以通过 Host  Header 来识别此 Event 是发给哪个 Trigger 的。而最新的做法,则是通过  URL 来进行区分(比如:http://foo-broker-filter-1da3a.default.svc.cluster.local/my-trigger 代表此事件是发送给 my-trigger 的),从而解除了 Trigger 对 Istio  VirtualService 的依赖。
  3. Remove Istio as a dependency:除了上述解耦之外,Knative Eventing Channel 和 Bus 的绑定目前也是通过 istio 的 VirtualService 实现的。在这个新的实现方案中,Provisioners 直接把  Bus 的 主机名写到 channel 的状态当中,就不再需要 Istio VirtualService 来充当 Proxy 了。这些提交,都在透出这样一个事实:Knative 正在逐步减少对 Istio 的各种依赖,这对于一个真正、适用于更广泛场景的 Serverless 基础设施来说,是非常重要的。

相关链接:
https://docs.google.com/presentation/d/10wuLMFXyol731WKuO5x7lalWrH0A6YVHa4exIERQaQ8/edit#slide=id.p
/>
https://github.com/knative/eventing/issues/918
/>
https://github.com/knative/eventing/issues/294

Istio 项目

  1. [重要安全增强]最近在 Envoy 代理中发现了两个安全漏洞(CVE 2019-9900 和 CVE 2019-9901)。这些漏洞现在已经在 Envoy 版本 1.9.1 中修补,并且相应地嵌入在 Istio 1.1.2 和 Istio 1.0.7 中的  Envoy版本中。由于 Envoy  是Istio 不可分割的一部分,因此建议用户立即更新 Istio 以降低这些漏洞带来的安全风险。
  2. [性能提升] Istio 1.1 中的新增强功能可以提高应用程序性能和服务管理效率,从而实现扩展,Pilot CPU 使用率降低了 90%, 内存使用率降低 50%。业界已有尝试在Kubernetes中使用 Pilot 实现服务的流量管理,对应用服务提供多版本管理、灵活的流量治理策略,以支持多种灰度发布场景。可以参考通过 Istio 管理应用的灰度发布。

相关链接:
https://yq.aliyun.com/articles/667297?source_type=cnvol_422_wenzhang
/>
containerd 项目**

  1. runc v2 shim 支持 cgroup 设置:containerd 目前支持多个容器使用同一个 containerd-shim 来管理 - 一个 Pod 就可以使用一个 containerd-shim 来管理一组容器,减少 containerd-shim 对系统资源的开销。但是目前新的 shim v2 没有提供配置 Cgroup 接口,这个功能会在 1.3 Release 中解决。有了这个能力之后,上层应用就可以将 containerd-shim 资源控制也纳入 Pod 资源管理体系中,严格控制系统服务占用的资源大小。
  2. containerd 插件 ID 管理:containerd 允许开发者将自定义的组件注册到服务里,提供了可插拔的能力。但是当前 containerd 插件的管理是假设 ID 是唯一,这会导致相同 ID 的插件加载结果不可预测。当前该问题还在讨论中,计划在 1.3 Release 中解决。


相关链接:

https://github.com/containerd/containerd/issues/3198
/>
https://github.com/containerd/containerd/pull/3004
/>
https://github.com/containerd/containerd/issues/3210

本周云原生最佳实践


传统富容器运维模式如何云原生化?**

  1. 在很多企业当中长期以来都在使用富容器模式,即:在业务容器里安装 systemd、 sshd、监控进程等系统进程,模拟一个虚拟机的行为。这种运维方式固然方便业务迁入,但是也跟云原生理念中的“不可变基础设施”产生了本质冲突。比如:容器里的内容被操作人员频繁变化给升级、发布带来了众多运维隐患;富容器模式导致开发人员其实并不了解容器概念,在容器里随机位置写日志甚至用户数据等高风险的行为屡见不鲜。
  2. 来自阿里巴巴“全站云化”的实践:
  • 将富容器容器运行时替换为支持 CRI 体系的标准容器运行时比如 containerd 等。目前阿里已经将 PouchContainer 全面升级为 containerd 发行版。
  • 把富容器里面的耦合在一起进程、服务进行拆分,变成一个 Pod 里的多个容器,下面是“全站云化”采用的拆分方法:(1)  业务容器:运行业务主进程,允许 exec 方式进入;(2)  运维 Sidecar 容器:日志收集、debugger、运维辅助进程等 ;(3)  业务辅助容器:Service Mesh 的 agent。

**

开源项目推荐

  1. 本周我们向您推荐 SPIFFE 项目。SPIFFE,从运维人员的第一感觉而言,是解决证书下发问题的。以往的安全体系更注重自然人的身份认证,而在 SPIFFE 里面所有的运行实体都有身份。一个案例就是 K8s 上的每个 pod 都配置相应的身份,对于多云和混合云的安全角度讲,SPIFFE 的好处在于不被供应商的安全认证体系绑定,可以达到跨云/跨域的身份认证,从而确保安全。下面是我们搜集的一些关于 SPIFFE 的不错的公开资料,有兴趣可以去了解:

    • 项目的主要发起人 Evan 的演讲
    • SPIRE 是 SPIFFE 的实现,和 Service Mesh 结合详见这篇文章
    • SPIRE 的零信任安全机制


相关链接:

https://spiffe.io/
/>
https://v.qq.com/x/page/t07113umnwq.html
/>
https://segmentfault.com/a/1190000018432444
/>
https://www.aqniu.com/learn/39145.html

本周阅读推荐

  1. Knative:精简代码之道,作者 Brian McClain | 译者 孙海洲。这篇文章用循序渐进的例子对“什么是 Knative”做出了很好的回答。如果你现在对 Knative 的认识还停留在三张分别叫做Build, Serving 和 Eventing的插图的话,那可能阅读一下这篇文章会让你对它们的理解更加形象。
  2. Spark in action on Kubernetes - 存储篇,by Alibaba 莫源。存储永远是大数据计算的核心之一,随着新计算场景的不断涌现和硬件技术的飞速发展,存储的适配关系到大规模计算的成本、性能、稳定性等核心竞争要素。本文继上面分析K8s中的Spark Operator之后,从硬件限制、计算成本和存储成本几个角度,讨论了云原生时代来临后存储如何解决成本低、存得多、读写快这几个挑战,详细介绍了阿里云上相关产品在不同场景下的表现,并总结了不同场景下适用的存储解决方案以及选择的原因。如果你是K8s和大数据方面的开发者和使用者,这是一篇你不应该错过的博客,可以快速的帮你梳理当前技术下存储的场景和典型解决方案。


相关链接:

http://www.servicemesher.com/blog/knative-whittling-down-the-code/
/>
https://yq.aliyun.com/articles/695315?source_type=cnvol_422_wenzhang

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
6月前
|
自然语言处理 监控 Cloud Native
对话阿里云云原生产品负责人李国强:推进可观测产品与OpenTelemetry开源生态全面融合
阿里云宣布多款可观测产品全面升级,其中,应用实时监控服务 ARMS 在业内率先推进了与 OpenTelemetry 开源生态的全面融合,极大丰富了可观测的数据类型及规模,大幅增强了 ARMS 核心能力。本次阿里云 ARMS 产品全面升级的背景是什么?为什么会产生围绕 OpenTelemetry 进行产品演进的核心策略?在云原生、大模型等新型应用架构类型层出不穷的今天,又将如何为企业解决新的挑战?阿里云云原生应用平台产品负责人李国强接受采访解答了这些疑问,点击本文走进全新升级的阿里云可观测产品。
42012 13
|
4月前
|
消息中间件 监控 Cloud Native
阿里云云原生生态强调事件驱动架构(EDA),借助EventBridge和EventMesh实现微服务间的高效协作。
【7月更文挑战第3天】阿里云云原生生态强调事件驱动架构(EDA),借助EventBridge和EventMesh实现微服务间的高效协作。EDA提升系统弹性和可维护性,促进业务敏捷性。实施路径包括事件模型设计、集成阿里云服务、开发事件处理器和监控优化。通过阿里云服务,开发者能轻松构建响应式、可扩展的云原生应用,加速创新并驱动数字化转型。
89 0
|
5月前
|
运维 Kubernetes Cloud Native
Canonical 开源 MicroK8 | 云原生生态周报 Vol. 25
Canonical 开源 MicroK8 | 云原生生态周报 Vol. 25
|
6月前
|
消息中间件 监控 Cloud Native
【阿里云云原生专栏】事件驱动架构在阿里云云原生生态中的角色与实施路径
【5月更文挑战第23天】本文探讨了事件驱动架构在阿里云云原生生态中的关键作用,强调其在微服务协同和应用创新中的效率提升。阿里云提供了EventBridge和EventMesh等服务支持EDA,其中EventBridge作为事件中枢,实现跨平台事件传递,而EventMesh提供高性能事件处理。通过事件模型设计、服务集成、开发处理器和监控优化四个步骤,用户可在阿里云上实施事件驱动架构,构建敏捷响应的云原生应用。随着云原生技术发展,EDA将成为企业数字化转型的重要推动力。
113 0
|
6月前
|
运维 Cloud Native 云计算
云原生技术:构建灵活高效的应用生态
随着云计算技术的不断发展,云原生技术作为一种全新的应用开发和部署模式,正逐渐成为业界关注的焦点。本文将介绍云原生技术的基本概念、优势以及在构建灵活高效的应用生态方面的应用实践,以期为读者提供全面了解云原生技术的视角。
|
6月前
|
供应链 Cloud Native 安全
云原生时代下,操作系统生态的挑战与机遇
人工智能、大数据、云计算等新技术的发展也对操作系统的灵活度和智能化提出新的要求。
|
6月前
|
Cloud Native 数据库 云计算
从传统云架构到云原生生态体系架构的演进
从传统云架构到云原生生态体系架构的演进
276 0
|
Kubernetes 监控 Cloud Native
提升效率!云原生生态从业人员不可或缺的工具集合!
提升效率!云原生生态从业人员不可或缺的工具集合!
74 0
|
存储 运维 NoSQL
阿里云计算巢加速器:让优秀的软件生于云、长于云—入选企业深度访谈—NebulaGraph:打造灵活弹性的云原生图数据库,与阿里云计算巢共同拥抱开放生态
阿里云计算巢加速器:让优秀的软件生于云、长于云—入选企业深度访谈—NebulaGraph:打造灵活弹性的云原生图数据库,与阿里云计算巢共同拥抱开放生态
857 1
|
存储 边缘计算 运维
CNStack 云服务&云组件:打造丰富的云原生技术中台生态
CNStack 云服务&云组件:打造丰富的云原生技术中台生态
CNStack 云服务&云组件:打造丰富的云原生技术中台生态