谷歌KDD'23工作：如何提升推薦系統Ranking模型訓練穩定性
谷歌在KDD 2023發表了一篇工作，探索了推薦系統ranking模型的訓練穩定性問題，分析了造成訓練穩定性存在問題的潛在原因，以及現有的一些提升模型穩定性方法的不足，并提出了一種新
在現代化應用技術領域中，容器編排平臺簡化了針對基于微服務應用的基礎架構配置，并通過模塊化實現了高效的工作負載的管理。而作為一個被廣泛采用的、能夠支持多種部署資源的平臺，Kubernetes更是方便了企業大規模地以CI/CD管道的方式，部署和管理各類應用程序。雖然Kubernetes提供了滾動更新(rolling updates)作為默認的部署策略，但是某些用例則需要使用非常規的方法，來部署或更新集群中的各項服務。下面，我們將在回顧Kubernetes基本部署概念的基礎上，深入探討各種高級的Kubernetes部署策略、它們的優缺點、及其用例。
Kubernetes的部署概念
在部署過程中，集群管理員可以自定義應用程序的生命周期，以及執行更新的方式。而Kubernetes通常會使用部署資源，并以聲明的方式去更新各類應用程序。它的這種自動化部署方式，實現并維護了各個集群對象及應用程序的所需狀態。而且，其后端無需人工干預，即可以一種安全且可重復的方式，來執行應用程序的更新。也就是說，Kubernetes的部署可以協助集群管理員實現：
部署單個pod或副本集更新一組pod或副本集回滾到早期的版本暫?；蚶^續部署擴展各種部署
下面，我們將探討Kubernetes是如何簡化容器化應用的更新過程，以及它將如何應對持續交付的挑戰。
Kubernetes對象
雖然Kubernetes可以利用許多種工作負載資源對象，作為持久實體，去管理集群的狀態，但Kubernetes API通常會使用Deployment(部署)、ReplicaSet(副本集)、StatefulSet(有狀態集)和DaemonSet(守護程序集)四種資源，對應用程序進行聲明式更新。下面我們來具體看看這四種資源的特點：
Deployment
作為一種Kubernetes資源，Deployment可用于定義和識別應用程序所需的狀態。集群管理員在Deployment的YAML文件中通過描述預期的狀態，以便部署控制器，并據此將實際狀態逐漸更改為預期的狀態。而為了確保高可用性，部署控制器還會通過持續監控，按需將健康的集群節點和pod，去替換那些失敗的集群節點和pod。
ReplicaSet
ReplicaSet可用于維護特定數量的pod，以確保其高可用性。ReplicaSet的清單文件會包括如下字段：
用于識別隸屬于某個集合的pod選擇器通過副本數，來表示集合中應該有多少個pod通過一個pod模板，來顯示新的pod應創建哪些數據，以滿足副本集的標準StatefulSet
StatefulSet對象可以管理某個有狀態的應用程序中的pod部署與擴展。該資源會基于相同的容器規范，去管理pod，并確保整組pod的唯一性、以及排列有序。StatefulSet的持久性pod標識符，能夠方便集群管理員將其工作負載連接到具有高可用性的持久性存儲卷上。
DaemonSet
DaemonSet通過確保一組節點運行在某個pod的副本上，來協助維護應用程序的部署。DaemonSet資源主要被用于管理各種代理的部署和生命周期中，例如：
每個節點上的各個集群存儲代理日志收集的守護進程節點監控的守護進程
您也可以通過鏈接--https://kubernetes.io/docs/concepts/workloads/controllers/，查看更多有關各種Kubernetes工作負載資源的列表，及其詳細信息。
使用部署更新
Kubernetes的部署提供了一種可預測的方法，來啟動和停止pod。有了這些資源，我們可以輕松地實施部署、回滾更改、以及以自主迭代式管理軟件的發布周期。目前，Kubernetes通過提供各種部署策略，來實現更小、更頻繁的更新，并為應用提供如下優勢：
通過更快的客戶反饋，以獲得更好的功能性優化縮短面市時間提高DevOps團隊的生產力
默認情況下，由Kubernetes提供的滾動式更新，可作為其標準的部署策略，實現一次性將新的版本去替換某個舊的pod，以避免集群的停機。此外，根據功能性的目標和類型的不同，Kubernetes還支持包括藍綠、金絲雀和A/B部署在內，各種高級部署策略。下面，讓我們來詳細討論這些策略的特點，及其優缺點。
Kubernetes部署的高級策略
部署配置與路由功能的結合使用，能夠方便發布團隊在提交完整版本之前，在實時的生產環境中，測試新功能的有效性。為此，開發人員可以利用Kubernetes所支持的高級部署策略，來精確地控制特定版本的質量。當然，具體應當采取何種Kubernetes的部署方式，去發布應用程序的更新和新功能，則取決于實際用例和工作負載。
藍綠部署
在藍綠策略中，應用程序的新舊實例會被同時部署。在用戶可以持續訪問現有版本(藍色)的同時，具有相同數量的新版本(綠色)實例可供站點可靠性工程師(site reliability engineering，SRE)和QA團隊使用。一旦QA團隊確認了綠色版本已通過所有測試要求，用戶就會被重定向到新的版本上。這往往是通過更新負載均衡服務上selector字段中的version標簽來實現的。通常，當開發人員想要避免出現版本控制問題時，藍綠部署就非常適用。
使用藍綠部署策略
讓我們假設某個應用程序的第一個版為v1.0.0，而可用的第二個版是v2.0.0。那么如下代碼段便是指向第一個版本的服務：
apiVersion: v1
kind: Service
metadata:
name: darwin-service-a
spec:
type: LoadBalancer
selector:
app: nginx
version: v1.0.0
ports:
- name: http
port: 80
targetPort: 80
而下面是指向第二個版本的服務：
apiVersion: v1
kind: Service
metadata:
name: darwin-service-b
spec:
type: LoadBalancer
selector:
app: nginx
version: v2.0.0
ports:
- name: http
port: 80
targetPort: http
一旦我們完成了必要的測試，并批準了第二個版本，那么指向第一個服務的selector就需要更改為v2.0.0：
apiVersion: v1
kind: Service
metadata:
name: darwin-service-a
spec:
type: LoadBalancer
selector:
app: nginx
version: v2.0.0
ports:
- name: http
port: 80
targetPort: http
如果新版本的應用程序能夠按預期運行，那么v1.0.0版就可以“下線”了。
金絲雀部署
在金絲雀策略中，一部分用戶會被路由到承載了新版本的pod上。該用戶群會逐漸增加，而連接到舊版本的群體則會相應減少。該策略可用于比較使用著兩個版本的用戶集合的體驗。如果未檢測到錯誤，我們則可以將新版本推送給遺留在舊版本上的用戶。
使用金絲雀部署策略
原生的Kubernetes金絲雀部署的過程包含如下步驟：
1. 通過以下方式部署運行版本1所需的副本：
部署第一個應用程序：
$ kubectl apply -f darwin-v1.yaml
將其擴展至所需的副本數量：
$ kubectl scale --replicas=9 deploy darwin-v1
2.部署版本2的實例：
$ kubectl apply -f darwin-v2.yaml
3.測試版本2是否已部署成功：
$ service=$(minikube service darwin --url)
$ while sleep 0.1; do curl "$service"; done
4.如果部署成功，則擴展版本2的實例數量：
$ kubectl scale --replicas=10 deploy darwin-v2
5.一旦所有副本都上線，您就可以“優雅地”刪除版本1了：
$ kubectl delete deploy darwin-v1A/B部署
通過A/B部署，管理員可以將特定的用戶子集，路由到具有某些限制和/或條件的新版本上。此類部署主要被用于評估用戶群對某些新功能的反響。由于用戶在測試期間并不知曉自己已被呈現了新的功能，因此A/B部署有時也被稱為“暗啟動”。
使用A/B部署策略
以下是對Istio服務網格執行A/B測試的方法示例。它將有助于使用流量權重(traffic weight)來推出不同的版本：
1.假設集群上已經安裝了Istio，那么我們首先需要部署兩個版本的應用：
$ kubectl apply -f darwin-v1.yaml -f darwin-v2.yaml
2. 然后，我們可以通過Istio網關去發布兩個版本，并使用如下命令，將請求匹配到第一個服務上：
$ kubectl apply -f ./gateway.yaml -f ./virtualservice.yaml
3.接著，我們可以使用如下命令，根據權重來應用Istio的VirtualService規則：
$ kubectl apply -f ./virtualservice-weight.yaml
它會以1:10的比例，在版本之間分配流量的權重。為了轉移流量的權重，我們可以編輯每個服務的權重，然后通過Kubernetes CLI去更新VirtualService規則。
每種高級部署策略的適用場景
由于Kubernetes用例會因可用性要求、預算限制、可用資源和其他考慮因素而異，因此目前并不存在一種萬能的部署策略。您在選擇部署策略時，需要考慮以下表格：
Kubernetes部署策略比較
小結
借助各種部署資源，Kubernetes管理員可以通過建立高效的版本控制系統，來更新pod，回滾到早期版本、或擴展基礎架構，以滿足不斷增長的工作負載，并通過管理應用的不同版本，來最小化停機時間。
上文介紹的各種Kubernetes高級部署策略，能夠在一定程度上方便管理員將流量和請求路由到特定的版本上，從而在真實的測試環境中處理各種錯誤。同時，這些策略也常被用于，在管理員和開發人員完全提交更改之前，檢驗新的功能是否能夠按照原定計劃運行，以及通過充分的回滾選項，實現多種松散的耦合服務，進而實現應用更新和功能上的快速交付。當然，具體該如何選擇，還需要您根據實際的應用環境，參照上述比較表，做出選擇。
其他可參考資源使用kubectl創建部署Kubernetes的各種部署用例Kubernetes部署生命周期的不同狀態譯者介紹
陳峻 (Julian Chen)，51CTO社區編輯，具有十多年的IT項目實施經驗，善于對內外部資源與風險實施管控，專注傳播網絡與信息安全知識與經驗;持續以博文、專題和譯文等形式，分享前沿技術與新知;經常以線上、線下等方式，開展信息安全類培訓與授課。
原文標題：Advanced Kubernetes Deployment Strategies，作者：Sudip Sengupta
本文鏈接：http://m.www897cc.com/showinfo-119-2171-0.htmlKubernetes的高級部署策略集 譯文
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 云安全日報220222: 紅帽Ruby腳本語言發現任意代碼執行漏洞，需要盡快升級
下一篇： 組織網友刷好評 亞馬遜將兩家公司告上法庭
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號