業界要聞
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 年的趨勢預測，主要包括了三個重點方向：
（a） Serverless 架構
（b） 混合雲架構
（c） 端到端的 CI/CD 方案
Helm 是目前雲原生技術體系中進行應用管理最被廣泛使用的開源項目，沒有之一。根據 CNCF 剛剛發布的 KubeCon EU 2019 的總結報告，Kubernetes（k8s），Prometheus 和 Helm 這三個項目，再次蟬聯 KubeCon 上最被關注的開源項目前三名。如果您還不了解 Helm V3，可以移步《深度解讀Helm 3: 猶抱琵琶半遮面》
我們知道 Kubernetes 中關於使用存儲卷的機制有 In-Tree、Flexvolume 模式，那為何還要提出 CSI 方式呢？CSI 標准使 K8S 和存儲提供者之間將徹底解耦，將存儲的所有的部件作為容器形式運行在 K8S 上，它具有怎樣的協議規范，如何部署及使用呢？