业界要闻
- Twitter 的基础设施将从 Mesos 全面转向 Kubernetes：不久前Twitter 在旧金山总部举行了一次技术发布会，Twitter 计算平台（Twitter Computing Platform）产品与技术负责人正式宣布此消息，同时解读了Twitter决策原因、方案具体技术路径。推荐你来阅读这篇解读文章来知晓一二。Twitter 抛弃 Mesos，全面转向 Kubernetes。
- Microsoft 在 Build 大会上通过开源开发者项目进一步拓展云计算生态。其中最受关注的，包括了 Kubernetes-based Event Driven Autoscaling （KEDA）项目 和引发广泛讨论的 Windows Terminal。
- KEDA 项目，为 Kubernetes 原生的应用自动水平扩展器（HAP）提供了一个对接各种触发源的接口（比如 Kafka 和 RabbitMQ），从而能够通过这些渠道里的信息来触发 K8s 应用的水平扩展，甚至直接驱动 Azure Functions（Azure 的 FaaS 服务是可以直接对接 K8s 的）。在大力投入“云原生”体系之后，Microsoft 坚持通过 K8s 整合自身各种云计算产品的战略，初见成效，这也将是 Knative 项目遭受到的第一个挑战。
- Windows Terminal 项目在给 Windows 带来更原生的 Linux 开发体验的同时，同也宣布了 Microsoft 计划将 Linux 内核插入 Win10 （预计今年 6 月正式发布）的“雄伟计划”。这将意味着，原本“开发在 Mac、部署在云上”的工作方式，将有可能发生重大变革：Microsoft 正在用实际行动尝试连通开发者体验中的最后一公里。
在现今企业服务器OS市场，Windows依然占据半壁*，其市场分额达60%之多，把Windows应用搬站上云不仅仅是基础设施的迁移，更重要的是通过Kubernetes等云原生技术让传统的Windows应用架构体系升级，充分利用云上的弹性、敏捷等能力，实现业务应用的快速迭代和交付。可以参考阿里云专家分享“通过编排模板创建Windows应用”。
上游重要进展
Kubernetes 项目
- K8s 1.15版本发布时间定在 6月17日，性能有望进一步大幅提升。目前，社区已经发布了k8s 1.15.0 alpha.2 预览版本。其中，来自 Google 的工程师与阿里云工程师合作的 Bookmark API （#75474，#74074） 赫然在列。这个更新为 WATCH 操作添加了“书签（Bookmark）”，使得这些海量的 WATCH 操作的建立者在重启之后只需要对“书签”之外的少数历史变化进行追溯。在特定情况下，K8s APIServer 的性能会被提高 40 倍以上。
- KEP：NodeLocalDNS 特性即将 Beta（默认开启），边缘计算场景有望受益。ubernetes提供原生的DNS服务，通常以Deployment的方式部署，所以只会运行在集群的某些节点上。这导致 Pod会经常需要跨节点进行DNS解析，效率很低。在边缘弱网络链接场景下甚至出现 DNS 解析不可用的情况。而该 KEP 则提出在每个节点以Daemonset方式部署本地DNS缓存，是的当前节点上Pod的 DNS 解析都优先走本地的 DNS 缓存。
Knative 项目
- Knative重新审视事件触发源（Channel）的API 语义设计：Knative Eventing项目本周投票确定了为每一个事件触发源（Channel ）定义单独的 CRD 的设计，而不是像现在这样用一个大 Provisioner 来进行描述，计划在0.7版本实现该功能。不难看到，面对 KEDA 的潜在挑战 ，Knative 项目正在重新审视如何通过事件触发源来进一步扩张项目生态。
- Knative 正在开发 Event Registry: 通过 Event Registry，能很方便的获知有哪些事件可以进行消费，这样就可以对这些事件通过 Trigger 进行订阅事件。当前功能目前进展中，该特性计划在0.6版本发布。
Istio/Envoy 项目
- Envoy正打算提供一个DNS filter用于完成DNS名称到集群名的映射。该filter可以通过xDS API来动态配置。实现这个filter需要依赖社区正在做的支持UDP协议的能力。
- Envoy新增TDS协议支持运行时配置某些feature和参数。通过将runtime映射到文件系统的目录树中，以文件的方式的来修改参数。控制平面可通过TDS去控制这些runtime参数。
- Envoy开始制定标准明确什么是稳定的API。目的是为了在今后升级Envoy API的时候可以做到向后兼容，使得控制平面在连接Envoy的时候也可以做到相互兼容。
Containerd 项目
- containerd 通过 fifo 来实现动态接管 containerd-shim 标准输出。但是 containerd-shim 退出之后，containerd 服务端还保留着 fifo 的文件具柄，会导致大量的文件具柄泄漏。目前该问题已经得到修复。
- devicemapper snapshotter 实践优化：containerd 创建 committed devicemapper 的时候，并不会 deactivate 这个 device，这会导致在它之上创建新的 snapshotter 时，需要挂起和恢复动作，这会让镜像下载和创建容器的速度变慢。目前该问题已经得到修复，改善了 devicemapper snapshotter 的性能。
开源项目推荐
本周推荐你关注 Klusterkit 项目。Klusterkit 是一款简化Kubernetes部署的工具，特点如下：
- 支持内网环境下的离线安装；支持多种CNI插件；支持 etcd 的备份和恢复；支持k8s HA部署
-
这个项目目前包含三个工具：
- etcdadm，简化etcd运维；
- nodeadm，支持安装kubeadm的基础依赖；
- cctl，支持对接Kubernetes的cluster api简化k8s集群的HA部署；
c.关于这个 K8s “部署神器”，你还可以阅读这篇介绍参考来做更深入的了解。
本周阅读推荐
- Google Traffic Director详细介绍: Google最近宣布用于服务网格的Traffic Director beta测试版，为VM和容器服务带来全局流量管理。Traffic Director 是托管版的 Service Mesh 控制平面，主要卖点和特色是：对混合云/多云的支持，支持全局负载均衡；支持VM服务，可混合使用虚拟机和容器；整合 serverless 的部分特性，提供基于流量的自动伸缩能力。本文将对 Traffic Director 进行详细介绍和产品分析。
- Knative Tracing 介绍: 微服务架构本身会面临一系列诸如：后台错误原因分析、各个微服务组件的调用情况诊断等。所以需要有一个 Tracing 系统解决这些问题。基于 Serverless 模型来开发一个完整的业务实现，需要分解成多个 Serverless 模块，每个模块单独通过 Knative 的 Serving 部署，这些不同的 Serving 之间需要调用链进行事务的串联。
- 像Google一样构建机器学习系统 - 开发你的机器学习工作流：Google在机器学习工作流平台上的工程经验非常丰富，它的TensorFlow Extended机器学习平台支撑了Google的搜索，翻译，视频等核心业务；更重要的是其对机器学习领域工程效率问题的理解深刻。机器学习工作流是一个任务驱动的流程，同时也是数据驱动的流程，这里涉及到数据的导入和准备，模型训练Checkpoint的导出评估，到最终模型的导出。
名词解释：KEP - Kubernetes Enhancement Proposal， 即 Kubernetes 上游设计文档
本周报由阿里巴巴容器平台联合蚂蚁金服共同发布
本周作者：张磊，徙远，天千，至简，傅伟，敖小剑
责任编辑：木环
前期周报回顾
云原生生态周报 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_513_wenzhang