Moje pody kubernetes ciągle ulegają awarii z komunikatem „CrashLoopBackOff”, ale nie mogę znaleźć żadnego dziennika

Oto, co otrzymuję:

[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

Poniżej znajduje się wynik z funkcji „opisać pody” kubectl opisać pody

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)"

Mam dwa pody: nfs-web-07rxz, nfs-web-fdr9h, ale jeśli zrobię „kubectl logs nfs-web-07rxz” lub z opcją „-p”, nie widzę żadnego dziennika w obu podach.

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

To jest mój plik yaml replicationController : plik 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

Mój obraz Dockera został utworzony z tego prostego pliku Dockera:

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

Używam klastra Kubernetes na CentOs-1611, wersja 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"}

Jeśli uruchomiłem obraz dockera przez "docker run", mogłem uruchomić obraz bez żadnego problemu, tylko przez kubernetes dostałem awarię.

Czy ktoś może mi pomóc, jak mogę debugować bez przeglądania żadnego dziennika?

Jak skomentował @Sukumar, musisz mieć swój plik Dockerfile z poleceniem do uruchomienia lub mieć swój ReplicationController określić polecenie.

Kapsuła ulega awarii, ponieważ uruchamia się, a następnie natychmiast zamyka, dlatego Kubernetes uruchamia się ponownie, a cykl trwa.

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

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

Musiałem utrzymywać działający pod dla kolejnych wywołań kubectl exec i jak wskazały powyższe komentarze, mój pod został zabity przez mój klaster k8s, ponieważ zakończył wykonywanie wszystkich swoich zadań. Udało mi się utrzymać działanie kapsuły, po prostu kopiąc ją komendą, która nie zatrzymywała się automatycznie, jak w:

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

Jeśli masz aplikację, która ładuje się wolniej, może to być związane z początkowymi wartościami sond gotowości / żywotności. Rozwiązałem swój problem, zwiększając wartość initialDelaySecondsdo 120 sekund, ponieważ moja SpringBootaplikacja obsługuje dużo inicjalizacji. Dokumentacja nie wspomina o domyślnym 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

Bardzo dobre wyjaśnienie tych wartości można znaleźć w artykule Jaka jest domyślna wartość initialDelaySeconds .

Algorytm sprawdzania stanu lub gotowości działa tak:

1. Poczekaj na initialDelaySeconds
2. wykonaj sprawdzenie i poczekaj timeoutSecondsna limit czasu, jeśli liczba kontynuowanych sukcesów jest większa niż successThresholdpowodzenie zwrotu
3. jeśli liczba kontynuowanych błędów jest większa niż failureThresholdzwrócenie błędu, w przeciwnym razie zaczekaj periodSecondsi rozpocznij nowe sprawdzenie

W moim przypadku moja aplikacja może teraz ładować się w bardzo przejrzysty sposób, dzięki czemu wiem, że nie otrzymam okresowego wyłączenia awaryjnego, ponieważ czasami byłoby to na granicy tych stawek.

Z tej strony kontener umiera po poprawnym uruchomieniu wszystkiego, ale ulega awarii, ponieważ wszystkie polecenia zakończyły się. Albo sprawisz, że Twoje usługi będą działały na pierwszym planie, albo utworzysz skrypt utrzymujący przy życiu. W ten sposób Kubernetes pokaże, że Twoja aplikacja jest uruchomiona. Należy zauważyć, że w Dockerśrodowisku ten problem nie występuje. Tylko Kubernetes chce działającej aplikacji.

Aktualizacja (przykład):

Oto jak uniknąć CrashLoopBackOff podczas uruchamiania kontenera Netshoot :

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

Mój kapsuła ciągle się zawieszała i nie mogłem znaleźć przyczyny. Na szczęście jest miejsce, w którym kubernetes zapisuje wszystkie zdarzenia, które miały miejsce przed rozbiciem kapsuły .
(# Lista zdarzeń posortowanych według sygnatury czasowej)

Aby zobaczyć te zdarzenia, uruchom polecenie:

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

pamiętaj, --namespace mynamespaceaby w razie potrzeby dodać argument do polecenia

Zdarzenia pokazane w danych wyjściowych polecenia pokazały mi, dlaczego mój kapsuła ciągle się zawieszała.

W pliku yaml dodaj linie poleceń i argumentów:

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

Pracuje dla mnie.

Zauważyłem ten sam problem i dodałem blok poleceń i argumentów w pliku yaml. Kopiuję próbkę mojego pliku yaml w celach informacyjnych

 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

W moim przypadku problemem było to, o czym wspomniał Steve S.:

Kapsuła ulega awarii, ponieważ uruchamia się, a następnie natychmiast zamyka, dlatego Kubernetes uruchamia się ponownie, a cykl trwa.

Mianowicie miałem aplikację Java, która mainwyrzuciła wyjątek (i coś przesłoniło domyślną procedurę obsługi nieprzechwyconych wyjątków, więc nic nie zostało zarejestrowane). Rozwiązaniem było umieścić ciało mainna try { ... } catchi wydrukować wyjątek. W ten sposób mogłem dowiedzieć się, co jest nie tak i naprawić.

(Inną przyczyną może być coś w wywołaniu aplikacji System.exit; możesz użyć niestandardowego SecurityManagerz przesłoniętym, checkExitaby zapobiec (lub zarejestrować wywołującego) wyjście; zobacz https://stackoverflow.com/a/5401319/204205 .)

Podczas rozwiązywania tego samego problemu nie znalazłem żadnych dzienników podczas używania kubeclt logs <pod_id>. Dlatego ssh: ed in do instancji węzła, aby spróbować uruchomić kontener przy użyciu zwykłego dockera. Ku mojemu zdziwieniu to również się nie udało.

Przy wejściu do kontenera z:

docker exec -it faulty:latest /bin/sh

i szperając wokół stwierdziłem, że nie była to najnowsza wersja.

W instancji była już dostępna wadliwa wersja obrazu platformy Docker.

Kiedy usunąłem wadliwe: najnowsza instancja z:

docker rmi faulty:latest

wszystko zaczęło działać.

Rozwiązałem ten problem, zwiększyłem zasoby pamięci

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

Miałem ten sam problem i teraz w końcu go rozwiązałem. Nie używam pliku Docker-Compose. Właśnie dodałem tę linię w moim pliku Docker i zadziałało.

ENV CI=true

Źródła: https://github.com/GoogleContainerTools/skaffold/issues/3882

Spróbuj ponownie uruchomić kapsułę i uciekać

 kubectl get pods --watch

aby obserwować stan kapsuły w miarę jej postępu.

W moim przypadku zobaczyłbym tylko wynik końcowy „CrashLoopBackOff”, ale kontener Dockera działał poprawnie lokalnie. Więc obserwowałem kapsuły używając powyższego polecenia i widziałem, jak pojemnik na krótko przechodzi w stan OOMKilled , co dla mnie oznaczało, że wymaga więcej pamięci.

Rozwiązałem ten problem, usuwając spację między cudzysłowami i wartością polecenia wewnątrz tablicy, dzieje się tak, ponieważ kontener zakończył działanie po uruchomieniu i nie ma wykonywalnego polecenia, które ma zostać uruchomione w kontenerze.

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

Miałem podobny problem, ale został rozwiązany, gdy poprawiłem zookeeper.yamlplik, w którym nazwa usługi była niezgodna z nazwami kontenerów wdrożenia pliku. Zostało rozwiązane, czyniąc je takimi samymi.

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