Kubernetes pod desc показывает ошибку "отказано в соединении" - PullRequest
Новая
       6

Kubernetes pod desc показывает ошибку "отказано в соединении"

0 голосов
/ 01 ноября 2018

Я новичок из Kubernetes. У меня заканчиваются идеи по решению статуса Pod, застрявшего на ContainerCreating. Я работаю над примером приложения от AWS (https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html#eks-guestbook), образец очень похож на официальный образец (https://kubernetes.io/docs/tutorials/stateless-application/guestbook/).

Большое спасибо за руководство по поиску первопричин:

Почему я получаю сообщение об ошибке "Отклонено", что делает порт 50051? Благодаря. 

$ kubectl get pods --all-namespaces

NAMESPACE     NAME                        READY   STATUS              RESTARTS   AGE
default       guestbook-8k9pp             0/1     ContainerCreating   0          15h
default       guestbook-b2n49             0/1     ContainerCreating   0          15h
default       guestbook-gtjnj             0/1     ContainerCreating   0          15h
default       redis-master-rhwnt          0/1     ContainerCreating   0          15h
default       redis-slave-b284x           0/1     ContainerCreating   0          15h
default       redis-slave-vnlj4           0/1     ContainerCreating   0          15h
kube-system   aws-node-jkfg8              0/1     CrashLoopBackOff    273        1d
kube-system   aws-node-lpvn9              0/1     CrashLoopBackOff    273        1d
kube-system   aws-node-nmwzn              0/1     Error               274        1d
kube-system   kube-dns-64b69465b4-ftlm6   0/3     ContainerCreating   0          4d
kube-system   kube-proxy-cxdj7            1/1     Running             0          1d
kube-system   kube-proxy-g2js4            1/1     Running             0          1d
kube-system   kube-proxy-rhq6v            1/1     Running             0          1d

$ kubectl describe pod guestbook-8k9pp

Name:           guestbook-8k9pp
Namespace:      default
Node:           ip-172-31-91-242.ec2.internal/172.31.91.242
Start Time:     Wed, 31 Oct 2018 04:59:11 -0800
Labels:         app=guestbook
Annotations:    <none>
Status:         Pending
IP:             
Controlled By:  ReplicationController/guestbook
Containers:
  guestbook:
    Container ID:   
    Image:          k8s.gcr.io/guestbook:v3
    Image ID:       
    Port:           3000/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       ContainerCreating
    Ready:          False
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-jb75l (ro)
Conditions:
  Type           Status
  Initialized    True 
  Ready          False 
  PodScheduled   True 
Volumes:
  default-token-jb75l:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-jb75l
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason                  Age                    From                                    Message
  ----     ------                  ----                   ----                                    -------
  Normal   SandboxChanged          11m (x19561 over 13h)  kubelet, ip-172-31-91-242.ec2.internal  Pod sandbox changed, it will be killed and re-created.
  Warning  FailedCreatePodSandBox  74s (x19368 over 13h)  kubelet, ip-172-31-91-242.ec2.internal  Failed create pod sandbox: rpc error: code = Unknown desc = NetworkPlugin cni failed to set up pod "guestbook-8k9pp_default" network: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: **desc = "transport: Error while dialing dial tcp 127.0.0.1:50051: connect: connection refused"**

Ответы [ 2 ]

0 голосов
/ 09 января 2019

У меня была похожая проблема. То же сообщение об ошибке, но гораздо более простой набор стручков. Использование kubectl get pods --all-namespaces показало, что у одного конкретного узла был CrashLoopBackOff.

Я масштабировал свои узлы, а затем снова уменьшал масштаб (фактически воссоздавая этот узел), и эта проблема, похоже, ушла.

0 голосов
/ 02 ноября 2018

Кластер Kubernetes, который я создал, находится на AWS EKS. Кластер EKS был создан мной вручную через консоль EKS.

Я создал второй кластер с официальным образцом VPC для кластера EKS (https://amazon -eks.s3-us-west-2.amazonaws.com / cloudformation / 2018-08-30 / amazon-eks- vpc-sample.yaml ), и, похоже, сейчас работает.

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

...