user1595858
user1595858

Reputation: 3890

Are Kubernete's ConfigMaps Writable?

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

Answers (4)

Caesar
Caesar

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

Honord
Honord

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

Ryan Dawson
Ryan Dawson

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

stacksonstacks
stacksonstacks

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

Related Questions