kubernetesポッドが「CrashLoopBackOff」でクラッシュし続けますが、ログが見つかりません

106

これは私が得続けているものです：

[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

以下は「describepods」からの出力です kubectldescribe 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の2つのポッドがありますが、「kubectl logs nfs-web-07rxz」または「-p」オプションを使用すると、両方のポッドにログが表示されません。

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

これは私のreplicationControlleryamlファイルです： replicationControlleryamlファイル

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

「dockerrun」でdockerイメージを実行すると、問題なくイメージを実行できましたが、kubernetesを介してのみクラッシュしました。

誰かが私を助けてくれますか、ログを見ずにデバッグするにはどうすればよいですか？

kubernetes 
— ルシファー
ソース
1
ポッドyamlにコマンドを追加してみてください。
— スクマール2017年
2
ログを確認してくださいkubectl logs -f <pod_name>。（サーバー/コンテナ）起動の問題である可能性があります。
— Vishrant
kubectl get eventsクラッシュループの原因を確認するために実行することもできます。
— MargachChris19年

回答:

83

@Sukumarがコメントしたように、Dockerfileに実行するコマンドを持たせるか、ReplicationControllerにコマンドを指定させる必要があります。

ポッドが起動してすぐに終了するため、ポッドがクラッシュします。したがって、Kubernetesが再起動し、サイクルが続行されます。

— スティーブ・スロカ
ソース
1
適切なDockerfileを追加してもエラーが発生する場合、その理由は何でしょうか。コマンドを正しく追加しても同じエラーが発生します。また、kubernetesデプロイメントを使用せずに独立したDockerイメージをテストすると、出力が得られます。したがって、Dockerfileでは問題ありません。その展開に関連する何か？ここで私が直面している問題全体を追加しました、stackoverflow.com / questions / 56001352 / … 。見て頂けますか？
— ジェイコブ
2
何CrashLoopBackoff手段と、この現象が発生することができ、様々なケースに深さに行く本当に良いブログがあります： managedkube.com/kubernetes/pod/failure/crashloopbackoff/k8sbot/...
— ガー
52 
kubectl -n <namespace-name> describe pod <pod name>

kubectl -n <namespace-name> logs -p  <pod name>
— user128364
ソース
47
このコマンドは問題を解決する場合もあれば、解決しない場合もありますが、適切な回答には、問題がどのように解決されるかについての説明が常に含まれている必要があります。
— BDL
最初のコマンドkubectl -n <namespace-name> describe pod <pod name>はポッドを記述することです。これを使用して、ポッドの作成およびリソースの不足などのポッドの実行におけるエラーを確認できます。2番目のコマンドkubectl -n <namespace-name> logs -p <pod name>は、ポッドで実行されているアプリケーションのログを確認するために使用できます。
— iamabhishek
13

後続のkubectlexec呼び出しのためにポッドを実行し続ける必要がありました。上記のコメントが指摘しているように、ポッドはすべてのタスクの実行を完了したため、k8sクラスターによって強制終了されていました。次のように自動的に停止しないコマンドでポッドをキックするだけで、ポッドを実行し続けることができました。

kubectl run YOUR_POD_NAME -n YOUR_NAMESPACE --image SOME_PUBLIC_IMAGE:latest --command tailf /dev/null
— hmacias
ソース
7
tailf私には機能しませんでしたが、これは機能しました（Alpine linuxの場合）：--command /usr/bin/tail -- -f /dev/null
— JakubHolý19年
1
ポッド名ではありません。デプロイメント名です。kubectl run <deployment name> -n <namespace> --image <image> --command tailf /dev/null
— ガブリエル呉
9

ブートストラップに時間がかかるアプリケーションがある場合は、準備/活性プローブの初期値に関連している可能性があります。アプリケーションが多くの初期化を処理する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して新しいチェックを開始します

私の場合、アプリケーションは非常に明確な方法でブートストラップできるようになりました。そのため、定期的なクラッシュループバックオフが発生しないことがわかっています。これは、これらのレートの制限に達することがあるためです。

— マルチェロデセールス
ソース
あなたは私に多くの時間を節約しました！ありがとうございました。私のプローブ時間は90年代で、ポッドを起動することすらできませんでした。
— Abhinav Pandey
8

このページにすべてのコマンドが終了しているため、コンテナのすべてを正しく実行した後、金型だがクラッシュします。サービスをフォアグラウンドで実行するか、キープアライブスクリプトを作成します。そうすることで、Kubernetesはアプリケーションが実行中であることを示します。Docker環境では、この問題は発生しないことに注意する必要があります。実行中のアプリが必要なのはKubernetesだけです。

更新（例）：

ここで回避する方法ですCrashLoopBackOffを起動するときに、Netshootのコンテナを：

kubectl run netshoot --image nicolaka/netshoot -- sleep infinity
— ジュリアン・ニャンバル
ソース
6

ポッドがクラッシュし続け、原因を見つけることができませんでした。幸い、ポッドがクラッシュする前に発生したすべてのイベントをkubernetesが保存するスペースがあります。
（タイムスタンプでソートされた#Listイベント）

これらのイベントを確認するには、次のコマンドを実行します。

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

--namespace mynamespace必要に応じて、必ずコマンドに引数を追加してください

コマンドの出力に表示されるイベントは、ポッドがクラッシュし続ける理由を示しています。

— マティアス
ソース
ありがとう！このヒントは、秘密のボリュームのマウントに問題があることを検出するのに役立ちました。
— 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

私の場合、問題はSteveS。が述べたことでした。

ポッドが起動してすぐに終了するため、ポッドがクラッシュします。したがって、Kubernetesが再起動し、サイクルが続行されます。

つまりmain、例外をスローしたJavaアプリケーションがありました（そして、何かがデフォルトのキャッチされなかった例外ハンドラーを上書きして、何もログに記録されませんでした）。解決策は、の体を入れていたmainにtry { ... } catchして例外をプリントアウト。したがって、私は何が悪かったのかを見つけて修正することができました。

（別の原因は、アプリの呼び出しにある可能性がSystem.exitあります。SecurityManagerオーバーライドさcheckExitれたカスタムを使用して、終了を防止（または呼び出し元をログに記録）できます。https：//stackoverflow.com/a/5401319/204205を参照してください。）

— ヤクブ・ホリー
ソース
0

同じ問題のトラブルシューティングを行っているときに、を使用するとログが見つかりませんでしたkubeclt logs <pod_id>。したがって、ノードインスタンスにSSHで接続して、プレーンDockerを使用してコンテナを実行しようとしました。驚いたことに、これも失敗しました。

コンテナに入るとき： 

docker exec -it faulty:latest /bin/sh

調べてみると、最新バージョンではないことがわかりました。

Dockerイメージの障害のあるバージョンがインスタンスですでに利用可能でした。

faulty：latestインスタンスを次のように削除したとき：

docker rmi faulty:latest

すべてが機能し始めました。

— javabeangrinder
ソース
0

この問題を解決しましたメモリリソースを増やしました

  resources:
          limits:
            cpu: 1
            memory: 1Gi
          requests:
            cpu: 100m
        memory: 250Mi
— ヨウスラADDALI
ソース
0

ポッドを再実行して実行してみてください

 kubectl get pods --watch

進行中のポッドのステータスを監視します。

私の場合、最終結果「CrashLoopBackOff」しか表示されませんが、Dockerコンテナーはローカルで正常に実行されました。そのため、上記のコマンドを使用してポッドを監視し、コンテナが一時的にOOMKilled状態に移行するのを確認しました。これは、より多くのメモリが必要であることを意味します。

— ジョシュ・ウォルフ
ソース
0

配列内の引用符とコマンド値の間のスペースを削除することでこの問題を解決しました。これは、コンテナーが起動後に終了し、コンテナー内で実行する実行可能コマンドが存在しないために発生します。

['sh', '-c', 'echo Hello Kubernetes! && sleep 3600']
— アルジュナ
ソース
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
— アシュナ
ソース
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.