Eri*_*bbs 6 configuration kubernetes
我有一个部署,其中包括一个 configMap、persistentVolumeClaim 和一个服务。我更改了 configMap 并将部署重新应用于我的集群。我了解此更改不会自动重新启动部署中的 pod:
更新了 configMap.yaml 但它没有被应用到 Kubernetes pods
我知道我可以kubectl delete -f wiki.yaml && kubectl apply -f wiki.yaml。但这会破坏持久卷,其中包含我希望在重启后继续存在的数据。如何以保留现有卷的方式重新启动 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
Run Code Online (Sandbox Code Playgroud)
对于配置更改后重新启动容器的具体问题,从 kubectl v1.15 开始,您可以执行以下操作:
# apply the config changes
kubectl apply -f wiki.yaml
# restart the containers in the deployment
kubectl rollout restart deployment wiki-deployment
Run Code Online (Sandbox Code Playgroud)
除了 之外kubectl rollout restart deployment,还有一些替代方法可以做到这一点:
1. 重启 Pod
kubectl delete pods -l app=wiki
Run Code Online (Sandbox Code Playgroud)
这会导致您的 Deployment 的 Pod 重新启动,在这种情况下,它们会读取更新的 ConfigMap。
2. 对 ConfigMap 进行版本控制
与其简单地命名您的 ConfigMap wiki-config,不如将其命名为wiki-config-v1。然后,当您更新配置时,只需创建一个名为 的新 ConfigMap wiki-config-v2。
现在,编辑您的部署规范以引用wiki-config-v2ConfigMap 而不是wiki-config-v1:
apiVersion: apps/v1
kind: Deployment
# ...
volumes:
- name: config-templates
configMap:
name: wiki-config-v2
Run Code Online (Sandbox Code Playgroud)
然后,重新应用部署:
apiVersion: apps/v1
kind: Deployment
# ...
volumes:
- name: config-templates
configMap:
name: wiki-config-v2
Run Code Online (Sandbox Code Playgroud)
由于部署清单中的 Pod 模板已更改,因此重新应用部署将重新创建所有 Pod。新 Pod 将使用新版本的 ConfigMap。
作为这种方法的另一个优点,如果您保留旧的 ConfigMap ( wiki-config-v1) 而不是删除它,您可以随时通过再次编辑部署清单来恢复到以前的配置。
这种方法在Kubernetes 最佳实践(O'Reilly, 2019) 的第 1 章中有所描述。
| 归档时间: |
|
| 查看次数: |
5707 次 |
| 最近记录: |