The Kubernetes Downward API allows an administrator to pass on some information that a developer would otherwise have to use something like Fabric8 to get. Using Fabric8 usually requires defining a Service Account with a node get cluster role, which creates an attack vector.
For example, using the Downward API I can pass the name of the node an application is running on. This could then be used to add rack (well, node) awareness for consumer partition assignment.
Cribl uses the following syntax, which IMHO works well.
# Downward API values
envValueFrom:
- name: CRIBL_K8S_POD
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: CRIBL_K8S_CPU_LIMIT
valueFrom:
resourceFieldRef:
resource: limits.cpu
divisor: 1mIt then simply injects that block into the env block of the rendered deployment as follows.
env:
{{ if .Values.envValueFrom }}
{{ toYaml .Values.envValueFrom | nindent 6 }}
{{- end }}
{{- range $key, $value := .Values.env }}
- name: {{ tpl $key $ }}
value: "{{ tpl (print $value) $ }}"
{{- end }}
The Kubernetes Downward API allows an administrator to pass on some information that a developer would otherwise have to use something like Fabric8 to get. Using Fabric8 usually requires defining a Service Account with a node get cluster role, which creates an attack vector.
For example, using the Downward API I can pass the name of the node an application is running on. This could then be used to add rack (well, node) awareness for consumer partition assignment.
Cribl uses the following syntax, which IMHO works well.
It then simply injects that block into the
envblock of the rendered deployment as follows.