前言

《云原生生态周报》由阿里云容器平台联合蚂蚁金服共同发布，每周一期。众多一线社区专家与您一起“跟踪动态，读懂社区”，分享云原生社区项目进展、活动发布、精选博客等信息。以下是第一期云原生生态周报的内容。

业界要闻

Azure Red Hat OpenShift已经GA。在刚刚结束的Red Hat Summit 2019上，Azure Red Hat OpenShift正式宣布GA，这是一个微软和红帽共同打造的Managed Kubernetes服务：原本的红帽的OpenShift本身就存在on-premise和公有云两个选项，Azure Red Hat OpenShift的出现宣告了一个新的方向，即为公有云厂商提供只在其云平台上运行的Managed Kubernetes服务。RHEL 8同样在Red Hat Summit 2019上进行了发布。
DOCKER IMAGE VULNERABILITY (CVE-2019-5021)：新发现的Docker Image安全漏洞
- 问题：如果你的Container镜像中包括 shadow 或者 linux-pam package并且有以non-root身份运行的service，攻击者只要可以通过任何不安全手段连接系统（who compromised your system via an unrelated security vulnerabillity），或者可以使用shell，那么攻击者就可以获取容器内容的root权限。
- 被影响对象包括Docker image releases (7 March 2019)：edge (20190228 snapshot)、v3.9.2、v3.8.4、v3.7.3、v3.6.5和已经停止维护的v3.5、v3.4和v3.3
- 如果你的在被影响范围内，请尽快进行修复，参见详情
红帽发布Universal Base Image（UBI）。随着RHEL 7，红帽发布了RHEL标准镜像，为客户提供企业级别的容器能力。然而这个标准镜像只能运行在Red Hat的平台之上，意味着你必须是他们的客户。而本次发布的UBI可以叠加在任何OCI兼容的容器之上，无论你是否是付费客户。UBI提供了一些列基础能力，例如基础镜像、集中内置的语言（nodejs, ruby, python, php, perl, etc）、常用的RPM包等等。

上游重要进展

Kubenetes项目

Control Plane的metrics设计趋于稳定，开始考虑添加设计稳定性标注。目前K8s control plane提供的metrics是缺乏稳定性保障的，这个KEP的目的是为metrics中的字段（name、type、label等）提供一种表达机制，来表明这些字段是否可以被可靠的修改。随着目前control plane层的metrics趋于稳定，未来的修改应该谨慎并引入管控机制。具体可以看 Kubernetes Control-Plane Metrics Stability

Knative 项目

knative-eventing 0.6.0 发布，主要特性是：增强易用性，新增Registy，便于事件消费；增强可用性：新增事件跟踪机制以及 Metrics；简化依赖，去掉 Istio 依赖，减少了对 Eventing-Sources 组件的依赖，数据源处理迁移到 Eventing 中。详细说明请见 knative-eventing 0.6.0解读文章
knative-serving 0.6.0 发布，主要特性是：新api模型，移植v1beta1 API到v1alpha1 API，不兼容的部分预计会在0.7.0+实施；优化scale0实现方式，增加ServerlessService（SKS）；集成Auto-TLS；控制器解耦，以便容易替换默认实现。详细说明请见 knative-serving 0.6.0解读文章。 ServerlessService（SKS）的详细介绍请见 SKS解读文章。

更多可参见《Knative Eventing 中如何排查Event事件处理异常》

开源项目推荐

KubeOne: A New Lifecycle Management Tool for HA Kubernetes Clusters。KubeOne是一个帮助你部署、配置、升级高可用K8s集群的工具。以Kubeadm作为底层，KubeOne定义了Kubermatic machine-controller这个Cluster API，方便用户可以以K8s的声明式API方式来管理集群中的worker节点。更多信息可以参考：KubeOne博文和 Github链接
KEDA: a Kubernetes-based Event Driven Autoscaling component。微软推出的基于事件的自动弹性方案。区别于传统反应式的水平弹性方案（例如基于某个metric的变化），很多场景中用事件驱动的方式触发弹性动作是更加可靠的方案。相关博文介绍了KEDA接入的丰富的事件源，包括Kafka, Azure Queues, Azure Service Bus, RabbitMQ, HTTP, and Azure Event Grid / Cloud Events等等。具体可以看 Announcing KEDA博文和 Github链接

本周阅读推荐

etcd 在超大规模数据场景下的性能优化，作者：陈星宇（宇慕）来自阿里巴巴。etcd是一个开源的分布式的kv存储系统, 最近刚被cncf列为沙箱孵化项目。etcd的应用场景很广，很多地方都用到了它，例如kubernetes就用它作为集群内部存储元信息的账本。本篇文章简单介绍了阿里巴巴超大规模集群中对etcd使用的场景也就是优化的背景和优化的必要性。在干活部分，本文从etcd内部存储系统的工作方式开始，详细描述了阿里巴巴超大规模容器调度场景下对etcd进行优化的具体的实现方式，优化后性能提高24倍。总之这是一篇相当硬核的博文，从场景到代码级别的诊断分析应有尽有。更加值得一提的是，本文得到CNCF官方网站的转载。中文版链接；英文版链接
To Multicluster, or Not to Multicluster: Inter-Cluster Communication Using a Service Mesh, by Andrew Jenkins. K8s已经成为容器编排的事实标准。在使用K8s解决了集群内通讯的问题后，我们发现解决集群间通讯似乎需要更多的设计以及难以避免的开销。很多用户的确有多集群的需求，但是在你开始设计多集群方案的时候，你真的了解你对多集群的核心诉求吗？你对多集群的诉求和别人的理解真的一致吗？这篇文章介绍了几种典型的多集群需求（统一管控的多集群 vs 以高可用为目的的多集群 vs 组成复杂业务&集群间密集通讯的多集群），并指出适配这些需求需要的是不同的设计思路。如果你也在考虑多集群的需求，不妨看一看。原文链接
Kubernetes Operating Systems, by Steven Acreman. 从最早的CoreOS开始，随着K8s的蓬勃发展，最近出现了k3os、Talos等与K8s息息相关的操作系统纷纷出现，那么这些操作系统和在基础Linux环境上安装K8s有什么不同？阅读这篇文章可以帮助你梳理一下思路。原文链接
Google Cloud Run详细介绍: 在Cloud Next 2019 大会上，Google 宣布了 Cloud Run，这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 knative 项目，宣称要将 serverless 带入容器世界。

本周报由阿里巴巴容器平台联合蚂蚁金服共同发布

本周作者：临石，敖小剑，陈有坤，元毅，冬岛

责任编辑：木环

前期周报回顾
云原生生态周报 Vol.4：Twitter 从 Mesos 全面转向 Kubernetes
云原生生态周报 Vol. 3：Docker Hub 遭入侵，Java 8 开始提供良好的容器支持
 云原生生态周报 Vol. 2：Godaddy 开源 KES、CNCF 提供免费云原生课程
 云原生生态周报 Vol. 1：Google 发布 Cloud Run，开源项目 Kubecost 让 K8s 花费一目了然

创作场景

云原生生态周报 Vol. 5: etcd 性能知多少