Reputation: 3890
Is it possible to directly modify the file mounted by configMap
? We have an application that reads a configuration file that was configMap
type and the application should able to edit the file and the changes should be persisted if the configMap
is shared with other pods and when the pod restarts.
If configMap
is not meant for this, then what should we relay on consul
to save the configuration?
Upvotes: 15
Views: 30905
Reputation: 8544
@RyanDawson might be correct from the perspective of what configmaps are intended for, but from a technical standpoint, they are very writable. And you won't be in bad company if you do. Consider for example Flink, which manages its HA state by writing it to configmaps.
And while @stacksonstacks is correct that configmaps can be written to by using kubectl, this is only half the way: If you want to update the configmap from your application, that means you need write access to configmaps from inside an application on k8s. And it's unlikely that you want to store your personal k8s API access token in a secret.
The best solution to this access problem is to give the pod that is supposed to write to the configmap a service account. This service account needs to be bound to a role that allows the actual access. With the service account, the pod will gain access to a secret token at /var/run/secrets/kubernetes.io/serviceaccount/
which can be used to access the kubernetes API. This token will also be automatically be picked up by kubectl.
I can't find a full example setup on the kubernetes documentation (you probably need to gather the details from the rbac and serviceaccount pages), so I'll add an example setup that continuously updates a configmap with the current time:
---
# Equivalent to whatever would be your application
apiVersion: apps/v1
kind: Deployment
metadata:
name: configmap-updater
labels:
app: configmap-updater
spec:
selector:
matchLabels:
name: configmap-updater
template:
metadata:
labels:
name: configmap-updater
spec:
serviceAccountName: configmap-update-sa # secrets automounted at /var/run/secrets/kubernetes.io/serviceaccount/
containers:
- name: configmap-updater-container
image: archlinux
# You could also use kubectl patch configmap hello -p '{"data": {"now":"'$(date +%s)'"}}'
# But I couldn't find an image that has kubectl preinstalled on the spot,
# so here you go: curl api client
command:
- bash
- -euc
- |
sec=/var/run/secrets/kubernetes.io/serviceaccount
while true; do
sleep 10;
curl -sS \
-H "Authorization: Bearer $(cat $sec/token)" \
-H "Content-Type: application/json-patch+json" \
--cacert $sec/ca.crt \
--request PATCH \
--data '[{"op": "replace", "path": "/data", "value": {"now":"'$(date +%s)'","updater":"'$(cat /etc/hostname)'"}}]' \
https://$KUBERNETES_SERVICE_HOST/api/v1/namespaces/default/configmaps/hello
done
---
# The configmap to be updated
apiVersion: v1
kind: ConfigMap
metadata:
name: hello
---
# And the access setup
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: configmap-update-sa
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: configmap-update-binding
subjects:
- kind: ServiceAccount
name: configmap-update-sa
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: configmap-update-role
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: configmap-update-role
# Benefit of using RBAC over giving your personal access token as a secret to your application: You can pinpoint which access you want to allow
rules:
- apiGroups: [""] # Empty string for kubernetes system
resources: [configmaps]
resourceNames: [hello]
verbs: [patch]
(I've tested this in minikube and know that it works in EKS. If this approach doesn't work somewhere, I'd be happy to know about it.)
If updating configmaps to hold state feels too dirty, one possibility may be to create a custom resource definition and give it some state attributes. That might express your intent better. But you won't be able to mount a CRD as a file, and from kubernetes' point of view, it will be very much the same, just some data changing.
Upvotes: 5
Reputation: 111
From Kubernetes doc, it can be updated see link
When a ConfigMap already being consumed in a volume is updated, projected keys are eventually updated as well. Kubelet is checking whether the mounted ConfigMap is fresh on every periodic sync. However, it is using its local ttl-based cache for getting the current value of the ConfigMap. As a result, the total delay from the moment when the ConfigMap is updated to the moment when new keys are projected to the pod can be as long as kubelet sync period + ttl of ConfigMaps cache in kubelet.
Upvotes: -4
Reputation: 12558
Yes a configmap is not intended to be writeable. If you're interacting with files from a configmap then you could instead put the files in a writeable volume and mount the volume. Or you could, as you suggest, use centralised configuration like consul. Given, that the app is dynamically writing to this data you could consider it state rather than configuration. Then it could be stored in a database. Another option could be a distributed cache such as redis or hazelcast.
Upvotes: 13
Reputation: 9321
AFAIK the changes to a ConfigMap
will only exist locally in-memory.
That is, changes aren't visible to other pods and on a pod restart the changes will be lost.
One solution is to use the kubectl
binary or the kubernetes API from within the configuring application to recreate the ConfigMap
after the configuration changes.
e.g. kubectl apply -f /path/to/updated/config.yaml
Upvotes: 5