Disponível para encomenda agora · Nova Iorque
Kubernetes upstream, construído com RKE2, em que o servidor de API, o scheduler e o etcd são operados por nós e cada nó worker é um servidor dedicado que aluga connosco. Sem hipervisor por baixo dos seus pods, sem vizinhos nos seus núcleos, e mantém SSH root, a consola e o modo de recuperação em cada nó.
Dúvidas antes de encomendar? . A nossa IA responde em segundos e pode verificar a sua conta e os servidores; um engenheiro assume sempre que pedir. Sem chat? Escreva-nos a partir da página de contacto.
A divisão do trabalho
Muitos serviços gerenciados de Kubernetes mantêm os nós fora do seu alcance. Aqui a linha é traçada no plano de controle: tudo acima dele é nossa responsabilidade, cada máquina abaixo dele permanece sua.
Por que os workers são bare metal
Um pod em uma VM na nuvem roda sobre um kernel convidado em cima de um kernel hospedeiro. Em um nó dedicado há um único kernel, no próprio hardware, então os núcleos e a memória que você aluga vão para os seus pods, e não para um segundo sistema operacional por baixo deles.
A carga de trabalho de mais ninguém compartilha a máquina, seus discos ou sua largura de banda de memória. Um benchmark que você roda na segunda-feira não é desfeito pelo job em lote de outra pessoa na sexta-feira.
Os servidores worker são cobrados com um valor fixo mensal, sem cobrança por gigabyte que sai do cluster. Servir tráfego não se transforma em uma segunda fatura.
Kubernetes é um projeto open-source da CNCF sob a licença Apache 2.0, e o RKE2 o executa upstream. Manifests que rodam aqui rodam em qualquer cluster conformante, então sair custa a você uma migração, não uma reescrita.
A stack
| Camada | O que é |
|---|---|
| Distribuição | RKE2, Kubernetes upstream em conformidade com a CNCF |
| Plano de controle | Operado por nós: 1 nó para desenvolvimento, 3 nós para alta disponibilidade |
| Estado do cluster | etcd embutido, com snapshot a cada 6 horas |
| Nós de trabalho | Servidores dedicados na sua conta, escolhidos um a um do estoque de Nova York e usados como estão, já com Ubuntu 24.04 ou 26.04 (sem reinstalação, sem taxa de configuração); de 1 a 10 por pedido, podendo adicionar mais depois até 10 |
| Agendamento | Um pool, cada nó rotulado com pool=general; rótulos e taints adicionais definidos por você com kubectl (cluster-admin) |
| Rede de pods | Cilium, com NetworkPolicy do Kubernetes aplicada; sem criptografia entre nós, então use TLS ou mTLS nos seus aplicativos, ou uma service mesh, onde o tráfego precisar ser criptografado |
| Balanceadores de carga | MetalLB: um Service do tipo LoadBalancer assume um dos endereços IPv4 extras nos seus servidores de trabalho |
| Rede dos nós | Os endereços públicos dos nós, com um firewall que admite apenas os próprios nós do cluster; sem VLAN privada |
| Acesso | Download do kubeconfig; SSH root, console e modo de resgate em cada nó de trabalho |
| Atualizações | Iniciadas por você; primeiro o plano de controle, depois os nós um a um |
| Localização | Nova York |
É assim que cada cluster que construímos em Nova York é montado. Se uma camada mudar, esta tabela muda junto.
Nós de trabalho
Um pedido leva de 1 a 10 servidores de trabalho, cada um escolhido entre as máquinas de Nova York prontas agora, e o painel adiciona mais depois, até 10 no total. Cada nó de trabalho entra em um pool e carrega o rótulo pool=general. Você tem cluster-admin, então separar as máquinas de GPU da camada web fica a um kubectl label e um kubectl taint de distância.
pool=general são seus para definir; não adicionamos regras de agendamento próprias$ kubectl label node k8s-250123-w3 gpu=true
$ kubectl taint node k8s-250123-w3 gpu=true:NoSchedule
apiVersion: v1
kind: Pod
metadata: name: inference
spec: nodeSelector: gpu: "true" tolerations: - key: gpu operator: Exists effect: NoSchedule containers: - name: model image: ghcr.io/example/model:1.0Perguntas
Gerenciado. Nós operamos o plano de controle, incluindo o etcd e seus snapshots, e conduzimos as atualizações quando você inicia uma. Seus servidores dedicados entram no cluster como nós de trabalho, e você nunca precisa operar o plano de controle por conta própria.
RKE2, uma distribuição em conformidade com a CNCF que entrega o Kubernetes upstream. Seus manifestos, Helm charts e operadores funcionam como em qualquer outro cluster em conformidade.
Sim. Cada nó de trabalho é um servidor dedicado na sua conta, com SSH root, console e modo de resgate, exatamente como quando não faz parte de um cluster. Essa é a principal diferença em relação à maioria dos Kubernetes gerenciados, onde os nós costumam ser fechados para você.
O MetalLB atribui a eles os endereços IPv4 adicionais dos seus servidores de trabalho, de modo que o endereço na frente do seu Service é um que você já possui, em vez de um que emprestamos de um pool compartilhado.
Não, não há VLAN privada por cluster. Os nós se comunicam entre si pelos endereços públicos na nossa rede, e um firewall em cada nó admite apenas os nós do próprio cluster. O tráfego entre nós não é criptografado pelo cluster: as políticas de rede do Cilium controlam quais pods podem conversar, e para tráfego criptografado entre serviços use TLS ou mTLS nas suas aplicações, ou uma service mesh.
Sim. Você escolhe cada servidor de trabalho entre as máquinas de Nova York prontas agora, então servidores GPU e CPU podem entrar no mesmo cluster. Todos começam em um pool rotulado como pool=general; com cluster-admin você mesmo rotula e aplica taints nos nós GPU, e as cargas de trabalho escolhem entre eles com node selectors e tolerations.
Você escolhe quando. Atualizamos o plano de controle primeiro, depois os nós de trabalho um de cada vez, para que uma carga de trabalho com mais de uma réplica continue atendendo enquanto o cluster avança para a nova versão.
Sim, em Nova York. Na página de pedido você escolhe um plano de controle Dev ou HA e de um a dez servidores de trabalho entre as máquinas de Nova York prontas agora; o cluster é criado assim que as primeiras faturas são pagas, e o kubeconfig dele fica esperando no seu painel.
Escolha um plano de controle, dê um nome ao cluster e selecione de um a dez servidores de trabalho. Os workers chegam exatamente como estão em estoque, já com Ubuntu 24.04 ou 26.04, portanto não há taxa de configuração e eles entram logo após a entrega, assim que as primeiras faturas forem pagas; o kubeconfig fica no seu painel assim que o cluster informar que está pronto.
Prefere rodar o Kubernetes por conta própria? Veja metal dedicado para contêineres. Precisa de uma máquina pequena em vez de um cluster? Um Cloud VPS é uma máquina virtual KVM; a página de servidores dedicados lista as máquinas que um worker pode ser.