Deployment Architecture Overview
Palette provides a centralized management plane that orchestrates Kubernetes clusters across public clouds, private data centers, and edge environments. The management plane handles cluster provisioning, monitoring, and Day-2 operations, while a lightweight agent installed in each workload cluster enforces the desired state locally.
This section covers the deployment models available for hosting the Palette management plane, the data flow between Palette and your workload clusters, and the internal communication mechanisms that keep the platform reliable at scale.
Deployment Models
Palette and Palette VerteX support three architecture models: multi-tenant SaaS, dedicated SaaS, and self-hosted, which includes support for airgapped environments. With these flexible deployment models, we can work within your existing requirements for responsibility separation and network restrictions. Model availability depends on the edition of Palette (Palette or Palette VerteX) and the location of the deployment (US or EU).
| Deployment Model | Description |
|---|---|
| Multi-Tenant SaaS | The management plane is hosted in AWS and managed by Spectro Cloud. Each customer operates as an isolated tenant with enforced data isolation and access controls. Spectro Cloud controls management plane upgrades. |
| Dedicated SaaS | The management plane is hosted as a dedicated instance in a customer-selected cloud and region within Spectro Cloud's cloud account. Spectro Cloud manages the instance, and the customer controls when to upgrade the management plane. |
| Self-Hosted | The management plane is hosted in the customer's environment. This environment can be a public cloud, a data center, or bare metal devices. This model supports airgapped environments. |
SaaS Region Availability
| Deployment Model | Geography | Palette Regions | Palette VerteX Regions |
|---|---|---|---|
| Multi-Tenant SaaS | US | us-east-1, us-west-1, and us-west-2 | us-gov-west-1 |
| Multi-Tenant SaaS | EU | eu-central-1 and eu-west-1 | Not available |
| Dedicated SaaS | US | Customer decides | Not available |
| Dedicated SaaS | EU | Customer decides | Not available |
Product Security
At Spectro Cloud, we recognize the importance of robust security measures in today's rapidly evolving digital landscape. As the provider of our cutting-edge SaaS and self-hosted Palette product, our commitment to safeguarding your data and ensuring the integrity of our services is paramount. Learn more about Palette security by reviewing the Security section.
SaaS Architecture and Data Flow
The Palette SaaS platform can manage clusters on public clouds (AWS, Azure, and Google Cloud), data centers (VMware vSphere, Apache CloudStack, MAAS, and Nutanix), and bare metal devices. The architecture and data flow slightly differ based on whether the target environment is a public cloud or private data center.
SaaS to Public Clouds
The following diagram illustrates the data flow for the Palette SaaS platform to manage the EKS cluster using the user's cloud account in AWS:
There are two main data flows represented in the provisioning flow (red) and monitoring flow (green).
-
Provisioning data flow: A tenant user from the browser or API client (e.g., Terraform provider) to configure Cluster Profile, Cloud Configuration (e.g., which cloud account to use, cloud-specific placement settings like VPC, subnet), and cluster specifications (e.g., cluster size, node instance type, etc.). This information is sent to Palette. In turn, Palette will invoke the cloud API to talk to the cloud endpoint using the cloud credentials specified to provision the Kubernetes cluster. Once the cluster is provisioned, a Palette management agent will be pushed and installed in the cluster. This agent will receive the Cluster Profile and Cluster Specifications as the desired state from SaaS. The agent will further inspect the desired state and pull additional add-on integrations from Palette's public package registry, or optionally a private package registry hosted by the tenant user. Once all required add-on integrations are installed, the agent will send a message to SaaS to indicate the full-stack K8s provisioning is completed.
-
Monitoring data flow: The agent will periodically report the cluster health status back to the Palette SaaS platform. The agent will also stay in the watch loop to check if the cluster's stat matches the declared desired state. If there is any deviation (e.g. a worker node is accidentally shut down by a user directly from the cloud console), the agent can either send an alert message or based on the policy, do auto reconciliation/self-healing to bring the cluster back to match with the desired state. If there is an updated Cluster Profile or Cluster Spec, the agent will receive the updated and desired state from SaaS. It will then enforce the desired state by making cluster configuration changes accordingly.
SaaS to Private Clouds / Data Center / Bare Metal
For private clouds like VMware, since the Palette SaaS platform does not have direct access to the private cloud endpoint (e.g., vCenter), there is one extra component, Palette Private Cloud Gateway, to be deployed in a private cloud environment to act as the local orchestrator and the proxy between Palette’s SaaS platform and cloud endpoint. The following diagram illustrates the data flow for the Palette SaaS platform to manage an on-prem VMware private data center:
Self-Hosted Architecture and Data Flow
Although the Palette SaaS platform fully supports both public clouds and data centers, some customers, especially with regulated industry or air-gapped environments, may prefer to install Palette in their own environment behind the firewall, so that they can control the platform upgrade cycles and ensure no sensitive data are exposed. For these use cases, Palette supports a self-hosted on-premises installation. The platform updates and add-on integration contents can be optionally downloaded from a self-hosted private repository instead of pulling from Palette’s hosted public repository.
Message Brokers
Palette’s internal microservices require a stable, secure, and scalable way to exchange information efficiently. To support this, Palette uses a gRPC Remote Procedure Call (gRPC)–based message broker service that acts as a central hub for communication between microservices through a publish-subscribe model. Each microservice can publish messages or subscribe to messages on specific topics, and the broker ensures that messages are delivered reliably, securely, and in real time.
To handle communication across large-scale, distributed environments, the message broker runs as multiple pod replicas within each management plane cluster. This provides the following benefits:
-
Load distribution - Incoming gRPC connections are automatically balanced across replicas to optimize resource usage and prevent message broker pods from becoming overloaded.
-
High availability - If a message broker pod fails, others continue to handle traffic without interruption. By default, each management plane includes two broker replicas.
-
Cluster quorum - Message brokers automatically detect each other and form a cluster, allowing them to coordinate message delivery and maintain consistent performance as the system scales.
-
Security - All communication between message broker pods is encrypted and authenticated using secondary certificates to ensure secure message exchange.
To inspect the message brokers of your self-hosted Palette or Palette VerteX management plane cluster, connect to your management plane cluster with the kubectl CLI and execute the following command.
kubectl get statefulset msgbroker --namespace hubble-system
NAME READY AGE
msgbroker 2/2 97d