Essa é a versão completa de impressão dessa seção Clique aqui para imprimir.

Retornar à visualização normal.

Tarefas

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.

1 - Instale as ferramentas

Configure as ferramentas do Kubernetes no seu computador.

kubectl

A ferramenta de linha de comando do Kubernetes, kubectl, permite que você execute comandos nos clusters Kubernetes. Você pode usar o kubectl para instalar aplicações, inspecionar e gerenciar recursos de cluster e visualizar os logs. Para obter mais informações, incluindo uma lista completa de operações kubectl, consulte a documentação de referência kubectl.

Kubectl é instalável em uma variedade de plataformas tais como Linux, macOS e Windows. Encontre seu sistema operacional preferido abaixo.

kind

O kind permite que você execute o Kubernetes no seu computador local. Esta ferramenta requer que você tenha o Docker instalado e configurado.

A página de Início Rápido mostra o que você precisa fazer para começar a trabalhar com o kind.

Acesse o guia de início rápido do kind

minikube

Assim como o kind, o minikube é uma ferramenta que permite executar o Kubernetes localmente. O minikube executa um cluster Kubernetes local com tudo-em-um ou com vários nós no seu computador pessoal (incluindo PCs Windows, macOS e Linux) para que você possa experimentar o Kubernetes ou para o trabalho de desenvolvimento diário.

Você pode seguir o guia de início oficial se o seu foco é instalar a ferramenta.

Acesse o guia de início

Depois de instalar o minikube, você pode usá-lo para executar uma aplicação exemplo.

kubeadm

Você pode usar a ferramenta kubeadm para criar e gerenciar clusters Kubernetes. Ela executa as ações necessárias para obter um cluster mínimo viável e seguro em funcionamento de maneira amigável ao usuário.

Instalando a ferramenta kubeadm mostra como instalar o kubeadm. Uma vez instalado, você pode usá-lo para criar um cluster.

Acesse o guia instalando a ferramenta kubeadm

1.1 - Instale e configure o kubectl no Linux

Antes de você começar

Você deve usar uma versão do kubectl que esteja próxima da versão do seu cluster. Por exemplo, um cliente v1.26 pode se comunicar com as versões v1.25, v1.26 e v1.27 da camada de gerenciamento. Usar a versão compatível mais recente do kubectl ajuda a evitar problemas inesperados.

Instale o kubectl no Linux

Existem os seguintes métodos para instalar o kubectl no Linux:

Instale o binário kubectl no Linux usando o curl

  1. Faça download da versão mais recente com o comando:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
    
  2. Valide o binário (opcional)

    Faça download do arquivo checksum de verificação do kubectl:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"
    

    Valide o binário kubectl em relação ao arquivo de verificação:

    echo "$(cat kubectl.sha256)  kubectl" | sha256sum --check
    

    Se válido, a saída será:

    kubectl: OK
    

    Se a verificação falhar, o sha256 exibirá o status diferente de zero e a saída será semelhante a:

    kubectl: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Instale o kubectl

    sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
    
  4. Teste para garantir que a versão que você instalou esteja atualizada:

    kubectl version --client
    

    Ou use isso para visualizar mais detalhes da versão:

    kubectl version --client --output=yaml    
    

Instale usando o gerenciador de pacotes nativo

  1. Atualize o índice do apt e instale os pacotes necessários para utilizar o repositório apt do Kubernetes:

    sudo apt-get update
    sudo apt-get install -y ca-certificates curl
    

    Se você usa o Debian 9 (stretch) ou anterior, também precisará instalar o apt-transport-https:

    sudo apt-get install -y apt-transport-https
    
  2. Faça download da chave de assinatura pública do Google Cloud:

    curl -fsSL https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-archive-keyring.gpg
    
  3. Adicione o repositório apt do Kubernetes:

    echo "deb [signed-by=/etc/apt/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list
    
  4. Atualize o índice do apt com o novo repositório e instale o kubectl:

    sudo apt-get update
    sudo apt-get install -y kubectl
    

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
sudo yum install -y kubectl

Instale usando outro gerenciador de pacotes

Se você estiver no Ubuntu ou em outra distribuição Linux que suporte o gerenciador de pacotes snap, o kubectl está disponível como um aplicativo snap.

snap install kubectl --classic
kubectl version --client

Se você estiver no Linux e usando o gerenciador de pacotes Homebrew, o kubectl está disponível para instalação.

brew install kubectl
kubectl version --client

Verifique a configuração kubectl

Para que o kubectl encontre e acesse um cluster Kubernetes, ele precisa de um arquivo kubeconfig, que é criado automaticamente quando você cria um cluster usando kube-up.sh ou instala com sucesso um cluster Minikube. Por padrão, a configuração kubectl está localizada em ~/.kube/config.

Verifique se o kubectl está configurado corretamente obtendo o estado do cluster:

kubectl cluster-info

Se você receber uma URL de resposta, o kubectl está configurado corretamente para acessar seu cluster.

Se você receber uma mensagem semelhante à seguinte, o kubectl não está configurado corretamente ou não consegue se conectar a um cluster Kubernetes.

The connection to the server <server-name:port> was refused - did you specify the right host or port?

Por exemplo, se você pretende executar um cluster Kubernetes no seu laptop (localmente), precisará que uma ferramenta como o Minikube seja instalada primeiro, para em seguida executar novamente os comandos indicados acima.

Se o kubectl cluster-info retornar a URL de resposta, mas você não conseguir acessar seu cluster, para verificar se ele está configurado corretamente, use:

kubectl cluster-info dump

Configurações e plugins opcionais do kubectl

Ative o autocompletar no shell

O kubectl oferece recursos de autocompletar para Bash, Zsh, Fish e PowerShell, o que pode economizar muita digitação.

Abaixo estão os procedimentos para configurar o autocompletar para Bash, Fish e Zsh.

Introdução

O script de autocompletar do kubectl para Bash pode ser gerado com o comando kubectl completion bash. O script permite habilitar o autocompletar do kubectl no seu shell.

No entanto, o script autocompletar depende do bash-completion, o que significa que você precisa instalar este software primeiro (executando type _init_completion você pode testar se tem o bash-completion instalado).

Instale bash-completion

O bash-completion é fornecido por muitos gerenciadores de pacotes (veja aqui). Você pode instalar com apt-get install bash-completion ou yum install bash-completion, etc.

Os comandos acima criam /usr/share/bash-completion/bash_completion, que é o script principal de bash-completion. Dependendo do seu gerenciador de pacotes, você tem que adicionar manualmente ao seu arquivo ~/.bashrc.

Para descobrir, recarregue seu shell e execute type _init_completion. Se o comando for bem-sucedido, já está definido, caso contrário, adicione o seguinte ao seu arquivo ~/.bashrc:

source /usr/share/bash-completion/bash_completion

Recarregue o seu shell e verifique se o bash-completion está instalado corretamente digitando type _init_completion.

Ative o autocompletar do kubectl

Bash

Agora você precisa garantir que o autocompletar do kubectl esteja ativo em todas as suas sessões shell. Existem duas maneiras pelas quais você pode fazer isso:


echo 'source <(kubectl completion bash)' >>~/.bashrc


kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl > /dev/null
sudo chmod a+r /etc/bash_completion.d/kubectl

Se você tiver um alias para kubectl, você pode estender o autocompletar do shell para trabalhar com esse alias:

echo 'alias k=kubectl' >>~/.bashrc
echo 'complete -o default -F __start_kubectl k' >>~/.bashrc

Todas as abordagens são equivalentes. Depois de recarregar seu shell, o autocompletar do kubectl deve estar funcionando. Para ativar o autocompletar do bash na sessão atual do shell, execute exec bash:

exec bash

O script de autocompletar do kubectl para Fish pode ser gerado com o comando kubectl completion fish. O script permite habilitar o autocompletar do kubectl no seu shell.

Para fazer isso em todas as suas sessões do shell, adicione a seguinte linha ao seu arquivo ~/.config/fish/config.fish:

kubectl completion fish | source

Depois de recarregar seu shell, o autocompletar do kubectl deve estar funcionando.

O script de autocompletar do kubectl para Zsh pode ser gerado com o comando kubectl completion zsh. Este script habilita o autocompletar do kubectl no seu shell.

Para fazer isso em todas as suas sessões de shell, adicione a seguinte linha no arquivo ~/.zshrc:

source <(kubectl completion zsh)

Se você tiver um alias para kubectl, o autocompletar funcionará automaticamente com ele.

Depois de recarregar seu shell, o autocompletar do kubectl deve estar funcionando.

Se você ver um erro similar a 2: command not found: compdef, adicione o seguinte bloco ao início do seu arquivo ~/.zshrc:

autoload -Uz compinit
compinit

Instale o plugin kubectl convert

Um plugin para a ferramenta Kubernetes de linha de comando kubectl, que permite converter manifestos entre diferentes versões da API. Isso pode ser particularmente útil para migrar manifestos para uma versão não obsoleta com a versão mais recente da API Kubernetes. Para mais informações, visite Migrar para APIs não obsoletas

  1. Faça download da versão mais recente com o comando:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert"
    
  2. Valide o binário (opcional)

    Faça download do arquivo checksum de verificação do kubectl-convert:

    curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl-convert.sha256"
    

    Valide o binário kubectl-convert com o arquivo de verificação:

    echo "$(cat kubectl-convert.sha256) kubectl-convert" | sha256sum --check
    

    Se válido, a saída será:

    kubectl-convert: OK
    

    Se a verificação falhar, o sha256 exibirá o status diferente de zero e a saída será semelhante a:

    kubectl-convert: FAILED
    sha256sum: WARNING: 1 computed checksum did NOT match
    
  3. Instale o kubectl-convert

    sudo install -o root -g root -m 0755 kubectl-convert /usr/local/bin/kubectl-convert
    
  4. Verifique se o plugin foi instalado com sucesso

    kubectl convert --help
    

    Se não for exibido um erro, isso significa que o plugin foi instalado com sucesso.

Próximos passos

2 - Gerenciando Secrets

Gerenciando dados de configurações usando Secrets.

2.1 - Gerenciando Secret usando kubectl

Criando objetos Secret usando a linha de comando kubectl.

Antes de você começar

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:

Criando um Secret

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=admin \
  --from-literal=password='S!B\*d$zDsb='

Verificando o Secret

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.

Decodificando o Secret

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

Limpeza

Para apagar o Secret que você criou:

kubectl delete secret db-user-pass

Próximos passos

2.2 - Gerenciando Secret usando Arquivo de Configuração

Criando objetos Secret usando arquivos de configuração de recursos.

Antes de você começar

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:

Crie o arquivo de configuração

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.

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>    

Crie o objeto Secret

Agora, crie o Secret usando kubectl apply:

kubectl apply -f ./secret.yaml

A saída deve ser similar a:

secret/mysecret created

Verifique o Secret

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.

Limpeza

Para apagar o Secret que você criou:

kubectl delete secret mysecret

Próximos passos

2.3 - Gerenciando Secret usando Kustomize

Criando objetos Secret usando o arquivo kustomization.yaml

Desde 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.

Antes de você começar

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:

Criando um arquivo de Kustomization

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.

Criando o Secret

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.

Verifique o Secret criado

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.

Limpeza

Para apagar o Secret que você criou:

kubectl delete secret db-user-pass-96mffmfh4k

Próximos passos

3 - Configurar Pods e Contêineres

Realizar tarefas comuns de configuração de Pods e contêineres

3.1 - Configurando GMSA Para Pods e Contêineres Windows

ESTADO DA FUNCIONALIDADE: Kubernetes v1.18 [stable]

Esta página mostra como configurar Contas de serviço gerenciadas em grupo (GMSA) para Pods e contêineres que vão executar em nós Windows. Contas de serviço gerenciadas em grupo são um tipo específico de conta do Active Directory que provê gerenciamento automático de senhas, gerenciamento simplificado de service principal name (SPN), e a habilidade de delegar o gerenciamento a outros administradores através de múltiplos servidores.

No Kubernetes, especificações de credenciais GMSA são configuradas dentro do escopo do cluster Kubernetes como recursos personalizados. Os Pods Windows, assim como contêineres individuais dentro de um Pod, podem ser configurados para usar as funções GMSA baseadas em domínio (exemplo: autenticação Kerberos) quando interagirem com outros serviços Windows.

Antes de você começar

Você precisa ter um cluster Kubernetes, e a ferramenta de linha de comando kubectl precisa estar configurada para comunicar-se com seu cluster. O cluster deve possuir nós de carga de trabalho Windows. Esta seção cobre o conjunto inicial de passos requeridos para cada cluster:

Instale o CRD GMSACredentialSpec

Uma CustomResourceDefinition (CRD) para a especificação de recursos de credencial GMSA precisa ser configurada no cluster, para definir o tipo de recurso do cliente GMSACredentialSpec. Faça o download do YAML do CRD de GMSA e salve como gmsa-crd.yaml. A seguir, instale o CRD com kubectl apply -f gmsa-crd.yaml.

Instale webhooks para validar usuários GMSA

Dois webhooks precisam ser configurados no cluster Kubernetes para popular e validar as referências de especificação de credenciais GMSA no nível do Pod ou contêiner:

  1. Um webhook de mutação que expanda as referências para as GMSAs, (por nome a partir de uma especificação de Pod) em uma especificação de credencial completa em formato JSON dentro da especificação do Pod.

  2. Um webhook de validação garante que todas as referências para GMSAs estão autorizadas a serem usadas pela conta de serviço do Pod.

A instalação dos webhooks acima e dos objetos associados requer as etapas abaixo:

  1. Crie um par de chaves de certificado (que será usado para permitir que o contêiner do webhook se comunique com o cluster)

  2. Instale um Secret com o certificado acima.

  3. Crie um Deployment para a lógica principal do webhook.

  4. Crie as configurações de webhook de validação e de mutação, referentes ao Deployment.

Um script pode ser usado para implantar e configurar os webhooks GMSA e objetos associados mencionados acima. O script pode ser executado com a opção --dry-run=server para possibilitar que você possa revisar as alterações antes que sejam aplicadas no seu cluster.

O template YAML usado pelo script também pode ser usado para implantar os webhooks e objetos associados manualmente (com as substituições apropriadas para os parâmetros).

Configurar GMSAs e nós Windows em Active Directory

Antes que os Pods no Kubernetes possam ser configurados para usar GMSAs, as GMSAs apropriadas precisam ser provisionadas no Active Directory como descrito na documentação de GMSA do Windows. Nós de carga de trabalho Windows (que são parte do cluster Kubernetes) precisam ser configurados no Active Directory para acessar as credenciais secretas associadas com a GMSA apropriada, como descrito na documentação de GMSA do Windows.

Crie recursos de especificação de GMSA

Com o CRD GMSACredentialSpec instalado (como descrito anteriormente), recursos customizados contendo recursos de especificação de credenciais GMSA podem ser configurados. A especificação de credencial GMSA não contém dados secretos nem sensíveis. É informação que o agente de execução de contêiner pode usar para descrever a apropriada GMSA de um contêiner para o Windows. Especificações de credenciais GMSA podem ser geradas em formato YAML com o utilitário PowerShell script.

A seguir são os passos para gerar a especificação de credencial GMSA YAML manualmente, em formato JSON e então convertê-la para YAML:

  1. Importar o módulo CredentialSpec: ipmo CredentialSpec.psm1

  2. Crie a especificação da credencial em formato JSON usando New-CredentialSpec. Para criar a especificação da credencial GMSA nomeada WebApp1, execute New-CredentialSpec -Name WebApp1 -AccountName WebApp1 -Domain $(Get-ADDomain -Current LocalComputer)

  3. Use Get-CredentialSpec para mostrar o caminho do arquivo JSON.

  4. Converta o arquivo credspec de JSON para o formato YAML e aplique os campos de cabeçalho necessários apiVersion, kind, metadata e credspec para transformá-lo em uma instância do recurso customizado GMSACredentialSpec que pode ser configurado no Kubernetes.

A configuração YAML a seguir descreve as especificações de credencial GMSA nomeada gmsa-WebApp1:

apiVersion: windows.k8s.io/v1
kind: GMSACredentialSpec
metadata:
  name: gmsa-WebApp1      #Este é um nome arbitrário, mas será usado como referência
credspec:
  ActiveDirectoryConfig:
    GroupManagedServiceAccounts:
    - Name: WebApp1       #Nome de usuário da conta GMSA
      Scope: CONTOSO      #Nome de Domínio NETBIOS
    - Name: WebApp1       #Nome de usuário da conta GMSA
      Scope: contoso.com  #Nome de domínio DNS
  CmsPlugins:
  - ActiveDirectory
  DomainJoinConfig:
    DnsName: contoso.com        #Nome de domínio DNS
    DnsTreeName: contoso.com    #Nome de domínio DNS raiz
    Guid: 244818ae-87ac-4fcd-92ec-e79e5252348a  #GUID
    MachineAccountName: WebApp1 #Nome de usuário da conta GMSA
    NetBiosName: CONTOSO        #Nome de domínio NETBIOS
    Sid: S-1-5-21-2126449477-2524075714-3094792973 #SID da GMSA

O recurso de especificação de credencial acima deve ser salvo como gmsa-Webapp1-credspec.yaml e aplicado no cluster usando: kubectl apply -f gmsa-Webapp1-credspec.yml

Configure um ClusterRole para habilitar RBAC nas especificações de credenciais GMSA específicas

Uma ClusterRole precisa ser definida para cada recurso de especificação de credencial GMSA. Isto autoriza o verbo use em um recurso GMSA específico por um sujeito, geralmente uma conta de serviço. O exemplo a seguir mostra um ClusterRole que autoriza o uso de credencial gmsa-WebApp1 acima. Salve o arquivo como gmsa-webapp1-role.yaml e aplique usando kubectl apply -f gmsa-webapp1-role.yaml

#Criando um Role para ler o credspec
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: webapp1-role
rules:
- apiGroups: ["windows.k8s.io"]
  resources: ["gmsacredentialspecs"]
  verbs: ["use"]
  resourceNames: ["gmsa-WebApp1"]

Atribua o Role às contas de serviço para usar especificações de credencial GMSA específicas

Uma conta de serviço (com a qual os Pods virão configurados), precisa ser vinculada ao ClusterRole criado acima. Isto autoriza a conta de serviço a usar a especificação apropriada de recurso de credencial GMSA. O trecho a seguir mostra a conta de serviço padrão vinculada ao ClusterRole webapp1-role, para usar a especificação de recurso de credencial gmsa-WebApp1 criada acima.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: allow-default-svc-account-read-on-gmsa-WebApp1
  namespace: default
subjects:
- kind: ServiceAccount
  name: default
  namespace: default
roleRef:
  kind: ClusterRole
  name: webapp1-role
  apiGroup: rbac.authorization.k8s.io

Configure a especificação de recurso de credencial GMSA em uma especificação de Pod

O campo securityContext.windowsOptions.gmsaCredentialSpecName do Pod, é usado de referência para recursos customizados, em especificações de certificado GMSA apropriadas em especificações do Pod. Isto configura todos contêineres do Pod para usar GMSA. Uma amostra da anotação populada para referir-se a gmsa-WebApp1:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      securityContext:
        windowsOptions:
          gmsaCredentialSpecName: gmsa-webapp1
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
      nodeSelector:
        kubernetes.io/os: windows

Contêineres individuais em uma especificação de Pod podem também indicar a credencial GMSA apropriada, usando o campo securityContext.windowsOptions.gmsaCredentialSpecName por contêiner. Por exemplo:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    run: with-creds
  name: with-creds
  namespace: default
spec:
  replicas: 1
  selector:
    matchLabels:
      run: with-creds
  template:
    metadata:
      labels:
        run: with-creds
    spec:
      containers:
      - image: mcr.microsoft.com/windows/servercore/iis:windowsservercore-ltsc2019
        imagePullPolicy: Always
        name: iis
        securityContext:
          windowsOptions:
            gmsaCredentialSpecName: gmsa-Webapp1
      nodeSelector:
        kubernetes.io/os: windows

Assim que as especificações do Pod com os campos GMSA preenchidos (como descrito acima) são aplicadas em um cluster, ocorre a seguinte sequência de eventos:

  1. O webhook de mutação resolve e expande todas as referências aos recursos de especificações de credenciais GMSA para o conteúdo das especificações de credenciais GMSA.

  2. O webhook de validação garante que a conta de serviço associada ao Pod, seja autorizada para o verbo use na especificação GMSA especificada.

  3. O agente de execução de contêiner configura cada contêiner do Windows com a especificação de credencial GMSA especificada, para que o contêiner possa assumir a identidade do GMSA no Active Directory, e tenha acesso aos serviços no domínio usando essa identidade.

Autenticando para compartilhamentos de rede usando hostname ou FQDN

Se você estiver enfrentando problemas ao se conectar aos compartilhamentos SMB de Pods usando o hostname ou o FQDN, mas conseguindo acessar os compartilhamentos por meio de seu endereço IPv4, verifique se a chave do registro a seguir está definida nos nós Windows.

reg add "HKLM\SYSTEM\CurrentControlSet\Services\hns\State" /v EnableCompartmentNamespace /t REG_DWORD /d 1

Os Pods em execução precisarão ser recriados para pegar as mudanças de comportamento. Mais informações sobre como essa chave de registro é usada podem ser encontradas aqui

Solução de problemas

Se você estiver tendo dificuldades para fazer com que o GMSA funcione em seu ambiente, existem algumas etapas de solução de problemas que você pode tentar.

Primeiro, verifique se a especificação de credencial foi passada para o Pod. Para fazer isso, você precisará rodar kubectl exec em um de seus Pods e verificar a saída do comando nltest.exe /parentdomain.

No exemplo abaixo, o Pod não recebeu a especificação de credencial corretamente:

kubectl exec -it iis-auth-7776966999-n5nzr powershell.exe

nltest.exe /parentdomain resulta no seguinte erro:

Getting parent domain failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

Se o seu Pod obteve a especificação de credencial corretamente, o próximo passo é verificar a comunicação com o domínio. Primeiro, de dentro do seu Pod, execute rapidamente um nslookup para encontrar a raiz do seu domínio.

Isso vai nos dizer 3 coisas:

  1. O Pod pode chegar ao DC
  2. O DC pode chegar ao Pod
  3. O DNS está funcionando corretamente.

Se o DNS e o teste de comunicação passarem, em seguida, você precisará verificar se o Pod estabeleceu um canal de comunicação segura com o domínio. Para fazer isso, novamente, em seu Pod execute o comando nltest.exe /query.

nltest.exe /query

Resulta na seguinte saída:

I_NetLogonControl failed: Status = 1722 0x6ba RPC_S_SERVER_UNAVAILABLE

Isso nos diz que, por algum motivo, o Pod não conseguiu se logar no domínio usando a conta definida na especificação de credencial. Você pode tentar reparar o canal seguro executando o seguinte:

nltest /sc_reset:domain.example

Se o comando for bem sucedido, você verá uma saída semelhante a esta:

Flags: 30 HAS_IP  HAS_TIMESERV
Trusted DC Name \\dc10.domain.example
Trusted DC Connection Status Status = 0 0x0 NERR_Success
The command completed successfully

Se o excerto acima corrigir o erro, você poderá automatizar a etapa adicionando o seguinte lifecycle hook à sua especificação de Pod. Se não corrigiu o erro, você precisará examinar sua especificação de credencial novamente e confirmar que ela está correta e completa.

        image: registry.domain.example/iis-auth:1809v1
        lifecycle:
          postStart:
            exec:
              command: ["powershell.exe","-command","do { Restart-Service -Name netlogon } while ( $($Result = (nltest.exe /query); if ($Result -like '*0x0 NERR_Success*') {return $true} else {return $false}) -eq $false)"]
        imagePullPolicy: IfNotPresent

Se você adicionar a seção lifecycle, mostrada acima à sua especificação de Pod, o Pod irá executar os comandos listados para reiniciar o serviço netlogon até que o comando nltest.exe /query execute sem erro.

3.2 - Configurando RunAsUserName Para Pods e Contêineres Windows

ESTADO DA FUNCIONALIDADE: Kubernetes v1.18 [stable]

Esta página mostra como usar a configuração runAsUserName para Pods e contêineres que serão executados em nós Windows. Isso é aproximadamente equivalente à configuração runAsUser específica do Linux, permitindo a você executar aplicativos em um contêiner com um nome de usuário diferente do padrão.

Antes de você começar

Você precisa ter um cluster Kubernetes, e a ferramenta de linha de comando Kubectl deve ser configurada para se comunicar com o seu cluster. Espera-se que o cluster tenha nós de carga de trabalho Windows, onde os Pods com contêineres executando as cargas de trabalho do Windows, serão agendados.

Defina o nome de usuário para um Pod

Para especificar o nome de usuário com o qual executar os processos de contêiner do Pod, inclua o campo securityContext (PodSecurityContext) na especificação do Pod, e dentro dela, o campo WindowsOptions (WindowsSecurityContextOptions) contendo o campo runAsUserName.

As opções de contexto de segurança do Windows que você especificar para um Pod, se aplicam a todos os contêineres do Pod, inclusive os de inicialização.

Veja abaixo um arquivo de configuração para um Pod do Windows que possui o campo runAsUserName definido:

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-pod-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
  nodeSelector:
    kubernetes.io/os: windows

Crie o Pod:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-pod.yaml

Verifique se o contêiner do Pod está em execução:

kubectl get pod run-as-username-pod-demo

Abra um shell para o contêiner em execução:

kubectl exec -it run-as-username-pod-demo -- powershell

Verifique se o shell está executando com o nome de usuário correto:

echo $env:USERNAME

A saída deve ser:

ContainerUser

Defina o nome de usuário para o contêiner

Para especificar o nome de usuário com o qual executar os processos de um contêiner, inclua o campo SecurityContext (SecurityContext) no manifesto do contêiner, e dentro dele, o campo WindowsOptions (WindowsSecurityContextOptions) contendo o campo runAsUserName.

As opções de contexto de segurança do Windows que você especificar para um contêiner, se aplicam apenas a esse contêiner individual, e substituem as configurações feitas no nível do Pod.

Aqui está o arquivo de configuração para um pod que possui um contêiner, e o campo runAsUserName está definido no nível do Pod e no nível do contêiner:

apiVersion: v1
kind: Pod
metadata:
  name: run-as-username-container-demo
spec:
  securityContext:
    windowsOptions:
      runAsUserName: "ContainerUser"
  containers:
  - name: run-as-username-demo
    image: mcr.microsoft.com/windows/servercore:ltsc2019
    command: ["ping", "-t", "localhost"]
    securityContext:
        windowsOptions:
            runAsUserName: "ContainerAdministrator"
  nodeSelector:
    kubernetes.io/os: windows

Crie o Pod:

kubectl apply -f https://k8s.io/examples/windows/run-as-username-container.yaml

Verifique se o contêiner do Pod está em execução:

kubectl get pod run-as-username-container-demo

Abra um shell para o contêiner em execução:

kubectl exec -it run-as-username-container-demo -- powershell

Verifique se o shell está executando o usuário correto, (aquele definido no nível do contêiner):

echo $env:USERNAME

A saída deve ser:

ContainerAdministrator

Limitações de nomes de usuários no Windows

Para usar esse recurso, o valor definido no campo runAsUserName deve ser um nome de usuário válido. Deve ter o seguinte formato: DOMAIN\USER, onde DOMAIN\ é opcional. Os nomes de usuário do Windows não diferenciam letras maiúsculas e minúsculas. Além disso, existem algumas restrições em relação ao DOMAIN e USER:

  • O campo runAsUserName: não pode estar vazio, e não pode conter caracteres de controle (Valores ASCII : 0x00-0x1F, 0x7F)
  • O nome de DOMAIN NetBios, ou um nome de DNS, cada um com suas próprias restrições:
    • Nomes NetBios: máximo de 15 caracteres, não podem iniciar com . (ponto), e não podem conter os seguintes caracteres: \ / : * ? " < > |
    • Nomes DNS: máximo de 255 caracteres, contendo apenas caracteres alfanuméricos, pontos, e traços, e não podem iniciar ou terminar com um . (ponto) ou - (traço).
  • O USER: deve ter no máximo 20 caracteres, não pode conter somente pontos ou espaços, e não pode conter os seguintes caracteres: " / \ [ ] : ; | = , + * ? < > @.

Exemplos de valores aceitáveis para o campo runAsUserName: ContainerAdministrator, ContainerUser, NT AUTHORITY\NETWORK SERVICE, NT AUTHORITY\LOCAL SERVICE.

Para mais informações sobre estas limitações, verifique aqui e aqui.

Próximos passos

3.3 - Configurando Qualidade do Serviço Para Pods

Esta 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.

Antes de você começar

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, digite kubectl version.

Classes QoS

Quando o Kubernetes cria um Pod, ele atribui uma dessas classes de QoS ao Pod:

  • Guaranteed
  • Burstable
  • BestEffort

Crie um namespace

Crie um namespace, assim os seus recursos criados neste exercício estarão isolados do resto do seu cluster.

kubectl create namespace qos-example

Crie um Pod ao qual seja atribuída uma classe de QoS Guaranteed

Para que um Pod receba uma classe de QoS Guaranteed:

  • Todo contêiner no Pod deve ter um limite de memória e um requisito de memória.
  • Para cada contêiner no Pod, o limite de memória deve ser igual ao requisito de memória.
  • Todo contêiner no Pod deve ter um limite de CPU e um requisito de CPU.
  • Para cada contêiner no Pod, o limite de CPU deve ser igual ao requisito de CPU.

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

Crie um Pod ao qual seja atribuída uma classe de QoS Burstable

Um Pod recebe uma classe de QoS Burstable se:

  • O Pod não atende aos critérios para a classe de QoS Guaranteed.
  • Pelo menos um contêiner no Pod tem um requisito ou limite de memória ou CPU.

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

Crie um Pod ao qual seja atribuída uma classe de QoS BestEffort

Para 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

Crie um Pod que tenha dois contêineres

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

Limpeza

Apague seu namespace:

kubectl delete namespace qos-example

Próximos passos

Para desenvolvedores de App

Para administradores de cluster

3.4 - Atribuindo Recursos Estendidos a um Contêiner

ESTADO DA FUNCIONALIDADE: Kubernetes v1.30 [stable]

Esta página mostra como atribuir recursos estendidos a um Contêiner.

Antes de você começar

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, digite kubectl version.

Antes de fazer este exercício, faça o exercício em Anunciar recursos estendidos para um Nó. Isso configurará um de seus nós para anunciar um recurso de dongle.

Atribua um recurso estendido a um Pod

Para solicitar um recurso estendido, inclua o campo resources:requests no seu manifesto do contêiner. Recursos estendidos são totalmente qualificados com qualquer domínio fora do *.kubernetes.io/. Nomes de recursos estendidos válidos tem a forma de example.com/foo, onde example.com é substituído pelo domínio da sua organização e foo é um nome descritivo de recurso.

Aqui está o arquivo de configuração para um pod que possui um contêiner:

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo
spec:
  containers:
  - name: extended-resource-demo-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 3
      limits:
        example.com/dongle: 3

No arquivo de configuração, você pode ver que o contêiner solicita 3 dongles.

Crie um Pod:

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod.yaml

Verifique se o pod está em execução:

kubectl get pod extended-resource-demo

Descreva o pod:

kubectl describe pod extended-resource-demo

A saída mostra as solicitações de dongle:

Limits:
  example.com/dongle: 3
Requests:
  example.com/dongle: 3

Tente criar um segundo Pod

Aqui está o arquivo de configuração para um pod que possui um contêiner. O contêiner solicita dois dongles.

apiVersion: v1
kind: Pod
metadata:
  name: extended-resource-demo-2
spec:
  containers:
  - name: extended-resource-demo-2-ctr
    image: nginx
    resources:
      requests:
        example.com/dongle: 2
      limits:
        example.com/dongle: 2

O Kubernetes não poderá satisfazer o pedido de dois dongles, porque o primeiro pod usou três dos quatro dongles disponíveis.

Tente criar um pod:

kubectl apply -f https://k8s.io/examples/pods/resource/extended-resource-pod-2.yaml

Descreva o pod:

kubectl describe pod extended-resource-demo-2

A saída mostra que o pod não pode ser agendado, porque não há nó que tenha 2 dongles disponíveis:

Conditions:
  Type    Status
  PodScheduled  False
...
Events:
  ...
  ... Warning   FailedScheduling  pod (extended-resource-demo-2) failed to fit in any node
fit failure summary on nodes : Insufficient example.com/dongle (1)

Veja o status do pod:

kubectl get pod extended-resource-demo-2

A saída mostra que o Pod foi criado, mas não está programado para ser executado em um nó. Tem um status de pendente:

NAME                       READY     STATUS    RESTARTS   AGE
extended-resource-demo-2   0/1       Pending   0          6m

Limpeza

Exclua os Pods que você criou para este exercício:

kubectl delete pod extended-resource-demo
kubectl delete pod extended-resource-demo-2

Próximos passos

Para desenvolvedores de aplicativos

Para administradores de cluster

3.5 - Configurando um Pod Para Usar um Volume Para Armazenamento

Esta página mostra como configurar um Pod para usar um Volume para armazenamento.

O sistema de arquivos de um contêiner apenas existe enquanto o contêiner existir. Então, quando um contêiner termina e reinicia, as alterações do sistema de arquivos são perdidas. Para um armazenamento mais consistente, independente do contêiner, você pode usar um Volume. Isso é especialmente importante para aplicações stateful, tal como armazenamentos chave-valor (tal como Redis) e bancos de dados.

Antes de você começar

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, digite kubectl version.

Configure um volume para um Pod

Neste exercício, você cria um Pod que executa um contêiner. Este Pod tem um Volume do tipo emptyDir que persiste durante a existência do Pod, mesmo que o contêiner termine e reinicie. Aqui está o arquivo de configuração para o pod:

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: redis
    volumeMounts:
    - name: redis-storage
      mountPath: /data/redis
  volumes:
  - name: redis-storage
    emptyDir: {}
  1. Crie o Pod:

    kubectl apply -f https://k8s.io/examples/pods/storage/redis.yaml
    
  2. Verifique se o contêiner do pod está funcionando, e então procure por mudanças no Pod:

    kubectl get pod redis --watch
    

    A saída se parece com isso:

    NAME      READY     STATUS    RESTARTS   AGE
    redis     1/1       Running   0          13s
    
  3. Em outro terminal, pegue um shell para o contêiner em execução:

    kubectl exec -it redis -- /bin/bash
    
  4. No seu shell, vá para /data/redis, e então crie um arquivo:

    root@redis:/data# cd /data/redis/
    root@redis:/data/redis# echo Hello > test-file
    
  5. No seu shell, liste os processos em execução:

    root@redis:/data/redis# apt-get update
    root@redis:/data/redis# apt-get install procps
    root@redis:/data/redis# ps aux
    

    A saída é semelhante a esta:

    USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
    redis        1  0.1  0.1  33308  3828 ?        Ssl  00:46   0:00 redis-server *:6379
    root        12  0.0  0.0  20228  3020 ?        Ss   00:47   0:00 /bin/bash
    root        15  0.0  0.0  17500  2072 ?        R+   00:48   0:00 ps aux
    
  6. Em seu shell, encerre o processo do Redis:

    root@redis:/data/redis# kill <pid>
    

    Onde <pid> é o process ID (PID) do Redis.

  7. No seu terminal original, preste atenção nas mudanças no Pod do Redis. Eventualmente, você vai ver algo assim:

    NAME      READY     STATUS     RESTARTS   AGE
    redis     1/1       Running    0          13s
    redis     0/1       Completed  0         6m
    redis     1/1       Running    1         6m
    

Neste ponto, o Contêiner terminou e reiniciou. Isso porque o Pod do Redis tem uma restartPolicy de Always.

  1. Abra um shell dentro do Contêiner reiniciado:

    kubectl exec -it redis -- /bin/bash
    
  2. No seu shell, vá para /data/redis, e verifique se test-file ainda está lá.

    root@redis:/data/redis# cd /data/redis/
    root@redis:/data/redis# ls
    test-file
    
  3. Exclua o pod que você criou para este exercício:

    kubectl delete pod redis
    

Próximos passos

  • Veja Volume.

  • Veja Pod.

  • Além do armazenamento de disco local fornecido por emptyDir, o Kubernetes suporta muitas soluções de armazenamento diferentes, conectadas via rede, incluindo PD na GCE e EBS na EC2, que são preferidos para dados críticos e vão lidar com os detalhes, como montar e desmontar os dispositivos nos Nós. Veja Volumes para mais detalhes.

3.6 - Configurando um Pod Para Usar um Volume Persistente Para armazenamento

Esta página mostra como configurar um Pod para usar um PersistentVolumeClaim para armazenamento. Aqui está o resumo do processo:

  1. Você, como administrador do cluster, faz a criação de um Volume Persistente suportado por armazenamento físico. Você não associa o volume a nenhum Pod.

  2. Você, agora assumindo o papel de desenvolvedor/usuário do cluster, faz a criação de um PersistentVolumeClaim que é automaticamente vinculado ao Volume Persistente adequado.

  3. Você cria um Pod que usa o PersistentVolumeClaim acima para armazenamento.

Antes de você começar

  • Você precisa ter um cluster Kubernetes que tenha apenas um nó, e a ferramenta de linha de comando kubectl configurada para se comunicar com seu cluster. Se você ainda não tem um cluster de um único nó, você pode criar um usando o Minikube.

  • Familiarize-se com o material em Volumes persistentes.

Criando um arquivo index.html no seu nó

Abra um shell no único nó do seu cluster. A maneira de abrir um shell vai depender de como você inicializou seu cluster. Por exemplo, se você estiver usando o Minikube, você pode abrir um shell para o seu nó digitando minikube ssh.

No seu shell desse nó, crie um diretótio /mnt/data:

# Assumindo que o seu nó use "sudo" para executar comandos 
# como superusuário
sudo mkdir /mnt/data

content/pt-br/docs/tasks/configure-pod-container/configure-service-account.md No diretório /mnt/data, crie o arquivo index.html:

# Novamente assumindo que seu nó use "sudo" para executar comandos
# como superusuário
sudo sh -c "echo 'Hello from Kubernetes storage' > /mnt/data/index.html"

Teste se o arquivo index.html existe:

cat /mnt/data/index.html

A saída deve ser:

Hello from Kubernetes storage

Você agora pode fechar o shell do seu nó.

Crie um Volume Persistente

Neste exercício, você cria um Volume Persistente hostPath. O Kubernetes suporta hostPath para desenvolvimento e teste em um cluster com apenas um nó. Um Volume Persistente hostPath usa um arquivo ou diretório no nó, para emular um armazenamento conectado pela rede.

Em um cluster de produção, você não usaria hostPath. Em vez disso um administrador de cluster provisionaria um recurso de rede, como um disco persistente do Google Compute Engine, um NFS compartilhado, ou um volume do Amazon Elastic Block Store. Administradores podem também usar classes de armazenamento para incializar provisionamento dinâmico.

Aqui está o arquivo de configuração para o Volume Persistente hostPath:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: task-pv-volume
  labels:
    type: local
spec:
  storageClassName: manual
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

O arquivo de configuração especifica que o volume está no diretório /mnt/data do nó do cluster. A configuração também especifica um tamanho de 10 gibibytes e um modo de acesso ReadWriteOnce, o que significa que o volume pode ser montado como leitura-escrita pelo único nó. Define o nome da classe de armazenamento manual para o Volume Persistente, que será usado para vincular requisições PersistentVolumeClaim à esse Volume Persistente.

Crie o Volume Persistente:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-volume.yaml

Veja informações do Volume Persistente:

kubectl get pv task-pv-volume

A saída mostra que o Volume Persistente tem um STATUS de Available. Isto significa que ainda não foi vinculado a um PersistentVolumeClaim.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Available             manual                   4s

Crie um PersistentVolumeClaim

O próximo passo é criar um PersistentVolumeClaim. Pods usam PersistentVolumeClaims para requisitar armazenamento físico. Neste exercício, você vai criar um PersistentVolumeClaim que requisita um volume com pelo menos três gibibytes, com acesso de leitura-escrita para pelo menos um nó.

Aqui está o arquivo de configuração para oPersistentVolumeClaim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: task-pv-claim
spec:
  storageClassName: manual
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 3Gi

Crie o PersistentVolumeClaim:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-claim.yaml

Após criar o PersistentVolumeClaim, o Kubernetes control plane procura por um Volume Persistente que satisfaça os requerimentos reivindicados. Se o control plane encontrar um Volume Persistente adequado, com a mesma classe de armazenamento, ele liga o volume requisitado.

Olhe novamente o Volume Persistente:

kubectl get pv task-pv-volume

Agora a saída mostra um STATUS de Bound.

NAME             CAPACITY   ACCESSMODES   RECLAIMPOLICY   STATUS    CLAIM                   STORAGECLASS   REASON    AGE
task-pv-volume   10Gi       RWO           Retain          Bound     default/task-pv-claim   manual                   2m

Olhe para o PersistentVolumeClaim:

kubectl get pvc task-pv-claim

A saída mostra que oPersistentVolumeClaim está vinculado ao seu Volume Persistente, task-pv-volume.

NAME            STATUS    VOLUME           CAPACITY   ACCESSMODES   STORAGECLASS   AGE
task-pv-claim   Bound     task-pv-volume   10Gi       RWO           manual         30s

Crie um Pod

O próximo passo é criar um Pod que usa o seu PersistentVolumeClaim como um volume.

Aqui está o arquivo de configuração para o Pod:

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage


Note que o arquivo de configuração do Pod especifica um PersistentVolumeClaim, mas não especifica um Volume Persistente. Do ponto de vista do Pod, a reivindicação é de um volume.

Crie o Pod:

kubectl apply -f https://k8s.io/examples/pods/storage/pv-pod.yaml

Verifique se o contêiner no Pod está executando;

kubectl get pod task-pv-pod

Abra o shell do contêiner, executando no seu Pod:

kubectl exec -it task-pv-pod -- /bin/bash

No seu shell, verifique se o nginx está servindo o arquivo index.html do volume do hostPath:

# Certifique-se de executar esses 3 comandos dentro do shell, na raiz que vem da
# execução "kubectl exec" do passo anterior
apt update
apt install curl
curl http://localhost/

A saída mostra o texto que você escreveu no arquivo index.html no volume do hostPath:

Hello from Kubernetes storage

Se você vir essa mensagem, configurou com sucesso um pod para usar o armazenamento de um PersistentVolumeClaim.

Limpeza

Exclua o Pod, o PersistentVolumeClaim e o Volume Persistente:

kubectl delete pod task-pv-pod
kubectl delete pvc task-pv-claim
kubectl delete pv task-pv-volume

Se você ainda não tem um shell aberto no nó em seu cluster, Abra um novo shell da mesma maneira que você fez antes. No shell do seu nó, remova o arquivo e o diretório que você criou:

# Pressupondo que seu nó usa "sudo" para executar comandos
# como superusuário
sudo rm /mnt/data/index.html
sudo rmdir /mnt/data

Você pode agora fechar o shell do seu nó.

Montando o mesmo Volume Persistente em dois lugares


apiVersion: v1
kind: Pod
metadata:
  name: test
spec:
  containers:
    - name: test
      image: nginx
      volumeMounts:
        # a mount for site-data
        - name: config
          mountPath: /usr/share/nginx/html
          subPath: html
        # another mount for nginx config
        - name: config
          mountPath: /etc/nginx/nginx.conf
          subPath: nginx.conf
  volumes:
    - name: config
      persistentVolumeClaim:
        claimName: test-nfs-claim

Você pode realizar a montagem de 2 volumes no seu contêiner nginx:

/usr/share/nginx/html para o website estático /etc/nginx/nginx.conf para a configuração padrão

Controle de accesso

Armazenamento configurado com um group ID (GID) possibilita a escrita somente pelos Pods usando a mesma GID. GIDs incompatíveis ou perdidos causam erros de negação de permissão. Para reduzir a necessidade de coordenação de usuários, um administrador pode anotar um Volume Persistente com uma GID. Então a GID é automaticamente adicionada a qualquer Pod que use um Volume Persistente.

Use a anotação pv.beta.kubernetes.io/gid como a seguir:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv1
  annotations:
    pv.beta.kubernetes.io/gid: "1234"

Quando um Pod consome um Volume Persistente que tem uma anotação GID, o GID anotado é aplicado à todos os contêiners no Pod, da mesma forma que as GIDs especificadas no contexto de segurança em que o Pod está. Cada GID, se é originário de uma anotação de Volume Persistente ou da especificação do Pod, é aplicada ao primeiro processo executando em cada contêiner.

Próximos passos

Referência

3.7 - Atribuindo Pods aos Nós

Esta página mostra como atribuir um Pod Kubernetes a um nó particular em um cluster Kubernetes.

Antes de você começar

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, digite kubectl version.

Adicione um rótulo a um nó

  1. 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
    
  2. 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.

  3. 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.

Crie um pod que é agendado em seu nó escolhido

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
  1. 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
    
  2. 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
    

Crie um pod que é agendado em um nó específico

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.

Próximos passos

3.8 - Configurando um Pod Para Usar um ConfigMap

Muitas aplicações dependem da configuração que é usada durante a inicialização do aplicativo ou do agente de execução. Na maioria das vezes, há um requisito para ajustar os valores atribuídos aos parâmetros de configuração. O objeto ConfigMap é a maneira usada no Kubernetes para injetar dados de configuração em Pods de aplicativos. O ConfigMap permite que você desacople os artefatos de configuração do conteúdo da imagem, para manter os aplicativos de contêiner portáveis. Esta página fornece uma série de exemplos de uso, demonstrando como criar ConfigMaps e configurar Pods usando dados armazenados em ConfigMaps.

Antes de você começar

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, digite kubectl version.

Crie um ConfigMap

Você pode usar kubectl create configmap ou um gerador de ConfigMap, em um arquivo kustomization.yaml para criar um ConfigMap. Perceba que o kubectl começou a suportar o kustomization.yaml desde a versão 1.14.

Crie um ConfigMap Usando kubectl create configmap

Use o comando kubectl create configmap para criar um ConfigMap a partir de diretórios, arquivos, ou valores literais:

kubectl create configmap <map-name> <data-source>

Onde <map-name> é o nome que você quer atribuir ao ConfigMap e <data-source> é o diretório, arquivo, ou o valor literal de onde buscar os dados. O nome de um objeto ConfigMap precisa ser um nome de subdomínio DNS válido. Quando você estiver criando um ConfigMap baseado em um arquivo, a chave no <data-source> é por padrão o nome-base do arquivo, e o valor é por padrão o conteúdo do arquivo.

Você pode usar kubectl describe ou kubectl get para obter informações sobre um ConfigMap.

Crie um ConfigMap a partir de diretórios

Você pode usar kubectl create configmap para criar um ConfigMap a partir de vários arquivos no mesmo diretório. Quando você está criando um ConfigMap baseado em um diretório, o kubectl identifica arquivos cujo nome-base é uma chave válida no diretório e empacota cada um desses arquivos no novo ConfigMap. Quaisquer entradas existentes no diretório que não sejam arquivos regulares são ignoradas (ex. subdiretórios, links simbólicos, dispositivos, pipes, etc).

Por exemplo:

# Criando o diretório local

mkdir -p configure-pod-container/configmap/

# Baixe os arquivos de amostra no diretório `configure-pod-container/configmap/` 

wget https://kubernetes.io/examples/configmap/game.properties -O configure-pod-container/configmap/game.properties
wget https://kubernetes.io/examples/configmap/ui.properties -O configure-pod-container/configmap/ui.properties

# Crie o ConfigMap

kubectl create configmap game-config --from-file=configure-pod-container/configmap/

O comando acima empacota cada arquivo, neste caso, game.properties e ui.properties no diretório configure-pod-container/configmap/ dentro do ConfigMap de nome game-config. Você pode exibir detalhes do ConfigMap usando o seguinte comando:

kubectl describe configmaps game-config

A saída é semelhante a esta:

Name:         game-config
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Os arquivos game.properties e ui.properties no diretório configure-pod-container/configmap/ estão representados na seção data do ConfigMap.

kubectl get configmaps game-config -o yaml

A saída é semelhante a esta:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:52:05Z
  name: game-config
  namespace: default
  resourceVersion: "516"
  uid: b4952dc3-d670-11e5-8cd0-68f728db1985
data:
  game.properties: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30    
  ui.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true
    how.nice.to.look=fairlyNice    

Crie um ConfigMap a partir de arquivos

Você pode usar kubectl create configmap para criar um ConfigMap a partir de um arquivo individual, ou a partir de múltiplos arquivos.

Por exemplo,

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties

Produziria o seguinte ConfigMap:

kubectl describe configmaps game-config-2

Onde a saída é semelhante a esta:

Name:         game-config-2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30

Você pode passar o argumento --from-file múltiplas vezes para criar um ConfigMap a partir de múltiplas fontes de dados.

kubectl create configmap game-config-2 --from-file=configure-pod-container/configmap/game.properties --from-file=configure-pod-container/configmap/ui.properties

Você pode exibir detalhes do ConfigMap game-config-2 usando o comando a seguir:

kubectl describe configmaps game-config-2

A saída é semelhante a esta:

Name:         game-config-2
Namespace:    default
Labels:       <none>
Annotations:  <none>

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
ui.properties:
----
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice

Quando o kubectl cria um ConfigMap a partir de entradas que não são ASCII ou UTF-8, a ferramenta os coloca no campo binaryData do ConfigMap, e não no campo data. Fontes de dados de texto e binário podem ser combinadas em um ConfigMap. Se você quiser ver o campo binaryData (e seus valores) em um ConfigMap, você pode executar kubectl get configmap -o jsonpath='{.binaryData}' <name>.

Use a opção --from-env-file para criar um ConfigMap a partir de um arquivo de ambiente, por exemplo:

# Os arquivos de ambiente contêm uma lista de variáveis de ambiente.
# Essas regras de sintaxe se aplicam:
#   Cada linha em um arquivo de ambiente deve estar em formato VAR=VAL.
#   Linhas começando com # (ex. comentários) são ignoradas.
#   Linhas em branco são ignoradas.
#   Não há manuseio especial de aspas (ex. eles farão parte dos valores do ConfigMap).

# Baixe os arquivos de amostra no diretório `configure-pod-container/configmap/`
wget https://kubernetes.io/examples/configmap/game-env-file.properties -O configure-pod-container/configmap/game-env-file.properties
wget https://kubernetes.io/examples/configmap/ui-env-file.properties -O configure-pod-container/configmap/ui-env-file.properties

# O arquivo de ambiente `game-env-file.properties` se parece como o abaixo
cat configure-pod-container/configmap/game-env-file.properties
enemies=aliens
lives=3
allowed="true"

# Este comentário e a linha vazia acima dela são ignorados
kubectl create configmap game-config-env-file \
       --from-env-file=configure-pod-container/configmap/game-env-file.properties

Produziria o seguinte ConfigMap:

kubectl get configmap game-config-env-file -o yaml

onde a saída é semelhante a esta:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2017-12-27T18:36:28Z
  name: game-config-env-file
  namespace: default
  resourceVersion: "809965"
  uid: d9d1ca5b-eb34-11e7-887b-42010a8002b8
data:
  allowed: '"true"'
  enemies: aliens
  lives: "3"

A partir do Kubernetes v1.23, o kubectl suporta múltiplas ocorrências do argumento --from-env-file para criar um ConfigMap para múltiplas fontes de dados.

kubectl create configmap config-multi-env-files \
        --from-env-file=configure-pod-container/configmap/game-env-file.properties \
        --from-env-file=configure-pod-container/configmap/ui-env-file.properties

Produziria o seguinte ConfigMap:

kubectl get configmap config-multi-env-files -o yaml

Onde a saída é semelhante a esta:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2017-12-27T18:38:34Z
  name: config-multi-env-files
  namespace: default
  resourceVersion: "810136"
  uid: 252c4572-eb35-11e7-887b-42010a8002b8
data:
  allowed: '"true"'
  color: purple
  enemies: aliens
  how: fairlyNice
  lives: "3"
  textmode: "true"

Defina a chave a ser usada ao criar um ConfigMap a partir de um arquivo

Você pode definir uma chave que não seja o nome do arquivo, para usar na seção data do seu ConfigMap quando usar o argumento --from-file:

kubectl create configmap game-config-3 --from-file=<my-key-name>=<path-to-file>

Onde <my-key-name> é a chave que você deseja usar no ConfigMap e <path-to-file> é a localização do arquivo fonte de dados, que você deseja que a chave represente.

Por exemplo:

kubectl create configmap game-config-3 --from-file=game-special-key=configure-pod-container/configmap/game.properties

Produziria o seguinte ConfigMap:

kubectl get configmaps game-config-3 -o yaml

Onde a saída é semelhante a esta:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T18:54:22Z
  name: game-config-3
  namespace: default
  resourceVersion: "530"
  uid: 05f8da22-d671-11e5-8cd0-68f728db1985
data:
  game-special-key: |
    enemies=aliens
    lives=3
    enemies.cheat=true
    enemies.cheat.level=noGoodRotten
    secret.code.passphrase=UUDDLRLRBABAS
    secret.code.allowed=true
    secret.code.lives=30    

Criando um ConfigMap a partir de valores literais

Você pode usar kubectl create configmap com o argumento --from-literal para definir um valor literal a partir da linha de comando:

kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm

Você pode passar vários pares de chave-valor. Cada par fornecido na linha de comando é representado como uma entrada separada na seção data do ConfigMap.

kubectl get configmaps special-config -o yaml

A saída é semelhante a esta:

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: special-config
  namespace: default
  resourceVersion: "651"
  uid: dadce046-d673-11e5-8cd0-68f728db1985
data:
  special.how: very
  special.type: charm

Crie um ConfigMap de um gerador

Você também pode criar um ConfigMap a partir de geradores e então aplicá-lo no cluster para criar objetos no servidor da API. Você deve especificar os geradores em um arquivo kustomization.yaml dentro de um diretório.

Gere o ConfigMap a partir de arquivos

Por exemplo, para gerar um ConfigMap a partir de arquivos configure-pod-container/configmap/game.properties

# Crie um arquivo kustomization.yaml com um ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-4
  files:
  - configure-pod-container/configmap/game.properties
EOF

Aplique o diretório de kustomization para criar o objeto ConfigMap.

kubectl apply -k .
configmap/game-config-4-m9dm2f92bt created

Você pode verificar se o ConfigMap foi criado, assim:

kubectl get configmap
NAME                       DATA   AGE
game-config-4-m9dm2f92bt   1      37s
kubectl describe configmaps/game-config-4-m9dm2f92bt
Name:         game-config-4-m9dm2f92bt
Namespace:    default
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"v1","data":{"game.properties":"enemies=aliens\nlives=3\nenemies.cheat=true\nenemies.cheat.level=noGoodRotten\nsecret.code.p...

Data
====
game.properties:
----
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
Events:  <none>

Observe que o nome gerado para o ConfigMap tem um sufixo anexado, que é o hash do conteúdo. Isso garante que um novo ConfigMap é gerado cada vez que o seu conteúdo é modificado.

Defina a chave a ser usada ao gerar um ConfigMap a partir de um arquivo

Você pode definir uma chave que não seja o nome do arquivo para usar no gerador do ConfigMap. Por exemplo, para gerar um ConfigMap a partir de arquivos configure-pod-container/configmap/game.properties com a chave game-special-key

# Criando um arquivo kustomization.yaml com o ConfigMapGenerator
cat <<EOF >./kustomization.yaml
configMapGenerator:
- name: game-config-5
  files:
  - game-special-key=configure-pod-container/configmap/game.properties
EOF

Aplicar o diretório kustomization para criar o objeto ConfigMap.

kubectl apply -k .
configmap/game-config-5-m67dt67794 created

Gere ConfigMap a partir de literais

Este exemplo mostra como criar um ConfigMap a partir de dois literais chave/valor: special.type=charm e special.how=very, usando Kustomize e kubectl. Para alcançar isso, você pode especificar o gerador ConfigMap. Crie (ou sobreponha) o arquivo kustomization.yaml para que ele tenha os seguintes conteúdos:

---
# Conteúdos de um aruivo kustomization.yaml para criar um ConfigMap a partir de literais
configMapGenerator:
- name: special-config-2
  literals:
  - special.how=very
  - special.type=charm

Aplique o diretório kustomization para criar o objeto ConfigMap.

kubectl apply -k .
configmap/special-config-2-c92b5mmcf2 created

Limpeza provisória

Antes de prosseguir, limpe alguns dos ConfigMaps que você fez:

kubectl delete configmap special-config
kubectl delete configmap env-config
kubectl delete configmap -l 'game-config in (config-4,config-5)

Agora que você aprendeu a definir ConfigMaps, você pode avançar na próxima seção, e aprender como usar esses objetos com Pods.

Definir variáveis de ambiente de contêineres usando dados ConfigMap

Defina uma variável de ambiente de contêiner com dados de um único ConfigMap

  1. Defina uma variável de ambiente como um par de chave-valor em um ConfigMap:

    kubectl create configmap special-config --from-literal=special.how=very
    
  2. Atribua o valor special.how definido no ConfigMap para a variável de ambiente SPECIAL_LEVEL_KEY na especificação do pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: registry.k8s.io/busybox
          command: [ "/bin/sh", "-c", "env" ]
          env:
            # Defina a variável de ambiente
            - name: SPECIAL_LEVEL_KEY
              valueFrom:
                configMapKeyRef:
                  # O ConfigMap contendo o valor que você deseja atribuir ao SPECIAL_LEVEL_KEY
                  name: special-config
                  # Especifique a chave associada ao valor
                  key: special.how
      restartPolicy: Never
    

    Crie o Pod:

    kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml
    

    Agora, a saída do Pod inclui a variável de ambiente SPECIAL_LEVEL_KEY=very.

Defina variáveis de ambiente de contêineres com dados de múltiplos mapas de configuração

  • Como no exemplo anterior, crie primeiro o ConfigMap.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: special-config
      namespace: default
    data:
      special.how: very
    ---
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: env-config
      namespace: default
    data:
      log_level: INFO
    

    Crie o ConfigMap:

    kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml
    
  • Defina as variáveis de ambiente na especificação do Pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: registry.k8s.io/busybox
          command: [ "/bin/sh", "-c", "env" ]
          env:
            - name: SPECIAL_LEVEL_KEY
              valueFrom:
                configMapKeyRef:
                  name: special-config
                  key: special.how
            - name: LOG_LEVEL
              valueFrom:
                configMapKeyRef:
                  name: env-config
                  key: log_level
      restartPolicy: Never
    

    Crie o Pod:

    kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml
    

    Agora, a saída do Pod inclui as variáveis de ambiente SPECIAL_LEVEL_KEY=very e LOG_LEVEL=INFO.

Configure todos os pares de chave-valor em um ConfigMap como variáveis de ambiente de contêineres

  • Criando um ConfigMap contendo vários pares de chave-valor.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: special-config
      namespace: default
    data:
      SPECIAL_LEVEL: very
      SPECIAL_TYPE: charm
    

    Crie o ConfigMap:

    kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml
    
  • Use envFrom para definir todos os dados do ConfigMap como variáveis de ambiente do contêiner. A chave do ConfigMap torna-se o nome da variável de ambiente no Pod.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dapi-test-pod
    spec:
      containers:
        - name: test-container
          image: registry.k8s.io/busybox
          command: [ "/bin/sh", "-c", "env" ]
          envFrom:
          - configMapRef:
              name: special-config
      restartPolicy: Never
    

    Crie o Pod:

    kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml
    

    Agora, a saída do Pod inclui as variáveis de ambiente SPECIAL_LEVEL=very e SPECIAL_TYPE=charm.

Use variáveis de ambiente definidas no ConfigMap em comandos do Pod

Você pode usar variáveis de ambiente definidas no ConfigMap no command e args de um contêiner usando a sintaxe de substituição do Kubernetes $(VAR_NAME).

Por exemplo, a seguinte especificação de Pod

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/echo", "$(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ]
      env:
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_LEVEL
        - name: SPECIAL_TYPE_KEY
          valueFrom:
            configMapKeyRef:
              name: special-config
              key: SPECIAL_TYPE
  restartPolicy: Never

criado pela execução

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valueFrom.yaml

produz a seguinte saída no contêiner test-container:

kubectl logs dapi-test-pod
very charm

Adicione dados do ConfigMap em um Volume

Conforme explicado Criando um ConfigMap a partir de arquivos, quando você cria um ConfigMap usando --from-file, o nome do arquivo se torna uma chave armazenada na seção data do ConfigMap. O conteúdo do arquivo se torna o valor da chave.

Os exemplos nesta seção se referem a um ConfigMap de nome' special-config, mostrado abaixo.

apiVersion: v1
kind: ConfigMap
metadata:
  name: special-config
  namespace: default
data:
  SPECIAL_LEVEL: very
  SPECIAL_TYPE: charm

Crie o ConfigMap:

kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml

Preencher um volume com dados armazenados em um ConfigMap

Adicione o nome do ConfigMap debaixo da seção volumes das especificações do Pod. Isso adiciona os dados do ConfigMap ao diretório especificado como volumeMounts.mountPath (nesse caso, /etc/config). A seção command lista arquivos do diretório com nomes que correspondem às chaves no ConfigMap.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh", "-c", "ls /etc/config/" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        # Forneça o nome do ConfigMap que contém os arquivos 
        # que você deseja adicionar ao contêiner
        name: special-config
  restartPolicy: Never

Crie o Pod:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml

Quando o Pod executa, o comando ls /etc/config/ produz a saída abaixo:

SPECIAL_LEVEL
SPECIAL_TYPE

Adicione dados ConfigMap para um caminho específico no volume

Use o campo path para especificar o caminho de arquivo desejado para ítens específicos do ConfigMap. Nesse caso, o item SPECIAL_LEVEL será montado no volume config-volume em /etc/config/keys.

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: registry.k8s.io/busybox
      command: [ "/bin/sh","-c","cat /etc/config/keys" ]
      volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: special-config
        items:
        - key: SPECIAL_LEVEL
          path: keys
  restartPolicy: Never

Crie o Pod:

kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-specific-key.yaml

Quando o Pod executar, o comando cat /etc/config/keys produz a saída abaixo:

very

Projete chaves para caminhos específicos e permissões de arquivos

Você pode projetar chaves para caminhos específicos e permissões específicas em uma base por-arquivo. O guia do usuário Segredos explica a sintaxe.

Referências Opcionais

Uma referência de ConfigMap pode ser marcada opcional. Se o ConfigMap for inexistente, o volume montado estará vazio. Se o ConfigMap existir, mas a chave referenciada é inexistente, o caminho estará ausente no ponto de montagem.

ConfigMaps montados são atualizados automaticamente

Quando um ConfigMap montado é atualizado, o conteúdo projetado é eventualmente atualizado também. Isso se aplica no caso em que um ConfigMap referenciado opcionalmente passe a existir após o Pod ser iniciado.

O Kubelet verifica se o ConfigMap montado está atualizado em cada sincronização periódica. No entanto, ele usa seu cache local baseado em TTL para obter o valor atual do ConfigMap. Como resultado, o atraso total, desde o momento em que o ConfigMap foi atualizado até o momento em que novas chaves são projetadas para o pod, pode ser tão longo quanto o período de sincronização do Kubelet (1 minuto por padrão) + TTL de cache do ConfigMap (1 minuto por padrão) no kubelet.

Compreendendo ConfigMap e Pods

O recurso da API ConfigMap armazena dados de configuração como pares de chave-valor. Os dados podem ser consumidos em Pods, ou fornecidos para componentes do sistema, como controladores. O ConfigMap é similar ao Secret, mas fornece um meio de trabalhar com strings que não contêm informações confidenciais. Usuários e componentes do sistema podem armazenar dados de configuração em ConfigMaps.

O campo data do ConfigMap contém os dados de configuração. Como mostrado no exemplo abaixo, estes podem ser simples (como propriedades individuais definidas usando --from-literal) ou complexos (como arquivos de configuração ou blobs JSON definidos usando --from-file).

apiVersion: v1
kind: ConfigMap
metadata:
  creationTimestamp: 2016-02-18T19:14:38Z
  name: example-config
  namespace: default
data:
  # exemplo de uma propriedade simples definida usando --from-literal
  example.property.1: hello
  example.property.2: world
  # exemplo de uma propriedade complexa definida usando --from-file
  example.property.file: |-
    property.1=value-1
    property.2=value-2
    property.3=value-3    

Restrições

  • Você deve criar um ConfigMap antes de referenciá-lo em uma especificação de Pod (a menos que você marque o ConfigMap como optional). Se você referenciar um ConfigMap que não existe, O Pod não vai iniciar. Da mesma forma, referências a chaves que não existem no ConfigMap impedirão o Pod de iniciar.

  • Se você usar envFrom para definir variáveis de ambiente do ConfigMap, chaves que são consideradas inválidas serão ignoradas. O Pod poderá iniciar, mas os nomes inválidos serão registrados no log de eventos (InvalidVariableNames). A mensagem de log lista cada chave ignorada. Por exemplo:

    kubectl get events
    

    A saída é semelhante a esta:

    LASTSEEN FIRSTSEEN COUNT NAME          KIND  SUBOBJECT  TYPE      REASON                            SOURCE                MESSAGE
    0s       0s        1     dapi-test-pod Pod              Warning   InvalidEnvironmentVariableNames   {kubelet, 127.0.0.1}  Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names.
    
  • O ConfigMap reside em um Namespace específico. Um ConfigMap só pode ser referenciado por Pods residentes no mesmo namespace.

  • Você não pode usar um ConfigMap para Pods estáticos, porque o kubelet não oferece suporte a isso.

Próximos passos

3.9 - Compartilhando o Namespace de Processo Entre Contêineres em um Pod

Esta página mostra como configurar o compartilhamento de namespace de processos para um Pod. Quando O compartilhamento de namespace de processos está ativado, os processos em um Contêiner são visíveis para todos os outros Contêineres no mesmo Pod.

Você pode usar este recurso para configurar Contêineres de cooperação, como um manipulador de log sidecar de contêiner, ou para solucionar problemas em imagens de contêiner que não incluem utilitários de depuração como um shell.

Antes de você começar

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:

Configure um pod

O compartilhamento de namespace de processos é ativado usando o campo shareProcessNamespace da .spec para um Pod. Por exemplo:

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
  - name: shell
    image: busybox:1.28
    securityContext:
      capabilities:
        add:
        - SYS_PTRACE
    stdin: true
    tty: true
  1. Crie o pod nginx no seu cluster:

    kubectl apply -f https://k8s.io/examples/pods/share-process-namespace.yaml
    
  2. Conecte ao shell do contêiner e execute o comando ps:

    kubectl attach -it nginx -c shell
    

    Se você não vir um prompt de comando, tente pressionar Enter. No shell do Contêiner execute:

    # execute este comando dentro do "shell" do contêiner
    ps ax
    

    A saída é semelhante a esta:

    PID   USER     TIME  COMMAND
        1 root      0:00 /pause
        8 root      0:00 nginx: master process nginx -g daemon off;
       14 101       0:00 nginx: worker process
       15 root      0:00 sh
       21 root      0:00 ps ax
    

Você pode sinalizar processos em outros Contêineres. Por exemplo, mandando SIGHUP ao nginx para restartar o processo worker. Isso requer a capacidade SYS_PTRACE.

# execute este comando dentro do "shell" do contêiner
kill -HUP 8   # substitua o "8" pelo PID do processo principal do nginx, se necessário
ps ax

A saída é semelhante a esta:

PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    8 root      0:00 nginx: master process nginx -g daemon off;
   15 root      0:00 sh
   22 101       0:00 nginx: worker process
   23 root      0:00 ps ax

É até possível acessar o sistema de arquivos de outro contêiner usando o link /proc/$pid/root.

# execute este comando dentro do "shell" do contêiner
# substitua o "8" pelo PID do processo Nginx, se necessario
head /proc/8/root/etc/nginx/nginx.conf

A saída é semelhante a esta:

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;


events {
    worker_connections  1024;

Compreendendo o compartilhamento de namespace de processos

Os Pods compartilham muitos recursos, por isso faz sentido que eles também compartilhem um namespace de processo. Alguns Contêineres podem esperar serem isolados de outros, no entanto, por isso, é importante entender as diferenças:

  1. O processo de contêiner não tem mais o PID 1. Alguns Contêineres recusam começar sem o PID 1 (por exemplo, contêineres usando systemd) ou executando comandos como kill -HUP 1 para sinalizar o processo de Contêiner. Em pods com um namespace de processos compartilhado, kill -HUP 1 irá sinalizar a sandbox (/pause no exemplo acima).

  2. Os processos são visíveis para outros contêineres no Pod. Isso inclui todas informações visíveis em /proc, como senhas que foram passadas como argumentos ou variáveis de ambiente. Estes são protegidos apenas por permissões regulares do Unix.

  3. Sistema de arquivos do Contêiner são visíveis para outros Contêineres do pod através do link /proc/$pid/root. Isso facilita a depuração, mas também significa que os segredos do sistema de arquivos, são protegidos apenas por permissões de sistema de arquivos.

3.10 - Criando Pods Estáticos

Pods Estáticos são gerenciados diretamente pelo daemon kubelet em um nó específico, sem o servidor de API observando-os. Ao contrário dos pods que são gerenciados pelo Control Plane (por exemplo, uma Implantação); em vez disso, o kubelet observa cada Pod estático (e reinicia-os se falharem).

Pods estáticos estão sempre ligados a um Kubelet em um nó específico.

O Kubelet tenta automaticamente criar um mirror Pod no servidor de API do Kubernetes para cada Pod estático. Isso significa que os pods em execução em um nó são visíveis no servidor de API, mas não podem ser controlados a partir daí. Aos nomes de Pods será sufixados com o nome de host do nó, com um hífem a esquerda.

Antes de você começar

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, digite kubectl version.

Esta página assume que você está usando um CRI-O para executar os Pods, e que seus nós estão executando o sistema operacional Fedora. Instruções para outras distribuições, ou instalações de Kubernetes, podem variar.

Crie um pod estático

Você pode configurar um Pod estático com um arquivo de configuração hospedado no sistema de arquivos ou um arquivo de configuração hospedado na Web.

Manifesto do Pod estático hospedado no sistema de arquivos

Os manifestos, são definições de Pod padrão em formato JSON ou YAML em um diretório específico. Use o campo staticPodPath: <diretório> no arquivo de configuração do kubelet, que periodicamente varre o diretório e cria/exclui Pods estáticos conforme os arquivos YAML/JSON aparecem/desaparecem. Observe que o Kubelet ignorará os arquivos começando com pontos ao varrer o diretório especificado.

Por exemplo, como iniciar um servidor Web simples como um Pod estático

  1. Escolha um nó onde você deseja executar um Pod estático. Neste exemplo, é my-node1.

    ssh my-node1
    
  2. Escolha um diretório, digamos /etc/kubernetes/manifests e coloque uma definição de pod para um servidor web lá, por exemplo /etc/kubernetes/manifests/static-web.yaml:

    # Execute este comando no nó onde o Kubelet está funcionando
    mkdir -p /etc/kubernetes/manifests/
    cat <<EOF >/etc/kubernetes/manifests/static-web.yaml
    apiVersion: v1
    kind: Pod
    metadata:
      name: static-web
      labels:
        role: myrole
    spec:
      containers:
        - name: web
          image: nginx
          ports:
            - name: web
              containerPort: 80
              protocol: TCP
    EOF
    
  3. Configure seu kubelet no nó para usar este diretório executando-o com o argumento --pod-manifest-path=/etc/kubernetes/manifests/. No Fedora, edite o arquivo /etc/kubernetes/kubelet para incluir esta linha:

    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubernetes/manifests/"
    

    ou adicione o campo staticPodPath: <o diretótio> no arquivo de configuração do kubelet.

  4. Reinicie o kubelet. No Fedora, você poderia executar:

    # Execute este comando no nó onde o kubelet está funcionando
    systemctl restart kubelet
    

Manifesto do Pod estático hospedado na Web

O Kubelet baixa periodicamente um arquivo especificado pelo argumento --manifest-url=<URL> e interpreta-o como um arquivo JSON/YAML que contém as definições do Pod. Similar ao que manifestos hospedados no sistema de arquivos fazem, o kubelet reexamina o manifesto em um agendamento. Se houver alterações na lista de Pods estáticos, o kubelet aplica-os.

Para usar esta abordagem:

  1. Crie um arquivo YAML e armazene-o em um servidor da Web, para que você possa passar o URL desse arquivo para o Kubelet.

    apiVersion: v1
    kind: Pod
    metadata:
      name: static-web
      labels:
        role: myrole
    spec:
      containers:
        - name: web
          image: nginx
          ports:
            - name: web
              containerPort: 80
              protocol: TCP
    
  2. Configure o kubelet no seu nó selecionado para usar este manifesto da Web, executando-o com --manifest-url=<manifest-url>. No Fedora, edite /etc/kubernetes/kubelet para incluir esta linha:

    KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --manifest-url=<manifest-url>"
    
  3. Reinicie o Kubelet. No Fedora, você usaria:

    # Execute este comando no nó onde o kubelet está funcionando
    systemctl restart kubelet
    

Observe o comportamento do Pod estático

Quando o kubelet começa, inicia automaticamente todos os pods estáticos definidos. Como você definiu um Pod estático e reiniciou o kubelet, o novo pod estático deveria já estar em execução.

Você pode ver os Contêineres em execução (incluindo os Pods estáticos) ao executar (no Nó):

# Execute este comando no nó onde o kubelet está funcionando
crictl ps

A saída pode ser algo como:

CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
129fd7d382018   docker.io/library/nginx@sha256:...    11 minutes ago    Running    web     0          34533c6729106

Você pode ver o Pod espelho no servidor de API:

kubectl get pods
NAME         READY   STATUS    RESTARTS        AGE
static-web   1/1     Running   0               2m

Os Rótulos dos pods estáticos são propagados no Pod espelho. Você pode usar esses rótulos como seletores via normal, etc.

Se você tentar usar o kubectl para excluir o Pod espelho do servidor de API, o kubelet não remove o Pod estático:

kubectl delete pod static-web
pod "static-web" deleted

Você pode ver que o Pod ainda está funcionando:

kubectl get pods
NAME         READY   STATUS    RESTARTS   AGE
static-web   1/1     Running   0          4s

De volta ao seu nó, onde o kubelet está funcionando, você pode tentar parar o Contêiner manualmente. Você verá que, depois de algum tempo, o Kubelet notará e reiniciará o Pod automaticamente:

# Execute esses comandos no nó onde o Kubelet está funcionando
crictl stop 129fd7d382018 # substitua pelo ID do seu contêiner
sleep 20
crictl ps
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
89db4553e1eeb   docker.io/library/nginx@sha256:...    19 seconds ago    Running    web     1          34533c6729106

Adição e remoção dinâmica de Pods estáticos

O Kubelet em execução varre periodicamente o diretório configurado (/etc/kubernetes/manifests em nosso exemplo) por alterações, e adiciona/remove os pods à medida que os arquivos aparecem/desaparecem neste diretório.

# Pressupondo que você esteja usando a configuração de Pod estático hospedada no sistema de arquivos
# Execute esses comandos no nó onde o Kubelet está funcionando
#
mv /etc/kubelet.d/static-web.yaml /tmp
sleep 20
crictl ps
# Você vê que nenhum contêiner nginx está funcionando
#
mv /tmp/static-web.yaml  /etc/kubelet.d/
sleep 20
crictl ps
CONTAINER       IMAGE                                 CREATED           STATE      NAME    ATTEMPT    POD ID
f427638871c35   docker.io/library/nginx@sha256:...    19 seconds ago    Running    web     1          34533c6729106

3.11 - Aplicando os Padrões de Segurança do Pod Através da Configuração do Controlador de Admissão Embutido

O Kubernetes fornece um controlador de admissão embutido para garantir os padrões de segurança do Pod. Você pode configurar esse controlador de admissão para definir padrões e isenções em todo o cluster.

Antes de você começar

Após uma release alfa no Kubernetes v1.22, o controlador de admissão Pod Security Admission tornou-se disponível por padrão no Kubernetes v1.23, no estado beta. Da versão 1.25 em diante o controlador de admissão Pod Security Admission está publicamente disponível.

Para verificar a versão, digite kubectl version.

Se você não estiver utilizando o Kubernetes 1.30, você pode verificar a documentação da versão do Kubernetes que você está utilizando.

Configure o Controlador de Admissão

apiVersion: apiserver.config.k8s.io/v1 # veja a nota de compatibilidade
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    # Padrões aplicados quando o label de modo não é especificado.
    #
    # O valor para o label Level deve ser uma das opções abaixo:
    # - "privileged" (padrão)
    # - "baseline"
    # - "restricted"
    #
    # O valor para o label Version deve ser uma das opções abaixo:
    # - "latest" (padrão)
    # - versão específica no formato "v1.30"
    defaults:
      enforce: "privileged"
      enforce-version: "latest"
      audit: "privileged"
      audit-version: "latest"
      warn: "privileged"
      warn-version: "latest"
    exemptions:
      # Lista de usuários autenticados a eximir.
      usernames: []
      # Lista de RuntimeClasses a eximir.
      runtimeClasses: []
      # Lista de namespaces a eximir.
      namespaces: []

3.12 - Aplicando Padrões de Segurança de Pod com `Labels` em Namespace

Os namespaces podem ser rotulados para aplicar os Padrões de segurança de pod. As três políticas privilegiado, linha de base e restrito cobrem amplamente o espectro de segurança e são implementados pela segurança de Pod controlador de admissão.

Antes de você começar

O seu servidor Kubernetes deve estar numa versão igual ou superior a v1.22. Para verificar a versão, digite kubectl version.

Exigindo o padrão de segurança baseline de pod com rótulos em namespace

Este manifesto define um Namespace my-baseline-namespace que:

  • Bloqueia quaisquer Pods que não satisfazem os requisitos da política baseline.
  • Gera um aviso para o usuário e adiciona uma anotação de auditoria, a qualquer pod criado que não satisfaça os requisitos da política restricted.
  • Fixa as versões das políticas baseline e restricted à v1.30.
apiVersion: v1
kind: Namespace
metadata:
  name: my-baseline-namespace
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.30

    # Estamos definindo-os para o nosso nível _desejado_  `enforce`.
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.30
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.30

Adicionar Rótulos aos Namespaces Existentes com kubectl label

É útil aplicar a flag --dry-run ao avaliar inicialmente as alterações do perfil de segurança para namespaces. As verificações padrão de segurança do pod ainda serão executadas em modo dry run, dando-lhe informações sobre como a nova política trataria os pods existentes, sem realmente atualizar a política.

kubectl label --dry-run=server --overwrite ns --all \
    pod-security.kubernetes.io/enforce=baseline

Aplicando a todos os namespaces

Se você está apenas começando com os padrões de segurança de pod, um primeiro passo adequado seria configurar todos namespaces com anotações de auditoria para um nível mais rigoroso, como baseline:

kubectl label --overwrite ns --all \
  pod-security.kubernetes.io/audit=baseline \
  pod-security.kubernetes.io/warn=baseline

Observe que isso não está aplicando as definições de nível, para que os namespaces que não foram explicitamente avaliados possam ser distinguidos. Você pode listar os namespaces sem um nível aplicado, explicitamente definido, usando este comando:

kubectl get namespaces --selector='!pod-security.kubernetes.io/enforce'

Aplicando a um único namespace

Você pode atualizar um namespace específico também. Este comando adiciona a política enforce=restricted ao my-existing-namespace, fixando a política que restringe à versão v1.30.

kubectl label --overwrite ns my-existing-namespace \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=v1.30

4 - Utilize o Cilium para NetworkPolicy

Essa página mostra como utilizar o Cilium para NetworkPolicy.

Para saber mais sobre o Cilium, leia o artigo Introdução ao Cilium (em inglês).

Antes de você começar

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, digite kubectl version.

Fazendo o Deploy do Cilium no Minikube para Testes Básicos

Para familiarizar-se com o Cilium você poderá seguir o guia Guia de Primeiros Passos do Cilium no Kubernetes (em inglês) e realizar uma instalação básica do Cilium através de um DaemonSet no minikube.

Inicie o minikube, a versão mínima exigida é >= v1.5.2, com os seguintes argumentos:

minikube version
minikube version: v1.5.2
minikube start --network-plugin=cni

Para o minikube, você poderá instalar o Cilium utilizando a ferramenta de linha de comando (CLI). Para isso, primeiro faça o download da última versão do CLI com o seguinte comando:

curl -LO https://github.com/cilium/cilium-cli/releases/latest/download/cilium-linux-amd64.tar.gz

Em seguida extraia o arquivo baixado para o diretório /usr/local/bin com os comandos:

sudo tar xzvfC cilium-linux-amd64.tar.gz /usr/local/bin
rm cilium-linux-amd64.tar.gz

Após executar os passos acima, você poderá instalar o Cilium utilizando o comando abaixo:

cilium install

O Cilium irá detectar as configurações do cluster automaticamente, criará e instalará os componentes apropriados para que a instalação seja bem sucedida. Os componentes são:

  • Certificate Authority (CA) no Secret cilium-ca e os certificados para o Hubble (camada de observabilidade do Cilium).
  • Service accounts.
  • Cluster roles.
  • ConfigMap.
  • Um agente DaemonSet e um Operator Deployment.

Após a instalação, você poderá visualizar o status geral do Deployment do Cilium com o comando cilium status. Confira a saída esperada da opção status aqui.

O restante do guia de primeiros passos utiliza como base uma aplicação de exemplo para explicar como aplicar políticas de segurança tanto para L3/L4 (como endereço de IP + porta), quanto para L7 (como HTTP).

Fazendo o deploy do Cilium para uso em produção

Para instruções detalhadas de como fazer o deploy do Cilium em produção, acesse: Guia de Instalação do Cilium no Kubernetes (em inglês).

Essa documentação inclui detalhes sobre os requisitos, instruções e exemplos de DaemonSet para produção.

Entendendo os componentes do Cilium

Ao realizar o deploy do Cilium no cluster, Pods são adicionados ao namespace kube-system. Para ver essa lista de Pods execute:

kubectl get pods --namespace=kube-system -l k8s-app=cilium

Você verá uma lista de Pods similar a essa:

NAME           READY   STATUS    RESTARTS   AGE
cilium-kkdhz   1/1     Running   0          3m23s
...

Um Pod cilium roda em cada um dos nós do seu cluster e garante as políticas de rede no tráfego de/para Pods naquele nó usando o Linux BPF.

Próximos passos

Uma vez que seu cluster estiver rodando, você pode seguir o artigo Declarar uma Network Policy (em inglês) para testar as políticas de NetworkPolicy do Kubernetes com o Cilium. Divirta-se! Se tiver dúvidas, nos contate usando o Canal Slack do Cilium.

5 - Depurando Contêineres de Inicialização

Esta página mostra como investigar problemas relacionados à execução de contêineres de inicialização. As linhas de comando de exemplo abaixo referem-se ao pod como <pod-name> e aos contêineres de inicialização como <init-container-1> e <init-container-2>.

Antes de você começar

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, digite kubectl version.

Verificando o status dos contêineres de inicialização

Exiba o status do seu pod:

kubectl get pod <pod-name>

Por exemplo, um status de Init:1/2 indica que uma das duas inicializações de contêineres concluíram com sucesso:

NAME         READY     STATUS     RESTARTS   AGE
<pod-name>   0/1       Init:1/2   0          7s

Consulte Entendendo sobre o status do pod para obter mais exemplos de valores de status e seus significados.

Obtendo detalhes sobre os contêineres de inicialização

Veja informações mais detalhadas sobre a execução de contêineres de inicialização:

kubectl describe pod <pod-name>

Por exemplo, um pod com dois contêineres de inicialização pode mostrar o seguinte:

Init Containers:
  <init-container-1>:
    Container ID:    ...
    ...
    State:           Terminated
      Reason:        Completed
      Exit Code:     0
      Started:       ...
      Finished:      ...
    Ready:           True
    Restart Count:   0
    ...
  <init-container-2>:
    Container ID:    ...
    ...
    State:           Waiting
      Reason:        CrashLoopBackOff
    Last State:      Terminated
      Reason:        Error
      Exit Code:     1
      Started:       ...
      Finished:      ...
    Ready:           False
    Restart Count:   3
    ...

Você também pode acessar programaticamente os status dos contêineres de inicialização, lendo o campo status.initContainerStatuses nas especificações do pod:

kubectl get pod nginx --template '{{.status.initContainerStatuses}}'

Este comando retornará as mesmas informações acima em JSON bruto.

Acessando logs de contêineres de inicialização

Passe o nome do contêiner de inicialização junto com o nome do Pod para acessar seus logs.

kubectl logs <pod-name> -c <init-container-2>

Contêineres de inicialização que executam comandos de script de shell imprimem à medida que são executados. Por exemplo, você pode fazer isso no Bash executando set -x no início do script.

Entendendo sobre o status do pod

Um status do Pod começando com Init: resume o status da execução de contêineres de inicialização. A tabela abaixo descreve alguns valores de status de exemplo que você pode ver durante a depuração de contêineres de inicialização.

Status Significado
Init:N/M O pod tem contêineres de inicialização M e N que foram concluídas até agora.
Init:Error Um contêiner de inicialização falhou ao executar.
Init:CrashLoopBackOff Um contêiner de inicialização falhou repetidamente.
Pending O pod ainda não começou a executar o contêiner de inicialização.
PodInitializing ou Running O pod já concluiu a execução dos contêineres de inicialização.

6 - Acessando Aplicações em um Cluster

Configurar balanceamento de carga, redirecionamento de porta, ou configuração de firewall ou DNS para acessar aplicativos em um cluster.

6.1 - Acessando clusters

Esse tópico fala sobre diversas maneiras de interagir com clusters.

Acessando pela primeira vez com kubectl

Se estiver acessando o Kubernetes API pela primeira vez, recomendamos usar a CLI do Kubernetes, kubectl.

Para acessar um cluster, você precisa saber a localização do cluster e ter credenciais para acessá-lo. Geralmente, isso é configurado automaticamente quando você trabalha com um Guia de instalação ou outra pessoa configurou o cluster e forneceu a você credenciais e uma localização.

Verifique o local e as credenciais que o kubectl conhece com esse comando:

kubectl config view

Muitos dos exemplos fornecem uma introdução ao uso do kubectl e a documentação completa pode ser encontrada no guia de referência do kubectl.

Acessando diretamente a API REST

O Kubectl lida com a localização e a autenticação no servidor de API. Se você quiser acessar diretamente a API REST com um cliente http como curl ou wget, ou um navegador, há várias maneiras de localizar e autenticar:

  • Executar o kubectl no modo proxy.
    • Método recomendado.
    • Usa a localização previamente armazenada do servidor da API.
    • Verifica a identidade do apiserver usando um certificado autoassinado. Não há possibilidade de ataque MITM (Man-In-The-Middle).
    • Autentica-se no servidor da API.
    • No futuro, poderá fazer balanceamento de carga inteligente no lado do cliente, e transferência em caso de falha.
  • Forneça o local e as credenciais diretamente para o cliente http.
    • Método alternativo.
    • Funciona com alguns tipos de código de cliente que são confundidos pelo uso de um proxy.
    • É necessário importar um certificado raiz em seu navegador para se proteger contra ataque MITM (Man-In-The-Middle).

Usando o kubectl proxy

O comando a seguir executa o kubectl em um modo em que ele atua como um proxy reverso. Ele lida com localização do apiserver e da autenticação. Execute-o desta forma:

kubectl proxy --port=8080

Consulte kubectl proxy para obter mais detalhes.

Em seguida, você pode explorar a API com curl, wget ou um navegador, substituindo localhost por [::1] para IPv6, da seguinte forma:

curl http://localhost:8080/api/

O resultado é semelhante a este:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Sem kubectl proxy

Use kubectl apply e kubectl describe secret... para criar um token para a conta de serviço padrão com grep/cut:

Primeiro, crie o Secret, solicitando um token para a ServiceAccount padrão:

kubectl apply -f - <<EOF
apiVersion: v1
kind: Secret
metadata:
  name: default-token
  annotations:
    kubernetes.io/service-account.name: default
type: kubernetes.io/service-account-token
EOF

Em seguida, aguarde até que o controlador de token preencha o Secret com um token:

while ! kubectl describe secret default-token | grep -E '^token' >/dev/null; do
  echo "waiting for token..." >&2
  sleep 1
done

Recupere e use o token gerado:

APISERVER=$(kubectl config view --minify | grep server | cut -f 2- -d ":" | tr -d " ")
TOKEN=$(kubectl describe secret default-token | grep -E '^token' | cut -f2 -d':' | tr -d " ")

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

O resultado é semelhante a este:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Usando jsonpath:

APISERVER=$(kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}')
TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)

curl $APISERVER/api --header "Authorization: Bearer $TOKEN" --insecure

O resultado é semelhante a este:

{
  "kind": "APIVersions",
  "versions": [
    "v1"
  ],
  "serverAddressByClientCIDRs": [
    {
      "clientCIDR": "0.0.0.0/0",
      "serverAddress": "10.0.1.149:443"
    }
  ]
}

Os exemplos acima usam a opção --insecure. Isso deixa o cluster sujeito a ataques MITM. Quando o kubectl acessa o cluster, ele usa um certificado raiz guardado e certificados de cliente para acessar o servidor. (Esses certificados são instalados no diretório ~/.kube). Como os certificados do cluster normalmente são autoassinados, pode ser necessária uma configuração especial para que seu cliente http use o certificado raiz.

Em alguns clusters, o servidor da API não requer autenticação; ele pode servir no localhost ou estar protegido por um firewall. Não há um padrão para isso. A página Controlando Acesso à API do Kubernetes
descreve como um administrador de cluster pode configurar isso.

Acesso programático à API

O Kubernetes suporta oficialmente as bibliotecas de clientes Go e Python.

Cliente Go

  • Para obter a biblioteca, execute o seguinte comando: go get k8s.io/client-go@kubernetes-<kubernetes-version-number>, consulte INSTALL.md para obter instruções detalhadas de instalação. Consulte https://github.com/kubernetes/client-go para ver quais versões são compatíveis.
  • Escreva um aplicativo utilizando o cliente Go. Observe que ela define seus próprios objetos de API, portanto, se necessário, importe as definições de API do cliente Go em vez de importá-las do repositório principal. Por exemplo, import "k8s.io/client-go/kubernetes" está correto.

O cliente Go pode usar o mesmo arquivo kubeconfig como a CLI do kubectl faz, para localizar e autenticar ao apiserver. Veja esse exemplo.

Se o aplicativo for disponibilizado como um pod no cluster, consulte a próxima seção.

Cliente Python

Para usar o cliente Python, execute o seguinte comando: pip install kubernetes. Consulte a página Python Client Library para obter mais opções de instalação.

O cliente Python pode usar o mesmo arquivo kubeconfig que a ferramenta kubectl utiliza para localizar e autenticar ao servidor da API. Veja esse exemplo.

Outras bibliotecas

Existem bibliotecas de clientes para acessar a API utilizando outras linguagens. Consulte a documentação de outras bibliotecas para saber como elas se autenticam.

Acessando a API a partir de um pod

Ao acessar a API a partir de um pod, a localização e a autenticação para o servidor de API são um pouco diferentes.

Consulte Acessando a API a partir de um pod para obter mais detalhes.

Acessando serviços em execução no cluster

A seção anterior descreve como se conectar ao servidor da API do Kubernetes. Para obter informações sobre como se conectar a outros serviços em execução em um cluster do Kubernetes, consulte Acessando serviços em execução em clusters.

Solicitação de redirecionamentos

Os recursos de redirecionamento foram descontinuados e removidos. Em vez disso, use um proxy (veja abaixo).

Tantos proxies

Há vários proxies diferentes que você pode encontrar ao usar o Kubernetes:

  1. O kubectl proxy:

    • é executado no computador de um usuário ou em um pod
    • cria um proxy de um endereço localhost para o servidor da API do Kubernetes
    • a conexão do cliente para o proxy usa HTTP
    • a conexão do proxy para o servidor da API usa HTTPS
    • localiza o apiserver
    • adiciona cabeçalhos de autenticação
  2. O proxy do servidor da API:

    • é um bastião incorporado ao apiserver
    • conecta um usuário fora do cluster aos IPs do cluster que, de outra forma, poderiam não ser acessíveis
    • é executado no processo do servidor da API
    • cliente para proxy usa HTTPS (ou http se o servidor da API estiver configurado dessa forma)
    • a conexão do proxy para o destino pode usar HTTP ou HTTPS, conforme escolhido pelo proxy usando as informações disponíveis
    • pode ser usado para acessar um Nó, Pod ou Serviço
    • faz o balanceamento de carga quando usado para acessar um serviço
  3. O kube proxy:

    • é executado em cada nó
    • proxy de UDP e TCP
    • não entende HTTP
    • fornece balanceamento de carga
    • é usado apenas para acessar serviços
  4. Um Proxy/balanceador de carga na frente do(s) servidor(es) da API:

    • a existência e a implementação variam de cluster para cluster (por exemplo, nginx)
    • fica entre todos os clientes e um ou mais servidores da API
    • atua como um balanceador de carga se houver vários servidores da API.
  5. Balanceadores de carga de provedor de nuvem em serviços externos:

    • são fornecidos por alguns provedores de nuvem computacional (por exemplo, AWS ELB, Google Cloud Load Balancer)
    • são criados automaticamente quando o serviço Kubernetes tem o tipo LoadBalancer
    • usam somente UDP/TCP
    • a implementação varia de acordo com o provedor de nuvem.

Normalmente, os usuários do Kubernetes não precisam se preocupar com nada além dos dois primeiros tipos. O administrador do cluster normalmente garantirá que os últimos tipos sejam configurados corretamente.

6.2 - Configurar o acesso a múltiplos clusters

Esta página mostra como configurar o acesso a vários clusters usando arquivos de configuração. Depois que os clusters, os usuários e os contextos forem definidos em um ou mais arquivos de configuração, você pode alternar rapidamente entre os clusters usando o comando kubectl config use-context.

Antes de você começar

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 se kubectl está instalado, execute kubectl version --client. A versão do kubectl deve ter no máximo uma versão menor de diferença da versão do servidor de API do seu cluster.

Defina clusters, usuários e contextos

Suponha que você tenha dois clusters, um para o trabalho de desenvolvimento, chamado development, e outro para o trabalho de teste, chamado test. No cluster development, seus desenvolvedores de front-end trabalham em um namespace chamado frontend, e os desenvolvedores de armazenamento trabalham em um namespace chamado storage. Em seu cluster test, os desenvolvedores trabalham no namespace padrão ou criam namespaces auxiliares conforme acharem adequado. O acesso ao cluster de desenvolvimento requer autenticação por certificado. O acesso ao cluster de teste requer autenticação por nome de usuário e senha.

Crie um diretório chamado config-exercise. Em seu diretório config-exercise, crie um arquivo chamado config-demo com este conteúdo:

apiVersion: v1
kind: Config
preferences: {}

clusters:
- cluster:
  name: development
- cluster:
  name: test

users:
- name: developer
- name: experimenter

contexts:
- context:
  name: dev-frontend
- context:
  name: dev-storage
- context:
  name: exp-test

Um arquivo de configuração descreve clusters, usuários e contextos. Seu arquivo config-demo tem a estrutura para descrever dois clusters, dois usuários e três contextos.

Vá para o diretório config-exercise. Digite estes comandos para adicionar detalhes do cluster ao seu arquivo de configuração:

kubectl config --kubeconfig=config-demo set-cluster development --server=https://1.2.3.4 --certificate-authority=fake-ca-file
kubectl config --kubeconfig=config-demo set-cluster test --server=https://5.6.7.8 --insecure-skip-tls-verify

Adicione detalhes do usuário ao seu arquivo de configuração:

kubectl config --kubeconfig=config-demo set-credentials developer --client-certificate=fake-cert-file --client-key=fake-key-seefile
kubectl config --kubeconfig=config-demo set-credentials experimenter --username=exp --password=some-password

Adicione detalhes de contexto ao seu arquivo de configuração:

kubectl config --kubeconfig=config-demo set-context dev-frontend --cluster=development --namespace=frontend --user=developer
kubectl config --kubeconfig=config-demo set-context dev-storage --cluster=development --namespace=storage --user=developer
kubectl config --kubeconfig=config-demo set-context exp-test --cluster=test --namespace=default --user=experimenter

Abra seu arquivo config-demo para ver os detalhes adicionados. Como alternativa para abrir o arquivo config-demo, você pode usar o comando config view

kubectl config --kubeconfig=config-demo view

O resultado mostra os dois clusters, dois usuários e três contextos:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
- cluster:
    insecure-skip-tls-verify: true
    server: https://5.6.7.8
  name: test
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test
current-context: ""
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file
- name: experimenter
  user:
    # Nota de documentação (este comentário NÃO faz parte da saída do comando).
    # Armazenar senhas na configuração do cliente Kubernetes é arriscado.
    # Uma alternativa melhor seria usar um plugin de credenciais
    # e armazenar as credenciais separadamente.
    # Veja https://kubernetes.io/pt-br/docs/reference/access-authn-authz/authentication/#plugins-de-credenciais-client-go
    password: some-password
    username: exp

O fake-ca-file, o fake-cert-file e o fake-key-file acima são os espaços reservados para a localização dos arquivos de certificado. Você precisa alterá-los para a localização real dos arquivos de certificado em seu ambiente.

Às vezes, você pode querer usar dados codificados em Base64 incorporados aqui, em vez de arquivos de certificado separados. Nesse caso, é necessário adicionar o sufixo data às chaves, por exemplo, certificate-authority-data, client-certificate-data, client-key-data.

Cada contexto é uma tripla (cluster, usuário, namespace). Por exemplo, o contexto dev-frontend diz: "Use as credenciais do usuário developer para acessar o namespace frontend do cluster development".

Define o contexto atual:

kubectl config --kubeconfig=config-demo use-context dev-frontend

Agora, sempre que você use um comando kubectl, a ação será aplicada ao cluster, e ao namespace listados no contexto dev-frontend. E o comando usará as credenciais do usuário listado no contexto dev-frontend.

Para ver apenas as informações de configuração associadas ao o contexto atual, use a opção --minify.

kubectl config --kubeconfig=config-demo view --minify

O resultado mostra as informações de configuração associadas ao contexto dev-frontend:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: fake-ca-file
    server: https://1.2.3.4
  name: development
contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
current-context: dev-frontend
kind: Config
preferences: {}
users:
- name: developer
  user:
    client-certificate: fake-cert-file
    client-key: fake-key-file

Agora, suponha que você queira trabalhar por um tempo no cluster de teste.

Altere o contexto atual para exp-test:

kubectl config --kubeconfig=config-demo use-context exp-test

Agora, qualquer comando kubectl que você usar, será aplicado ao namespace padrão do cluster test. E o comando usará as credenciais do usuário listado no contexto exp-test.

Ver a configuração associada ao novo contexto atual, exp-test.

kubectl config --kubeconfig=config-demo view --minify

Por fim, suponha que você queira trabalhar por um tempo no namespace storage do cluster development.

Altere o contexto atual para dev-storage:

kubectl config --kubeconfig=config-demo use-context dev-storage

Ver a configuração associada ao novo contexto atual, dev-storage.

kubectl config --kubeconfig=config-demo view --minify

Crie um segundo arquivo de configuração

Em seu diretório config-exercise, crie um arquivo chamado config-demo-2 com este conteúdo:

apiVersion: v1
kind: Config
preferences: {}

contexts:
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up

O arquivo de configuração anterior define um novo contexto chamado dev-ramp-up.

Defina a variável de ambiente KUBECONFIG

Verifique se você tem uma variável de ambiente chamada KUBECONFIG. Em caso afirmativo, salve o valor atual da variável de ambiente KUBECONFIG para que você possa restaurá-lo posteriormente. Por exemplo:

Linux

export KUBECONFIG_SAVED="$KUBECONFIG"

Windows PowerShell

$Env:KUBECONFIG_SAVED=$ENV:KUBECONFIG

A variável de ambiente KUBECONFIG é uma lista de caminhos para arquivos de configuração. A lista é delimitada por dois pontos para Linux e Mac, e delimitada por ponto e vírgula para Windows. Se você tiver uma variável de ambiente KUBECONFIG, familiarize-se com os arquivos de configuração na lista.

Anexe temporariamente duas localizações à sua variável de ambiente KUBECONFIG. Por exemplo:

Linux

export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2"

Windows PowerShell

$Env:KUBECONFIG=("config-demo;config-demo-2")

Em seu diretório config-exercise, digite este comando:

kubectl config view

O resultado mostra informações mescladas de todos os arquivos listados em sua variável de ambiente KUBECONFIG. Em particular, observe que as informações mescladas têm o contexto dev-ramp-up do arquivo config-demo-2 e os três contextos do arquivo config-demo:

contexts:
- context:
    cluster: development
    namespace: frontend
    user: developer
  name: dev-frontend
- context:
    cluster: development
    namespace: ramp
    user: developer
  name: dev-ramp-up
- context:
    cluster: development
    namespace: storage
    user: developer
  name: dev-storage
- context:
    cluster: test
    namespace: default
    user: experimenter
  name: exp-test

Para obter mais informações sobre como os arquivos kubeconfig são mesclados, consulte Organizando o acesso ao cluster usando arquivos kubeconfig

Explore o diretório $HOME/.kube

Se você já tiver um cluster e puder usar o kubectl para interagir com o o cluster, então provavelmente você tem um arquivo chamado config no diretório $HOME/.kube.

Vá para $HOME/.kube e veja quais arquivos estão lá. Normalmente, há um arquivo chamado config. Também pode haver outros arquivos de configuração nesse diretório. Em um breve momento familiarize-se com o conteúdo desses arquivos.

Acrescente $HOME/.kube/config à sua variável de ambiente KUBECONFIG

Se você tiver um arquivo $HOME/.kube/config e ele ainda não estiver listado em sua variável de ambiente KUBECONFIG, acrescente-o à sua variável de ambiente KUBECONFIG agora. Por exemplo:

Linux

export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config"

Windows Powershell

$Env:KUBECONFIG="$Env:KUBECONFIG;$HOME\.kube\config"

Visualize as informações de configuração mescladas de todos os arquivos que agora estão listados em sua variável de ambiente KUBECONFIG. Em seu diretório config-exercise, digite:

kubectl config view

Limpar

Retorne sua variável de ambiente KUBECONFIG ao seu valor original. Por exemplo:

Linux

export KUBECONFIG="$KUBECONFIG_SAVED"

Windows PowerShell

$Env:KUBECONFIG=$ENV:KUBECONFIG_SAVED

Verificar o sujeito representado pelo kubeconfig

Nem sempre é óbvio quais atributos (nome de usuário, grupos) você obterá após a autenticação no cluster. Isso pode ser ainda mais desafiador se você estiver gerenciando mais de um cluster ao mesmo tempo.

Há um subcomando de kubectl para verificar os atributos do sujeito, como o nome de usuário, para o Kubernetes contexto selecionado: kubectl auth whoami.

Leia Acesso da API às informações de autenticação de um cliente para saber mais sobre isso em detalhes.

Próximos passos

6.3 - Use o redirecionamento de porta para acessar aplicativos em um cluster.

Esta página mostra como usar o kubectl port-forward para se conectar a um servidor MongoDB em execução em um cluster Kubernetes. Esse tipo de conexão pode ser útil para depuração de bancos de dados.

Antes de você começar

  • 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:

    O seu servidor Kubernetes deve estar numa versão igual ou superior a v1.10. Para verificar a versão, digite kubectl version.
  • Instale o MongoDB Shell.

Criando a implantação e o serviço do MongoDB

  1. Crie uma Implantação que execute o MongoDB:

    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml
    

    A saída de um comando bem-sucedido verifica que a implantação foi criada:

    deployment.apps/mongo criado
    

    Visualize o status do pod para verificar se ele está pronto:

    kubectl get pods
    

    A saída exibe o pod criado:

    NAME                     READY   STATUS    RESTARTS   AGE
    mongo-75f59d57f4-4nd6q   1/1     Em execução   0          2m4s
    

    Visualize o status da implantação:

    kubectl get deployment
    

    A saída exibe que a implantação foi criada:

    NAME    READY   UP-TO-DATE   AVAILABLE   AGE
    mongo   1/1     1            1           2m21s
    

    A implantação gerencia automaticamente um conjunto de réplicas. Visualize o status do conjunto de réplicas usando:

    kubectl get replicaset
    

    Visualize o status do conjunto de réplicas usando:

    NAME               DESIRED   CURRENT   READY   AGE
    mongo-75f59d57f4   1         1         1       3m12s
    
  2. Crie um serviço para expor o MongoDB na rede:

    kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml
    

    A saída de um comando bem-sucedido verifica que o serviço foi criado:

    service/mongo criado
    

    Verifique o serviço criado::

    kubectl get service mongo
    

    A saída exibe o serviço criado:

    NAME    TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
    mongo   ClusterIP   10.96.41.183   <none>        27017/TCP   11s
    
  3. Verifique se o servidor MongoDB está sendo executado no Pod e ouvindo a porta 27017:

    # Altere mongo-75f59d57f4-4nd6q para o nome do Pod
    kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}'
    

    A saída exibe a porta para o MongoDB nesse Pod:

    27017
    

    27017 é a porta TCP alocada ao MongoDB na internet.

Encaminhe uma porta local para uma porta no Pod

  1. kubectl port-forward permite usar o nome do recurso, como o nome do pod, para selecionar um pod correspondente para encaminhar a porta.

    # Altere mongo-75f59d57f4-4nd6q para o nome do Pod
    kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017
    

    que é o mesmo que

    kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017
    

    ou

    kubectl port-forward deployment/mongo 28015:27017
    

    ou

    kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017
    

    ou

    kubectl port-forward service/mongo 28015:27017
    

    Qualquer um dos comandos acima funciona. A saída é semelhante a esta:

    Encaminhamento de 127.0.0.1:28015 -> 27017
    Encaminhamento de [::1]:28015 -> 27017
    
  2. Inicie a interface de linha de comando do MongoDB:

    mongosh --port 28015
    
  3. No prompt de comando do MongoDB, digite o comando ping:

    db.runCommand( { ping: 1 } )
    

    Uma solicitação de ping bem-sucedida retorna:

    { ok: 1 }
    

Opcionalmente, deixe kubectl escolher a porta local

Se você não precisa de uma porta local específica, pode permitir que o kubectl escolha e reserve a porta local e, assim, evitar ter que gerenciar conflitos de porta local, com a sintaxe ligeiramente mais simples:

kubectl port-forward deployment/mongo :27017

A ferramenta kubectl encontra um número de porta local que não está em uso (evitando números de porta baixos, porque esses podem ser usados por outras aplicações). A saída é semelhante a:

Encaminhamento de 127.0.0.1:63753 -> 27017
Encaminhamento de [::1]:63753 -> 27017

Discussão

As conexões feitas à porta local 28015 são encaminhadas para a porta 27017 do Pod que está executando o servidor MongoDB. Com esta conexão em vigor, você pode usar seu local de trabalho para depurar o banco de dados que está sendo executado no Pod.

Próximos passos

Saiba mais sobre kubectl port-forward.

6.4 - Conectando um Frontend a um Backend usando Serviços

Esta tarefa mostra como criar um microserviço frontend e um microserviço backend. O microserviço backend é um serviço que envia uma mensagem de saudação. O frontend expõe o backend usando o nginx e um objeto Service do Kubernetes.

Objetivos

  • Crie e execute um microserviço de backend de amostra chamado hello usando um objeto Deployment.
  • Use um objeto de serviço (Service) para enviar tráfego para as várias réplicas do microserviço de backend.
  • Crie e execute um microserviço de frontend chamado nginx, também usando um objeto Deployment.
  • Configure o microserviço de frontend para enviar tráfego para o microserviço de backend.
  • Use um objeto Service do tipo LoadBalancer para expor o microserviço de frontend fora do cluster.

Antes de você começar

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, digite kubectl version.

Esta tarefa utiliza Serviços com balanceadores de carga externos, que necessitam de um ambiente suportado. Se o seu ambiente não suportar isso, você pode substituir por um serviço do tipo NodePort.

Criando o backend usando um Deployment.

O backend é um microserviço simples de saudação. Aqui está o arquivo de configuração para o Deployment do backend:

---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend
spec:
  selector:
    matchLabels:
      app: hello
      tier: backend
      track: stable
  replicas: 3
  template:
    metadata:
      labels:
        app: hello
        tier: backend
        track: stable
    spec:
      containers:
        - name: hello
          image: "gcr.io/google-samples/hello-go-gke:1.0"
          ports:
            - name: http
              containerPort: 80
...

Crie o Deployment do backend:

kubectl apply -f https://k8s.io/examples/service/access/backend-deployment.yaml

Veja informações sobre o Deployment do backend:

kubectl describe deployment backend

A saída é semelhante a esta:

Name:                           backend
Namespace:                      default
CreationTimestamp:              Mon, 24 Oct 2016 14:21:02 -0700
Labels:                         app=hello
                                tier=backend
                                track=stable
Annotations:                    deployment.kubernetes.io/revision=1
Selector:                       app=hello,tier=backend,track=stable
Replicas:                       3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:                   RollingUpdate
MinReadySeconds:                0
RollingUpdateStrategy:          1 max unavailable, 1 max surge
Pod Template:
  Labels:       app=hello
                tier=backend
                track=stable
  Containers:
   hello:
    Image:              "gcr.io/google-samples/hello-go-gke:1.0"
    Port:               80/TCP
    Environment:        <none>
    Mounts:             <none>
  Volumes:              <none>
Conditions:
  Type          Status  Reason
  ----          ------  ------
  Available     True    MinimumReplicasAvailable
  Progressing   True    NewReplicaSetAvailable
OldReplicaSets:                 <none>
NewReplicaSet:                  hello-3621623197 (3/3 replicas created)
Events:
...

Criando o objeto Service hello

A chave para enviar solicitações do frontend para o backend é o Service do backend. Um Service cria um endereço IP persistente e uma entrada de nome DNS, para que o microserviço do backend possa ser sempre acessado. Um Service usa seletores para encontrar os Pods para os quais ele roteia o tráfego.

Primeiro, explore o arquivo de configuração do Service:

---
apiVersion: v1
kind: Service
metadata:
  name: hello
spec:
  selector:
    app: hello
    tier: backend
  ports:
  - protocol: TCP
    port: 80
    targetPort: http
...

No arquivo de configuração, você pode ver que o Service, chamado de hello, roteia o tráfego para Pods que possuem as labels app: hello e tier: backend.

Crie o Service para o backend:

kubectl apply -f https://k8s.io/examples/service/access/backend-service.yaml

Neste ponto, você possui um Deployment chamado backend executando três réplicas do seu aplicativo hello e possui um Service que pode rotear o tráfego para eles. No entanto, esse serviço ainda não pode ser acessado ou resolvido fora do cluster.

Criando o frontend

Agora que o seu backend está em execução, você pode criar um frontend que seja acessível fora do cluster e se conecte ao backend por meio de solicitações de proxy.

O frontend envia solicitações para os worker Pods do backend usando o nome DNS fornecido ao Serviço do backend. O nome DNS é hello, que é o valor do campo name no arquivo de configuração examples/service/access/backend-service.yaml.

Os Pods no Deployment do frontend executam uma imagem nginx que é configurada para fazer proxy de solicitações para o Serviço de backend hello. Aqui está o arquivo de configuração nginx:

# The identifier Backend is internal to nginx, and used to name this specific upstream
upstream Backend {
    # hello is the internal DNS name used by the backend Service inside Kubernetes
    server hello;
}

server { listen 80;

location / {
    # The following statement will proxy traffic to the upstream named Backend
    proxy_pass http://Backend;
}

}

Similarmente ao backend, o frontend possui um Deployment e um Service. Uma diferença importante a ser notada entre os serviços de backend e frontend é que a configuração do serviço de frontend tem o parâmetro type: LoadBalancer, o que significa que o serviço usa um balanceador de carga fornecido pelo provedor de nuvem e será acessível de fora do cluster.

---
apiVersion: v1
kind: Service
metadata:
  name: frontend
spec:
  selector:
    app: hello
    tier: frontend
  ports:
  - protocol: "TCP"
    port: 80
    targetPort: 80
  type: LoadBalancer
...
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
spec:
  selector:
    matchLabels:
      app: hello
      tier: frontend
      track: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: hello
        tier: frontend
        track: stable
    spec:
      containers:
        - name: nginx
          image: "gcr.io/google-samples/hello-frontend:1.0"
          lifecycle:
            preStop:
              exec:
                command: ["/usr/sbin/nginx","-s","quit"]
...

Crie o Deployment e o Service para o frontend:

kubectl apply -f https://k8s.io/examples/service/access/frontend-deployment.yaml
kubectl apply -f https://k8s.io/examples/service/access/frontend-service.yaml

A saída mostra que ambos os recursos foram criados:

deployment.apps/frontend created
service/frontend created

Interagindo com o Service frontend

Depois de criar um Service do tipo LoadBalancer, você pode usar este comando para encontrar o IP externo:

kubectl get service frontend --watch

Isso exibe a configuração do Service frontend e fica monitorando por mudanças. Inicialmente, o IP externo é exibido como <pending>:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   <pending>     80/TCP   10s

Assim que um IP externo é provisionado, a configuração é atualizada para incluir o novo IP na seção EXTERNAL-IP:

NAME       TYPE           CLUSTER-IP      EXTERNAL-IP        PORT(S)  AGE
frontend   LoadBalancer   10.51.252.116   XXX.XXX.XXX.XXX    80/TCP   1m

Esse IP agora pode ser usado para interagir com o serviço frontend de fora do cluster.

Enviando tráfego por meio do frontend

Agora que o frontend e o backend estão conectados, você pode acessar o endpoint usando o comando curl no IP externo do seu serviço frontend:

curl http://${EXTERNAL_IP} # substitua isto pelo `EXTERNAL-IP` que você viu antes

A saída mostra a mensagem gerada pelo backend:

{"message":"Hello"}

Limpando

Para excluir os Services, digite este comando:

kubectl delete services frontend backend

Para excluir os Deployments, ReplicaSets e `Pods que estão executando as aplicações frontend e backend, digite este comando:

kubectl delete deployment frontend backend

Próximos passos

6.5 - Criando um Balanceador de Carga Externo

Esta página mostra como criar um balanceador de carga externo para um service em execução em um cluster Kubernetes.

Criando um Service, você tem a opção de criar automaticamente um balanceador de carga em nuvem. Isso fornece um endereço IP acessível externamente que envia tráfego para a porta correta nos nós do seu cluster, desde que seu cluster seja executado em um ambiente suportado e esteja configurado com o pacote do provedor de balanceador de carga em nuvem correto.

Você também pode usar um Ingress no lugar de Service.

Para obter mais informações, verifique a documentação do Ingress.

Antes de você começar

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:

Seu cluster deve estar em execução em uma nuvem ou em outro ambiente que já tenha suporte para configurar balanceadores de carga externos.

Criando um service

Criando um service com base em um manifesto

Para criar um balanceador de carga externo, adicione a seguinte linha ao manifesto do service:

    type: LoadBalancer

Seu manifesto pode se parecer com:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  type: LoadBalancer

Criando um Service usando o kubectl

Como alternativa, você pode criar o service com o comando kubectl expose e a flag --type=LoadBalancer:

kubectl expose deployment example --port=8765 --target-port=9376 \
        --name=example-service --type=LoadBalancer

Esse comando cria um novo service usando os mesmos seletores do recurso referenciado (no caso do exemplo acima, um Deployment chamado example).

Para obter mais informações, incluindo flags opcionais, consulte a referência do comando kubectl expose reference.

Encontrando seu endereço IP

Você pode encontrar o endereço IP criado para o seu service obtendo as informações do service por meio do kubectl:

kubectl describe services example-service

que devem produzir resultados semelhantes a:

Name:                     example-service
Namespace:                default
Labels:                   app=example
Annotations:              <none>
Selector:                 app=example
Type:                     LoadBalancer
IP Families:              <none>
IP:                       10.3.22.96
IPs:                      10.3.22.96
LoadBalancer Ingress:     192.0.2.89
Port:                     <unset>  8765/TCP
TargetPort:               9376/TCP
NodePort:                 <unset>  30593/TCP
Endpoints:                172.17.0.3:9376
Session Affinity:         None
External Traffic Policy:  Cluster
Events:                   <none>

O endereço IP do balanceador de carga é listado ao lado de LoadBalancer Ingress.

Preservando o IP de origem do cliente

Por padrão, o IP de origem visto no contêiner de destino não é o IP de origem original do cliente. Para permitir a preservação do IP do cliente, os seguintes campos podem ser configurados no .spec do Service:

  • .spec.externalTrafficPolicy - indica se este Service deseja rotear o tráfego externo para endpoints locais do nó ou em todo o cluster. Existem duas opções disponíveis: Cluster (padrão) e Local. Cluster oculta o IP de origem do cliente e pode causar um segundo salto para outro nó, mas deve ter uma boa distribuição geral de carga. Local preserva o IP de origem do cliente e evita um segundo salto para Service do tipo LoadBalancer e NodePort, mas corre o risco de uma distribuição de tráfego potencialmente desequilibrada.

  • .spec.healthCheckNodePort - especifica a porta de verificação de integridade (número de porta numérico) para o service. Se você não especificar healthCheckNodePort, o controlador de service alocará uma porta do intervalo NodePort do seu cluster. Você pode configurar esse intervalo definindo uma opção de linha de comando do servidor de API, --service-node-port-range. O Service usará o valor healthCheckNodePort especificado pelo usuário, se você o especificar, desde que o tipo do Service esteja definido como LoadBalancer e externalTrafficPolicy esteja definido como Local.

A definição externalTrafficPolicy: Local no manifesto do Service ativa esse recurso. Por exemplo:

apiVersion: v1
kind: Service
metadata:
  name: example-service
spec:
  selector:
    app: example
  ports:
    - port: 8765
      targetPort: 9376
  externalTrafficPolicy: Local
  type: LoadBalancer

Ressalvas e limitações ao preservar IPs de origem

Os service de balanceamento de carga de alguns provedores de nuvem não permitem configurar pesos diferentes para cada destino.

Como cada destino recebe o mesmo peso no balanceamento de tráfego para os Nós, o tráfego externo não é distribuído igualmente entre os Pods. Isso ocorre porque o balanceador de carga externo não considera o número de Pods por Nó.

Quando NumServicePods << NumNodes ou NumServicePods >> NumNodes, uma distribuição relativamente próxima da igualdade será observada, mesmo sem pesos.

O tráfego interno Pod-a-Pod deve apresentar um comportamento similar aos services ClusterIP, com a mesma probabilidade entre todos os Pods.

Limpeza de balanceadores de carga

ESTADO DA FUNCIONALIDADE: Kubernetes v1.17 [stable]

Em um caso normal, ao excluir um Service do tipo LoadBalancer, os recursos de balanceamento de carga no provedor de nuvem são automaticamente removidos. Porém, existem casos onde esses recursos permanecem ativos, mesmo após a exclusão do Service. Para resolver esse problema, foi introduzida a Proteção por Finalizadores para LoadBalancers de Service. Essa proteção utiliza finalizadores, que são mecanismos que impedem a exclusão de um Serviço até que os recursos de balanceamento de carga associados também sejam removidos.

Para Service do tipo LoadBalancer, o controlador de service utiliza um finalizador chamado service.kubernetes.io/load-balancer-cleanup. Esse finalizador funciona como um mecanismo de segurança, impedindo a exclusão do Service até que o recurso de balanceamento de carga associado seja removido. Essa medida evita a existência de recursos de balanceamento de carga órfãos, mesmo em situações inesperadas, como a falha do controlador de service.

Provedores de balanceamento de carga externo

É importante ressaltar que o roteamento e distribuição do tráfego para essa funcionalidade são realizados por um balanceador de carga que não faz parte do cluster Kubernetes.

Quando um Serviço é configurado como LoadBalancer, o Kubernetes garante o acesso interno aos pods do Serviço (como no tipo ClusterIP) e também integra o Serviço com um balanceador de carga externo. A camada de gerenciamento do Kubernetes é responsável por criar o balanceador de carga externo no provedor de nuvem, configurar as verificações de integridade (quando necessárias) e as regras de filtragem de pacotes (quando necessárias). Assim que o provedor de nuvem aloca um endereço IP ao balanceador de carga, a camada de gerenciamento o adiciona ao objeto de Serviço, tornando-o acessível externamente.

Próximos passos

6.6 - Comunicação entre contêineres no mesmo pod usando um volume compartilhado

Esta página mostra como usar um Volume para realizar a comunicação entre dois contêineres rodando no mesmo Pod. Veja também como permitir que processos se comuniquem por compartilhamento de namespace do processo entre os contêineres.

Antes de você começar

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, digite kubectl version.

Criando um pod que executa dois contêineres

Neste exercício, você cria um Pod que executa dois contêineres. Os dois contêineres compartilham um volume que eles podem usar para se comunicar. Aqui está o arquivo de configuração para o Pod:

apiVersion: v1
kind: Pod
metadata:
  name: two-containers
spec:

  restartPolicy: Never

  volumes:
  - name: shared-data
    emptyDir: {}

  containers:

  - name: nginx-container
    image: nginx
    volumeMounts:
    - name: shared-data
      mountPath: /usr/share/nginx/html

  - name: debian-container
    image: debian
    volumeMounts:
    - name: shared-data
      mountPath: /pod-data
    command: ["/bin/sh"]
    args: ["-c", "echo Hello from the debian container > /pod-data/index.html"]

No arquivo de configuração, você pode ver que o Pod tem um shared-data chamado shared-data.

O primeiro contêiner listado no arquivo de configuração executa um servidor nginx. O caminho de montagem para o volume compartilhado é /usr/share/nginx/html. O segundo contêiner é baseado na imagem debian e tem um caminho de montagem /pod-data. O segundo contêiner executa o seguinte comando e é encerrado.

echo Hello from the debian container > /pod-data/index.html

Observe que o segundo contêiner grava o arquivo index.html no diretório raiz do servidor nginx.

Crie o Pod e os dois contêineres:

kubectl apply -f https://k8s.io/examples/pods/two-container-pod.yaml

Veja as informações sobre o Pod e os contêineres:

kubectl get pod two-containers --output=yaml

Aqui está uma parte da saída:

apiVersion: v1
kind: Pod
metadata:
  ...
  name: two-containers
  namespace: default
  ...
spec:
  ...
  containerStatuses:

  - containerID: docker://c1d8abd1 ...
    image: debian
    ...
    lastState:
      terminated:
        ...
    name: debian-container
    ...

  - containerID: docker://96c1ff2c5bb ...
    image: nginx
    ...
    name: nginx-container
    ...
    state:
      running:
    ...

Você pode ver que o contêiner debian foi encerrado e o contêiner nginx ainda está em execução.

Obtenha um shell para o contêiner nginx:

kubectl exec -it two-containers -c nginx-container -- /bin/bash

Em seu shell, verifique que o nginx está em execução:

root@two-containers:/# apt-get update
root@two-containers:/# apt-get install curl procps
root@two-containers:/# ps aux

A saída é semelhante a esta:

USER       PID  ...  STAT START   TIME COMMAND
root         1  ...  Ss   21:12   0:00 nginx: master process nginx -g daemon off;

Lembre-se de que o contêiner debian criou o arquivo index.html no diretório raiz do nginx. Use curl para enviar uma solicitação GET para o servidor nginx:

root@two-containers:/# curl localhost

A saída mostra que o nginx responde com uma página da web escrita pelo contêiner debian:

Hello from the debian container

Discussão

O principal motivo pelo qual os pods podem ter vários contêineres é oferecer suporte a aplicações extras que apoiam uma aplicação principal. Exemplos típicos de aplicativos auxiliares são extratores de dados, aplicações para envio de dados e proxies. Aplicativos auxiliares e primários geralmente precisam se comunicar uns com os outros. Normalmente, isso é feito por meio de um sistema de arquivos compartilhado, conforme mostrado neste exercício, ou por meio da interface de rede de loopback, localhost. Um exemplo desse padrão é um servidor web junto com um programa auxiliar que consulta um repositório Git para novas atualizações.

O volume neste exercício fornece uma maneira dos contêineres se comunicarem durante a vida útil do Pod. Se o Pod for excluído e recriado, todos os dados armazenados no volume compartilhado serão perdidos.

Próximos passos

6.7 - Configurando o Ingress no Minikube com o NGINX Ingress Controller Config

O Ingress é um objeto da API que define regras que permitem acesso externo a serviços em um cluster. Um Ingress controller cumpre as regras estabelecidas no Ingress.

Essa página mostra como configurar um Ingress simples que redireciona as requisições para o Service "web" ou "web2" dependendo do URI HTTP.

Antes de você começar

Esse tutorial assume que você está usando minikube para rodar um cluster Kubernetes local. Visite Install tools para aprender como instalar o minikube.

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:

O seu servidor Kubernetes deve estar numa versão igual ou superior a 1.19. Para verificar a versão, digite kubectl version. Se você estiver usando uma versão mais antiga do Kubernetes, veja a documentação para essa versão.

Criando um cluster minikube

Se você ainda não configurou um cluster local, rode minikube start para criar um cluster.

Ativando o Ingress controller

  1. Para ativar o NGINX Ingress controller, rode os seguintes comandos:

    minikube addons enable ingress
    
  2. Verifique que o NGINX Ingress controller está rodando

    kubectl get pods -n ingress-nginx
    

    O resultado deve ser similar a:

    NAME                                        READY   STATUS      RESTARTS    AGE
    ingress-nginx-admission-create-g9g49        0/1     Completed   0          11m
    ingress-nginx-admission-patch-rqp78         0/1     Completed   1          11m
    ingress-nginx-controller-59b45fb494-26npt   1/1     Running     0          11m
    

Instale uma aplicação hello world

  1. Crie um Deployment usando o seguinte comando:

    kubectl create deployment web --image=gcr.io/google-samples/hello-app:1.0
    

    O resultado deve ser:

    deployment.apps/web created
    
  2. Exponha o Deployment:

    kubectl expose deployment web --type=NodePort --port=8080
    

    O resultado deve ser:

    service/web exposed
    
  3. Verifique que o Service está criado e disponível em uma porta do nó:

    kubectl get service web
    

    O resultado deve ser similar:

    NAME      TYPE       CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
    web       NodePort   10.104.133.249   <none>        8080:31637/TCP   12m
    
  4. Visite o Service via NodePort:

    minikube service web --url
    

    O resultado é similar a:

    http://172.17.0.15:31637
    
    curl http://172.17.0.15:31637 
    

    O resultado é similar a:

    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    

    Você agora pode acessar a aplicação de exemplo através do endereço IP do Minikube e NodePort. No próximo passo, você irá acessar a aplicação usando o recurso Ingress.

Criando um Ingress

O manifesto a seguir define um Ingress que envia tráfego para seu Serviço via hello-world.info.

  1. crie example-ingress.yaml usando o arquivo:

    apiVersion: networking.k8s.io/v1
    kind: Ingress
    metadata:
      name: example-ingress
      annotations:
        nginx.ingress.kubernetes.io/rewrite-target: /$1
    spec:
      rules:
        - host: hello-world.info
          http:
            paths:
              - path: /
                pathType: Prefix
                backend:
                  service:
                    name: web
                    port:
                      number: 8080
    
  2. Crie o objeto Ingress rodando o seguinte comando:

    kubectl apply -f https://k8s.io/examples/service/networking/example-ingress.yaml
    

    O resultado deve ser:

    ingress.networking.k8s.io/example-ingress created
    
  3. Verifique se o endereço IP está configurado:

    kubectl get ingress
    

    Você deve ver um endereçco IPv4 na coluna ADDRESS; por exemplo:

    NAME              CLASS    HOSTS              ADDRESS        PORTS   AGE
    example-ingress   <none>   hello-world.info   172.17.0.15    80      38s
    
  4. Verifique se o Ingress controller está direcionando o tráfego:

    curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info
    

    Você deve ver:

    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    

    Você também pode visitar hello-world.info no seu navegador.

    • Opcionalmente Procure o endereço IP externo reportado pelo minikube:

      minikube ip
      

      Adicione uma linha semelhante à seguinte no final do arquivo /etc/hosts no seu computador (você vai precisar de acesso de administrador):

      172.17.0.15 hello-world.info
      

      Depois que você fizer essa mudança, seu navegador enviará solicitações da URL hello-world.info para o Minikube

Criando um segundo Deployment

  1. Crie outro Deployment usando o seguinte comando:

    kubectl create deployment web2 --image=gcr.io/google-samples/hello-app:2.0
    

    O resultado deve ser:

    deployment.apps/web2 created
    
  2. Expondo o segundo Deployment:

    kubectl expose deployment web2 --port=8080 --type=NodePort
    

    O resultado deve ser:

    service/web2 exposed
    

Edite o Ingress existente

  1. Edite o manifesto example-ingress.yaml existente, e adicione as seguintes linhas no final:

    - path: /v2
      pathType: Prefix
      backend:
        service:
          name: web2
          port:
            number: 8080
    
  2. Aplique as mudanças:

    kubectl apply -f example-ingress.yaml
    

    Você deve ver:

    ingress.networking/example-ingress configured
    

Testando o seu Ingress

  1. Acesse a primeira versão da sua aplicação Hello World.

    curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info
    

    O resultado deve ser similar a:

    Hello, world!
    Version: 1.0.0
    Hostname: web-55b8c6998d-8k564
    
  2. Acesse a segunda versão da sua aplicação Hello World.

    curl --resolve "hello-world.info:80:$( minikube ip )" -i http://hello-world.info/v2
    

    O resultado deve ser similar a:

    Hello, world!
    Version: 2.0.0
    Hostname: web2-75cd47646f-t8cjk
    

Próximos passos

6.8 - Configurar DNS em um cluster

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.

6.9 - Acessando serviços em execução em clusters

Esta página mostra como se conectar aos serviços em execução no cluster Kubernetes.

Antes de você começar

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, digite kubectl version.

Acessando serviços em execução no cluster

No Kubernetes, todos nós, Pods e serviços têm seus próprios IPs. Em muitos casos, os IPs dos nós, dos Pods e alguns dos IPs de serviço em um cluster não serão roteáveis, portanto, não estarão acessíveis a partir de uma máquina fora do cluster, como seu computador.

Maneiras de se conectar

Você tem várias opções para se conectar a nós, Pods e serviços de fora do cluster:

  • Acesse serviços através de IPs públicos.
    • Use um serviço com tipo NodePort ou LoadBalancer para tornar o serviço acessível fora do cluster. Consulte a documentação de serviços e kubectl expose.
    • Dependendo do ambiente do cluster, isso pode expor o serviço apenas para a rede corporativa, ou pode expô-lo para a Internet. Pense se o serviço que está sendo exposto é seguro. Ele faz sua própria autenticação?
    • Coloque Pods atrás de serviços. Para acessar um Pod específico de um conjunto de réplicas, como para depurar, coloque uma label exclusiva no Pod e crie um novo serviço que selecione esta label.
    • Na maioria dos casos, não deve ser necessário para o desenvolvedor de aplicativos acessar diretamente nós através de seus endereços IP.
  • Acesse serviços, nós ou Pods usando o Verbo Proxy.
    • Faz autenticação e autorização do servidor de API antes de acessar o serviço remoto. Use isto se os serviços não forem seguros o suficiente para expor à Internet, ou para obter acesso a portas no IP do nó, ou para depuração.
    • Proxies podem causar problemas para algumas aplicações web.
    • Só funciona para HTTP/HTTPS.
    • Descrito aqui.
  • Acesse a partir de um nó ou Pod no cluster.
    • Execute um Pod e, em seguida, conecte-se a um shell nele usando kubectl exec. Conecte-se a outros nós, Pods e serviços a partir desse shell.
    • Alguns clusters podem permitir que você faça ssh para um nó no cluster. De lá, você pode conseguir acessar os serviços do cluster. Este é um método que não é padrão e funcionará em alguns clusters, mas não em outros. Navegadores e outras ferramentas podem ou não estar instalados. O DNS do cluster pode não funcionar.

Descobrindo serviços integrados

Normalmente, existem vários serviços que são iniciados em um cluster pelo kube-system. Obtenha uma lista desses serviços com o comando kubectl cluster-info:

kubectl cluster-info

A saída é semelhante a esta:

Kubernetes master is running at https://192.0.2.1
elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy
kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy
kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy
grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy
heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy

Isso mostra a URL referente ao verbo proxy para acessar cada serviço. Por exemplo, este cluster tem os logs a nível de cluster habilitados (usando o Elasticsearch), que pode ser acessado em https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/ se as credenciais adequadas forem passadas ou através do comando kubectl proxy, como por exemplo: http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/.

Construindo manualmente URLs de proxy do servidor da API

Como mencionado acima, você usa o comando kubectl cluster-info para recuperar a URL do proxy do serviço. Para criar URLs de proxy que incluem endpoints, sufixos e parâmetros de serviço, você adiciona à URL do proxy do serviço: http://endereço_do_mestre_do_kubernetes/api/v1/namespaces/nome_do_namespace/services/[https:]nome_do_serviço[:nome_da_porta]/proxy

Se você não especificou um nome para a porta, não é necessário especificar nome_da_porta na URL. Você também pode usar o número da porta no lugar do nome_da_porta para portas nomeadas e não nomeadas.

Por padrão, o servidor da API usa um proxy para o seu serviço através de HTTP. Para usar HTTPS, adicione o prefixo https: ao nome do serviço: http://<endereço_do_mestre_do_kubernetes>/api/v1/namespaces/<nome_do_namespace>/services/<nome_do_serviço>/proxy

Os formatos suportados para o segmento <nome_do_serviço> da URL são:

  • <nome_do_serviço> - usa um proxy para a porta padrão ou não nomeada usando http
  • <nome_do_serviço>:<nome_da_porta> - usa um proxy para a porta nomeada ou número da porta especificado usando http
  • https:<nome_do_serviço>: - usa um proxy para a porta padrão ou não nomeada usando https (observe o dois-pontos no final)
  • https:<nome_do_serviço>:<nome_da_porta> - usa um proxy para a porta nomeada ou número da porta especificado usando https
Exemplos
  • Para acessar o endpoint de serviço Elasticsearch _search?q=user:kimchy, você usaria:

    http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy
    
  • Para acessar as informações de integridade do cluster Elasticsearch _cluster/health?pretty=true, você usaria:

    https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true
    

    As informações de integridade são semelhantes a estas:

      {
        "cluster_name" : "kubernetes_logging",
        "status" : "yellow",
        "timed_out" : false,
        "number_of_nodes" : 1,
        "number_of_data_nodes" : 1,
        "active_primary_shards" : 5,
        "active_shards" : 5,
        "relocating_shards" : 0,
        "initializing_shards" : 0,
        "unassigned_shards" : 5
      }
    
  • Para acessar as informações de integridade do serviço Elasticsearch _cluster/health?pretty=true, você usaria:

    https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true
    

Usando navegadores da web para acessar serviços em execução no cluster

Você pode conseguir de colocar um URL de proxy do servidor da API na barra de endereço de um navegador. No entanto:

  • Os navegadores da web geralmente não podem passar tokens, portanto, você pode precisar usar autenticação básica (senha). O servidor da API pode ser configurado para aceitar autenticação básica, mas o seu cluster pode não estar configurado para aceitar autenticação básica.
  • Algumas aplicações da web podem não funcionar, principalmente aqueles com javascript do lado do cliente que constroem URLs com um mecanismo que não está ciente do prefixo do caminho do proxy.

7 - Configurar um provedor de credenciais de imagem para o kubelet

Configure o plugin de provedor de credenciais de imagem do kubelet
ESTADO DA FUNCIONALIDADE: Kubernetes v1.26 [stable]

A partir do Kubernetes v1.20, o kubelet pode obter dinamicamente as credenciais para um registro de imagem de contêiner usando plugins executáveis. O kubelet e o plugin executável se comunicam por meio de stdio (stdin, stdout e stderr) usando APIs versionadas do Kubernetes. Esses plugins permitem que o kubelet solicite credenciais para um registro de contêiner dinamicamente, em vez de armazenar credenciais estáticas no disco. Por exemplo, o plugin pode se comunicar com um servidor de metadados local para recuperar credenciais de curta duração para uma imagem que está sendo baixada pelo kubelet.

Você pode estar interessado em usar essa funcionalidade se alguma das condições abaixo for verdadeira:

  • Chamadas de API para um serviço de provedor de nuvem são necessárias para recuperar informações de autenticação para um registro.
  • As credenciais têm tempos de expiração curtos e é necessário solicitar novas credenciais com frequência.
  • Armazenar credenciais de registro no disco ou em imagePullSecrets não é aceitável.

Este guia demonstra como configurar o mecanismo de plugin do provedor de credenciais de imagem do kubelet.

Antes de você começar

  • Você precisa de um cluster Kubernetes com nós que suportem plugins de provedor de credenciais do kubelet. Esse suporte está disponível no Kubernetes 1.30; As versões v1.24 e v1.25 do Kubernetes incluíram isso como um recurso beta, ativado por padrão.

  • Uma implementação funcional de um plugin executável de provedor de credenciais. Você pode criar seu próprio plugin ou usar um fornecido por provedores de nuvem.

O seu servidor Kubernetes deve estar numa versão igual ou superior a v1.26. Para verificar a versão, digite kubectl version.

Instalando Plugins nos Nós

Um plugin de provedor de credenciais é um binário executável que será executado pelo kubelet. Certifique-se de que o binário do plugin exista em cada nó do seu cluster e esteja armazenado em um diretório conhecido. O diretório será necessário posteriormente ao configurar as flags do kubelet.

Configurando o Kubelet

Para usar esse recurso, o kubelet espera que duas flags sejam definidas:

  • --image-credential-provider-config - o caminho para o arquivo de configuração do plugin de provedor de credenciais.
  • --image-credential-provider-bin-dir - o caminho para o diretório onde estão localizados os binários do plugin de provedor de credenciais.

Configurar um provedor de credenciais do kubelet

O arquivo de configuração passado para --image-credential-provider-config é lido pelo kubelet para determinar quais plugins executáveis devem ser invocados para quais imagens de contêiner. Aqui está um exemplo de arquivo de configuração que você pode acabar usando se estiver usando o plugin baseado no ECR:

apiVersion: kubelet.config.k8s.io/v1
kind: CredentialProviderConfig
# providers é uma lista de plug-ins auxiliares do provedor de credenciais que serão habilitados pelo kubelet.
# Vários provedores podem corresponder a uma única imagem, caso em que as credenciais
# de todos os provedores serão devolvidos ao kubelet. Se vários provedores forem chamados
# para uma única imagem, os resultados são combinados. Se os provedores retornarem 
# chaves de autenticação sobrepostas, o valor do provedor anterior da lista é usado.
providers:
   # name é o nome necessário do provedor de credenciais. Deve corresponder ao nome do
   # executável do provedor visto pelo kubelet. O executável deve estar no 
   # diretório bin do kubelet (definido pela flag --image-credential-provider-bin-dir).
   - name: ecr
     # matchImages é uma lista obrigatória de strings usadas para corresponder às imagens para
     # determinar se este provedor deve ser invocado. Se uma das strings corresponder à
     # imagem solicitada do kubelet, o plug-in será invocado e terá uma chance
     # para fornecer credenciais. Espera-se que as imagens contenham o domínio de registro
     # e caminho da URL.
     #
     # Cada entrada em matchImages é um padrão que pode opcionalmente conter uma porta e um caminho.
     # Globs podem ser usados no domínio, mas não na porta ou no caminho. Globs são suportados
     # como subdomínios como '*.k8s.io' ou 'k8s.*.io' e domínios de nível superior como 'k8s.*'.
     # A correspondência de subdomínios parciais como 'app*.k8s.io' também é suportada. Cada glob só pode corresponder
     # a um único segmento de subdomínio, então `*.io` **não** corresponde a `*.k8s.io`.
     #
     # Existe uma correspondência entre uma imagem e uma matchImage quando todas as opções abaixo são verdadeiras:
     # - Ambos contêm o mesmo número de partes de domínio e cada parte faz correspondência.
     # - O caminho da URL de um matchImages deve ser um prefixo do caminho do URL da imagem de destino.
     # - Se matchImages contiver uma porta, a porta também deverá corresponder à imagem.
     #
     # Valores de exemplo de matchImages:
     # - 123456789.dkr.ecr.us-east-1.amazonaws.com
     # - *.azurecr.io
     # - gcr.io
     # - *.*.registry.io
     # - Registry.io:8080/path
     matchImages:
       - "*.dkr.ecr.*.amazonaws.com"
       - "*.dkr.ecr.*.amazonaws.cn"
       - "*.dkr.ecr-fips.*.amazonaws.com"
       - "*.dkr.ecr.us-iso-east-1.c2s.ic.gov"
       - "*.dkr.ecr.us-isob-east-1.sc2s.sgov.gov"
     # defaultCacheDuration é a duração padrão em que o plug-in armazenará as credenciais na memória
     # se a duração do cache não for fornecida na resposta do plug-in. Este campo é obrigatório.
     defaultCacheDuration: "12h"
     # Versão de entrada necessária do exec CredentialProviderRequest. O CredentialProviderResponse retornado
     # DEVE usar a mesma versão de codificação da entrada. Os valores atualmente suportados são:
     # - credentialprovider.kubelet.k8s.io/v1
     apiVersion: credentialprovider.kubelet.k8s.io/v1
     # Argumentos para passar ao comando quando for executá-lo.
     # +optional
     args:
       - get-credentials
     # Env define variáveis de ambiente adicionais para expor ao processo. Esses valores
     # são combinados com o ambiente do host, bem como as variáveis que o client-go usa
     # para passar o argumento para o plugin.
     # +optional
     env:
       - name: AWS_PROFILE
         value: example_profile

O campo providers é uma lista de plugins habilitados usados pelo kubelet. Cada entrada tem alguns campos obrigatórios:

  • name: o nome do plugin que DEVE corresponder ao nome do binário executável que existe no diretório passado para --image-credential-provider-bin-dir.
  • matchImages: uma lista de strings usadas para comparar com imagens, a fim de determinar se este provedor deve ser invocado. Mais sobre isso abaixo.
  • defaultCacheDuration: a duração padrão em que o kubelet armazenará em cache as credenciais em memória, caso a duração de cache não tenha sido especificada pelo plugin.
  • apiVersion: a versão da API que o kubelet e o plugin executável usarão ao se comunicar.

Cada provedor de credenciais também pode receber argumentos opcionais e variáveis de ambiente. Consulte os implementadores do plugin para determinar qual conjunto de argumentos e variáveis de ambiente são necessários para um determinado plugin.

Configurar a correspondência de imagens

O campo matchImages de cada provedor de credenciais é usado pelo kubelet para determinar se um plugin deve ser invocado para uma determinada imagem que um Pod está usando. Cada entrada em matchImages é um padrão de imagem que pode opcionalmente conter uma porta e um caminho. Globs podem ser usados no domínio, mas não na porta ou no caminho. Globs são suportados como subdomínios como *.k8s.io ou k8s.*.io, e domínios de nível superior como k8s.*. Correspondência de subdomínios parciais como app*.k8s.io também é suportada. Cada glob só pode corresponder a um único segmento de subdomínio, então *.io NÃO corresponde a *.k8s.io.

Uma correspondência existe entre um nome de imagem e uma entrada matchImage quando todos os itens abaixo são verdadeiros:

  • Ambos contêm o mesmo número de partes de domínio e cada parte corresponde.
  • O caminho da URL da imagem correspondente deve ser um prefixo do caminho da URL da imagem de destino.
  • Se o matchImages contiver uma porta, então a porta deve corresponder na imagem também.

Alguns valores de exemplo de padrões matchImages são:

  • 123456789.dkr.ecr.us-east-1.amazonaws.com
  • *.azurecr.io
  • gcr.io
  • *.*.registry.io
  • foo.registry.io:8080/path

Próximos passos

8 - Limitar o consumo de armazenamento

Este exemplo demonstra como limitar a quantidade de armazenamento consumido em um namespace.

Os seguintes recursos são usados na demonstração: ResourceQuota, LimitRange, e PersistentVolumeClaim.

Antes de você começar

  • 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, digite kubectl version.

Cenário: Limitando o consumo de armazenamento.

O administrador do cluster está operando um cluster em nome de uma população de usuários e o administrador quer controlar quanto armazenamento um único namespace pode consumir para controlar custos.

O administrador gostaria de limitar:

  1. O número de persistent volume claims em um namespace
  2. A quantidade de armazenamento que cada claim pode solicitar
  3. A quantidade total de armazenamento que o namespace pode ter.

LimitRange para limitar solicitações de armazenamento

Adicionar um LimitRange a um namespace impõe tamanhos mínimos e máximos para solicitações de armazenamento. O armazenamento é solicitado através do PersistentVolumeClaim. O controlador de admissão que impõe os limites rejeitará qualquer PVC que esteja acima ou abaixo dos valores definidos pelo administrador.

Neste exemplo, um PVC que solicita 10Gi de armazenamento seria rejeitado porque excede o limite máximo de 2Gi.

apiVersion: v1
kind: LimitRange
metadata:
  name: storagelimits
spec:
  limits:
  - type: PersistentVolumeClaim
    max:
      storage: 2Gi
    min:
      storage: 1Gi

As requisições de armazenamento mínimas são usadas quando o provedor de armazenamento subjacente exige certos valores mínimos. Por exemplo, os volumes do AWS EBS têm um requisito mínimo de 1 Gi.

StorageQuota para limitar a quantidade de PVC e a capacidade de armazenamento cumulativa

Os administradores podem limitar o número de PVCs em um namespace, bem como a capacidade cumulativa desses PVCs. Novos PVCs que excedam qualquer um desses valores máximos serão rejeitados.

Neste exemplo, o sexto PVC no namespace seria rejeitado porque excede a contagem máxima de 5. Alternativamente, uma cota máxima de 5Gi, combinada com o limite máximo de 2Gi acima, não pode ter 3 PVCs, cada um com 2Gi. Isso seria um total de 6Gi solicitados para um namespace limitado a 5Gi.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storagequota
spec:
  hard:
    persistentvolumeclaims: "5"
    requests.storage: "5Gi"

Resumo

Um LimitRange pode colocar um limite na quantidade de armazenamento solicitado enquanto um ResourceQuota pode efetivamente limitar o armazenamento consumido por um namespace através do número de claims e da capacidade de armazenamento cumulativa. Isso permite que um administrador do cluster planeje o custo de armazenamento do seu cluster sem risco de qualquer projeto exceder sua cota.

9 - Personalizando o Serviço DNS

Essa página explica como configurar os seus Pod(s) de DNS e personalizar o processo de resolução de DNS no seu cluster.

Antes de você começar

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:

Seu cluster deve estar executando o complemento CoreDNS.

O seu servidor Kubernetes deve estar numa versão igual ou superior a v1.12. Para verificar a versão, digite kubectl version.

Introdução

DNS é um serviço integrado do Kubernetes que é iniciado automaticamente usando o gerenciador de complementos cluster add-on.

Se você estiver executando o CoreDNS como um Deployment, ele geralmente será exposto como um service do Kubernetes com o endereço de IP estático. O kubelet passa informações de resolução de DNS para cada contêiner com a flag --cluster-dns=<dns-service-ip>.

Os nomes DNS também precisam de domínios. Você configura o domínio local no kubelet com a flag --cluster-domain=<default-local-domain>.

O servidor DNS suporta pesquisas de encaminhamento (registros A e AAAA), pesquisas de porta (registros SRV), pesquisas de endereço de IP reverso (registros PTR) e muito mais. Para mais informações, veja DNS para Serviços e Pods.

Se a dnsPolicy de um Pod estiver definida como default, ele herda a configuração de resolução de nome do nó em que o Pod é executado. A resolução de DNS do Pod deve se comportar da mesma forma que o nó. Veja Problemas conhecidos.

Se você não quiser isso, ou se quiser uma configuração de DNS diferente para os pods, pode usar a flag --resolv-conf do kubelet. Defina essa flag como "" para impedir que os Pods herdem a configuração do DNS. Defina-a como um caminho de arquivo válido para especificar um arquivo diferente de /etc/resolv.conf para a herança de DNS.

CoreDNS

CoreDNS é um servidor oficial de DNS de propósito geral que pode atuar como DNS do cluster, cumprindo com as especificações DNS.

Opções CoreDNS ConfigMap options

CoreDNS é um servidor DNS que é modular e plugável, com plugins que adicionam novas funcionalidades. O servidor CoreDNS pode ser configurado por um Corefile, que é o arquivo de configuração do CoreDNS. Como administrador de cluster, você pode modificar o ConfigMap que contém o arquivo Corefile do CoreDNS para mudar como o descoberta de serviços DNS se comporta para esse cluster.

No Kubernetes, o CoreDNS é instalado com a seguinte configuração padrão do Corefile:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            fallthrough in-addr.arpa ip6.arpa
            ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }    

A configuração do Corefile inclui os seguintes plugins do CoreDNS:

  • errors: Erros são enviados para stdout.
  • health: A integridade do CoreDNS é reportada para http://localhost:8080/health. Nesta sintaxe estendida, lameduck marcará o processo como não-íntegro, esperando por 5 segundos antes que o processo seja encerrado.
  • ready: Um endpoint HTTP na porta 8181 retornará 200 OK, quando todos os plugins que são capazes de sinalizar prontidão tiverem feito isso.
  • kubernetes: O CoreDNS responderá a consultas DNS baseado no IP dos Serviços e Pods. Você pode encontrar mais detalhes sobre este plugin no site do CoreDNS.
    • ttl permite que você defina um TTL personalizado para as respostas. O padrão é 5 segundos. O TTL mínimo permitido é de 0 segundos e o máximo é de 3600 segundos. Definir o TTL como 0 impedirá que os registros sejam armazenados em cache.
    • A opção pods insecure é fornecida para retrocompatibilidade com o kube-dns.
    • Você pode usar a opção pods verified, que retorna um registro A somente se houver um Pod no mesmo namespace com um IP correspondente.
    • A opção pods disabled pode ser usada se você não usar registros de Pod.
  • prometheus: As métricas do CoreDNS ficam disponíveis em http://localhost:9153/metrics seguindo o formato Prometheus, também conhecido como OpenMetrics.
  • forward: Qualquer consulta que não esteja no domínio do cluster do Kubernetes é encaminhada para resolutores predefinidos (/etc/resolv.conf).
  • cache: Habilita um cache de frontend.
  • loop: Detecta loops de encaminhamento simples e interrompe o processo do CoreDNS se um loop for encontrado.
  • reload: Permite a recarga automática de um Corefile que foi alterado. Depois de editar a configuração do ConfigMap, é necessario dois minutos para que as alterações entrem em vigor.
  • loadbalance: Este é um balanceador de carga DNS round-robin que randomiza a ordem dos registros A, AAAA e MX na resposta.

Você pode modificar o comportamento padrão do CoreDNS modificando o ConfigMap.

Configuração de domínio Stub e upstream nameserver usando o CoreDNS

O CoreDNS tem a capacidade de configurar domínios Stub e upstream nameservers usando o plugin forward.

Exemplo

Se um operador de cluster possui um servidor de domínio Consul localizado em "10.150.0.1" e todos os nomes Consul possuem o sufixo ".consul.local". Para configurá-lo no CoreDNS, o administrador do cluster cria a seguinte entrada no ConfigMap do CoreDNS.

consul.local:53 {
    errors
    cache 30
    forward . 10.150.0.1
}

Para forçar explicitamente que todas as pesquisas de DNS fora do cluster passem por um nameserver específico em 172.16.0.1, aponte o forward para o nameserver em vez de /etc/resolv.conf.

forward .  172.16.0.1

O ConfigMap final, juntamente com a configuração padrão do Corefile, é:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . 172.16.0.1
        cache 30
        loop
        reload
        loadbalance
    }
    consul.local:53 {
        errors
        cache 30
        forward . 10.150.0.1
    }    

Próximos passos