web-dev-qa-db-ja.com

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 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の2つのポッドがありますが、「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 file

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 run」でdockerイメージを実行すると、kubernetesを介してのみ問題なくイメージを実行できました。

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

kubernetes
46
Lucifer

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

ポッドは起動してすぐに終了するためクラッシュします。そのため、Kubernetesが再起動し、サイクルが継続します。

44
Steve Sloka
kubectl -n <namespace-name> describe pod <pod name>

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

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

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

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

3
Julien Nyambal

ブートストラップに時間がかかるアプリケーションがある場合、レディネス/活性プローブの初期値に関連している可能性があります。 initialDelaySecondsアプリケーションが多くの初期化を処理するため、SpringBootの値を120に増やすことで問題を解決しました。ドキュメントには、notデフォルト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を待って新しいチェックを開始します

私の場合、アプリケーションは非常に明確な方法でbootstrapできるようになったため、定期的なcrashloopbackoffが発生しないことがあります。

1
Marcello de Sales

私の場合、問題はSteve S.が言ったことです。

ポッドは起動してすぐに終了するためクラッシュします。そのため、Kubernetesが再起動し、サイクルが継続します。

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

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

0
Jakub Holý

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

コンテナに入るとき：

docker exec -it faulty:latest /bin/sh

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

欠陥のあるバージョンのdockerイメージは、インスタンスですでに利用可能です。

Faulty：latestインスタンスを削除したとき：

docker rmi faulty:latest

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

0
javabeangrinder