kubernets之就绪探针

一 介绍就绪探针

　　1.1  开始介绍就绪探针之前，让我们来提问几个问题？第一，在sevice这章我们了解到, 当流量从Ingress被转发到服务，然后服务从其维护当Endponits

里面列表查找到任一pod之后，就开始将该pod作为服务的后端来处理请求，如果是该pod需要提前预热，或者需要一段时间后才能提供服务，如此servcie也无从知晓？

第二 就是前面我已经介绍过存活探针，回顾一下其作用，存活探针的作用是，感知pod是否正常运行并定时反馈给管控器(RC等),当pod检测出异常之后，就会立马删除该pod

并且重启从镜像仓库里面拉起一摸一样的pod来代替这个异常pod，而就绪探针应该是什么样子的呢？下面对着这些疑问，让我们一起来认识就绪探针，并且分别解答这些问题

　　1.2  第一个问题，就是我们要讲的就绪探针，在pod中加入就绪探针，如果pod准备就绪，kubernets就会探测到就绪探针已经ready，可以作为后端的服务器来进行提供服务

反之，服务则会临时就pod剔除Endpoint的列表，等到pod准备就绪才开始将pod作为后端应用提供者加入，并且还可以给就绪探针添加一个延时，pod创建之后到这个时间

点才开始进行对就绪探针的探测

　　1.3  就绪探针的类型

• HTTP探针   对pod探针的内部发起http请求，通过相应的返回码判断是否达到就绪状态
• Exec探针    在pod内部执行命令，当命令执行结果返回为0则表示达到就绪
• Tcp socker探针  在pod内部尝试建立tcp连接，若创建成功则表示达到就绪状态

二  向pod中添加就绪探针

　　2.1  RC的文件定义

apiVersion: v1
kind: ReplicationController
...
spec:
  ...
  template:
    ...
    spec:
      containers:
      - name: kubia
        image: luksa/kubia
        readinessProbe:
            exec:
              command:
              - ls
              - /var/ready

• 如此会向RC中的每个pod都会添加一个就绪探针
• 对于之前创建的pod显示的状态仍然是ready，因为后面RC的修改对已经创建的pod没影响
• 如果删除了所有pod，然后在让RC重新根据模板来创建pod，此时pod里面又都没有这个文件，则这些pod都显示为not ready，并且不会作为服务的后端处理请求

三 就绪探针的一些注意事项

　　3.1  就绪探针应该是必须的，而不是可选的

　　　　对于微服务而言，都有很多的pod组合而成，当服务和pod被创建成功之后，就预示着就可能会有请求落到pod里面去，但是如果pod应用还没准备好，则客户端会反馈拒绝连接，这意味着

错误的异常发生，很容易给系统管理员或者k8s集群的研发人员造成困惑

　　3.2 如果想要从服务中添加pod只需要在pod上面添加标签和服务的标签选择器里面添加enabled=true，同理删除的时候可以将标签删除

　　3.3  不需要将容器终于程序添加到就绪探针的逻辑里面，因为只要容器关机，kubernets会从所有的服务中移除这个pod，所有不需要多此一举的去实现这个从服务移除逻辑