configuration - example - Kubernetes equivalente de env-file en Docker

kubernetes configmap

Question

Antecedentes:

Actualmente estamos usando Docker y Docker Compose para nuestros servicios. Hemos externalizado la configuración para diferentes entornos en archivos que definen variables de entorno leídas por la aplicación. Por ejemplo, un archivo prod.env :

ENV_VAR_ONE=Something Prod
ENV_VAR_TWO=Something else Prod

y un archivo test.env :

ENV_VAR_ONE=Something Test
ENV_VAR_TWO=Something else Test

Por lo tanto, simplemente podemos usar el archivo prod.env o test.env al iniciar el contenedor:

docker run --env-file prod.env <image>

Luego, nuestra aplicación retoma su configuración en función de las variables de entorno definidas en prod.env .

Preguntas:

1. ¿Hay alguna manera de proporcionar variables de entorno desde un archivo en Kubernetes (por ejemplo, al definir un pod) en lugar de codificarlas de esta manera:

apiVersion: v1 kind: Pod metadata: labels: context: docker-k8s-lab name: mysql-pod name: mysql-pod spec: containers: - env: - name: MYSQL_USER value: mysql - name: MYSQL_PASSWORD value: mysql - name: MYSQL_DATABASE value: sample - name: MYSQL_ROOT_PASSWORD value: supersecret image: "mysql:latest" name: mysql ports: - containerPort: 3306

2. Si esto no es posible, ¿cuál es el enfoque sugerido?

Answer 1

Al definir un pod para Kubernetes usando un archivo YAML, no hay forma directa de especificar un archivo diferente que contenga variables de entorno para un contenedor. El proyecto Kubernetes dice que mejorarán esta área en el futuro (ver los documentos de Kubernetes ).

Mientras tanto, sugiero usar una herramienta de aprovisionamiento y hacer que el pod YAML sea una plantilla. Por ejemplo, usando Ansible su archivo YAML pod podría verse así:

archivo my-pod.yaml.template :

apiVersion: v1
kind: Pod
...
spec:
containers:
...
env:
- name: MYSQL_ROOT_PASSWORD
value: {{ mysql_root_pasword }}
...

Luego, su libro de jugadas de Ansible puede especificar la variable mysql_root_password algún lugar conveniente y sustituirla al crear el recurso, por ejemplo:

archivo my-playbook.yaml :

- hosts: my_hosts
vars_files:
- my-env-vars-{{ deploy_to }}.yaml
tasks:
- name: create pod YAML from template
template: src=my-pod.yaml.template dst=my-pod.yaml
- name: create pod in Kubernetes
command: kubectl create -f my-pod.yaml

archivo my-env-vars-prod.yaml :

mysql_root_password: supersecret

archivo my-env-vars-test.yaml :

mysql_root_password: notsosecret

Ahora crea el recurso pod ejecutando, por ejemplo:

ansible-playbook -e deploy=test my-playbook.yaml

Answer 2

Esta es una pregunta antigua pero tiene muchos espectadores, así que agrego mi respuesta. La mejor manera de separar la configuración de la implementación de K8 es usar Helm. Cada paquete Helm puede tener un archivo values.yaml y podemos usar fácilmente esos valores en el gráfico Helm. Si tenemos una topología de múltiples componentes, podemos crear un paquete Helm paraguas y el paquete de valores primarios también puede sobrescribir los archivos de valores secundarios.

Answer 3

Esto funciona para mi:

archivo env-secret.yaml

apiVersion: v1
kind: Secret
metadata:
name: env-secret
type: Opaque
stringData:
.env: |-
APP_NAME=Laravel
APP_ENV=local

y en el deployment.yaml o pod.yaml

spec:
...
volumeMounts:
- name: foo
mountPath: "/var/www/html/.env"
subPath: .env
volumes:
- name: foo
secret:
secretName: env-secret
````

Answer 4

Puede llenar las variables de entorno de un contenedor mediante el uso de Secrets o ConfigMaps . Use Secretos cuando los datos con los que está trabajando sean confidenciales (por ejemplo, contraseñas) y ConfigMaps cuando no lo sea.

En su definición de Pod, especifique que el contenedor debe extraer valores de un Secreto:

apiVersion: v1
kind: Pod
metadata:
labels:
context: docker-k8s-lab
name: mysql-pod
name: mysql-pod
spec:
containers:
- image: "mysql:latest"
name: mysql
ports:
- containerPort: 3306
envFrom:
- secretRef:
name: mysql-secret

Tenga en cuenta que esta sintaxis solo está disponible en Kubernetes 1.6 o posterior. En una versión anterior de Kubernetes, deberá especificar cada valor manualmente, por ejemplo:

env:
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: mysql-secret
key: MYSQL_USER

(Tenga en cuenta que env toma una matriz como valor)

Y repitiendo para cada valor.

Cualquiera que sea el enfoque que utilice, ahora puede definir dos Secretos diferentes, uno para producción y otro para desarrollador.

dev-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
type: Opaque
data:
MYSQL_USER: bXlzcWwK
MYSQL_PASSWORD: bXlzcWwK
MYSQL_DATABASE: c2FtcGxlCg==
MYSQL_ROOT_PASSWORD: c3VwZXJzZWNyZXQK

prod-secret.yaml:

apiVersion: v1
kind: Secret
metadata:
name: mysql-secret
type: Opaque
data:
MYSQL_USER: am9obgo=
MYSQL_PASSWORD: c2VjdXJlCg==
MYSQL_DATABASE: cHJvZC1kYgo=
MYSQL_ROOT_PASSWORD: cm9vdHkK

E implemente el secreto correcto en el clúster Kubernetes correcto:

kubectl config use-context dev
kubectl create -f dev-secret.yaml
kubectl config use-context prod
kubectl create -f prod-secret.yaml

Ahora, cada vez que se inicia un Pod, rellenará sus variables de entorno a partir de los valores especificados en el Secreto.

Answer 5

Una nueva actualización para Kubernetes (v1.6) permite lo que solicitó (hace años).

Ahora puede usar envFrom como este en su archivo yaml:

 containers:
- name: django
image: image/name
envFrom:
- secretRef:
name: prod-secrets

Donde desarrollo-secretos es tu secreto, puedes crearlo de la siguiente manera:

kubectl create secret generic prod-secrets --from-file=prod/env.txt`

Donde el contenido del archivo txt es un valor-clave:

DB_USER=username_here
DB_PASSWORD=password_here

Los documentos siguen siendo lagos de ejemplos, tuve que buscar mucho en esos lugares:

• envFrom secretos , buscar envFrom : muestra que esta opción está disponible.
• Los documentos equivalentes de ConfigMap muestran un ejemplo sobre cómo usarlo.