kubernetes学习-kubectl命令、探针（二）
一、在任意节点使用 kubectl
# 在master节点获取节点信息
[root@k8s-master k8s]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane,master 16h v1.23.6
k8s-node1 Ready <none> 15h v1.23.6
k8s-node2 Ready <none> 15h v1.23.6# 如果在其他节点执行这个命令，报错如下：
[root@k8s-node1 ~]# kubectl get nodes
The connection to the server localhost:8080 was refused - did you specify the right host or port?# 为什么在master节点可以执行上述的命令
# 因为在master节点有如下配置文件
[root@k8s-master k8s]# cat ~/.kube/config
apiVersion: v1 # 指定了这个kubeconfig文件的API版本
clusters: # 定义了可以访问的Kubernetes集群列表
- cluster: # 定义了一个集群的信息certificate-authority-data: LS0tCg== # 集群的证书颁发机构（CA）的证书数据，用于验证服务器的证书server: https://192.168.129.131:6443 # 集群API服务器的地址和端口name: kubernetes # 集群的名称，用于在上下文中引用
contexts: # 定义了上下文列表，上下文是集群和用户信息的组合，用于确定如何访问集群
- context: # 定义了一个上下文的信息cluster: kubernetes # 指定这个上下文使用的集群名称user: kubernetes-admin # 指定这个上下文使用的用户名称name: kubernetes-admin@kubernetes # 这个上下文的名称，用于在配置中引用
current-context: kubernetes-admin@kubernetes # 指定当前使用的上下文名称。这意味着当你使用kubectl命令时，默认会使用这个上下文来访问Kubernetes集群
kind: Config # 指定了这个文件的类型是Kubernetes配置
preferences: {} # 这个部分用于存储用户的偏好设置，这里为空，表示没有特定的偏好设置
users: # 部分定义了可以访问Kubernetes集群的用户列表
- name: kubernetes-admin # 用户的名称user: # 定义了用户的具体信息client-certificate-data: LS0tCg== # 这是用户的客户端证书数据，用于客户端认证client-key-data: LS0tLS= # 这是用户的客户端私钥数据，用于签名请求# 但是另外两台机器并没有这个配置文件，所以无法访问到API server服务# 1. 将 master 节点中 /etc/kubernetes/admin.conf 拷贝到需要运行的服务器的 /etc/kubernetes 目录中
scp /etc/kubernetes/admin.conf root@k8s-node1:/etc/kubernetes
scp /etc/kubernetes/admin.conf root@k8s-node2:/etc/kubernetes# 2. 在对应的服务器上配置环境变量
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
source ~/.bash_profile# 此时在其他节点都可以使用kubectl命令了
[root@k8s-node1 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane,master 16h v1.23.6
k8s-node1 Ready <none> 15h v1.23.6
k8s-node2 Ready <none> 15h v1.23.6[root@k8s-node2 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane,master 16h v1.23.6
k8s-node1 Ready <none> 15h v1.23.6
k8s-node2 Ready <none> 15h v1.23.6
kubernetes的命令文档：Kubectl Reference Docs
# 查看命令空间
[root@k8s-master k8s]# kubectl get ns
NAME STATUS AGE
default Active 16h
kube-node-lease Active 16h
kube-public Active 16h
kube-system Active 16h# 查看pod，不指定命名空间，使用默认命令空间
[root@k8s-master k8s]# kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-85b98978db-zwnkq 1/1 Running 0 37m# 获取deploy
[root@k8s-master k8s]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 1/1 1 1 38m# 扩容
[root@k8s-master k8s]# kubectl scale deploy --replicas=3 nginx
deployment.apps/nginx scaled# 查看效果
[root@k8s-master k8s]# kubectl get deploy
NAME READY UP-TO-DATE AVAILABLE AGE
nginx 3/3 3 3 42m[root@k8s-master k8s]# kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-85b98978db-h2dl6 1/1 Running 0 39s
nginx-85b98978db-jfvf7 0/1 ContainerCreating 0 39s
nginx-85b98978db-zwnkq 1/1 Running # 查看详细信息
[root@k8s-master k8s]# kubectl get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-85b98978db-h2dl6 1/1 Running 0 2m24s 10.244.169.130 k8s-node2 <none> <none>
nginx-85b98978db-jfvf7 1/1 Running 0 2m24s 10.244.36.65 k8s-node1 <none> <none>
nginx-85b98978db-zwnkq 1/1 Running 0 42m 10.244.169.129 k8s-node2 <none> <none>可以看到pod随机部署在了不同的节点上，从这里发现了之前集群初始化的时候，指定的cidr的作用了--pod-network-cidr=10.244.0.0/16这个参数应该是用来指定pod的IP的前缀，不同长度的前缀，可以不用不同规模的pod大小# 查看deploy的配置文件，以yaml格式输出
[root@k8s-master k8s]# kubectl get deploy nginx -o yaml
apiVersion: apps/v1 # 指定了使用的Kubernetes API版本，这里是apps/v1，适用于大多数部署（Deployments）资源。
kind: Deployment # 指定了这是一个Deployment资源
metadata: # 元数据annotations: # 包含了部署的注解信息，例如deployment.kubernetes.io/revision: "1"表示这个部署的版本号是1deployment.kubernetes.io/revision: "1"creationTimestamp: "2024-12-29T08:16:20Z"generation: 2 # 当前对象的生成号，每次对象被更新时，这个值会增加labels: # 包含了标签信息，这里有一个app: nginx标签，用于选择和过滤资源app: nginxname: nginx # 部署的名称，这里是nginxnamespace: default # 部署所在的命名空间，这里是defaultresourceVersion: "84930" # 资源的版本号，每次对象被修改时，Kubernetes都会增加这个版本号uid: d1e7e9c1-a2f9-4142-b43c-dcf83397fd13 # 资源的唯一标识符
spec: # 规格progressDeadlineSeconds: 600 # 部署进度截止时间，单位是秒。如果在这个时间内没有达到期望的状态，部署会被认为是失败的。replicas: 3 # 期望的副本数量，这里是3，意味着Kubernetes会尝试保持3个运行的nginx副本revisionHistoryLimit: 10 # 保留的旧版本（revision）数量，这里是10。selector: # 用于选择哪些Pod属于这个部署的标签选择器matchLabels: # 匹配标签app: nginx的Pod会被选中app: nginxstrategy: # 更新策略rollingUpdate: # 滚动更新策略maxSurge: 25% # 在滚动更新期间，允许的最大额外副本数量，这里是25%，意味着最多可以有原始副本数量的25%作为额外副本maxUnavailable: 25% # 在滚动更新期间，允许的最大不可用副本数量，这里也是25%type: RollingUpdate # 更新类型，这里是RollingUpdatetemplate: # Pod模板metadata: # Pod的元数据，包括标签app: nginxcreationTimestamp: nulllabels:app: nginxspec: # Pod的规格containers:- image: nginx # 容器使用的镜像，这里是nginximagePullPolicy: Always # 镜像拉取策略，这里是Always，表示总是从远程仓库拉取镜像name: nginx # 容器名称，这里是nginxresources: {} # 资源限制，这里是空的，表示没有设置terminationMessagePath: /dev/termination-log # 用于容器终止时的消息处理terminationMessagePolicy: FilednsPolicy: ClusterFirst # DNS策略，这里是ClusterFirst，表示首先使用集群的DNSrestartPolicy: Always # 重启策略，这里是Always，表示容器总是会被重启schedulerName: default-scheduler # 调度器名称，这里是default-schedulersecurityContext: {} # 安全上下文，这里是空的terminationGracePeriodSeconds: 30 # 终止宽限期，单位是秒，这里是30秒。
status: # 状态availableReplicas: 3 # 当前可用的副本数量，这里是3conditions: # 部署的状态条件列表,包括进度条件（Progressing）和可用性条件（Available），每个条件都有状态（True/False）、类型、原因、消息和时间戳等信息- lastTransitionTime: "2024-12-29T08:16:20Z"lastUpdateTime: "2024-12-29T08:18:23Z"message: ReplicaSet "nginx-85b98978db" has successfully progressed.reason: NewReplicaSetAvailablestatus: "True"type: Progressing- lastTransitionTime: "2024-12-29T08:58:30Z"lastUpdateTime: "2024-12-29T08:58:30Z"message: Deployment has minimum availability.reason: MinimumReplicasAvailablestatus: "True"type: AvailableobservedGeneration: 2 # 观察到的部署代数，与generation字段对应，表示当前的部署状态与哪一代部署规格相匹配readyReplicas: 3 # 当前准备就绪的副本数量，这里是3replicas: 3 # 当前的副本数量，这里是3updatedReplicas: 3 # 已更新的副本数量，这里是3，表示所有的副本都已经被更新到最新的版本
二、资源操作
（1）创建对象
$ kubectl create -f ./my-manifest.yaml # 创建资源
$ kubectl create -f ./my1.yaml -f ./my2.yaml # 使用多个文件创建资源
$ kubectl create -f ./dir # 使用目录下的所有清单文件来创建资源
$ kubectl create -f https://git.io/vPieo # 使用 url 来创建资源
$ kubectl run nginx --image=nginx # 启动一个 nginx 实例
$ kubectl explain pods,svc # 获取 pod 和 svc 的文档# 从 stdin 输入中创建多个 YAML 对象
$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:name: busybox-sleep
spec:containers:- name: busyboximage: busyboxargs:- sleep- "1000000"
---
apiVersion: v1
kind: Pod
metadata:name: busybox-sleep-less
spec:containers:- name: busyboximage: busyboxargs:- sleep- "1000"
EOF# 创建包含几个 key 的 Secret
$ cat <<EOF | kubectl create -f -
apiVersion: v1
kind: Secret
metadata:name: mysecret
type: Opaque
data:password: $(echo "s33msi4" | base64)username: $(echo "jane" | base64)
EOF（2）显示和查找资源
# Get commands with basic output
$ kubectl get services # 列出所有 namespace 中的所有 service
$ kubectl get pods --all-namespaces # 列出所有 namespace 中的所有 pod
$ kubectl get pods -o wide # 列出所有 pod 并显示详细信息
$ kubectl get deployment my-dep # 列出指定 deployment
$ kubectl get pods --include-uninitialized # 列出该 namespace 中的所有 pod 包括未初始化的# 使用详细输出来描述命令
$ kubectl describe nodes my-node
$ kubectl describe pods my-pod$ kubectl get services --sort-by=.metadata.name # List Services Sorted by Name# 根据重启次数排序列出 pod
$ kubectl get pods --sort-by='.status.containerStatuses[0].restartCount'# 获取所有具有 app=cassandra 的 pod 中的 version 标签
$ kubectl get pods --selector=app=cassandra rc -o \jsonpath='{.items[*].metadata.labels.version}'# 获取所有节点的 ExternalIP
$ kubectl get nodes -o jsonpath='{.items[*].status.addresses[?(@.type=="ExternalIP")].address}'# 列出属于某个 PC 的 Pod 的名字
# “jq”命令用于转换复杂的 jsonpath，参考 https://stedolan.github.io/jq/
$ sel=${$(kubectl get rc my-rc --output=json | jq -j '.spec.selector | to_entries | .[] | "\(.key)=\(.value),"')%?}
$ echo $(kubectl get pods --selector=$sel --output=jsonpath={.items..metadata.name})# 查看哪些节点已就绪
$ JSONPATH='{range .items[*]}{@.metadata.name}:{range @.status.conditions[*]}{@.type}={@.status};{end}{end}' \&& kubectl get nodes -o jsonpath="$JSONPATH" | grep "Ready=True"# 列出当前 Pod 中使用的 Secret
$ kubectl get pods -o json | jq '.items[].spec.containers[].env[]?.valueFrom.secretKeyRef.name' | grep -v null | sort | uniq（3）更新资源
$ kubectl rolling-update frontend-v1 -f frontend-v2.json # 滚动更新 pod frontend-v1
$ kubectl rolling-update frontend-v1 frontend-v2 --image=image:v2 # 更新资源名称并更新镜像
$ kubectl rolling-update frontend --image=image:v2 # 更新 frontend pod 中的镜像
$ kubectl rolling-update frontend-v1 frontend-v2 --rollback # 退出已存在的进行中的滚动更新
$ cat pod.json | kubectl replace -f - # 基于 stdin 输入的 JSON 替换 pod# 强制替换，删除后重新创建资源。会导致服务中断。
$ kubectl replace --force -f ./pod.json# 为 nginx RC 创建服务，启用本地 80 端口连接到容器上的 8000 端口
$ kubectl expose rc nginx --port=80 --target-port=8000# 更新单容器 pod 的镜像版本（tag）到 v4
$ kubectl get pod mypod -o yaml | sed 's/\(image: myimage\):.*$/\1:v4/' | kubectl replace -f -$ kubectl label pods my-pod new-label=awesome # 添加标签
$ kubectl annotate pods my-pod icon-url=http://goo.gl/XXBTWq # 添加注解
$ kubectl autoscale deployment foo --min=2 --max=10 # 自动扩展 deployment “foo”（4）修补资源
$ kubectl patch node k8s-node-1 -p '{"spec":{"unschedulable":true}}' # 部分更新节点# 更新容器镜像； spec.containers[*].name 是必须的，因为这是合并的关键字
$ kubectl patch pod valid-pod -p '{"spec":{"containers":[{"name":"kubernetes-serve-hostname","image":"new image"}]}}'# 使用具有位置数组的 json 补丁更新容器镜像
$ kubectl patch pod valid-pod --type='json' -p='[{"op": "replace", "path": "/spec/containers/0/image", "value":"new image"}]'# 使用具有位置数组的 json 补丁禁用 deployment 的 livenessProbe
$ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", "path": "/spec/template/spec/containers/0/livenessProbe"}]'（5）编辑资源
$ kubectl edit svc/docker-registry # 编辑名为 docker-registry 的 service
$ KUBE_EDITOR="nano" kubectl edit svc/docker-registry # 使用其它编辑器（6）scale资源
$ kubectl scale --replicas=3 rs/foo # Scale a replicaset named 'foo' to 3
$ kubectl scale --replicas=3 -f foo.yaml # Scale a resource specified in "foo.yaml" to 3
$ kubectl scale --current-replicas=2 --replicas=3 deployment/mysql # If the deployment named mysql's current size is 2, scale mysql to 3
$ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multiple replication controllers
（7）删除资源
$ kubectl delete -f ./pod.json # 删除 pod.json 文件中定义的类型和名称的 pod
$ kubectl delete pod,service baz foo # 删除名为“baz”的 pod 和名为“foo”的 service
$ kubectl delete pods,services -l name=myLabel # 删除具有 name=myLabel 标签的 pod 和 serivce
$ kubectl delete pods,services -l name=myLabel --include-uninitialized # 删除具有 name=myLabel 标签的 pod 和 service，包括尚未初始化的
$ kubectl -n my-ns delete po,svc --all # 删除 my-ns namespace 下的所有 pod 和 serivce，包括尚未初始化的[root@k8s-master k8s]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 19h
nginx NodePort 10.106.36.179 <none> 80:32268/TCP 3h39m[root@k8s-master k8s]# kubectl delete svc nginx
service "nginx" deleted三、创建一个Pod
# 编写配置文件 nginx-demo.yaml
apiVersion: v1 # api 版本
kind: Pod # 资源类型
metadata: # Pod 相关的元数据，用于描述Pod的数据name: nginx-demo # Pod 的名称labels: # 定义Pod的标签type: appversion: 1.0.0 # 自定义的Pod的版本namespace: 'default' # 命名空间
spec: # 期望Pod按照下面的描述信息进行创建containers: # 描述Pod中的容器- name: nginx # 容器名称image: nginx:1.7.9 # 容器镜像imagePullPolicy: IfNotPresent # 镜像拉取策略command: # 指定容器启动时执行的命令- nginx- -g- 'daemon off;' # nginx -g 'daemon off;'workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录ports:- name: http # 端口名称containerPort: 80 # 描述容器内部暴露的端口protocol: TCP # 指定通讯协议env:- name: JVM_OPTS # 环境变量名称value: '-Xms128m -Xmx128m' # 环境变量值resources:requests: # 最少需要多少资源cpu: 100m # 限制最少使用 0.1 个 cpu 核心memory: 128Mi # 最少使用 128 Mlimits:cpu: 200m # 最多使用0.2个cpu核心memory: 256Mi # 最多使用256MrestartPolicy: OnFailure # 重启策略# 根据配置文件创建资源
[root@k8s-master pods]# kubectl create -f nginx-demo.yaml
pod/nginx-demo created# 查看创建的pod
[root@k8s-master pods]# kubectl get po
NAME READY STATUS RESTARTS AGE
nginx-demo 0/1 ImagePullBackOff 0 2m27s# 上面的输出看到镜像拉取失败了，手动改了一下nginx-demo.yaml中的镜像，删除了后面的版本指定
# 删除pod，重新创建# 查看重新构建之后的pod的信息
[root@k8s-master pods]# kubectl get po nginx-demo -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-demo 1/1 Running 0 60s 10.244.36.67 k8s-node1 <none> <none>该pod位于 k8s-node1，访问 curl 10.244.36.67
[root@k8s-master pods]# curl 10.244.36.67
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p><p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p>
</body>
</html>没有指定端口，也可以实现访问，
查看路由信息
[root@k8s-master pods]# ip route show
default via 192.168.129.2 dev ens33 proto dhcp metric 100
10.244.36.64/26 via 192.168.129.132 dev tunl0 proto bird onlink
10.244.169.128/26 via 192.168.129.133 dev tunl0 proto bird onlink
blackhole 10.244.235.192/26 proto bird
10.244.235.208 dev cali2bc6c55610c scope link
10.244.235.209 dev calif2d5c75b225 scope link
10.244.235.210 dev cali62a7910352c scope link
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.129.0/24 dev ens33 proto kernel scope link src 192.168.129.131 metric 100 10.244.36.64/26网段指向了192.168.129.132网关，该网关就是k8s-node1，
再到k8s-node1节点查看路由信息
[root@k8s-node1 ~]# ip route show
default via 192.168.129.2 dev ens33
blackhole 10.244.36.64/26 proto bird
10.244.36.67 dev cali7543b7f115c scope link
10.244.169.128/26 via 192.168.129.133 dev tunl0 proto bird onlink
10.244.235.192/26 via 192.168.129.131 dev tunl0 proto bird onlink
169.254.0.0/16 dev ens33 scope link metric 1002
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
192.168.129.0/24 dev ens33 proto kernel scope link src 192.168.129.132 可以看到10.244.36.67 dev cali7543b7f115c scope link 的IP地址了docker设置代理：
彻底解决docker：docker: Get https://registry-1.docker.io/v2/: net/http: request canceled 报错-CSDN博客
如何优雅的给 Docker 配置网络代理 - CharyGao - 博客园
四、探针
（1）类型
（a）StartupProbe:（启动探针）是一种重要的健康检查机制，主要用于检测容器内的应用是否已经成功启动并完成初始化任务
- 延缓其他探针生效：在容器启动初期，StartupProbe先于存活探针（LivenessProbe）和就绪探针（ReadinessProbe）生效。当StartupProbe配置存在时，kubelet不会执行LivenessProbe和ReadinessProbe，直到StartupProbe成功为止。这对于某些启动时间较长或者启动过程中有复杂初始化序列的应用程序来说非常重要，可以避免在应用还未完全启动时就被误判为不健康或就绪，进而被错误地重启或流量过早涌入。
- 防止频繁重启：若应用启动期间，LivenessProbe或ReadinessProbe就开始工作，而此时应用可能还没有完全启动成功，这两个探针可能会因为应用未能及时响应而触发容器重启，造成不必要的服务中断和循环重启。StartupProbe的存在可以有效地防止此类情况的发生。
- 确保应用稳定：StartupProbe使得Kubernetes能够在应用真正启动完毕后才将其视为健康的，并开始接受流量，从而保障了集群中应用服务的稳定性。
StartupProbe的配置通常是在Pod的YAML文件中进行的，可以通过HTTP GET请求、TCP Socket检查或执行命令三种方式来实现健康检查。以下是一些关键的配置参数：
- initialDelaySeconds：容器启动后等待多少秒后探针才开始工作，默认是0秒。这个参数可以根据应用的启动时间来设置，以确保探针在应用完全启动后才开始检查。
- periodSeconds：执行探测的时间间隔，默认为10秒。这个参数决定了探针多久检查一次应用的健康状态。
- timeoutSeconds：探针执行检测请求后，等待响应的超时时间，默认为1秒。如果在这个时间内没有收到响应，则认为探测失败。
- failureThreshold：探测失败的重试次数，重试一定次数后认为失败。这个参数可以根据应用的稳定性和健康检查的重要性来设置。
- successThreshold：探针在失败后，被视为成功的最小连续成功数。对于StartupProbe来说，这个值通常是1，表示只要有一次成功探测，就可以认为应用已经启动完成。
以下是一个使用HTTP GET请求方式配置StartupProbe的示例：
apiVersion: v1
kind: Pod
metadata:name: mypod
spec:containers:- name: mycontainerimage: myimagestartupProbe:httpGet:path: /startupport: 80initialDelaySeconds: 10periodSeconds: 5timeoutSeconds: 2failureThreshold: 30successThreshold: 1在这个示例中，StartupProbe会在容器启动后等待10秒才开始工作，然后每5秒检查一次应用的健康状态。如果连续30次探测失败，则认为应用启动失败。但只要有一次成功探测，kubelet就会停止执行StartupProbe，并开始执行LivenessProbe和ReadinessProbe。
（b）LivenessProbe（存活探针）是Kubernetes（k8s）中用于检测容器内主进程或服务是否仍然运行正常且响应健康检查的关键机制。
LivenessProbe的主要目的是确保容器内应用程序的可用性和稳定性。当检测到容器不健康时，Kubernetes会采取相应措施（如重启容器）来恢复服务的正常运行。
LivenessProbe的配置通常包括以下几个关键参数：
- initialDelaySeconds：容器启动后等待多少秒后探针才开始工作。这个参数可以根据应用的启动时间来设置，以确保探针在应用完全启动后才开始检查。
- periodSeconds：执行探测的时间间隔。这个参数决定了探针多久检查一次应用的健康状态。
- timeoutSeconds：探针执行检测请求后，等待响应的超时时间。如果在这个时间内没有收到响应，则认为探测失败。
- failureThreshold：探测失败的重试次数。如果探测失败次数达到这个阈值，则Kubernetes将认为容器不健康，并根据重启策略采取行动。
- successThreshold：探测成功的最小连续次数。只有连续探测成功达到这个次数，才认为容器是健康的。
LivenessProbe支持多种探测方式来检查容器的健康状态，包括：
- ExecAction：在容器内执行一个命令，如果命令的退出状态码为0，则认为探测成功。这种方式适用于需要执行特定命令来检查应用健康状态的场景。
- TCPSocketAction：尝试与容器的指定端口建立TCP连接，如果连接成功，则认为探测成功。这种方式适用于只需要检查端口是否开放来确认应用健康状态的场景。
- HTTPGetAction：向容器的指定端口和路径发送一个HTTP GET请求，如果响应的状态码在200到400之间，则认为探测成功。这种方式适用于需要检查HTTP服务是否响应来确认应用健康状态的场景。
以下是一个使用HTTP GET请求方式配置LivenessProbe的示例：
apiVersion: v1
kind: Pod
metadata:name: example-pod
spec:containers:- name: example-containerimage: example-imagelivenessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 3periodSeconds: 10timeoutSeconds: 1failureThreshold: 3successThreshold: 1在这个示例中，LivenessProbe会在容器启动后等待3秒才开始工作，然后每10秒检查一次应用的健康状态。如果连续3次探测失败，则认为容器不健康，并可能触发容器的重启操作。
（c）ReadinessProbe（就绪探针）是Kubernetes中一种重要的健康检查机制，用于判断容器是否已经准备好接收请求。
ReadinessProbe的主要作用是确保只有健康的、已经准备好处理请求的容器才会被加入到Service的后端Endpoint列表中，从而接收来自外部的请求。如果容器没有通过ReadinessProbe的检查，它将被从Endpoint列表中移除，暂停接收请求。这有助于防止将流量发送到尚未准备好的容器，提高系统的稳定性和可靠性。
ReadinessProbe的配置参数与LivenessProbe类似，但它们的用途和触发条件不同。以下是一些关键的配置参数：
- initialDelaySeconds：容器启动后等待多少秒后探针才开始工作。这个参数可以根据应用的启动时间和初始化时间来设置。
- periodSeconds：执行探测的时间间隔。这个参数决定了探针多久检查一次容器的就绪状态。
- timeoutSeconds：探针执行检测请求后，等待响应的超时时间。如果在这个时间内没有收到响应，则认为探测失败。
- failureThreshold：探测失败的重试次数。如果探测失败次数达到这个阈值，则容器被认为是不就绪的。
- successThreshold：探测成功的最小连续次数。只有连续探测成功达到这个次数，才认为容器是就绪的。
ReadinessProbe在以下场景中非常有用：
- 滚动更新：在滚动更新过程中，新的Pod会逐渐替换旧的Pod。通过配置ReadinessProbe，可以确保只有新的Pod完全就绪后才开始接收流量，从而避免服务中断。
- 资源限制：当容器受到资源限制（如CPU或内存不足）时，可能会导致应用无法及时处理请求。通过配置ReadinessProbe，可以在资源不足时暂停向受影响的容器发送请求，从而保护系统的稳定性。
- 依赖服务：如果容器依赖于其他服务（如数据库或外部API），则可以通过配置ReadinessProbe来确保这些依赖服务已经可用后再接收请求。
以下是一个使用HTTP GET请求方式配置ReadinessProbe的示例：
apiVersion: v1
kind: Pod
metadata:name: example-pod
spec:containers:- name: example-containerimage: example-imagereadinessProbe:httpGet:path: /readyport: 8080initialDelaySeconds: 5periodSeconds: 10timeoutSeconds: 2failureThreshold: 3successThreshold: 1在这个示例中，ReadinessProbe会在容器启动后等待5秒才开始工作，然后每10秒检查一次容器的就绪状态。如果连续3次探测失败，则认为容器是不就绪的，并将其从Service的Endpoint列表中移除。
（2）探测方式
（a）ExecAction：
以下是一个使用ExecAction探测方式配置ReadinessProbe的示例YAML文件：
apiVersion: v1
kind: Pod
metadata:name: readiness-probe-exec-example
spec:containers:- name: my-containerimage: my-image:latestreadinessProbe:exec:command: ["/bin/sh", "-c", "my-readiness-check-command"]initialDelaySeconds: 5periodSeconds: 10timeoutSeconds: 2failureThreshold: 3successThreshold: 1在这个示例中：
command字段指定了要执行的命令和参数。在这个例子中，/bin/sh -c用于在容器中执行一个shell命令，my-readiness-check-command是实际要执行的检查就绪状态的命令（需要替换为实际的命令）。initialDelaySeconds设置为5秒，表示容器启动后等待5秒才开始执行就绪探测。periodSeconds设置为10秒，表示每隔10秒执行一次就绪探测。timeoutSeconds设置为2秒，表示探测命令的超时时间为2秒。failureThreshold设置为3，表示如果连续3次探测失败，则认为容器未就绪。successThreshold设置为1，表示只需要一次探测成功，就认为容器已经就绪。
（b）TCPSocketAction：
以下是一个使用TCPSocketAction探测方式配置ReadinessProbe的示例YAML文件：
apiVersion: v1
kind: Pod
metadata:name: readiness-probe-tcp-example
spec:containers:- name: my-containerimage: my-image:latestports:- containerPort: 8080readinessProbe:tcpSocket:port: 8080initialDelaySeconds: 5periodSeconds: 10timeoutSeconds: 2failureThreshold: 3successThreshold: 1在这个示例中：
port字段指定了要连接的容器端口（8080）。initialDelaySeconds设置为5秒，表示容器启动后等待5秒才开始执行就绪探测。periodSeconds设置为10秒，表示每隔10秒执行一次就绪探测。timeoutSeconds设置为2秒，表示探测请求的超时时间为2秒。failureThreshold设置为3，表示如果连续3次探测失败，则认为容器未就绪。successThreshold设置为1，表示只需要一次探测成功，就认为容器已经就绪。
（c）HTTPGetAction：
ReadinessProbe的HTTPGetAction探测方式是一种通过向容器的特定端口和路径发送HTTP GET请求来检查容器就绪状态的方法。如果请求返回的状态码在200到399之间，则认为容器已经就绪；如果返回其他状态码，则认为容器未就绪。
以下是一个使用HTTPGetAction探测方式配置ReadinessProbe的示例YAML文件：
apiVersion: v1
kind: Pod
metadata:name: readiness-probe-http-example
spec:containers:- name: my-containerimage: my-image:latestports:- containerPort: 8080readinessProbe:httpGet:path: /healthzport: 8080scheme: HTTPinitialDelaySeconds: 5periodSeconds: 10timeoutSeconds: 2failureThreshold: 3successThreshold: 1在这个示例中：
path字段指定了要请求的HTTP路径（/healthz）。这通常是应用提供的健康检查端点。port字段指定了要连接的容器端口（8080）。scheme字段指定了请求的协议方案为HTTP（默认为HTTP，也可以设置为HTTPS）。initialDelaySeconds设置为5秒，表示容器启动后等待5秒才开始执行就绪探测。periodSeconds设置为10秒，表示每隔10秒执行一次就绪探测。timeoutSeconds设置为2秒，表示探测请求的超时时间为2秒。failureThreshold设置为3，表示如果连续3次探测失败，则认为容器未就绪。successThreshold设置为1，表示只需要一次探测成功，就认为容器已经就绪。
测试startupProbe的httpGet方式：
# 删除之前的pod
[root@k8s-master pods]# kubectl delete po nginx-demo# 重新编辑配置文件
[root@k8s-master pods]# vim nginx-demo.yaml
[root@k8s-master pods]# cat nginx-demo.yaml
apiVersion: v1 # api 版本
kind: Pod # 资源类型
metadata: # Pod 相关的元数据，用于描述Pod的数据name: nginx-demo # Pod 的名称labels: # 定义Pod的标签type: appversion: 1.0.0 # 自定义的Pod的版本namespace: 'default' # 命名空间
spec: # 期望Pod按照下面的描述信息进行创建containers: # 描述Pod中的容器- name: nginx # 容器名称image: nginx # 容器镜像imagePullPolicy: IfNotPresent # 镜像拉取策略startupProbe: # 应用启动探针httpGet: # 探测方式, 基于http 请求探测path: /api/path # http请求路径port: 80 # 请求端口failureThreshold: 3 # 失败3次即为失败periodSeconds: 10 # 间隔时间successThreshold: 1 # 多少次检测成功算成功timeoutSeconds: 5 # 请求超时时间command: # 指定容器启动时执行的命令- nginx- -g- 'daemon off;' # nginx -g 'daemon off;'workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录ports:- name: http # 端口名称containerPort: 80 # 描述容器内部暴露的端口protocol: TCP # 指定通讯协议env:- name: JVM_OPTS # 环境变量名称value: '-Xms128m -Xmx128m' # 环境变量值resources:requests: # 最少需要多少资源cpu: 100m # 限制最少使用 0.1 个 cpu 核心memory: 128Mi # 最少使用 128 Mlimits:cpu: 200m # 最多使用0.2个cpu核心memory: 256Mi # 最多使用256MrestartPolicy: OnFailure # 重启策略# 由于上面写的api路径不存在，会导致应用无法启动
# 创建pod
[root@k8s-master pods]# kubectl create -f nginx-demo.yaml
pod/nginx-demo created
# 查看描述信息
[root@k8s-master pods]# kubectl describe po nginx-demo
Name: nginx-demo
Namespace: default
Priority: 0
Node: k8s-node1/192.168.129.132
Start Time: Thu, 02 Jan 2025 23:15:20 +0800
Labels: type=appversion=1.0.0
Annotations: cni.projectcalico.org/containerID: f1b496c329c4d30bfb0ae7d2132c1ec1edb85374079810af5d03a907df17d592cni.projectcalico.org/podIP: 10.244.36.68/32cni.projectcalico.org/podIPs: 10.244.36.68/32
Status: Running
IP: 10.244.36.68
IPs:IP: 10.244.36.68
Containers:nginx:Container ID: docker://8e54415669056ee3700a6da59a6475e6c206037bf860f15a22af6a12ded5795bImage: nginxImage ID: docker-pullable://nginx@sha256:42e917aaa1b5bb40dd0f6f7f4f857490ac7747d7ef73b391c774a41a8b994f15Port: 80/TCPHost Port: 0/TCPCommand:nginx-gdaemon off;State: RunningStarted: Thu, 02 Jan 2025 23:16:50 +0800Last State: TerminatedReason: CompletedExit Code: 0Started: Thu, 02 Jan 2025 23:16:20 +0800Finished: Thu, 02 Jan 2025 23:16:50 +0800Ready: FalseRestart Count: 3Limits:cpu: 200mmemory: 256MiRequests:cpu: 100mmemory: 128MiStartup: http-get http://:80/api/path delay=0s timeout=5s period=10s #success=1 #failure=3Environment:JVM_OPTS: -Xms128m -Xmx128mMounts:/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-4s56j (ro)
Conditions:Type StatusInitialized True Ready False ContainersReady False PodScheduled True
Volumes:kube-api-access-4s56j:Type: Projected (a volume that contains injected data from multiple sources)TokenExpirationSeconds: 3607ConfigMapName: kube-root-ca.crtConfigMapOptional: <nil>DownwardAPI: true
QoS Class: Burstable
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300snode.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:Type Reason Age From Message---- ------ ---- ---- -------Normal Scheduled 99s default-scheduler Successfully assigned default/nginx-demo to k8s-node1Normal Pulled 9s (x4 over 99s) kubelet Container image "nginx" already present on machineNormal Created 9s (x4 over 98s) kubelet Created container nginxNormal Started 9s (x4 over 98s) kubelet Started container nginxWarning Unhealthy 9s (x9 over 89s) kubelet Startup probe failed: HTTP probe failed with statuscode: 404Normal Killing 9s (x3 over 69s) kubelet Container nginx failed startup probe, will be restarted
从描述信息中可以看到startupProbe探针失败：
测试startupProbe的exec方式：
[root@k8s-master pods]# vim nginx-demo.yaml
[root@k8s-master pods]# cat nginx-demo.yaml
apiVersion: v1 # api 版本
kind: Pod # 资源类型
metadata: # Pod 相关的元数据，用于描述Pod的数据name: nginx-po # Pod 的名称labels: # 定义Pod的标签type: appversion: 1.0.0 # 自定义的Pod的版本namespace: 'default' # 命名空间
spec: # 期望Pod按照下面的描述信息进行创建containers: # 描述Pod中的容器- name: nginx # 容器名称image: nginx # 容器镜像imagePullPolicy: IfNotPresent # 镜像拉取策略startupProbe: # 应用启动探针# httpGet: # 探测方式, 基于http 请求探测# path: /index.html # http请求路径# port: 80 # 请求端口exec:command:- sh- -c- "sleep 5; echo 'success' > /inited;"failureThreshold: 3 # 失败3次即为失败periodSeconds: 10 # 间隔时间successThreshold: 1 # 多少次检测成功算成功timeoutSeconds: 5 # 请求超时时间command: # 指定容器启动时执行的命令- nginx- -g- 'daemon off;' # nginx -g 'daemon off;'workingDir: /usr/share/nginx/html # 定义容器启动后的工作目录ports:- name: http # 端口名称containerPort: 80 # 描述容器内部暴露的端口protocol: TCP # 指定通讯协议env:- name: JVM_OPTS # 环境变量名称value: '-Xms128m -Xmx128m' # 环境变量值resources:requests: # 最少需要多少资源cpu: 100m # 限制最少使用 0.1 个 cpu 核心memory: 128Mi # 最少使用 128 Mlimits:cpu: 200m # 最多使用0.2个cpu核心memory: 256Mi # 最多使用256MrestartPolicy: OnFailure # 重启策略# 启动之后，查看描述信息，会发现超时信息Warning Unhealthy 10s (x2 over 20s) kubelet Startup probe failed: command "sh -c sleep 5; echo 'success' > /inited;" timed out# 将sleep时间修改为1之后，重新创建，这次会启动成功