Skip to content

Managed Multi-Region Kubernetes

A Kubernetes cluster does not have to be limited to one datacenter or one cloud provider. InteSys operates managed clusters whose worker nodes can sit in a single region, spread across our two Brazilian datacenters, or be distributed among different providers — always as one Kubernetes environment.

One Kubernetes environment with workers in br-sp-1, br-sp-2 and public cloud, under a control plane operated by InteSys

From the application's perspective, the nodes are part of the same cluster. From the infrastructure perspective, each group of nodes belongs to a different region, datacenter or provider.

Where worker nodes can live

Location Detail
br-sp-1 Cirion SAO1 — Cotia/SP, Brazil
br-sp-2 Equinix SP3 — Tamboré/SP, Brazil
Public cloud AWS, Google Cloud, Microsoft Azure, DigitalOcean, OVHcloud, Hetzner
Customer infrastructure Own datacenter or colocation
Other compatible environments Evaluated case by case

There is no requirement to use InteSys infrastructure exclusively. The combination follows the application's requirements.

The control plane is not on your bill

In traditional Kubernetes environments, the customer has to provision servers dedicated purely to the control plane — in a highly available setup, usually three machines that run none of the application's workloads.

Traditional model with a billed control plane compared with the InteSys managed model

The control plane does not disappear from the architecture: it is abstracted, operated and provided by InteSys as part of the platform.

Customers pay for the computing resources used by their worker nodes. CPU, memory, storage and traffic vary with the selected region and provider — which also makes it possible to use each provider where it offers the greatest technical or commercial advantage.

Deployment models

Model Arrangement Suited to
Single region Workers in one region Regional applications, simplicity and cost as priorities
Multi-DC in Brazil br-sp-1 + br-sp-2 High availability with all data inside the country
Hybrid InteSys + public cloud Extra capacity, DR or international reach
Multi-cloud Two or more providers Reduced dependency on a single provider

→ The four models in detail

What InteSys operates

  • Platform lifecycle — stable, supported versions, upgrade planning, progressive worker upgrades and controlled node replacement.
  • Cilium networking — identity-based L3/L4 policies, namespace segmentation, network observability and node-to-node encryption when the architecture calls for it.
  • Layered security — operating system hardening aligned with CIS Benchmarks, least-privilege RBAC, Pod Security Standards and restrictions on privileged containers.
  • Topology as policy — nodes labelled by region and zone, enabling automatic distribution, anti-affinity, topology spread constraints and PodDisruptionBudgets.
  • Operating systems chosen per project — minimal, Cloud Native or immutable distributions, selected for compatibility, attack surface and compliance requirements.

Customers keep control of their workloads: namespaces, deployments, services and applications. InteSys operates the Kubernetes platform required to run them.

Managed, not merely hosted

The goal is not to hand over servers with Kubernetes installed. The platform itself is operated as a service — including upgrades, networking, security policies and cluster health monitoring.

Choosing the architecture

There is no single multi-region architecture that suits every application. A globally distributed stateless application has very different requirements from a transactional database that must keep all data in Brazil.

Requirement Typical architecture
Lower cost and simplicity Single region
High availability in Brazil br-sp-1 + br-sp-2
Disaster recovery with another provider InteSys + public cloud
Reduced provider dependency Multi-cloud
Users across different continents Global Kubernetes
Existing customer infrastructure InteSys + on-premises
Data restricted to Brazil Workers and storage in Brazilian regions

Evolution is gradual: start in br-sp-1, add br-sp-2 for high availability and, when a real requirement appears, bring in public cloud or your own infrastructure. There is no need to start global in order to get there.

Next Steps