Kubernetes em vários continentes: k3s e k8s em alta disponibilidade entre centros de dados de todo o mundo

O Kubernetes é o padrão quando as aplicações têm de funcionar de forma tolerante a falhas e escalar automaticamente. A ideia óbvia de estender um único cluster Kubernetes por servidores nos EUA, na Europa e na Ásia esbarra, no entanto, num pormenor: no etcd, a base de dados onde o Kubernetes guarda todo o seu estado. Este artigo mostra como o Kubernetes em vários continentes funciona mesmo assim, e de forma a aguentar a falha de um continente inteiro: com um cluster por região, um deploy comum via GitOps e um Geo-DNS que envia os utilizadores para a região saudável mais próxima.

Montamos a arquitetura com o k3s, a distribuição Kubernetes leve e totalmente certificada que se instala em minutos, e no fim mostramos o que muda com um Kubernetes clássico instalado com o kubeadm. As bases sobre disponibilidade, quorum e failover em várias localizações estão explicadas em pormenor no artigo Docker Swarm em três continentes; aqui tratamos do que é diferente no Kubernetes.

Um cluster para todos os continentes ou um cluster por região?

Para o Kubernetes em vários continentes, a arquitetura certa é um cluster por região, e não um único cluster para todos os continentes. Cada cluster funciona de forma independente, todos são implementados a partir do mesmo repositório Git, e um Geo-DNS com health checks distribui os utilizadores. Se uma região falhar, as outras assumem o serviço, sem que seja preciso coordenar um estado comum do cluster através do oceano.

Porque é que o etcd não tolera longas distâncias

O Kubernetes guarda cada estado, cada configuração e cada alteração no etcd, um armazenamento chave-valor com consenso Raft. Cada escrita precisa da confirmação da maioria de todos os membros do etcd. Por predefinição, o etcd trabalha com um heartbeat de 100 milissegundos e um timeout de eleição de um segundo; entre a Europa, a América do Norte e a Ásia, os tempos de trânsito dos pacotes situam-se entre 80 e 250 milissegundos. É possível aumentar estes tempos, mas então todas as escritas no cluster ficam lentas, desde o agendamento de um pod até à gravação de um Secret. A documentação do k3s é clara neste ponto: o etcd integrado não é suportado em clusters distribuídos por várias redes, e todos os servidores devem estar na mesma localização. Também o próprio Kubernetes foi concebido para que um cluster abranja várias zonas dentro de uma região, e não vários continentes.

Os três padrões comparados

A abordagem «um cluster por região» tem uma segunda vantagem, muitas vezes subestimada: um erro no plano de controlo, uma alteração errada no cluster ou um upgrade que corre mal afeta sempre apenas uma região. Os utilizadores das outras regiões nem dão por isso.

k3s ou k8s?

Ambos são Kubernetes a sério, com a mesma API, os mesmos manifestos e as mesmas ferramentas. A diferença está na estrutura e no esforço:

Para a arquitetura com um cluster por região, recomendamos o k3s: operar três clusters só é confortável se cada um deles for simples. Quem já tem experiência com o kubeadm pode adotar a arquitetura sem alterações; a secção sobre o kubeadm, mais abaixo, mostra as diferenças.

A arquitetura: três regiões, três clusters, um ponto de entrada

Configuração inicial e expansão

A configuração inicial consiste em três servidores, um nos EUA, um na Europa e um na Ásia, cada um como cluster independente de nó único. Se um servidor falhar, a sua região falha, e o Geo-DNS envia os respetivos utilizadores para a região vizinha. Esta fase já está concebida para a falha de um continente inteiro. Na expansão, cada região recebe três servidores na mesma localização; assim, cada região sobrevive também, por si só, à falha de um servidor, sem que os utilizadores tenham de ser redirecionados.

Que localizações da KernelHost são adequadas

A KernelHost opera servidores no centro de dados maincubes em Frankfurt am Main e oferece servidores virtuais noutras localizações na Europa, na América do Norte e na Ásia-Pacífico, entre elas três localizações nos EUA, o Canadá, Londres, Estrasburgo, Varsóvia, Helsínquia, Singapura, o Japão, Sydney e Mumbai. A lista completa está na página Localizações de servidores. O exemplo deste artigo usa Frankfurt am Main para a Europa, a costa leste dos EUA para a América do Norte e Singapura para a Ásia.

Guia: Kubernetes com k3s em três regiões

O exemplo usa três servidores com Debian 12 ou 13: k3s-eu, k3s-us e k3s-asia. Os endereços públicos vêm da rede de documentação 203.0.113.0/24, e o domínio é example.com. Substitua ambos pelos seus valores.

Passo 1: disponibilizar servidores em três regiões

Encomende três servidores em três regiões, com pelo menos 2 vCPU e 4 GB de RAM, para que, além do k3s, também a sua aplicação tenha espaço. Aplique a proteção básica da checklist para novos servidores root e atribua nomes de host descritivos. O etcd beneficia claramente de SSD rápidos, e o armazenamento NVMe dos servidores da KernelHost cumpre esse requisito.

Passo 2: instalar o k3s

Em cada um dos três servidores, instale o k3s com um único comando. Cada servidor passa assim a ser um cluster Kubernetes completo com um nó:

curl -sfL https://get.k3s.io | sh -
kubectl get nodes

Após cerca de um minuto, o kubectl get nodes mostra o nó como Ready. Vêm incluídos o Traefik como controlador de Ingress, o Flannel como rede e um provisionador para volumes locais.

Passo 3: expandir para três servidores por região

Se quiser que a própria região fique em alta disponibilidade, coloque três servidores na mesma localização. O primeiro servidor inicia o etcd integrado, e os outros dois juntam-se ao cluster com um token comum. O etcd exige um número ímpar de servidores; com três servidores, a região aguenta a falha de um servidor:

curl -sfL https://get.k3s.io | K3S_TOKEN=TOKEN_SECRETO sh -s - server \
    --cluster-init \
    --tls-san=api.eu.example.com

curl -sfL https://get.k3s.io | K3S_TOKEN=TOKEN_SECRETO sh -s - server \
    --server https://203.0.113.21:6443 \
    --tls-san=api.eu.example.com

Todos os servidores de uma região precisam das mesmas definições para os intervalos de rede e para as funcionalidades. Entre eles, têm de estar abertas as portas 2379 a 2380/TCP para o etcd, 6443/TCP para a API, 10250/TCP para o Kubelet e 8472/UDP para a rede Flannel; para o exterior, ficam bloqueadas. O token é um segredo: quem o conhecer pode acrescentar servidores seus ao cluster.

Passo 4: configurar o acesso aos três clusters

O k3s guarda as credenciais de acesso em /etc/rancher/k3s/k3s.yaml. Copie o ficheiro de cada cluster para o seu computador de trabalho, substitua nele 127.0.0.1 pelo endereço do servidor e dê aos contextos o nome da respetiva região:

kubectl config rename-context default eu
kubectl config use-context eu
kubectl --context us get nodes

A API na porta 6443 é o acesso mais poderoso ao cluster. Permita esse acesso na firewall apenas a partir do seu próprio endereço ou de uma VPN, nunca para toda a internet. O ficheiro k3s.yaml contém um certificado de administrador e deve ser guardado com o mesmo cuidado que uma palavra-passe de root.

Passo 5: GitOps com o Flux em cada cluster

Para que as três regiões operem a mesma aplicação na mesma versão, o estado desejado fica num repositório Git e, em cada cluster, corre o Flux, que estabelece esse estado de forma autónoma. Cada cluster vai, portanto, buscar a sua configuração por si próprio; não existe um servidor central de deploy que possa falhar. Uma estrutura de repositório comprovada:

apps/
  web/            manifestos comuns da aplicação
clusters/
  eu/             definições e versão para a Europa
  us/             definições e versão para a América do Norte
  asia/           definições e versão para a Ásia

flux bootstrap git --url=ssh://git@git.example.com/infra/fleet.git --branch=main --path=clusters/eu

Execute o mesmo comando com --path=clusters/us e --path=clusters/asia no respetivo contexto. Como cada região tem o seu próprio diretório, pode implementar uma nova versão primeiro numa região e só depois nas outras.

Passo 6: descrever a aplicação de forma tolerante a falhas

Dentro de uma região, há três elementos que garantem que a aplicação sobrevive a manutenções e a falhas de servidores: várias réplicas distribuídas por nós diferentes, verificações que detetam pods não saudáveis e um orçamento de interrupções que impede que uma manutenção remova todos os pods ao mesmo tempo:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway
          labelSelector:
            matchLabels:
              app: web
      containers:
        - name: web
          image: registry.example.com/web:1.0
          ports:
            - containerPort: 8080
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /health
              port: 8080
            periodSeconds: 10
---
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: web

A verificação de readiness retira um pod do tráfego enquanto ele não responder, e a verificação de liveness reinicia-o quando fica bloqueado. Num cluster de nó único, a distribuição por vários nós ainda não tem efeito; passa a aplicar-se automaticamente assim que a região tiver três servidores.

Passo 7: Ingress e certificados

A entrada fica a cargo do Traefik incluído. Como as três regiões servem o mesmo domínio, obtenha os certificados TLS com o cert-manager através da validação DNS: esta funciona em todas as regiões, independentemente do sítio para onde o registo DNS aponta nesse momento. A validação HTTP, pelo contrário, falha em todas as regiões para as quais o registo não aponta nesse momento. Quem trabalha sem Ingress do Kubernetes encontra as bases no artigo Configurar o nginx como reverse proxy.

Passo 8: configurar o Geo-DNS com failover

Um serviço de DNS com encaminhamento geográfico e health checks envia os utilizadores da Europa para Frankfurt am Main, os da América para a costa leste dos EUA e os da Ásia para Singapura, e verifica a cada 30 a 60 segundos se a entrada de cada região responde. Se uma região falhar, deixa de devolver o respetivo endereço. Defina o TTL dos registos para 60 segundos; assim, uma comutação fica normalmente concluída ao fim de um a dois minutos. Quem quiser gerir os registos a partir do próprio cluster pode usar o external-dns para isso.

Passo 9: implementar região a região e testar a falha

Introduza uma nova versão primeiro no diretório de uma região, observe essa região durante alguns minutos e só depois adote a versão nas outras. Assim, um erro que nenhuma verificação deteta atinge no máximo uma região. Para ensaiar a falha de uma região, pare o k3s no respetivo servidor e verifique se o Geo-DNS retira a região das respostas e se a região vizinha aguenta a carga:

systemctl stop k3s
systemctl start k3s

Numa região com três servidores, ensaie também a manutenção de um único servidor. O kubectl drain desloca os pods respeitando o orçamento de interrupções do passo 6, e o kubectl uncordon volta a colocar o servidor em serviço:

kubectl drain k3s-eu-2 --ignore-daemonsets --delete-emptydir-data
kubectl uncordon k3s-eu-2

Dados entre regiões

O Kubernetes distribui pods, não dados. Um PersistentVolume do provisionador incluído fica em exatamente um nó, e entre os clusters não existe, de origem, qualquer armazenamento de dados comum. Por isso, para tudo o que envolve dados, aplica-se o mesmo que em qualquer cluster distribuído por várias localizações:

• As bases de dados tratam da sua própria replicação. Uma solução comprovada é uma instância primária numa região com réplicas nas outras; operadores de bases de dados como o CloudNativePG para PostgreSQL suportam essas réplicas também entre clusters diferentes. Entre continentes, a replicação é assíncrona, e numa emergência podem faltar os últimos segundos de escritas. Para escrita sem perdas em todo o mundo, existem bases de dados multirregião como o CockroachDB ou o YugabyteDB.
• Os ficheiros e os uploads devem ficar num armazenamento de objetos compatível com S3, com replicação para uma segunda região.
• As sessões ficam numa base de dados replicada ou numa cache replicada, ou então a aplicação usa tokens assinados.
• Os backups continuam a ser obrigatórios, porque a replicação distribui os erros tal como distribui os dados bons. Para objetos e volumes do Kubernetes, o Velero é adequado; para as bases, consulte a estratégia de backup para servidores.

Kubernetes com kubeadm em vez de k3s

Com o kubeadm, a arquitetura mantém-se a mesma: um cluster por região, GitOps, Geo-DNS. O que muda é a construção de cada cluster. Instale em todos os nós um runtime de containers como o containerd, bem como o kubeadm, o kubelet e o kubectl, coloque à frente da API da região um load balancer ou um endereço virtual, por exemplo com o kube-vip, e inicialize o primeiro nó do plano de controlo:

kubeadm init --control-plane-endpoint "api.eu.example.com:6443" --upload-certs

A saída contém dois comandos de adesão: um com --control-plane --certificate-key para os outros dois nós do plano de controlo e um para os workers. Depois, instale um plugin de rede como o Calico ou o Cilium e um controlador de Ingress, que o k3s já traz de origem. O esforço adicional compensa quando precisa de escolher componentes específicos de forma deliberada ou de se manter próximo da versão upstream.

Porquê a KernelHost para Kubernetes em vários continentes

Na página Alugar servidor cloud encontra uma visão geral de todos os planos cloud e uma comparação de custos com os grandes fornecedores de cloud.

Erros frequentes e como evitá-los

• etcd estendido entre continentes. O resultado são escritas lentas e eleições instáveis, e no k3s com etcd integrado isto não é suportado. Solução: um cluster por região.
• Dois servidores numa região. O etcd precisa de uma maioria, e dois servidores não aguentam nenhuma falha. Solução: um ou três.
• API aberta a toda a internet. A porta 6443 é a chave mestra do cluster. Solução: apenas a partir do seu próprio endereço ou por VPN.
• Servidor central de deploy. Se falhar, deixa de ser possível implementar o que quer que seja. Solução: o Flux em cada cluster, que se serve diretamente do Git.
• Atualização em todas as regiões ao mesmo tempo. Nesse caso, um erro afeta todos os utilizadores. Solução: região a região, através dos diretórios no repositório.
• Certificados por validação HTTP. Nas regiões para as quais o registo DNS não aponta nesse momento, a renovação falha. Solução: validação DNS.
• Base de dados num volume local sem replicação. Se o nó falhar, os dados ficam inacessíveis. Solução: replicação através de um operador de bases de dados.
• Sem probes e sem orçamento de interrupções. Os pods não saudáveis continuam a receber tráfego, e as manutenções tiram todos os pods da rede ao mesmo tempo. Solução: verificações de readiness e liveness, mais um PodDisruptionBudget.

Em resumo

• Para o Kubernetes em vários continentes, o correto é um cluster por região; um único cluster para todos os continentes falha por causa da latência do etcd.
• A configuração inicial consiste em três servidores, um nos EUA, um na Europa e um na Ásia; esta fase já sobrevive à falha de um continente inteiro.
• Na expansão, cada região recebe três servidores na mesma localização, e assim cada região sobrevive também a falhas de servidores individuais.
• O Flux em cada cluster implementa a aplicação a partir do mesmo repositório Git, região a região.
• Um Geo-DNS com health checks e um TTL curto envia os utilizadores para a região saudável mais próxima, e os certificados são obtidos por validação DNS.
• O Kubernetes distribui pods, não dados: as bases de dados precisam de replicação própria e os backups continuam a ser obrigatórios.
• Para esta arquitetura, o k3s é normalmente uma escolha melhor do que o kubeadm, porque três clusters simples são mais fáceis de operar do que três complexos.