Um ConfigMap é um recurso do Kubernetes para injetar configuração em seus contêineres. Eles permitem que você mantenha as configurações de sua pilha separadamente de seu código. Veja como trabalhar com ConfigMaps e fornecê-los aos seus pods.

Publicidade

Para que servem os ConfigMaps?

ConfigMaps são projetado especificamente para encapsular pequenas quantidades de dados de configuração não confidenciais. Eles são um mecanismo para obter pares de valores-chave arbitrários em seus pods. Eles são comumente usados ​​para armazenar o endereço IP do servidor de banco de dados, o endereço de e-mail de saída do seu aplicativo e outras configurações específicas do aplicativo que precisam ser configuradas fora dos pods.

O ConfigMap permite gerenciar esses dados em um recurso Kubernetes dedicado. Os pods recebem os pares de valores-chave como variáveis ​​de ambiente ou arquivos em um volume montado.

Para que não usá-los?

Existem algumas situações em que um ConfigMap deve não ser usado.

Publicidade

Os ConfigMaps não são armazenados com segurança e seus valores não têm criptografia. Eles não devem conter quaisquer dados sensíveis ou confidenciais que possam constituir um risco de segurança ou privacidade se vazados.

Não coloque senhas, chaves de API ou chaves de criptografia em um ConfigMap – use um segredo do Kubernetes, pois eles funcionam de maneira semelhante aos ConfigMaps, mas com proteções adicionais. Os sistemas que precisam de uma conexão com o banco de dados devem colocar o nome do host em um ConfigMap e as credenciais em um segredo separado.

ConfigMaps individuais não podem exceder 1 MB de tamanho. Os sistemas que precisam de mais chaves de configuração podem ser melhor atendidos por uma abordagem alternativa, como a injeção de arquivos de configuração gerados manualmente por meio de um volume.

Se você deseja manter os ConfigMaps, considere dividir sua configuração em vários recursos do ConfigMap. Essa abordagem deve evitar o limite de 1 MB, permitindo que você forneça a cada um dos seus pods o conjunto mínimo de chaves de configuração de que precisa.

Publicidade

Os valores do ConfigMap podem ser strings UTF-8 ou dados binários codificados como string base64. Os nomes das chaves podem conter alfanuméricos, . (período), - (hífen), e _ (sublinhado) caracteres. Algumas linguagens de programação e estruturas podem ter uma convenção diferente para variáveis ​​de configuração, portanto, certifique-se de usar um formato compatível com o Kubernetes e seu aplicativo.

Publicidade

Criação de um ConfigMap

Os ConfigMaps têm manifestos YAML simples. Cada ConfigMap precisa de um name no formato Kubernetes padrão e um data campo contendo seus pares de valores-chave:

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-configmap
data:
  database_host: "192.168.0.10"
  system_email: "[email protected]"

o data campo é para especificar chaves com valores de string. Você pode usar binaryData em vez ou tão bem como data para adicionar valores binários codificados em base64. As chaves devem ser exclusivas em ambos data e binaryData.

Aplique o manifesto ao seu cluster usando kubectl ou sua ferramenta preferida.

Vinculando ConfigMaps e Pods

Um ConfigMap não faz nada por conta própria. Você adicionou alguns dados ao seu cluster; agora vamos vinculá-lo a um pod:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      envFrom:
        - configMapRef:
            name: example-configmap

o envFrom campo puxa em variáveis ​​de ambiente definidas por outro recurso referenciado. Neste caso, um configMapRef identifica o ConfigMap criado anteriormente. Os contêineres do pod serão iniciados com database_host e system_email variáveis ​​de ambiente definidas.

Publicidade

Adicionando Seletivamente Variáveis ​​de Ambiente

envFrom é útil quando você deseja consumir todas as chaves no ConfigMap e tem certeza de que não haverá conflitos com as outras variáveis ​​de ambiente do seu pod. Em situações mais controladas, use um env seção, defina as chaves individuais e extraia o valor de cada chave do ConfigMap:

env:
  - name: DATABASE_HOST_IP
    valueFrom:
      configMapKeyRef:
        name: example-configmap
        key: database_host

Este exemplo mostra como um pod pode ser iniciado apenas com o database_host chave do ConfigMap. A chave também é renomeada antes da injeção para que o pod a receba como DATABASE_HOST_IP.

Usando ConfigMaps com volumes

Os ConfigMaps podem ser montados como arquivos dentro de pods. O Kubernetes cria um volume, injeta o conteúdo do ConfigMap como um conjunto de arquivos e monta o volume no seu pod.

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image:latest
      volumeMounts:
        - name: app-config
          mountPath: "/etc/config-data"
          readOnly: true
  volumes:
    - name: app-config
      configMap:
        name: example-configmap

Este manifesto de pod cria um volume chamado app-config. o configMap campo preencherá previamente o volume usando os dados no ConfigMap especificado.

O Pod monta o volume para /etc/config-data. Seus contêineres podem ler os arquivos dentro do diretório para acessar seus valores de configuração. Cada chave do ConfigMap terá seu próprio arquivo no ponto de montagem.

Publicidade

Atualizando valores do ConfigMap

Como um ConfigMap é um recurso padrão da API Kubernetes, você pode atualizar os valores a qualquer momento, modificando seu manifesto e reaplicando-o ao cluster. Como os novos valores alcançam seus pods depende do mecanismo de injeção que você está usando.

Volumes montados

Os ConfigMaps montados em pods por meio de um volume serão atualizados pelo Kubernetes. As alterações nos ConfigMaps são verificadas periodicamente; quando uma diferença for detectada, os arquivos em seu volume serão atualizados, então seu pod receberá os novos dados. O atraso depende de o intervalo de sincronização configurado para as instâncias Kubelet em seus nós de trabalho.

variáveis ​​ambientais

Alterar as variáveis ​​de ambiente de um pod não é possível, portanto, as alterações do ConfigMap não alcançarão os pods existentes que fazem referência a chaves por meio desse mecanismo. Você deve substituir seus pods para usar os novos dados.

Os pods recém-criados sempre receberão os dados atuais do ConfigMap, independentemente de você usar volumes ou variáveis ​​de ambiente. Se você precisar forçar uma atualização de configuração, altere uma anotação no seu pod para que o Kubernetes a recrie.

Immutable ConfigMaps

Os ConfigMaps têm um opcional immutable campo que os impede de serem atualizados. Quando este campo é definido, você não pode atualizar os dados do ConfigMap ou remover o status imutável.

Publicidade
apiVersion: v1
kind: ConfigMap
metadata:
  name: immutable-configmap
data:
  foo: bar
immutable: true

Isso pode ser útil quando você tem certeza de que os valores de configuração nunca serão alterados. Além disso, melhora a segurança, removendo a possibilidade de edições acidentais. O desempenho também pode ser melhorado, pois o Kubernetes não precisa mais monitorar o ConfigMap para propagar quaisquer alterações de valor em seus pods.

Resumo

Os ConfigMaps devem ser a sua escolha para fornecer chaves de configuração não confidenciais aos pods do Kubernetes. Eles são um recurso de API de primeira classe que você pode consumir como variáveis ​​de ambiente ou arquivos montados em volumes.

As senhas e outras credenciais pertencem aos Segredos. Eles funcionam de forma muito semelhante aos ConfigMaps e são referenciados pelos pods da mesma maneira. Substituto configMapRef com secretRef para puxar uma chave de um segredo nomeado em vez de um ConfigMap.