雲原生生態週報 Vol. 11 | K8s 1.16 早知道
業界要聞
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 上，它具有怎樣的協議規範，如何