正如@Sukumar评论的那样，你需要让你的Dockerfile有一个命令来运行，或者让你的ReplicationController指定一个命令。

吊舱崩溃是因为它启动后立即退出，因此Kubernetes重新启动，循环继续。

我需要为后续的kubectl执行调用保持一个pod运行，正如上面的评论所指出的，我的pod正在被我的k8s集群杀死，因为它已经完成了所有的任务。我设法保持我的豆荚运行，只需用一个不会自动停止的命令踢豆荚:

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

#Show details of specific pod
kubectl  describe pod <pod name> -n <namespace-name>

# View logs for specific pod
kubectl  logs <pod name> -n <namespace-name>

在这个页面中，容器在正确运行一切之后死亡，但由于所有命令结束而崩溃。要么让服务在前台运行，要么创建一个keep alive脚本。通过这样做，Kubernetes将显示您的应用程序正在运行。我们必须注意到，在Docker环境中，不会遇到这个问题。只有Kubernetes想要一个可运行的应用程序。

更新(示例):

下面是如何在启动Netshoot容器时避免CrashLoopBackOff:

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

如果您的应用程序启动速度较慢，这可能与就绪/活动探测的初始值有关。我通过将initialDelaySeconds的值增加到120s来解决我的问题，因为我的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的默认值是什么给出了一个很好的解释。

运行状况或就绪状态检查算法的工作方式如下: 等待initialDelaySeconds 执行check并等待timeoutSeconds超时 如果连续成功的次数大于successThreshold返回成功 如果连续失败的次数大于failureThreshold，则返回失败，否则等待periodSeconds并开始新的检查

在我的例子中，我的应用程序现在可以以一种非常清晰的方式引导，因此我知道我不会得到周期性的崩溃回退，因为有时它会达到这些速率的极限。

就我而言，问题就像Steve S.提到的:

吊舱崩溃是因为它启动后立即退出，因此Kubernetes重新启动，循环继续。

也就是说，我有一个Java应用程序，它的主抛出了一个异常(并且某些东西覆盖了默认的未捕获异常处理程序，因此没有记录任何内容)。解决方案是将main的主体放入try{…}捕获并输出异常。这样我就能找出问题所在并修复它。

(另一个原因可能是应用程序中调用System.exit的东西;您可以使用自定义SecurityManager与覆盖的checkExit来防止(或记录的调用者)退出;参见https://stackoverflow.com/a/5401319/204205)。

在解决相同问题的同时，我发现使用kubeclt logs <pod_id>时没有日志。 因此，我ssh:ed在节点实例中尝试使用普通docker运行容器。令我惊讶的是，这也失败了。

当以下列物品进入货柜时:

docker exec -it faulty:latest /bin/sh

我四处打听，发现它不是最新的版本。

实例上已经有一个错误的docker映像版本。

当我删除故障:最新实例与:

docker rmi faulty:latest

一切都开始运转起来。

我的吊舱一直在崩溃，我找不到原因。幸运的是，kubernetes有一个空间保存了我的吊舱崩溃之前发生的所有事件。 (#按时间戳排序的事件列表)

要查看这些事件，运行命令:

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

如果需要，请确保在命令中添加——namespace mynamespace参数

命令输出中显示的事件显示了我的pod不断崩溃的原因。

我通过增加内存资源解决了这个问题

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

在你的yaml文件中，添加命令行和参数行:

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

对我有用。

我也有同样的问题，现在我终于解决了。我没有使用docker-compose文件。 我只是在Docker文件中添加了这一行，它起作用了。

ENV CI=true

参考: https://github.com/GoogleContainerTools/skaffold/issues/3882

试着重新运行吊舱并运行

 kubectl get pods --watch

在飞行过程中观察吊舱的状态。

在我的情况下，我只会看到最终结果，' CrashLoopBackOff '，但docker容器在本地运行良好。因此，我使用上面的命令查看了pod，我看到容器短暂地进入了OOMKilled状态，这对我来说意味着它需要更多内存。

我发现了同样的问题，并在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

我通过删除引号和数组内的命令值之间的空格来解决这个问题，这是因为容器启动后退出，没有可执行的命令，在容器内运行。

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

我也有类似的问题，但当我纠正了我的动物园管理员后，问题解决了。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

在我的例子中，这个错误是特定于hello-world docker映像的。我使用nginx图像而不是hello-world图像，错误被解决了。

在我的例子中，问题是错误的命令行参数列表。我在我的部署文件中这样做:

...
args:
  - "--foo 10"
  - "--bar 100"

而不是正确的方法:

...
args:
  - "--foo"
  - "10"
  - "--bar"
  - "100"

当我执行'docker run xxx '命令时，我终于找到了解决方案，然后我得到了错误。这是由于平台不完整造成的。

如上所述，容器在创建时退出。

如果您希望在不使用yaml文件的情况下进行测试，可以将sleep命令传递给kubectl创建部署语句。双连字符——表示命令，相当于Pod或Deployment yaml文件中的command:。

下面的命令为使用sleep 1234的debian创建了一个部署，因此它不会立即退出。

kubectl create deployment deb --image=debian:buster-slim -- "sh" "-c" "while true; do sleep 1234; done"

然后你可以创建一个服务等，或者，测试容器，你可以kubectl exec -it <pod-name>——sh(或——bash)到你刚刚创建的容器中测试它。

似乎Pod应该处于crashloopbackoff状态的原因有很多。

In my case, one of the container was terminating continuously due to the missing Environment value.

因此，调试的最佳方法是-

1. check Pod description output i.e. kubectl describe pod abcxxx
2. check the events generated related to the Pod i.e. kubectl get events| grep abcxxx
3. Check if End-points have been created for the Pod i.e. kubectl get ep
4. Check if dependent resources have been in-place e.g. CRDs or configmaps or any other resource that may be required.

kubectl logs -f POD，将只生成运行中的容器的日志。后缀——previous用于从前一个容器获取日志。主要用于调试。希望这能有所帮助。