Мои поды kubernetes продолжают вылетать из-за «CrashLoopBackOff», но я не могу найти ни одного журнала

Вот что я получаю:

[root@centos-master ~]# 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 describe pods.

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», я не вижу никаких журналов в обоих модулях.

[root@centos-master ~]# kubectl logs nfs-web-07rxz -p
[root@centos-master ~]# kubectl logs nfs-web-07rxz

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

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, версия kube:

[root@centos-master ~]# 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"}

Если я запустил образ докера с помощью «docker run», я смог запустить образ без каких-либо проблем, только через kubernetes я получил сбой.

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

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

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

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

kubectl -n <namespace-name> logs -p  <pod name> 

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

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

Если у вас есть приложение, которое загружается медленнее, это может быть связано с начальными значениями зондов готовности / живучести. Я решил свою проблему, увеличив значение 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и начните новую проверку

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

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

Обновить (пример):

Вот как избежать CrashLoopBackOff при запуске контейнера Netshoot :

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity

Моя капсула продолжала падать, и я не мог найти причину. К счастью, есть место, где kubernetes сохраняет все события, которые произошли до того, как мой модуль разбился .
(# Список событий, отсортированных по отметке времени)

Чтобы увидеть эти события, выполните команду:

kubectl get events --sort-by=.metadata.creationTimestamp

при необходимости не забудьте добавить --namespace mynamespaceаргумент в команду

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

В вашем yaml-файле добавьте строки command и args:

...
containers:
      - name: api
        image: localhost:5000/image-name 
        command: [ "sleep" ]
        args: [ "infinity" ]
...

Работает для меня.

Я заметил ту же проблему и добавил блок command и args в файл yaml. Я копирую образец своего файла yaml для справки

 apiVersion: v1
    kind: Pod
    metadata:
      labels:
        run: ubuntu
      name: ubuntu
      namespace: default
    spec:
      containers:
      - image: gcr.io/ow/hellokubernetes/ubuntu
        imagePullPolicy: Never
        name: ubuntu
        resources:
          requests:
            cpu: 100m
        command: ["/bin/sh"]
        args: ["-c", "while true; do echo hello; sleep 10;done"]
      dnsPolicy: ClusterFirst
      enableServiceLinks: true

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

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

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

(Другой причиной может быть что-то в вызывающем приложении System.exit; вы можете использовать обычай SecurityManagerс переопределением, checkExitчтобы предотвратить (или зарегистрировать вызывающего) выход; см. Https://stackoverflow.com/a/5401319/204205 .

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

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

docker exec -it faulty:latest /bin/sh

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

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

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

docker rmi faulty:latest

все заработало.

Решил эту проблему Увеличил ресурс памяти

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi 

У меня была такая же проблема, и теперь я наконец ее решил. Я не использую файл docker-compose. Я просто добавил эту строку в свой файл Docker, и она сработала.

ENV CI=true

Ссылка: https://github.com/GoogleContainerTools/skaffold/issues/3882

Попробуйте повторно запустить модуль и запустить

 kubectl get pods --watch

чтобы следить за статусом модуля по мере его выполнения.

В моем случае я бы увидел только конечный результат «CrashLoopBackOff», но контейнер докеров работал нормально локально. Итак, я наблюдал за модулями, используя указанную выше команду, и увидел, что контейнер на короткое время перешел в состояние OOMKilled , что для меня означало, что ему требуется больше памяти.

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

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']

У меня была аналогичная проблема, но она была решена, когда я исправил свой zookeeper.yamlфайл, в котором имя службы не соответствовало именам контейнеров развертывания файлов. Это было решено, сделав их такими же.

apiVersion: v1
kind: Service
metadata:
  name: zk1
  namespace: nbd-mlbpoc-lab
  labels:
    app: zk-1
spec:
  ports:
  - name: client
    port: 2181
    protocol: TCP
  - name: follower
    port: 2888
    protocol: TCP
  - name: leader
    port: 3888
    protocol: TCP
  selector:
    app: zk-1
---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  name: zk-deployment
  namespace: nbd-mlbpoc-lab
spec:
  template:
    metadata:
      labels:
        app: zk-1
    spec:
      containers:
      - name: zk1
        image: digitalwonderland/zookeeper
        ports:
        - containerPort: 2181
        env:
        - name: ZOOKEEPER_ID
          value: "1"
        - name: ZOOKEEPER_SERVER_1
          value: zk1