库伯内特斯工作清理
据我所知，作业对象应该在一定时间后收获豆荚。但是在我的GKE集群（库伯内特斯1.1.8）上，“kubectl get pods-a”似乎可以列出几天前的豆荚。
所有这些都是使用乔布斯API创建的。
我确实注意到在使用 kubectl 删除作业后，pod 也被删除了。
我在这里主要担心的是，我将在批量作业中在集群上运行成千上万个pod，并且不想让内部待办系统过载。
共有3个答案
我最近构建了一个kubernetes操作符来执行此任务。
部署后，它将监视选定的命名空间，并删除已完成的作业/pod（如果它们完成时没有错误/重启）。
https://github.com/lwolf/kube-cleanup-operator
确实，你以前必须手动删除工作。@puja在写作时的回答是正确的。
Kubernetes 1.12.0发布了一个TTL特性(在alpha中),您可以设置它在完成后的指定秒数自动清理作业(changelog)。您可以将其设置为零，以便立即清理。查看工作文档。
文档中的示例:
apiVersion: batch/v1
kind: Job
metadata:
name: pi-with-ttl
spec:
ttlSecondsAfterFinished: 100
template:
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
看起来从 Kubernetes 1.6（和 v2alpha1 api 版本）开始，如果你使用 cronjobs 来创建作业（反过来，创建你的 pod），你将能够限制保留多少旧作业。只需将以下内容添加到您的工作规范中：
successfulJobsHistoryLimit: X
failedJobsHistoryLimit: Y
其中X和Y是系统应该保留多少先前运行的作业的限制（默认情况下，它会无限期地保留作业[至少在1.5版上]）
编辑2018-09-29:
对于更新的K8S版本，更新的留档链接如下：
>
CronJob - 作业历史记录限制
CronJob API 规范
-
我正在尝试在Kubernetes集群（Azure AKS）中部署Flink作业。作业群集在启动后立即中止，但任务管理器运行正常。 docker镜像创建成功，没有任何异常。我可以运行docker镜像，也可以SSHdocker镜像。 我已经按照以下链接中提到的步骤： https://github.com/apache/flink/tree/release-1.9/flink-container/kub
-
我在windows 10中创建了两个在我的minikube环境中运行的POD。一个POD带有Spring boot应用程序容器，另一个POD带有mysql容器。对于Spring boot应用程序，服务类型为nodePort，对于MYSQL pod，服务类型为club sterIP。这意味着Mysql pod只需要在集群内部进行通信。但是对于Spring boot应用程序，需要从浏览器访问，所以我配
-
首先，我开始库伯内特斯使用法兰绒与。 然后我重置所有并使用重新启动。 但是，接口 仍然是 这就是我清理的方式： 我在重置中遗漏了什么吗？
-
我假设没有愚蠢的问题，所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行1.15的Kubernetes集群。AKS上的x，通过Terraform部署和管理。AKS最近宣布Azure将在AKS上停用Kubernetes的1.15版本，我需要将集群升级到1.16或更高版本。现在，据我所知，直接在Azure中升级集群不会对集群的内容产生任何影响，即节点、豆荚、秘密和当前在那里的所有其他
-
我是库伯内特斯的新手。我正在为K8S使用GKE托管服务。有2个部署nginx、httpd，并为这2个部署创建了NodePort服务。 我正在尝试为服务创建入口规则。nginx入口控制器是通过helm安装的。我有一个来自freenom的域，并将Google云DNS设置为使用静态公共IP。当我尝试点击入口URL（domain/nginx）时，它会给出： "默认后端-404" 部署： 服务： 与http
-
我在Kubernetes是个新手。我想知道在kubernetes环境中最好的生产部署场景是什么。 在过去的学派中，我习惯于将Web服务器（例如Nginx或Apache）放在DMZ层，而将其放在其他层（我们称之为层）。这样，只有web服务器在DMZ上，恶意攻击只能在web服务器VM上进行。 据我所知，K8S部署不再需要这种方法；这是因为K8S自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。