作者 | 孫健波、汪萌海、陳有坤、李鵬

<a name="Cjuu6" rel="nofollow"></a>
## 業界要聞

1. [CNCF 宣佈 TUF 畢業](https://www.cncf.io/announcement/2019/12/18/cloud-native-computing-foundation-announces-tuf-graduation/)

CNCF 宣佈 TUF（The update Framework）專案正式畢業，成為繼 Kubernetes、Premetheus、Envoy、CoreDNS、containerd、Fluentd Jaeger 以及 Vitess 之後，第九個正式畢業的專案。TUF 是一項用於保護軟體更新系統的開源安全技術，也是從雲原生計算基金會畢業的第一個以規範與安全性為重點的專案。與此同時，TUF 還是首個源自高校的 CNCF 畢業專案。

2. [Istio 釋出安全公告](https://istio.io/news/security/istio-security-2019-007/)

- CVE-2019-18801：該漏洞透過向下遊傳送 HTTP/2 大 header 請求影響 Envoy 的 HTTP/1 編解碼器，利用此漏洞可能導致拒絕服務、許可權逃逸或資訊洩露；

- CVE-2019-18802：HTTP/1 編解碼器沒有修剪掉 header 值之後的空格，使攻擊者可以繞開 Istio 的策略，最終導致資訊洩露或特權升級；

- CVE-2019-18838：收到不帶 "Host" header HTTP 請求後， Envoy 路由管理器會由於空指標導致 Envoy 程式異常終止。

<br>**解決方案**

- 對於 Istio 1.2.x 版本：升級到 Istio 1.2.10 或以上；
- 對於 Istio 1.3.x 版本：升級到 Istio 1.3.6 或以上；
- 對於 Istio 1.4.x 版本：升級到 Istio 1.4.2 或以上。

3. [2020 年三大 Service Mesh 發展趨勢](https://thenewstack.io/the-top-3-service-mesh-developments-in-2020/)

- 隨著 Kubernetes 的愈發普及和標準化，應用場景越來越複雜，服務網格的需求會快速增加；

- Istio 的先發優勢會越來越明顯，以至於它很難被擊敗，因為越來越多的軟體供應商會提供 Istio 的解決方案；

- 更多的使用場景會出現，目前服務網格的使用場景主要在 "mTLS（統一鑑權解決方案）"，“應用可觀測性解決方案”，“流量管理解決方案”，2020 年會出現服務網格技術的殺手級解決方案。

<a name="5Knjw" rel="nofollow"></a>
## 上游重要進展
<a name="8rEZG" rel="nofollow"></a>
### Kubenetes

1. [add KEP: Node Maintenance Lease](https://github.com/kubernetes/enhancements/pull/1411)

增加用於 Node 協作的租約，該提案主要解決的是多個元件對 Node 均有操作，加鎖獨佔的問題，比如線上 debug Node 問題的時候，又比如 Node 更新系統起作用的時候，不希望 Node 快照備份系統起作用。

2. [K8s 排程器升級計劃進入到階段二](https://lwn.net/Articles/806896/)

- 一階段是構建了新的排程框架，目標是把 scheduler 變成一個執行不同擴充套件外掛的 callback 的引擎，可以註冊 callback 函式，把一系列排程計算、預測相關的函式作為 plugin；
- [二階段](https://github.com/kubernetes/kubernetes/issues/85822)的主要目標是把原先內建在 K8s scheduler 裡面的預測和排程演算法移入對應的 plugin 中透過排程框架呼叫，許多 PR 圍繞該目標在展開。

3. [K8s 社群子專案 rktlet 正式被歸檔](https://github.com/kubernetes/community/pull/4336)

rktlet 是基於容器執行時 [rkt 專案](https://github.com/rkt/rkt)的 CRI（Container Runtime Interface） 實現，類似 kubelet，隨著 rkt 專案退出 CNCF，rktlet 也無人維護，如今正式被移出。

<a name="8z9xN" rel="nofollow"></a>
### Knative

1. [Knative serving PodSpec 功能性](https://docs.google.com/document/d/1DY5t7LqGPOq5Jw5AixSgJY8S2VuQnTGzRpV6apY_nAI)

在 Knative 中，RevisionTemplateSpec 像 PodSpec 的一個子集，只實現了部分功能。為了保持 Knative 的簡易性，哪些欄位需要加，哪些欄位不需要加，文件中列出了一些條件。另外針對運維角色，有些欄位不是面向開發的，但 K8s 都把欄位暴露出來了，K8s 這樣做不意味著 Knative 也需要這樣做，可以把它作為一個 Configmap 的配置值或者新增運維的 CRD。

2. [關於事件域 Eventing domains](https://docs.google.com/document/d/10S2MnYiy8wNBO8fXdtAviX0GvJXeoFqNOHG6Qh1-EAs/edit)

在事件系統中，事件生產者和消費者通常不直接通訊。在許多情況下，都涉及充當事件匯流排的訊息中介軟體。透過這種方式，可以對事件進行集中管理，消費者和生產者可以發出和訂閱哪些內容，並且可以設定過濾器或策略。因此，引入了事件域的定義。

<a name="p7mlY" rel="nofollow"></a>
### Istio

1. [社群在討論如何緩解 Istio CNI 競爭問題](https://docs.google.com/document/d/1SQzrFxtcn3o_79OtJYbSHMPuqZNhR3EaEhbkpBVMXAw/edit#heading=h.24fawmrtxcw1)

Istio CNI 競爭問題是指在透過使用 Istio CNI 外掛配置容器網路安裝 iptables 規則時，可能會遇到應用程式的 pod 在 Istio CNI 配置完成之前就啟動，導致出現沒有配置 iptables 規則的應用程式 pod 出現，這會導致安全問題，因為可以繞開所有的 Istio 策略檢查。

社群討論了可能在 Istio1.5 中提供的短期方案，並提出長期方案是希望 K8s 提供標準方法：在節點排程 Pod 之前，確保關鍵守護程式已經準備好；如果關鍵守護程式失敗，請汙染節點。後續將與 K8s 社群繼續討論。

<a name="E07sH" rel="nofollow"></a>
## 開源專案推薦

1. [OAM Go SDK](https://github.com/oam-dev/oam-go-sdk)

基於OAM（開放應用模型）的 Go 語言 SDK，SDK 中包含了 OAM Spec 的解析和 Controller 框架，可以快速構建 OAM 的實現，快速對接標準應用模型。

2. [Vault](https://github.com/hashicorp/vault)

Vault 是 HashiCorp公司（旗下還有Vagrant，Terraform，Consul 等知名產品）維護的開源軟體，它的設計思想基於雲原生背景下動態基礎設施的特點，在雲上的不同網路層以及不同的服務之間已經很難找到傳統的信任邊界，服務之間更加強調以身份（identity）為核心的認證和訪問控制，而不是像傳統靜態基礎設施中以 IP、主機地址作為信任憑證（[與 K8s 對接](https://www.vaultproject.io/docs/platform/k8s/index.html)）。

3. [kube-score](https://github.com/zegl/kube-score)

kube-score 是 K8s 物件靜態檢查工具，透過分析 K8s 物件的 Yaml 檔案做一些推薦，以提升可靠性和安全性。

<a name="zQtsP" rel="nofollow"></a>
## 本週閱讀推薦

1. [《The Open Application Model from Alibaba's Perspective》](https://www.infoq.com/articles/oam-alibaba/)

InfoQ 國際總站發表文章《阿里巴巴視角下的開放應用模型》，詳細講述了 OAM 的由來以及阿里巴巴在 K8s 應用管理上的實踐。

2. [《Dynamic Database Credentials with Vault and Kubernetes》](https://www.hashicorp.com/blog/dynamic-database-credentials-with-vault-and-kubernetes/)

使用 Vault 在 Kubernetes 體系中提供動態資料庫鑑權資訊，文中針對雲原生場景下 Pod 生命週期短、變化快等問題，Vault 提供了一系列 Policy 解決動態鑑權資訊注入的問題。

3. [《Debugging and Monitoring DNS issues in Kubernetes》](https://cilium.io/blog/2019/12/18/how-to-debug-dns-issues-in-k8s/)

在 Kubernetes 上 debug DNS 問題的指南。

4. [《將 Sidecar 容器帶入新的階段 | KubeCon NA 2019》](https://mp.weixin.qq.com/s/dGR3Y1-iWFNWUaTY-EaOtQ)

本文介紹了螞蟻金服和阿里巴巴集團場景下對 Sidecar 容器的各種使用方式。

5. [《容器十年：隔離性、效率與相容性》](https://mp.weixin.qq.com/s/fJsBEXUqcHU0rOsSQIuvXg)

從 2008 年基於核心 cgroup 的 LXC 誕生至今，現代 Linux 的容器化已逾 10 年，先後有基於 cgroup/namespace 的程式隔離容器技術、基於 CPU 硬體指令集的虛擬化技術，以及透過重寫核心功能實現的使用者空間核心容器技術紛紛登場，各有千秋。

6. [《StackRox 2020 預測：從 Kubernetes 到 DevOps》](https://segmentfault.com/a/1190000021371249)

StackRox 的聯合創始人，技術長Ali Golshan 對 2020 年技術發展做了一些預測，這些預測涉及 Kubernetes 和服務網格技術的增長。

>“[阿里巴巴雲原生](https://developer.aliyun.com/group/alisoftwaretech/)關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，做最懂雲原生開發者的技術圈。”

CNCF 宣佈 TUF 畢業 | 雲原生生態週報 Vol. 33

相關文章