Getting started

This guide walks new users through the essential first steps of setting up and using the Cloudfleet platform: creating an organization, launching a cluster, connecting a cloud account, and deploying and exposing your first application.

At its core, Cloudfleet Kubernetes Engine (CFKE) provides a fully managed Kubernetes service. This service is engineered to run containerized workloads on clusters that can span multiple cloud providers and on-premise setups, offering a single pane of glass for infrastructure management. This approach addresses the common challenge of managing diversified infrastructure environments, each with its own tools and configurations, by providing a unified control plane and consistent operational experience.

If you’re familiar with traditional Kubernetes, one key difference is how Cloudfleet handles infrastructure provisioning. In traditional environments, you provision virtual machines or physical servers upfront, making decisions about node count and instance types before deploying applications. Cloudfleet reverses this workflow: you simply connect your cloud account (called a Fleet), deploy your workloads, and Cloudfleet automatically provisions the optimal nodes to run them. The system continuously monitors your cluster, automatically removing unused nodes when workloads scale down. This eliminates capacity planning and ensures you only pay for infrastructure while it’s actually needed.

To follow this guide, you will need:

• A Cloudfleet account. New accounts start with €200 in credit, valid for 30 days, so you can complete this guide without any charges.
• An account with a supported cloud provider. This guide uses Hetzner Cloud for the walkthrough, but AWS, GCP, or your own Linux servers work just as well.
• About 15 minutes.

Understanding key Cloudfleet concepts

Before diving into the practical steps, it’s helpful to understand a few core concepts that are fundamental to the Cloudfleet platform. These concepts are central to how Cloudfleet simplifies and automates Kubernetes management.

Cloudfleet Kubernetes Engine (CFKE)

CFKE is the heart of Cloudfleet’s offering. It is a fully managed Kubernetes service designed to run containerized workloads across different cloud and on-premise infrastructure environments at the same time.

• Managed control plane: A significant feature of CFKE is its managed Kubernetes control plane. This means Cloudfleet handles the setup, maintenance, availability, and scalability of the Kubernetes API servers and the underlying persistence layer. This frees users from the operational overhead of managing the Kubernetes master components, allowing them to focus on their applications.

• Node auto-provisioning: CFKE features a sophisticated node auto-provisioner that automates the provisioning and management of worker nodes (the compute infrastructure where applications run) for supported cloud providers (AWS, GCP, and Hetzner Cloud). It dynamically selects optimal compute instances and scales them as needed based on workload demands, optimizes costs, and handles the full node lifecycle. This “hands-free” infrastructure management means users don’t need to manually create, size, or upgrade worker nodes on these supported platforms.

• Self-managed nodes: For any infrastructure beyond the natively supported cloud providers, Cloudfleet allows adding any VM or bare-metal Linux server to an existing CFKE cluster. This extends Cloudfleet’s capabilities to any cloud provider, on-premise environments, or edge locations. Self-managed nodes can be easily provisioned using Terraform or added manually, making Cloudfleet truly infrastructure-agnostic.

For a detailed comparison of these approaches and guidance on when to use each, see How Cloudfleet provisions nodes.

• Kubernetes compatibility: CFKE runs upstream Kubernetes and adheres to Kubernetes conformance standards. This ensures that applications deployed on CFKE are portable and can operate with existing Kubernetes tools and plugins without modification.

Fleets

A Fleet is a connection between your CFKE cluster and a cloud provider account (AWS, GCP, or Hetzner Cloud) where Cloudfleet can provision worker nodes. When you create a Fleet, you grant Cloudfleet permission to create and manage virtual machines in your cloud account on your behalf.

Nodes are provisioned directly in your cloud provider account, meaning you pay the cloud provider for infrastructure costs using your existing agreement, credits, or discounts. All workloads run in your own cloud account, and Cloudfleet manages the Kubernetes layer without accessing your application data. Cloudfleet requests only the permissions needed to provision and manage nodes, and you can revoke access at any time.

A single CFKE cluster can have multiple Fleets across different cloud providers, enabling workloads to run across AWS, GCP, and Hetzner simultaneously.

Step 1: Creating your Cloudfleet organization

The first practical step is to create a Cloudfleet organization. As a first step, you create the root account together with the organization that provides access to the Cloudfleet Console, the central hub for managing organizations, clusters, and other resources.

1. Visit the sign-up page: Navigate to the Cloudfleet sign-up page. The process takes only a few minutes.
2. Enter your details: Provide your name, email address, and password.
3. Choose your organization type: Select whether the organization is personal (for individuals) or business (for legal entities). Business organizations use a company legal name on invoices and can add a VAT or tax ID.
4. Add billing information: Enter a billing address and a payment method. Both are required to create an organization. Cloudfleet accepts credit and debit cards for all organizations, and SEPA Direct Debit for business organizations. Every new account starts with €200 in credit, valid for 30 days, so there is no charge to begin.
5. Activate your account: Follow the instructions sent to the provided email address to activate the account.
6. Access the console: Once the account is set up and activated, you can login with your credentials to the Cloudfleet Console.

For details on cluster plans and pricing, see the Cloudfleet pricing page.

Once you have an active organization, you can also invite your team members to the organization for collaboration.

Step 2: Creating your first CFKE cluster

When you create a cluster, you get an empty Kubernetes cluster with no nodes. To run applications, this cluster then needs worker nodes, which are provisioned via a Fleet that connects to a cloud provider account or on-premises resources. You will set up the Fleet in the next step; first, create the cluster itself.

1. Start the wizard: In the Cloudfleet Console, click the “Create cluster” button to launch the cluster creation wizard.

   

2. Choose the control plane region and cluster type: The control plane region is the geographical location where your cluster’s control plane runs. Importantly, it does not restrict where your worker nodes can run: a Cloudfleet cluster can span nodes across multiple regions, multiple cloud providers, and even on-premises hardware at the same time. Choose a region close to where most of your workloads will run, or one that satisfies your regulatory requirements. Keep in mind that the control plane region cannot be changed after the cluster is created.

   For the cluster type, Cloudfleet offers three tiers. Basic runs on a shared, single-zone control plane with a low monthly base fee and is suitable for development, testing, and non-critical workloads. Pro provides a dedicated, highly available control plane with a 99.95% uptime SLA and technical support, making it the recommended choice for production. Enterprise adds a stricter SLA with custom terms, audit logging, and a named technical account manager. You can start with Basic and upgrade later. See Cluster types for a detailed comparison.

   

3. Set the name, Kubernetes version, and release channel: Choose a human-friendly name for the cluster (e.g. my-first-cfke-cluster). The default version, 1.x.x, always tracks the latest v1 release. The release channel controls how quickly your cluster adopts new Kubernetes versions: the default Rapid channel adopts new versions as soon as Cloudfleet publishes them, while the Stable and Extended channels (available on Pro and Enterprise clusters) roll out more conservatively. See Kubernetes versions and upgrades for details.

   

4. Review the remaining options: The following steps let you customize networking (available on Pro and Enterprise clusters) and GPU sharing options. The defaults are fine for a first cluster.

5. Create the cluster: The final step displays your selected configuration. Review your choices and click “Create”. Provisioning the control plane takes 2-3 minutes, and the console will indicate when the cluster is ready.

Step 3: Adding compute capacity with a Fleet

Once the cluster’s control plane is active, it requires worker nodes to run applications. This is where Fleets are essential. A Fleet represents a connected cloud account or on-premises infrastructure where Cloudfleet is authorized to provision and manage nodes.

When you define a Fleet, you do not actually create nodes; you only specify the cloud provider and provide the necessary authorization details. Once you deploy an application, Cloudfleet evaluates your application’s requirements (e.g. CPU, memory, region) and provisions the appropriate number and size of nodes in the connected cloud account. If Cloudfleet detects idle capacity, it removes or consolidates unused nodes, ensuring efficient resource utilization and cost optimization.

Ways to add nodes

Cloudfleet supports several ways to add compute capacity to a cluster, and you can freely mix them within the same cluster:

• Auto-provisioning Fleets on AWS, GCP, and Hetzner Cloud: Cloudfleet creates, scales, and manages nodes for you automatically based on your workloads. Hetzner Cloud requires only an API token. AWS and GCP use keyless authentication: on AWS, you create an IAM role that CFKE can assume (Cloudfleet provides a Terraform module that automates this), and on GCP, you grant IAM roles to a CFKE-managed service account principal in your project. See the Fleet configuration documentation for step-by-step setup instructions for each provider.

• Self-managed nodes: Any VM or bare-metal Linux server can join your cluster, whether it runs in another cloud provider, your on-premises data center, or an edge location. You provision the machine yourself and connect it with a single command, or automate the process with Terraform. See the self-managed nodes documentation for instructions and provider-specific guides.

• Fleets with static capacity (private preview): Reserve a fixed number of nodes of a specific instance type, cloud, and region, similar to a traditional node pool, for workloads that need hot capacity at all times. See Fleets with static capacity.

• Infrastructure as code: For production environments, you can manage clusters, Fleets, and self-managed nodes declaratively with the Cloudfleet Terraform provider.

For a comparison of these approaches and guidance on when to use each, see How Cloudfleet provisions nodes.

Hetzner Cloud is just one of the options, and it is the one we cover in this guide because it is the fastest to set up: it requires nothing more than an API token. If you use a different provider or your own hardware, follow the corresponding guide linked above and then continue with the next step. The rest of this guide works the same regardless of which path you choose.

Prerequisites

Before creating the Fleet, ensure you have:

• A Hetzner Cloud account and project. If you don’t have one yet, you can create it in the Hetzner Cloud Console.
• A Hetzner Cloud API token with “Read & Write” permissions, generated as explained in the Hetzner documentation. Copy and temporarily store the token; you will paste it into the Cloudfleet Console in a moment.

You don’t need to launch any servers in advance. Cloudfleet provisions them on demand through the Hetzner Cloud API as workloads are deployed.

Creating a Fleet

1. Open the node setup dialog: In the Cloudfleet Console, click “Add nodes” on your cluster’s card.

   

   Cloudfleet supports two ways of adding nodes to a cluster: auto-provisioning Fleets, where Cloudfleet creates and scales nodes for you automatically, and self-managed nodes, where you connect servers you manage yourself. For this guide, select “Auto-provisioning fleet”.

   

2. Choose a name and providers: Name your Fleet and select the infrastructure providers it can use. A single Fleet can span multiple providers and regions, allowing you to mix them within a single cluster, and you can add more providers later. For this guide, enable “Hetzner Cloud” and click “Next”.

   

3. Provide the Hetzner API token: Paste the API token you generated earlier. Cloudfleet verifies the token and uses it to securely provision nodes in your Hetzner Cloud account. Nodes are created directly in your Hetzner project, so you pay Hetzner for the infrastructure at their regular prices.

4. Fine-tune how the Fleet provisions nodes: Normally, the size, location, and type of each node are determined by your workload definitions: Cloudfleet reads the resource requests, node affinities, and selector labels of your pods and picks the most cost-effective matching instance. The Fleet configuration lets you narrow these choices if needed: you can choose a scaling profile, restrict the CPU architecture (amd64/arm64) and capacity type (on-demand or spot), cap the total vCPU count of the Fleet as a cost control measure, or limit provisioning to specific regions and instance families with Fleet constraints. The defaults are fine for a first cluster.

   

5. Finalize Fleet creation: Review your Fleet configuration and click “Create”.

With the Fleet configured, Cloudfleet now has the authorization and information needed to provision worker nodes in your Hetzner Cloud account as applications are deployed to the CFKE cluster.

Step 4: Installing and configuring the Cloudfleet CLI

With the cluster running and a Fleet configured, the next step is to install the tools needed to access the cluster and deploy applications. The Cloudfleet Command Line Interface (CLI), cloudfleet-cli (often referred to as cloudfleet), is an essential tool for managing Cloudfleet resources from a terminal. It allows users to create and manage clusters, configure kubectl, add self-managed nodes, and interact with the Cloudfleet API programmatically.

Installing the Cloudfleet CLI

Cloudfleet provides installation methods for various operating systems, with package managers being the preferred route for ease of installation and updates. You can also find these instructions in the Cloudfleet Console by clicking “Configure kubectl” on your cluster’s card.

brew install cloudfleetai/tap/cloudfleet-cli

curl -fsSL https://downloads.cloudfleet.ai/apt/pubkey.gpg \
  | sudo tee /usr/share/keyrings/cloudfleet-archive-keyring.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/cloudfleet-archive-keyring.gpg] \
https://downloads.cloudfleet.ai/apt stable main" \
  | sudo tee /etc/apt/sources.list.d/cloudfleet.list
sudo apt-get update
sudo apt-get install cloudfleet

sudo tee /etc/yum.repos.d/cloudfleet.repo << 'EOF'
[cloudfleet]
name=Cloudfleet
baseurl=https://downloads.cloudfleet.ai/yum
enabled=1
gpgcheck=1
gpgkey=https://downloads.cloudfleet.ai/yum/pubkey.gpg
EOF
sudo dnf install cloudfleet

sudo rpm -i cloudfleet.rpm

winget install Cloudfleet.CLI

After installation, users can verify it by running cloudfleet --version or cloudfleet --help to confirm.

Installing kubectl

The Kubernetes command-line tool, kubectl, allows you to run commands against the Kubernetes cluster and works together with Cloudfleet CLI to interact with your CFKE cluster.

If you have been using Kubernetes already, you might have already installed kubectl. If not, there are multiple ways of installing kubectl and you can visit the Kubernetes documentation to learn how to install it based on your platform and preferred method of installation. On macOS, you can install kubectl with Homebrew (brew install kubectl), and on Windows with winget (winget install kubectl).

Connecting kubectl to your CFKE cluster

To interact with the Kubernetes cluster using kubectl, the local kubectl configuration (kubeconfig) must be updated to point to the new CFKE cluster. Additionally, the Cloudfleet CLI must be configured with your account to enable authentication against the cluster.

To perform these steps, click “Configure kubectl” on your cluster’s card in the Cloudfleet Console. The “Connect to cluster” wizard will guide you through the CLI tool configuration. You can skip the first step if you have already installed the Cloudfleet CLI.

First, inform the CLI which organization you are working with by creating a profile. Copy and execute the first command from the wizard, replacing YOUR_ORGANIZATION_ID with your actual organization ID:

cloudfleet auth add-profile user default YOUR_ORGANIZATION_ID

Running this command configures a profile named “default” for your CLI. If you have access to multiple organizations, you can configure your CLI for them as well, but “default” will suffice for now. Your organization ID is displayed in the wizard, and can also be found in the console by navigating to Billing -> Payment and viewing it under the Billing Contact Information section.

Note: User authentication requires a browser to complete the authentication process. The CLI will open a browser window to authenticate the user. If you are using the CLI in a headless environment (including WSL on Windows), please use token-based authentication as a workaround.

After adding the profile, configure kubectl to use the Cloudfleet CLI as an authentication helper. This eliminates the need to manually configure certificates or manage passwords. Copy and execute the second command from the wizard, replacing YOUR_CLUSTER_ID with your actual cluster ID:

cloudfleet clusters kubeconfig YOUR_CLUSTER_ID

This command updates your ~/.kube/config file, allowing you to access your CFKE cluster with a new context named YOUR_CLUSTER_ID/default. For convenience, set the current context to the newly created cluster:

kubectl config use-context YOUR_CLUSTER_ID/default

You can now verify the connectivity by executing the following command:

kubectl cluster-info

This should display information about the Kubernetes control plane. Another useful command is:

kubectl get nodes

Initially, if no workloads have been deployed, this command will return no nodes. This is normal and expected. As previously explained, CFKE worker nodes are provisioned on-demand by the node auto-provisioner, so a new cluster starts without any nodes. Nodes will appear automatically when you deploy your first application in the next step.

Step 5: Deploying your first application

Now that the CFKE cluster is running, a Fleet is configured, and kubectl is connected, it’s time to deploy a sample application. This will demonstrate how Cloudfleet, through Kubernetes, orchestrates workloads and how its node auto-provisioner works. Standard Kubernetes tooling, specifically kubectl, is used for this purpose.

Deploying a sample application

A common “hello world” example for Kubernetes is deploying an Nginx web server.

Create a Deployment: Use the following kubectl command to create a Kubernetes Deployment:

kubectl create deployment nginx-deployment --image=nginx:latest --replicas=2

This command instructs Kubernetes to:

• create deployment nginx-deployment: Create a new Deployment object named nginx-deployment.
• –image=nginx:latest: Use the latest official Nginx image from Docker Hub
• –replicas=2: Request two running instances (Pods) of the Nginx application. Deploying two replicas, rather than one, introduces a basic level of availability and can better demonstrate how Kubernetes distributes workloads, potentially across multiple auto-provisioned nodes.

Once deployed, CFKE locates the most cost-effective server that meets the location and resource requirements of the Pods. With the Hetzner Fleet from this guide, both Nginx Pods fit on the smallest available server type, provisioned in the cheapest available region. The whole demo runs on a single small virtual machine that costs a few cents per hour, billed directly by your cloud provider.

Checking your deployment

After issuing the deployment command, Kubernetes will begin working to achieve the desired state.

Check Deployment status:

kubectl get deployments

This command will display the nginx-deployment and its status, indicating the number of replicas that are ready and available.

Check Pod status:

kubectl get pods

This command will list the individual Nginx Pods and their current status. Initially, they might go through states such as Pending and ContainerCreating before reaching the Running state.

The Pods may remain in the Pending state for a short period while Cloudfleet’s node auto-provisioner provisions new worker nodes in the configured Fleet to accommodate them. This is expected behavior and demonstrates a key automation feature of CFKE.

Note: If Pods stay in Pending for more than a few minutes, open the Events tab in the Cloudfleet Console. Provisioning problems such as an invalid API token, provider quota limits, or overly strict Fleet constraints are reported there. If you get stuck, feel free to contact support.

Watch nodes being provisioned:

You can observe the provisioning process while it happens. Each node request is represented by a NodeClaim object:

kubectl get nodeclaims -o wide

This shows the instance type, capacity type, and region that the node auto-provisioner selected for each node. Once the nodes have joined the cluster, they appear in kubectl get nodes. After a few moments, the output should look similar to this (names, instance types, and regions will differ based on your Fleet):

$ kubectl get pods
NAME                               READY   STATUS    RESTARTS   AGE
nginx-deployment-98d9dcdf8-mdtwc   1/1     Running   0          5m48s
nginx-deployment-98d9dcdf8-x7k2p   1/1     Running   0          5m48s

$ kubectl get nodeclaims -o wide
NAME            TYPE   CAPACITY    ZONE   NODE                       READY   AGE     IMAGEID        ID                                                NODEPOOL   NODECLASS   DRIFTED
fleet-1-d4p4t   cx23   on-demand   nbg1   inviting-bull-2768940197   True    5m44s   ubuntu-24.04   hetzner://fleet-1/nbg1/inviting-bull-2768940197   fleet-1    fleet-1

$ kubectl get nodes
NAME                       STATUS   ROLES    AGE     VERSION
inviting-bull-2768940197   Ready    <none>   4m33s   v1.34.9

You can also watch the node provisioning progress on your cluster’s card in the Cloudfleet Console:

Kubernetes components generate events for all changes in the cluster. You can monitor these events with kubectl events, or use the Events tab in the Cloudfleet Console for an aggregated view of events across all your clusters:

Once the nodes are ready and all Pods are running, you can navigate to the Workloads tab in the Cloudfleet Console to view the current state of your Pods:

The provisioned instances appear in your own cloud provider console as regular virtual machines. All servers created by Cloudfleet are tagged, making them easy to identify and monitor for cost tracking.

Understanding node auto-provisioning in action

When the nginx-deployment was created, CFKE’s node auto-provisioner detected the new workload requirements (two Nginx Pods needing resources).

If the cluster had no suitable worker nodes, or if existing nodes were at capacity, the node auto-provisioner would automatically:

1. Calculate the optimal type and size of virtual machines needed from the configured Fleet (e.g., specific instance types from AWS, GCP, or Hetzner).
2. Provision these new nodes.
3. Once the nodes join the cluster and are ready, Kubernetes schedules the Nginx Pods onto them.

The node auto-provisioner selects the nodes to be created based on Pod requirements and labels. In this example, we did not add any labels to the Pods, which instructed CFKE to create the nodes with the cheapest available option. Since CFKE is a global solution, it also finds the cheapest region among the providers enabled in your Fleet and runs the workload in that place.

However, many times we want to influence which cloud or geography our workload must run in. In this case, we can use Pod labels and node selectors to instruct CFKE to deploy the workloads only in those specific places. To learn more about the large set of options that CFKE offers for workload scheduling, please visit the node auto-provisioning document.

Step 6: Exposing the application to the internet

In Kubernetes, deployments are exposed to the public internet using Services. A Service is a Kubernetes object that functions as a load balancer, directing traffic to the appropriate Pods based on labels.

To expose the demo Nginx deployment, create a Service using the following command:

kubectl expose deployment nginx-deployment \
    --type=LoadBalancer --name=nginx-service \
    --port=80 --target-port=80

When you create a Service of type LoadBalancer in CFKE, Cloudfleet detects which cloud providers and regions your nodes run in and automatically provisions a load balancer within each of them. In a single-provider setup like this guide, that means one load balancer in your cloud account, next to your nodes. In a multi-cloud cluster, CFKE provisions a load balancer in every provider and region where nodes exist, so traffic can be served close to your workloads.

After the load balancer is provisioned, you can retrieve its IP address by running:

$ kubectl get svc nginx-service
NAME            TYPE           CLUSTER-IP      EXTERNAL-IP                    PORT(S)        AGE
nginx-service   LoadBalancer   10.111.186.87   192.0.2.254,2001:db8:5678::1   80:30239/TCP   96s

The external IP address (or addresses, in a multi-cloud cluster) appears in the EXTERNAL-IP column. Navigate to this address in a web browser and the default Nginx welcome page should appear.

Note: Load balancer provisioning and features vary by cloud provider. See the load balancing documentation for the current support matrix and configuration options, and on-premises load balancing with BGP for self-managed environments.

When you are done experimenting, you can remove the demo application with kubectl delete svc nginx-service and kubectl delete deployment nginx-deployment. The node auto-provisioner consolidates and removes nodes that are no longer needed for your workloads.

Next steps: Continue your Cloudfleet journey

Congratulations! You have successfully navigated the initial steps of using Cloudfleet: creating an account, launching a CFKE cluster, configuring a Fleet, installing the CLI, and deploying and exposing a sample application. This provides a foundational understanding of Cloudfleet’s workflow and its power in simplifying Kubernetes management.

Explore more Cloudfleet features

Cloudfleet offers a rich set of features designed for robust, scalable, and flexible Kubernetes operations. Here are some areas for further exploration:

• Deeper dive into node auto-provisioning: Learn more about how CFKE intelligently manages worker nodes on supported cloud providers, including how to use scheduling constraints, taints, tolerations, and affinity/anti-affinity rules to influence node selection and workload placement. The documentation includes references for specific labels like cfke.io/accelerator-name or kubernetes.io/arch that can be used for fine-grained control.

• Persistent volumes: If your applications need storage that survives Pod restarts, follow the tutorial on using persistent volumes with Cloudfleet on Hetzner to install a CSI driver and mount cloud volumes in your cluster.

• Manage Cloudfleet from AI assistants: Connect Claude and other AI assistants to your Cloudfleet organization through the MCP server to inspect clusters, query workloads, and manage support tickets in natural language.

• Advanced networking: Explore Cloudfleet’s capabilities for global secure networking, which connects nodes across various clouds and regions as if they were on the same network. Learn about multi-region/multi-cloud load balancing in more detail and options for integrating with on-premises networks, potentially using BGP for on-premises load balancing.

• Hybrid and on-premises deployments: Discover how to integrate self-managed Linux servers from any cloud provider, on-premises data centers, or edge locations into a CFKE cluster. Self-managed nodes can be provisioned using Terraform or added manually, providing a powerful alternative to node auto-provisioning for infrastructure not yet natively supported. Tutorials may cover specific scenarios, such as deploying Kubernetes on Proxmox.

• Accessing cloud APIs securely: Learn how CFKE facilitates secure access from workloads running on CFKE to public cloud provider APIs (e.g., AWS S3, GCP BigQuery, Azure Blob Storage) using OIDC, eliminating the need for hard-coded credentials in applications.

• GPU-accelerated workloads: For AI/ML tasks, learn how to use GPUs with Cloudfleet, potentially leveraging specialized providers like Lambda Cloud or specific GPU instances on AWS/GCP.

• Integrating Cloudfleet with CI/CD: Authenticate GitHub Actions and GitLab CI pipelines to your CFKE clusters using OIDC workload identity federation, with no long-lived credentials in your repositories.

Further resources

To continue learning and make the most of Cloudfleet:

• Cloudfleet documentation: The official documentation is the comprehensive resource for all Cloudfleet features and configurations: https://cloudfleet.ai/docs

• Cloudfleet tutorials: A growing collection of practical guides and step-by-step instructions for various use cases, from general Kubernetes operations to specific integrations and AI/ML setups: https://cloudfleet.ai/tutorials/

• API reference: For users interested in programmatic interaction and automation, the API reference provides details on Cloudfleet API endpoints: https://cloudfleet.ai/docs/reference/api-reference/

• Support: If assistance or answers to specific questions are needed, feel free to reach out to Cloudfleet team by contacting the support

The Cloudfleet team is dedicated to making the Kubernetes experience seamless and powerful, from datacenters to the cloud and the edge. This guide is just the beginning of what can be achieved with the platform.