Kubeadm

• 1: kubeadm (auto-gerado)
• 1.1:
• 1.2:
• 1.3:
• 1.4:
• 1.5:
• 1.6:
• 1.7:
• 1.8:
• 1.9:
• 1.10:
• 1.11:
• 1.12:
• 1.13:
• 1.14:
• 1.15:
• 1.16:
• 1.17:
• 1.18:
• 1.19:
• 1.20:
• 1.21:
• 1.22:
• 1.23:
• 1.24:
• 1.25:
• 1.26:
• 1.27:
• 1.28:
• 1.29:
• 1.30:
• 1.31:
• 1.32:
• 1.33:
• 1.34:
• 1.35:
• 1.36:
• 1.37:
• 1.38:
• 1.39:
• 1.40:
• 2: kubeadm init
• 3: kubeadm join
• 4: kubeadm upgrade
• 5: kubeadm config
• 6: kubeadm reset
• 7: kubeadm token
• 8: kubeadm version
• 9: kubeadm alpha
• 10: kubeadm certs
• 11: kubeadm kubeconfig
• 12: kubeadm upgrade phase

1 - kubeadm (auto-gerado)

1.1 -

Comandos relacionados ao manuseio de certificados kubernetes

Sinopse

Comandos relacionados ao manuseio de certificados kubernetes

Opções

Opções herdadas do comando superior

1.2 -

Gerar as chaves de certificado

Sinopse

Este comando exibirá uma chave de certificado segura gerada aleatoriamente que pode ser usada com o comando "init".

Você também pode usar "kubeadm init --upload-certs" sem especificar uma chave de certificado e ela irá gerar e exibir uma para você.

kubeadm certs certificate-key [flags]

Opções

Opções herdadas do comando superior

1.3 -

Verifique a expiração dos certificados para um cluster Kubernetes

Sinopse

Verifica a expiração dos certificados PKI local gerenciados pelo kubeadm.

kubeadm certs check-expiration [flags]

Opções

Opções herdadas do comando superior

1.4 -

Gerar chaves e solicitações de assinatura de certificados

Sinopse

Gera as chaves e as solicitações de assinatura de certificados (CSRs) para todos os certificados necessários para executar a camada de gerenciamento. Este comando também gera os arquivos kubeconfig parciais com dados de chave privada no campo "users > user > client-key-data" e, para cada arquivo kubeconfig, um arquivo ".csr" correspondente é criado.

Esse comando foi projetado para uso no modo de CA externo do Kubeadm. Ele gera CSRs que você pode enviar à sua autoridade de certificação externa para assinatura.

Os certificados PEM assinados e codificados devem ser salvos juntamente com os arquivos da chave, usando ".crt" como extensão de arquivo ou, no caso de arquivos kubeconfig, o certificado assinado codificado no formato PEM deve ser codificado em base64 e adicionado ao arquivo kubeconfig no campo "users > user > client-certificate-data".

kubeadm certs generate-csr [flags]

Exemplos

  # O comando a seguir gera as chaves e CSRs para todos os certificados do plano de controle e arquivos kubeconfig: 
  kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Opções

Opções herdadas do comando superior

1.5 -

Renove certificados para um cluster Kubernetes

Sinopse

Este comando não deve ser executado sozinho. Veja a lista de subcomandos disponíveis.

kubeadm certs renew [flags]

Opções

Opções herdadas do comando superior

1.6 -

Renove o certificado incorporado no arquivo kubeconfig para o administrador e o kubeadm usarem

Sinopse

Renove o certificado incorporado no arquivo kubeconfig para o administrador e o kubeadm usarem.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar a API de certificados do K8s para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew admin.conf [flags]

Opções

Opções herdadas dos comandos superiores

1.7 -

Renovar todos os certificados disponíveis

Sinopse

Renove todos os certificados conhecidos e necessários para executar a camada de gerenciamento. As renovações são executadas incondicionalmente, independentemente da data de expiração. As renovações também podem ser executadas individualmente para obter mais controle.

kubeadm certs renew all [flags]

Opções

Opções herdadas do comando superior

1.8 -

Renove o certificado que o apiserver usa para acessar o etcd.

Sinopse

Renove o certificado que o apiserver usa para acessar o etcd.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar a API de certificado K8s para renovação do certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew apiserver-etcd-client [flags]

Opções

Opções herdadas do comando superior

1.9 -

Renove o certificado para o servidor API se conectar ao kubelet

Sinopse

Renove o certificado para o servidor da API se conectar ao kubelet.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar a API de certificado do K8s para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew apiserver-kubelet-client [flags]

Opções

Opções herdadas do comando superior

1.10 -

Renove o certificado para servir a API do Kubernetes

Sinopse

Renove o certificado para servir a API do Kubernetes.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew apiserver [flags]

Opções

Opções herdadas do comando superior

1.11 -

Renove o certificado incorporado no arquivo kubeconfig para o uso do gerenciador de controladores.

Sinopse

Renove o certificado incorporado no arquivo kubeconfig para o uso do gerenciador de controladores.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew controller-manager.conf [flags]

Opções

Opções herdadas do comando superior

1.12 -

Renove o certificado para liveness probes para verificar a integridade do etcd

Sinopse

Renove o certificado para liveness probes para verificar a integridade do etcd.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew etcd-healthcheck-client [flags]

Opções

Opções herdadas do comando superior

1.13 -

Renove o certificado para nós etcd se comunicarem uns com os outros

Sinopse

Renove o certificado para nós etcd se comunicarem uns com os outros.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew etcd-peer [flags]

Opções

Opções herdadas do comando superior

1.14 -

Renove o certificado para servir o etcd

Sinopse

Renove o certificado para servir o etcd.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew etcd-server [flags]

Opções

Opções herdadas do comando superior

1.15 -

Renove o certificado para o cliente front proxy

Sinopse

Renove o certificado para o cliente front proxy.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew front-proxy-client [flags]

Opções

Opções herdadas do comando superior

1.16 -

Renove o certificado incorporado no arquivo kubeconfig para o gerenciador de agendamento usar

Sinopse

Renove o certificado incorporado no arquivo kubeconfig para o gerenciador de agendamento usar.

As renovações são executadas incondicionalmente, independentemente da data de expiração do certificado; atributos extras, como SANs, serão baseados no arquivo/certificados existentes, não há necessidade de informá-los novamente.

A renovação, por padrão, tenta usar a autoridade de certificação na PKI local gerenciada pelo kubeadm; como alternativa, é possível usar o certificado K8s da API para renovação de certificado, ou como última opção, para gerar uma solicitação CSR.

Após a renovação, para tornar as alterações efetivas, é necessário reiniciar os componentes da camada de gerenciamento e, eventualmente, redistribuir o certificado renovado, caso o arquivo seja usado em outro lugar.

kubeadm certs renew scheduler.conf [flags]

Opções

Opções herdadas do comando superior

1.17 -

Exibe uma lista de imagens que o kubeadm usará. O arquivo de configuração é usado caso quaisquer imagens ou repositórios de imagens sejam personalizados.

Sinopse

Exibe uma lista de imagens que o kubeadm usará. O arquivo de configuração é usado caso quaisquer imagens ou repositórios de imagens sejam personalizados.

kubeadm config images list [flags]

Opções

Opções herdadas do comando superior

1.18 -

Puxe imagens usadas pelo kubeadm

Sinopse

Baixa imagens usadas pelo kubeadm

kubeadm config images pull [flags]

Opções

Opções herdadas do comando superior

1.19 -

Leia uma versão mais antiga dos tipos de API de configuração do kubeadm a partir de um arquivo e envie o objeto de configuração semelhante para a versão mais recente

Sinopse

Esse comando permite converter objetos de configuração de versões mais antigas para a versão mais recente suportada, localmente na ferramenta CLI sem nunca tocar em nada no cluster. Nesta versão do kubeadm, as seguintes versões da API são suportadas:

• Kubeadm.k8s.io/v1beta3

Além disso, o kubeadm só pode escrever a configuração da versão "kubeadm.k8s.io/v1beta3", mas pode ler os dois tipos. Portanto, independentemente da versão que você passar para o parâmetro --old-config , o objeto API será lido, desserializado, padronizado, convertido, validado e serializado novamente quando escrito no stdout ou --new-config, se especificado.

Em outras palavras, a saída deste comando é o que o kubeadm realmente leria internamente se você enviasse este arquivo para "kubeadm init"

kubeadm config migrate [flags]

Opções

Opções herdadas do comando superior

1.20 -

Exibe configurações

Sinopse

Este comando exibe as configurações para subcomandos fornecidos. Para mais detalhes, consulte: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Opções

Opções herdadas do comando superior

1.21 -

Exibe a configuração de inicialização padrão, que pode ser usada para 'kubeadm init'

Sinopse

Este comando exibe objetos, como a configuração de inicialização padrão que é usada para 'kubeadm init'.

Observe que os valores confidenciais, como os campos do Token Bootstrap, são substituídos por valores de exemplo como "abcdef.0123456789abcdef", a fim de passar na validação, mas não executar o cálculo real para criar um token.

kubeadm config print init-defaults [flags]

Opções

Opções herdadas do comando superior

1.22 -

Exibe a configuração padrão do join, que pode ser usada para 'kubeadm join'

Sinopse

Este comando exibe objetos como a configuração padrão de join que é usada para 'kubeadm join'.

Observe que valores confidenciais, como os campos do Token Bootstrap, são substituídos por valores de exemplo como "abcdef.0123456789abcdef", a fim de passar na validação, mas não executar o cálculo real para criar um token.

kubeadm config print join-defaults [flags]

Opções

Opções herdadas do comando superior

1.23 -

Rode este comando para configurar a camada de gerenciamento do Kubernetes

Sinopse

Rode este comando para configurar a camada de gerenciamento do Kubernetes

O comando "init" executa as fases abaixo:

preflight                    Efetua as verificações pré-execução
certs                        Geração de certificados
  /ca                          Gera a autoridade de certificação (CA) auto-assinada do Kubernetes para provisionamento de identidades para outros componentes do Kubernetes
  /apiserver                   Gera o certificado para o servidor da API do Kubernetes
  /apiserver-kubelet-client    Gera o certificado para o servidor da API se conectar ao Kubelet
  /front-proxy-ca              Gera a autoridade de certificação (CA) auto-assinada para provisionamento de identidades para o front proxy
  /front-proxy-client          Gera o certificado para o cliente do front proxy
  /etcd-ca                     Gera a autoridade de certificação (CA) auto-assinada para provisionamento de identidades para o etcd
  /etcd-server                 Gera o certificado para servir o etcd
  /etcd-peer                   Gera o certificado para comunicação entre nós do etcd
  /etcd-healthcheck-client     Gera o certificado para liveness probes fazerem a verificação de integridade do etcd
  /apiserver-etcd-client       Gera o certificado que o servidor da API utiliza para comunicar-se com o etcd
  /sa                          Gera uma chave privada para assinatura de tokens de conta de serviço, juntamente com sua chave pública
kubeconfig                   Gera todos os arquivos kubeconfig necessários para estabelecer a camada de gerenciamento e o arquivo kubeconfig de administração
  /admin                       Gera um arquivo kubeconfig para o administrador e o próprio kubeadm utilizarem
  /kubelet                     Gera um arquivo kubeconfig para o kubelet utilizar *somente* para fins de inicialização do cluster
  /controller-manager          Gera um arquivo kubeconfig para o gerenciador de controladores utilizar
  /scheduler                   Gera um arquivo kubeconfig para o escalonador do Kubernetes utilizar
kubelet-start                Escreve as configurações do kubelet e (re)inicializa o kubelet
control-plane                Gera todos os manifestos de Pods estáticos necessários para estabelecer a camada de gerenciamento
  /apiserver                   Gera o manifesto do Pod estático do kube-apiserver
  /controller-manager          Gera o manifesto do Pod estático do kube-controller-manager
  /scheduler                   Gera o manifesto do Pod estático do kube-scheduler
etcd                         Gera o manifesto do Pod estático para um etcd local
  /local                       Gera o manifesto do Pod estático para uma instância local e de nó único do etcd
upload-config                Sobe a configuração do kubeadm e do kubelet para um ConfigMap
  /kubeadm                     Sobe a configuração ClusterConfiguration do kubeadm para um ConfigMap
  /kubelet                     Sobe a configuração do kubelet para um ConfigMap
upload-certs                 Sobe os certificados para o kubeadm-certs
mark-control-plane           Marca um nó como parte da camada de gerenciamento
bootstrap-token              Gera tokens de autoinicialização utilizados para associar um nó a um cluster
kubelet-finalize             Atualiza configurações relevantes ao kubelet após a inicialização TLS
  /experimental-cert-rotation  Habilita rotação de certificados do cliente do kubelet
addon                        Instala os addons requeridos para passar nos testes de conformidade
  /coredns                     Instala o addon CoreDNS em um cluster Kubernetes
  /kube-proxy                  Instala o addon kube-proxy em um cluster Kubernetes

kubeadm init [flags]

Opções

Opções herdadas de comandos superiores

1.24 -

Rode este comando em qualquer máquina que você deseje adicionar a um cluster existente

Sinopse

Ao associar um novo nó a um cluster inicializado com kubeadm, temos que estabelecer a confiança bidirecional. Este processo é dividido entre a descoberta (em que o nó estabelece a confiança na camada de gerenciamento do Kubernetes) e a inicialização TLS (em que a camada de gerenciamento do Kubernetes estabelece a confiança no nó).

Existem duas principais formas de descoberta. A primeira delas é o uso de um token compartilhado, juntamente com o endereço IP do servidor da API. A segunda é o fornecimento de um arquivo - um subconjunto do arquivo kubeconfig padrão. O arquivo de descoberta/kubeconfig suporta autenticação por token, plugins de autenticação do client-go ("exec"), "tokenFile" e "authProvider". Este arquivo pode ser um arquivo local ou um arquivo baixado através de uma URL HTTPS. Os formatos são kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443, kubeadm join --discovery-file caminho/para/arquivo.conf, ou kubeadm join --discovery-file https://endereco/arquivo.conf. Somente um formato pode ser utilizado. Se os dados para a descoberta são carregados de uma URL, o protocolo HTTPS deve ser utilizado. Neste caso, o conjunto de CAs instalado no host é utilizado para verificar a conexão.

Se você utilizou um token compartilhado para descoberta, você deve também passar a opção --discovery-token-ca-cert-hash para validar a chave pública da autoridade de certificação raiz (CA) apresentada pela camada de gerenciamento do Kubernetes. O valor desta opção é especificado no formato "<tipo-de-hash>:<valor-codificado-em-hexadecimal>", onde o tipo de hash suportado é "sha256". O hash é calculado a partir dos bytes do objeto Subject Public Key Info (SPKI), como especificado pela RFC7469. Este valor fica disponível na saída do comando kubeadm init ou pode ser calculado utilizando ferramentas padronizadas. A opção --discovery-token-ca-cert-hash pode ser especificada múltiplas vezes para permitir informar mais que uma chave pública.

Se você não puder obter o hash da chave pública da autoridade de certificação de antemão, você pode passar a opção --discovery-token-unsafe-skip-ca-verification para desabilitar esta verificação. Esta opção enfraquece o modelo de segurança do kubeadm, já que outros nós podem potencialmente personificar a camada de gerenciamento do Kubernetes.

O mecanismo de inicialização TLS também é conduzido por um token compartilhado. Este token é utilizado para temporariamente autenticar-se com a camada de gerenciamento do Kubernetes para enviar uma requisição de assinatura de certificado (CSR) para um par de chaves criado localmente. Por padrão, o kubeadm irá configurar a camada de gerenciamento do Kubernetes para automaticamente aprovar estas requisições de assinatura. O token é enviado através da opção --tls-bootstrap-token abcdef.1234567890abcdef.

Frequentemente, o mesmo token é utilizado para ambas as partes. Neste caso, a opção --token pode ser utilizada ao invés de especificar cada token individualmente.

O comando join [api-server-endpoint] executa as seguintes fases:

preflight               Executa as verificações pré-execução
control-plane-prepare   Prepara a máquina para servir um nó da camada de gerenciamento
  /download-certs        [EXPERIMENTAL] Baixa certificados compartilhados entre nós da camada de gerenciamento do Secret kubeadm-certs
  /certs                 Gera os certificados para os novos componentes da camada de gerenciamento
  /kubeconfig            Gera o arquivo kubeconfig para os novos componentes da camada de gerenciamento
  /control-plane         Gera os manifestos para os novos componentes da camada de gerenciamento
kubelet-start          Escreve as configurações do kubelet, os certificados, e (re)inicia o kubelet
control-plane-join     Associa uma máquina como uma instância da camada de gerenciamento
  /etcd                  Adiciona como um novo membro do etcd local
  /update-status         Registra o novo nó da camada de gerenciamento no objeto ClusterStatus mantido no ConfigMap kubeadm-config (DESCONTINUADO)
  /mark-control-plane    Marca um nó como nó da camada de gerenciamento

kubeadm join [api-server-endpoint] [flags]

Opções

Opções herdadas dos comandos superiores

1.25 -

Utilitários de arquivo Kubeconfig

Sinopse

Utilitários de arquivo Kubeconfig.

Opções

Opções herdadas do comando superior

1.26 -

Saída do arquivo kubeconfig para um usuário adicional.

Sinopse

Exibe o arquivo kubeconfig para um usuário adicional.

kubeadm kubeconfig user [flags]

Exemplos

  # Exibe um arquivo kubeconfig para um usuário adicional chamado foo usando um arquivo bar de configuração
  kubeadm kubeconfig user --client-name=foo --config=bar

Opções

Opções herdadas do comando superior

1.27 -

Executa o melhor esforço para reverter as alterações feitas no host por 'kubeadm init' ou 'kubeadm join'

Sinopse

Executa o melhor esforço para reverter as alterações feitas no host por 'kubeadm init' ou 'kubeadm join'

O comando "reset" executa as seguintes fases:

preflight           Executa as verificações pré-execução do preflight.
remove-etcd-member  Remove um membro etcd local.
cleanup-node        Executa a limpeza do nó.

kubeadm reset [flags]

Opções

Opções herdadas do comando superior

1.28 -

Crie tokens de inicialização no servidor

Sinopse

Este comando criará um token de inicialização. Você pode especificar os usos para este token, o "tempo de vida" e uma descrição amigável, que é opcional.

O [token] é o token real para gravar. Este deve ser um token aleatório gerado com segurança da forma "[a-z0-9]{6}.[a-z0-9]{16}". Se nenhum [token] for fornecido, o kubeadm gerará um token aleatório.

kubeadm token create [token]

Opções

Opções herdadas dos comandos superiores

1.29 -

Excluir tokens de inicialização no servidor

Sinopse

Este comando excluirá uma lista de tokens de inicialização para você.

O [token-value] é um Token completo na forma "[a-z0-9]{6}.[a-z0-9]{16}" ou o ID do Token na forma "[a-z0-9]{6}" a ser excluído.

kubeadm token delete [token-value] ...

Opções

Opções herdadas dos comandos superiores

1.30 -

Gere e exiba um token de inicialização, mas não o crie no servidor

Sinopse

Este comando exibirá um token de inicialização gerado aleatoriamente que pode ser usado com os comandos "init" e "join".

Você não precisa usar este comando para gerar um token. Você pode fazer isso sozinho, desde que esteja no formato "[a-z0-9]{6}.[a-z0-9]{16}". Este comando é fornecido por conveniência para gerar tokens no formato fornecido.

Você também pode usar "kubeadm init" sem especificar um token e ele gerará e exibirá um para você.

kubeadm token generate [flags]

Opções

Opções herdadas dos comandos superiores

1.31 -

Liste tokens de inicialização no servidor

Sinopse

Este comando listará todos os tokens de inicialização para você

kubeadm token list [flags]

Opções

Opções herdadas dos comandos superiores

1.32 -

Atualiza o cluster Kubernetes para uma versão específica

Sinopse

Atualiza o cluster Kubernetes para uma versão específica

kubeadm upgrade apply [versão]

Opções

Opções herdadas de comandos superiores

1.33 -

Mostra quais diferenças serão aplicadas aos manifestos dos Pods estáticos existentes. Veja também: kubeadm upgrade apply --dry-run

Sinopse

Mostra quais diferenças serão aplicadas aos manifestos dos Pods estáticos existentes. Veja também: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [versão] [flags]

Opções

Opções herdadas de comandos superiores

1.34 -

Comando para atualização de um nó no cluster

Sinopse

Comando para atualização de um nó no cluster

O comando "node" executa as seguintes fases:

preflight       Executa as verificações de pré-atualização do nó
control-plane   Atualiza a instância da camada de gerenciamento implantada neste nó, se houver
kubelet-config  Atualiza a configuração do kubelet para este nó

kubeadm upgrade node [flags]

Opções

Opções herdadas de comandos superiores

1.35 -

Use este comando para invocar uma fase única do fluxo de trabalho do nó

Sinopse

Use este comando para invocar uma fase única do fluxo de trabalho do nó

Opções

Opções herdadas dos comandos superiores

1.36 -

Atualiza a instância da camada de gerenciamento instalada nesse nó, se houver

Sinopse

Atualiza a instância da camada de gerenciamento instalada nesse nó, se houver

kubeadm upgrade node phase control-plane [flags]

Opções

Opções herdadas dos comandos superiores

1.37 -

Atualize a configuração do kubelet para este nó

Sinopse

Baixa no cluster o ConfigMap de configuração do kubelet no formato "kubelet-config-1.X", onde X é a menor versão do kubelet. O kubeadm usa o campo KuberneteVersion no ConfigMap kubeadm-config para determinar qual é a versão desejada do kubelet.

kubeadm upgrade node phase kubelet-config [flags]

Opções

Opções herdadas dos comandos superiores

1.38 -

Execute verificações antes de atualização do nó

Sinopse

Execute verificações antes de atualização do nó

kubeadm upgrade node phase preflight [flags]

Opções

Opções herdadas dos comandos superiores

1.39 -

Verifique quais versões estão disponíveis para atualizar e verifique se o seu cluster atual é atualizável. Para pular a verificação da Internet, passe o parâmetro opcional [versão]

Sinopse

Verifique quais versões estão disponíveis para atualizar e verifique se o seu cluster atual é atualizável. Para pular a verificação da Internet, passe o parâmetro opcional [versão]

kubeadm upgrade plan [versão] [flags]

Opções

Opções herdadas de comandos superiores

1.40 -

Exibe a versão do kubeadm

Sinopse

Exibe a versão do kubeadm

kubeadm version [flags]

Opções

Opção herdada do comando superior

2 - kubeadm init

Este comando inicializa um nó da camada de gerenciamento do Kubernetes.

Rode este comando para configurar a camada de gerenciamento do Kubernetes

Sinopse

Rode este comando para configurar a camada de gerenciamento do Kubernetes

O comando "init" executa as fases abaixo:

preflight                    Efetua as verificações pré-execução
certs                        Geração de certificados
  /ca                          Gera a autoridade de certificação (CA) auto-assinada do Kubernetes para provisionamento de identidades para outros componentes do Kubernetes
  /apiserver                   Gera o certificado para o servidor da API do Kubernetes
  /apiserver-kubelet-client    Gera o certificado para o servidor da API se conectar ao Kubelet
  /front-proxy-ca              Gera a autoridade de certificação (CA) auto-assinada para provisionamento de identidades para o front proxy
  /front-proxy-client          Gera o certificado para o cliente do front proxy
  /etcd-ca                     Gera a autoridade de certificação (CA) auto-assinada para provisionamento de identidades para o etcd
  /etcd-server                 Gera o certificado para servir o etcd
  /etcd-peer                   Gera o certificado para comunicação entre nós do etcd
  /etcd-healthcheck-client     Gera o certificado para liveness probes fazerem a verificação de integridade do etcd
  /apiserver-etcd-client       Gera o certificado que o servidor da API utiliza para comunicar-se com o etcd
  /sa                          Gera uma chave privada para assinatura de tokens de conta de serviço, juntamente com sua chave pública
kubeconfig                   Gera todos os arquivos kubeconfig necessários para estabelecer a camada de gerenciamento e o arquivo kubeconfig de administração
  /admin                       Gera um arquivo kubeconfig para o administrador e o próprio kubeadm utilizarem
  /kubelet                     Gera um arquivo kubeconfig para o kubelet utilizar *somente* para fins de inicialização do cluster
  /controller-manager          Gera um arquivo kubeconfig para o gerenciador de controladores utilizar
  /scheduler                   Gera um arquivo kubeconfig para o escalonador do Kubernetes utilizar
kubelet-start                Escreve as configurações do kubelet e (re)inicializa o kubelet
control-plane                Gera todos os manifestos de Pods estáticos necessários para estabelecer a camada de gerenciamento
  /apiserver                   Gera o manifesto do Pod estático do kube-apiserver
  /controller-manager          Gera o manifesto do Pod estático do kube-controller-manager
  /scheduler                   Gera o manifesto do Pod estático do kube-scheduler
etcd                         Gera o manifesto do Pod estático para um etcd local
  /local                       Gera o manifesto do Pod estático para uma instância local e de nó único do etcd
upload-config                Sobe a configuração do kubeadm e do kubelet para um ConfigMap
  /kubeadm                     Sobe a configuração ClusterConfiguration do kubeadm para um ConfigMap
  /kubelet                     Sobe a configuração do kubelet para um ConfigMap
upload-certs                 Sobe os certificados para o kubeadm-certs
mark-control-plane           Marca um nó como parte da camada de gerenciamento
bootstrap-token              Gera tokens de autoinicialização utilizados para associar um nó a um cluster
kubelet-finalize             Atualiza configurações relevantes ao kubelet após a inicialização TLS
  /experimental-cert-rotation  Habilita rotação de certificados do cliente do kubelet
addon                        Instala os addons requeridos para passar nos testes de conformidade
  /coredns                     Instala o addon CoreDNS em um cluster Kubernetes
  /kube-proxy                  Instala o addon kube-proxy em um cluster Kubernetes

kubeadm init [flags]

Opções

Opções herdadas de comandos superiores

Fluxo do comando Init

O comando kubeadm init inicializa um nó da camada de gerenciamento do Kubernetes através da execução dos passos abaixo:

1. Roda uma série de verificações pré-execução para validar o estado do sistema antes de efetuar mudanças. Algumas verificações emitem apenas avisos, outras são consideradas erros e cancelam a execução do kubeadm até que o problema seja corrigido ou que o usuário especifique a opção --ignore-preflight-errors=<lista-de-erros-a-ignorar>.

2. Gera uma autoridade de certificação (CA) auto-assinada para criar identidades para cada um dos componentes do cluster. O usuário pode informar seu próprio certificado CA e/ou chave ao instalar estes arquivos no diretório de certificados configurado através da opção --cert-dir (por padrão, este diretório é /etc/kubernetes/pki). Os certificados do servidor da API terão entradas adicionais para nomes alternativos (subject alternative names, ou SANs) especificados através da opção --apiserver-cert-extra-sans. Estes argumentos serão modificados para caracteres minúsculos quando necessário.

3. Escreve arquivos kubeconfig adicionais no diretório /etc/kubernetes para o kubelet, para o gerenciador de controladores e para o escalonador utilizarem ao conectarem-se ao servidor da API, cada um com sua própria identidade, bem como um arquivo kubeconfig adicional para administração do cluster chamado admin.conf.

4. Gera manifestos de Pods estáticos para o servidor da API, para o gerenciador de controladores e para o escalonador. No caso de uma instância externa do etcd não ter sido providenciada, um manifesto de Pod estático adicional é gerado para o etcd.

   Manifestos de Pods estáticos são escritos no diretório /etc/kubernetes/manifests; o kubelet lê este diretório em busca de manifestos de Pods para criar na inicialização.

   Uma vez que os Pods da camada de gerenciamento estejam criados e rodando, a sequência de execução do comando kubeadm init pode continuar.

5. Aplica labels e taints ao nó da camada de gerenciamento de modo que cargas de trabalho adicionais não sejam escalonadas para executar neste nó.

6. Gera o token que nós adicionais podem utilizar para associarem-se a uma camada de gerenciamento no futuro. Opcionalmente, o usuário pode fornecer um token através da opção --token, conforme descrito na documentação do comando kubeadm token.

7. Prepara todas as configurações necessárias para permitir que nós se associem ao cluster utilizando os mecanismos de Tokens de Inicialização e Inicialização TLS:

   • Escreve um ConfigMap para disponibilizar toda a informação necessária para associar-se a um cluster e para configurar regras de controle de acesso baseada em funções (RBAC).

   • Permite o acesso dos tokens de inicialização à API de assinaturas CSR.

   • Configura a auto-aprovação de novas requisições CSR.

   Para mais informações, consulte kubeadm join.

8. Instala um servidor DNS (CoreDNS) e os componentes adicionais do kube-proxy através do servidor da API. A partir da versão 1.11 do Kubernetes, CoreDNS é o servidor DNS padrão. Mesmo que o servidor DNS seja instalado nessa etapa, o seu Pod não será escalonado até que um CNI seja instalado.

   Aviso: O uso do kube-dns com o kubeadm foi descontinuado na versão v1.18 e removido na versão v1.21 do Kubernetes.

Utilizando fases de inicialização com o kubeadm

O kubeadm permite que você crie um nó da camada de gerenciamento em fases utilizando o comando kubeadm init phase.

Para visualizar a lista ordenada de fases e subfases, você pode rodar o comando kubeadm init --help. A lista estará localizada no topo da ajuda e cada fase tem sua descrição listada juntamente com o comando. Perceba que ao rodar o comando kubeadm init todas as fases e subfases são executadas nesta ordem exata.

Algumas fases possuem flags específicas. Caso você deseje ver uma lista de todas as opções disponíveis, utilize a flag --help. Por exemplo:

sudo kubeadm init phase control-plane controller-manager --help

Você também pode utilizar a flag --help para ver uma lista de subfases de uma fase superior:

sudo kubeadm init phase control-plane --help

kubeadm init também expõe uma flag chamada --skip-phases que pode ser utilizada para pular a execução de certas fases. Esta flag aceita uma lista de nomes de fases. Os nomes de fases aceitos estão descritos na lista ordenada acima.

Um exemplo:

sudo kubeadm init phase control-plane all --config=configfile.yaml
sudo kubeadm init phase etcd local --config=configfile.yaml
# agora você pode modificar os manifestos da camada de gerenciamento e do etcd
sudo kubeadm init --skip-phases=control-plane,etcd --config=configfile.yaml

O que este exemplo faz é escrever os manifestos da camada de gerenciamento e do etcd no diretório /etc/kubernetes/manifests, baseados na configuração descrita no arquivo configfile.yaml. Isto permite que você modifique os arquivos e então pule estas fases utilizando a opção --skip-phases. Ao chamar o último comando, você cria um nó da camada de gerenciamento com os manifestos personalizados.

Como alternativa, você pode também utilizar o campo skipPhases na configuração InitConfiguration.

Utilizando kubeadm init com um arquivo de configuração

É possível configurar o comando kubeadm init com um arquivo de configuração ao invés de argumentos de linha de comando, e algumas funcionalidades mais avançadas podem estar disponíveis apenas como opções do arquivo de configuração. Este arquivo é fornecido utilizando a opção --config e deve conter uma estrutura ClusterConfiguration e, opcionalmente, mais estruturas separadas por ---\n. Combinar a opção --config com outras opções de linha de comando pode não ser permitido em alguns casos.

A configuração padrão pode ser emitida utilizando o comando kubeadm config print.

Se a sua configuração não estiver utilizando a última versão, é recomendado que você migre utilizando o comando kubeadm config migrate.

Para mais informações sobre os campos e utilização da configuração, você pode consultar a página de referência da API.

Utilizando kubeadm init com feature gates

O kubeadm suporta um conjunto de feature gates que são exclusivos do kubeadm e podem ser utilizados somente durante a criação de um cluster com kubeadm init. Estas funcionalidades podem controlar o comportamento do cluster. Os feature gates são removidos assim que uma funcionalidade atinge a disponibilidade geral (general availability, ou GA).

Para informar um feature gate, você pode utilizar a opção --feature-gates do comando kubeadm init, ou pode adicioná-las no campo featureGates quando um arquivo de configuração é utilizado através da opção --config.

A utilização de feature gates dos componentes principais do Kubernetes com o kubeadm não é suportada. Ao invés disso, é possível enviá-los através da personalização de componentes com a API do kubeadm.

Lista dos feature gates:

Descrição dos feature gates:

PublicKeysECDSA

Pode ser utilizado para criar um cluster que utilize certificados ECDSA no lugar do algoritmo RSA padrão. A renovação dos certificados ECDSA existentes também é suportada utilizando o comando kubeadm certs renew, mas você não pode alternar entre os algoritmos RSA e ECDSA dinamicamente ou durante atualizações.

RootlessControlPlane

Quando habilitada esta opção, os componentes da camada de gerenciamento cuja instalação de Pods estáticos é controlada pelo kubeadm, como o kube-apiserver, kube-controller-manager, kube-scheduler e etcd, têm seus contêineres configurados para rodarem como usuários não-root. Se a opção não for habilitada, estes componentes são executados como root. Você pode alterar o valor deste feature gate antes de atualizar seu cluster para uma versão mais recente do Kubernetes.

UnversionedKubeletConfigMap

Esta opção controla o nome do ConfigMap onde o kubeadm armazena os dados de configuração do kubelet. Quando esta opção não for especificada ou estiver especificada com o valor true, o ConfigMap será nomeado kubelet-config. Caso esteja especificada com o valor false, o nome do ConfigMap incluirá as versões maior e menor do Kubernetes instalado (por exemplo, kubelet-config-1.30). O kubeadm garante que as regras de RBAC para leitura e escrita deste ConfigMap serão apropriadas para o valor escolhido. Quando o kubeadm cria este ConfigMap (durante a execução dos comandos kubeadm init ou kubeadm upgrade apply), o kubeadm irá respeitar o valor da opção UnversionedKubeletConfigMap. Quando tal ConfigMap for lido (durante a execução dos comandos kubeadm join, kubeadm reset, kubeadm upgrade...), o kubeadm tentará utilizar o nome do ConfigMap sem a versão primeiro. Se esta operação não for bem-sucedida, então o kubeadm irá utilizar o nome legado (versionado) para este ConfigMap.

Adicionando parâmetros do kube-proxy

Para informações sobre como utilizar parâmetros do kube-proxy na configuração do kubeadm, veja:

• referência do kube-proxy

Para informações sobre como habilitar o modo IPVS com o kubeadm, veja:

• IPVS

Informando opções personalizadas em componentes da camada de gerenciamento

Para informações sobre como passar as opções aos componentes da camada de gerenciamento, veja:

• opções da camada de gerenciamento

Executando o kubeadm sem uma conexão à internet

Para executar o kubeadm sem uma conexão à internet, você precisa baixar as imagens de contêiner requeridas pela camada de gerenciamento.

Você pode listar e baixar as imagens utilizando o subcomando kubeadm config images:

kubeadm config images list
kubeadm config images pull

Você pode passar a opção --config para os comandos acima através de um arquivo de configuração do kubeadm para controlar os campos kubernetesVersion e imageRepository.

Todas as imagens padrão hospedadas em registry.k8s.io que o kubeadm requer suportam múltiplas arquiteturas.

Utilizando imagens personalizadas

Por padrão, o kubeadm baixa imagens hospedadas no repositório de contêineres registry.k8s.io. Se a versão requisitada do Kubernetes é um rótulo de integração contínua (por exemplo, ci/latest), o repositório de contêineres gcr.io/k8s-staging-ci-images é utilizado.

Você pode sobrescrever este comportamento utilizando o kubeadm com um arquivo de configuração. Personalizações permitidas são:

• Fornecer um valor para o campo kubernetesVersion que afeta a versão das imagens.
• Fornecer um repositório de contêineres alternativo através do campo imageRepository para ser utilizado no lugar de registry.k8s.io.
• Fornecer um valor específico para os campos imageRepository e imageTag, correspondendo ao repositório de contêineres e tag a ser utilizada, para as imagens dos componentes etcd ou CoreDNS.

Caminhos de imagens do repositório de contêineres padrão registry.k8s.io podem diferir dos utilizados em repositórios de contêineres personalizados através do campo imageRepository devido a razões de retrocompatibilidade. Por exemplo, uma imagem pode ter um subcaminho em registry.k8s.io/subcaminho/imagem, mas quando utilizado um repositório de contêineres personalizado, o valor padrão será meu.repositoriopersonalizado.io/imagem.

Para garantir que você terá as imagens no seu repositório personalizado em caminhos que o kubeadm consiga consumir, você deve:

• Baixar as imagens dos caminhos padrão registry.k8s.io utilizando o comando kubeadm config images {list|pull}.
• Subir as imagens para os caminhos listados no resultado do comando kubeadm config images list --config=config.yaml, onde config.yaml contém o valor customizado do campo imageRepository, e/ou imageTag para os componentes etcd e CoreDNS.
• Utilizar o mesmo arquivo config.yaml quando executar o comando kubeadm init.

Imagens personalizadas para o sandbox (imagem pause)

Para configurar uma imagem personalizada para o sandbox, você precisará configurar o agente de execução de contêineres para utilizar a imagem. Verifique a documentação para o seu agente de execução de contêineres para mais informações sobre como modificar esta configuração; para alguns agentes de execução de contêiner você também encontrará informações no tópico Agentes de Execução de Contêineres.

Carregando certificados da camada de gerenciamento no cluster

Ao adicionar a opção --upload-certs ao comando kubeadm init você pode subir temporariamente certificados da camada de gerenciamento em um Secret no cluster. Este Secret expira automaticamente após 2 horas. Os certificados são encriptados utilizando uma chave de 32 bytes que pode ser especificada através da opção --certificate-key. A mesma chave pode ser utilizada para baixar certificados quando nós adicionais da camada de gerenciamento estão se associando ao cluster, utilizando as opções --control-plane e --certificate-key ao rodar kubeadm join.

O seguinte comando de fase pode ser usado para subir os certificados novamente após a sua expiração:

kubeadm init phase upload-certs --upload-certs --certificate-key=ALGUM_VALOR --config=ALGUM_ARQUIVO_YAML

Se a opção --certificate-key não for passada aos comandos kubeadm init e kubeadm init phase upload-certs, uma nova chave será gerada automaticamente.

O comando abaixo pode ser utilizado para gerar uma nova chave sob demanda:

kubeadm certs certificate-key

Gerenciamento de certificados com o kubeadm

Para informações detalhadas sobre gerenciamento de certificados com o kubeadm, consulte Gerenciamento de Certificados com o kubeadm. O documento inclui informações sobre a utilização de autoridades de certificação (CA) externas, certificados personalizados e renovação de certificados.

Gerenciando o arquivo drop-in do kubeadm para o kubelet

O pacote kubeadm é distribuído com um arquivo de configuração para rodar o kubelet utilizando systemd. Note que o kubeadm nunca altera este arquivo. Este arquivo drop-in é parte do pacote DEB/RPM do kubeadm.

Para mais informações, consulte Gerenciando o arquivo drop-in do kubeadm para o systemd.

Usando o kubeadm com agentes de execução CRI

Por padrão, o kubeadm tenta detectar seu agente de execução de contêineres. Para mais detalhes sobre esta detecção, consulte o guia de instalação CRI do kubeadm.

Configurando o nome do nó

Por padrão, o kubeadm gera um nome para o nó baseado no endereço da máquina. Você pode sobrescrever esta configuração utilizando a opção --node-name. Esta opção passa o valor apropriado para a opção --hostname-override do kubelet.

Note que sobrescrever o hostname de um nó pode interferir com provedores de nuvem.

Automatizando o kubeadm

Ao invés de copiar o token que você obteve do comando kubeadm init para cada nó, como descrito no tutorial básico do kubeadm, você pode paralelizar a distribuição do token para facilitar a automação. Para implementar esta automação, você precisa saber o endereço IP que o nó da camada de gerenciamento irá ter após a sua inicialização, ou utilizar um nome DNS ou um endereço de um balanceador de carga.

1. Gere um token. Este token deve ter a forma <string de 6 caracteres>.<string de 16 caracteres>. Mais especificamente, o token precisa ser compatível com a expressão regular: [a-z0-9]{6}\.[a-z0-9]{16}.

   O kubeadm pode gerar um token para você:

    kubeadm token generate
   

2. Inicialize o nó da camada de gerenciamento e os nós de carga de trabalho de forma concorrente com este token. Conforme os nós forem iniciando, eles deverão encontrar uns aos outros e formar o cluster. O mesmo argumento --token pode ser utilizado em ambos os comandos kubeadm init e kubeadm join.

3. O mesmo procedimento pode ser feito para a opção --certificate-key quando nós adicionais da camada de gerenciamento associarem-se ao cluster. A chave pode ser gerada utilizando:

   kubeadm certs certificate-key
   

Uma vez que o cluster esteja inicializado, você pode buscar as credenciais para a camada de gerenciamento no caminho /etc/kubernetes/admin.conf e utilizá-las para conectar-se ao cluster.

Note que este tipo de inicialização tem algumas garantias de segurança relaxadas pois ele não permite que o hash do CA raiz seja validado com a opção --discovery-token-ca-cert-hash (pois este hash não é gerado quando os nós são provisionados). Para detalhes, veja a documentação do comando kubeadm join.

Próximos passos

• kubeadm init phase para entender mais sobre as fases do comando kubeadm init
• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster
• kubeadm upgrade para atualizar um cluster do Kubernetes para uma versão mais recente
• kubeadm reset para reverter quaisquer mudanças feitas neste host pelos comandos kubeadm init ou kubeadm join

3 - kubeadm join

Este comando inicializa um nó de processamento do Kubernetes e o associa ao cluster.

Rode este comando em qualquer máquina que você deseje adicionar a um cluster existente

Sinopse

Ao associar um novo nó a um cluster inicializado com kubeadm, temos que estabelecer a confiança bidirecional. Este processo é dividido entre a descoberta (em que o nó estabelece a confiança na camada de gerenciamento do Kubernetes) e a inicialização TLS (em que a camada de gerenciamento do Kubernetes estabelece a confiança no nó).

Existem duas principais formas de descoberta. A primeira delas é o uso de um token compartilhado, juntamente com o endereço IP do servidor da API. A segunda é o fornecimento de um arquivo - um subconjunto do arquivo kubeconfig padrão. O arquivo de descoberta/kubeconfig suporta autenticação por token, plugins de autenticação do client-go ("exec"), "tokenFile" e "authProvider". Este arquivo pode ser um arquivo local ou um arquivo baixado através de uma URL HTTPS. Os formatos são kubeadm join --discovery-token abcdef.1234567890abcdef 1.2.3.4:6443, kubeadm join --discovery-file caminho/para/arquivo.conf, ou kubeadm join --discovery-file https://endereco/arquivo.conf. Somente um formato pode ser utilizado. Se os dados para a descoberta são carregados de uma URL, o protocolo HTTPS deve ser utilizado. Neste caso, o conjunto de CAs instalado no host é utilizado para verificar a conexão.

Se você utilizou um token compartilhado para descoberta, você deve também passar a opção --discovery-token-ca-cert-hash para validar a chave pública da autoridade de certificação raiz (CA) apresentada pela camada de gerenciamento do Kubernetes. O valor desta opção é especificado no formato "<tipo-de-hash>:<valor-codificado-em-hexadecimal>", onde o tipo de hash suportado é "sha256". O hash é calculado a partir dos bytes do objeto Subject Public Key Info (SPKI), como especificado pela RFC7469. Este valor fica disponível na saída do comando kubeadm init ou pode ser calculado utilizando ferramentas padronizadas. A opção --discovery-token-ca-cert-hash pode ser especificada múltiplas vezes para permitir informar mais que uma chave pública.

Se você não puder obter o hash da chave pública da autoridade de certificação de antemão, você pode passar a opção --discovery-token-unsafe-skip-ca-verification para desabilitar esta verificação. Esta opção enfraquece o modelo de segurança do kubeadm, já que outros nós podem potencialmente personificar a camada de gerenciamento do Kubernetes.

O mecanismo de inicialização TLS também é conduzido por um token compartilhado. Este token é utilizado para temporariamente autenticar-se com a camada de gerenciamento do Kubernetes para enviar uma requisição de assinatura de certificado (CSR) para um par de chaves criado localmente. Por padrão, o kubeadm irá configurar a camada de gerenciamento do Kubernetes para automaticamente aprovar estas requisições de assinatura. O token é enviado através da opção --tls-bootstrap-token abcdef.1234567890abcdef.

Frequentemente, o mesmo token é utilizado para ambas as partes. Neste caso, a opção --token pode ser utilizada ao invés de especificar cada token individualmente.

O comando join [api-server-endpoint] executa as seguintes fases:

preflight               Executa as verificações pré-execução
control-plane-prepare   Prepara a máquina para servir um nó da camada de gerenciamento
  /download-certs        [EXPERIMENTAL] Baixa certificados compartilhados entre nós da camada de gerenciamento do Secret kubeadm-certs
  /certs                 Gera os certificados para os novos componentes da camada de gerenciamento
  /kubeconfig            Gera o arquivo kubeconfig para os novos componentes da camada de gerenciamento
  /control-plane         Gera os manifestos para os novos componentes da camada de gerenciamento
kubelet-start          Escreve as configurações do kubelet, os certificados, e (re)inicia o kubelet
control-plane-join     Associa uma máquina como uma instância da camada de gerenciamento
  /etcd                  Adiciona como um novo membro do etcd local
  /update-status         Registra o novo nó da camada de gerenciamento no objeto ClusterStatus mantido no ConfigMap kubeadm-config (DESCONTINUADO)
  /mark-control-plane    Marca um nó como nó da camada de gerenciamento

kubeadm join [api-server-endpoint] [flags]

Opções

Opções herdadas dos comandos superiores

Fluxo do comando join

O comando kubeadm join inicializa um nó de processamento ou um nó da camada de gerenciamento e o adiciona ao cluster. Esta ação consiste nos seguintes passos para nós de processamento:

1. O kubeadm baixa as informações necessárias do cluster através servidor da API. Por padrão, o token de autoinicialização e o hash da chave da autoridade de certificação (CA) são utilizados para verificar a autenticidade dos dados baixados. O certificado raiz também pode ser descoberto diretamente através de um arquivo ou URL.

2. Uma vez que as informações do cluster são conhecidas, o kubelet pode começar o processo de inicialização TLS.

   A inicialização TLS utiliza o token compartilhado para autenticar temporariamente com o servidor da API do Kubernetes a fim de submeter uma requisição de assinatura de certificado (certificate signing request, ou CSR); por padrão, a camada de gerenciamento assina essa requisição CSR automaticamente.

3. Por fim, o kubeadm configura o kubelet local para conectar no servidor da API com a identidade definitiva atribuída ao nó.

Para nós da camada de gerenciamento, passos adicionais são executados:

1. O download de certificados compartilhados por todos os nós da camada de gerenciamento (quando explicitamente solicitado pelo usuário).

2. Geração de manifestos, certificados e arquivo kubeconfig para os componentes da camada de gerenciamento.

3. Adição de um novo membro local do etcd.

Utilizando fases de associação com o kubeadm

O kubeadm permite que você associe um nó a um cluster em fases utilizando kubeadm join phase.

Para visualizar a lista ordenada de fases e subfases disponíveis, você pode executar o comando kubeadm join --help. A lista estará localizada no topo da tela da ajuda e cada fase terá uma descrição ao lado. Note que ao chamar kubeadm join todas as fases e subfases serão executadas nesta ordem exata.

Algumas fases possuem opções únicas, portanto, se você desejar ver uma lista das opções disponíveis, adicione a flag --help. Por exemplo:

kubeadm join phase kubelet-start --help

De forma semelhante ao comando kubeadm init phase, kubeadm join phase permite que você ignore uma lista de fases utilizando a opção --skip-phases.

Por exemplo:

sudo kubeadm join --skip-phases=preflight --config=config.yaml

Alternativamente, você pode utilizar o campo skipPhases no manifesto JoinConfiguration.

Descobrindo em qual autoridade de certificação (CA) do cluster confiar

A descoberta do kubeadm tem diversas opções, cada uma com suas próprias contrapartidas de segurança. O método correto para o seu ambiente depende de como você aprovisiona seus nós e as expectativas de segurança que você tem a respeito da rede e ciclo de vida dos seus nós.

Descoberta baseada em token com fixação da autoridade de certificação (CA)

Este é o modo padrão do kubeadm. Neste modo, o kubeadm baixa a configuração do cluster (incluindo a CA raiz) e a valida, utilizando o token, além de verificar que a chave pública da CA raiz corresponda ao hash fornecido e que o certificado do servidor da API seja válido sob a CA raiz.

O hash da chave pública da CA tem o formato sha256:<hash_codificado_em_hexa>. Por padrão, o valor do hash é retornado no comando kubeadm join impresso ao final da execução de kubeadm init ou na saída do comando kubeadm token create --print-join-command. Este hash é gerado em um formato padronizado (veja a RFC7469) e pode também ser calculado com ferramentas de terceiros ou sistemas de provisionamento. Por exemplo, caso deseje utilizar a ferramenta de linha de comando do OpenSSL:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

Exemplos de comandos kubeadm join:

Para nós de processamento:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef 1.2.3.4:6443

Para nós da camada de gerenciamento:

kubeadm join --discovery-token abcdef.1234567890abcdef --discovery-token-ca-cert-hash sha256:1234..cdef --control-plane 1.2.3.4:6443

Você também pode executar o comando join para um nó da camada de gerenciamento com a opção --certificate-key para copiar certificados para este nó, caso o comando kubeadm init tenha sido executado com a opção --upload-certs.

Vantagens:

• Permite à inicialização dos nós descobrir uma raiz de confiança para a camada de gerenciamento mesmo que outros nós de processamento ou a rede estejam comprometidos.

• É conveniente para ser executado manualmente pois toda a informação requerida cabe num único comando kubeadm join.

Desvantagens:

• O hash da autoridade de certificação normalmente não está disponível até que a camada de gerenciamento seja aprovisionada, o que pode tornar mais difícil a criação de ferramentas de aprovisionamento automatizadas que utilizem o kubeadm. Uma alternativa para evitar esta limitação é gerar sua autoridade de certificação de antemão.

Descoberta baseada em token sem fixação da autoridade de certificação (CA)

Este modo depende apenas do token simétrico para assinar (HMAC-SHA256) a informação de descoberta que estabelece a raiz de confiança para a camada de gerenciamento. Para utilizar este modo, os nós que estão se associando ao cluster devem ignorar a validação do hash da chave pública da autoridade de certificação, utilizando a opção --discovery-token-unsafe-skip-ca-verification. Você deve considerar o uso de um dos outros modos quando possível.

Exemplo de comando kubeadm join:

kubeadm join --token abcdef.1234567890abcdef --discovery-token-unsafe-skip-ca-verification 1.2.3.4:6443

Vantagens:

• Ainda protege de muitos ataques a nível de rede.

• O token pode ser gerado de antemão e compartilhado com os nós da camada de gerenciamento e de processamento, que por sua vez podem inicializar-se em paralelo, sem coordenação. Isto permite que este modo seja utilizado em muitos cenários de aprovisionamento.

Desvantagens:

• Se um mau ator conseguir roubar um token de inicialização através de algum tipo de vulnerabilidade, este mau ator conseguirá utilizar o token (juntamente com accesso a nível de rede) para personificar um nó da camada de gerenciamento perante os outros nós de processamento. Esta contrapartida pode ou não ser aceitável no seu ambiente.

Descoberta baseada em arquivos ou HTTPS

Este modo fornece uma maneira alternativa de estabelecer uma raiz de confiança entre os nós da camada de gerenciamento e os nós de processamento. Considere utilizar este modo se você estiver construindo uma infraestrutura de aprovisionamento automático utilizando o kubeadm. O formato do arquivo de descoberta é um arquivo kubeconfig comum do Kubernetes.

Caso o arquivo de descoberta não contenha credenciais, o token de descoberta TLS será utilizado.

Exemplos de comandos kubeadm join:

• kubeadm join --discovery-file caminho/para/arquivo.conf (arquivo local)

• kubeadm join --discovery-file https://endereco/arquivo.conf (URL HTTPS remota)

Vantagens:

• Permite à inicialização dos nós descobrir uma raiz de confiança de forma segura para que a camada de gerenciamento utilize mesmo que a rede ou outros nós de processamento estejam comprometidos.

Desvantagens:

• Requer que você tenha uma forma de carregar a informação do nó da camada de gerenciamento para outros nós em inicialização. Se o arquivo de descoberta contém credenciais, você precisa mantê-lo secreto e transferi-lo através de um canal de comunicação seguro. Isto pode ser possível através do seu provedor de nuvem ou ferramenta de aprovisionamento.

Tornando sua instalação ainda mais segura

Os valores padrão de instalação do kubeadm podem não funcionar para todos os casos de uso. Esta seção documenta como tornar uma instalação mais segura, ao custo de usabilidade.

Desligando a auto-aprovação de certificados de cliente para nós

Por padrão, um auto-aprovador de requisições CSR está habilitado. Este auto-aprovador irá aprovar quaisquer requisições de certificado de cliente para um kubelet quando um token de autoinicialização for utilizado para autenticação. Se você não deseja que o cluster aprove automaticamente certificados de cliente para os kubelets, você pode desligar a auto-aprovação com o seguinte comando:

kubectl delete clusterrolebinding kubeadm:node-autoapprove-bootstrap

Após o desligamento da auto-aprovação, o comando kubeadm join irá aguardar até que o administrador do cluster aprove a requisição CSR:

1. Utilizando o comando kubeadm get csr, você verá que o CSR original está em estado pendente.

   kubectl get csr
   

   A saída é semelhante a:

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   18s       system:bootstrap:878f07   Pending
   

2. O comando kubectl certificate approve permite ao administrador aprovar o CSR. Esta ação informa ao controlador de assinatura de certificados que este deve emitir um certificado para o requerente com os atributos requeridos no CSR.

   kubectl certificate approve node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ
   

   A saída é semelhante a:

   certificatesigningrequest "node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ" approved
   

3. Este comando muda o estado do objeto CSR para o estado ativo.

   kubectl get csr
   

   A saída é semelhante a:

   NAME                                                   AGE       REQUESTOR                 CONDITION
   node-csr-c69HXe7aYcqkS1bKmH4faEnHAWxn6i2bHZ2mD04jZyQ   1m        system:bootstrap:878f07   Approved,Issued
   

Esta mudança força com que o fluxo do comando kubeadm join seja bem-sucedido somente quando o comando kubectl certificate approve for executado.

Desligando o acesso público ao ConfigMap cluster-info

Para que o fluxo de associação de um nó ao cluster seja possível utilizando somente um token como a única informação necessária para validação, um ConfigMap com alguns dados necessários para validação da identidade do nó da camada de gerenciamento é exposto publicamente por padrão. Embora nenhum dado deste ConfigMap seja privado, alguns usuários ainda podem preferir bloquear este acesso. Mudar este acesso bloqueia a habilidade de utilizar a opção --discovery-token do fluxo do comando kubeadm join. Para desabilitar este acesso:

• Obtenha o arquivo cluster-info do servidor da API:

kubectl -n kube-public get cm cluster-info -o jsonpath='{.data.kubeconfig}' | tee cluster-info.yaml

A saída é semelhante a:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <ca-cert>
    server: https://<ip>:<port>
  name: ""
contexts: []
current-context: ""
preferences: {}
users: []

• Utilize o arquivo cluster-info.yaml como um argumento para o comando kubeadm join --discovery-file.

• Desligue o acesso público ao ConfigMap cluster-info:

kubectl -n kube-public delete rolebinding kubeadm:bootstrap-signer-clusterinfo

Estes comandos devem ser executados após kubeadm init, mas antes de kubeadm join.

Utilizando kubeadm join com um arquivo de configuração

É possível configurar o comando kubeadm join apenas com um arquivo de configuração, em vez de utilizar opções de linha de comando, e algumas funcionalidades avançadas podem estar disponíveis somente como opções no arquivo de configuração. Este arquivo é passado através da opção --config e deve conter uma estrutura JoinConfiguration. A utilização da opção --config com outras opções da linha de comando pode não ser permitida em alguns casos.

A configuração padrão pode ser emitida utilizando o comando kubeadm config print.

Caso sua configuração não esteja utilizando a versão mais recente, é recomendado que você migre utilizando o comando kubeadm config migrate.

Para mais informações sobre os campos e utilização da configuração você pode consultar a referência da API.

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes.
• kubeadm token para gerenciar tokens utilizados no comando kubeadm join.
• kubeadm reset para reverter quaisquer mudanças feitas nesta máquina pelos comandos kubeadm init ou kubeadm join.

4 - kubeadm upgrade

kubeadm upgrade é um comando amigável que envolve uma lógica de atualização complexa por trás de um comando, com suporte para planejar e executar de fato uma atualização.

Guia do kubeadm upgrade

As etapas para realizar uma atualização usando kubeadm estão descritas neste documento. Para versões mais antigas do kubeadm, consulte os conjuntos de documentação mais antigos do site Kubernetes.

Você pode usar kubeadm upgrade diff para ver as alterações que seriam aplicadas aos manifestos de Pod estático.

No Kubernetes v1.15.0 e posteriores, o kubeadm upgrade apply e kubeadm upgrade node também renovarão automaticamente os certificados gerenciados pelo kubeadm neste nó, incluindo aqueles armazenados nos arquivos do kubeconfig. É possível optar por não renovar usando a flag --certificate-renewal=false. Para mais detalhes sobre a renovação dos certificados, consulte a documentação de gerenciamento de certificados.

kubeadm upgrade plan

Verifique quais versões estão disponíveis para atualizar e verifique se o seu cluster atual é atualizável. Para pular a verificação da Internet, passe o parâmetro opcional [versão]

Sinopse

Verifique quais versões estão disponíveis para atualizar e verifique se o seu cluster atual é atualizável. Para pular a verificação da Internet, passe o parâmetro opcional [versão]

kubeadm upgrade plan [versão] [flags]

Opções

Opções herdadas de comandos superiores

kubeadm upgrade apply

Atualiza o cluster Kubernetes para uma versão específica

Sinopse

Atualiza o cluster Kubernetes para uma versão específica

kubeadm upgrade apply [versão]

Opções

Opções herdadas de comandos superiores

kubeadm upgrade diff

Mostra quais diferenças serão aplicadas aos manifestos dos Pods estáticos existentes. Veja também: kubeadm upgrade apply --dry-run

Sinopse

Mostra quais diferenças serão aplicadas aos manifestos dos Pods estáticos existentes. Veja também: kubeadm upgrade apply --dry-run

kubeadm upgrade diff [versão] [flags]

Opções

Opções herdadas de comandos superiores

kubeadm upgrade node

Comando para atualização de um nó no cluster

Sinopse

Comando para atualização de um nó no cluster

O comando "node" executa as seguintes fases:

preflight       Executa as verificações de pré-atualização do nó
control-plane   Atualiza a instância da camada de gerenciamento implantada neste nó, se houver
kubelet-config  Atualiza a configuração do kubelet para este nó

kubeadm upgrade node [flags]

Opções

Opções herdadas de comandos superiores

Próximos passos

• kubeadm config se você inicializou seu cluster usando kubeadm v1.7.x ou inferior, para configurar seu cluster para kubeadm upgrade

5 - kubeadm config

Durante o kubeadm init, o kubeadm carrega o objeto ClusterConfiguration para o seu cluster em um ConfigMap chamado kubeadm-config no namespace do kube-system. Essa configuração é então lida durante kubeadm join, kubeadm reset e kubeadm upgrade.

Você pode usar o kubeadm config print para exibir a configuração estática padrão que o kubeadm usa para o kubeadm init e kubeadm join.

Para obter mais informações sobre init e join, navegue até Usando o kubeadm init com um arquivo de configuração ou Usando o kubeadm join com um arquivo de configuração.

Para obter mais informações sobre como usar a API de configuração do kubeadm, navegue até Personalizando componentes com a API do kubeadm..

Você pode usar o kubeadm config migrate para converter seus arquivos de configuração antigos que contêm uma versão obsoleta da API para uma versão mais recente e suportada da API.

kubeadm config images list e kubeadm config images pull podem ser usadas para listar e baixar as imagens que o kubeadm precisa.

kubeadm config print

Exibe configurações

Sinopse

Este comando exibe as configurações para subcomandos fornecidos. Para mais detalhes, consulte: https://pkg.go.dev/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#section-directories

kubeadm config print [flags]

Opções

Opções herdadas do comando superior

kubeadm config print init-defaults

Exibe a configuração de inicialização padrão, que pode ser usada para 'kubeadm init'

Sinopse

Este comando exibe objetos, como a configuração de inicialização padrão que é usada para 'kubeadm init'.

Observe que os valores confidenciais, como os campos do Token Bootstrap, são substituídos por valores de exemplo como "abcdef.0123456789abcdef", a fim de passar na validação, mas não executar o cálculo real para criar um token.

kubeadm config print init-defaults [flags]

Opções

Opções herdadas do comando superior

kubeadm config print join-defaults

Exibe a configuração padrão do join, que pode ser usada para 'kubeadm join'

Sinopse

Este comando exibe objetos como a configuração padrão de join que é usada para 'kubeadm join'.

Observe que valores confidenciais, como os campos do Token Bootstrap, são substituídos por valores de exemplo como "abcdef.0123456789abcdef", a fim de passar na validação, mas não executar o cálculo real para criar um token.

kubeadm config print join-defaults [flags]

Opções

Opções herdadas do comando superior

kubeadm config migrate

Leia uma versão mais antiga dos tipos de API de configuração do kubeadm a partir de um arquivo e envie o objeto de configuração semelhante para a versão mais recente

Sinopse

Esse comando permite converter objetos de configuração de versões mais antigas para a versão mais recente suportada, localmente na ferramenta CLI sem nunca tocar em nada no cluster. Nesta versão do kubeadm, as seguintes versões da API são suportadas:

• Kubeadm.k8s.io/v1beta3

Além disso, o kubeadm só pode escrever a configuração da versão "kubeadm.k8s.io/v1beta3", mas pode ler os dois tipos. Portanto, independentemente da versão que você passar para o parâmetro --old-config , o objeto API será lido, desserializado, padronizado, convertido, validado e serializado novamente quando escrito no stdout ou --new-config, se especificado.

Em outras palavras, a saída deste comando é o que o kubeadm realmente leria internamente se você enviasse este arquivo para "kubeadm init"

kubeadm config migrate [flags]

Opções

Opções herdadas do comando superior

kubeadm config images list

Exibe uma lista de imagens que o kubeadm usará. O arquivo de configuração é usado caso quaisquer imagens ou repositórios de imagens sejam personalizados.

Sinopse

Exibe uma lista de imagens que o kubeadm usará. O arquivo de configuração é usado caso quaisquer imagens ou repositórios de imagens sejam personalizados.

kubeadm config images list [flags]

Opções

Opções herdadas do comando superior

kubeadm config images pull

Puxe imagens usadas pelo kubeadm

Sinopse

Baixa imagens usadas pelo kubeadm

kubeadm config images pull [flags]

Opções

Opções herdadas do comando superior

Próximos passos

• kubeadm upgrade para atualizar um cluster Kubernetes para uma versão mais recente

6 - kubeadm reset

Executa o melhor esforço para reverter as alterações feitas pelo kubeadm init ou kubeadm join.

Executa o melhor esforço para reverter as alterações feitas no host por 'kubeadm init' ou 'kubeadm join'

Sinopse

Executa o melhor esforço para reverter as alterações feitas no host por 'kubeadm init' ou 'kubeadm join'

O comando "reset" executa as seguintes fases:

preflight           Executa as verificações pré-execução do preflight.
remove-etcd-member  Remove um membro etcd local.
cleanup-node        Executa a limpeza do nó.

kubeadm reset [flags]

Opções

Opções herdadas do comando superior

Fluxo de execução do comando reset

O kubeadm reset é o responsável por limpar o sistema de arquivos local dos nós a partir dos arquivos que foram criados usando os comandos kubeadm init ou kubeadm join. O reset dos nós da camanda de gerenciamento também remove o etcd local do nó do cluster etcd.

O kubeadm reset phase pode ser usado para executar separadamente as fases do fluxo de trabalho acima. Para pular uma lista de fases você pode usar --skip-phases, que funciona de maneira semelhante aos executores de fases dos comandos kubeadm join e kubeadm init.

Limpeza do etcd externo

O kubeadm reset não excluirá nenhum dado do etcd se o etcd externo estiver em uso. Isso significa que, se você executar o kubeadm init novamente usando os mesmos etcd endpoints, verá o estado dos clusters anteriores.

Para limpar dados etcd, é recomendável que você use um cliente como etcdctl, tal como:

etcdctl del "" --prefix

Consulte a documentação do etcd para obter mais informações.

Próximos passos

• kubeadm init para inicializar um nó do plano de controle do Kubernetes
• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster

7 - kubeadm token

Os Bootstrap tokens são usados para estabelecer uma relação de confiança bidirecional entre um nó que se junta ao cluster e um nó do plano de controle, conforme descrito na autenticação com tokens de inicialização.

O kubeadm init cria um token inicial com um TTL de 24 horas. Os comandos a seguir permitem que você gerencie esse token e também crie e gerencie os novos.

kubeadm token create

Crie tokens de inicialização no servidor

Sinopse

Este comando criará um token de inicialização. Você pode especificar os usos para este token, o "tempo de vida" e uma descrição amigável, que é opcional.

O [token] é o token real para gravar. Este deve ser um token aleatório gerado com segurança da forma "[a-z0-9]{6}.[a-z0-9]{16}". Se nenhum [token] for fornecido, o kubeadm gerará um token aleatório.

kubeadm token create [token]

Opções

Opções herdadas dos comandos superiores

kubeadm token delete

Excluir tokens de inicialização no servidor

Sinopse

Este comando excluirá uma lista de tokens de inicialização para você.

O [token-value] é um Token completo na forma "[a-z0-9]{6}.[a-z0-9]{16}" ou o ID do Token na forma "[a-z0-9]{6}" a ser excluído.

kubeadm token delete [token-value] ...

Opções

Opções herdadas dos comandos superiores

kubeadm token generate

Gere e exiba um token de inicialização, mas não o crie no servidor

Sinopse

Este comando exibirá um token de inicialização gerado aleatoriamente que pode ser usado com os comandos "init" e "join".

Você não precisa usar este comando para gerar um token. Você pode fazer isso sozinho, desde que esteja no formato "[a-z0-9]{6}.[a-z0-9]{16}". Este comando é fornecido por conveniência para gerar tokens no formato fornecido.

Você também pode usar "kubeadm init" sem especificar um token e ele gerará e exibirá um para você.

kubeadm token generate [flags]

Opções

Opções herdadas dos comandos superiores

kubeadm token list

Liste tokens de inicialização no servidor

Sinopse

Este comando listará todos os tokens de inicialização para você

kubeadm token list [flags]

Opções

Opções herdadas dos comandos superiores

Próximos passos

• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster

8 - kubeadm version

Este comando exibe a versão do kubeadm.

Exibe a versão do kubeadm

Sinopse

Exibe a versão do kubeadm

kubeadm version [flags]

Opções

Opção herdada do comando superior

9 - kubeadm alpha

Atualmente, não há comandos experimentais sob o kubeadm alpha.

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó worker do Kubernetes e associá-lo ao cluster
• kubeadm reset para reverter quaisquer alterações feitas neste host pelo kubeadm init ou kubeadm join

10 - kubeadm certs

O kubeadm certs fornece os utilitários para gerenciar os certificados. Para obter mais detalhes sobre como esses comandos podem ser usados, consulte Gerenciamento de Certificados com o kubeadm.

kubeadm certs

Um conjunto de utilitários para usar os certificados Kubernetes

• visão geral

kubeadm certs renew

Você pode renovar todos os certificados Kubernetes usando o subcomando all ou renová-los seletivamente. Para mais detalhes, consulte Manual de renovação do certificado.

• renew
• all
• admin.conf
• apiserver-etcd-client
• apiserver-kubelet-client
• apiserver
• controller-manager.conf
• etcd-healthcheck-client
• etcd-peer
• etcd-server
• front-proxy-client
• scheduler.conf

kubeadm certs renew [flags]

kubeadm certs renew all [flags]

kubeadm certs renew admin.conf [flags]

kubeadm certs renew apiserver-etcd-client [flags]

kubeadm certs renew apiserver-kubelet-client [flags]

kubeadm certs renew apiserver [flags]

kubeadm certs renew controller-manager.conf [flags]

kubeadm certs renew etcd-healthcheck-client [flags]

kubeadm certs renew etcd-peer [flags]

kubeadm certs renew etcd-server [flags]

kubeadm certs renew front-proxy-client [flags]

kubeadm certs renew scheduler.conf [flags]

kubeadm certs certificate-key

Este comando pode ser usado para gerar uma nova chave do certificado da camada de gerenciamento. A chave pode ser passada como --certificate-key to kubeadm init e kubeadm join para permitir uma cópia automática dos certificados ao unir nós adicionais a camada de gerenciamento.

• certificate-key

kubeadm certs certificate-key [flags]

kubeadm certs check-expiration

Este comando verifica a expiração dos certificados na PKI local gerenciada pelo kubeadm. Para mais detalhes, consulte Verificar a expiração do certificado.

• check-expiration

kubeadm certs check-expiration [flags]

kubeadm certs generate-csr

Este comando pode ser usado para gerar chaves e CSRs para todos os certificados da camada de gerenciamento e arquivos kubeconfig. O usuário pode então assinar os CSRs com uma autoridade de certificação de sua escolha.

• generate-csr

kubeadm certs generate-csr [flags]

  # O comando a seguir gera as chaves e CSRs para todos os certificados do plano de controle e arquivos kubeconfig: 
  kubeadm certs generate-csr --kubeconfig-dir /tmp/etc-k8s --cert-dir /tmp/etc-k8s/pki

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó de carga de trabalho do Kubernetes e associá-lo ao cluster
• kubeadm reset para reverter quaisquer alterações feitas, neste host, pelo kubeadm init ou kubeadm join

11 - kubeadm kubeconfig

kubeadm kubeconfig fornece utilitários para gerenciar arquivos kubeconfig.

Para exemplos de uso do comando kubeadm kubeconfig user, consulte Gerando arquivos kubeconfig para usuários adicionais.

kubeadm kubeconfig

• visão geral

kubeadm kubeconfig user

Esse comando pode ser usado para gerar um arquivo kubeconfig para um usuário adicional.

• user

kubeadm kubeconfig user [flags]

  # Exibe um arquivo kubeconfig para um usuário adicional chamado foo usando um arquivo bar de configuração
  kubeadm kubeconfig user --client-name=foo --config=bar

12 - kubeadm upgrade phase

Na versão v1.15.0, o kubeadm introduziu suporte preliminar para as fases kubeadm upgrade node. Fases para outros subcomandos kubeadm upgrade, tal como apply, podem ser adicionadas nas seguintes versões.

kubeadm upgrade node phase

Usando essa fase, você pode optar por executar as etapas separadas da atualização de nós, sejam eles nós secundários da camada de gerenciamento ou nós de execução de cargas de trabalho. Observe que kubeadm upgrade apply ainda precisa ser chamado em um nó principal da camada de gerenciamento.

• phase
• preflight
• control-plane
• kubelet-config

kubeadm upgrade node phase preflight [flags]

kubeadm upgrade node phase control-plane [flags]

kubeadm upgrade node phase kubelet-config [flags]

Próximos passos

• kubeadm init para inicializar um nó da camada de gerenciamento do Kubernetes
• kubeadm join para inicializar um nó worker do Kubernetes e associá-lo ao cluster
• kubeadm reset para reverter quaisquer alterações feitas, neste host, pelo kubeadm init ou kubeadm join
• kubeadm upgrade para atualizar um cluster Kubernetes para uma versão mais recente
• kubeadm alpha para visualizar um conjunto de recursos disponibilizados para coletar feedback da comunidade