Мої стручки 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 описують стручки

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 nfs-web-07rxz" або з опцією "-p", я не бачу жодного журналу в обох модулях.

[root@centos-master ~]# kubectl logs nfs-web-07rxz -p
[root@centos-master ~]# 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 було зроблено з цього простого файлу 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 за допомогою "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і почніть нову перевірку

У моєму випадку моя програма тепер може завантажуватися дуже чітко, так що я знаю, що не отримуватиму періодичного аварійного завершення роботи, оскільки іноді це буде на межі цих ставок.

На цій сторінці контейнер вмирає після того, як все правильно запущено, але аварійно завершує роботу, оскільки всі команди закінчились. Або ви змушуєте свої служби працювати на передньому плані, або ви створюєте сценарій підтримання життя. Роблячи це, Kubernetes покаже, що ваша програма працює. Слід зазначити, що в Dockerнавколишньому середовищі ця проблема не зустрічається. Запущений додаток хоче лише Kubernetes.

Оновлення (приклад):

Ось як уникнути CrashLoopBackOff при запуску контейнера Netshoot :

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

Мій стручок продовжував збій, і я не зміг знайти причину. На щастя , є місце, де kubernetes зберігає всі події, що відбулися до того, як мій стручок розбився .
(# Список подій, відсортованих за позначкою часу)

Щоб побачити ці події, запустіть команду:

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

обов’язково додайте --namespace mynamespaceаргумент до команди, якщо це необхідно

Події, показані в результатах команди, показали моє, чому мій стручок продовжував збій.

У своєму файлі yaml додайте рядки команд та аргументів:

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

Працює для мене.

Я спостерігав ту ж проблему і додав блок команд і аргументів у файл 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