Почему состояние развертывания приложения «Доступно: 0», если служба правильно развернута в мини-кубе? - PullRequest
0 голосов
/ 02 июля 2019

Я пытаюсь развернуть внутренний компонент моего приложения для тестирования REST API.Я разбил компоненты на части и создал образ в minikube.i создал файл yaml для развертывания и создания служб.Теперь, когда я пытаюсь развернуть его через sudo kubectl create -f frontend-deployment.yaml, он развертывается без каких-либо ошибок, но когда я проверяю состояние развертываний, это то, что показано:

NAME   READY   UP-TO-DATE   AVAILABLE   AGE
back   0/3     3            0           2m57s

Интересно, что услуга, соответствующая этому развертыванию, доступна.

NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
back         ClusterIP   10.98.73.249   <none>        8080/TCP         3m9s

Я также попытался создать развертывание, запустив depmnment statemnts по отдельности, например sudo kubectl run back --image=back --port=8080 --image-pull-policy Never, но результат был таким же.*

kind: Service
apiVersion: v1
metadata:
  name: back
spec:
  selector:
    app: back
  ports:
  - protocol: TCP
    port: 8080
  type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: back
spec:
  selector:
      matchLabels:
        app: back
  replicas: 3
  template:
    metadata:
      labels:
        app: back
    spec:
      containers:
        - name: back
          image: back
          imagePullPolicy: Never
          ports:
            - containerPort: 8080

Как я могу выполнить развертывание и запустить его, так как это вызывает внутреннюю ошибку сервера на моей стороне интерфейса приложения?

Описание модуля pod

Name:           back-7fd9995747-nlqhq
Namespace:      default
Priority:       0
Node:           minikube/10.0.2.15
Start Time:     Mon, 15 Jul 2019 12:49:52 +0200
Labels:         pod-template-hash=7fd9995747
                run=back
Annotations:    <none>
Status:         Running
IP:             172.17.0.7
Controlled By:  ReplicaSet/back-7fd9995747
Containers:
  back:
    Container ID:   docker://8a46e16c52be24b12831bb38d2088b8059947d099299d15755d77094b9cb5a8b
    Image:          back:latest
    Image ID:       docker://sha256:69218763696932578e199b9ab5fc2c3e9087f9482ac7e767db2f5939be98a534
    Port:           8080/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Error
      Exit Code:    1
      Started:      Mon, 15 Jul 2019 12:49:54 +0200
      Finished:     Mon, 15 Jul 2019 12:49:54 +0200
    Ready:          False
    Restart Count:  1
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-c247f (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  default-token-c247f:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-c247f
    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   Scheduled  6s               default-scheduler  Successfully assigned default/back-7fd9995747-nlqhq to minikube
  Normal   Pulled     4s (x2 over 5s)  kubelet, minikube  Container image "back:latest" already present on machine
  Normal   Created    4s (x2 over 5s)  kubelet, minikube  Created container back
  Normal   Started    4s (x2 over 5s)  kubelet, minikube  Started container back
  Warning  BackOff    2s (x2 over 3s)  kubelet, minikube  Back-off restarting failed container

1 Ответ

0 голосов
/ 03 июля 2019

Как видите, ноль из трех Бобов имеет статус Готов:

NAME   READY   AVAILABLE
back   0/3     0 

Чтобы узнать, что происходит, вы должны проверить базовые Боды:

$ kubectl get pods -l app=back

, а затем посмотретьна События в их описании:

$ kubectl describe pod back-...
...