Reputation: 1
Below is the manifest for Pod within a deployment:
apiVersion: apps/v1
kind: Deployment
metadata:
name: prometheus-deployment
namespace: monitoring
labels:
app: prometheus
spec:
replicas: 1
selector:
matchLabels:
app: prometheus
template:
metadata:
labels:
app: prometheus
annotations:
version: "1"
spec:
containers:
- name: prometheus-server
image: prom/prometheus:v2.9.2
imagePullPolicy: "IfNotPresent"
args:
- --config.file=/etc/config/prometheus.yml
- --storage.tsdb.path=/data
- --web.console.libraries=/etc/prometheus/console_libraries
- --web.console.templates=/etc/prometheus/consoles
- --web.enable-lifecycle
volumeMounts:
- name: config-volume
mountPath: /etc/config/prometheus.yml
subPath: prometheus.yml
- name: prometheus-data
mountPath: /data
subPath: ""
resources:
limits:
cpu: 200m
memory: 512Mi
requests:
cpu: 100m
memory: 256Mi
ports:
- containerPort: 9090
readinessProbe:
httpGet:
path: /-/ready
port: 9090
initialDelaySeconds: 30
timeoutSeconds: 30
livenessProbe:
httpGet:
path: /-/healthy
port: 9090
initialDelaySeconds: 30
timeoutSeconds: 30
securityContext:
runAsNonRoot: true
runAsUser: 65534
volumes:
- name: config-volume
configMap:
name: prometheus-config
- name: prometheus-data
emptyDir: {}
where prometheus-config
is being configured as shown below:
apiVersion: v1
kind: ConfigMap
metadata:
name: prometheus-config
namespace: monitoring
data:
prometheus.yml: |
scrape_configs:
- job_name: prometheus
static_configs:
- targets:
- localhost:9090
Does rolling out prometheus-config
(only) with new changes, make it visible to running Pod(prometheus-server
)?
Does configMap:
overwrite the contents of /etc/prometheus/prometheus.yml
(if any)?
Upvotes: 2
Views: 1641
Reputation: 23778
The ConfigMap needs to exist at the time of the creation of the POD unless the ConfigMap reference of the deployment is marked as "optional".
volumes:
- name: config-volume
configMap:
name: prometheus-config
optional: true
In the case where the optionally referenced ConfigMap comes to exist after the POD is created, the Kubernetes periodic sync will update the projected content in the volume. Kubernates documentation hints at the time it might take.
Kubelet checks whether the mounted ConfigMap is fresh on every periodic sync. However, it uses 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 (1 minute by default) + TTL of ConfigMaps cache (1 minute by default) in kubelet. You can trigger an immediate refresh by updating one of the pod's annotations.
There is no reference in the docs to the effect that updating the values of an existing ConfigMap is going to update the volume mount or ENV of the container.
Upvotes: 2