對于k8s上的pod來說，它由于容器組成，它是k8s里的最基本單位，你可以通過service來實現對pod的負載均衡，對外提供服務，而可以不需要傳統的nginx做負載了，當然如果你的域名是公開的，不需要云上的負載服務的，也可以直接使用k8s的ingress來實現。
參考：

不能平滑發布

pod在部署過程中,會出現pod未準備好的情況，而如果這時你的外布負載直接打過來，就出現了503的問題，當然如果你又加了一層nginx，可以避免這種問題。

怎么判斷Pod是否Ready

Kubernetes自(zi)身實現(xian)了一個叫做Ready Pod的(de)概念來輔助滾(gun)動(dong)(dong)更新(xin)(xin)。具(ju)體來說就是，ReadinessProbe （就緒探針(zhen)）可以(yi)使(shi)Deployment逐步更新(xin)(xin)Pod，同時也(ye)可以(yi)使(shi)用它控制何時才能進行滾(gun)動(dong)(dong)更新(xin)(xin)，Service也(ye)使(shi)用它來確(que)定應(ying)該將哪些Pod包(bao)含在服務的(de)Endpoints中。

readinessProbe容器中的探針

 containers:
  - name: keycloak-controller
    image: jboss/keycloak:14.0.0
    readinessProbe: #探針功能，服務啟動成功后再加到service的endpoints中
      periodSeconds: 10 #每10秒檢測一次
      initialDelaySeconds: 5 #pod啟動后,延時5秒
      httpGet:
        path: /auth/realms/master/
        port: 8080

上(shang)面的(de)配置中(zhong)，我(wo)(wo)們探針是容(rong)器里的(de)api接口(kou)/auth/realms/master/，我(wo)(wo)們每(mei)10秒去(qu)檢查一次它的(de)狀態，當成(cheng)功之(zhi)后，延時5秒加入到service的(de)Endpoints中(zhong)，以便對外提(ti)供(gong)服務。

滾動部署

我(wo)們(men)按(an)說3個(ge)(ge)pod副本來說，我(wo)們(men)讓(rang)它1個(ge)(ge)1個(ge)(ge)的pod進(jin)行(xing)替換(huan)，下(xia)面代碼體(ti)現了這個(ge)(ge)邏輯

  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0

特別注意

對于探針檢查和service里的能數publishNotReadyAddresses:true是沖突的，當你配置它之后，你的探針是無效的，因為無論你的容器是否就緒，當publishNotReadyAddresses為true時，都會加入到service的endpoints里，這一點(dian)要非常注(zhu)意。

有些時間需(xu)要(yao)把(ba)(ba)publishNotReadyAddresses設為true，當你的多個pod在就緒之前就直接相互通訊時，例如使用jgroup進行組(zu)建集群時，你就需(xu)要(yao)把(ba)(ba)publishNotReadyAddresses改為true，否則你的集群也起不來。

• 最后進行測試之后，發現也是有500毫秒的服務不可用狀態