按照發布計劃，Kubernetes 1.7版本將於6月28日（週三）正式釋出。本次版本更新共包含26個Feature，其中Alpha版本16個，Beta版本6個，Stable版本4個。

1、Alpha Features

• Kubernetes應該更容易新增策略控制

場景：

• 作為一名Kubernetes系統管理員，需要新增一些個人的安全策略來控制叢集資訊的顯示。
• 作為一名Kubernetes開發者，在核心程式碼倉庫外開發某種新特性，並以一種解耦、去中心化的方式將其合併到Pod生命週期中。

我們計劃為Kubernetes新增一項功能，比如向遠端伺服器發出請求執行檢查，以及向資源對像新增一個“initializer”，允許Pod在被別的客戶端發現之前執行某些操作。最後我們還希望找到一個可用來動態選擇執行系統配置的方法，來選擇新增或移除這些整合。

在之前的雜湊演算法（adler）中確實存在雜湊碰撞。考慮過fnv演算法，更穩定但更慢。另外，對資源物件進行雜湊會受到API版本的影響，同一個ReplicaSet的名字在不同的Kubernetes版本里會不一樣。

處於上面的考慮，決定在Deployment的Status結構裡引入新的域：collisionCount，在發生雜湊碰撞時計算一個唯一的雜湊值。Deployment Controller會根據PodTemplate和CollisionCount一起計算雜湊值，並將計算結果用於ReplicaSet命名等。

• StatefulSets通過Burst模式支援更快的擴充套件

現在的StatefulSets實現中，只有當前序Pod都執行起來才能建立後面的Pod。雖然一個Pod掛掉不會死鎖，但如果是Unhealthy狀態會卡住這個過程。尤其是，如果pod-0和pod-4都掛了，當前的實現會試著重啟pod-0，而pod-4只有pod-0起來後才能啟動。這樣的表現很安全。對於另外一些有狀態應用，不需要考慮已經部署的Pod的順序，那麼上面的規則會帶來一些約束，造成不必要的不可用現象。所以需要指定一個註解(annotation)來與StatefulSetController進行通訊，讓它可以同時多個Pod。

• Kubelet伺服器TLS證書迴圈

• 在etcd里加密Secrets

現如今Secret型別的物件按照base64的編碼後儲存在etcd叢集裡，通過給這些secrets進一步加密可以讓Kubernetes變得更加安全。在Secret被寫入etcd和被讀取之前，它的資料將被加密，加密器可以根據使用者需求進行調整，並提供一個抽象的加密介面，允許接入多種加密方法。

一般而言，更願意選擇將儲存etcd資料的儲存卷全盤加密。這個特性的場景包括對etcd API的非法訪問等。

• HPA狀態

本特性將為HPA的Status新增用來描述某一時刻HPA狀態的欄位HorizontalPodAutoscalerCondition，定義為：

type HorizontalPodAutoscalerCondition struct {
    // Type聲明瞭當前狀態
    Type HorizontalPodAutoScalerConditionType
    // Status是該狀態的“狀態”，True，False，Unknown
    Status ConditionStatus
    // LastTransitionTime是最後一次狀態遷移的時間
    LastTransitionTime metav1.Time
    // Reason是最後一次狀態遷移的原因
    Reason string
    // Message是人類可讀的狀態遷移細節
    Message string
}

• Kubelet客戶端TLS證書迴圈

• 支援多種雲服務商

為了支援可插拔式架構，會引入一個名為cloud-controller-manager的二進位制程式。

這樣做的好處是：

• 使對於用到kubelet/kcm時需要一個cloud config選項的雲服務商的配置更加簡單，比如Azure。簡化啟動，並且讓kubeadm減少承擔處理這些選項的功能。
• 按需啟用。比如使用者希望執行他們自己的Overlay網路，仍使用提供的L4負載均衡器。這在現在是做不到的。
• 減少Kubernetes核心倉庫的負擔，提高雲服務商相關功能的迭代。

• Metrics伺服器

提供對於Pod和Nodes使用資源的指標，用於HPA或者排程，以及自定義指標、kubectl top命令、Kubernetes Dashboard等場景。

比較有挑戰的是，計劃每個pod/node收集10個指標，而Kubernetes 1.6可以支援到5000個節點，每個節點30個Pod，那麼在1分鐘內平均每秒要採集25000個指標，後端的etcd無法承受這麼大的負載。所以引入Metrics 伺服器將它們存到記憶體裡。

• 容器執行時介面(CRI)整合

主要為了依據容器執行時介面（CRI）將containerd整合到Kubelet裡。Containerd是用來管理容器生命週期的最小實現，包括容器執行、管理和映象分發等。這樣的好處是：

• 穩定性：Containerd更新慢，相對穩定
• 相容性：Containerd與Kubernetes需求吻合
• 效能：比Docker消耗更少的資源、減少了一層技術棧
• 基金：CNCF

• CRI驗證測試套件

這是用來驗證Kubelet 執行時介面的命令列工具。

• Scheduler擴充套件的方法繫結

• 本地短時儲存支援

• 增強CRI

為CRI新增獲取容器狀態統計資訊的功能。

• 本地持久儲存支援

2、Beta Features

• 自定義資源定義

將ThirdPartyResource遷移到新的API組，以配合對extensions組的棄用和新增一些新的基礎特性。在extensions/v1beta1現存的TPR已被棄用，但為了便於使用者遷移，仍然活躍。在理想的情況下，將在一個獨立的API Server中實現TPR，然後通過API Aggregation合併到kube-apiserver中。其他更新包括對TPR命名規範等。

• API 聚合

這個特性的主要目的是將單體的API Server劃分為多個聚合的Server。每個人都可以編寫自己的Server然後將API進行聚合。叢集管理員應該可以在執行時啟動一些聚合伺服器並暴露新的API介面，實現無縫擴充套件。這樣做可以：

• 提高擴充套件性
• 緩解新API在Kubernetes核心團隊程式碼Review時的阻塞情況
• 可以用來實驗測試性的API
• 保證新的API符合Kubernetes約定

• 為PodDisruptionBudget新增MaxUnavailable

• 有狀態應用的升級

實現了對StatefulSet的滾動升級，以及它的Controller History，並使它的狀態與DaemonSet和ReplicaSet的相一致。升級支援的策略有：

• RollingUpdate：升級改動會應用到StatefulSet的全部Pod，過程滿足StatefulSet的一些約束
• Partitioned：升級改動只會應用到StatefulSet的一部分Pod，適用於Canary釋出
• OnDelete：觸發一個延遲表現，當Pod被手動刪除時會重新建立，禁用版本追蹤和按需滾動重啟。

實現DaemonSet的歷史和回滾：

• 使用PodTemplate來儲存DaemonSet歷史
• 使用PodTemplateGeneration同時標識Pod和PodTemplate，因此DaemonSet Controller可以將Pod和對應的PodTemplate進行對映
• 每個PodTemlate是DaemonSet Template + Annotation + templateGeneration的快照。一個DaemonSet擁有多個PodTemplate
• DaemonSet歷史的預設清理策略為2。只有沒有Pods對映到PodTemplate的才會被清理。
• 在服務端實現回滾，利用RollbackConfig，就像Deployment一樣

• 限制Node訪問API

添加了一個新的Node授權模式，以及NodeRestriction管理外掛，用於關聯、限制Node對某些API的訪問，這樣它們只能修改自己的Node API物件，以及在它們之上的Pod物件，還有接收這些Pod上的Secrets和Configmaps

3、Stable Features

• GA版本網路策略

NetworkPolicy資源更新為GA版本。

NetworkPolicy實現了對Ingress選擇Pods的策略。NetworkPolicy的Spec欄位定義如下：

type NetworkPolicySpec strut {
    // 為該NetworkPolicy選擇對應的Pods，按照下面的IngressRule陣列進行配置
    PodSelector unversioned.LabelSelector `json:"podSelector"`
    // 為選中的Pods設定規則，NetworkPolicyIngressRule描述了流量的埠和源頭
    // 符合這兩點的流量被認為匹配這個規則
    Ingress []NetworkPolicyIngressRule `json:"ingress,omitempty"`
}

• GCP 為虛擬IP保留源IP

源IP保留——改變雲上的負載均衡策略為健康檢查，並且只對含有該服務Pods的節點響應。原來的實現裡，雲上的負載均衡器會把流量分發到Kubernetes的各個節點，然後等量地交給該服務的後端Pod進行處理。因為DNAT要求重定向流量到它的最終目的地，所以對每個會話返回的路徑必須匹配包含相同節點的反向路徑。為了實現它， 這些節點會使用SNAT，用它自己的IP替換掉源IP。這樣導致服務的endpoints發現會話來自一個叢集本地的IP地址，而外部的源IP就丟失了。在多數場景裡，外部的IP必須保留起來。

• 雲服務商儲存Metrics

Kubernetes 應該提供例如雲服務商API的計數和延遲率等Metrics。在理想的情況下，希望能獲取到對所有云服務商和所有Kubernetes API呼叫的Metrics。本特性只侷限在GCE和AWS。這樣做是為了:

• 叢集管理員應該監控Kubernetes對雲API的使用情況，以輔助排查那些破壞掉API配額的場景中的問題
• 叢集管理員應該可以監控Kubernetes依賴的雲API的健康情況和延遲

• StorageOS 卷外掛

StorageOS卷外掛支援：

• 動態提供Storage Classes
• PV和PVC

歡迎關注譯者微信公眾號