Open gaopeiliang opened 4 years ago
一定要：
一定要定义 readiness 保证服务在准备好时，再接收流量
增加一个言简意赅的endpoint，使用 httpGet 检查
检查一定要是最直接的处理业务的endpoint，而非管理等endpoint
服务一定要准备好时，endpoint才返回200，加载数据，预热等阶段可以返回503
一定不要：
liveness 不要依赖外部服务，否则外部服务问题，会使容器重建
不要使用相同的 liveness 和 readiness , 如果使用了相同的，那么liveness 的判定时间一定要比 readiness 长
不要使用 exec probes 探测模式 （k8s对错误的exec command 和 超时都 认为是无效的执行，忽略对结果的影响， 而在http，tcp probe 的处理上都认为是failed 的探测，所以 exec 在面对 command 错误，僵尸进程，死锁进程等超时响应情况时，不能正确反应POD状态）
所以最好定义 liveness 只探测服务是不是死锁，僵尸等，重启解决不可能恢复的局面 定义 readiness 检查服务能提供正常服务所需的依赖，任何一个必须的依赖无法 正常的提供服务，服务就需要下线，等待依赖恢复在上线
一定要：
一定要定义 readiness 保证服务在准备好时，再接收流量
增加一个言简意赅的endpoint，使用 httpGet 检查
检查一定要是最直接的处理业务的endpoint，而非管理等endpoint
服务一定要准备好时，endpoint才返回200，加载数据，预热等阶段可以返回503
一定不要：
liveness 不要依赖外部服务，否则外部服务问题，会使容器重建
不要使用相同的 liveness 和 readiness , 如果使用了相同的，那么liveness 的判定时间一定要比 readiness 长
不要使用 exec probes 探测模式 （k8s对错误的exec command 和 超时都 认为是无效的执行，忽略对结果的影响， 而在http，tcp probe 的处理上都认为是failed 的探测，所以 exec 在面对 command 错误，僵尸进程，死锁进程等超时响应情况时，不能正确反应POD状态）
所以最好定义 liveness 只探测服务是不是死锁，僵尸等，重启解决不可能恢复的局面 定义 readiness 检查服务能提供正常服务所需的依赖，任何一个必须的依赖无法 正常的提供服务，服务就需要下线，等待依赖恢复在上线