Gardener Managed Kubernetes

Yes. Leafcloud supports Infrastructure as Code (IaC) for both managed and self-managed Kubernetes deployments. Your approach depends on whether you want Gardener-managed clusters or full DIY control.

Managed Kubernetes with Terraform:

For Gardener-managed clusters, use the official Gardener Terraform provider. Define cluster specifications including:

• Kubernetes version and worker pools
• Machine types and networking configuration
• Extensions as Terraform resources

The provider handles the entire cluster lifecycle—terraform apply creates the cluster, terraform destroy removes it. State management works identically to other Terraform providers. Example configurations are available in Leafcloud documentation showing multi-worker-pool setups, GPU node pools, and hibernation schedules.

Self-Managed Kubernetes with Terraform:

For self-managed clusters, use the OpenStack Terraform provider to provision the underlying infrastructure:

• Create VMs for control plane and worker nodes
• Configure networking with Neutron
• Provision Cinder volumes for etcd storage
• Set up security groups

Then bootstrap Kubernetes using your preferred method (Rancher, Kubeadm, RKE2) via cloud-init scripts or Terraform provisioners. This approach gives you complete control over every layer of the stack.

Rancher with Terraform:

Rancher provides its own Terraform provider (rancher2) that can provision RKE or RKE2 clusters on Leafcloud infrastructure. First use OpenStack provider to create VMs, then use Rancher provider to install and configure Kubernetes. This combines infrastructure automation with Rancher's cluster management features.

Other IaC Tools:

Beyond Terraform, Leafcloud supports:

• Ansible: OpenStack modules + kubespray
• Pulumi: OpenStack provider
• Direct OpenStack APIs: Custom tooling
• Gardener CLI: gardenctl with YAML definitions—perfect for GitOps workflows with ArgoCD or Flux

Best Practice:

Start with Gardener-managed Kubernetes via Terraform if you want operational simplicity. Switch to self-managed when you need specific distributions, custom control plane configurations, or want to eliminate the €84.50/month cluster management fee. Both approaches integrate seamlessly with CI/CD pipelines and GitOps practices.

Need help? Our Amsterdam team provides IaC examples and migration guidance. Email hello@leaf.cloud or schedule a call.

Gardener has its own command-line tool called gardenctl. You can use gardenctl to connect to your cluster and manage your garden.

• Install Gardenctl: Follow the installation instructions provided in the Leafcloud documentation.
• Connect to Your Cluster: Use gardenctl commands to access and manage your Kubernetes cluster efficiently. For detailed steps, refer to the Leafcloud Gardenctl Documentation.

You can manage and create Kubernetes clusters (shoots) using Gardener in two main ways:

• Declaratively with YAML:
  • Define cluster configurations in YAML files.
  • Use gardenctl to apply these configurations, creating or updating clusters as specified.
• Via the Gardener UI:
  • Access the Gardener dashboard at dashboard.gardener.leaf.cloud.
  • Use the intuitive interface to manage and create clusters. Both methods offer flexible and efficient cluster management. For detailed instructions, visit the Leafcloud Gardenctl Documentation.

The Kubernetes setup consists of several parts:

• Control Plane: Managed by Leafcloud, it oversees the Kubernetes cluster.
• Worker Nodes: Created in the customer's OpenStack project to run applications and workloads.
• Networking: Configured in the customer's OpenStack project to connect worker nodes and resources.
• Security Groups: Enhance security and control network access in the customer's OpenStack project.

The upgrade process includes:

• Node Replacement: Nodes are replaced one by one when changing the Kubernetes version.
• Workload Migration: Workloads from old nodes are automatically migrated to the new nodes.
• Seamless Transition: Ensures minimal downtime, maintaining consistency and smooth operation.

When you create a Kubernetes Service with type: LoadBalancer, Leafcloud automatically provisions an OpenStack Octavia load balancer and assigns it an external IP address. This integration works identically for both Gardener-managed and self-managed Kubernetes clusters.

Automatic Provisioning:

The Kubernetes cloud-controller-manager detects the LoadBalancer service and calls the OpenStack Octavia API to create a load balancer resource. Within 30-60 seconds, Octavia provisions the LB infrastructure, allocates a floating IP from your project's IP pool, and updates the Kubernetes service with the EXTERNAL-IP field.

Your application becomes accessible from the internet immediately.

Load Balancer Configuration:

Octavia creates a Layer 4 TCP/UDP load balancer by default. The LB monitors backend health via TCP connection checks to the NodePort on each worker node.

Traffic flows: External IP → Octavia LB → NodePort on worker nodes → kube-proxy → application pods.

This architecture provides high availability—if a worker node fails, Octavia automatically routes traffic to healthy nodes.

Advanced Options:

Use service annotations to customize LB behavior:

• Set loadbalancer.openstack.org/floating-network-id to specify which external network to use for the floating IP
• Configure loadbalancer.openstack.org/timeout-client-data for connection timeouts (useful for WebSocket or long-polling applications)
• Enable proxy protocol with loadbalancer.openstack.org/proxy-protocol: "true" to preserve client IP addresses

SSL/TLS Termination:

For HTTPS, two approaches work:

1. Use an Ingress controller (NGINX, Traefik) behind a LoadBalancer service—the Ingress handles TLS termination and routes to multiple backend services
2. Configure Octavia LB with TLS certificates directly via OpenStack annotations

The first approach is more common for Kubernetes workloads.

Cost and Cleanup:

Each LoadBalancer service creates one Octavia LB instance in your OpenStack project. Pricing is based on the load balancer resource (check pricing page for current rates).

When you delete the Kubernetes service with kubectl delete, the cloud-controller-manager automatically deletes the corresponding Octavia LB and releases the floating IP. No manual cleanup required.

Self-Managed Clusters:

For self-managed Kubernetes, ensure your cluster has the OpenStack cloud-controller-manager installed and configured with proper credentials (clouds.yaml).

Without this component, LoadBalancer services will remain in <pending> state indefinitely. Rancher and most OpenStack-aware Kubernetes installers configure this automatically, but DIY setups with Kubeadm require manual cloud-controller-manager deployment.

Monitoring:

View load balancer status in the OpenStack Horizon dashboard under Network → Load Balancers. Check health monitor status, active connections, and traffic statistics.

Kubernetes events (kubectl describe service <name>) show provisioning progress and any errors during LB creation.

When you create a PersistentVolumeClaim (PVC) in Kubernetes, the OpenStack Cinder CSI driver automatically provisions a block storage volume in your OpenStack project. This dynamic provisioning works for both Gardener-managed and self-managed Kubernetes clusters on Leafcloud infrastructure.

Automatic Volume Provisioning:

The Kubernetes CSI controller watches for new PVC resources. When detected, it calls the OpenStack Cinder API to create a volume with the requested size and storage class.

Cinder provisions the volume from available storage pools (typically network-attached SSD or HDD storage). The CSI driver then creates a PersistentVolume (PV) resource in Kubernetes that references the Cinder volume ID.

The PV and PVC bind automatically, and the volume becomes available for pod mounting.

Storage Classes:

Leafcloud provides multiple StorageClass options:

• Default class: Standard SSD storage with reasonable IOPS for general workloads
• High-performance classes: Faster NVMe-backed volumes for databases and I/O-intensive applications
• Parameters: Control volume type, replication factor, and encryption settings

Check available storage classes with kubectl get storageclass.

Volume Attachment:

When a pod uses a PVC, the Cinder CSI node plugin attaches the volume to the worker node running the pod. For Cinder volumes, this creates an iSCSI or RBD connection from the worker node to the storage backend.

The volume appears as a block device on the node, which Kubernetes then formats (first use only) and mounts to the pod's filesystem at the specified mountPath.

Multiple pods can share a PVC if the StorageClass supports ReadWriteMany access mode, though most Cinder volumes use ReadWriteOnce (single writer).

Volume Features:

Snapshots: Cinder volumes support snapshots via VolumeSnapshot resources. Create point-in-time backups of data without stopping applications. Snapshots can restore to new PVCs for testing, disaster recovery, or cloning environments.

Volume expansion: Works dynamically—edit the PVC to request a larger size, and the CSI driver expands the underlying Cinder volume without pod restarts (filesystem must support online resize, like ext4 or XFS).

Data Persistence:

Unlike ephemeral pod storage, PVC data persists after pod deletion. The PVC and underlying Cinder volume remain intact until you explicitly delete the PVC resource.

Set reclaimPolicy: Retain on StorageClass to preserve Cinder volumes even after PVC deletion (useful for forensic analysis or data recovery). Default policy is Delete, which removes the Cinder volume when the PVC is deleted.

Performance Considerations:

Network-attached Cinder volumes have higher latency than local NVMe storage (typically 1-5ms vs <1ms).

For latency-sensitive workloads like databases:

• Use storage classes backed by fast SSD storage
• Consider local volumes if data persistence isn't critical
• Check volume IOPS limits in your storage class—some classes enforce QoS limits to ensure fair resource sharing across tenants

Self-Managed Clusters:

For self-managed Kubernetes, ensure the Cinder CSI driver is installed and configured with OpenStack credentials.

Rancher and OpenStack-aware Kubernetes distributions include this by default. DIY Kubeadm clusters require manual CSI driver deployment using Helm charts or manifests from the cloud-provider-openstack project.

Configure the CSI driver with your clouds.yaml credentials file.

Monitoring and Troubleshooting:

View Cinder volumes in the OpenStack Horizon dashboard under Volumes → Volumes. Check volume status, attachment state, and size.

For PVC issues, inspect events with kubectl describe pvc <name>.

Common problems include:

• Quota exhaustion (too many volumes)
• Insufficient storage capacity in the Cinder pool
• Misconfigured CSI driver credentials

Cost Management:

Cinder volumes are billed based on provisioned size (GB/month), not actual usage. A 100GB PVC costs the same whether empty or full.

Cost optimization tips:

• Delete unused PVCs to reduce costs
• Use volume snapshots sparingly—snapshots also incur storage costs
• Check the Leafcloud pricing page for current Cinder volume rates

Our Gardener Managed Kubernetes service is available here. For self-managed Kubernetes on OpenStack, see this guide.

You can find documentation related to Leafcloud Kubernetes here.

Leafcloud supports both Calico and Cilium network types.

Leafcloud offers Kubernetes 1.32 (stable) and Kubernetes 1.33 (preview).

Version 1.32 (Stable): Current production-ready release. Fully tested and validated. Recommended for all production workloads. Includes latest stable features, security patches, and bug fixes.

Version 1.33 (Preview): Early access to upcoming release. Test new features before general availability. Suitable for development/staging environments. Helps prepare for future upgrades.

Update policy: Leafcloud stays within 1-2 versions of the latest upstream Kubernetes release. When a new version reaches stable status, we add it within 4-6 weeks. Older versions remain available for 6 months after deprecation to allow migration time.

Standard Kubernetes API: All Gardener-managed clusters use the standard Kubernetes API, ensuring compatibility with standard tooling (kubectl, Helm, Terraform, ArgoCD, etc.). You can migrate workloads to/from any standard Kubernetes cluster without code changes.

Zero-downtime updates: Upgrade clusters via Gardener dashboard with rolling updates. Worker nodes update sequentially, maintaining workload availability. Schedule maintenance windows or enable auto-update for hands-free management.