Устранение ошибки «CrashLoopBackOff» при развертывании образа docker с помощью Kubernetes

#kubernetes #deployment #server #google-kubernetes-engine #crashloopbackoff

#kubernetes #развертывание #сервер #google-kubernetes-engine #crashloopbackoff

Вопрос:

На самом деле я следую инструкциям https://cloud.google.com/kubernetes-engine/docs/tutorials/hello-app#console руководство по развертыванию веб-приложения. Я создал файл и изображение docker в своем локальном каталоге. И я загрузил изображение в реестр контейнеров Google cloud platform. Передача образа в реестр завершена успешно. А затем я создал kubernetes cluster и попытался его развернуть. Но контейнер получил ошибку «CrashLoopBackOff».

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

Следуйте документам, ошибка заключается в том, что «модули повторно запускаются и выходят из строя», и решение внимательно просматривает журналы…

Я искал случай других пользователей: например, imagePullPolicy: всегда / restartPolicy: всегда, но ошибка не решена… введите описание образа здесь

ps: по журналу pods .. код ошибки равен 0

pps: Теперь я пытаюсь изменить файл yaml контейнера. imagePullPolicy ifnotPresent Чтобы Always . Но

 Pod "nginx-1-99dcd4d9f-84szv" is invalid: 
spec: Forbidden: pod updates may not change fields other than 
`spec.containers[*].image`, 
`spec.initContainers[*].image`, 
`spec.activeDeadlineSeconds` or 
`spec.tolerations` (only additions to existing tolerations)   

core.PodSpec{    
    Volumes: []core.Volume{
        {Name: "default-token-stk86", VolumeSource: core.VolumeSource{Secret: amp;core.SecretVolumeSource{SecretName: "default-token-stk86", DefaultMode: amp;420
                }
            }
        }
    },    InitContainers: nil,    Containers: []core.Container{
        {   
             TerminationMessagePath: "/dev/termination-log",    
             TerminationMessagePolicy: "File", 
             -  ImagePullPolicy: "Always", 
                ImagePullPolicy: "IfNotPresent",    
             SecurityContext: nil,    
             Stdin: false,
        },
    },    EphemeralContainers: nil,    RestartPolicy: "Always",
}
  

Появляется это сообщение об ошибке.

Вот мой файл Dockerfile. установите настройки и веб-страницу для тестирования ‘phptest.php » Чтобы позволить phptest.php Я изменил файл по умолчанию и init.sh

 FROM    ubuntu
RUN     apt-get update amp;amp; apt-get upgrade -y amp;amp; 
        apt-get -y install 
        nginx 
        vim 
        php-fpm 
COPY    srcs/default /
COPY    srcs/phptest.php /
COPY    srcs/init.sh /
EXPOSE  80
CMD     bash init.sh
  

init.sh находится здесь

 rm /etc/nginx/sites-available/default
mv default /etc/nginx/sites-available/
mv phptest.php /var/www/html
chown -R www-data /var/www/*
chmod -R 755 /var/www/*
service nginx start
service php7.4-fpm start
bash

  

Я загрузил новую задачу, потому что вопрос post не соответствовал рекомендациям stackoverflow

Комментарии:

1. Привет, это CrashLoopBackOff означает, что код в контейнере сбой. Проверьте журналы для модуля kubectl logs pod/POD_NAME_HERE -n NAMESPACE_HERE . Также ошибка, которую вы получаете при изменении политики imagePullPolicy, говорит о том, что вам нужно удалить модуль и создать его снова

Ответ №1:

Контейнеры Kubernetes по большей части не могут запускать интерактивные оболочки, но это то, что является основным процессом в вашем контейнере. (Изображение CMD выполняется init.sh ; это выполняет некоторую работу, включая запуск некоторых вспомогательных процессов, а затем выполняется bash ; bash не выполняется на tty, поэтому он завершается немедленно; поэтому контейнер также завершается; и поскольку его контейнер находится в цикле запуска и немедленного завершения, модуль переходит в состояние CrashLoopBackOff.)

Вам следует перепроектировать эту настройку так, чтобы у вас было два отдельных развертывания, одно из которых запускает PHP-приложение, а другое — обратный прокси-сервер Nginx. (И аналогично две соответствующие службы.) Каждый из них запускает эти процессы непосредственно как свои образы CMD (не пытайтесь использовать service ). Вы должны иметь возможность протестировать аналогичную настройку с помощью Docker Compose или другого более легкого инструмента, прежде чем переводить его обратно в среду Kubernetes.