Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official.

etcd embutido com alta disponibilidade

O etcd embutido (HA) pode ter problemas de desempenho em discos mais lentos, como os Raspberry Pis rodando com cartões SD.

Por que um número ímpar de nós de servidor?

Um cluster de etcd embutido de alta disponibilidade deve ser composto por um número ímpar de nós de servidor para que o etcd mantenha o quórum. Para um cluster com n servidores, o quórum é (n/2)+1. Para qualquer cluster de tamanho ímpar, adicionar um nó sempre aumentará o número de nós necessários para o quórum. Embora adicionar um nó a um cluster de tamanho ímpar pareça melhor, já que há mais máquinas, a tolerância a falhas é pior, pois exatamente o mesmo número de nós pode falhar sem perder o quórum, mas há mais nós que podem falhar.

Um cluster HA K3s com etcd embutido é composto por:

  • Três ou mais nós de servidor que servirão a API do Kubernetes, executarão outros serviços do plano de controle e hospedarão o datastore etcd embutido.

  • Opcional: Zero ou mais nós agentes que são designados para executar seus apps e serviços

  • Opcional: Um endereço de registro fixo para que os nós agentes se registrem no cluster

Para implantar rapidamente grandes clusters HA, veja Projetos Relacionados

Para começar, primeiro inicie um nó de servidor com a flag cluster-init para habilitar o clustering e um token que será usado como um segredo compartilhado para adicionar servidores adicionais ao cluster.

curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s K3S_TOKEN=SECRET sh -s - server \
    --cluster-init \
    --tls-san=<FIXED_IP> # Optional, needed if using a fixed registration address

Após iniciar o primeiro servidor, junte o segundo e o terceiro servidores ao cluster usando o segredo compartilhado:

curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s K3S_TOKEN=SECRET sh -s - server \
    --server https://<ip or hostname of server1>:6443 \
    --tls-san=<FIXED_IP> # Optional, needed if using a fixed registration address

Onde INSTALL_K3S_ARTIFACT_URL é o URL dos Artefatos Principais

Verifique se o segundo e o terceiro servidores agora fazem parte do cluster:

$ kubectl get nodes
NAME        STATUS   ROLES                       AGE   VERSION
server1     Ready    control-plane,etcd,master   28m   vX.Y.Z
server2     Ready    control-plane,etcd,master   13m   vX.Y.Z
server3     Ready    control-plane,etcd,master   10m   vX.Y.Z

Agora você tem um plano de controle altamente disponível. Quaisquer servidores agrupados com sucesso podem ser usados no argumento --server para adicionar nós de servidor e agentes adicionais. A junção de nós de agentes adicionais ao cluster segue o mesmo procedimento que os servidores:

curl -sfL https://get.k3s.io | INSTALL_K3S_ARTIFACT_URL=<PRIME-ARTIFACTS-URL>/k3s K3S_TOKEN=SECRET sh -s - agent --server https://<ip or hostname of server>:6443

Existem algumas flags de configuração que devem ser as mesmas em todos os nós de servidor:

  • Flags relacionadas à rede: --cluster-dns, --cluster-domain, --cluster-cidr, --service-cidr

  • Flags que controlam a implantação de certos componentes: --disable-helm-controller, --disable-kube-proxy, --disable-network-policy e qualquer componente passado para --disable

  • Flags relacionadas a recursos: --secrets-encryption

Clusters existentes de nó único

Se você tem um cluster existente usando o banco de dados SQLite embutido padrão, pode convertê-lo para etcd simplesmente reiniciando seu servidor K3s com a flag --cluster-init. Uma vez que você tenha feito isso, poderá adicionar instâncias adicionais conforme descrito acima.

Se um datastore etcd for encontrado no disco, seja porque aquele nó já foi inicializado ou já se juntou a um cluster, os argumentos do datastore (--cluster-init, --server, --datastore-endpoint, etc) são ignorados.