k8s 查看pod流量_k8s之Pod健康检测

LivenessProbe和ReadinessProb。

LivenessProbe:用于判断容器是否存活,即running状态,如果LivenessProbe探针探测到容器不健康,则kubelet将kill掉容器,并根据容器的重启策略是否重启,如果一个容器不包含LivenessProbe探针,则Kubelet认为容器的LivenessProbe探针的返回值永远成功。

ReadinessProbe探针:用于判断容器是否启动完成,即容器的Ready是否为True,可以接收请求,如果ReadinessProbe探测失败,则Pod的状态将被修改,控制器将此Pod的Endpoint从 对应的service的Endpoint列表中移除,从此以后不再调度此Pod上。

每类探针都支持三种探测方法:

exec: 通过执行命令来检查服务是否正常,针对复杂检测或无HTTP接口的服务,如果该命令的返回值为0表示,则表示容器健康。

httpGet:通过http请求方式检查服务是否正常,返回200-399状态码则容器健康。

tcpSocket:通过容器的IP和Port执行TCP检查,如果能够建立TCP连接,则表明容器健康。

探针探测的结果有以下三者之一:

Success:Container通过了检查。

Failure:Container未通过检查。

Unknown:未能执行检查,因此不采取任何措施。

示例一:通过exec方式做健康探测

exec-liveness.yaml

apiVersion: v1

kind: Pod

metadata:

labels:

test: liveness

name: liveness-exec

spec:

containers:

- name: liveness

image: k8s.gcr.io/busybox

args:

- /bin/sh

- -c

- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600

livenessProbe:

exec:

command:

- cat

- /tmp/healthy

initialDelaySeconds: 5

periodSeconds: 5

在该配置文件中,对容器执行livenessProbe检查,periodSeconds字段指定kubelet每5s执行一次检查,检查的命令为cat /tmp/healthy,initialDelaySeconds字段告诉kubelet应该在执行第一次检查之前等待5秒,

如果命令执行成功,则返回0,那么kubelet就认为容器是健康的,如果为非0,则Kubelet会Kill掉容器并根据重启策略来决定是否需要重启。

当容器启动时,它会执行以下命令:

/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600"

对于容器的前30秒,有一个/tmp/healthy文件。因此,在前30秒内,该命令cat /tmp/healthy返回成功代码。30秒后,cat /tmp/healthy返回失败代码。

创建Pod:

kubectl create -f https://k8s.io/examples/pods/probe/exec-liveness.yaml

在30秒内,查看Pod事件:

kubectl describe pod liveness-exec

输出表明尚未探测到失败:

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

24s 24s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0

23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"

23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"

23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]

23s 23s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e

35秒后,再次查看Pod事件:

kubectl describe pod liveness-exec

在输出的中显示探测失败,并且容器已被杀死并重新创建。

FirstSeen LastSeen Count From SubobjectPath Type Reason Message

--------- -------- ----- ---- ------------- -------- ------ -------

37s 37s 1 {default-scheduler } Normal Scheduled Successfully assigned liveness-exec to worker0

36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulling pulling image "k8s.gcr.io/busybox"

36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Pulled Successfully pulled image "k8s.gcr.io/busybox"

36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Created Created container with docker id 86849c15382e; Security:[seccomp=unconfined]

36s 36s 1 {kubelet worker0} spec.containers{liveness} Normal Started Started container with docker id 86849c15382e

2s 2s 1 {kubelet worker0} spec.containers{liveness} Warning Unhealthy Liveness probe failed: cat: can‘t open ‘/tmp/healthy‘: No such file or directory

再等30秒,确认Container已重新启动:

kubectl get pod liveness-exec

下面输出中RESTARTS的次数已增加:

AME READY STATUS RESTARTS AGE

liveness-exec 1/1 Running 1 1m

示例二:通过HTTP方式做健康检查

pods/probe/http-liveness.yaml

apiVersion: v1

kind: Pod

metadata:

labels:

test: liveness

name: liveness-http

spec:

containers:

- name: liveness

image: k8s.gcr.io/liveness

args:

- /server

livenessProbe:

httpGet:

path: /healthz

port: 8080

httpHeaders:

- name: X-Custom-Header

value: Awesome

initialDelaySeconds: 3

periodSeconds: 3

在配置文件中,使用k8s.gcr.io/liveness镜像,创建出一个Pod,其中periodSeconds字段指定kubelet每3秒执行一次探测,initialDelaySeconds字段告诉kubelet延迟等待3秒,探测方式为向容器中运行的服务发送HTTP GET请求,请求8080端口下的/healthz, 任何大于或等于200且小于400的代码表示成功。任何其他代码表示失败。

创建此Pod

kubectl create -f https://k8s.io/examples/pods/probe/http-liveness.yaml

10秒后,查看Pod事件以验证liveness探测失败并且Container已重新启动:

kubectl describe pod liveness-http

示例三:通过HTTP方式做健康检查

Kubelet将尝试在指定的端口上打开容器上的套接字,如果能建立连接,则表明容器健康。

pods/probe/tcp-liveness-readiness.yaml

apiVersion: v1

kind: Pod

metadata:

name: goproxy

labels:

app: goproxy

spec:

containers:

- name: goproxy

image: k8s.gcr.io/goproxy:0.1

ports:

- containerPort: 8080

readinessProbe:

tcpSocket:

port: 8080

initialDelaySeconds: 5

periodSeconds: 10

livenessProbe:

tcpSocket:

port: 8080

initialDelaySeconds: 15

periodSeconds: 20

TCP检查方式和HTTP检查方式非常相似,示例中两种探针都使用了,在容器启动5秒后,kubelet将发送第一个readinessProbe探针,这将连接到容器的8080端口,

如果探测成功,则该Pod将被标识为ready,10秒后,kubelet将进行第二次连接。

除此之后,此配置还包含了livenessProbe探针,在容器启动15秒后,kubelet将发送第一个livenessProbe探针,仍然尝试连接容器的8080端口,如果连接失败则重启容器。

创建:

kubectl create -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml

15秒后,查看Pod事件以验证活动探测:

kubectl describe pod goproxy

当容器有多个端口时,通常会给每个端口命名,所以在使用探针探测时,也可以直接写自定义的端口名称

ports:

- name: liveness-port

containerPort: 8080

hostPort: 8080

livenessProbe:

httpGet:

path: /healthz

port: liveness-port

ReadinessProbe探针的配置:

有的时候应用程序可能暂时无法接受请求,比如在容器应用程序启动期间加载一些数据或配置文件,在这种情况下,不希望终止应用程序也不让它处理请求,则使用ReadinessProbe探针。

ReadinessProbe探针探测容器是否已准备就绪,如果未准备就绪则kubernetes不会将流量转发给此Pod。

ReadinessProbe探针的配置与livenessProbe的配置方式相似,只不过是将livenessProbe字段修改为ReadinessProbe。

readinessProbe:

exec:

command:

- cat

- /tmp/healthy

initialDelaySeconds: 5

periodSeconds: 5

ReadinessProbe探针的HTTP、TCP的探测方式也与livenessProbe的基本一致。

配置探针(Probe)相关属性

探针(Probe)有许多可选字段,可以用来更加精确的控制Liveness和Readiness两种探针的行为(Probe)

initialDelaySeconds: Pod启动后延迟多久才进行检查,单位:秒

periodSeconds: 检查的间隔时间,默认为10,单位:秒

timeoutSeconds,默认为1,单位秒。

successThreshold:探测失败后认为成功的最小连接成功次数,默认为1,在Liveness探针中必须为1,最小值为1.

failureThreshold:探测失败的重试次数,重试一定次数后将认为失败,在readiness探针中,Pod会被标记为未就绪,默认为3,最小值为1。

httpGe探测方式 t有如下可选的控制字段:

host:要连接的主机名,默认为Pod IP,可以在http request head中设置host头部。

scheme: 用于连接host的协议,默认为HTTP。

path:http服务器上的访问URI

httpHeaders:自定义HTTP请求headers,HTTP允许重复headers.

port: 容器上要访问端口的号或名称。

对于HTTP的检查方式,Kubelet发送HTTP请求到指定的path和port, kubelet发送给host(默认为Pod IP).

你可能感兴趣的:(k8s,查看pod流量)