내 kubernetes 포드가 "CrashLoopBackOff"로 계속 충돌하지만 로그를 찾을 수 없습니다.

111

이것이 내가 계속 얻는 것입니다.

[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

아래는 "describe pods" 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

이것은 내 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

CentOs-1611, kube 버전에서 kubernetes 클러스터를 실행하고 있습니다.

[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를 통해서만 충돌이 발생했습니다.

누군가 나를 도울 수 있습니까? 로그를 보지 않고 어떻게 디버깅 할 수 있습니까?

kubernetes 
— 샛별
소스
1
pod yaml에 명령 을 추가해 볼 수 있습니까 ?
— Sukumar
2
kubectl logs -f <pod_name>(서버 / 컨테이너) 시작 문제 일 수있는 로그를 확인하십시오 .
— Vishrant
또한 실행할 수 있습니다 kubectl get events호감 루프 원인을 확인합니다.
— Margach Chris

답변:

88

@Sukumar가 언급했듯이 Dockerfile 에 실행할 명령 이 있거나 ReplicationController가 명령을 지정하도록해야합니다.

포드가 시작된 후 즉시 종료되기 때문에 충돌이 발생하므로 Kubernetes가 다시 시작되고주기가 계속됩니다.

— 스티브 슬로 카
소스
1
적절한 Dockerfile이 추가되었지만 여전히 오류가 발생한다면 그 이유는 무엇일까요? 명령을 제대로 추가해도 동일한 오류가 발생합니다. 그리고 kubernetes deployment를 사용하지 않고 독립된 도커 이미지를 테스트 할 때 출력을 얻습니다. 따라서 Dockerfile에는 문제가 없습니다. 배포와 관련된 것이 있습니까?. 여기에 내가 직면 한 전체 문제인 stackoverflow.com/questions/56001352/…를 추가했습니다 . 좀 봐 주실 래요?
— Jacob
2
CrashLoopBackoff의 의미와 이것이 발생할 수있는 다양한 경우에 대해 자세히 설명하는 정말 좋은 블로그가 있습니다. managedkube.com/kubernetes/pod/failure/crashloopbackoff/k8sbot/…
— gar
54 
kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name>
— user128364
소스
50
이 명령이 문제를 해결하거나 해결하지 못할 수도 있지만 좋은 대답에는 항상 문제 해결 방법에 대한 설명이 포함되어야합니다.
— BDL
1
첫 번째 명령 kubectl -n <namespace-name> describe pod <pod name>은 pod를 설명하는 것입니다. pod 생성 및 리소스 부족 등 pod 실행시 오류를 확인하는 데 사용할 수 있습니다. 두 번째 명령 kubectl -n <namespace-name> logs -p <pod name>은 pod에서 실행중인 애플리케이션의 로그를 확인하는 데 사용할 수 있습니다 .
— iamabhishek
13

후속 kubectl exec 호출을 위해 포드를 계속 실행할 필요가 있었고 위의 설명에서 지적했듯이 모든 작업 실행을 완료했기 때문에 내 포드가 내 k8s 클러스터에 의해 죽임을당했습니다. 다음과 같이 자동으로 중지되지 않는 명령으로 포드를 걷어차 서 포드를 계속 실행했습니다.

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null
— hmacias
소스
7
tailf나를 위해 작동하지만이 (알파인 리눅스에)하지 않았다 :--command /usr/bin/tail -- -f /dev/null
— 야쿱 거룩한
1
포드 이름이 아닙니다. 배포 이름입니다. kubectl run <deployment name> -n <namespace> --image <image> --command tailf /dev/null
— Gabriel Wu
10

부트 스트랩 속도가 느린 애플리케이션이있는 경우 준비 상태 / 활성 상태 프로브의 초기 값과 관련이있을 수 있습니다. initialDelaySeconds내 SpringBoot응용 프로그램이 많은 초기화를 처리 하므로 값 을 120s로 늘려 문제를 해결했습니다 . 문서에는 기본값 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

이러한 값에 대한 아주 좋은 설명은 What is the default value of initialDelaySeconds에 의해 제공됩니다 .

상태 또는 준비 상태 확인 알고리즘은 다음과 같이 작동합니다.

  1. 기다립니다 initialDelaySeconds
  2. 확인을 수행하고 timeoutSeconds연속 성공 횟수가 successThreshold반환 성공 보다 큰 경우 시간 초과를 기다립니다.
  3. 연속 실패 수가 failureThreshold리턴 실패 보다 큰 경우 그렇지 않으면 대기 periodSeconds하고 새 검사를 시작하십시오.

제 경우에는 애플리케이션이 이제 매우 명확한 방식으로 부트 스트랩 할 수 있으므로 때때로 해당 속도의 한계에 도달하기 때문에주기적인 충돌 루프백 오프가 발생하지 않는다는 것을 알 수 있습니다.

— Marcello de Sales
소스
당신은 저에게 많은 시간을 절약했습니다! 감사합니다. 내 프로브 시간은 90 초 였고 포드가 시작되지도 않았습니다.
— Abhinav Pandey
Lol 광산은 1 초 였으므로 즉시 추락했습니다. 300으로 전환했고 이제 정상적으로 실행 중입니다!
— takanuva15
9

에서 이 페이지 의 모든 명령이 종료하기 때문에, 컨테이너 제대로 모든 것을 실행 한 후 다이하지만 충돌합니다. 서비스를 포 그라운드에서 실행하거나 연결 유지 스크립트를 만듭니다. 이렇게하면 Kubernetes는 애플리케이션이 실행 중임을 보여줍니다. 우리는에주의해야 할 Docker환경이 문제가 발생하지 않습니다. 실행중인 앱을 원하는 것은 Kubernetes뿐입니다.

업데이트 (예) :

Netshoot 컨테이너를 시작할 때 CrashLoopBackOff 를 피하는 방법은 다음과 같습니다 .

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity
— 줄리앙 얌발
소스
7

내 포드가 계속 충돌했고 원인을 찾을 수 없었습니다. 다행히도 kubernetes가 내 포드가 충돌하기 전에 발생한 모든 이벤트를 저장하는 공간이 있습니다.
(타임 스탬프별로 정렬 된 #List Events)

이러한 이벤트를 보려면 다음 명령을 실행하십시오.

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

--namespace mynamespace필요한 경우 명령에 인수 를 추가하십시오.

명령 출력에 표시된 이벤트는 내 포드가 계속 충돌하는 이유를 보여줍니다.

— Matyas
소스
감사! 이 팁은 비밀로 볼륨을 마운트하는 데 문제가 있음을 감지하는 데 도움이되었습니다.
— Leif John
또한 포드에 할당 된 관리 ID가 잘못되었음을 발견하는 데 도움이되었습니다.
— Jorn.Beyers
3

yaml 파일에서 명령 및 인수 줄을 추가합니다.

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

나를 위해 작동합니다.

— 마르셀라 로메로
소스
1

동일한 문제를 관찰하고 yaml 파일에 명령 및 args 블록을 추가했습니다. 참조를 위해 내 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
— amit23comp
소스
0

제 경우 문제는 Steve S.가 언급 한 것입니다.

포드가 시작된 후 즉시 종료되기 때문에 충돌이 발생하므로 Kubernetes가 다시 시작되고주기가 계속됩니다.

즉 main, 예외 가 발생한 Java 응용 프로그램이 있습니다 (그리고 아무것도 기록되지 않도록 기본 잡히지 않은 예외 처리기를 재정의했습니다). 해결책은 본문을 main넣고 try { ... } catch예외를 인쇄하는 것이 었습니다 . 따라서 나는 무엇이 잘못되었는지 알아 내고 고칠 수있었습니다.

(또 다른 원인은 앱 호출의 무언가 일 System.exit수 있습니다. 사용자 정의 SecurityManager를 재정 의하여 종료 checkExit를 방지 (또는 호출자 기록) 할 수 있습니다 . https://stackoverflow.com/a/5401319/204205를 참조 하십시오 .

— 야 쿠브 홀리
소스
0

동일한 문제를 해결하는 동안 kubeclt logs <pod_id>. 따라서 일반 도커를 사용하여 컨테이너를 실행하려고 노드 인스턴스에 ssh : ed. 놀랍게도 이것도 실패했습니다.

다음으로 용기에 들어갈 때 : 

docker exec -it faulty:latest /bin/sh

주변을 샅샅이 뒤져 최신 버전이 아니라는 것을 알았습니다.

인스턴스에서 이미 잘못된 버전의 Docker 이미지를 사용할 수 있습니다.

faulty : latest 인스턴스를 다음과 같이 제거했을 때 :

docker rmi faulty:latest

모든 것이 작동하기 시작했습니다.

— 자바빈 그라인더
소스
0

이 문제를 해결했습니다. 메모리 리소스를 늘 렸습니다.

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi
— 요 스라 아 달리
소스
0

포드를 다시 실행하고 실행 해보십시오.

 kubectl get pods --watch

진행되는 포드의 상태를 확인합니다.

제 경우에는 'CrashLoopBackOff'라는 최종 결과 만 표시되지만 도커 컨테이너는 로컬에서 정상적으로 실행되었습니다. 그래서 위의 명령을 사용하여 포드를보고 컨테이너가 OOMKilled 상태 로 잠시 진행되는 것을 보았습니다 . 이는 더 많은 메모리가 필요하다는 것을 의미합니다.

— 조쉬 울프
소스
0

배열 내부의 따옴표와 명령 값 사이의 공백을 제거 하여이 문제를 해결했습니다. 이는 컨테이너가 시작된 후 종료되고 컨테이너 내부에서 실행할 실행 가능한 명령이 없기 때문에 발생합니다.

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
— 아르 준 A
소스
0

비슷한 문제가 있었지만 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
— Ashna
소스
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.