Xelon Kubernetes Service (XKS)
Xelon Kubernetes Service (XKS) is the managed Kubernetes offering on Xelon HQ. XKS provides conformant upstream Kubernetes with a managed control plane, automated node lifecycle, and native integrations for storage, networking, and load balancing.
XKS clusters run on Talos Linux — an immutable, minimal operating system purpose-built for Kubernetes. Talos eliminates SSH access and traditional package managers, reducing your attack surface and simplifying operations. Talos is the underlying OS; the managed Kubernetes service itself is XKS.
Talos Linux is fully API-managed, immutable, and contains only the components required to run Kubernetes. This makes XKS clusters more secure, consistent, and easier to upgrade.
Creating an XKS Cluster
Navigate to Kubernetes > Kubernetes and click Create Cluster.
| Field | Description |
|---|---|
| Cluster Name | A unique name for your cluster. Use lowercase letters, numbers, and hyphens. |
| Select Tenant | The tenant that owns the cluster. |
| Select Cloud | The cloud location for the cluster infrastructure. |
| Talos Version | Select the Talos Linux version to use for the cluster nodes. |
| Kubernetes Version | Select the Kubernetes version. Must be compatible with the chosen Talos version. |
| Schematic ID | Optional. A unique identifier for a specific Talos OS image with built-in components from the Talos Factory. |
Each Kubernetes cluster is automatically provisioned with a dedicated /29 WAN subnet. This gives the cluster its own static public IP addresses for the API endpoint, load balancers, and virtual IPs. You do not need to reserve IPs manually — the entire subnet is dedicated to the cluster for its lifetime.
Control Plane Configuration
Configure the control plane nodes that manage the cluster state and API server:
| Parameter | Description | Recommendation |
|---|---|---|
| CPU Cores | Virtual CPU cores per control plane node. | 2+ cores |
| RAM | Memory per control plane node in GB. | 4+ GB |
| Disk Size | Storage per control plane node in GB. | 50+ GB |
| Cluster Type | Toggle Production for a 3-node HA control plane (recommended for any cluster that will run real workloads), or Test for a single non-HA control plane node. The number of control plane nodes is fixed by this choice — there is no free-form node-count field. You can switch from Test to Production after creation (see Editing Control Planes below). | Production |
Worker Node Configuration
Worker nodes run your application workloads. Configure resources based on your expected workload requirements:
| Parameter | Description | Minimum |
|---|---|---|
| CPU Cores | Virtual CPU cores per worker node. | 1 core (default 2) |
| RAM | Memory per worker node in GB. | 2 GB |
| Disk Size | Storage per worker node in GB. | 20 GB |
| Node Count | Number of worker nodes. | 1 node |
Click Create to start provisioning. XKS clusters typically take a few minutes to become ready.
What's Included vs. What You Manage
Xelon HQ provisions a production-ready, conformant Kubernetes cluster with a baseline of pre-installed components. Everything beyond the baseline is fully under your control — XKS clusters are standard upstream Kubernetes, so any workload, CRD, operator, or add-on you can run on vanilla Kubernetes will run here.
Pre-Installed by Xelon
Every XKS cluster is bootstrapped with the following components, managed by Xelon:
| Component | Purpose |
|---|---|
| Cilium | The pre-installed Container Network Interface (CNI) on every XKS cluster, providing pod networking, network policies, and observability (kube-proxy is disabled). Cilium's ingress controller / cilium IngressClass is not guaranteed to be enabled by the managed baseline — confirm the IngressClass exists in your cluster (kubectl get ingressclass) before relying on it, or install an ingress controller of your choice. |
| Metrics Server | Serves resource metrics (CPU, memory) on the metrics.k8s.io API, enabling kubectl top. |
| Xelon CSI Driver | Container Storage Interface driver that integrates Kubernetes PersistentVolumeClaim resources with Xelon persistent storage. |
| Xelon Cloud Controller Manager (CCM) | Cloud-provider integration for Service type=LoadBalancer, node lifecycle management, and routing. |
| Kubelet Serving Certificate Approver | Automatically approves kubelet serving certificates so metrics and log endpoints work out of the box. |
What You Manage
You have full administrative access to the cluster via the provided kubeconfig. There are no admission policies or API restrictions imposed by Xelon beyond the pre-installed components. Everything listed below is supported without limitations:
- Custom Resource Definitions (CRDs) — Install any CRD required by your applications, operators, or platform tools (e.g., cert-manager, Sealed Secrets, Kyverno, Argo CD, Flux).
- Gateway API — Install the Gateway API CRDs and use
Gateway,GatewayClass,HTTPRoute, andGRPCRouteresources along with a compatible implementation (e.g., Cilium Gateway, Istio, Envoy Gateway). - Ingress controllers — The managed baseline does not guarantee an ingress controller is enabled (see the note on Cilium in the table above). Install the ingress controller of your choice — NGINX Ingress, Traefik, HAProxy, Kong, Contour, etc. — based on the protocol and feature support your workloads need.
- Service meshes — Install Istio, Linkerd, or Cilium Service Mesh for advanced traffic management, mTLS, and observability.
- Custom operators and controllers — Run any Kubernetes operator or controller your workloads require.
- Helm charts — Deploy applications and platform components via Helm.
- Autoscaling (HPA, VPA, Cluster Autoscaler) — Install and configure Horizontal Pod Autoscaler, Vertical Pod Autoscaler, or the Kubernetes Cluster Autoscaler yourself. These controllers are not part of the managed offering today. The pre-installed Metrics Server provides the metrics API required for HPA/VPA, but the autoscaler controllers themselves must be deployed by the customer.
XKS clusters on Xelon HQ are conformant upstream Kubernetes. If a workload runs on any other Kubernetes distribution, it will run here. Xelon does not fork Kubernetes or impose custom APIs.
Worker node counts and per-node resources (CPU, RAM, disk) are adjusted manually through the HQ UI or API. Load-based cluster node autoscaling is not provided by the managed service — you can install the Kubernetes Cluster Autoscaler yourself if automated node scaling is required.
Cluster Info and Status
The cluster details page provides an overview of your XKS cluster including:
- Cluster health status and readiness
- Talos Linux version and Kubernetes version
- Control plane and worker node counts
- API server endpoint
- Individual node status and resource utilization
Editing Control Planes
You can modify the control plane configuration after cluster creation. From the cluster details page, scroll to the Control Planes section and click the Edit button next to it. You can adjust:
- CPU cores and RAM per control plane node
- Disk size per node
The number of control plane nodes is not editable here — it is fixed by the cluster type you picked at creation (Test = 1 node, Production = 3 nodes).
To grow a Test cluster from 1 to 3 control plane nodes, click the Upgrade button shown next to the control plane nodes in the Control Planes section on the cluster detail page. The Upgrade button is only visible on Test-mode clusters. Upgrading also adds a second load balancer (1 → 2) to provide HA for the API endpoint. This change cannot be reverted — a cluster that has been upgraded to Production cannot be moved back to Test mode.
Modifying control plane resources triggers a rolling update. Nodes are updated one at a time to maintain cluster availability. Run updates on a Production (3-node HA) control plane so the cluster stays available while nodes are updated one at a time; on a Test cluster the single control plane node makes the API briefly unavailable during the rolling update.
Managing Worker Nodes
Worker nodes can be scaled and reconfigured as your workload demands change:
- Scale up: Increase the worker node count to add capacity.
- Scale down: Decrease the node count to reduce costs. Workloads are automatically rescheduled.
- Resize: Modify CPU, RAM, or disk per worker node.
Cluster Resources
The resources view shows the aggregate compute capacity of your cluster, including total and available CPU, memory, and storage across all nodes. Use this view to determine whether you need to scale your cluster.
Upgrading Talos and Kubernetes Versions
Xelon HQ supports in-place upgrades for both Talos Linux and Kubernetes versions. From the cluster details page, click Upgrade and select the target versions.
Check Compatibility
Verify that your target Kubernetes version is compatible with the selected Talos version. The upgrade dialog shows only compatible combinations.
Initiate Upgrade
Select the new Talos and/or Kubernetes version and confirm the upgrade. Control plane nodes are upgraded first, followed by worker nodes.
Monitor Progress
Track the upgrade progress in the cluster details view. Each node shows its current version and upgrade status.
Test version upgrades on a non-production cluster first. Ensure your workloads are compatible with the new Kubernetes version before upgrading production clusters.
Deleting a Cluster
To delete an XKS cluster, navigate to the cluster details page and click Delete Cluster. Confirm the deletion when prompted.
Deleting a cluster permanently destroys all nodes, workloads, persistent volumes, and associated resources. This action is irreversible.