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 ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou 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 db-user-pass \
--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 ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou 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.
base64 em Darwin/MacOS, os usuários devem evitar usar a opção -b
para separar linhas grandes. Por outro lado, usuários de Linux devem adicionar a opção
-w 0 ao comando base64 ou o pipe base64 | tr -d '\n' se a opção w nã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 ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou 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
kubectlEsta página mostra como configurar os Pods para que, a eles sejam atribuídos particularmente classes de Qualidade de Serviço (QoS). O Kubernetes usa classes QoS para tomar decisões sobre agendamento e despejo de Pods.
Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:
Para verificar a versão, digitekubectl version.
Quando o Kubernetes cria um Pod, ele atribui uma dessas classes de QoS ao Pod:
Crie um namespace, assim os seus recursos criados neste exercício estarão isolados do resto do seu cluster.
kubectl create namespace qos-example
GuaranteedPara que um Pod receba uma classe de QoS Guaranteed:
Essas restrições se aplicam igualmente a contêineres de inicialização bem como de aplicativos.
Aqui está o arquivo de configuração para um pod que possui um contêiner. O contêiner tem um limite de memória e um requisito de memória, ambos iguais a 200 MiB. O contêiner tem um limite de CPU e uma solicitação de CPU, ambos iguais a 700 miliCPU:
apiVersion: v1
kind: Pod
metadata:
name: qos-demo
namespace: qos-example
spec:
containers:
- name: qos-demo-ctr
image: nginx
resources:
limits:
memory: "200Mi"
cpu: "700m"
requests:
memory: "200Mi"
cpu: "700m"
Crie o Pod:
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod.yaml --namespace=qos-example
Veja informações detalhadas sobre o pod:
kubectl get pod qos-demo --namespace=qos-example --output=yaml
A saída mostra que o Kubernetes forneceu ao pod uma classe de QoS Guaranteed. A saída também
verifica se o contêiner do Pod tem um requisito de memória que corresponde ao seu limite de memória, e possui
um requisito de CPU que corresponde ao seu limite de CPU.
spec:
containers:
...
resources:
limits:
cpu: 700m
memory: 200Mi
requests:
cpu: 700m
memory: 200Mi
...
status:
qosClass: Guaranteed
Apague seu Pod:
kubectl delete pod qos-demo --namespace=qos-example
BurstableUm Pod recebe uma classe de QoS Burstable se:
Guaranteed.Aqui está o arquivo de configuração para um Pod que possui um contêiner. O contêiner tem um limite de memória de 200 MiB e um requisito de memória de 100 MiB.
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-2
namespace: qos-example
spec:
containers:
- name: qos-demo-2-ctr
image: nginx
resources:
limits:
memory: "200Mi"
requests:
memory: "100Mi"
Crie o Pod:
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-2.yaml --namespace=qos-example
Veja informações detalhadas sobre o Pod:
kubectl get pod qos-demo-2 --namespace=qos-example --output=yaml
A saída mostra que o Kubernetes forneceu ao pod uma classe de QoS Burstable.
spec:
containers:
- image: nginx
imagePullPolicy: Always
name: qos-demo-2-ctr
resources:
limits:
memory: 200Mi
requests:
memory: 100Mi
...
status:
qosClass: Burstable
Apague seu Pod:
kubectl delete pod qos-demo-2 --namespace=qos-example
BestEffortPara que um Pod receba uma classe de QoS BestEffort, os contêineres no pod não devem
ter quaisquer requisitos ou limites de CPU ou memória.
Aqui está o arquivo de configuração para um Pod que possui um contêiner. O contêiner não tem requisitos ou limites de memória ou CPU:
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-3
namespace: qos-example
spec:
containers:
- name: qos-demo-3-ctr
image: nginx
Crie o Pod:
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-3.yaml --namespace=qos-example
Veja informações detalhadas sobre o Pod:
kubectl get pod qos-demo-3 --namespace=qos-example --output=yaml
A saída mostra que o Kubernetes forneceu ao Pod uma classe de QoS BestEffort.
spec:
containers:
...
resources: {}
...
status:
qosClass: BestEffort
Apague seu Pod:
kubectl delete pod qos-demo-3 --namespace=qos-example
Aqui está o arquivo de configuração para um Pod que possui dois contêineres. Um contêiner especifica um requisito de memória de 200 MiB. O outro contêiner não especifica nenhum requisito ou limite.
apiVersion: v1
kind: Pod
metadata:
name: qos-demo-4
namespace: qos-example
spec:
containers:
- name: qos-demo-4-ctr-1
image: nginx
resources:
requests:
memory: "200Mi"
- name: qos-demo-4-ctr-2
image: redis
Observe que este Pod atende aos critérios para a classe de QoS Burstable. Isto é, ele não atende aos
critérios para a classe de QoS Guaranteed, e um de seus contêineres tem um requisito de memória.
Crie o Pod:
kubectl apply -f https://k8s.io/examples/pods/qos/qos-pod-4.yaml --namespace=qos-example
Veja informações detalhadas sobre o Pod:
kubectl get pod qos-demo-4 --namespace=qos-example --output=yaml
A saída mostra que o Kubernetes forneceu ao pod uma classe de QoS Burstable:
spec:
containers:
...
name: qos-demo-4-ctr-1
resources:
requests:
memory: 200Mi
...
name: qos-demo-4-ctr-2
resources: {}
...
status:
qosClass: Burstable
Apague seu Pod:
kubectl delete pod qos-demo-4 --namespace=qos-example
Apague seu namespace:
kubectl delete namespace qos-example
Configurar Requisitos e Limites de Memória Padrão Para um Namespace
Configurar Requisitos e Limites Padrão de CPU Para um Namespace
Configurar Restrições de Memória Mínima e Máxima Para um Namespace
Configurar Restrições Mínimas e Máximas de CPU Para um Namespace
Topologia de Controle de Gerenciamento de Politicas em um Nó
O Kubernetes oferece um complemento de DNS para os clusters, que a maioria dos ambientes suportados habilitam por padrão. Na versão do Kubernetes 1.11 e posterior, o CoreDNS é recomendado e instalado por padrão com o kubeadm.
Para mais informações sobre como configurar o CoreDNS para um cluster Kubernetes, veja Personalização do Serviço de DNS. Para ver um exemplo que demonstra como usar o DNS do Kubernetes com o kube-dns, consulte Plugin de exemplo para DNS.
Esta página mostra como atribuir um Pod Kubernetes a um nó particular em um cluster Kubernetes.
Você precisa ter um cluster do Kubernetes e a ferramenta de linha de comando kubectl deve estar configurada para se comunicar com seu cluster. É recomendado executar esse tutorial em um cluster com pelo menos dois nós que não estejam atuando como hosts de camada de gerenciamento. Se você ainda não possui um cluster, pode criar um usando o minikube ou pode usar um dos seguintes ambientes:
Para verificar a versão, digitekubectl version.
Liste os nós em seu cluster, juntamente com seus rótulos:
kubectl get nodes --show-labels
A saída é similar a esta:
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
Escolha um de seus nós, e adicione um rótulo a ele:
kubectl label nodes <your-node-name> disktype=ssd
onde <your-node-name> é o nome do seu nó escolhido.
Verifique se seu nó escolhido tem o rótulo disktype=ssd:
kubectl get nodes --show-labels
A saída é similiar a esta:
NAME STATUS ROLES AGE VERSION LABELS
worker0 Ready <none> 1d v1.13.0 ...,disktype=ssd,kubernetes.io/hostname=worker0
worker1 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker1
worker2 Ready <none> 1d v1.13.0 ...,kubernetes.io/hostname=worker2
Na saída anterior, você pode ver que o nó worker0 tem o rótulo disktype=ssd.
Este arquivo de configuração de pod descreve um pod que tem um seletor de nó,
disktype: ssd. Isto significa que o pod será agendado em um nó que tem o rótulo disktype=ssd.
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
env: test
spec:
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
nodeSelector:
disktype: ssd
Use o arquivo de configuração para criar um pod que será agendado no nó escolhido:
kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml
Verifique se o pod está executando no nó escolhido:
kubectl get pods --output=wide
A saída é similar a esta:
NAME READY STATUS RESTARTS AGE IP NODE
nginx 1/1 Running 0 13s 10.200.0.4 worker0
Você pode também agendar um pod para um nó específico usando nodeName.
apiVersion: v1
kind: Pod
metadata:
name: nginx
spec:
nodeName: foo-node # schedule pod to specific node
containers:
- name: nginx
image: nginx
imagePullPolicy: IfNotPresent
Use o arquivo de configuração para criar um pod que será agendado somente no nó foo-node.