【问题标题】:Kubernetes deployment not auto-terminating after successful run of command成功运行命令后,Kubernetes 部署不会自动终止
【发布时间】:2019-03-16 17:46:10
【问题描述】:

我有一个 Kubernetes 集群,我在其中创建了一个部署来运行一个 pod。不幸的是,在运行它之后,Pod 不想自行终止,而是进入了重新启动/CrashLoopBackOff 循环的连续状态。

命令(在入口点上)在第一次部署时运行正确,我希望它只运行一次。

我正在使用 Python K8s API 以编程方式部署配置了入口点的 docker 映像。这是我的部署 YAML:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kio
  namespace: kmlflow
  labels:
    app: kio
    name: kio
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kio
      name: kio
  template:
    metadata:
      labels:
        app: kio
        name: kio
    spec:
      containers:
      - name: kio-ingester
        image: MY_IMAGE
        command: ["/opt/bin/kio"]
        args: ["some", "args"]
        imagePullPolicy: Always
      restart: Never
  backofflimit: 0

感谢您的帮助

kubectl pod 的输出是:

Name:               ingest-160-779874b676-8pgv5
Namespace:          kmlflow
Priority:           0
PriorityClassName:  <none>
Node:               02-w540-02.glebe.kinetica.com/172.30.255.205
Start Time:         Thu, 11 Oct 2018 13:31:20 -0400
Labels:             app=kio
                    name=kio
                    pod-template-hash=3354306232
Annotations:        <none>
Status:             Running
IP:                 10.244.0.228
Controlled By:      ReplicaSet/ingest-160-779874b676
Containers:
  kio-ingester:
    Container ID:  docker://b67a682d04e69c2dc5c1be7e02bf2e4cf7a12a7557dfbe642dfb531ca4b03f07
    Image:         kinetica/kinetica-intel
    Image ID:      docker-pullable://docker.io/kinetica/kinetica-intel@sha256:eefbb6595eb71822300ef97d5cbcdac7ec58f2041f8190d3a2ba9cffd6a0d87c
    Port:          <none>
    Host Port:     <none>
    Command:
      /opt/gpudb/bin/kio
    Args:
      --source
      kinetica://172.30.50.161:9191::dataset_iris
      --destination
      kinetica://172.30.50.161:9191::iris5000
    State:          Waiting
      Reason:       CrashLoopBackOff
    Last State:     Terminated
      Reason:       Completed
      Exit Code:    0
      Started:      Thu, 11 Oct 2018 13:33:27 -0400
      Finished:     Thu, 11 Oct 2018 13:33:32 -0400
    Ready:          False
    Restart Count:  4
    Environment:    <none>
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from default-token-69wkn (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             False 
  ContainersReady   False 
  PodScheduled      True 
Volumes:
  default-token-69wkn:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  default-token-69wkn
    Optional:    false
QoS Class:       BestEffort
Node-Selectors:  <none>
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
Events:
  Type     Reason     Age                  From                                    Message
  ----     ------     ----                 ----                                    -------
  Normal   Scheduled  2m39s                default-scheduler                       Successfully assigned kmlflow/ingest-160-779874b676-8pgv5 to 02-w540-02.glebe.kinetica.com
  Normal   Created    89s (x4 over 2m28s)  kubelet, 02-w540-02.glebe.kinetica.com  Created container
  Normal   Started    89s (x4 over 2m28s)  kubelet, 02-w540-02.glebe.kinetica.com  Started container
  Warning  BackOff    44s (x7 over 2m15s)  kubelet, 02-w540-02.glebe.kinetica.com  Back-off restarting failed container
  Normal   Pulling    33s (x5 over 2m28s)  kubelet, 02-w540-02.glebe.kinetica.com  pulling image "kinetica/kinetica-intel"
  Normal   Pulled     33s (x5 over 2m28s)  kubelet, 02-w540-02.glebe.kinetica.com  Successfully pulled image "kinetica/kinetica-intel"

Kubectl logs &lt;crashing-pod&gt; 没有输出,因为带有注入参数的命令 KIO 成功运行不会将任何内容打印到标准输出。

【问题讨论】:

  • 它基本上是崩溃或退出不成功。你能发布kubectl describe &lt;pod-that-is-crashing&gt;kubectl logs &lt;pod-that-is-crashing&gt; 的输出吗
  • 使用此信息更新的原始帖子。该命令(它是从 pod 内运行的应用程序)是否有可能没有按照应有的代码 0 退出,因为它在重新启动并进入崩溃循环之前在第一次迭代中正常工作。在此过程中运行 kubectl get pods 表明 pod 状态确实从“ContainerCreating”变为“Running”到“Completed”,此时我可以看到它已经完成了它应该做的事情。但几秒钟后,吊舱状态开始从“正在运行”循环到“已完成”再到“CrashLoopBackOff”
  • 是否可以使用 batch/v1 API 将其作为作业启动,而不是使用 apps/v1 进行部署?
  • 是的,发布了一个答案。希望对您有所帮助!

标签: kubernetes kinetica


【解决方案1】:

如果您想运行一次任务并在成功完成后完成,您应该考虑使用Kubernetes JobsCronJobs

类似这样的:

apiVersion: batch/v1
kind: Job
metadata:
  name: kio
  namespace: kmlflow
  labels:
    app: kio
    name: kio
spec:
  template:
    metadata:
      labels:
        app: kio
        name: kio
    spec:
      containers:
      - name: kio-ingester
        image: MY_IMAGE
        command: ["/opt/bin/kio"]
        args: ["some", "args"]
        imagePullPolicy: Always
      restart: Never
  backoffLimit: 4

如果您有 Kubernetes 1.12 或更高版本,要自动删除作业,您可以使用ttlSecondsAfterFinished。不幸的是,如果您使用的是 Kuberbetes 1.11 或更早版本,则必须手动删除它们,或者您可以设置 CronJob 来执行此操作。

【讨论】:

  • 这个解决方案效果很好,谢谢。我想知道作业是否有办法在其成功状态达到 1 时自动删除自己?
  • 是的。如果您使用的是 k8s 1.12 或更高版本,则可以使用 ttlSecondsAfterFinished。如果您使用的是 k8s 1.11 或更早版本,则必须手动删除它们或构建自己的自动化。更新了答案。
猜你喜欢
  • 2020-06-08
  • 1970-01-01
  • 1970-01-01
  • 2010-10-10
  • 2023-02-15
  • 2018-01-26
  • 1970-01-01
  • 2019-07-15
相关资源
最近更新 更多