运行有意定期退出的容器
如何让Kubernates自动重新启动容器，该容器有目的地退出，以便从环境变量中获取新数据？
我有一个运行在Kubernates集群上的容器，其运行方式如下：
- 集装箱启动，工作轮询
- 如果它收到一个任务，它就会做一些工作。
- 它再次投票找工作，直到.
- 。。容器已经运行了超过一段时间，然后退出，而不是轮询更多的工作。
它需要不断地重新启动，因为它使用由Kubernates秘密填充的环境变量，这些秘密由另一个进程定期刷新。
我尝试过部署，但由于获得了CrashLoopBackOff状态，这似乎不太合适，这意味着工作人员被调度的次数越来越少。
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-fonky-worker
labels:
app: my-fonky-worker
spec:
replicas: 2
selector:
matchLabels:
app: my-fonky-worker
template:
metadata:
labels:
app: my-fonky-worker
spec:
containers:
- name: my-fonky-worker-container
image: my-fonky-worker:latest
env:
- name: NOTSOSECRETSTUFF
value: cats_are_great
- name: SECRETSTUFF
valueFrom:
secretKeyRef:
name: secret-name
key: secret-key我也尝试过一个CronJob，但这似乎有点麻烦，因为它可能意味着容器处于停止状态几秒钟。
回答 3
Stack Overflow用户
发布于 2019-08-20 15:01:31
正如@Josh所说的，您需要使用退出0，否则它将被视为失败的容器！这是参考文献
根据第一个例子，"Pod正在运行，并且有一个容器。容器成功退出。“如果您的restartPolicy被设置为“始终”(顺便说一句，这是默认的)，那么容器将重新启动，尽管Pod状态显示正在运行，但是如果您对容器进行日志记录，则可以看到容器的重新启动。
它需要不断地重新启动，因为它使用由Kubernates秘密填充的环境变量，这些秘密由另一个进程定期刷新。
我会对此采取不同的做法。我将按照解释的这里挂载配置映射，这将自动刷新挂载配置映射数据参考。注意:请注意“kubelet同步周期(默认情况下为1分钟)+ ConfigMaps缓存的ttl (默认情况下为1分钟)”来管理Pod中configmap数据的刷新速率。
Stack Overflow用户
发布于 2019-08-20 14:42:25
我认为解决这个问题的方法是将您的容器作为一个cron作业运行。但不要使用startingDeadlineSeconds作为容器杀手。
按计划进行。
在您的容器中，您可以让它轮询工作N次。在N次之后，它退出0。
Stack Overflow用户
发布于 2019-08-21 16:59:26
如果我在您的示例中正确理解了以下两个问题：
- 重新启动容器
- 更新秘密值
为了使您的秘密保持最新，您应该考虑使用阿米特·库马尔·古普塔注释描述的机密，并将机密作为卷(而不是环境变量)挂载，这里就是一个例子。
根据重新启动容器的第二个问题，它取决于garlicFrancium描述的退出代码是什么
从另一个角度来看，您可以使用init容器等待新任务和主容器，以便根据您的需求继续执行这些任务或创建作业调度程序。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
labels:
app: complete
name: complete
spec:
replicas: 1
selector:
matchLabels:
app: complete
template:
metadata:
labels:
app: complete
spec:
hostname: c1
containers:
- name: complete
command:
- "bash"
args:
- "-c"
- "wa=$(shuf -i 15-30 -n 1)&& echo $wa && sleep $wa"
image: ubuntu
imagePullPolicy: IfNotPresent
resources: {}
initContainers:
- name: wait-for
image: ubuntu
command: ['bash', '-c', 'sleep 30']
restartPolicy: Always请注意：
- 当卷中已经使用的秘密被更新时，投影密钥最终也会被更新。Kubelet正在检查安装的秘密是否在每一次周期同步中都是新鲜的。但是，它正在使用其本地缓存来获取秘密的当前值。缓存的类型可以使用(ConfigMapAndSecretChangeDetectionStrategy字段在KubeletConfiguration结构中)进行配置。它既可以通过基于ttl的watch (默认)传播，也可以直接将所有请求重定向到kube。因此，从更新秘密的时刻到将新密钥投影到Pod的那一刻的总延迟可以与kubelet同步周期+缓存传播延迟一样长，其中缓存传播延迟取决于所选的缓存类型(它等于观察传播延迟、缓存的ttl或零响应)。
- 使用作为subPath卷挂载的容器将不会接收机密更新。
另请参阅：
https://stackoverflow.com/questions/57575922
复制相似问题
腾讯云开发者
