我有一个部署,其中包括一个configMap、persistentVolumeClaim和一个服务。我已经更改了configMap并将部署重新应用到我的集群中。我了解到此更改不会在部署中自动重启pod:
下面是Wiki.yaml的样子:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: dot-wiki
spec:
accessModes:
- ReadWriteOnce
volumeMode: Filesystem
resources:
requests:
storage: 4Gi
---
apiVersion: v1
kind: ConfigMap
metadata:
name: wiki-config
data:
config.json: |
{
"farm": true,
"security_type": "friends",
"secure_cookie": false,
"allowed": "*"
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: wiki-deployment
spec:
replicas: 1
selector:
matchLabels:
app: wiki
template:
metadata:
labels:
app: wiki
spec:
securityContext:
runAsUser: 1000
runAsGroup: 1000
fsGroup: 1000
initContainers:
- name: wiki-config
image: dobbs/farm:restrict-new-wiki
securityContext:
runAsUser: 0
runAsGroup: 0
allowPrivilegeEscalation: false
volumeMounts:
- name: dot-wiki
mountPath: /home/node/.wiki
command: ["chown", "-R", "1000:1000", "/home/node/.wiki"]
containers:
- name: farm
image: dobbs/farm:restrict-new-wiki
command: [
"wiki", "--config", "/etc/config/config.json",
"--admin", "bad password but memorable",
"--cookieSecret", "any-random-string-will-do-the-trick"]
ports:
- containerPort: 3000
volumeMounts:
- name: dot-wiki
mountPath: /home/node/.wiki
- name: config-templates
mountPath: /etc/config
volumes:
- name: dot-wiki
persistentVolumeClaim:
claimName: dot-wiki
- name: config-templates
configMap:
name: wiki-config
---
apiVersion: v1
kind: Service
metadata:
name: wiki-service
spec:
ports:
- name: http
targetPort: 3000
port: 80
selector:
app: wiki
除了Kubectl rollout restart deployment
之外,还有一些替代方法可以做到这一点:
1.重新启动吊舱
kubectl delete pods -l app=wiki
这会使部署的POD重新启动,在这种情况下,它们读取更新的ConfigMap。
apiVersion: apps/v1
kind: Deployment
# ...
volumes:
- name: config-templates
configMap:
name: wiki-config-v2
然后,重新应用部署:
kubectl apply -f wiki.yaml
由于部署清单中的Pod模板已经更改,部署的重新应用将重新创建所有Pod。新的吊舱将使用新版本的ConfigMap。
这种方法的另一个优点是,如果保留旧的ConfigMap(wiki-config-v1
)而不是删除它,则只需再次编辑部署清单,就可以随时恢复到以前的配置。
Kubernetes最佳实践(O'Reilly,2019)第一章描述了这种方法。
当与后台程序集关联的Kubernetes Pod的configmap更新时,如何自动重新启动它们? 根据kubernetes文档,当configmap卷挂载更新时,它会自动更新POD。但是,我并不认为后台进程集会发生这种情况。我错过了什么? 当我更新configmap中的字段以读取另一个日志文件时,虽然我看到卷挂载正在更新,但我看不到POD正在接收更改,除非我删除并重新创建后台启动。 有没有一种方
问题内容: 更改crontable文件后是否必须重新启动cron? 问题答案: 没有。 在cron手册页中: … cron然后将检查所有crontab的修改时间,并重新加载已更改的crontab。因此,无论何时修改crontab文件,都无需重新启动cron 但是,如果您只是想确保已完成, 要么
问题内容: 对于那些来自PHP背景的人来说,杀死节点并在每次代码更改后重新启动它的过程似乎非常繁琐。使用节点启动脚本以保存代码更改后自动重新启动节点时,是否有任何标志? 问题答案: forever模块具有多个node.js服务器的概念,并且可以启动,重新启动,停止和列出当前正在运行的服务器。它还可以监视文件更改并根据需要重新启动节点。 如果尚未安装,请安装: 安装后,调用命令:使用该标志监视文件的
问题内容: 我正在开发一个。是否可以在更改后立即重启?我正在使用CoffeeScript开发它。保存更改后可以观看以便重新启动吗? 问题答案: 您可以创建一个这种意愿的,只是另一个一饮而尽child_process。 我曾经为了接受“主任务”而在需要重新启动时运行。因此,为了运行此程序,您可以调用: 要进行测试,请致电或查看日志。
这个问题似乎不是关于特定的编程问题、软件算法或主要由程序员使用的软件工具。如果你认为这个问题会在另一个Stack Exchange网站上出现,你可以留下评论来解释问题的答案。 更改crontable文件后是否必须重新启动cron?