当前位置: 首页 > 知识库问答 >
问题:

为什么 Pod 仍处于“待处理”状态?

林元明
2023-03-14

我很困惑为什么我的吊舱一直处于待定状态。

Vitess在节点上调度vttablet pod时似乎有问题。我构建了一个2个工作节点Kubernetes集群(节点a

当我允许主节点调度 Pod 时,三个挂起的 vttablet 都在主节点上启动(第一个错误,然后正常运行),并且我创建表,两个 vttablet 执行失败。

当我添加两个新节点(节点C

NAMESPACE     NAME                               READY     STATUS    RESTARTS   AGE       IP            NODE               NOMINATED NODE
default       etcd-global-5zh4k77slf             1/1       Running   0          46m       192.168.2.3   t-searchredis-a2   <none>
default       etcd-global-f7db9nnfq9             1/1       Running   0          45m       192.168.2.5   t-searchredis-a2   <none>
default       etcd-global-ksh5r9k45l             1/1       Running   0          45m       192.168.1.4   t-searchredis-a1   <none>
default       etcd-operator-6f44498865-t84l5     1/1       Running   0          50m       192.168.2.2   t-searchredis-a2   <none>
default       etcd-test-5g5lmcrl2x               1/1       Running   0          46m       192.168.2.4   t-searchredis-a2   <none>
default       etcd-test-g4xrkk7wgg               1/1       Running   0          45m       192.168.1.5   t-searchredis-a1   <none>
default       etcd-test-jkq4rjrwm8               1/1       Running   0          45m       192.168.2.6   t-searchredis-a2   <none>
default       vtctld-z5d46                       1/1       Running   0          44m       192.168.1.6   t-searchredis-a1   <none>
default       vttablet-100                       0/2       Pending   0          40m       <none>        <none>             <none>
default       vttablet-101                       0/2       Pending   0          40m       <none>        <none>             <none>
default       vttablet-102                       0/2       Pending   0          40m       <none>        <none>             <none>
default       vttablet-103                       0/2       Pending   0          40m       <none>        <none>             <none>
default       vttablet-104                       0/2       Pending   0          40m       <none>        <none>             <none>


apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2018-11-27T07:25:19Z
  labels:
    app: vitess
    component: vttablet
    keyspace: test_keyspace
    shard: "0"
    tablet: test-0000000100
  name: vttablet-100
  namespace: default
  resourceVersion: "22304"
  selfLink: /api/v1/namespaces/default/pods/vttablet-100
  uid: 98258046-f215-11e8-b6a1-fa163e0411d1
spec:
  containers:
  - command:
    - bash
    - -c
    - |-
      set -e
      mkdir -p $VTDATAROOT/tmp
      chown -R vitess /vt
      su -p -s /bin/bash -c "/vt/bin/vttablet -binlog_use_v3_resharding_mode -topo_implementation etcd2 -topo_global_server_address http://etcd-global-client:2379 -topo_global_root /global -log_dir $VTDATAROOT/tmp -alsologtostderr -port 15002 -grpc_port 16002 -service_map 'grpc-queryservice,grpc-tabletmanager,grpc-updatestream' -tablet-path test-0000000100 -tablet_hostname $(hostname -i) -init_keyspace test_keyspace -init_shard 0 -init_tablet_type replica -health_check_interval 5s -mysqlctl_socket $VTDATAROOT/mysqlctl.sock -enable_semi_sync -enable_replication_reporter -orc_api_url http://orchestrator/api -orc_discover_interval 5m -restore_from_backup -backup_storage_implementation file -file_backup_storage_root '/usr/local/MySQL_DB_Backup/test'" vitess
    env:
    - name: EXTRA_MY_CNF
      value: /vt/config/mycnf/master_mysql56.cnf
    image: vitess/lite
    imagePullPolicy: Always
    livenessProbe:
      failureThreshold: 3
      httpGet:
        path: /debug/vars
        port: 15002
        scheme: HTTP
      initialDelaySeconds: 60
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 10
    name: vttablet
    ports:
    - containerPort: 15002
      name: web
      protocol: TCP
    - containerPort: 16002
      name: grpc
      protocol: TCP
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
      requests:
        cpu: 500m
        memory: 1Gi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /dev/log
      name: syslog
    - mountPath: /vt/vtdataroot
      name: vtdataroot
    - mountPath: /etc/ssl/certs/ca-certificates.crt
      name: certs
      readOnly: true
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-7g2jb
      readOnly: true
  - command:
    - sh
    - -c
    - |-
      mkdir -p $VTDATAROOT/tmp && chown -R vitess /vt
      su -p -c "/vt/bin/mysqlctld -log_dir $VTDATAROOT/tmp -alsologtostderr -tablet_uid 100 -socket_file $VTDATAROOT/mysqlctl.sock -init_db_sql_file $VTROOT/config/init_db.sql" vitess
    env:
    - name: EXTRA_MY_CNF
      value: /vt/config/mycnf/master_mysql56.cnf
    image: vitess/lite
    imagePullPolicy: Always
    name: mysql
    resources:
      limits:
        cpu: 500m
        memory: 1Gi
      requests:
        cpu: 500m
        memory: 1Gi
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /dev/log
      name: syslog
    - mountPath: /vt/vtdataroot
      name: vtdataroot
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: default-token-7g2jb
      readOnly: true
  dnsPolicy: ClusterFirst
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: default
  serviceAccountName: default
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - hostPath:
      path: /dev/log
      type: ""
    name: syslog
  - emptyDir: {}
    name: vtdataroot
  - hostPath:
      path: /etc/ssl/certs/ca-certificates.crt
      type: ""
    name: certs
  - name: default-token-7g2jb
    secret:
      defaultMode: 420
      secretName: default-token-7g2jb
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-11-27T07:25:19Z
    message: '0/3 nodes are available: 1 node(s) had taints that the pod didn''t tolerate,
      2 Insufficient cpu.'
    reason: Unschedulable
    status: "False"
    type: PodScheduled
  phase: Pending
  qosClass: Guaranteed

共有1个答案

鲜于渊
2023-03-14

正如您在底部看到的:

message: '0/3 nodes are available: 1 node(s) had taints that the pod didn''t tolerate,
  2 Insufficient cpu.'

这意味着根据您在pod中指定的限制,您的两个工作节点资源不足。您将需要更多的工人,或者更小的CPU请求。

 类似资料:
  • 问题内容: 我已经制作了一个简单的聊天应用程序,它使用jquery使用长轮询方法, 这应该发生:页面加载后,发生对listen.php的无限请求,并且当用户发送消息时,代码通过send.php将消息发送到数据库。 问题是,使用萤火虫,我发现在listen.php请求之后执行的send.php请求仍然悬而未决。表示发送消息的请求仍处于待处理状态。 问题答案: 问题是由于 会话锁定 ; 和文件两者都使

  • 我们在库伯内特斯部署了自卫队。从SCDF UI中,我们可以使用基于Docker的源处理器创建流 应用程序日志显示Tomcat没有初始化,因为没有暴露哪些/执行器endpoint 对问题可能是什么以及如何解决有什么想法吗? SCDF日志 Skipper日志

  • 我已经用Java编写了一个简单的ECHO协议服务器,使用。 很简单: 线程正在上等待客户端的输入。但是我发现所有的工作线程都处于状态,通过,我认为它们可能处于状态。 线程在等待数据到达时被阻塞,但为什么在这里它是可运行的? 下面是输出:

  • 如何启动线程: 我调用关闭线程:

  • 问题内容: 我看到了一些无法解释的Proguard行为。 AFAIK proguard不关注android清单。另外,在我的proguard.cfg文件中,我没有提及BroadcastReceiver相关的类。因此,我认为应该删除这些内容。 但是我在bin / proguard.txt中看到了一些奇怪的东西: 并且该类(BroadcastReceiver的后裔)不会被剥离。理性对我没有任何意义:

  • 我们在其中一个模块中使用了Hystrix-断路器模式[library]。usecase是:-我们正在从kafka轮询16个消息,并使用pararllel流处理它们,因此,对于工作流中的每条消息,它需要3个rest调用,这些调用由hystric命令保护。现在,问题是当我尝试运行单个实例时,CPU显示尖峰,线程转储显示许多线程处于等待状态,等待所有3个命令。如下所示:-

  • 用例:每次我需要处理一个作业时创建一个新线程。 目前的实现:我使用的执行器服务与固定大小的线程池,例如50。对于每个作业,我都向executor服务提交一个新线程。 我试图实现的行为更像是自动伸缩。在高峰时间跨越更多的服务器(在本例中是线程)。并在负载不是很高的时候终止额外的服务器并保持最小的服务器计数。

  • 我有一个关于Kubernetes环境的问题。我有K8s云,在我添加了一个持久卷分配给一个豆荚后,这个豆荚仍然处于“容器创建”状态。此PV已正确分配PVC。PVC与副本2一起位于两个外部GlusterFS服务器上。 你有什么想法可能是错的吗?我在哪里可以找到详细的日志?提前THX。 编辑:Gluster mount正确地安装在Master上,如果我手动添加任何文件,它将正确地复制到两个Gluster