☰

Qual é a maneira correta de modificar a configuração do kubelet e do plano de controle com o kubeadm?

tag-icon • tag-icon kubernetes kubeadm
Qual é a maneira correta de modificar a configuração do kubelet e do plano de controle com o kubeadm?

Instalei um cluster kubernetes (v1.20.0) com 3 mestres e 3 nós usando kubeadm inite kubeadm join, todos no Ubuntu 20.04. Agora preciso atualizar a configuração e

  • Adicione --cloud-provider=externalo sinalizador de inicialização do kubelet em todos os nós, pois irei usardriver vsphere-csi
  • Alterar --service-cidrdevido aos requisitos da rede

No entanto, não tenho certeza de qual é a maneira correta de fazer essas alterações.

Kubelet

Olhando para /etc/systemd/system/kubelet.service.d/10-kubeadm.conflá, há uma referência, /etc/default/kubeletmas é considerado um último recurso e recomenda a atualização .NodeRegistration.KubeletExtraArgs:

...
# This is a file that the user can use for overrides of the kubelet args as a last resort. Preferably, the user should use
# the .NodeRegistration.KubeletExtraArgs object in the configuration files instead. KUBELET_EXTRA_ARGS should be sourced from this file.
EnvironmentFile=-/etc/default/kubelet
...

Onde fica isso .NodeRegistration.KubeletExtraArgse como posso alterá-lo para todos os nós do cluster?

plano de controle

Pelo que entendi, o apiserver e o controller-manager são executados como pods estáticos em cada master e leem suas configurações do /etc/kubernetes/manifests/kube-<type>.yaml. Meu primeiro pensamento foi fazer as alterações necessárias nesses arquivos, no entanto, de acordo com os documentos do Kubernetes ematualizando um cluster kubeadm, kubeadm irá:

* Fetches the kubeadm ClusterConfiguration from the cluster.
* Optionally backups the kube-apiserver certificate.
* Upgrades the static Pod manifests for the control plane components.

Como alterei os manifestos manualmente, eles não são atualizados no ClusterConfiguration ( kubectl -n kube-system get cm kubeadm-config -o yaml), minhas alterações sobreviveriam a uma atualização dessa forma? Suponho que também poderia editar o ClusterConfiguration manualmente, kubeadm edit cm ...mas isso parece propenso a erros e é fácil esquecer de alterá-lo todas as vezes.

De acordo com os documentos, existe uma maneira depersonalizar a configuração do plano de controlemas isso parece ocorrer apenas na instalação do cluster pela primeira vez. Por exemplo, kubeadm config print init-defaultscomo o nome sugere, forneça apenas os valores padrão, não o que está atualmente em execução no cluster. A tentativa de extrair o ClusterConfiguration kubectl -n kube-system get cm kubeadm-config -o yamle executá- kubeadm init --config <config>lo falha de várias maneiras porque o cluster já está inicializado.

Kubeadm pode ser executadoplano de controle de fase inicialque atualiza os manifestos do pod estático, mas deixa o ClusterConfiguration intacto, então eu precisaria executar a upload-configfase também.

Com base no exposto, o fluxo de trabalho parece ser

  • Extraia o ClusterConfiguration kubeadm -n kube-system get cm kubeadm-confige salve-o em um arquivo yaml
  • Modifique o arquivo yaml com as alterações necessárias
  • Aplicar alterações comkubeadm init phase control-plane all --config <yaml>
  • Carregar configuração modificadakubeadm init phase upload-config all --config <yaml>
  • Distribua o arquivo yaml modificado para todos os mestres
  • Para cada master, inscreva-se comkubeadm init phase control-plane all --config <yaml>

O que me preocupa aqui é a aparente desconexão entre os manifestos do pod estático e o ClusterConfiguration. As alterações não são feitas com muita frequência, por isso é muito fácil esquecer que alterar um local também exige alterações no outro - manualmente.

Não há como atualizar as configurações do kubelet e do plano de controle que garantam a consistência entre os componentes do kubernetes e o kubeadm? Ainda sou muito novo no Kubernetes e hábastantede documentação sobre isso, então me desculpe se perdi algo óbvio aqui.

Responder1

Tentarei responder a ambas as suas perguntas.

1. Adicione --cloud-provider=external sinalizador de inicialização do kubelet em todos os nós

Onde está este .NodeRegistration.KubeletExtraArgs e como posso alterá-lo para todos os nós do cluster?

KubeletExtraArgssão quaisquer argumentos e parâmetros suportados pelo kubelet. Eles estão documentadosaqui. Você precisa usar o kubeletcomando com sinalizadores adequados para modificá-lo. Além disso, observe que o sinalizador que você está prestes a usar será removido no k8s v1.23:

--cloud-provider stringO provedor de serviços em nuvem. Defina como string vazia para execução sem provedor de nuvem. Se definido, o provedor de nuvem determina o nome do nó (consulte a documentação do provedor de nuvem para determinar se e como o nome do host é usado). (OBS.: será removido na versão 1.23, em favor da remoção do código do provedor de nuvem do Kubelet.)

EDITAR:

Para melhor responder à sua pergunta sobre:.NodeRegistration.KubeletExtraArgs

Estes também são elementos doarquivo de configuração de inicialização do kubeadm:

É possível configurar kubeadm initcom um arquivo de configuração em vez de sinalizadores de linha de comando, e alguns recursos mais avançados podem estar disponíveis apenas como opções de arquivo de configuração. Este arquivo é passado usando o --configflag e deve conter uma ClusterConfiguration estrutura e opcionalmente mais estruturas separadas por ---\nMixar --configcom outros flags pode não ser permitido em alguns casos.

Você também pode encontrar mais detalhes sobre oNodeRegistrationOptionsbem como mais informações sobre os campos e uso da configuração.

Além disso, observe que:

KubeletExtraArgspassa argumentos extras para o kubelet. Os argumentos aqui são passados ​​para a linha de comando do kubelet por meio do arquivo de ambiente

kubeadm grava em tempo de execução para o kubelet ser fonte. Isso substitui a configuração genérica de nível base no kubelet-config-1.X ConfigMap

Os sinalizadores têm prioridade mais alta durante a análise. Esses valores são locais e específicos do nó em que o kubeadm está sendo executado.

EDITAR2:

kubeadm initdeve ser usado apenas uma vez ao criar um cluster, sempre que você o usar com sinalizadores ou um arquivo de configuração. Você não pode alterar as configurações executando-as novamente com valores diferentes.Aquivocê encontrará informações sobre o kubeadm e seu uso. Depois que o cluster estiver configurado, o kubeadm deverá ser descartado e as alterações feitas diretamente nos manifestos do pod estático.

2. Altere --service-cidr devido aos requisitos de rede

Isso é mais complicado. Você poderia tentar fazer isso de forma semelhanteaquiouaquimas essa abordagem está sujeita a erros e não é recomendada.

A maneira mais viável e segura seria simplesmente recriar o cluster com kubeadm resete kubeadm init --service-cidr. A opção de alterar automaticamente os CIDRs nem era esperada da perspectiva do Kubernetes. Então, em resumo, oredefinição do kubeadmé o caminho a seguir aqui.

Responder2

Em relação a

Entendo que KubletExtraArgs se refere aos argumentos da linha de comando do kubelet, o que não entendo é onde está esse atributo e como posso modificá-lo.

múltiplas fontes, comoEsteponto de adicionar

/etc/systemd/system/kubelet.service.d/10-kubeadm.conf

linhas como por exemplo

Environment="KUBELET_EXTRA_ARGS=--pod-manifest-path=/etc/kubelet.d/"

para definir o ambiente para um diretório personalizado para pods estáticos aqui, por exemplo, em vez de usar o cli com

kubelet --pod-manifest-path=/etc/kubelet.d

como sugere nos documentos.

Se você pesquisar no Google, $KUBELET_EXTRA_ARGSencontrará muitos exemplos do 10-kubeadm.confarquivo mencionado acima.

informação relacionada