Мои кубернетовые стручки продолжают сбой с "CrashLoopBackOff", но я не могу найти ни одного журнала

Это то, что я продолжаю получать:

[[email protected] ~]# kubectl get pods
NAME               READY     STATUS             RESTARTS   AGE
nfs-server-h6nw8   1/1       Running            0          1h
nfs-web-07rxz      0/1       CrashLoopBackOff   8          16m
nfs-web-fdr9h      0/1       CrashLoopBackOff   8          16m

Ниже выведено из "описания стручков" kubectl описывают стручки

Events:
  FirstSeen LastSeen    Count   From                SubobjectPath       Type        Reason      Message
  --------- --------    -----   ----                -------------       --------    ------      -------
  16m       16m     1   {default-scheduler }                    Normal      Scheduled   Successfully assigned nfs-web-fdr9h to centos-minion-2
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id 495fcbb06836
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Started     Started container with docker id d56f34ae4e8f
  16m       16m     1   {kubelet centos-minion-2}   spec.containers{web}    Normal      Created     Created container with docker id d56f34ae4e8f
  16m       16m     2   {kubelet centos-minion-2}               Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "web" with CrashLoopBackOff: "Back-off 10s restarting failed container=web pod=nfs-web-fdr9h_default(461c937d-d870-11e6-98de-005056040cc2)"

У меня есть два контейнера: nfs-web-07rxz, nfs-web-fdr9h, но если я делаю "kubectl logs nfs-web-07rxz" или с опцией "-p", я не вижу никакого журнала в обоих контейнерах.

[[email protected] ~]# kubectl logs nfs-web-07rxz -p
[[email protected] ~]# kubectl logs nfs-web-07rxz

Это мой файл replicationController yaml: файл replicationController yaml

apiVersion: v1 kind: ReplicationController metadata:   name: nfs-web spec:   replicas: 2   selector:
    role: web-frontend   template:
    metadata:
      labels:
        role: web-frontend
    spec:
      containers:
      - name: web
        image: eso-cmbu-docker.artifactory.eng.vmware.com/demo-container:demo-version3.0
        ports:
          - name: web
            containerPort: 80
        securityContext:
          privileged: true

Изображение Docker было сделано из этого простого файла докеров:

FROM ubuntu
RUN apt-get update
RUN apt-get install -y nginx
RUN apt-get install -y nfs-common

Я запускаю свой кластер kubernetes на CentOs-1611, версия для куба:

[[email protected] ~]# kubectl version
Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"86dc49aa137175378ac7fba7751c3d3e7f18e5fc", GitTreeState:"clean", BuildDate:"2016-12-15T16:57:18Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Если я запустил изображение докера с помощью "запуска докеров", я смог запустить изображение без каких-либо проблем, только через кубернетов я получил сбой.

Может кто-то помочь мне, как я могу отлаживать, не видя какого-либо журнала?

Ответ 1

Как комментировал @Sukumar, вам нужно, чтобы у вашего Dockerfile была команда для запуска или у вашего ReplicationController была указана команда.

Пакет сбой, потому что он запускается, а затем немедленно выходит, таким образом Кубернете перезапускается, и цикл продолжается.

Ответ 2

kubectl -n <namespace-name> describe pod <pod name>

kubectl -n mortgages-dev2 logs -p  <pod name> 

Ответ 3

У меня была необходимость держать pod для последующих вызовов kubectl exec, и, как указывалось выше, мой блок был убит моим кластером k8s, потому что он выполнил все свои задачи. Мне удалось сохранить мой стручок, просто нажав на стручку с командой, которая не останавливалась автоматически, как в:

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null

Ответ 4

На этой странице контейнер умирает после правильного запуска, но сбой, потому что все команды завершены. Либо вы заставляете свои службы работать на переднем плане, либо создаете сценарий keep alive. Таким образом, Kubernetes покажет, что ваше приложение запущено. Следует отметить, что в среде Docker эта проблема не встречается. Только Кубернетес хочет запустить приложение.

Ответ 5

Если у вас есть приложение, которое загружается медленнее, оно может быть связано с начальными значениями проб готовности/живучести. Я решил свою проблему, увеличив значение initialDelaySeconds до 120 с, так как мое приложение SpringBoot имеет дело с большой инициализацией. В документации не упоминается значение по умолчанию 0 (https://kubernetes.io/docs/api-reference/v1.9/#probe-v1-core)

service:
  livenessProbe:
    httpGet:
      path: /health/local
      scheme: HTTP
      port: 8888
    initialDelaySeconds: 120
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10
  readinessProbe:
    httpGet:
      path: /admin/health
      scheme: HTTP
      port: 8642
    initialDelaySeconds: 150
    periodSeconds: 5
    timeoutSeconds: 5
    failureThreshold: 10

Очень хорошее объяснение об этих значениях дает " Что такое значение по умолчанию initialDelaySeconds".

Алгоритм проверки работоспособности или готовности работает следующим образом:

  1. ждать initialDelaySeconds
  2. выполнить проверку и подождать timeoutSeconds для тайм-аута, если число продолжающихся успехов больше, чем successThreshold возвращать успех
  3. если количество продолжающихся сбоев больше, чем failureThreshold возвращайте сбои, иначе подождите periodSeconds и начните новую проверку

В моем случае мое приложение теперь может быть загружено очень четко, так что я знаю, что не получу периодический аварийный возврат, потому что иногда он будет на пределе этих скоростей.

Ответ 6

В моем случае проблема заключалась в том, что упомянул Стив С.:

Стручок падает, потому что он запускается, затем сразу же выходит, поэтому Kubernetes перезапускается и цикл продолжается.

А именно, у меня было Java-приложение, main которого выдало исключение (и что-то переопределило обработчик необработанных исключений по умолчанию, чтобы ничего не регистрировалось). Решением было поместить тело main в try {... } catch и распечатать исключение. Таким образом я мог узнать, что было не так, и исправить это.

(Другой причиной может быть что-то в приложении, вызывающее System.exit; вы можете использовать собственный SecurityManager с переопределенным checkExit для предотвращения (или регистрации вызывающего) выхода; см. fooobar.com/questions/179310/.... )

Ответ 7

При устранении этой же проблемы я не нашел журналов при использовании kubeclt logs <pod_id>. Поэтому я ssh: ввел в экземпляр узла, чтобы попытаться запустить контейнер с помощью простого докера. К моему удивлению, это также не удалось.

При входе в контейнер с:

docker exec -it faulty:latest /bin/sh

и осматривая я обнаружил, что это была не последняя версия.

Неисправная версия образа докера уже была доступна в экземпляре.

Когда я удалил неисправный: последний экземпляр с:

docker rmi faulty:latest

все начало работать.