如果你的服務器資(zi)源緊張，pod可(ke)能只(zhi)能是單(dan)副本了，這時(shi)在(zai)進行平滑的滾動部署(shu)時(shi)，應該(gai)如何(he)配置(zhi)呢(ni)？總不(bu)能在(zai)部署(shu)期間503吧，這是不(bu)能接(jie)受(shou)的！

maxUnavailable來配置不可用數量

我們可以在spec.strategy.strategy.rollingUpdate中，將不可用數maxUnavailable改(gai)成0即可(ke)實現平滑部(bu)署，配置如(ru)下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: keycloak-deployment
  namespace: kc
spec:
  replicas: 1
  #滾動升級策略
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0 #當副本為1時，我們采用這個配置，即不允許有多余的pod

如果是(shi)多個(ge)副本，你(ni)也可(ke)(ke)(ke)以通過(guo)rollingUpdate中的(de)maxSurge來控制可(ke)(ke)(ke)用(yong)節點(dian)數(shu)，maxUnavailable來控制不可(ke)(ke)(ke)用(yong)數(shu)，如下面的(de)配(pei)置(zhi)，在(zai)副本為(wei)3個(ge)時(shi)，可(ke)(ke)(ke)用(yong)數(shu)至少為(wei)1個(ge)，不可(ke)(ke)(ke)用(yong)也是(shi)0個(ge)，相當于1個(ge)1個(ge)的(de)副本去啟動，整(zheng)個(ge)deployment對外始(shi)終是(shi)3個(ge)可(ke)(ke)(ke)用(yong)的(de)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 的總結：

1. 作用：readinessProbe 用于確定容器是否已經準備好接收流量。如果容器的 readinessProbe 失敗，Kubernetes 將(jiang)不會(hui)將(jiang)流量(liang)路由到(dao)該容器(qi)。

2. 配置方式：readinessProbe 可以(yi)通過 HTTP、TCP 或執行命(ming)(ming)令的方式進行配置(zhi)。你可以(yi)指定(ding)(ding)一個 HTTP 請求(qiu)路徑、端(duan)口號或自(zi)定(ding)(ding)義命(ming)(ming)令，并設置(zhi)相應的超(chao)時時間和周期。

3. 成功條件：readinessProbe 根據配置的方(fang)式來判斷(duan)容器的就緒狀態。例如，對(dui)于 HTTP 探測(ce)，返(fan)回(hui)狀態碼在200-399之間(jian)表示成(cheng)(cheng)功(gong)(gong)；對(dui)于 TCP 探測(ce)，連接成(cheng)(cheng)功(gong)(gong)即為成(cheng)(cheng)功(gong)(gong)；對(dui)于執(zhi)行(xing)命令探測(ce)，返(fan)回(hui)值為0表示成(cheng)(cheng)功(gong)(gong)。

4. 失敗處理：當 readinessProbe 失(shi)敗(bai)時，Kubernetes 不會將流量路由(you)到該容器。容器可能會被標記為 Unready 狀態，并從 Service 的負載均衡(heng)中剔除。

5. 重試策略：如果 readinessProbe 失敗，Kubernetes 將按照(zhao)配置(zhi)的間隔時間進行重試(shi)。只(zhi)有當連續多次探(tan)測失敗后，容器才會(hui)被認定為不可(ke)用。

6. 應用場景：適用于需要一(yi)段時(shi)間來啟(qi)動服務或加載數據的應用程序(xu)，以確保在容器完(wan)全就緒之前不接(jie)收(shou)流量。

7. 常見配置：示例配置如下，包括(kuo) HTTP 探(tan)測(ce)、TCP 探(tan)測(ce)和執行命(ming)令探(tan)測(ce)：

   readinessProbe:
     httpGet:
       path: /healthz
       port: 8080
     initialDelaySeconds: 5
     periodSeconds: 10
   

通過合理配置 readinessProbe，可(ke)以提高容器(qi)的(de)(de)穩(wen)定性和可(ke)靠性，確保應(ying)用程序(xu)在容器(qi)就(jiu)緒后再(zai)接收流量，避免因為服(fu)務未(wei)完全(quan)啟動(dong)而導致的(de)(de)請求(qiu)失敗。希望(wang)這個總結(jie)對你有所(suo)幫(bang)助。如果還有其他問題(ti)，請隨時(shi)告訴(su)我。