簡介： OpenKruise 是阿里雲開源的雲原生應用自動化管理套件，也是當前託管在 Cloud Native Computing Foundation （CNCF） 下的 Sandbox 專案。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，是阿里內部生產環境大規模應用的基於 Kubernetes 之上的標準擴充套件元件，也是緊貼上游社群標準、適應網際網路規模化場景的技術理念與最佳實踐。
前言
OpenKruise 是阿里雲開源的雲原生應用自動化管理套件，也是當前託管在 Cloud Native Computing Foundation （CNCF） 下的 Sandbox 專案。它來自阿里巴巴多年來容器化、雲原生的技術沉澱，是阿里內部生產環境大規模應用的基於 Kubernetes 之上的標準擴充套件元件，也是緊貼上游社群標準、適應網際網路規模化場景的技術理念與最佳實踐。
OpenKruise 在 2021 年 3 月 4 日釋出了最新的 v0。8。0版本（ChangeLog），其中增強了 SidecarSet 的能力，特別是對日誌管理類 Sidecar 有了更加完善的支援。
背景
Sidecar 是雲原生中一種非常重要的容器設計模式，它將輔助能力從主容器中剝離出來成為單獨的 sidecar 容器。在微服務架構中，通常也使用 sidecar 模式將微服務中的配置管理、服務發現、路由、熔斷等通用能力從主程式中剝離出來，從而極大降低了微服務架構中的複雜性。隨著 Service Mesh 的逐步風靡，sidecar 模式也日益深入人心，在阿里巴巴集團內部也大量使用 sidecar 模式來管理諸如運維、安全、訊息中介軟體等通用元件。
在 Kubernetes 叢集中，Pod 不僅可以實現主容器與 sidecar 容器的構建，同時提供了許多功能強大的 workload（例如：deployment、statefulset）來對 Pod 進行管理、升級。但是隨著 Kubernetes 叢集上的業務日益增多，sidecar 容器的種類與規模也隨之日益龐大，對線上 sidecar 容器的管理和升級成為了愈發繁雜的工作：
業務 Pod 裡面包含了運維、安全、代理等多個 sidecar 容器，業務線同學不僅要完成自身主容器的配置，而且還需要熟悉這些 sidecar 容器的配置，這不僅增加了業務同學的工作量，同時也無形增加了 sidecar 容器配置的風險。sidecar 容器的升級需要連同業務主容器一起重啟（deployment、statefulset 等 workload 基於 Pod 銷燬、重建的模式，來實現 Pod 的滾動升級），推動和升級支撐著線上數百款業務的 sidecar 容器，必然存在著極大的業務阻力。作為 sidecar 容器的提供者對線上諸多各種配置以及版本的 sidecar 容器沒有直接有效的升級手段，這對 sidecar 容器的管理意味著極大的潛在風險。
阿里巴巴集團內部擁有著百萬級的容器數量連同上面承載的上千個業務，因此，sidecar 容器的管理與升級也就成為了亟待完善的主題。因此，我們總結了內部許多 sidecar 容器的通用化需求，並將其沉澱到 OpenKruise 上面，最終抽象為 SidecarSet 作為管理和升級種類繁多 sidecar 容器的利器。
OpenKruise SidecarSet
SidecarSet 是 OpenKruise 中針對 sidecar 抽象出來的概念，負責注入和升級 Kubernetes 叢集中的 sidecar 容器，是 OpenKruise 的核心 workload 之一。它提供了非常豐富的功能，使用者使用 SidecarSet 可以非常方便實現 sidecar 容器的管理。主要特性如下：
配置單獨管理：為每一個 sidecar 容器配置單獨的 SidecarSet 配置，方便管理。
自動注入：在新建、擴容、重建 pod 的場景中，實現 sidecar 容器的自動注入。
原地升級：支援不重建 pod 的方式完成 sidecar 容器的原地升級，不影響業務主容器，幷包含豐富的灰度釋出策略
注意：針對 Pod 中包含多個容器的模式，其中對外提供主要業務邏輯能力的容器稱之為 主容器，其它一些如日誌採集、安全、代理等輔助能力的容器稱之為 Sidecar 容器。例如：一個對外提供 web 能力的 pod，nginx 容器提供主要的 web server 能力即為主容器，logtail 容器負責採集、上報 nginx 日誌即為 Sidecar 容器。本文中的 SidecarSet 資源抽象也是為解決 Sidecar 容器的一些問題。
1。 Sidecar logging architectures
應用日誌可以讓你瞭解應用內部的執行狀況，日誌對除錯問題和監控叢集活動非常有用。應用容器化後，最簡單且最廣泛採用的日誌記錄方式就是寫入標準輸出和標準錯誤。
但是，在當前分散式系統、大規模叢集的時代下，上述方案還不足以達到生產環境的標準。首先，對於分散式系統而言，日誌都是分散在單個容器裡面，沒有一個統一彙總的地方。其次，如果發生容器崩潰、Pod 被驅逐等場景，會出現日誌丟失的情況。因此，需要一種更加可靠，獨立於容器生命週期的日誌解決方案。
Sidecar logging architectures 是將 logging agent 放到一個獨立的 sidecar 容器中，透過共享日誌目錄的方式，實現容器日誌的採集，然後儲存到日誌平臺的後端儲存。
阿里巴巴以及螞蟻集團內部同樣也是基於這種架構實現了容器的日誌採集，下面我將介 紹OpenKruise SidecarSet 如何助力Sidecar 日誌架構在 Kubernetes 叢集中的大規模落地實踐。
2。 自動注入
OpenKruise SidecarSet 基於 Kubernetes AdmissionWebhook 機制實現了 sidecar 容器的自動注入，因此只要將 sidecar 配置到 SidecarSet 中，不管使用者用 CloneSet、Deployment、StatefulSet 等任何方式部署，擴出來的 Pod 中都會注入定義好的 sidecar 容器。
Sidecar 容器的所有者只需要配置自身的 SidecarSet，就可以在業務無感知的情況下完成 sidecar 容器的注入，這種方式極大的降低了 sidecar 容器使用的門檻，也方便了 sidecar 所有者的管理工作。為了滿足 sidecar 注入的多種場景，SidecarSet 除 containers 之外還擴充套件瞭如下欄位：
# sidecarset。yamlapiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： test-sidecarsetspec： # 透過selector選擇pod selector： matchLabels： app： web-server # 指定 namespace 生效 namespace： ns-1 # container definition containers： - name： logtail image： logtail：1。0。0 # 共享指定卷 volumeMounts： - name： web-log mountPath： /var/log/web # 共享所有卷 shareVolumePolicy： disabled # 環境變數共享 transferEnv： - sourceContainerName： web-server # TZ代表時區，例如：web-server容器中存在環境變數 TZ=Asia/Shanghai envName： TZ volumes： - name： web-log emptyDir： {}
Pod 選擇器支援 selector 來選擇要注入的 Pod，如示例中將選擇 labels［app］ = web-server 的 pod，將 logtail 容器注入進去，也可以在所有的 pod 中新增一個 labels［inject/logtail］ = true 的方式，來實現全域性性的 sidecar 注入。namespace：sidecarSet 預設是全域性生效的，如果只想對某一個 namespace 生效，則配置該引數。
資料卷共享共享指定卷：透過 volumeMounts 和 volumes 可以完成與主容器的特定卷的共享，如示例中透過共享 web-log volume 來達到日誌採集的效果。共享所有卷：透過 shareVolumePolicy = enabled | disabled 來控制是否掛載 pod 主容器的所有卷卷，常用於日誌收集等 sidecar，配置為 enabled 後會把應用容器中所有掛載點注入 sidecar 同一路經下（sidecar 中本身就有宣告的資料卷和掛載點除外）。
環境變數共享：可以透過 transferEnv 從其它容器中獲取環境變數，會把名為 sourceContainerName 容器中名為 envName 的環境變數複製到本 sidecar 容器，如示例中日誌 sidecar 容器共享了主容器的時區 TZ，這在海外環境中尤其常見。
注意：Kubernetes 社群對於已經建立的 Pod 不允許修改 container 數量，所以上述注入能力只能發生在 Pod 建立階段，對於已經建立的 Pod 需要透過重建的方式來注入。
3。 原地升級
SidecarSet 不僅實現 sidecar 容器的注入，而且複用了 OpenKruise 中原地升級的特性，實現了在不重啟 Pod 和主容器的前提下單獨升級 sidecar 容器的能力。由於這種升級方式基本上能做到業務方無感知的程度，所以 sidecar 容器的升級已不再是上下交困的難題，從而極大解放了 sidecar 的所有者，提升了 sidecar 版本迭代的速度。
注意：Kubernetes 社群對於已經建立的 Pod 只允許修改 container。image 欄位，因此對於 sidecar 容器的修改包含除 container。image 的其它欄位，則需要透過 Pod 重建的方式，不能直接原地升級。
為了滿足一些複雜的 sidecar 升級場景，SidecarSet 除了原地升級以外，還提供了非常豐富的灰度釋出策略。
4。 灰度釋出
灰度釋出應該算是日常釋出中最常見的一種手段，它能夠比較平滑的完成 sidecar 容器的釋出，尤其是在大規模叢集的場景下，強烈建議使用這種方式。下面是首批暫停，後續基於最大不可用滾動釋出的例子，假設一個有 1000 個 pod 需要釋出：
apiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： sidecarsetspec： # 。。。 updateStrategy： type： RollingUpdate partition： 980 maxUnavailable： 10%上述配置首先發布（1000 - 980）= 20 個 pod 之後就會暫停釋出，業務可以觀察一段時間發現 sidecar 容器正常後，調整重新 update SidecarSet 配置：
apiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： sidecarsetspec： # 。。。 updateStrategy： type： RollingUpdate maxUnavailable： 10%這樣調整後，對於餘下的 980 個 pod，將會按照最大不可用的數量（10% * 1000 = 100）的順序進行釋出，直到所有的 pod 都發布完成。
Partition的語義是保留舊版本 Pod 的數量或百分比，預設為 0。這裡的 partition 不表示任何 order 序號。如果在釋出過程中設定了 partition：
如果是數字，控制器會將 （replicas - partition） 數量的 Pod 更新到最新版本。如果是百分比，控制器會將 （replicas * （100% - partition）） 數量的 Pod 更新到最新版本。
MaxUnavailable是釋出過程中保證的，同一時間下最大不可用的 Pod 數量，預設值為 1。使用者可以將其設定為絕對值或百分比（百分比會被控制器按照 selected pod 做基數來計算出一個背後的絕對值）。
注意：maxUnavailable 和 partition 兩個值是沒有必然關聯。舉例：
當 {matched pod}=100，partition=50，maxUnavailable=10，控制器會發布 50 個 Pod 到新版本，但是釋出視窗為 10，即同一時間只會釋出 10 個 Pod，每釋出好一個 Pod 才會再找一個釋出，直到 50 個釋出完成。當 {matched pod}=100，partition=80，maxUnavailable=30，控制器會發布 20 個 Pod 到新版本，因為滿足 maxUnavailable 數量，所以這 20 個 Pod 會同時釋出。
5。 金絲雀釋出
對於有金絲雀釋出需求的業務，可以透過 strategy。selector 來實現。方式：對於需要率先金絲雀灰度的 pod 打上固定的 labels［canary。release］ = true，再透過 strategy。selector。matchLabels 來選中該 pod。
apiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： sidecarsetspec： # 。。。 updateStrategy： type： RollingUpdate selector： matchLabels： - canary。release： true maxUnavailable： 10%
上述配置只會釋出打上金絲雀 labels 的容器，在完成金絲雀驗證之後，透過將 updateStrategy。selector 配置去掉，就會繼續透過最大不可用來滾動釋出。
6。 打散發布
SidecarSet 對於 pod 的升級順序，預設按照如下規則：
對升級的 pod 集合，保證多次升級的順序一致。
選擇優先順序是（越小優先順序越高）：unscheduled
除了上述預設釋出順序之外，scatter 打散策略允許使用者自定義將符合某些標籤的 Pod 打散到整個釋出過程中。比如，對於像 logtail 這種全域性性的 sidecar container，一個叢集當中很可能注入了幾十個業務 pod，因此可以使用基於 應用名 的方式來打散 logtail 的方式進行釋出，實現不同應用間打散灰度釋出的效果，並且這種方式可以同最大不可用一起使用。
apiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： sidecarsetspec： # 。。。 updateStrategy： type： RollingUpdate # 配置pod labels，假設所有的pod都包含labels［app_name］ scatterStrategy： - key： app_name value： nginx - key： app_name value： web-server - key： app_name value： api-gateway maxUnavailable： 10%注意：當前版本必須要列舉所有的應用名稱，我們將在下個版本支援只配置 label key 的智慧打散方式。
7。 實踐
阿里巴巴以及螞蟻集團內部已經大規模的使用 SidecarSet 來管理 sidecar 容器，下面我將透過日誌採集 Logtail sidecar 來作為一個示例。
基於 sidecarSet。yaml 配置檔案建立 SidecarSet 資源。# sidecarset。yamlapiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： logtail-sidecarsetspec： selector： matchLabels： app： nginx updateStrategy： type： RollingUpdate maxUnavailable： 10% containers： - name： logtail image： log-service/logtail：0。16。16 # when recevie sigterm， logtail will delay 10 seconds and then stop command： - sh - -c - /usr/local/ilogtail/run_logtail。sh 10 livenessProbe： exec： command： - /etc/init。d/ilogtaild - status resources： limits： memory： 512Mi requests： cpu： 10m memory： 30Mi ##### share this volume volumeMounts： - name： nginx-log mountPath： /var/log/nginx transferEnv： - sourceContainerName： nginx envName： TZ volumes： - name： nginx-log emptyDir： {}基於 pod。yaml 建立 Pod。apiVersion： v1kind： Podmetadata： labels： # matches the SidecarSet‘s selector app： nginx name： test-podspec： containers： - name： nginx image： log-service/docker-log-test：latest command： ［“/bin/mock_log”］ args： ［“——log-type=nginx”， “——stdout=false”， “——stderr=true”， “——path=/var/log/nginx/access。log”， “——total-count=1000000000”， “——logs-per-sec=100”］ volumeMounts： - name： nginx-log mountPath： /var/log/nginx envs： - name： TZ value： Asia/Shanghai volumes： - name： nginx-log emptyDir： {}建立這個 Pod，你會發現其中被注入了 logtail 容器：$ kubectl get podNAME READY STATUS RESTARTS AGEtest-pod 2/2 Running 0 118s$ kubectl get pods test-pod -o yaml |grep ’logtail：0。16。16‘ image： log-service/logtail：0。16。16此時，SidecarSet status 被更新為：$ kubectl get sidecarset logtail-sidecarset -o yaml | grep -A4 statusstatus： matchedPods： 1 observedGeneration： 1 readyPods： 1 updatedPods： 1更新 sidecarSet 中 sidecar container 的 image logtail：0。16。18。$ kubectl edit sidecarsets logtail-sidecarset# sidecarset。yamlapiVersion： apps。kruise。io/v1alpha1kind： SidecarSetmetadata： name： logtail-sidecarsetspec： containers： - name： logtail image： log-service/logtail：0。16。18此時，發現 pod 中的 logtail 容器已經被更新為了 logtail：0。16。18 版本，並且 pod 以及其它的容器沒有重啟。$ kubectl get pods |grep test-podtest-pod 2/2 Running 1 7m34s$ kubectl get pods test-pod -o yaml |grep ’image： logtail：0。16。18‘ image： log-service/logtail：0。16。18 $ kubectl describe pods test-podEvents： Type Reason Age From Message —— ———— —— —— ————- Normal Killing 5m47s kubelet Container logtail definition changed， will be restarted Normal Pulling 5m17s kubelet Pulling image “log-service/logtail：0。16。18” Normal Created 5m5s （x2 over 12m） kubelet Created container logtail Normal Started 5m5s （x2 over 12m） kubelet trong“ styleted container logtail Normal Pulled 5m5s kubelet Successfully pulled image ”log-service/logtail：0。16。18“總結
本次 OpenKruise v0。8。0 版本的升級，SidecarSet 特性主要是完善了日誌管理類 Sidecar 場景的能力，後續我們在持續深耕 SidecarSet 穩定性、效能的同時，也將覆蓋更多的場景，比如下一個版本將會增加針對 Service Mesh 場景的支援。同時，我們也歡迎更多的同學參與到 OpenKruise 社群來，共同建設一個場景更加豐富、完善的 K8s 應用管理、交付擴充套件能力，能夠面向更加規模化、複雜化、極致效能的場景。
作者：趙明山（立衡）
