kubernetes中的pod管理
Pod 的基本概念
Pod 是 Kubernetes 中最小的可部署和管理单元，代表集群中运行的单个实例。一个 Pod 可以包含一个或多个紧密关联的容器，这些容器共享网络命名空间、存储卷和其他资源。
Pod 的特点
共享网络：Pod 内的所有容器共享同一个 IP 地址和端口空间，可以通过
localhost相互通信。共享存储：Pod 可以挂载共享的存储卷（Volumes），供容器访问相同的数据。
生命周期：Pod 是短暂的，设计为可随时创建和销毁。当 Pod 被删除时，其内部容器也会终止。
Pod 的常见用途
单容器 Pod：最常见的场景，通常用于运行一个主应用容器。
多容器 Pod
：适用于需要紧密协作的容器，例如：
日志收集器（如 Fluentd）与主应用容器。
边车模式（Sidecar）容器，用于扩展主容器的功能（如代理或监控）。
kubectl基本命令
kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署
kubectl命令的语法如下：
kubectl [command] [type] [name] [flags]comand：指定要对资源执行的操作，例如create、get、delete
type：指定资源类型，比如deployment、pod、service
name：指定资源的名称，名称大小写敏感
flags：指定额外的可选参数
#显示集群版本[root@master ~]# kubectl version#显示集群信息[root@master ~]# kubectl cluster-info#创建一个webcluster控制器，控制器中pod数量为2[root@master ~]# kubectl create deployment webcluseter --image nginx --replicas 2#查看控制器[root@master ~]# kubectl get deployments.apps#查看资源帮助[rootmaster ~]# kubectl explain deployment#删除资源[root@master ~]# kubectl delete deployments.apps web
#查看所有pod[root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEweb 1/1 Running 0 6m18s#查看某个pod[root@master ~]# kubectl get pod webNAME READY STATUS RESTARTS AGEweb 1/1 Running 0 6m18s# 查看某个pod,以yaml格式展示结果[root@master ~]# kubectl get pod web -o yamlapiVersion: v1kind: Podmetadata:creationTimestamp: "2025-10-20T07:36:01Z"labels:run: webname: webnamespace: defaultresourceVersion: "15681"uid: 1c38b2e6-a543-483d-955a-df2a4e673943spec:containers:- image: nginximagePullPolicy: Alwaysname: webresources: {}terminationMessagePath: /dev/termination-logterminationMessagePolicy: FilevolumeMounts:- mountPath: /var/run/secrets/kubernetes.io/serviceaccountname: kube-api-access-b9t6rreadOnly: truednsPolicy: ClusterFirstenableServiceLinks: truenodeName: node2preemptionPolicy: PreemptLowerPrioritypriority: 0restartPolicy: AlwaysschedulerName: default-schedulersecurityContext: {}serviceAccount: defaultserviceAccountName: defaultterminationGracePeriodSeconds: 30tolerations:- effect: NoExecutekey: node.kubernetes.io/not-readyoperator: ExiststolerationSeconds: 300- effect: NoExecutekey: node.kubernetes.io/unreachableoperator: ExiststolerationSeconds: 300volumes:- name: kube-api-access-b9t6rprojected:defaultMode: 420sources:- serviceAccountToken:expirationSeconds: 3607path: token- configMap:items:- key: ca.crtpath: ca.crtname: kube-root-ca.crt- downwardAPI:items:- fieldRef:apiVersion: v1fieldPath: metadata.namespacepath: namespacestatus:conditions:- lastProbeTime: nulllastTransitionTime: "2025-10-20T07:36:07Z"status: "True"type: PodReadyToStartContainers- lastProbeTime: nulllastTransitionTime: "2025-10-20T07:36:01Z"status: "True"type: Initialized- lastProbeTime: nulllastTransitionTime: "2025-10-20T07:36:07Z"status: "True"type: Ready- lastProbeTime: nulllastTransitionTime: "2025-10-20T07:36:07Z"status: "True"type: ContainersReady- lastProbeTime: nulllastTransitionTime: "2025-10-20T07:36:01Z"status: "True"type: PodScheduledcontainerStatuses:- containerID: docker://c3a2a0f4b444acbdd472973f9aa72289e84fc3e74ef589d940662c145ffec335image: nginx:latestimageID: docker-pullable://nginx@sha256:127262f8c4c716652d0e7863bba3b8c45bc9214a57d13786c854272102f7c945lastState: {}name: webready: truerestartCount: 0started: truestate:running:startedAt: "2025-10-20T07:36:06Z"hostIP: 192.168.188.143hostIPs:- ip: 192.168.188.143phase: RunningpodIP: 10.244.2.3podIPs:- ip: 10.244.2.3qosClass: BestEffortstartTime: "2025-10-20T07:36:01Z"资源类型
kubernetes中所有的内容都抽象为资源
[root@master ~]# kubectl api-resourcesNAME SHORTNAMES APIVERSION NAMESPACED KINDbindings v1 true Bindingcomponentstatuses cs v1 false ComponentStatusconfigmaps cm v1 true ConfigMapendpoints ep v1 true Endpointsevents ev v1 true Eventpod创建
创建自主式pod
#创建名为nginx的pod[root@master ~]# kubectl run nginx --image nginxpod/nginx created#查看所有pod[root@master ~]# kubectl get podsNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 14s#查看详细信息[root@master ~]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATESnginx 1/1 Running 0 26s 10.244.2.4 node2 <none> <none>#端口暴露[root@master ~]# kubectl expose pod nginx --port 80 --target-port 80service/nginx exposed[root@master ~]# kubectl get servicesNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d16hnginx ClusterIP 10.97.24.252 <none> 80/TCP 16s[root@master ~]# curl 10.97.24.252<!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 andworking. 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>运行交互pod
[root@master ~]# kubectl exec -it pods/nginx /bin/bashkubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.root@nginx:/# lsbin dev docker-entrypoint.sh home lib64 mnt proc run srv tmp varboot docker-entrypoint.d etc lib media opt root sbin sys usrroot@nginx:/# #复制日志文件到pod中[root@master ~]# kubectl cp anaconda-ks.cfg nginx:/[root@master ~]# kubectl exec -it pods/nginx /bin/bashkubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.root@nginx:/# lsanaconda-ks.cfg boot docker-entrypoint.d etc lib media opt root sbin sys usrbin dev docker-entrypoint.sh home lib64 mnt proc run srv tmp varroot@nginx:/# #复制pod中的文件到本机root@nginx:/# touch lpyroot@nginx:/# echo lll > lpyroot@nginx:/# lsanaconda-ks.cfg boot docker-entrypoint.d etc lib lpy mnt proc run srv tmp varbin dev docker-entrypoint.sh home lib64 media opt root sbin sys usrroot@nginx:/# cat lpy lllroot@nginx:/# exitexit[root@master ~]# kubectl cp nginx:/lpy /root/tar: Removing leading `/' from member nameserror: open /root: is a directory[root@master ~]# kubectl cp nginx:/lpy anaconda-ks.cfg tar: Removing leading `/' from member names[root@master ~]# ls公共 文档 anaconda-ks.cfg kube-flannel.yml模板 下载 cri-dockerd-0.3.14-3.el8.x86_64.rpm libcgroup-0.41-19.el8.x86_64.rpm视频 音乐 flannel-0.25.5.tag.gz nginx-1.24.0.tar.gz图片 桌面 k8s-1.30.tar nginx-latest.tar.gz[root@master ~]# \cat anaconda-ks.cfg lll[root@master ~]# kubectl cp nginx:/anaconda-ks.cfg anaconda-ks.cfg tar: Removing leading `/' from member names[root@master ~]# ls公共 文档 anaconda-ks.cfg kube-flannel.yml模板 下载 cri-dockerd-0.3.14-3.el8.x86_64.rpm libcgroup-0.41-19.el8.x86_64.rpm视频 音乐 flannel-0.25.5.tag.gz nginx-1.24.0.tar.gz图片 桌面 k8s-1.30.tar nginx-latest.tar.gz[root@master ~]# cat anaconda-ks.cfg # Generated by Anaconda 34.25.3.8# Generated by pykickstart v3.32#version=RHEL9利用控制器管理pod
高可用性和可靠性：
自动故障恢复：如果一个 Pod 失败或被删除，控制器会自动创建新的 Pod 来维持期望的副本数量。确保应用始终处于可用状态，减少因单个 Pod 故障导致的服务中断。
健康检查和自愈：可以配置控制器对 Pod 进行健康检查（如存活探针和就绪探针）。如果 Pod 不健康，控制器会采取适当的行动，如重启 Pod 或删除并重新创建它，以保证应用的正常运行。
可扩展性：
轻松扩缩容：可以通过简单的命令或配置更改来增加或减少 Pod 的数量，以满足不同的工作负载需求。例如，在高流量期间可以快速扩展以处理更多请求，在低流量期间可以缩容以节省资源。
水平自动扩缩容（HPA）：可以基于自定义指标（如 CPU 利用率、内存使用情况或应用特定的指标）自动调整 Pod 的数量，实现动态的资源分配和成本优化。
版本管理和更新：
滚动更新：对于 Deployment 等控制器，可以执行滚动更新来逐步替换旧版本的 Pod 为新版本，确保应用在更新过程中始终保持可用。可以控制更新的速率和策略，以减少对用户的影响。
回滚：如果更新出现问题，可以轻松回滚到上一个稳定版本，保证应用的稳定性和可靠性。
声明式配置：
简洁的配置方式：使用 YAML 或 JSON 格式的声明式配置文件来定义应用的部署需求。这种方式使得配置易于理解、维护和版本控制，同时也方便团队协作。
期望状态管理：只需要定义应用的期望状态（如副本数量、容器镜像等），控制器会自动调整实际状态与期望状态保持一致。无需手动管理每个 Pod 的创建和删除，提高了管理效率。
服务发现和负载均衡：
自动注册和发现：Kubernetes 中的服务（Service）可以自动发现由控制器管理的 Pod，并将流量路由到它们。这使得应用的服务发现和负载均衡变得简单和可靠，无需手动配置负载均衡器。
流量分发：可以根据不同的策略（如轮询、随机等）将请求分发到不同的 Pod，提高应用的性能和可用性。
多环境一致性：
一致的部署方式：在不同的环境（如开发、测试、生产）中，可以使用相同的控制器和配置来部署应用，确保应用在不同环境中的行为一致。这有助于减少部署差异和错误，提高开发和运维效率。
示例：
[root@master ~]# kubectl get podNo resources found in default namespace.[root@master ~]# kubectl create deployment web --image nginxdeployment.apps/web created[root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEweb-7c56dcdb9b-5sp7v 1/1 Running 0 3s#扩容[root@master ~]# kubectl scale deployment web --replicas 6deployment.apps/web scaled[root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEweb-7c56dcdb9b-46pqg 1/1 Running 0 4sweb-7c56dcdb9b-5sp7v 1/1 Running 0 30sweb-7c56dcdb9b-6ckts 1/1 Running 0 4sweb-7c56dcdb9b-fk2v8 1/1 Running 0 4sweb-7c56dcdb9b-frfzj 0/1 ContainerCreating 0 4sweb-7c56dcdb9b-m96ds 1/1 Running 0 4s[root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEweb-7c56dcdb9b-46pqg 1/1 Running 0 8sweb-7c56dcdb9b-5sp7v 1/1 Running 0 34sweb-7c56dcdb9b-6ckts 1/1 Running 0 8sweb-7c56dcdb9b-fk2v8 1/1 Running 0 8sweb-7c56dcdb9b-frfzj 1/1 Running 0 8sweb-7c56dcdb9b-m96ds 1/1 Running 0 8s[root@master ~]# #缩容[root@master ~]# kubectl scale deployment web --replicas 2deployment.apps/web scaled[root@master ~]# [root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEweb-7c56dcdb9b-5sp7v 1/1 Running 0 87sweb-7c56dcdb9b-m96ds 1/1 Running 0 61s应用版本的更新
#导入myapp镜像并打标签上传harbor仓库[root@master ~]# docker load -i myapp.tar.gz d39d92664027: Loading layer 4.232MB/4.232MB8460a579ab63: Loading layer 11.61MB/11.61MBc1dc81a64903: Loading layer 3.584kB/3.584kB68695a6cfd7d: Loading layer 4.608kB/4.608kB05a9e65e2d53: Loading layer 16.38kB/16.38kBa0d2c4392b06: Loading layer 7.68kB/7.68kBLoaded image: timinglee/myapp:v1Loaded image: timinglee/myapp:v2[root@master ~]# docker tag timinglee/myapp:v1 reg.timinglee.org/library/myapp:v1[root@master ~]# docker tag timinglee/myapp:v2 reg.timinglee.org/library/myapp:v2[root@master ~]# docker push reg.timinglee.org/library/myapp:v1The push refers to repository [reg.timinglee.org/library/myapp]a0d2c4392b06: Pushed 05a9e65e2d53: Pushed 68695a6cfd7d: Pushed c1dc81a64903: Pushed 8460a579ab63: Pushed d39d92664027: Pushed v1: digest: sha256:9eeca44ba2d410e54fccc54cbe9c021802aa8b9836a0bcf3d3229354e4c8870e size: 1569[root@master ~]# docker push reg.timinglee.org/library/myapp:v2The push refers to repository [reg.timinglee.org/library/myapp]05a9e65e2d53: Layer already exists 68695a6cfd7d: Layer already exists c1dc81a64903: Layer already exists 8460a579ab63: Layer already exists d39d92664027: Layer already exists v2: digest: sha256:5f4afc8302ade316fc47c99ee1d41f8ba94dbe7e3e7747dd87215a15429b9102 size: 1362#利用控制器建立pod[root@master ~]# kubectl create deployment app --image myapp:v1 --replicas 2deployment.apps/app created[root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEapp-fbf9c96c4-pz56j 1/1 Running 0 5sapp-fbf9c96c4-ssjrt 1/1 Running 0 5s#暴漏端口[root@master ~]# kubectl expose deployment app --port 80 --target-port 80service/app exposed[root@master ~]# kubectl get servicesNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEapp ClusterIP 10.100.29.164 <none> 80/TCP 7skubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d16h[root@master ~]# curl 10.100.29.164Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>#查看历史版本[root@master ~]# kubectl rollout history deployment appdeployment.apps/app REVISION CHANGE-CAUSE1 <none>#更新控制器镜像版本[root@master ~]# kubectl set image deployments/app myapp=myapp:v2deployment.apps/app image updated[root@master ~]# kubectl rollout history deployment appdeployment.apps/app REVISION CHANGE-CAUSE1 <none>2 <none>[root@master ~]# curl 10.100.29.164Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>[root@master ~]# 利用yaml文件部署应用
易于阅读和编写
语法简洁直观：YAML 使用缩进来表示层级关系，语法简单，不像 XML 那样需要大量的闭合标签，也比 JSON 更加人性化。例如，定义一个简单的 Pod 资源，在 YAML 中可以这样写：
yaml
apiVersion: v1kind: Podmetadata:name: my-podspec:containers:- name: my-containerimage: nginx:latest相比之下，用 JSON 表示同样的内容，格式会更紧凑，阅读起来没那么直观：
json
{"apiVersion": "v1","kind": "Pod","metadata": {"name": "my-pod"},"spec": {"containers": [{"name": "my-container","image": "nginx:latest"}]}}可读性强：YAML 文件能以一种接近自然语言的方式组织数据，开发人员、运维人员可以轻松理解其中定义的资源和配置，降低了学习和维护成本 ，即便没有深入了解过相关技术，也能较快明白文件大概定义了什么内容。
版本管理友好
方便对比和追踪：在软件开发和运维过程中，通常会使用版本控制系统（如 Git）。YAML 文件结构清晰，不同版本之间的差异很容易对比查看。当对应用的部署配置进行修改后，通过版本控制系统可以清楚地看到修改了哪些内容，方便追踪配置变更的历史，定位问题和进行回滚操作 。
团队协作顺畅：团队成员可以在 YAML 文件上进行协作，每个人提交的修改都能清晰展现，有助于提高协作效率，减少配置冲突和错误。
与容器编排系统适配性高
广泛支持：像 Kubernetes、Docker Swarm 等主流容器编排工具都原生支持使用 YAML 文件来定义和部署应用。在 Kubernetes 中，用户可以通过编写 YAML 文件来描述 Pod、Service、Deployment 等各种资源，然后使用
kubectl apply -f <filename.yaml>命令快速部署应用，操作简便且灵活。资源定义完整：YAML 文件可以全面定义应用所需的各种资源及其属性、依赖关系等。比如在 Kubernetes 的 YAML 配置中，不仅能定义容器镜像、资源限制等容器相关信息，还能设置网络策略、存储卷挂载等，确保应用在不同环境下都能按照预期的方式运行。
环境配置灵活
多环境适配：可以针对不同的环境（如开发、测试、生产环境）创建不同的 YAML 文件，或者在同一个 YAML 文件中通过变量、模板等方式来调整配置。例如，在开发环境中使用本地的测试镜像，而在生产环境中切换到正式的镜像仓库中的镜像 ，方便在不同环境中快速部署和管理应用。
动态配置调整：在应用运行过程中，如果需要对配置进行修改，只需要更新对应的 YAML 文件并重新应用，容器编排系统就能根据新的配置自动更新应用，无需重新构建整个应用程序，提高了运维效率。
运行pod
[root@master ~]# vim pod.yml apiVersion: v1kind: Podmetadata:labels:run: testname: testspec:containers:- image: nginx:latestname: web1- image: nginx:latestname: web2[root@master ~]# kubectl apply -f pod.yml pod/test created[root@master ~]# kubectl get podNAME READY STATUS RESTARTS AGEtest 1/2 Error 5 (103s ago) 3m23s#在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰端口映射
[root@master ~]# vim pod.yml apiVersion: v1kind: Podmetadata:labels:run: timingleename: testspec:containers:- image: myapp:v1name: myapp1ports:- name: httpcontainerPort: 80hostPort: 80protocol: TCP[root@master ~]# kubectl apply -f pod.ymlpod/test created[root@master ~]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEStest 1/1 Running 0 9s 10.244.2.13 node2 <none> <none>[root@master ~]# curl node2Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>如何设定环境变量
[root@master ~]# vim pod.yml apiVersion: v1kind: Podmetadata:labels:run: lpyname: testspec:containers:- image: busyboxplus:latestname: busyboxpluscommand: ["/bin/sh","-c","echo $NAME;sleep 30000000"]env:- name: NAMEvalue: lpy lpy[root@master ~]# kubectl apply -f pod.ymlpod/test created[root@master ~]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATEStest 1/1 Running 0 6s 10.244.2.14 node2 <none> <none>[root@master ~]# kubectl logs pods/test busyboxpluslpy lpypod的生命周期
INIT 容器
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
Init 容器与普通的容器非常像，除了如下两点：
它们总是运行到完成
init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。
如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
[root@master ~]# vim pod.ymlapiVersion: v1kind: Podmetadata:labels:name: initpodname: initpodspec:containers:- image: myapp:v1name: myappinitContainers:- name: init-myserviceimage: busyboxpluscommand: ["sh","-c","until test -e /testfile;do echo wating for myservice; sleep 2;done"][root@master ~]# kubectl apply -f pod.ymlpod/initpod created[root@master ~]# kubectl get podsNAME READY STATUS RESTARTS AGEinitpod 0/1 Init:0/1 0 3s[root@master ~]# kubectl logs pods/initpod init-myservicewating for myservicewating for myservicewating for myservicewating for myservicewating for myservicewating for myservice[root@master ~]# kubectl exec pods/initpod -c init-myservice -- /bin/sh -c "touch /testfile"[root@master ~]# kubectl get pods NAME READY STATUS RESTARTS AGEinitpod 1/1 Running 0 62s探针
在 Kubernetes（k8s）中，探针是用于检测容器健康状态的机制，通过定期执行检查，帮助 k8s 判断容器是否正常运行，从而采取相应措施保证应用的可用性 。常见的探针类型有以下几种：
存活探针（livenessProbe）
作用：用于判断容器是否处于运行状态，如果容器出现故障（例如程序崩溃、死锁等），存活探针检测到容器不健康后，k8s 会重启该容器，就像给生病罢工的工人重新安排工作，让应用恢复正常运行。
示例配置：在 Pod 的 YAML 文件中，可以这样配置存活探针。以下是一个使用 HTTP GET 请求检测容器是否存活的例子，假设容器内应用在 8080 端口提供 HTTP 服务：
apiVersion: v1kind: Podmetadata:name: my-podspec:containers:- name: my-containerimage: myapp:latestlivenessProbe:httpGet:path: /healthzport: 8080initialDelaySeconds: 5periodSeconds: 10其中，httpGet 定义了检测方式，path 是请求路径，port 是端口；initialDelaySeconds 表示容器启动后，延迟 5 秒开始执行首次探针检测；periodSeconds 表示每隔 10 秒执行一次检测。
就绪探针（readinessProbe）
作用：判断容器是否已经准备好接收请求，比如容器内应用可能需要加载配置文件、连接数据库等初始化操作，只有当这些操作都完成，容器才算真正就绪。k8s 通过就绪探针确认容器就绪后，才会将流量发送到该容器所在的 Pod 上，避免请求发送到还没准备好的容器而导致失败。
示例配置：同样以 HTTP GET 请求为例，配置就绪探针：
apiVersion: v1kind: Podmetadata:name: my-podspec:containers:- name: my-containerimage: myapp:latestreadinessProbe:httpGet:path: /readyport: 8080initialDelaySeconds: 10periodSeconds: 15这表示容器启动 10 秒后开始进行就绪检测，之后每隔 15 秒检测一次，通过访问 /ready 路径来判断容器是否就绪。
启动探针（startupProbe）
作用：主要用于处理一些启动时间较长的容器，避免存活探针和就绪探针在容器还在启动过程中就开始检测，导致误判容器不健康。启动探针会在容器启动初期持续检测，直到容器通过启动探针的检测，才会开始执行存活探针和就绪探针。
示例配置：以 TCP Socket 方式检测容器启动，假设应用监听在 8000 端口：
yaml
apiVersion: v1kind: Podmetadata:name: my-podspec:containers:- name: my-containerimage: myapp:lateststartupProbe:tcpSocket:port: 8000initialDelaySeconds: 30periodSeconds: 5timeoutSeconds: 1successThreshold: 1failureThreshold: 30这里，tcpSocket 表示使用 TCP 连接检测，port 是目标端口；initialDelaySeconds 为延迟 30 秒开始检测；periodSeconds 是检测间隔为 5 秒；timeoutSeconds 是每次检测的超时时间为 1 秒；successThreshold 表示连续 1 次检测成功，就认为容器启动成功；failureThreshold 表示连续 30 次检测失败，才认为容器启动失败。
通过合理配置这些探针，k8s 能够更好地管理容器的生命周期，保证应用的高可用性和稳定性 。