Kubernetes Health Check学习参考配置存活、就绪和启动探针环境准备rootmaster30:~# kubectl create ns healthrootmaster30:~# kubectl config set-context --current --namespace healthHealth Check应用可能会因为各种问题变的unhealthy例如临时连接断开配置错误应用本身错误。kubelet 使用probes探针周期性地监控容器中应用是否为healthy状态进一步决定什么时候要重启容器。 例如当存活探针可以探测到应用死锁应用在运行但是无法继续执行后面的步骤情况进而重启pod有助于提高应用的可用性即使其中存在缺陷。Probe Typekubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针存活探针和就绪探针成功之前不会重启确保这些探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测避免它们在启动运行之前就被杀掉。LivenessProbe用于确定pod中应用是否处于healthy状态。如果liveness probe检测的状态为unhealthy则控制器将重启创建一个同名的pod。ReadinessProbe用于确定pod中应用是否可以提供服务。如果返回失败状态则**服务将从endpoints 中删除容器ip地址。**即使容器处于运行状态也不接受代理发过来的请求。StartupProbe用于确定pod是否成功初始化。 如果指定则在成功完成之前不会执行其他探测。如果此探测失败Pod 将重新启动就像 livenessProbe 失败一样。 这可用于在 Pod 生命周期开始时提供不同的探测参数此时加载数据或预热缓存可能需要比稳态操作期间更长的时间。 这无法更新。探针核心目的失败动作StartupProbe确认容器初始化完成重启容器成功前禁活 / 就绪探针LivenessProbe确认应用正常存活重启容器ReadinessProbe确认应用可接收流量从 Service 端点摘除 IP不重启Checking Methods探针检查容器有四种不同的方法httpGet对容器的 IP 地址上指定端口和路径执行 HTTPGET请求。如果响应的状态码大于等于 200 且小于 400则诊断被认为是成功的exec在容器内执行指定命令。如果命令退出时返回码为 0则认为诊断成功tcpSocket对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开则诊断被认为是成功的。 如果远程系统容器在打开连接后立即将其关闭这算作是健康的grpc使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC 健康检查。 如果响应的状态是 “SERVING”则认为诊断成功检测方式判断成功标准httpGetHTTP 状态码 200~399exec命令 exit code 0tcpSocketTCP 端口能连通grpcgRPC 健康状态为 SERVINGHTTP Checks-httpGet当使用HTTP Checks控制器使用webhoook判定容器健康情况。如果HTTP的响应码在200-399之间判定check成功。适应范围可以返回HTTP状态码应用。livenessProberootmaster30:~# vim deploy-httpGet-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.html# port填写时间web端口port:80# scheme指定协议HTTP或者HTTPSscheme:HTTPprobe选项说明initialDelaySeconds必选。容器启动后多长时间probe开始生效。timeoutSeconds必选。probe需要多长时间完成。如果超过该值控制器判定probe失败。默认值1s最小值是1秒。periodSeconds可选。检查频率。默认值10s最小值是1秒。successThreshold可选连续成功最少次数后判定probe成功。默认值1最小值是1。failureThreshold可选。连续失败最少次数后判定probe失败。默认值3最小值是1。rootmaster30 ~13:55:40# kubectl apply -f deploy-httpGet-liveness.yamlrootmaster30 ~13:55:52# kubectl get podNAME READY STATUS RESTARTS AGE web-7dfcbbb5df-g55c41/1 Running04s rootmaster30 ~13:55:56# kubectl describe pod web-7dfcbbb5df-g55c4 | grep ^IP:IP:10.224.26.168# 删除主页文件rootmaster30 ~13:56:18# kubectl exec web-7dfcbbb5df-g55c4 -- rm htdocs/index.html# 观察pod状态RESTARTS次数变位1再次访问rootmaster30 ~13:56:31# kubectl get podNAME READY STATUS RESTARTS AGE web-7dfcbbb5df-g55c41/1 Running1(2s ago)79s# 容器删除需要一些时间由参数terminationGracePeriodSeconds设定默认值为30s。# 只有等容器删除并创建完成后才会继续检测rootmaster30 ~13:57:41# curl 10.224.26.168htmlbodyh1It works!/h1/body/html# 清理环境rootmaster30 ~13:57:48# kubectl delete deployments.apps webreadinessProberootmaster30 ~13:58:06# vim deploy-httpGet-readiness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:3selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加readinessProbe部分readinessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.htmlport:80scheme:HTTP# 创建应用rootmaster30 ~13:58:30# kubectl apply -f deploy-httpGet-readiness.yamlrootmaster30 ~13:58:48# kubectl expose deployment web --port80 --target-port80rootmaster30 ~13:59:08# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE web ClusterIP10.106.133.11none80/TCP 6s rootmaster30 ~13:59:14# kubectl get podsNAME READY STATUS RESTARTS AGE web-5d6964b9f5-5hghq1/1 Running044s web-5d6964b9f5-c2tmm1/1 Running044s web-5d6964b9f5-kvrkc1/1 Running044s# 准备3个pod主页文件rootmaster30 ~13:59:32# for pod in $(kubectl get pods -o name | awk -F / {print $2}); do kubectl exec $pod -- bash -c echo $pod htdocs/index.html; donerootmaster30 ~14:00:21# for i in {1..90};do curl -s 10.106.133.11;done| sort|uniq -c30web-5d6964b9f5-5hghq30web-5d6964b9f5-c2tmm30web-5d6964b9f5-kvrkc rootmaster30 ~14:01:18# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.26.169:80,10.224.26.170:80,10.224.71.221:80 2m25s# 删除 web-5d6964b9f5-5hghq主页文件rootmaster30 ~14:01:33# kubectl exec web-5d6964b9f5-5hghq -- rm htdocs/index.html# web 服务的后端没有pod的iprootmaster30 ~14:02:43# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.26.169:80,10.224.26.170:80 4m11s# 访问svc后端无法看到 web-9479dc55c-6bpg7rootmaster30 ~14:03:19# for i in {1..90};do curl -s 10.106.133.11;done|sort |uniq -c45web-5d6964b9f5-c2tmm45web-5d6964b9f5-kvrkc# 观察web-5d6964b9f5-5hghq状态READY为0RESTARTS数量为0rootmaster30 ~14:02:38# kubectl get podNAME READY STATUS RESTARTS AGE web-5d6964b9f5-5hghq0/1 Running03m55s web-5d6964b9f5-c2tmm1/1 Running03m55s web-5d6964b9f5-kvrkc1/1 Running03m55s# 清理环境rootmaster30:~# kubectl delete deployments.apps webExecution Checks-exec当使用容器执行检测kubelet代理将在容器内执行命令。返回值是0代表check成功。示例1检测容器自带文件rootmaster30:~# vim deploy-exec-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-cat-/usr/local/apache2/htdocs/index.html# 创建应用rootmaster30 ~14:38:27# kubectl apply -f deploy-exec-liveness.yamlrootmaster30 ~14:38:41# kubectl get podsNAME READY STATUS RESTARTS AGE web-546966967b-jwjpw1/1 Running012s# 删除主页文件rootmaster30 ~14:38:53# kubectl exec web-546966967b-jwjpw -- rm htdocs/index.html# 观察pod状态RESTARTS次数变位1rootmaster30 ~14:39:11# kubectl get podNAME READY STATUS RESTARTS AGE web-546966967b-jwjpw1/1 Running1(10s ago)53s示例2检测自定义文件rootmaster30 ~14:37:45# kubectl run busybox --imagebusybox --image-pull-policyIfNotPresent -o yaml --dry-runclient busybox.ymlrootmaster30 ~14:40:22# vim deploy-exec-busybox.ymlapiVersion:v1kind:Podmetadata:creationTimestamp:nulllabels:run:busyboxname:busyboxspec:containers:-image:busyboximagePullPolicy:IfNotPresentname:busybox# 添加args参数args:-/bin/sh--c-touch /tmp/healthy; sleep 10; rm-rf /tmp/healthy; sleep 100#添加livenessProbe参数livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-ls-/tmp/healthydnsPolicy:ClusterFirstrestartPolicy:Alwaysrootmaster30 ~14:40:37# kubectl apply -f deploy-exec-busybox.ymlrootmaster30 ~14:40:46# kubectl get podsNAME READY STATUS RESTARTS AGE busybox1/1 Running041s#等待一段时间后发现重启了一次rootmaster30 ~14:41:27# kubectl get podsNAME READY STATUS RESTARTS AGE busybox1/1 Running1(10s ago)65sTCP Socket Checks-tcpSocket当使用TCP socket checkskubelet代理尝试打开容器socket。如果check可以建立连接判定check成功。示例liveness probe使用TCP Socket checkrootmaster30:~# vim deploy-tcpSocket-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10tcpSocket:port:80Health Check CaseHealth Check 在 Scale Up 中的应用对于多副本应用 当执行Scale Up操作时 新副本会作为backend被添加到Service的负载均衡中 与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段 比如加载缓存数据、 连接数据库等 从容器启动到真正能够提供服务是需要一段时间的。 我们可以通过Readiness探测判断容器是否就绪 避免将请求发送到还没有准备好的backend。Health Check 在滚动更新中的应用Health Check另一个重要的应用场景是Rolling Update。 试想一下 现有一个正常运行的多副本应用 接下来对应用进行更新比如使用更高版本的image Kubernetes会启动新副本 然后发生了如下事件正常情况下新副本需要10秒钟完成准备工作 在此之前无法响应业务请求。由于人为配置错误 副本始终无法完成准备工作比如无法连接后端数据库。如果没有配置Health Check 会出现怎样的情况因为新副本本身没有异常退出 默认的Health Check机制会认为容器已经就绪 进而会逐步用新副本替换现有副本 其结果就是 当所有旧副本都被替换后 整个应用将无法处理请求 无法对外提供服务。 如果这是发生在重要的生产系统上 后果会非常严重。如果正确配置了Health Check 新副本只有通过了探测才会被添加到Service 如果没有通过探测 现有副本不会被全部替换 业务仍然正常进行。环境清理rootmaster30:~# kubectl delete ns health 
长河君 · 2026/8/25 12:52:26 · 阅读 1.2k k8s- Health Check
Kubernetes Health Check学习参考配置存活、就绪和启动探针环境准备rootmaster30:~# kubectl create ns healthrootmaster30:~# kubectl config set-context --current --namespace healthHealth Check应用可能会因为各种问题变的unhealthy例如临时连接断开配置错误应用本身错误。kubelet 使用probes探针周期性地监控容器中应用是否为healthy状态进一步决定什么时候要重启容器。 例如当存活探针可以探测到应用死锁应用在运行但是无法继续执行后面的步骤情况进而重启pod有助于提高应用的可用性即使其中存在缺陷。Probe Typekubelet 使用启动探针来了解应用容器何时启动。 如果配置了这类探针存活探针和就绪探针成功之前不会重启确保这些探针不会影响应用的启动。 启动探针可以用于对慢启动容器进行存活性检测避免它们在启动运行之前就被杀掉。LivenessProbe用于确定pod中应用是否处于healthy状态。如果liveness probe检测的状态为unhealthy则控制器将重启创建一个同名的pod。ReadinessProbe用于确定pod中应用是否可以提供服务。如果返回失败状态则**服务将从endpoints 中删除容器ip地址。**即使容器处于运行状态也不接受代理发过来的请求。StartupProbe用于确定pod是否成功初始化。 如果指定则在成功完成之前不会执行其他探测。如果此探测失败Pod 将重新启动就像 livenessProbe 失败一样。 这可用于在 Pod 生命周期开始时提供不同的探测参数此时加载数据或预热缓存可能需要比稳态操作期间更长的时间。 这无法更新。探针核心目的失败动作StartupProbe确认容器初始化完成重启容器成功前禁活 / 就绪探针LivenessProbe确认应用正常存活重启容器ReadinessProbe确认应用可接收流量从 Service 端点摘除 IP不重启Checking Methods探针检查容器有四种不同的方法httpGet对容器的 IP 地址上指定端口和路径执行 HTTPGET请求。如果响应的状态码大于等于 200 且小于 400则诊断被认为是成功的exec在容器内执行指定命令。如果命令退出时返回码为 0则认为诊断成功tcpSocket对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开则诊断被认为是成功的。 如果远程系统容器在打开连接后立即将其关闭这算作是健康的grpc使用 gRPC 执行一个远程过程调用。 目标应该实现 gRPC 健康检查。 如果响应的状态是 “SERVING”则认为诊断成功检测方式判断成功标准httpGetHTTP 状态码 200~399exec命令 exit code 0tcpSocketTCP 端口能连通grpcgRPC 健康状态为 SERVINGHTTP Checks-httpGet当使用HTTP Checks控制器使用webhoook判定容器健康情况。如果HTTP的响应码在200-399之间判定check成功。适应范围可以返回HTTP状态码应用。livenessProberootmaster30:~# vim deploy-httpGet-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.html# port填写时间web端口port:80# scheme指定协议HTTP或者HTTPSscheme:HTTPprobe选项说明initialDelaySeconds必选。容器启动后多长时间probe开始生效。timeoutSeconds必选。probe需要多长时间完成。如果超过该值控制器判定probe失败。默认值1s最小值是1秒。periodSeconds可选。检查频率。默认值10s最小值是1秒。successThreshold可选连续成功最少次数后判定probe成功。默认值1最小值是1。failureThreshold可选。连续失败最少次数后判定probe失败。默认值3最小值是1。rootmaster30 ~13:55:40# kubectl apply -f deploy-httpGet-liveness.yamlrootmaster30 ~13:55:52# kubectl get podNAME READY STATUS RESTARTS AGE web-7dfcbbb5df-g55c41/1 Running04s rootmaster30 ~13:55:56# kubectl describe pod web-7dfcbbb5df-g55c4 | grep ^IP:IP:10.224.26.168# 删除主页文件rootmaster30 ~13:56:18# kubectl exec web-7dfcbbb5df-g55c4 -- rm htdocs/index.html# 观察pod状态RESTARTS次数变位1再次访问rootmaster30 ~13:56:31# kubectl get podNAME READY STATUS RESTARTS AGE web-7dfcbbb5df-g55c41/1 Running1(2s ago)79s# 容器删除需要一些时间由参数terminationGracePeriodSeconds设定默认值为30s。# 只有等容器删除并创建完成后才会继续检测rootmaster30 ~13:57:41# curl 10.224.26.168htmlbodyh1It works!/h1/body/html# 清理环境rootmaster30 ~13:57:48# kubectl delete deployments.apps webreadinessProberootmaster30 ~13:58:06# vim deploy-httpGet-readiness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:3selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加readinessProbe部分readinessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10httpGet:path:/index.htmlport:80scheme:HTTP# 创建应用rootmaster30 ~13:58:30# kubectl apply -f deploy-httpGet-readiness.yamlrootmaster30 ~13:58:48# kubectl expose deployment web --port80 --target-port80rootmaster30 ~13:59:08# kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)AGE web ClusterIP10.106.133.11none80/TCP 6s rootmaster30 ~13:59:14# kubectl get podsNAME READY STATUS RESTARTS AGE web-5d6964b9f5-5hghq1/1 Running044s web-5d6964b9f5-c2tmm1/1 Running044s web-5d6964b9f5-kvrkc1/1 Running044s# 准备3个pod主页文件rootmaster30 ~13:59:32# for pod in $(kubectl get pods -o name | awk -F / {print $2}); do kubectl exec $pod -- bash -c echo $pod htdocs/index.html; donerootmaster30 ~14:00:21# for i in {1..90};do curl -s 10.106.133.11;done| sort|uniq -c30web-5d6964b9f5-5hghq30web-5d6964b9f5-c2tmm30web-5d6964b9f5-kvrkc rootmaster30 ~14:01:18# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.26.169:80,10.224.26.170:80,10.224.71.221:80 2m25s# 删除 web-5d6964b9f5-5hghq主页文件rootmaster30 ~14:01:33# kubectl exec web-5d6964b9f5-5hghq -- rm htdocs/index.html# web 服务的后端没有pod的iprootmaster30 ~14:02:43# kubectl get endpoints webNAME ENDPOINTS AGE web10.224.26.169:80,10.224.26.170:80 4m11s# 访问svc后端无法看到 web-9479dc55c-6bpg7rootmaster30 ~14:03:19# for i in {1..90};do curl -s 10.106.133.11;done|sort |uniq -c45web-5d6964b9f5-c2tmm45web-5d6964b9f5-kvrkc# 观察web-5d6964b9f5-5hghq状态READY为0RESTARTS数量为0rootmaster30 ~14:02:38# kubectl get podNAME READY STATUS RESTARTS AGE web-5d6964b9f5-5hghq0/1 Running03m55s web-5d6964b9f5-c2tmm1/1 Running03m55s web-5d6964b9f5-kvrkc1/1 Running03m55s# 清理环境rootmaster30:~# kubectl delete deployments.apps webExecution Checks-exec当使用容器执行检测kubelet代理将在容器内执行命令。返回值是0代表check成功。示例1检测容器自带文件rootmaster30:~# vim deploy-exec-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-cat-/usr/local/apache2/htdocs/index.html# 创建应用rootmaster30 ~14:38:27# kubectl apply -f deploy-exec-liveness.yamlrootmaster30 ~14:38:41# kubectl get podsNAME READY STATUS RESTARTS AGE web-546966967b-jwjpw1/1 Running012s# 删除主页文件rootmaster30 ~14:38:53# kubectl exec web-546966967b-jwjpw -- rm htdocs/index.html# 观察pod状态RESTARTS次数变位1rootmaster30 ~14:39:11# kubectl get podNAME READY STATUS RESTARTS AGE web-546966967b-jwjpw1/1 Running1(10s ago)53s示例2检测自定义文件rootmaster30 ~14:37:45# kubectl run busybox --imagebusybox --image-pull-policyIfNotPresent -o yaml --dry-runclient busybox.ymlrootmaster30 ~14:40:22# vim deploy-exec-busybox.ymlapiVersion:v1kind:Podmetadata:creationTimestamp:nulllabels:run:busyboxname:busyboxspec:containers:-image:busyboximagePullPolicy:IfNotPresentname:busybox# 添加args参数args:-/bin/sh--c-touch /tmp/healthy; sleep 10; rm-rf /tmp/healthy; sleep 100#添加livenessProbe参数livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10exec:command:-ls-/tmp/healthydnsPolicy:ClusterFirstrestartPolicy:Alwaysrootmaster30 ~14:40:37# kubectl apply -f deploy-exec-busybox.ymlrootmaster30 ~14:40:46# kubectl get podsNAME READY STATUS RESTARTS AGE busybox1/1 Running041s#等待一段时间后发现重启了一次rootmaster30 ~14:41:27# kubectl get podsNAME READY STATUS RESTARTS AGE busybox1/1 Running1(10s ago)65sTCP Socket Checks-tcpSocket当使用TCP socket checkskubelet代理尝试打开容器socket。如果check可以建立连接判定check成功。示例liveness probe使用TCP Socket checkrootmaster30:~# vim deploy-tcpSocket-liveness.yamlapiVersion:apps/v1kind:Deploymentmetadata:labels:app:webname:webspec:replicas:1selector:matchLabels:app:webtemplate:metadata:labels:app:webspec:containers:-image:hub.laoma.cloud/library/httpdimagePullPolicy:IfNotPresentname:httpd# 添加livenessProbe部分livenessProbe:failureThreshold:3initialDelaySeconds:5periodSeconds:5successThreshold:1timeoutSeconds:10tcpSocket:port:80Health Check CaseHealth Check 在 Scale Up 中的应用对于多副本应用 当执行Scale Up操作时 新副本会作为backend被添加到Service的负载均衡中 与已有副本一起处理客户的请求。考虑到应用启动通常都需要一个准备阶段 比如加载缓存数据、 连接数据库等 从容器启动到真正能够提供服务是需要一段时间的。 我们可以通过Readiness探测判断容器是否就绪 避免将请求发送到还没有准备好的backend。Health Check 在滚动更新中的应用Health Check另一个重要的应用场景是Rolling Update。 试想一下 现有一个正常运行的多副本应用 接下来对应用进行更新比如使用更高版本的image Kubernetes会启动新副本 然后发生了如下事件正常情况下新副本需要10秒钟完成准备工作 在此之前无法响应业务请求。由于人为配置错误 副本始终无法完成准备工作比如无法连接后端数据库。如果没有配置Health Check 会出现怎样的情况因为新副本本身没有异常退出 默认的Health Check机制会认为容器已经就绪 进而会逐步用新副本替换现有副本 其结果就是 当所有旧副本都被替换后 整个应用将无法处理请求 无法对外提供服务。 如果这是发生在重要的生产系统上 后果会非常严重。如果正确配置了Health Check 新副本只有通过了探测才会被添加到Service 如果没有通过探测 现有副本不会被全部替换 业务仍然正常进行。环境清理rootmaster30:~# kubectl delete ns health