一 介绍就绪探针
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，所有不需要多此一举的去实现这个从服务移除逻辑