k8s~通过探针实现服务的平滑部署

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