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

    xiaoxiao2022-07-03  93

    业界要闻

    1 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上进行了发布。

    2 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如果你的在被影响范围内,请尽快进行修复,,参见详情

    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解读文章。

    开源项目推荐

    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 走向 K8s云原生生态周报 Vol. 3 | Java 8 ️️ Docker 云原生生态周报 Vol. 2 | Istio中Envoy 代理漏洞已修复 云原生生态周报 Vol. 1 | 谷歌云发布Cloud Run


    欢迎关注阿里云容器服务(ACK)提供高性能可伸缩的容器应用管理能力,支持企业级 Kubernetes 容器化应用的全生命周期管理。容器服务 Kubernetes 版简化集群的搭建和扩容等工作,整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳的 Kubernetes 容器化应用运行环境。https://www.aliyun.com/product/kubernetes?source_type=cnvol_520_wenzhang

    原文链接 

    最新回复(0)