如果你的伺服器資源緊張,pod可能只能是單副本了,這時在進行平滑的滾動部署時,應該如何配置呢?總不能在部署期間503吧,這是不能接受的!
maxUnavailable來配置不可用數量
我們可以在spec.strategy.strategy.rollingUpdate中,將不可用數maxUnavailable
改成0即可實現平滑部署,配置如下:
apiVersion: apps/v1
kind: Deployment
metadata:
name: keycloak-deployment
namespace: kc
spec:
replicas: 1
#滾動升級策略
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 0 #當副本為1時,我們採用這個配置,即不允許有多餘的pod
如果是多個副本,你也可以透過rollingUpdate中的maxSurge來控制可用節點數,maxUnavailable來控制不可用數,如下面的配置,在副本為3個時,可用數至少為1個,不可用也是0個,相當於1個1個的副本去啟動,整個deployment對外始終是3個可用的pod。
apiVersion: apps/v1
kind: Deployment
metadata:
name: keycloak-deployment
namespace: kc
spec:
replicas: 3
#滾動升級策略
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
部署過程如圖,1個副本時,在釋出期間,也始終有1個是可用的
k8s如何探測pod啟動了
readinessProbe
是 Kubernetes 中用來檢查容器是否準備好接收流量的機制。透過配置 readinessProbe
,Kubernetes 可以確保只有在容器完全就緒並能夠處理請求時才會將流量引導到該容器。以下是關於 readinessProbe
的總結:
-
作用:
readinessProbe
用於確定容器是否已經準備好接收流量。如果容器的readinessProbe
失敗,Kubernetes 將不會將流量路由到該容器。 -
配置方式:
readinessProbe
可以透過 HTTP、TCP 或執行命令的方式進行配置。你可以指定一個 HTTP 請求路徑、埠號或自定義命令,並設定相應的超時時間和週期。 -
成功條件:
readinessProbe
根據配置的方式來判斷容器的就緒狀態。例如,對於 HTTP 探測,返回狀態碼在200-399之間表示成功;對於 TCP 探測,連線成功即為成功;對於執行命令探測,返回值為0表示成功。 -
失敗處理:當
readinessProbe
失敗時,Kubernetes 不會將流量路由到該容器。容器可能會被標記為 Unready 狀態,並從 Service 的負載均衡中剔除。 -
重試策略:如果
readinessProbe
失敗,Kubernetes 將按照配置的間隔時間進行重試。只有當連續多次探測失敗後,容器才會被認定為不可用。 -
應用場景:適用於需要一段時間來啟動服務或載入資料的應用程式,以確保在容器完全就緒之前不接收流量。
-
常見配置:示例配置如下,包括 HTTP 探測、TCP 探測和執行命令探測:
readinessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 5 periodSeconds: 10
透過合理配置 readinessProbe
,可以提高容器的穩定性和可靠性,確保應用程式在容器就緒後再接收流量,避免因為服務未完全啟動而導致的請求失敗。希望這個總結對你有所幫助。如果還有其他問題,請隨時告訴我。