Datacentrics/DKSKubernetes Services no ar — servido pelo próprio DKS

Datacentrics Cloud — Nova linha de produto

Kubernetes gerenciado, dentro do seu datacenter.

O DKS entrega um cluster Kubernetes dedicado por cliente, em VLAN isolada, sobre a infraestrutura VMware da Datacentrics — com operação, observabilidade e SLA nossos. Esta página é a prova: ela está sendo servida pelo primeiro cluster DKS agora.

Por que existe

Para quem a nuvem pública não resolve

Há clientes que precisam de Kubernetes, mas não podem — ou não querem — levar seus dados para fora. O DKS atende exatamente esse cliente.

Soberania de dados

Dados em casa, LGPD simples

O workload e os dados nunca saem do datacenter. A resposta para a pergunta de compliance é uma frase: seu cluster, sua VLAN, seus dados.

Isolamento físico-lógico

Um cluster por cliente

Cada cliente recebe cluster dedicado em VLAN própria, atrás do seu firewall — o mesmo modelo de segregação que a Datacentrics já opera. Sem vizinhos, sem blast radius compartilhado.

Custo previsível

Preço em reais, sem surpresa

Sem cobrança por tráfego, por requisição ou variação cambial. Capacidade contratada, fatura previsível.

Operação inclusa

Gerenciado de verdade

Upgrades, certificados, backup de etcd, monitoramento e plantão são responsabilidade da Datacentrics. O cliente usa o cluster; nós o operamos.

Arquitetura

Como um cluster DKS é entregue

Duas camadas: o ambiente dedicado do cliente e o plano de gerência central da Datacentrics, que opera todos os clusters pela mesma esteira.

Ambiente dedicado do cliente — VLAN /24 própria
Cloudflare
DNS · proxy · WAF
pfSense
gateway · NAT · firewall
MetalLB + ingress
LB L2 · TLS automático
Control plane HA
3 nós · kube-vip · etcd
Workers
2..n · Cilium eBPF
Storage vSphere
CSI · volumes no datastore
Plano de gerência Datacentrics — um NOC para todos os clusters
Terraform + Ansible
cluster novo em até 1 dia
ArgoCD
GitOps · auditoria de mudanças
Grafana central
métricas · logs · alertas
Velero + etcd
backup off-cluster · DR testado

Kubernetes de upstream puro (kubeadm), sem camada proprietária: o que roda no DKS é o mesmo Kubernetes de qualquer nuvem — as aplicações do cliente entram e saem sem reescrita.

Stack técnica

Componentes escolhidos, não empilhados

Cada camada tem uma decisão de arquitetura registrada (ADR) por trás.

CamadaTecnologiaPor quê
Clusterkubeadm · containerdKubernetes upstream, sem licenciamento e sem lock-in de distribuição
Rede de podsCilium (eBPF)NetworkPolicies L3–L7 e observabilidade de rede (Hubble) inclusas
Load balancerMetalLBIPs de serviço na VLAN do cliente, sem hardware adicional
Ingress + TLSingress-nginx · cert-managerHTTPS automático com renovação sem intervenção humana
StoragevSphere CSIVolumes persistentes na resiliência do datastore que já operamos
ObservabilidadePrometheus · Grafana · LokiSLA medido, não prometido — dashboards por cliente
Backup / DRVelero · snapshots etcdRPO/RTO documentados e restore testado periodicamente
Entrega e esteiraArgoCD · Terraform · AnsibleTodo cluster nasce de código — idêntico, reproduzível, auditável

Planos

Três formatos de entrega

Do ambiente de desenvolvimento ao workload crítico com SLA contratual.

DKS Essential

Dev & teste

SLA: melhor esforço

  • 1 control plane · 2 workers
  • Storage local
  • HTTPS automático incluso
  • Observabilidade básica
  • Suporte em horário comercial

// porta de entrada e ambientes não críticos

DKS Enterprise

Workload crítico

SLA alvo: 99,9%

  • Tudo do Standard, mais:
  • Anti-afinidade auditada entre hosts físicos
  • Autoscaling de aplicações (HPA)
  • WAF de borda (Cloudflare)
  • DR com restore testado + relatório mensal de SLO
  • Suporte 24×7

// para o que não pode parar

Roadmap

Da prova de conceito ao catálogo

A tecnologia já está provada — este site é servido por ela. As fases abaixo transformam a prova em produto vendável, em ordem de dependência.

Concluída

Prova de conceito

Cluster kubeadm completo no VMware: rede Cilium, MetalLB, ingress público com HTTPS automático e aplicação servida da internet — este site.

Fase 1 · semanas 1–2

Alta disponibilidade do control plane

Três control planes com VIP (kube-vip) e anti-afinidade entre hosts físicos. Pré-requisito de qualquer SLA: elimina o ponto único de falha.

Fase 2 · semanas 2–4

Storage de produção

vSphere CSI: volumes que sobrevivem à perda de um nó, na resiliência do datastore que a Datacentrics já opera.

Fase 3 · semanas 3–5

Segurança auditável

Políticas de rede default-deny, gestão de secrets, RBAC por perfil e relatório CIS Benchmark — evidência pronta para a auditoria do cliente.

Fase 4 · semanas 4–6

Observabilidade e SLO

Prometheus, Grafana e Loki com alertas no plantão DCX. O SLA passa a ser um número medido e publicado, não uma promessa.

Fase 5 · semanas 6–9

Esteira de provisionamento

Terraform, Ansible e ArgoCD: cluster novo de cliente em até um dia, sem passos manuais. É o que define a margem do produto.

Fase 6 · semanas 8–12

Cliente piloto

Segundo cluster nasce inteiro pela esteira, com dashboards, backup e TLS no primeiro dia. Critério de pronto para vender: a repetição, não o protótipo.