对于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毫秒的服务不可用状态
