我的库伯内特斯吊舱一直与"CrashLoopBackOff“相撞，但我找不到任何日志

Question

这就是我一直得到的：

[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描述荚的输出

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映像是从这个简单的码头文件中生成的：

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

我正在CentOS1611上运行我的kubernetes集群，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的对接映像，我就能够运行这个映像，没有任何问题，只有通过kubernetes，我才得到了崩溃。

有人能帮我吗，我怎么能不看到任何日志就调试呢？

Answer 1

正如@Sukumar所指出的，您需要让您的Dockerfile有一个要运行的命令，或者让您的ReplicationController指定一个命令。

吊舱正在崩溃，因为它启动后立即退出，因此库伯内特斯重新启动，循环继续。

Answer 2

#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>

Answer 3

如果您的应用程序引导速度较慢，它可能与就绪/活性探测的初始值相关。当我的initialDelaySeconds应用程序处理大量初始化时，我通过将SpringBoot的值增加到120 s来解决我的问题。文档没有提到默认的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并启动新的检查

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