Essa é a versão completa de impressão dessa seção Clique aqui para imprimir.
Essa seção da documentação contém páginas que mostram como executar tarefas individuais.
Essas tarefas são organizadas em uma curta sequência de etapas e passos que te auxiliam a entender conceitos básicos.
Se você desejar adicionar uma tarefa, verifique como criar um Pull Request para a documentação.
Você precisa de um cluster Kubernetes e a ferramenta de linha de comando kubectl precisa estar configurada para acessar o seu cluster. Se você ainda não tem um cluster, pode criar um usando o minikube ou você pode usar um dos seguintes ambientes:
Um Secret pode conter credenciais de usuário requeridas por Pods para acesso a um banco de dados.
Por exemplo, uma string de conexão de banco de dados é composta por um usuário e senha.
Você pode armazenar o usuário em um arquivo ./username.txt e a senha em um
arquivo ./password.txt na sua máquina local.
echo -n 'admin' > ./username.txt
echo -n '1f2d1e2e67df' > ./password.txt
A opção -n nos comandos acima garante que os arquivos criados não vão conter
uma nova linha extra no final do arquivo de texto. Isso é importante porque
quando o kubectl lê um arquivo e codifica o conteúdo em uma string base64,
o caractere da nova linha extra também é codificado.
O comando kubectl create secret empacota os arquivos em um Secret e cria um
objeto no API server.
kubectl create secret generic db-user-pass \
--from-file=./username.txt \
--from-file=./password.txt
A saída deve ser similar a:
secret/db-user-pass created
O nome da chave padrão é o nome do arquivo. Opcionalmente, você pode definir
o nome da chave usando --from-file=[key=]source. Por exemplo:
kubectl create secret generic db-user-pass \
--from-file=username=./username.txt \
--from-file=password=./password.txt
Você não precisa escapar o caractere especial em senhas a partir de arquivos (--from-file).
Você também pode prover dados para Secret usando a tag --from-literal=<key>=<value>.
Essa tag pode ser especificada mais de uma vez para prover múltiplos pares de chave-valor.
Observe que caracteres especiais como $, \, *, =, e ! vão ser interpretados
pelo seu shell e precisam ser escapados.
Na maioria dos shells, a forma mais fácil de escapar as senhas é usar aspas simples (').
Por exemplo, se sua senha atual é S!B\*d$zDsb=, você precisa executar o comando dessa forma:
kubectl create secret generic dev-db-secret \
--from-literal=username=devuser \
--from-literal=password='S!B\*d$zDsb='
Você pode verificar se o secret foi criado:
kubectl get secrets
A saída deve ser similar a:
NAME TYPE DATA AGE
db-user-pass Opaque 2 51s
Você pode ver a descrição do Secret:
kubectl describe secrets/db-user-pass
A saída deve ser similar a:
Name: db-user-pass
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password: 12 bytes
username: 5 bytes
Os comandos kubectl get e kubectl describe omitem o conteúdo de um Secret por padrão.
Isso para proteger o Secret de ser exposto acidentalmente para uma pessoa não autorizada,
ou ser armazenado em um log de terminal.
Para ver o conteúdo de um Secret que você criou, execute o seguinte comando:
kubectl get secret db-user-pass -o jsonpath='{.data}'
A saída deve ser similar a:
{"password":"MWYyZDFlMmU2N2Rm","username":"YWRtaW4="}
Agora, você pode decodificar os dados de password:
echo 'MWYyZDFlMmU2N2Rm' | base64 --decode
A saída deve ser similar a:
1f2d1e2e67df
Para apagar o Secret que você criou:
kubectl delete secret db-user-pass
kubectlVocê precisa de um cluster Kubernetes e a ferramenta de linha de comando kubectl precisa estar configurada para acessar o seu cluster. Se você ainda não tem um cluster, pode criar um usando o minikube ou você pode usar um dos seguintes ambientes:
Você pode criar um Secret primeiramente em um arquivo, no formato JSON ou YAML, e depois
criar o objeto. O recurso Secret
contém dois mapas: data e stringData.
O campo data é usado para armazenar dados arbitrários, codificados usando base64. O
campo stringData é usado por conveniência, e permite que você use dados para um Secret
como strings não codificadas.
As chaves para data e stringData precisam ser compostas por caracteres alfanuméricos,
_, - ou ..
Por exemplo, para armazenar duas strings em um Secret usando o campo data, converta
as strings para base64 da seguinte forma:
echo -n 'admin' | base64
A saída deve ser similar a:
YWRtaW4=
echo -n '1f2d1e2e67df' | base64
A saída deve ser similar a:
MWYyZDFlMmU2N2Rm
Escreva o arquivo de configuração do Secret, que será parecido com:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
password: MWYyZDFlMmU2N2Rm
Perceba que o nome do objeto Secret precisa ser um nome de subdomínio DNS válido.
Nota: Os valores serializados dos dados JSON e YAML de um Secret são codificados em strings base64. Novas linhas não são válidas com essas strings e devem ser omitidas. Quando usar o utilitáriobase64em Darwin/MacOS, os usuários devem evitar usar a opção-bpara separar linhas grandes. Por outro lado, usuários de Linux devem adicionar a opção-w 0ao comandobase64ou o pipebase64 | tr -d '\n'se a opçãownão estiver disponível
Para cenários específicos, você pode querer usar o campo stringData ao invés de data.
Esse campo permite que você use strings não-base64 diretamente dentro do Secret,
e a string vai ser codificada para você quando o Secret for criado ou atualizado.
Um exemplo prático para isso pode ser quando você esteja fazendo deploy de uma aplicação que usa um Secret para armazenar um arquivo de configuração, e você quer popular partes desse arquivo de configuração durante o processo de implantação.
Por exemplo, se sua aplicação usa o seguinte arquivo de configuração:
apiUrl: "https://my.api.com/api/v1"
username: "<user>"
password: "<password>"
Você pode armazenar isso em um Secret usando a seguinte definição:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
stringData:
config.yaml: |
apiUrl: "https://my.api.com/api/v1"
username: <user>
password: <password>
Agora, crie o Secret usando kubectl apply:
kubectl apply -f ./secret.yaml
A saída deve ser similar a:
secret/mysecret created
O campo stringData é um campo de conveniência apenas de leitura. Ele nunca vai ser exibido
ao buscar um Secret. Por exemplo, se você executar o seguinte comando:
kubectl get secret mysecret -o yaml
A saída deve ser similar a:
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:40:59Z
name: mysecret
namespace: default
resourceVersion: "7225"
uid: c280ad2e-e916-11e8-98f2-025000000001
type: Opaque
data:
config.yaml: YXBpVXJsOiAiaHR0cHM6Ly9teS5hcGkuY29tL2FwaS92MSIKdXNlcm5hbWU6IHt7dXNlcm5hbWV9fQpwYXNzd29yZDoge3twYXNzd29yZH19
Os comandos kubectl get e kubectl describe omitem o conteúdo de um Secret por padrão.
Isso para proteger o Secret de ser exposto acidentalmente para uma pessoa não autorizada,
ou ser armazenado em um log de terminal.
Para verificar o conteúdo atual de um dado codificado, veja decodificando secret.
Se um campo, como username, é especificado em data e stringData,
o valor de stringData é o usado. Por exemplo, dada a seguinte definição do Secret:
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
username: YWRtaW4=
stringData:
username: administrator
Resulta no seguinte Secret:
apiVersion: v1
kind: Secret
metadata:
creationTimestamp: 2018-11-15T20:46:46Z
name: mysecret
namespace: default
resourceVersion: "7579"
uid: 91460ecb-e917-11e8-98f2-025000000001
type: Opaque
data:
username: YWRtaW5pc3RyYXRvcg==
Onde YWRtaW5pc3RyYXRvcg== é decodificado em administrator.
Para apagar o Secret que você criou:
kubectl delete secret mysecret
kubectlDesde o Kubernetes v1.14, o kubectl provê suporte para gerenciamento de objetos usando Kustomize.
O Kustomize provê geradores de recursos para criar Secrets e ConfigMaps.
Os geradores Kustomize devem ser especificados em um arquivo kustomization.yaml dentro
de um diretório. Depois de gerar o Secret, você pode criar o Secret com kubectl apply.
Você precisa de um cluster Kubernetes e a ferramenta de linha de comando kubectl precisa estar configurada para acessar o seu cluster. Se você ainda não tem um cluster, pode criar um usando o minikube ou você pode usar um dos seguintes ambientes:
Você pode criar um Secret definindo um secretGenerator em um
arquivo kustomization.yaml que referencia outros arquivos existentes.
Por exemplo, o seguinte arquivo kustomization referencia os
arquivos ./username.txt e ./password.txt:
secretGenerator:
- name: db-user-pass
files:
- username.txt
- password.txt
Você também pode definir o secretGenerator no arquivo kustomization.yaml
por meio de alguns literais.
Por exemplo, o seguinte arquivo kustomization.yaml contém dois literais
para username e password respectivamente:
secretGenerator:
- name: db-user-pass
literals:
- username=admin
- password=1f2d1e2e67df
Observe que nos dois casos, você não precisa codificar os valores em base64.
Aplique o diretório que contém o arquivo kustomization.yaml para criar o Secret.
kubectl apply -k .
A saída deve ser similar a:
secret/db-user-pass-96mffmfh4k created
Observe que quando um Secret é gerado, o nome do segredo é criado usando o hash dos dados do Secret mais o valor do hash. Isso garante que um novo Secret é gerado cada vez que os dados são modificados.
Você pode verificar que o secret foi criado:
kubectl get secrets
A saída deve ser similar a:
NAME TYPE DATA AGE
db-user-pass-96mffmfh4k Opaque 2 51s
Você pode ver a descrição de um secret:
kubectl describe secrets/db-user-pass-96mffmfh4k
A saída deve ser similar a:
Name: db-user-pass-96mffmfh4k
Namespace: default
Labels: <none>
Annotations: <none>
Type: Opaque
Data
====
password.txt: 12 bytes
username.txt: 5 bytes
Os comandos kubectl get e kubectl describe omitem o conteúdo de um Secret por padrão.
Isso para proteger o Secret de ser exposto acidentalmente para uma pessoa não autorizada,
ou ser armazenado em um log de terminal.
Para verificar o conteúdo atual de um dado codificado, veja decodificando secret.
Para apagar o Secret que você criou:
kubectl delete secret db-user-pass-96mffmfh4k
kubectl