业界要闻

Pivotal 发布了完全基于 Kubernetes 的 Pivotal Application Service （ PAS ）预览版

这意味着 Pivotal 公司一直以来在持续运作的老牌 PaaS 项目 Cloud Foundry （ CF ）终于得以正式拥抱 Kubernetes。PAS 将 CloudFoundry 的核心控制平面完全移植到了 Kubernetes 之上，从而使得用户可以使用 CF 闻名已久的 cf push APP 命令一键在 Kubernetes 上发布应用；而与此同时，操作人员则可以通过 K8s API 来进行平台层的管理。

Linkerd 2.4 发布：

Linkerd 2.4 发布，此版本增加了流量分割和服务网格接口（ SMI，Service Mesh Interface ）支持； Linkerd 的新流量分割功能，允许用户动态控制服务流量的百分比。这个功能强大的特性，可以通过 Kubernetes 服务之间请求流量的增量转移，实现灰度和蓝绿部署等策略。

上游重要进展

1. Kubernetes 设计增强提议（ KEP ）

（ a ） PVC/PV 克隆在 K8s 1.16 即将 Beta： https://github.com/kubernetes/enhancements/pull/1147
K8s 的 PVC/PVC 已经支持以克隆的形式创建，这使得用户可以一键复制当前的容器应用在使用的整个存储依赖（包括数据）。这个特性在测试、调试、搬迁等很多场景中都有需求。

（ b ） External credential providers： https://github.com/kubernetes/enhancements/pull/1137

k8s client 的认证方式现在只有 kubeconfig 一种。目前上游正在提议支持对接外部鉴权系统，以减少类似证书回滚、证书保存等问题；
支持 bearer tokens ；支持 mTLS ；等其他动态认证方式；
动态认证的配置通过 configmap 下发；其中包括认证系统的配置，工具等；

（ c ） Service Topology: add graduation criteria： https://github.com/kubernetes/enhancements/pull/1132

支持 k8s 服务拓扑感知的流量管理，实现服务的“本地访问”，本地可能包括：同一个 region，同一个 node，同一个 ns 等；
需要支持“本地服务”的健康检查，LB 规则等；考虑增加：PodLocator controller，kube-proxy 支持感知服务的拓扑配置，dns 支持拓扑感知；

2. Kubernetes v1.16.0-alpha.1 发布

其中几个需要重点关注的更新包括：

k8s 原生支持 api 响应压缩；如果 client 请求 Header 中带 Accept-Encoding: gzip，且 response body 大于 128KB，那么客户端会接收到 GZIP 压缩的响应； go client 默认支持，其他语言客户端需要适配；参考(#77449, @smarterclayton)
新增 runtimeclass admission controller，用来给 pod 配置特定 runtime 类型的 overhead，比如 kata 容器和 runc 的 pod overhead 就会差别很大； PodOverhead 在 1.16 中是一个 alpha 特性；参考(#78484, @egernst)

3. knative 项目

（ a ）简化 eventing 的事件消费处理: 社区正在计划简化事件消费处理，Google 正在进行原型的设计，后续会将相关代码进行分享。
（ b ）缩容时可配置自定义策略来选择 pod 缩容：暂定将在 1.0 版本提供 proposal
（ c ）基于 Envoy Filter 的 Knative Activator 方案：Istio Team 最近给 knative 提出的 Knative Activator 新方案，通过在 Ingress Gateway 的 Envoy 中加入一个特殊的 filter，来实现 Activator 的功能。目前正在进行 POC，通过 Mixer Adapter 来实现激活 Autoscaler。

开源项目推荐

1. IBM 开源的 Serverless 方案 -- kabanero：

kabanero 构建在 knative，istio，tekton 之上，提供 build、流量管理、CICD 等能力，同时支持 Eclipse codewind，Eclipse Che 等 IDE 对接；目前主要面向 Java 生态。

2. kyverno，一个 Kubernetes 原生的 Policy Engine 项目：

（ a ） kyverno 作为一个 dynamic admission controller 运行在 k8s 集群中，接受 APIServer 的 Admission WebHook HTTP 回调请求，来匹配类似资源的类型，名称，标签，资源规格等检查策略；

可以看到，相比于 OPA，kyverno 更加轻量级，可以认为只是 K8s 本身的 Policy 能力的一个封装

（ b ）这些检查策略可以通过 kyverno 的自定义资源类型 kyverno.io/v1alpha1 来定义；
（ c ）主要的使用场景是，可以对相同应用在不同部署环境做不同策略的 admission 的 validating 和 mutating

本周阅读推荐

《 KUBERNETES 2020: WHAT ’ S IN STORE FOR NEXT YEAR AND BEYOND?》

知名技术媒体发布了对 Kubernetes 生态在 2020 年的趋势预测，主要包括了三个重点方向：
（ a ） Serverless 架构
（ b ）混合云架构
（ c ）端到端的 CI/CD 方案

《初探云原生应用管理（二）: 为什么你必须尽快转向 Helm v3》

Helm 是目前云原生技术体系中进行应用管理最被广泛使用的开源项目，没有之一。根据 CNCF 刚刚发布的 KubeCon EU 2019 的总结报告，Kubernetes （ k8s ），Prometheus 和 Helm 这三个项目，再次蝉联 KubeCon 上最被关注的开源项目前三名。如果您还不了解 Helm V3，可以移步《深度解读 Helm 3: 犹抱琵琶半遮面》

《阿里云 Kubernetes CSI 实践》

我们知道 Kubernetes 中关于使用存储卷的机制有 In-Tree、Flexvolume 模式，那为何还要提出 CSI 方式呢？ CSI 标准使 K8S 和存储提供者之间将彻底解耦，将存储的所有的部件作为容器形式运行在 K8S 上，它具有怎样的协议规范，如何部署及使用呢？

云原生生态周报 Vol. 11 | K8s 1.16 早知道