Servidor cloud para Kubernetes na Europa
Kubernetes e a plataforma de orquestração padrão para cargas de trabalho em contentores em escala. Executa-lo bem requer mais do que apenas instalar k8s: precisa de hardware suficiente por no, redes confiáveis entre nos e compreender como e um cluster mínimo viavel.
Hospedar o seu cluster Kubernetes na Europa e um requisito prático se os seus utilizadores ou dados estão aqui. Redes privadas de baixa latência entre nos, conformidade com GDPR e proximidade física com a sua equipa de engenharia favorecem o alojamento na UE.
Por que o alojamento na UE importa para Kubernetes
Um cluster Kubernetes e um sistema distribuido. Os componentes do plano de controlo comunicam constantemente com os nos de trabalho. A latência de rede entre nos afeta diretamente a estabilidade do cluster. O etcd requer escritas de baixa latência para manter a consistência.
Colocar todos os nos no mesmo centro de dados da UE mantem a latência entre nos abaixo de 1 ms.
Requisitos mínimos do servidor
Kubernetes tem requisitos de hardware reais.
Para o no do plano de controlo:
- RAM: 4 GB mínimo (8 GB recomendado para clusters com mais de 10 trabalhadores)
- CPU: 2 núcleos mínimo (4 núcleos recomendado)
- Disco: 40 GB SSD
Para cada no de trabalho:
- RAM: 4 GB mínimo por no
- CPU: 2 núcleos mínimo por no
- Disco: 40 GB SSD por no
Uma configuração mínima pronta para produção e 1 no de plano de controlo mais 2 nos de trabalho.
Configuração recomendada DCXV
As instâncias cloud DCXV em https://dcxv.com/data-center#cloud comecam a partir de 15 EUR/mês. Para um cluster Kubernetes de 3 nos, três instâncias com 4 GB RAM e 4 vCPUs cada uma e um bom ponto de partida.
As instâncias cloud DCXV no mesmo centro de dados partilham uma rede privada com latência muito baixa entre instâncias. O suporte de engenheiros 24/7 esta incluído sem custo adicional.
Para clusters maiores, os servidores dedicados DCXV comecam a partir de 49 EUR/mês.
Guia de configuração
Implantação de um cluster k3s em três instâncias DCXV:
# No no do plano de controlo: instalar k3s
curl -sfL https://get.k3s.io | sh -
# Obter o token de adesão do plano de controlo
cat /var/lib/rancher/k3s/server/node-token
# Em cada no de trabalho: aderir ao cluster
curl -sfL https://get.k3s.io | K3S_URL=https://<control-plane-ip>:6443 K3S_TOKEN=<token> sh -
# Verificar que todos os nos estão prontos
kubectl get nodes
Quantos nós de plano de controle
Esta é a decisão a acertar antes de qualquer coisa rodar no cluster, porque o etcd mantém um quórum e um quórum precisa de maioria. A linha contraintuitiva é a segunda:
| Plano de controle | Sobrevive a perder | O quórum precisa de | Escolha quando |
|---|---|---|---|
| 1 nó | Nada - a API desaparece | 1 de 1 | Desenvolvimento, CI, staging, qualquer coisa reconstruível |
| 2 nós | Nada, e custa o dobro | 2 de 2 | Nunca - é estritamente pior que um nó |
| 3 nós | Um nó, sem perder escritas | 2 de 3 | Produção, e o mínimo que merece a palavra |
| 5 nós | Dois nós | 3 de 5 | Clusters grandes, ou quando um rack inteiro pode cair |
Dois nós é a armadilha: com número par não existe maioria, então perder qualquer um derruba o servidor de API igual a um nó único, e você pagou o dobro. Com os workers é o contrário - são gado, adicione e remova à vontade, e a quantidade não sustenta nada.
Expectativas de desempenho
Num cluster k3s de 3 nos com instâncias de 4 GB / 4 vCPU:
- Latência de agendamento de pods abaixo de 2 segundos para cargas de trabalho típicas
- Throughput de rede entre pods de 1-5 Gbps dentro do mesmo centro de dados
- Ingress gerindo 1.000-3.000 pedidos HTTP por segundo
- Tempos de resposta da API do plano de controlo abaixo de 50 ms
- Latência de escrita etcd abaixo de 5 ms com armazenamento SSD
Estas são expectativas para hardware desta classe, não medições do nosso próprio laboratório. Use-as como ponto de partida para o dimensionamento e meça a sua própria carga: os números reais dependem dos seus dados, das suas consultas e do seu tuning muito mais do que do fornecedor.
