Tabla de contenido

1. Mapas de configuración

Una de las mejores prácticas en la implementación de aplicaciones es separar la información de configuración requerida por la aplicación del programa, para que la aplicación se pueda reutilizar mejor y se puedan realizar funciones más flexibles a través de diferentes configuraciones.
Una vez que la aplicación se empaqueta como una imagen de contenedor, la inyección de configuración se puede realizar al crear un contenedor a través de variables de entorno o archivos de complemento. Sin embargo, en un entorno de clúster de contenedores a gran escala, será muy complicado configurar varios contenedores de manera diferente.
A partir de Kubernetes v1.2, se proporciona una solución de administración de configuración de aplicaciones unificada: ConfigMap.

Después de crear el ConfigMap, los datos se almacenarán en Etcd en K8s, y luego se hará referencia a los datos cuando se cree el Pod.

Escenario de aplicación: configuración de la aplicación

Pod usa los datos del mapa de configuración de dos maneras:

• Inyección de variables , obtenga ConfigMap a través de variables de entorno

• Montaje de volumen de datos , monte el contenido en ConfigMap como un archivo o directorio dentro del contenedor por medio de Montaje de volumen

Crear configMap.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  abc: "123"
  cde: "456"

  redis.properties: |
    port: 6379
    host: 192.168.2.117

Ver el mapa de configuración creado

Crear configMap-deploy.yaml

apiVersion: v1
kind: Pod
metadata:
  name: app-config-demo
spec:
  containers:
    - name: demo 
      image: nginx 
      env:
        - name: ABCD 
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: abc
        - name: CDEF
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: cde
      volumeMounts:
      - name: config             
        mountPath: "/config"  # 配置文件挂载在容器中的位置
        readOnly: true
  volumes:            # 数据卷挂载
    - name: config 
      configMap:
        name: app-config
        items:
        - key: "redis.properties"
          path: "redis.properties"

Verifique que la inyección de la variable sea exitosa y que el archivo de configuración redis.properties también esté montado en la ruta /config.

Notas sobre ConfigMaps

Ahora haga un resumen del uso de ConfigMap, así como algunos de sus puntos de atención.Los siguientes cinco puntos se enumeran en total:

El primer punto es el tamaño del archivo ConfigMap . Aunque no hay límite de tamaño para el archivo ConfigMap, hay un límite de tamaño para escribir datos en ETCD, y ahora está limitado a 1 MB;
El segundo punto a tener en cuenta es que cuando un pod importa un ConfigMap, debe ser un ConfigMap en el mismo espacio de nombres Como puede ver anteriormente, hay un campo de espacio de nombres en ConfigMap.metadata;
El tercer punto es el ConfigMap al que hace referencia el pod. Si el ConfigMap no existe, el pod no se puede crear correctamente. De hecho, esto también significa que el ConfigMap al que se hace referencia debe crearse antes de crear el pod;
El cuarto punto es la forma de usar envFrom. Al importar toda la información del ConfigMap a las variables de entorno, si algunas claves del ConfigMap no son válidas, por ejemplo, los nombres de las claves contienen números, esta variable de entorno no se inyectará en el contenedor y se ignorará. Pero se puede crear el propio pod. Esto es diferente al tercer punto, se basa en la existencia del archivo ConfigMap y se importa como una variable de entorno como un todo;
El último punto es: ¿qué tipo de pod puede usar ConfigMap? Aquí, solo los pods creados a través de la API de K8 pueden usar ConfigMap. Por ejemplo, los pods creados con la línea de comando kubectl definitivamente pueden usar ConfigMap, pero los pods creados con otros métodos, como los pods estáticos creados por kubelet a través del manifiesto, no pueden usar ConfigMap.

dos, secreto

Los secretos de k8 se utilizan para almacenar y administrar algunos datos confidenciales, como contraseñas, tokens, claves y otra información confidencial. Almacena los datos cifrados a los que Pod quiere acceder en Etcd . Luego, los usuarios pueden acceder a la información almacenada en estos Secretos montando Volúmenes o variables de entorno en contenedores Pod . Al igual que ConfigMap, la diferencia es que Secret almacena principalmente datos confidenciales y todos los datos deben estar codificados en base64.

Escenario de aplicación: Credenciales

kubectl create secret admite tres tipos de datos:

• docker-registry (kubernetes.io/dockerconfigjson): almacenar información de autenticación del almacén de imágenes

• genérico (Opaco): almacenar contraseñas, claves, etc.

• tls (kubernetes.io/tls): almacena certificados TLS

Podemos ejecutar el siguiente comando en el salto de línea de comandos de Linux para cifrar:

echo -n 'admin' | base64
echo -n '1f2d1e2e67df' | base64

Crear secreto.yaml

apiVersion: v1
kind: Secret
metadata:
  name: db-user-pass
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

Crear secret-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: secret-demo-pod
spec:
  containers:
  - name: demo 
    image: nginx 
    env:
      - name: USER 
        valueFrom:
          secretKeyRef:
            name: db-user-pass
            key: username
      - name: PASS
        valueFrom:
          secretKeyRef:
            name: db-user-pass
            key: password
    volumeMounts:
    - name: config
      mountPath: "/config"
      readOnly: true
  volumes:
    - name: config 
      secret:
        secretName: db-user-pass
        items:
        - key: username
          path: my-username

Leer con éxito el nombre de usuario y la contraseña

Algunos puntos de atención en el uso de Secret, se enumeran los siguientes tres puntos:

El primer punto es el límite de tamaño de archivo de Secret. Esto es lo mismo que ConfigMap, que también tiene 1 MB;
El segundo punto es que Secret usa la codificación base-64, pero no es muy diferente del texto sin formato. Por lo tanto, si hay alguna información confidencial para ser almacenada en secreto, debe ser considerada cuidadosamente. Es decir, se debe considerar cuidadosamente quién visitará su clúster y quién usará su Secreto, porque si pueden acceder al clúster, pueden obtener el Secreto;
El tercer punto es la mejor práctica para leer secretos. Se recomienda no usar list/watch. Si usa list/watch para operar, todos los secretos bajo el espacio de nombres serán retirados, lo que en realidad expone más información. Se recomienda utilizar el método GET, para que solo obtenga el secreto que necesita.

Enlace de referencia al texto original: gestión de configuración de aplicaciones de la serie K8S (siete)_blog de Lin Musen^~^-CSDN blog_k8s archivo de configuración de aplicaciones

Configuración de ConfigMap y Secret of kubernetes management application

1. Mapas de configuración

dos, secreto

Supongo que te gusta