首页 > 其他分享 >POD基本操作

POD基本操作

时间：2024-08-22 16:51:17浏览次数：11  
标签：kubectl Kubernetes 容器 标签 基本操作 POD Pod pod

一.Pod生命周期

在Kubernetes中，Pod的生命周期经历了几个重要的阶段。下面是Pod生命周期的详细介绍：

1.Pending（待处理）：

  • 调度: Pod被创建后，首先进入“Pending”状态。此时，Kubernetes的调度器（Scheduler）会选择一个合适的节点来运行Pod。

  • 资源分配: 在调度器选择了节点后，Pod仍在“Pending”状态，直到所有容器的镜像都被拉取下来，并且资源需求得到了满足。

2.Running（运行中）:
  • 初始化容器: 如果Pod定义了初始化容器（Init Containers），这些容器会在Pod的主容器之前启动。它们完成后，Pod状态会转变为“Running”。

在Kubernetes中，Pod的生命周期包括初始化容器（Init Containers）的特殊阶段。初始化容器是用于在Pod的主容器启动之前执行一些初始化任务的容器。它们是Pod的一部分，通常用于执行一些准备工作，例如数据库迁移、配置准备、依赖检查等。以下是有关初始化容器的详细生命周期信息：

### 初始化容器的生命周期

1. 定义阶段:
   - 在Pod的定义中，初始化容器与主容器一起列在Pod的规范（spec）中。每个初始化容器都可以有自己的镜像、命令、环境变量等配置。
2. 创建阶段:
   - 当Pod被创建时，初始化容器会根据Pod的规范进行启动。它们按照定义的顺序逐个启动。每个初始化容器都必须成功完成后，才会启动下一个初始化容器。
3. 启动阶段:
   - 顺序执行: 初始化容器会按照Pod规范中定义的顺序依次启动。如果一个初始化容器启动失败，Kubernetes会重试这个容器，直到成功或达到最大重试次数。
   - 完成任务: 每个初始化容器会执行其定义的任务，并且必须成功退出（以状态码0结束）。如果容器失败退出（以非零状态码结束），Kubernetes会重试，直到容器成功完成或者重试次数达到限制。
4. 过渡到运行阶段:
   - 成功: 当所有的初始化容器成功完成其任务后，Pod会进入“Running”状态，随后主容器（Containers）才会启动。
   - 失败: 如果某个初始化容器失败并且达到重试次数限制，整个Pod会标记为失败，主容器不会启动。
5. 终止阶段:
   - 终止: 一旦Pod的生命周期结束（无论是正常完成还是失败），初始化容器也会随之终止。Kubernetes会处理容器的清理工作，包括删除容器的日志和其他临时文件。

> ### 初始化容器的特点
>
> - 顺序性: 初始化容器按定义顺序执行，一个初始化容器完成后，才会开始下一个初始化容器。
> - 隔离性: 初始化容器在Pod中的主容器之前运行，它们可以有不同的镜像和配置，与主容器的环境相互隔离。
> - 重试机制: 如果初始化容器失败，Kubernetes会根据配置的重试策略重试该容器，直到成功或者达到重试限制。
>
> ### 使用场景
>
> 初始化容器非常适用于以下场景：
>
> - 数据库初始化: 在应用启动之前执行数据库迁移或初始化操作。
> - 配置检查: 检查或生成配置文件，确保主容器启动所需的环境准备好。
> - 依赖服务检查: 确保所需的外部服务或资源在主容器启动之前可用。
>
> 初始化容器提供了一种在Pod启动之前执行预处理任务的灵活方式，使得Pod的主容器能够在正确的环境中运行。

  • 主容器启动: 所有的初始化容器成功运行后，Pod中的主容器开始启动。此时Pod处于“Running”状态。

  • 健康检查: 在“Running”状态下，Kubernetes会持续进行健康检查（Liveness Probe）和就绪检查（Readiness Probe），以确保容器正常运行并能够接受流量。

3.Succeeded（成功）:

完成任务: 如果Pod中的所有容器成功完成任务并退出（对于短生命周期的Pod，如Batch Job中的Pod），Pod会转变为“Succeeded”状态。

4.Failed（失败）:

任务失败: 如果Pod中的容器因故障或错误而退出，Pod将转变为“Failed”状态。这通常表示容器没有成功完成其任务。

5.Unknown（未知）:

状态不确定: 如果Kubernetes无法从节点获取Pod的状态，Pod会处于“Unknown”状态。这可能是由于节点不可达或其他通信问题引起的。

6.Terminating（终止中）:

  • 终止: 当Pod被删除或终止时，Pod进入“Terminating”状态。在此状态下，Kubernetes会逐步停止Pod中的所有容器，并进行必要的清理工作。

  • Grace Period: Kubernetes会尊重Pod的终止宽限期（Grace Period），允许容器在关闭前完成它们的清理工作。终止宽限期可以通过Pod的terminationGracePeriodSeconds字段配置。

了解这些状态对于管理和调试Kubernetes中的应用非常重要。每个阶段和状态都有其特定的含义和影响，掌握它们可以帮助你更好地理解和控制Pod的行为。

二、Pod的探针

Kubernetes中的Pod探针用于检测容器的健康状态和就绪状态。主要有三种探针：

  1. Liveness Probe（存活探针）: 检查容器是否正常运行。如果探针失败，Kubernetes会重启容器。适用于检测容器是否陷入了死循环或挂起状态。

  2. Readiness Probe（就绪探针）: 确定容器是否准备好接受流量。探针失败会导致Pod从服务的负载均衡池中移除，直到容器恢复就绪状态。

  3. Startup Probe（启动探针）: 检测容器是否已启动。用于处理启动时需要较长时间的应用，避免在启动阶段被误判为不健康。（常用于脚本）

探针通常通过HTTP请求、TCP连接或执行命令来进行检查。

三、Pod的两个钩子

1.介绍

在Kubernetes中，Pod的两个钩子是：

  1. 生命周期钩子（Lifecycle Hooks）:

    • postStart: 在容器启动后立即执行的钩子。适用于需要在容器启动后执行某些任务的场景，例如初始化配置或启动一些后台进程。

    • preStop: 在容器停止之前执行的钩子。适用于在容器停止之前进行清理操作或保存状态等操作。

    生命周期钩子允许在容器的生命周期中特定的时间点执行自定义的脚本或命令。它们帮助开发者在容器的启动或停止时执行必要的操作。

  2. 终止钩子（Termination Hooks）:

    • 终止钩子是一个与生命周期钩子相似的概念，但在Kubernetes中并没有明确标记为“终止钩子”。而是在preStop钩子中定义了在容器停止之前要执行的操作，这也可以视为终止钩子的一部分。

2.配置示例

在Pod的定义中配置postStart和preStop的示例：

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example-image
    lifecycle:
      postStart:
        exec:
          command: ["/bin/sh", "-c", "echo 'Container started' > /var/log/startup.log"]
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo 'Container is stopping' > /var/log/shutdown.log"]

3.作用

  • postStart: 用于在容器启动后执行操作，比如配置、启动服务、或者进行一些初始化工作。需要注意的是，postStart 钩子是异步执行的，并不会等待操作完成后才继续执行容器中的主应用程序。

  • preStop: 用于在容器停止之前执行清理任务，比如关闭连接、清理缓存或保存数据。preStop 钩子是同步的，Kubernetes会等待钩子完成后才会真正停止容器。

这些钩子提供了一种在容器生命周期特定阶段执行自定义操作的方式，有助于确保容器的状态管理和资源清理。

四、Pod删除过程

Pod的删除过程在Kubernetes中涉及几个关键步骤。了解这些步骤有助于更好地管理Pod的生命周期和确保应用的平稳运行。以下是Pod删除的基本流程：

Pod running----Terminating----prestop hook----SIGTRM----terminationGracePeriodSeconds----SIGKILL----Deleted
1. 发起删除请求

当你通过kubectl delete pod <pod-name>命令或通过API请求删除Pod时，Kubernetes会开始删除过程。

2. 标记Pod为终止状态

Kubernetes将Pod的状态标记为Terminating。此时，Pod仍然存在，但已经不再接受新的流量或请求。

3. 执行preStop钩子（如果有）

如果Pod配置了preStop生命周期钩子，Kubernetes会在停止容器之前执行这个钩子。preStop钩子是同步的，Kubernetes会等待钩子完成后才会继续删除容器。

4. 停止容器

一旦preStop钩子（如果有）完成，Kubernetes会向容器发送终止信号（通常是SIGTERM）。容器接收到信号后应该开始优雅地关闭。

5. 等待容器关闭

Kubernetes会等待容器在设定的terminationGracePeriodSeconds（默认30秒）内完成关闭过程。这个时间可以通过Pod的spec配置项进行调整。如果容器在规定时间内没有优雅地关闭，Kubernetes会发送强制终止信号（SIGKILL）来强制关闭容器。

6. 删除Pod

容器关闭后，Kubernetes会从集群中删除Pod对象，包括相关的所有资源（例如日志、事件记录等）。Pod的终止状态也会被更新到Terminated。

7. 更新ReplicaSet或Deployment

如果Pod是由ReplicaSet或Deployment管理的，ReplicaSet或Deployment控制器会检测到Pod的删除，并根据策略创建新的Pod以维持期望的副本数。

8. 清理

如果Pod在删除之前进行了任何网络连接、挂载卷或存储的操作，Kubernetes会在Pod删除过程中清理这些资源，确保系统资源得到释放和回收。

#示例：
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example-image
    lifecycle:
      preStop:
        exec:
          command: ["/bin/sh", "-c", "echo 'Cleaning up before shutdown' > /var/log/shutdown.log"]

总结：Pod删除的过程确保了应用的优雅关闭和资源的正确管理。通过了解这些步骤，你可以更好地设计和管理你的Kubernetes集群，确保高效和可靠的服务运行。

五、ReplicaSet

ReplicaSet 是 Kubernetes 中的一个控制器，用于确保指定数量的 Pod 实例始终在运行。以下是 ReplicaSet 资源的字段介绍，包括 metadata、spec 和 status 部分的详细说明：

1.metadata

name: (string) ReplicaSet 的名字。
namespace: (string) ReplicaSet 所在的命名空间。
labels: (map[string]string) 一组标签，用于标识和选择对象。
annotations: (map[string]string) 由用户定义的附加信息，用于存储任意的元数据。
creationTimestamp: (string) ReplicaSet 的创建时间。

2.spec

spec 部分定义了 ReplicaSet 的行为和期望状态。

replicas: (int32) 要维持的 Pod 副本数量。这个字段是可选的，如果未指定，默认值为 1。

selector: (LabelSelector) 选择器，用于指定要管理的 Pod。这个字段定义了一个标签选择器，用于选择 ReplicaSet 要管理的 Pod。
　　 matchLabels: (map[string]string) 一组标签键值对，用于匹配 Pod。
    matchExpressions: ([]LabelSelectorRequirement) 用于选择 Pod 的表达式。

template: (PodTemplateSpec) Pod 模板，用于创建管理的 Pod。包含以下字段：
 　　metadata: (ObjectMeta) Pod 的元数据，通常包含标签和注释。
 　　spec: (PodSpec) Pod 的规范，定义了容器、卷、网络等。
     　　containers: ([]Container) Pod 中的容器列表，每个容器定义了镜像、端口等。
     　　volumes: ([]Volume) Pod 中的卷定义，用于存储数据。

3.status

status 部分描述了 ReplicaSet 的当前状态。

replicas: (int32) 当前 Pod 副本的数量。
fullyLabeledReplicas: (int32) 完全符合选择器的 Pod 数量。
readyReplicas: (int32) 准备就绪的 Pod 数量。
availableReplicas: (int32) 可用的 Pod 数量。
observedGeneration: (int64) 观察到的 ReplicaSet 的版本号。用于检测状态的更新。

六、Pod节点选择

在 Kubernetes 中，Pod 节点选择器（Node Selector）是一种用于指定 Pod 应该调度到哪个节点的机制。通过节点选择器，您可以控制 Pod 在集群中运行的节点，确保它们在符合特定条件的节点上运行。

如何使用节点选择器

1.标记节点： 首先，您需要为节点添加标签。标签是由键值对组成的，例如 role=frontend。

kubectl label nodes <node-name> role=frontend

2.使用节点选择器： 在 Pod 的定义文件中，您可以使用 nodeSelector 来指定 Pod 应该调度到哪些节点。例如，如果您想让 Pod 只调度到标签为 role=frontend 的节点上，可以在 Pod 的 YAML 文件中指定节点选择器。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image
  nodeSelector:
    role: frontend
示例：Pod 将只会调度到具有 `disktype=ssd` 标签的节点上
apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: nginx
  nodeSelector:
    disktype: ssd

注意事项：

  • 节点选择器的限制：节点选择器只能基于节点的标签来做选择，比较简单。如果需要更复杂的调度策略，可以使用 affinity 或 taints and tolerations。

  • 节点标签：确保节点已经正确地标记了标签，否则 Pod 可能会因为找不到符合条件的节点而无法调度。

  • 多重标签匹配：如果节点有多个标签，节点选择器会匹配所有指定的标签条件。

通过合理配置节点选择器，您可以优化资源分配，提高 Pod 的性能和稳定性。

七、制作查看删除标签

1.制作标签

使用 kubectl label 命令为 Pod 打标签。以下是语法和示例：

kubectl label pod <pod-name> <key>=<value>

  • <pod-name>：Pod 的名称。

  • <key>：标签的键。

  • <value>：标签的值。

例如，为名为 my-pod 的 Pod 打上标签 env=production：

kubectl label pod my-pod env=production

2.查看 Pod 标签

查看所有 Pods 的标签

kubectl get pods --show-labels

查看特定 Pod 的标签

kubectl describe pod <pod-name>

只显示特定 Pod 的标签

kubectl get pod <pod-name> --template '{{range $k, $v := .metadata.labels}}{{$k}}: {{$v}}{{"\n"}}{{end}}'

这条命令只显示指定 Pod 的标签，以键值对的形式。

查看指定标签名的pod信息

-L选项允许你在输出表格中添加额外的标签列，以便于更直观地查看 Pods 的标签。 可以指定多个标签键，通过逗号分隔，例如：-L project,app。

kubectl get pods -L project,app

-l 选项：用于 过滤资源，根据标签选择器选择要显示的资源

kubectl get pods -l app=myapp

3.查看 Node 标签

查看所有 Nodes 的标签

kubectl get nodes --show-labels

查看特定 Node 的标签

kubectl describe node <node-name>

只显示特定 Node 的标签

kubectl get node <node-name> --template '{{range $k, $v := .metadata.labels}}{{$k}}: {{$v}}{{"\n"}}{{end}}'

这条命令只显示指定 Node 的标签，以键值对的形式。

查看指定标签名的node信息

kubectl get nodes -L project
kubectl get node -l nodemaster=yes

4.删除标签

要删除 Pod 的标签，可以使用 kubectl label 命令并将标签值设置为空。以下是语法和示例：

kubectl label pod <pod-name> <key>-

  • <pod-name>：Pod 的名称。

  • <key>：要删除的标签的键。

例如，删除名为 my-pod 的 Pod 上的 env 标签：

kubectl label pod my-pod env-

5.指定节点

方法一：通过nodeName方式

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      nodeName: node1
      containers:
      - name: mycontainer
        image: harbor.hiuiu.com/nginx/nginx:1.21.5
        imagePullPolicy: Never
        ports:
        - containerPort: 80

kubectl apply -f replicaset.yaml

kubectl  get pod  -o wide

方法二：通过nodeSelector方式

#将pod加入标签为nodemaster=yes的node中，ReplicaSet只管理label为app=myapp的pod
kubectl explain rs.spec.template.spec.nodeSelector

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 4
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      nodeSelector:
        nodemaster: "yes"
      containers:
      - name: mycontainer
        image: harbor.hiuiu.com/nginx/nginx:1.21.5
        imagePullPolicy: Never
        ports:
        - containerPort: 80

kubectl apply -f replicaset.yaml

kubectl get pod -o wide

八、node亲和性

1.node亲和性

Kubernetes 的节点亲和性（Node Affinity）是一种调度机制，用于控制 Pod 被调度到哪些节点上。它允许你指定 Pod 应该运行在哪些特定的节点上，基于节点的标签。

节点亲和性是节点选择的扩展，它的配置方式类似于 Pod 的调度策略，通过在 Pod 的 spec.affinity.nodeAffinity 部分进行定义。

节点亲和性的基本概念

节点亲和性定义了 Pod 对节点的选择规则。它可以是：

  • 必需亲和性（RequiredDuringSchedulingIgnoredDuringExecution）：这些规则必须满足，否则 Pod 将不会被调度到节点上。它是强制性的。

  • 优先亲和性（PreferredDuringSchedulingIgnoredDuringExecution）：这些规则是优先考虑的，但不是强制性的。Kubernetes 将尽量满足这些规则，但如果无法满足，也不会阻止 Pod 调度。

必需亲和性

kubectl explain pods.spec.affinity.nodeAffinity.requiredDuringSchedulingIgnoredDuringExecution

#pod必须加入标签为zone=ky36或zone=ccc的node中
apiVersion: v1
kind: Pod
metadata:
  name: pod-node-affinity-demo
  namespace: default
  labels:
    app: myapp
spec:
    containers:
    - name: myapp
      image: harbor.hiuiu.com/nginx/nginx:1.21.5
    affinity:
      nodeAffinity:
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: zone
              operator: In
              values:
              - ky36
              - ccc

kubectl apply -f replicaset.yaml

kubectl  get pod -o wide

优先亲和性

kubectl explain pods.spec.affinity.nodeAffinity.preferredDuringSchedulingIgnoredDuringExecution

apiVersion: v1
kind: Pod
metadata:
  name: pod-node-affinity-demo
  namespace: default
  labels:
    app: myapp
spec:
    containers:
    - name: myapp
      image: harbor.hiuiu.com/nginx/nginx:1.21.5
    affinity:
      nodeAffinity:
        preferredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: zone
              operator: In
              values:
              - ky36
              - ccc

kubectl apply -f replicaset.yaml 

kubectl  get pod -o wide

2.Pod亲和性

kubectl explain pods.spec.affinity.podAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey
yaml1
apiVersion: v1
kind: Pod
metadata:
  name: pod-first
  labels:
    app2: myapp2
    tier: frontend
spec:
  containers:
  - name: myapp
    image: harbor.hiuiu.com/nginx/nginx:1.21.5

yaml2
apiVersion: v1
kind: Pod
metadata:
  name: pod-second
  labels:
    app: backend
    tier: db
spec:
  containers:
  - name: mysql
    image: harbor.hiuiu.com/nginx/nginx:1.21.5
    imagePullPolicy: IfNotPresent
  affinity:
    podAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app2
            operator: In
            values:
            - myapp2
        topologyKey: kubernetes.io/hostname

kubectl apply -f pod1.yaml 
kubectl apply -f pod2.yaml 
kubectl  get pod -o wide

3.Pod 反亲和性

kubectl explain pods.spec.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

九、Pod 拉取镜像策略

kubectl explain pod.spec.containers.imagePullPolicy
##imagePullPolicy (镜像拉取策略)：:
    IfNotPresent：node节点没有此镜像就去指定的镜像仓库拉取，node有就使用node本地镜像。
    Always：每次重建pod都会重新拉取镜像
    Never：从不到镜像中心拉取镜像，只使用本地镜

十、Pod重启策略

kubectl explain pod.spec.restartPolicy
restartPolicy
Always：默认值。无论容器退出的状态如何，始终重启容器。适用于长期运行的服务。
Never：容器退出后不会重启。适用于一次性任务或需要手动干预的情况。
OnFailure：只有当容器退出状态码表示失败时（非零退出码），才会重启。适用于希望重启失败的任务但不需要重启成功完成的任务。

 

标签：kubectl,Kubernetes,容器,标签,基本操作,POD,Pod,pod
From： https://www.cnblogs.com/hxqwe/p/18374239

相关文章

  • jmeter基本操作
    发送一个post请求/发送一个get请求1、创建一个线程2、新建一个http请求编辑http请求的内容POSTGET接口断言：响应参数：{"code":"200","msg":"登录成功！","model":{}}查看结果：保存，运行a、保存：b、运行红色表示错误绿色表示成功查看请求后的详情：取样器、请求......
  • 用Podman从零开始构建并运行一个Apache+PHP的容器镜像 （三)
    昨天我在之前从零开始创建的容器中实现了Apache服务的自动启动(详情记录在上一篇博文中：https://blog.csdn.net/arthurchan2021/article/details/141371026)。但是离实用性还有一段距离，所以今天继续折腾。到目前为止访问http://localhost:8080返回的页面还是Ubuntu给Apache......
  • Docker受限？试试Podman，手动搭建Ubuntu容器镜像
    Docker受限？试试Podman，手动搭建Ubuntu容器镜像最近，我打算用Docker来搭建一个开发环境，但遗憾的是，我发现DockerHub无法使用，甚至国内的镜像源也无法访问。这让我有些头疼，但好在我在寻找解决方案的过程中，发现了一个Docker的替代方案：Podman。Podman的使用方法与Docker几乎一模......
  • 一次Kubernetes Pod内存异常导致的测试环境耗时异常问题排查过程
    概述在使用公司内部后台系统测试环境时发现一个请求加载慢的问题，简简单单的列表，查询MongoDB数据库，测试环境不过几百上千条数据而已，请求耗时居然高达5~6秒：作为对比，生产环境的请求响应截图如下：经过持续跟进，该后台系统所有列表页面测试环境普遍比生产环境慢，不管是MongoDB还是MyS......
  • MAC安装CocoaPods
    如果已经安装过，则先执行卸载gemuninstallcocoapodssudorm-fr~/Library/Caches/CocoaPods/sudorm-fr~/.cocoapods/repos/master/新安装先执行geminstallcocoapods如果报错可尝试使用下面的命令sudogeminstall-n/usr/local/bincocoapods预览版sudogem......
  • MySQL基本操作
    MySQL基本操作学习目标：学习基本的SQL操作，实现数据库的基本管理SQL基本语法SQL库操作SQL表操作SQL数据操作一、SQL语法规则目标：了解SQL的基本语法规则SQL语法规则：SQL是一种结构化编程语言基础SQL指令通常是以行为单位SQL指令需要语句结束符，默认是英文分号：;、\g、\G\G：主......
  • pod数据持久化-pv与pvc资源及动态存储StorageClass
    一、pc与pvc的概念在传统的存储卷挂载，比如说nfs，它虽然能够实现我们大多数的生产场景，但是，耦合性比较高；举例：假设，我们要将集群从“阿里云”迁移到我们私有云服务器上，并改变存储卷挂在的类型，就无法实现，必须使用原有的存储卷类型；比如我们阿里云的存储卷是nfs，我们线下服务器的存储卷......
  • 在K8S中，⼀个pod的不同container能够分开被调动到不同的节点上吗？
    在Kubernetes(K8S)中，一个Pod是一组一起部署和管理的容器的集合。Pod内的容器总是被调度到同一个节点上运行，这是因为Pod设计的基本理念是其内的所有容器需要紧密耦合并且共享相同的网络命名空间和存储卷。具体来说，Pod内的容器有以下特点：共享IP地址：Pod内的所有容器共享......
  • 在K8S中，如果是因为开发写的镜像问题导致pod起不来该怎么排查？
    在Kubernetes（K8S）中，如果Pod无法启动是由于开发编写的镜像问题导致的，可以通过以下步骤进行详细排查：一、检查镜像状态确认镜像名称和标签：使用kubectldescribepod<pod-name>命令查看Pod的详细信息，确认Pod中引用的镜像名称和标签是否正确。检查镜像是否存在于仓库：登录到Do......
  • 在K8S中，在服务上线的时候Pod起不来怎么进行排查？
    当Kubernetes(K8S)中的服务上线时Pod无法启动，可以按照以下步骤进行详细的排查：1.检查Pod的状态首先使用kubectlgetpods命令查看Pod的状态，确认Pod是否处于Running状态。如果Pod处于Pending、Error或其他非正常状态，则需要进一步排查。kubectlgetpods2.......

赞助商

阅读排行

网站主页关于我们联系我们网站地图

本网站内容转载自其他媒体，侵权联系[admin##ips99.com]。

Copyright © 2020-2023 IPS99 版权所有 IPS99