Question

我有一个在Azure云上运行的群集。我在该群集上部署了对等服务。但是没有创建用于该部署的pod。我还扩大了该脱销的副本集。

即使我尝试创建简单的docker busybox映像部署，也无法创建pod。

请指导我可能是什么问题？

编辑

用于描述部署的输出

Name:               peer0-org-myorg
Namespace:          internal
CreationTimestamp:  Tue, 28 May 2019 06:12:21 +0000
Labels:             cattle.io/creator=norman
                    workload.user.cattle.io/workloadselector=deployment-internal-peer0-org-myorg
Annotations:        deployment.kubernetes.io/revision=1
                    field.cattle.io/creatorId=user-b29mj
                    field.cattle.io/publicEndpoints=null
Selector:           workload.user.cattle.io/workloadselector=deployment-internal-peer0-org-myorg
Replicas:           1 desired | 1 updated | 1 total | 1 available | 0 unavailable
StrategyType:       Recreate
MinReadySeconds:    0
Pod Template:
  Labels:       workload.user.cattle.io/workloadselector=deployment-internal-peer0-org-myorg
  Annotations:  cattle.io/timestamp=2019-06-11T08:19:40Z
                field.cattle.io/ports=[[{"containerPort":7051,"dnsName":"peer0-org-myorg-hostport","hostPort":7051,"kind":"HostPort","name":"7051tcp70510","protocol":"TCP","sourcePort":7051},{"containerPo...
  Containers:
   peer0-org-myorg:
    Image:       hyperledger/fabric-peer:1.4.0
    Ports:       7051/TCP, 7053/TCP
    Host Ports:  7051/TCP, 7053/TCP
    Environment:
      CORE_LEDGER_STATE_COUCHDBCONFIG_COUCHDBADDRESS:  couchdb0:5984
      CORE_LEDGER_STATE_COUCHDBCONFIG_PASSWORD:        root
      CORE_LEDGER_STATE_COUCHDBCONFIG_USERNAME:        root
      CORE_LEDGER_STATE_STATEDATABASE:                 CouchDB
      CORE_LOGGING_CAUTHDSL:                           INFO
      CORE_LOGGING_GOSSIP:                             WARNING
      CORE_LOGGING_GRPC:                               WARNING
      CORE_LOGGING_MSP:                                WARNING
      CORE_PEER_ADDRESS:                               peer0-org-myorg-com:7051
      CORE_PEER_ADDRESSAUTODETECT:                     true
      CORE_PEER_FILESYSTEMPATH:                        /var/hyperledger/peers/peer0/production
      CORE_PEER_GOSSIP_EXTERNALENDPOINT:               peer0-org-myorg-com:7051
      CORE_PEER_GOSSIP_ORGLEADER:                      false
      CORE_PEER_GOSSIP_USELEADERELECTION:              true
      CORE_PEER_ID:                                    peer0.org.myorg.com
      CORE_PEER_LOCALMSPID:                            orgMSP
      CORE_PEER_MSPCONFIGPATH:                         /mnt/crypto/crypto-config/peerOrganizations/org.myorg.com/peers/peer0.org.myorg.com/msp
      CORE_PEER_PROFILE_ENABLED:                       true
      CORE_PEER_TLS_CERT_FILE:                         /mnt/crypto/crypto-config/peerOrganizations/org.myorg.com/peers/peer0.org.myorg.com/tls/server.crt
      CORE_PEER_TLS_ENABLED:                           false
      CORE_PEER_TLS_KEY_FILE:                          /mnt/crypto/crypto-config/peerOrganizations/org.myorg.com/peers/peer0.org.myorg.com/tls/server.key
      CORE_PEER_TLS_ROOTCERT_FILE:                     /mnt/crypto/crypto-config/peerOrganizations/org.myorg.com/peers/peer0.org.myorg.com/tls/ca.crt
      CORE_PEER_TLS_SERVERHOSTOVERRIDE:                peer0.org.myorg.com
      CORE_VM_ENDPOINT:                                unix:///host/var/run/docker.sock
      FABRIC_LOGGING_SPEC:                             DEBUG
    Mounts:
      /host/var/run from worker1-dockersock (ro)
      /mnt/crypto from crypto (ro)
      /var/hyperledger/peers from vol2 (rw)
  Volumes:
   crypto:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  worker1-crypto-pvc
    ReadOnly:   false
   vol2:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  worker1-pvc
    ReadOnly:   false
   worker1-dockersock:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  worker1-dockersock
    ReadOnly:   false
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  peer0-org-myorg-6d6645ddd7 (1/1 replicas created)
NewReplicaSet:   <none>
Events:          <none>

Answer 1

有100万个原因导致吊舱损坏，并且可以获得大量信息，这些信息可以为您提供有关为何未创建吊舱的更多信息。我将从以下内容开始：

豆荚怎么说：

kubectl get pods --all-namespaces -o wide

如果您可以看到吊舱但它们有错误，那么错误说明了什么。进一步描述破碎的豆荚。

kubectl describe pod <pod-name>

或抓取日志

kubectl logs <pod-name>

也许您的部署出现了问题。检查部署。

kubectl get deployments

描述部署（如上面的pod），查找错误。

在您提供更多信息之前，我们无法真正帮助您。到目前为止，您进行了哪些调试尝试？显示哪些错误，您在哪里看到它们？尝试创建吊舱时实际上发生了什么。

kubectl获取/描述/记录所有内容，并让我们知道实际发生的情况。

这里是一个不错的起点：

编辑：在Azure门户中添加了一个故障排除图片（在下面的评论中提到）

Answer 2

kube-apiserver（k8s主平面组件）负责服务您的API请求，例如：kubectl create ..或kubectl scale ... 现在，实际上将这些kubernetes资源的状态维持在所需状态，是kube-controller-manager（另一个k8s主平面组件）的工作。另外，将这些资源调度到节点是kube-scheduler（另一个k8s主平面组件）的工作。

说了上述信息，并假设（我认为）您正在使用托管Kubernetes，因此上述组件由您的云提供商管理。但是，根据我的（本地kubernetes）经验，我可以说，如果正确执行了部署命令，则意味着kube-apiserver正常运行，而kube-controller无法正常运行。另外，如果豆荚出现但被卡在创建状态中，那么问题就是库伯调度程序无法解决问题。

总而言之，值得检查kube-controller和kube-scheduler的日志。

Answer 3

我在 Mac 上使用“Docker 桌面”时遇到了类似的情况，并通过在“Docker 桌面首选项”中增加 Docker 资源来克服...

因此，请尝试增加您的 Kubernetes 集群资源。

尚未在kubernetes中创建Pod，但存在部署吗？

3 个答案: