Skip to main content

Managed Kubernetes Service

Okustera Managed Kubernetes delivers upstream, CNCF-certified Kubernetes clusters orchestrated declaratively through OpenStack Magnum and Cluster API (CAPI).

Every tenant cluster runs on isolated Nova virtual machines, powered by high-performance Calico CNI, native Cinder CSI persistent volumes, and enterprise-grade operational lifecycle controls.

Architecture: Immutable Rolling Infrastructure​

Unlike legacy platforms where node operating systems and Kubernetes binaries are mutated in place (apt upgrade kubelet), Okustera treats every Kubernetes node as an immutable virtual machine:

  • Zero Host Drift: Nodes are never patched in place.
  • Deterministic Rollouts: Upgrades occur by launching new Nova VMs from tested golden images, joining them to the cluster, safely migrating workloads, and terminating the decommissioned nodes.
  • Declarative Orchestration: Cluster topology is reconciled continuously by Cluster API Provider OpenStack (CAPO).

Zero-Downtime Kubernetes Version Upgrades​

Okustera supports three complementary zero-downtime upgrade strategies designed to ensure customer services, API transactions, and database clusters suffer zero dropped packets and zero downtime:

Strategy 1: Node Rolling Surge (maxSurge: 1, maxUnavailable: 0)​

The default in-cluster upgrade mechanism operates with strict surge semantics:

  1. Surge Before Eviction: CAPI boots the new "Green" Nova VM before touching any existing "Blue" worker nodes.
  2. Readiness Verification: The node must boot, register with the Kubernetes API, initialize Calico CNI networking, and report Ready condition.
  3. Cordon & Evict: CAPI marks the old node unschedulable (kubectl cordon) and evicts pods in compliance with their PodDisruptionBudgets (PDBs).
  4. Volume Detach/Attach: Cinder CSI automatically unmounts block volumes from the decommissioned VM and attaches them to the new node.
  5. Node Termination: Only after the node is drained is the old Nova VM terminated.

Protecting Workloads with PodDisruptionBudgets:​

Ensure all critical deployments maintain at least one available replica during node drains:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: api-pdb
  namespace: default
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: api-service

Strategy 2: Cluster-Level Blue/Green Deployment with Canary Traffic Shifting​

For major Kubernetes releases where APIs or CRD schemas deprecate, Okustera enables Cluster-Level Blue/Green Deployments:

  1. Spin up Green Cluster: Provision a second cluster using Terraform or Magnum.
  2. Synchronize Addons & Workloads: Deploy application manifests and attach database replicas or S3 Barman backups.
  3. Canary Shift at APISIX Ingress: Route a progressive percentage ($5% \to 25% \to 50% \to 100%$) of traffic to the Green cluster using the APISIX traffic-split plugin.
  4. Instant 1-Second Rollback: If elevated 5xx errors or latencies occur on Green, shift traffic back to Blue instantly.
  5. Decommission Blue: Once Green is operating cleanly, tear down Cluster Blue.

Strategy 3: Application Canary Releases via Apache APISIX​

To deploy canary versions of your microservices within any cluster:

apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: production-canary
  namespace: default
spec:
  http:
    - name: canary-rule
      match:
        paths:
          - /api/v1/*
      backends:
        - serviceName: backend-v1
          servicePort: 80
          weight: 90
        - serviceName: backend-v2
          servicePort: 80
          weight: 10

Outdated Helm Packages & Deprecated API Management​

When upgrading Kubernetes versions, outdated Helm packages, obsolete CRDs, and removed APIs represent a primary operational hazard. Okustera implements a rigorous lifecycle framework to detect, map, and remediate outdated packages.

The Three Helm Failure Modes:​

  1. Removed Kubernetes APIs: A Helm chart renders templates with an API version removed in the target Kubernetes release (e.g. policy/v1beta1 $\to$ policy/v1 or networking.k8s.io/v1beta1 $\to$ networking.k8s.io/v1). The API server rejects the resource on deployment.
  2. Deadlocked Release Secrets: Helm persists rendered manifests in release Secrets (sh.helm.release.v1.<release>.v<n>). If a cluster is upgraded before updating the Helm release, future helm upgrade or helm rollback commands fail because Helm cannot decode or dry-run the old release manifest against the new API server.
  3. CRD Immutability in Helm: Helm does not upgrade CRDs in a chart's crds/ directory on helm upgrade. Applying the chart alone will result in schema validation failures if the controller requires newer CRD schemas.

Pre-Upgrade Lifecycle Workflow:​

1. Scan for Deprecated APIs:​

Run deprecation audits against the live cluster before scheduling upgrades:

# Scan in-cluster live resources
kubent

# Scan Helm release storage backend Secrets
pluto detect-helm

2. Apply CRDs Explicitly:​

Always apply CRDs prior to upgrading Helm operator charts:

kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.15.0/cert-manager.yaml

3. Recovering Deadlocked Releases with helm-mapkubeapis:​

If a cluster was already upgraded before updating Helm, use helm-mapkubeapis to patch the release Secret in-place:

# 1. Install plugin
helm plugin install https://github.com/helm/helm-mapkubeapis

# 2. Dry-run inspection
helm mapkubeapis --namespace default my-release --dry-run

# 3. Apply in-place metadata mapping
helm mapkubeapis --namespace default my-release

# 4. Perform standard upgrade
helm upgrade my-release my-repo/my-chart

Provisioning a Cluster via Terraform​

You can manage your clusters declaratively with the Okustera Terraform provider:

# Discover certified cluster template
data "okustera_kubernetes_cluster_config" "default" {
  cluster_name = "k8s-production-cluster"
}

# Provision upstream Kubernetes cluster
resource "okustera_kubernetes_cluster" "tenant_cluster" {
  name                = "production-k8s-cluster"
  cluster_template_id = "k8s-v1.30-calico-standard"
  master_count        = 1
  node_count          = 3
  floating_ip_enabled = true
  keypair             = "production-key"
}

Learn more in the Terraform Provider Documentation.

Tenant Cluster Operations in Cloud Portal​

The Okustera Cloud Portal (/kubernetes) simplifies cluster access and scaling:

1. Downloading Your Kubeconfig​

To manage your cluster with kubectl:

  1. Navigate to Kubernetes in the left sidebar.
  2. Select your cluster and click Download Kubeconfig.
  3. Save the file locally and configure your environment: 
    export KUBECONFIG=~/.kube/my-cluster.kubeconfig
    kubectl get nodes

2. Dynamic Worker Node Scaling​

To adapt to increased workload demand:

  1. In the cluster details view, click Scale Cluster.
  2. Adjust the Worker Node Count (e.g., from 3 to 5 nodes).
  3. Click Apply Scale. The Cluster API controller boots new Nova worker VMs, installs the Kubelet agent, joins the Calico mesh, and transitions nodes to Ready without interrupting existing pods.

REST API Reference​

  • GET /api/v1/kubernetes/clusters — List all Kubernetes clusters in the tenant project.
  • POST /api/v1/kubernetes/clusters — Provision a new Kubernetes cluster from template.
  • GET /api/v1/kubernetes/clusters/{id} — Inspect cluster health, API endpoint, and node count.
  • POST /api/v1/kubernetes/clusters/{id}/scale — Scale worker node pool count dynamically.
  • GET /api/v1/kubernetes/clusters/{id}/kubeconfig — Download cluster admin kubeconfig.
  • DELETE /api/v1/kubernetes/clusters/{id} — Safely drain and terminate cluster resources.
  • GET /api/v1/kubernetes/cluster-templates — List certified upstream Kubernetes templates.