业界要闻

1、 近日，全球知名市场调研机构Forrester发布首个企业级公共云容器平台报告 。 其中， 阿里云容器服务的市场表现全球前三、中国第一，同时创造中国企业最好成绩，进入强劲表现者象限 。报告显示，阿里云容器服务市场表现为中国第一，与谷歌云并列全球第三。 Forrester 分析师认为，“阿里云容器服务提供了广泛的开发和应用服务支持能力，并且具备丰富的市场生态和合作伙伴体系，是企业在中国寻求完备容器云服务能力的最佳选择。

2、 Virtual Kubelet 开源项目 发布第一个可商用1.0版本 ，本次发布的主要特点包括：

• API将趋于稳定
• 发布版不再提供二进制文件，用户可以自定义发行版。
• 提供测试用的CLI
• 非通用版的 Charts 也将从库中移除

上游重要进展

Kubernetes 项目
1 Kubernetes 设计增强提议（KEP）：

• Even Pods Spreading ，这个设计提议通过 MaxSkew 算法来尽量均匀的调度 Pod 到目的节点，相关的PR（#77760、# 77828、# 79062、#79063）。
• 增强 DaemonSet 灰度能力 ： 新增SurgingRollingUpdate，并在RollingUpdate和SurgingRollingUpdate中增加灰度升级的能力。

2 Scheduler Framework 特性添加了Filter插件，Filter插件用于过滤掉无法运行Pod的节点，可将所有现有的predicates 函数转换为Filter插件。 https://github.com/kubernetes/kubernetes/pull/78477

Knative 项目

1. Importers 中事件类型命名空间该如何设置？ GitHub社区关于该问题展开了讨论，首先关于Importer中 功能定位进行了确认。包括

• 针对事件生产者进行事件订阅及管理
• 从事件生产者获取事件信息
• 将事件转化成标准的CloudEvent
• 将事件发送到相应的Sink

其中针对将事件转换成CloudEvent时，事件的类型的命名空间前缀需要进行修改。以githhub事件为例，当前转换成CE(CloudEvent)时，设置为dev.knative.source.github. , 是否应该以事件生产者作为命名空间com.github. ，参考CloudEvent给出的映射处理： https://github.com/cloudevents/spec/blob/master/adapters/github.md 。

• CloudEvent事件属性过滤 。针对Cloud Event中除了data之外的其它属性，都应该可以通过Trigger进行过滤。
• 修改事件注册 Registry : 通过修改eventtypes ，支持发现Importer事件类型，增强事件注册Registry机制。该方案进行了进一步的讨论，包括通过eventTypesSupported替换eventTypes，这样表述更能让end-user清晰明白。
• Make it easier to consume events directly from specific sources 。针对事件源，优化用户使用场景本周确定了Decision，预计会在 0.9 之后实现。大致方案是用户可以直接在Eventype以及Trigger中指定事件源进行创建，参考 Demo

Istio 项目

Istio 发布了 1.2.x 和1.1.x 系列的最新版本1.2.3和1.1.12 ，增强了在虚拟服务中定义基于正则表达式的HTTP URI匹配时支持大小写的能力，这样用户可以定义出更加灵活的匹配路由规则。此外，Istio在多集群管理方面也提供了3种不同方式：多个控制平面、同VPC网络下的单控制平面与多个VPC网络下的单控制平面。值得注意的是，这几种方式并不是互斥的，在一个大型多集群网格环境下，既可以多个集群共享一个控制平面，同时也可以与其他集群保持独立的控制平面。这种场景在混合云多云环境下比较常见，例如在阿里云ACK容器服务控制台中可以接入外部已有集群，并与ACK集群形成一个服务网格。

开源项目推荐

1. IBM推出的Kabanero项目 ：它 将基础开源技术整合到了一个微服务的框架中，包括Knative、Istio与Tekton，还有Appsody、Codewind和Razee，帮助用户构建、部署和管理基于 Kubernetes 的应用程序的生命周期。快速创建云原生的 App，目前支持多种语言。包括nodeJS，Java，Swift等。[]( https://github.com/kabanero-io)
2. Kyverno，K8s Admission Controller 扩展项目 ： 它可以设置各种policy作为自定义admission的补充，可以约束用户的某些行为，例如必设置资源时必须设置limit和request，设置镜像版本时，必须按照指定的拉取策略设置等等。[]( https://github.com/nirmata/kyverno#1-validating-resources)
3. [k6](https://k6.io] ：k6 是一个以开发人员为中心的开源负载和性能回归测试工具，用于测试云原生后端基础架构的性能：API、微服务、无服务器、容器和网站。它可以很好地集成到开发工作流程和 CI/CD 自动化管道中。

本周阅读推荐

1. 在 Kubernetes 上使用 Jenkins ( https://mp.weixin.qq.com/s/-uCMaAr38B0Ge-cn5WQcVA)  本文描述了基于Kubernetes + Jenkins的一种DevOps的解决方案。
2. Cluster Monitoring With Prometheus Operator   https://containerjournal.com/2019/07/29/cluster-monitoring-with-prometheus-operator/  本文简要描述了Prometheus Operator 在Kubernetes的无缝安装和其作用、工作原理以及帮助监控通过 Prometheus Operator发挥作用以发现目标并削减冗余指标。
3. 基于边缘容器的阿里云CDN云原生实践  , 阿里云容器服务于8月1号正式公测“边缘Kubernetes集群托管”服务，该服务面向CDN、IoT等诸多边缘计算场景，提供云边一体的云原生体验。CDN场景中不仅规模比较大，而且也能锤炼整个边缘集群的稳定性和大规模的服务能力。
4. Knative 基本功能深入剖析：Knative Serving 自动扩缩容 Autoscaler  。Knative Serving 默在认情况下，提供了开箱即用的快速、基于请求的自动扩缩容功能 - Knative Pod Autoscaler（KPA）。本文旨在分享如何在 Knative 中玩转 Autoscaler。

本文作者：木环

原文链接

 本文为云栖社区原创内容，未经允许不得转载。