紅魔電競平板評測：大屏幕硬實力
前言：三年的疫情因為要上網課的原因激活了平板市場，如今網課的時代已經過去，大家的生活都恢復到了正軌，這也就意味著，真正考驗平板電腦生存的環境來了。也就是面對著這種殘酷的
在這篇文章中，我們將深入研究 Kubernetes 部署概念和一些常見策略，了解每種策略的優缺點。合適的部署策略使我們能夠在發布應用程序時最大限度地減少停機時間、增強客戶體驗并提高可靠性。
Kubernetes 部署是一種聲明性語句，通常在 YAML 文件中配置，用于定義應用程序生命周期以及如何管理對該應用程序的更新。
當將應用程序部署到 K8s 集群時，所選擇的部署策略將決定如何將應用程序從舊版本更新到新版本。某些策略可能會導致停機時間，而其他策略則可能引入測試概念并允許用戶分析。本文將介紹兩種常用的基本 K8s 部署策略：
以下策略被認為是“高級部署策略”，因為可以以多種方式控制流量的流向：
K8s 使用滾動更新策略作為默認策略，但在某些情況下可能不適用。讓我們詳細討論每種策略！
重新創建部署會終止所有的 Pod，并用新版本的 Pod 替換它們。這在舊版本和新版本的應用程序不能同時運行的情況下很有用。使用此策略產生的停機時間取決于應用程序關閉和啟動所需的時間。由于完全替換，應用程序狀態也會完全更新。
示例如下，type=Recreate表示為重新創建
spec: replicas: 10 strategy: type: Recreate
圖片
圖片
滾動更新是 K8s 的默認部署方式，旨在減少集群的停機時間。滾動更新會將運行舊版本應用程序的 Pod 逐步替換為新版本，而無需停機。
圖片
為了實現這一點，要使用就緒探針（Readiness probes）
就緒探針監視應用程序何時變為可用狀態。如果探針失敗，流量將不會發送到該 Pod。這些探針用于需要在就緒之前執行部分初始化步驟的應用程序，比如數據庫鏈接、緩存數據初始化，應用的發布注冊等操作。
一旦就緒探針檢測到新版本應用程序可用，舊版本應用程序將被刪除。如果出現問題，可以停止部署并回滾到上一個版本，避免整個集群的停機時間。由于每個 Pod 逐個替換，對于較大的集群，部署需要一定的時間。如果在另一個部署完成之前觸發了新的部署，版本將更新為新部署中指定的版本，并且尚未部署成功的先前部署版本將被忽略。
觸發滾動更新部署的條件是 Pod 規范中的某些更改，例如更新 Pod 的鏡像、環境變量或標簽?？梢允褂妹?nbsp;kubectl set image 來更新 Pod 鏡像。
yaml文件的 Spec: -> strategy: 部分可以使用兩個參數來細化部署：maxSurge 和 maxUnavailable。這兩個參數可以指定為百分比或絕對數值。當使用水平 Pod 自動縮放時，應使用百分比。
例如，下面的配置要求有 10 個副本，最多同時創建 3 個副本，允許在部署期間有 1 個副本不可用：
spec: replicas: 10 strategy: type: RollingUpdate rollingUpdate: maxSurge: 3 maxUnavailable: 1藍/綠部署涉及將新的應用程序版本（綠色）與舊版本（藍色）一起部署。通過服務選擇器對象作為負載均衡器，當新應用程序（綠色）經過測試和驗證后，將流量引導到新應用程序而不是舊應用程序。藍/綠部署可能會造成成本增加，因為在部署期間需要啟動兩倍數量的應用程序資源。
圖片
為了實現這一點，我們需要設置一個在部署之前的服務。例如，對于名為 web-app 的應用程序的 v1.0.0 版本的藍色部署，yaml 文件中的服務選擇器部分可能如下所示：
kind: Servicemetadata: name: web-app-01 labels: app: web-appselector: app: web-app version: v1.0.0藍色 web-app 的部署如下：
kind: Deploymentmetadata: name: web-app-01spec: template: metadata: labels: app: web-app version: "v1.0.0"當我們想要將流量引導到應用程序的新（綠色）版本時，我們更新 manifest 文件以指向新版本 v2.0.0。
kind: Servicemetadata: name: web-app-02 labels: app: web-appselector: app: web-app version: v2.0.0綠色應用程序的部署如下：
kind: Deploymentmetadata: name: web-app-02spec: template: metadata: labels: app: web-app version: "v2.0.0"金絲雀與“影子部署”一詞可以互換使用。
影子部署是一種策略，其中新版本的應用程序與現有的生產版本一起部署，主要用于監控和測試目的。在影子部署中，用戶流量不會主動路由到新版本。這對于測試新功能的生產負載特別有用。
圖片
這種技術比較復雜，需要特殊要求，尤其是出口流量。例如，有一個商品，您想調用支付服務進行影子測試，最終可能會讓客戶為他們的訂單支付兩次，所以復雜性比較高
金絲雀部署可用于讓一部分用戶測試應用程序的新版本，或者在對新版本的功能性沒有完全信心時使用。新版本的一個副本與舊版本一起發布，其中舊版本應用程序為大部分用戶提供服務，而新版本應用程序為一小部分測試用戶提供服務。如果新部署成功，則將其逐漸擴展到更多用戶。
圖片
例如，在一個具有 100 個運行的 Pod 的 K8s 集群中，有 95 個運行著應用程序的 v1.0.0 版本，而有 5 個運行著新的 v2.0.0 版本。95% 的用戶將被路由到舊版本，而5% 的用戶將被路由到新版本。為此，我們使用并行的兩個部署，可以分別進行擴展。
舊應用程序的 yaml 文件中的 spec 部分可能如下所示:
spec: replicas: 95新應用程序的 yaml 文件中的 spec 部分可能如下所示：
spec: replicas: 5在上面的示例中，運行 100 個 Pod 可能是不切實際的。更好的方法是使用負載均衡器，如NGINX、HAProxy或Traefik，或者使用類似Istio、Hashicorp Consul或Linkrd的服務網格，他們可以提供對流量的更好控制。
與金絲雀部署類似，使用 A/B 部署，我們可以基于一些目標參數（通常是 HTTP 標頭或 cookie等）定位給定的用戶，并根據權重在不同版本之間分配流量。這種技術被廣泛用于測試某個特定功能的轉化率，然后選擇轉化率最高的版本進行最終部署。
圖片
這種方法通常基于收集的用戶行為數據，并用于做出更好的業務決策。在 A/B 測試期間，用戶通常不會被告知新功能，以便進行真實的測試，并可以比較使用舊版本和新版本的用戶之間的體驗。由于額外的測試期和用戶體驗分析，使用 A/B 部署進行部署速度可能會較慢。
可以使用 Istio 和 Flagger 自動化進行 A/B 部署。
在本文中，我們討論了6種常見的K8s部署策略。在決定如何部署或升級您的應用程序時，如何使用這些策略，以及使用哪些工具來實現每種策略是非常重要的。
本文鏈接：http://www.www897cc.com/showinfo-26-56395-0.html六種不同類型的K8s部署策略總結
聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： Cython庫：從基本用法到高級用法
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號