Question

我试图在GKE上部署一个幽灵博客，在persistent disks with WordPress tutorial之后工作。我有一个工作容器，可以在GKE节点上手动运行：

docker run -d --name my-ghost-blog -p 2368:2368 -d us.gcr.io/my_project_id/my-ghost-blog

我也可以使用另一个教程中的以下方法正确创建一个pod：

kubectl run ghost --image=us.gcr.io/my_project_id/my-ghost-blog --port=2368

当我这样做时，我可以从群集中卷曲内部IP上的博客，并从kubectl get pod获得以下输出：

Name:       ghosty-nqgt0
Namespace:      default
Image(s):     us.gcr.io/my_project_id/my-ghost-blog
Node:       very-long-node-name/10.240.51.18
Labels:       run=ghost
Status:       Running
Reason:
Message:
IP:       10.216.0.9
Replication Controllers:  ghost (1/1 replicas created)
Containers:
  ghosty:
    Image:  us.gcr.io/my_project_id/my-ghost-blog
    Limits:
      cpu:    100m
    State:    Running
      Started:    Fri, 04 Sep 2015 12:18:44 -0400
    Ready:    True
    Restart Count:  0
Conditions:
  Type    Status
  Ready   True
Events:
  ...

当我尝试根据一个yaml文件创建pod时，问题出现了，符合Wordpress教程。这是yaml：

metadata:
  name: ghost
  labels:
    name: ghost
spec:
  containers:
    - image: us.gcr.io/my_project_id/my-ghost-blog
      name: ghost
      env:
        - name: NODE_ENV
          value: production
        - name: VIRTUAL_HOST
          value: myghostblog.com
      ports:
        - containerPort: 2368

当我运行kubectl create -f ghost.yaml时，会创建pod，但从未准备好：

> kubectl get pod ghost
NAME      READY     STATUS    RESTARTS   AGE
ghost     0/1       Running   11         3m

随着kubectl describe pod ghost：

的输出所确认，pod会不断重启

Name:       ghost
Namespace:      default
Image(s):     us.gcr.io/my_project_id/my-ghost-blog
Node:       very-long-node-name/10.240.51.18
Labels:       name=ghost
Status:       Running
Reason:
Message:
IP:       10.216.0.12
Replication Controllers:  <none>
Containers:
  ghost:
    Image:  us.gcr.io/my_project_id/my-ghost-blog
    Limits:
      cpu:    100m
    State:    Running
      Started:    Fri, 04 Sep 2015 14:08:20 -0400
    Ready:    False
    Restart Count:  10
Conditions:
  Type    Status
  Ready   False
Events:
  FirstSeen       LastSeen      Count From              SubobjectPath       Reason    Message
  Fri, 04 Sep 2015 14:03:20 -0400 Fri, 04 Sep 2015 14:03:20 -0400 1 {scheduler }                      scheduled Successfully assigned ghost to very-long-node-name
  Fri, 04 Sep 2015 14:03:27 -0400 Fri, 04 Sep 2015 14:03:27 -0400 1 {kubelet very-long-node-name} implicitly required container POD created   Created with docker id dbbc27b4d280
  Fri, 04 Sep 2015 14:03:27 -0400 Fri, 04 Sep 2015 14:03:27 -0400 1 {kubelet very-long-node-name} implicitly required container POD started   Started with docker id dbbc27b4d280
  Fri, 04 Sep 2015 14:03:27 -0400 Fri, 04 Sep 2015 14:03:27 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      created   Created with docker id ceb14ba72929
  Fri, 04 Sep 2015 14:03:27 -0400 Fri, 04 Sep 2015 14:03:27 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      started   Started with docker id ceb14ba72929
  Fri, 04 Sep 2015 14:03:27 -0400 Fri, 04 Sep 2015 14:03:27 -0400 1 {kubelet very-long-node-name} implicitly required container POD pulled    Pod container image "gcr.io/google_containers/pause:0.8.0" already present on machine
  Fri, 04 Sep 2015 14:03:30 -0400 Fri, 04 Sep 2015 14:03:30 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      started   Started with docker id 0b8957fe9b61
  Fri, 04 Sep 2015 14:03:30 -0400 Fri, 04 Sep 2015 14:03:30 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      created   Created with docker id 0b8957fe9b61
  Fri, 04 Sep 2015 14:03:40 -0400 Fri, 04 Sep 2015 14:03:40 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      created   Created with docker id edaf0df38c01
  Fri, 04 Sep 2015 14:03:40 -0400 Fri, 04 Sep 2015 14:03:40 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      started   Started with docker id edaf0df38c01
  Fri, 04 Sep 2015 14:03:50 -0400 Fri, 04 Sep 2015 14:03:50 -0400 1 {kubelet very-long-node-name} spec.containers{ghost}      started   Started with docker id d33f5e5a9637
...

如果我不杀死pod，这个创建/开始的循环将永远持续下去。与成功pod的唯一区别是缺少复制控制器。我不认为这是问题所在，因为教程没有提及rc。

为什么会这样？如何从配置文件创建成功的pod？我会在哪里找到关于正在发生的事情的更详细的日志？

Answer 1

如果相同的泊坞窗图片通过kubectl run工作但没有在pod中工作，则pod规格出现问题。比较从规范创建的pod的完整输出和由rc创建的pod的完整输出，通过为两者运行kubectl get pods <name> -o yaml来查看不同的内容。在黑暗中拍摄：pod规范中指定的环境变量是否可能导致它在启动时崩溃？

Answer 2

也许你可以在yaml文件中使用不同的重启策略？

我相信你所拥有的相当于

- restartPolicy: Never

没有复制控制器。您可以尝试将此行添加到yaml并将其设置为Always（这将为您提供RC）或OnFailure。

https://github.com/kubernetes/kubernetes/blob/master/docs/user-guide/pod-states.md#restartpolicy

Answer 3

容器日志可能很有用，使用kubectl日志

用法：

kubectl logs [-p] POD [-c CONTAINER]

http://kubernetes.io/v1.0/docs/user-guide/kubectl/kubectl_logs.html

Google Container Engine上的Kubernetes pod不断重启，从未准备好

3 个答案: