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/$(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:

    sudo curl -fsSLo /etc/apt/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.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/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

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/$(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 - Configurando GMSA Para Pods e Contêineres Windows

FEATURE STATE: 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 - Configurando RunAsUserName Para Pods e Contêineres Windows

FEATURE STATE: 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

4 - Gerenciando Secrets

Gerenciando dados de configurações usando Secrets.

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

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

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

5 - 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

6 - Atribuindo Recursos Estendidos a um Contêiner

FEATURE STATE: Kubernetes v1.26 [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

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

StatusSignificado
Init:N/MO pod tem contêineres de inicialização M e N que foram concluídas até agora.
Init:ErrorUm contêiner de inicialização falhou ao executar.
Init:CrashLoopBackOffUm contêiner de inicialização falhou repetidamente.
PendingO pod ainda não começou a executar o contêiner de inicialização.
PodInitializing ou RunningO pod já concluiu a execução dos contêineres de inicialização.

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

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

9.1 - 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

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

10 - 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

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.26, 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.26"
    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: []

12 - 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