對于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
作者：倉儲大叔，張占嶺，
榮譽：微軟MVP
QQ：853066980
支付寶掃一掃，為大叔打賞!
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/373808.html
標籤：其他
上一篇：不止是上云，更是上岸