Managed Kubernetes provides a streamlined way to deploy, manage, and scale containerized applications without the burden of maintaining the underlying infrastructure. With automated upgrades, monitoring, and scalability built in, you get all the power of Kubernetes—minus the operational complexity.

Setting up your Kubernetes cluster is quick and customizable. Start by selecting your deployment region to host your service close to your users or systems. Choose from multiple global data centers including France, Germany, UK, Singapore, and more.

Next, pick the Kubernetes version you want to deploy. We recommend using the latest stable version for the best security and compatibility.

Define your security update policy to control how patch updates are applied to your nodes:

Finally, name your service and choose an instance type that suits your workload—ranging from Basic to Business tiers, each with varying CPU, RAM, and pricing.

Once everything’s set, click Create Service to deploy your cluster.

The Service tab gives you a detailed overview of your Kubernetes cluster's configuration and status. It starts with basic information such as the unique cluster ID, the custom name you assigned, and its current operational status—whether it’s ready for use or still deploying. You’ll also see which Kubernetes version is running, helping you keep track of updates or compatibility needs.

The ETCD quota usage indicates how much of your cluster’s etcd key-value store is being used, which is important for configuration and cluster data storage. Below that, you can view the list of admission plugins that are currently enabled. These plugins help enforce policies on resource usage and access control within your cluster.

You can also see where your cluster is hosted geographically by checking the region, and determine whether it’s connected to a public or private network. Access-related details are provided as well, such as the Kubernetes API URL, which is used to connect to your cluster, and whether there are any limits placed on who can access the API.

Security features are also visible here. You can check your selected security update policy (like Maximum Security) and whether an OIDC provider is configured for secure authentication. Finally, you have access to the kubeconfig file, which contains credentials and configuration for securely accessing your cluster from command-line tools like.

The Actions section provides essential controls for managing, resetting, securing, or deleting your Kubernetes cluster. These tools allow you to rename the cluster, reset its configuration, regenerate security credentials, and manage update policies. Each action is designed to give you flexibility and control over your environment while maintaining security and service continuity. However, some actions are destructive and should be used with caution, as they can result in downtime or data loss.

Allows you to change the name of your cluster. This is useful for organizational clarity but does not affect your cluster’s functionality or configuration.

This action reinstalls your cluster to its original state. It will permanently delete all services, configurations, and data associated with the cluster. It’s an irreversible operation meant for complete reinitialization. You can choose to either delete all nodes or keep them and reinstall.

This regenerates your cluster’s kubeconfig file and security certificates. During this process, there may be a short period of downtime where access to the Kubernetes API is lost. Your running containers won’t be affected, but you’ll need to download the new kubeconfig afterward to regain control. All your Kubernetes resources remain intact.

Lets you set how patch updates are applied to your Kubernetes service:

Permanently deletes the cluster and all associated data. This action cannot be undone and does not include a refund. You must confirm by typing the cluster’s name to proceed. Use this only when you're sure the cluster is no longer needed.

Admission plugins control how Kubernetes handles and validates requests. In this section, you can enable or disable specific plugins to adjust your cluster’s behavior. For security reasons, the Node Restriction plugin must stay enabled and cannot be modified.

⚠️ Important: Any change to the admission plugins requires redeploying your API Server, which may cause a short disruption in service.

Control who can access your Kubernetes API server by specifying allowed IPv4 ranges. By default, if no IP addresses are added, the API server is publicly accessible without restrictions. To enhance security, you can add specific IPs to limit access to trusted clients only.

Use the Modify Limitations option to update or restrict access at any time.

OpenID Connect (OIDC) allows you to integrate external identity providers—such as Dex, Keycloak, or any SaaS provider that supports OpenID Connect discovery—to manage authentication for your Kubernetes cluster.

To set this up, you’ll need to provide your provider’s discovery URL (must use HTTPS), a Client ID, and optionally, a custom certificate authority (CA) if the provider’s certificate isn’t signed by a public root CA.

Advanced options let you define how user identity and group information is extracted from JWT tokens. You can specify claims for usernames and groups, set custom prefixes, restrict access by required claims, and choose acceptable signing algorithms.

Once configured, users can authenticate securely via your identity provider, streamlining access control and integrating Kubernetes authentication into your existing identity systems.
​
​

The Node Pools section displays details about each group of worker nodes in your Kubernetes cluster. Each pool has a unique name, associated flavor (defining CPU, RAM, and storage), and settings like anti-affinity to ensure high availability by spreading nodes across physical hardware.

You can also see the number of nodes currently running, whether autoscaling is enabled, the monthly cost, and the creation date. The status (e.g., READY) indicates whether the node pool is operational and ready to run workloads.

This section allows you to control who can reach your Kubernetes API server. By adding specific IPv4 ranges, you limit access to only trusted clients.

The Logs tab allows you to monitor and search through your cluster’s activity logs. You can filter logs by custom keywords and time ranges—such as the last 4 or 24 hours, or last 2 or 7 days—to help narrow down results during troubleshooting or audits. You can also activate Live Tail to see logs appear in real time as events happen. If no logs are displayed, it means there’s no recent activity matching your filters.