стручок не создается в kubernetes, но развертывание существует? - PullRequest
Новая
       21

стручок не создается в kubernetes, но развертывание существует?

0 голосов
/ 11 июня 2019

У меня работает кластер в облаке Azure.У меня есть развертывание одноранговой службы в этом кластере.Но модули для этого развертывания не создаются.Я также расширил набор реплик для этой депортации.

Даже когда я пытаюсь создать простое развертывание образа занятого Docker, он не может создать модули.

Пожалуйста, сообщите мне, в чем может быть проблема?

РЕДАКТИРОВАТЬ

вывод для описания развертывания 

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>

Ответы [ 2 ]

4 голосов
/ 11 июня 2019

Существует миллион причин, по которым ваши блоки могут быть сломаны, и есть куча информации, которую вы можете получить, которая даст вам больше информации о том, почему эти блоки не создаются. Я бы начал с:

Что говорят стручки: 

kubectl get pods --all-namespaces -o wide

Если вы видите стручки, но в них есть ошибки, о чем говорят ошибки. Далее опишите сломанные стручки. 

kubectl describe pod <pod-name>

Или захватить журналы 

kubectl logs <pod-name>

Возможно, что-то пошло не так с вашим развертыванием. Проверьте развертывания. 

kubectl get deployments

Опишите развертывания (как стручки выше), ищите ошибки.

Мы не сможем вам помочь, пока вы не предоставите больше информации. Какие попытки отладки вы предприняли до сих пор? Какие ошибки отображаются и где вы их видите? Что на самом деле происходит, когда есть попытка создать стручки.

kubectl Получить / описать / записать все и сообщить нам, что на самом деле происходит.

Вот хорошее место для начала:

РЕДАКТИРОВАТЬ: Добавлен рис устранения неполадок в портале Azure (упоминается в комментариях ниже)

enter image description here

0 голосов
/ 11 июня 2019

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.

...