Skip to main content

Managed Kubernetes

WebberStop Managed Kubernetes (WSI CKS) runs on top of upstream Kubernetes 1.27+ with full Cluster API support, integrated monitoring, and managed control planes. You can drive every cluster lifecycle action from the REST API.

Create a cluster​

The minimum required parameters:

api POST "/kubernetes-clusters" -d "{
  \"name\": \"prod-k8s\",
  \"description\": \"Production cluster\",
  \"zoneId\": \"$ZONE_ID\",
  \"kubernetesVersionId\": \"$K8S_VERSION_ID\",
  \"serviceOfferingId\": \"$SVC_OFF_ID\",
  \"size\": 3,
  \"controlNodes\": 1,
  \"networkId\": \"$TIER_ID\",
  \"vpcId\": \"$VPC_ID\",
  \"sshKeyPair\": \"my-key\"
}"

Get available Kubernetes versions:

api GET "/kubernetes-versions" | jq '.versions[] | {id, semanticVersion, state}'

Cluster inside an existing VPC tier​

This is the recommended pattern. Create the VPC and tier first, then pass vpcId and networkId when creating the cluster. The cluster nodes land in your tier, sharing routing with everything else in the VPC.

A /24 tier CIDR (251 usable IPs) is enough for 40 workers plus 3 control nodes plus headroom.

Cluster in its own isolated network​

If you omit networkId, the platform creates a fresh isolated network with a default CIDR. This is simpler for standalone clusters but cannot route to other resources without extra setup. Use the VPC tier pattern unless you have a specific reason not to.

Control CIDR​

To set your own CIDR, pre-create the network with POST /networks using your chosen CIDR, then pass its networkId to POST /kubernetes-clusters. The platform respects the network you pass.

Get kubeconfig​

After the cluster reaches Running state:

api GET "/kubernetes-clusters/$CLUSTER_ID/config" | jq -r '.kubeconfig' > kubeconfig.yaml
export KUBECONFIG=$(pwd)/kubeconfig.yaml
kubectl get nodes

Scale a cluster​

Set a target node count manually:

api POST "/kubernetes-clusters/$CLUSTER_ID/scale" -d '{
  "size": 10
}'

This adds or removes worker nodes to reach the target. The control plane is managed separately and is not affected.

Maximum cluster size​

The default upper bound on worker count is 50 nodes per cluster. If you need more, raise a ticket with capacity planning details.

Autoscaling​

Native CKS Cluster Autoscaler integration is on our roadmap. Until it ships, two patterns work today:

Pattern A: Scheduled scaling​

If your load follows a daily or weekly pattern, run a cron job that calls the scale endpoint at known times:

# Scale up before business hours
0 8 * * 1-5 /usr/local/bin/scale-cluster.sh 20

# Scale down at night
0 22 * * * /usr/local/bin/scale-cluster.sh 5

Where scale-cluster.sh is:

#!/bin/bash
TARGET=$1
TOKEN=$(curl -s "$API/login" -d "..." | jq -r '.token')
curl -X POST "$API/kubernetes-clusters/$CLUSTER_ID/scale" \
  -H "Authorization: Bearer $TOKEN" \
  -d "{\"size\": $TARGET}"

Pattern B: Pending-pod-driven scaling​

Run a small controller in your cluster that watches for Pending pods and calls the scale endpoint when capacity is short. Pseudocode:

def watch_pending_pods():
    while True:
        pending = kubectl_get_pending_pods()
        if len(pending) > 0 and not capacity_can_fit(pending):
            current = get_current_node_count()
            target = min(current + 2, MAX_NODES)
            scale_cluster(target)
        time.sleep(60)

A reference implementation in Go is available on request. Raise a ticket if you want it.

Upgrade Kubernetes version​

api POST "/kubernetes-clusters/$CLUSTER_ID/upgrade" -d "{
  \"kubernetesVersionId\": \"$NEW_K8S_VERSION_ID\"
}"

The upgrade is rolling. Control nodes are upgraded first, then worker nodes one at a time. A 5-node cluster takes roughly 15 to 20 minutes. Workloads with proper PodDisruptionBudgets remain available throughout.

Delete a cluster​

api DELETE "/kubernetes-clusters/$CLUSTER_ID"

This removes all nodes, the control plane, and the cluster record. Persistent volumes attached to the cluster are not deleted automatically. Clean those up separately via DELETE /volumes/{id}.

Networking notes​

VPC tier sizing​

For a 40-worker production cluster:

  • Tier CIDR: /24 (251 usable IPs).
  • Workers: 40
  • Control nodes: 3
  • Headroom: ~200 IPs for additional pods, services, future scaling.

If you plan more than 200 nodes, use a /23 tier (507 usable IPs) or split into two clusters.

Connecting application VMs to the cluster​

Place application VMs in a separate tier of the same VPC. The VPC virtual router handles routing between tiers; control allowed traffic with ACLs on each tier.

Example: web tier 10.20.10.0/24, K8s tier 10.20.20.0/24, database tier 10.20.30.0/24. Web tier ACL allows ingress from 0.0.0.0/0 on 443. K8s tier ACL allows ingress from 10.20.10.0/24 on NodePort range. Database tier ACL allows ingress from 10.20.20.0/24 on 3306.

Exposing services​

Inside the cluster, use a Service of type NodePort and then create a port-forward rule on the VPC's public IP pointing to the NodePort. Alternatively, deploy an ingress controller (nginx, traefik) on a NodePort and front it with a single port-forward for 80 and 443.

Cloud-provider-managed LoadBalancer type services are on our roadmap.

Persistent storage​

Mount a volume via the WebberStop CSI driver:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: webberstop-block
provisioner: webberstop.csi.driver
parameters:
  diskOfferingId: "<your-disk-offering-id>"
  zoneId: "<your-zone-id>"
reclaimPolicy: Retain

Then claim it from a Pod:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data
spec:
  accessModes: ["ReadWriteOnce"]
  storageClassName: webberstop-block
  resources:
    requests:
      storage: 100Gi

Volumes are zone-local. For workloads that need to survive a node failure, ensure your Deployment has the right scheduling constraints and use a separate persistent volume per replica (for example via a StatefulSet).

Common patterns​

Production cluster checklist​

  • VPC and tier pre-created with your chosen CIDRs.
  • Tier ACL allowing ingress from your web tier only on NodePort range.
  • 3 control nodes for HA.
  • 5 worker nodes minimum (scale up before launch).
  • Kubernetes version one minor behind latest (more stable).
  • Backups of etcd and persistent volumes scheduled.
  • Monitoring and log shipping configured.
  • Alerts on node count, pod restarts, and certificate expiry.

Disaster recovery​

For DR, replicate persistent volumes to a second zone and keep a Terraform definition of the cluster topology in version control. Re-create the cluster in the DR zone via API, restore volumes, point DNS at the new ingress IP.

Reference​

Full endpoint reference: Swagger → Kubernetes section.