dao2022-09-25 来自北京思考题： 1. Liveness 和 Readiness 都是循环探测，Liveness 探测失败会重启，而 Readiness 探测失败不会重启，可以从 Pod 状态 看出重启次数。 两者都可以单独使用，这时差异不大。 如果同时使用两者，Liveness 主要是确认应用运行着或者说活着，而 Readiness 是确认应用提供着服务或者说服务就绪着（可以接收流量）。 2. Shell 是从容器内部探测，TCP Socket 和 HTTP GET 都是在容器外部探测。 TCP Socket 基于端口的探测，端口打开即成功；HTTP GET 更丰富些，可以是端口 + 路径。作者回复: good
18
新时代农民工2022-08-26 来自北京老师请问，Startup、Liveness、Readiness三种探针是按顺序执行还是并行呢？作者回复: Startup成功之后才能执行后两个探针，后面两个是并行的。
17
邵涵2022-10-25 来自上海如老师原文所示，在startupProbe或livenessProbe探测失败之后，pod的status初始都是running。不过，在容器重启几次之后，pod的status会变为CrashLoopBackOff 如果startupProbe和livenessProbe探测成功，readinessProbe探测失败，pod的ready一直是0/1，status一直是running，当然，也不会重启 NAME READY STATUS RESTARTS AGE ngx-pod-probe 0/1 Running 0 27m作者回复: great
6
拾掇拾掇2022-09-12 来自北京Shell：不用知道端口；TCP Socket、HTTP GET这2个都得知道端口，用的时候还得显示调用端口吧作者回复: 是的，可以参考一些知名镜像的YAML ，看看它们是怎么做健康检查的。
共 2 条评论5- Geek_2ce0742022-09-30 来自北京老师 tcpSocket探测是由谁发起的
作者回复: 当然是Kubernetes，不能内部具体如何运转的就没细研究了。
3 
Lorry2023-02-03 来自四川Liveness指的是进程是否存在，Readiness则是指是否能够正常提供服务，所以可以使用tcp'协议检测Liveness，进程存在端口即存在，使用http检测服务，只有服务启动了参能够相应请求。 Shell是系统内进程级别交互，所以只能够本地访问，Tcp可以跨机器访问，但是访问的级别比较低，不能够获得顶层数据，Http是协议层数据，可以拿到应用层的服务信息，但是关注顶层信息，底层故障，顶层无法提供有价值信息了作者回复: great
共 2 条评论2
YueShi2022-08-31 来自北京"postStart"'"preStop"感觉可以做CICD，或者各种webhock钩子，或者简单的通知作者回复: 是的，这些都是Kubernetes为我们提供的回调接口。
2
大毛2023-06-26 来自北京思考题 1. liveness 和 readiness 探针分别代表程序正常运行和可以提供服务。要探索两者的区别就要看应用在这两种状态下的差异，即在程序运行和提供服务之间，差了些什么。程序正常运行，可能代表代码没有 bug，没有硬性的致命的问题，但是要让它达到可以提供服务的程度，还需要一些条件，比如：启动时可能需要缓存预热，这个阶段可能就是 liveness 成功但 readiness 失败。可能 pod 的负载过大，需要进行降级，这就需要将 readness 从成功改成失败。 所以可能两种探针失败也有不同的含义：liveness 失败代表应用运行出现比较致命问题，需要重启来续命。readiness 失败代表程序不太健康，这种不健康是可以恢复的。 2. 三种探测方式应用的使用情境不同吧，shell 是在操作系统层面上的探测，毕竟跑起来的业务代码不方便（可能也不应该？）关心 OS。TCP Socket 关心的是网络，关心的是不同进程间的基础通信？http Get 是在应用层面上的探测，感觉它应该和业务的关联比较紧密。 忽然感觉 kubernetes 真厉害，三种探针和三种探测方式，基本上可以检测出各个层面的问题。展开作者回复: great
1
peter2022-08-26 来自北京请教老师几个问题： Q1：第27讲中，创建4个nginx实例，没有端口冲突问题吗？ 四个nginx实例，两个在master，两个在worker。同一台机器上有两个pod，而pod的定义是一样的，即端口相同，那么，不存在端口冲突问题吗？ Q2：第27讲中，创建四个nginx实例后，不能访问nginx的欢迎页。 service也创建了。 用虚拟机上浏览器来访问127.0.0.1，失败， 执行“kubectl port-forward svc/ngx-svc 8080:80 &”以后， 浏览器上访问127.0.0.1:8080，报错： E0826 14:32:28.734987 42769 portforward.go:391] error copying from local connection to remote stream: read tcp4 127.0.0.1:8080->127.0.0.1:59752: read: connection reset by peer Q3：nginx的配置文件中，竖线是什么意思？ data: default.conf: |， 这里的竖线是什么意思？ Q4：操作系统能够看到的CPU，是指逻辑核吗？还是时间片？展开作者回复: 1.每个Nginx都是运行在pod里，被容器环境隔离，当然不会冲突，可以复习一下入门篇。 2. 这个暂时没看出是什么原因。 3.竖线是YAML 的长字符串语法，看前面的课程。 4.是逻辑核。
共 2 条评论1
WenjieXu2023-04-22 来自上海老师，如果一个pod需要加入到service中，是否意味着必须要配置readinessProbe？还是默认不配置的话，k8s会认为是up的，放到对应service的ep对象里？作者回复: 探针不是必须的，如果没有探针kubernetes就不会检查，直接认为是ready。