對於k8s上的pod來說，它由於容器組成，它是k8s里的最基本單位，你可以通過service來實現對pod的負載均衡，對外提供服務，而可以不需要傳統的nginx做負載了，當然如果你的域名是公開的，不需要雲上的負載服務的，也可以直接使用k8s的ingress來實現。
參考：https://www.bluematador.com/blog/kubernetes-deployments-rolling-update-configuration
不能平滑發布
pod在部署過程中,會出現pod未准備好的情況，而如果這時你的外布負載直接打過來，就出現了503的問題，當然如果你又加了一層nginx，可以避免這種問題。
怎么判斷Pod是否Ready
Kubernetes自身實現了一個叫做Ready Pod的概念來輔助滾動更新。具體來說就是，ReadinessProbe （就緒探針）可以使Deployment逐步更新Pod，同時也可以使用它控制何時才能進行滾動更新，Service也使用它來確定應該將哪些Pod包含在服務的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
上面的配置中，我們探針是容器里的api接口/auth/realms/master/，我們每10秒去檢查一次它的狀態，當成功之后，延時5秒加入到service的Endpoints中，以便對外提供服務。
滾動部署
我們按說3個pod副本來說，我們讓它1個1個的pod進行替換，下面代碼體現了這個邏輯
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
特別注意
對於探針檢查和service里的能數publishNotReadyAddresses:true是沖突的，當你配置它之后，你的探針是無效的，因為無論你的容器是否就緒，當publishNotReadyAddresses為true時，都會加入到service的endpoints里，這一點要非常注意。
有些時間需要把publishNotReadyAddresses設為true，當你的多個pod在就緒之前就直接相互通訊時，例如使用jgroup進行組建集群時，你就需要把publishNotReadyAddresses改為true，否則你的集群也起不來。
- 最后進行測試之后，發現也是有500毫秒的服務不可用狀態
