Se você é usuário do Rancher, provavelmente criou clusters personalizados usando o Rancher Server. No entanto, em alguns casos, pode ocorrer de o Rancher Server não conseguir mais gerenciar esses clusters devido a problemas como exclusão acidental ou perda de backup. Nesses cenários, uma solução comum seria reiniciar o Rancher Server e importar os clusters downstream novamente, mas isso pode causar complicações, como a impossibilidade de expandir novos nós no cluster.

Para evitar essas limitações, podemos usar o RKE para assumir o controle dos clusters personalizados criados pelo Rancher Server.

Como sabemos, clusters personalizados criados via UI do Rancher utilizam o RKE no back end. Portanto, o RKE tem a capacidade de gerenciar esses clusters diretamente, desde que sejam fornecidos três arquivos essenciais:

• cluster.yml: O arquivo de configuração do cluster RKE.
• kube_config_cluster.yml: Este arquivo contém as credenciais necessárias para acessar o cluster.
• cluster.rkestate: Um estado persistente do cluster Kubernetes.

Com esses arquivos em mãos, podemos utilizar o binário RKE para continuar gerenciando o cluster, incluindo adicionar novos nós.

Ambiente Demonstrativo

Este guia foi testado nas versões v2.4.x e v2.5.x do Rancher. Outras versões podem não ser compatíveis.

Configuração Inicial

Vamos começar criando um cluster personalizado no Rancher Server (eexcutado via Docker) com dois nós: ip-172-31-2-203 e ip-172-31-1-111.

# kubectl get nodes
NAME              STATUS   ROLES                      AGE     VERSION
ip-172-31-1-111   Ready    worker                     2m2s    v1.18.14
ip-172-31-2-203   Ready    controlplane,etcd,worker   3m23s   v1.18.14

Agora, vamos simular uma falha no Rancher Server desligando o nó ip-172-31-8-56.

Reucperando Arquivos Essenciais

Passo 1: Recuperando kube_config_cluster.yml

No nó controlplane, execute o seguinte comando para recuperar o arquivo de configuração:

docker run --rm --net=host \
-v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro \
--entrypoint bash $(docker inspect $(docker images -q --filter=label=io.cattle.agent=true) \
--format='{{index .RepoTags 0}}' | tail -1) \
-c 'kubectl --kubeconfig /etc/kubernetes/ssl/kubecfg-kube-node.yaml get configmap \
-n kube-system full-cluster-state \
-o json | jq -r .data."full-cluster-state" | jq \
-r .currentState.certificatesBundle."kube-admin".config | sed \
-e "/^[[:space:]]*server:/ s_:.*_: \"https://127.0.0.1:6443\"_"' \
> kubeconfig_admin.yml

Verifique se o arquivo foi recuperado corretamente:

kubectl --kubeconfig kubeconfig_admin.yml get nodes

Passo 2: Recuperando cluster.rkestate

Execute o seguinte comando no nó controlplane:

docker run --rm --net=host \
-v $(docker inspect kubelet --format '{{ range .Mounts }}{{ if eq .Destination "/etc/kubernetes" }}{{ .Source }}{{ end }}{{ end }}')/ssl:/etc/kubernetes/ssl:ro \
--entrypoint bash $(docker inspect $(docker images -q --filter=label=org.label-schema.vcs-url=https://github.com/rancher/hyperkube.git) \
--format='{{index .RepoTags 0}}' | tail -1) \
-c 'kubectl --kubeconfig /etc/kubernetes/ssl/kubecfg-kube-node.yaml \
-n kube-system get configmap full-cluster-state \
-o json | jq -r .data."full-cluster-state" | jq -r .' \
> cluster.rkestate

Passo 3: Criando o cluster.yml

Embora não haja uma maneira automática garantida de recuperar o cluster.yml, você pode usá-lo como base a partir do cluster.rkestate. Por exemplo:

nodes:
  - address: 172.31.2.203
    user: ubuntu
    role:
      - controlplane
      - etcd
      - worker
  - address: 172.31.1.111
    user: ubuntu
    role:
      - worker
kubernetes_version: v1.18.14-rancher1-1

Caso deseje adicionar novos nós, insira-os neste arquivo.

Adicionando Novos Nós

Com todos os arquivos prontos, use o RKE para atualizar o cluster:

rke up

Após a conclusão, verifique os nós:

kubectl --kubeconfig kubeconfig_admin.yml get nodes

Resultado esperado:

NAME              STATUS   ROLES                      AGE     VERSION
ip-172-31-1-111   Ready    worker                     8m6s    v1.18.14
ip-172-31-2-203   Ready    controlplane,etcd,worker   9m27s   v1.18.14
ip-172-31-5-186   Ready    worker                     29s     v1.18.14

Agora você pode gerenciar o cluster diretamente com o RKE.