Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Testing

Unit and Env-Tests

Testing is split into layers:

  • unit tests for helper functions and cloud logic
  • envtest controller tests with Kubernetes API machinery
  • opt-in SDK integration tests against a real STACKIT project
  • opt-in e2e tests that create billable STACKIT resources

Default test command:

make test

This runs:

  • generated manifest checks through controller-gen
  • go fmt
  • go vet
  • envtest-backed Go tests, excluding /e2e

Real cloud tests are gated by environment variables so they do not run accidentally.

E2E-Tests

The e2e suite runs against an isolated kind management cluster. The generic target runs manager startup, metrics, webhook certificate, and webhook CA injection checks without STACKIT cloud resources:

make test-e2e

The real cloud paths create billable STACKIT servers, load balancers, public IPs, and security groups. Run them only in a dedicated STACKIT project with cleanup permissions and cost controls. The main workload scenarios have dedicated make targets:

ScenarioMake targetOpt-in flag
NodeRef/providerID and Ready Nodesmake test-e2e-workload-noderefSTACKIT_E2E_NODE_REF=true
Bastion cluster create/delete with provider-managed bastion and node SSH security group cleanupmake test-e2e-workload-bastionSTACKIT_E2E_CREATE_CLUSTER=true, STACKIT_E2E_BASTION=true
Worker scale with Ready Nodesmake test-e2e-workload-scaleSTACKIT_E2E_SCALE_WORKLOAD=true
Worker upgrade with Ready replacement Nodesmake test-e2e-workload-upgrade-workersSTACKIT_E2E_UPGRADE_WORKLOAD_WORKERS=true
Control-plane upgrade with a Ready replacement Nodemake test-e2e-workload-upgrade-control-planeSTACKIT_E2E_UPGRADE_WORKLOAD_CONTROL_PLANE=true
ClusterClass topology create/ready/deletemake test-e2e-workload-topologySTACKIT_E2E_TOPOLOGY_WORKLOAD=true

The suite also contains lower-level real cloud scenarios without dedicated make targets. Run them through go test -tags=e2e ./test/e2e or make test-e2e with the corresponding opt-in flag and a focused Ginkgo expression:

ScenarioOpt-in flagSuggested focus
Single StackitMachine VM create/delete and leak checkSTACKIT_E2E_CREATE_VMS=truecreate and delete a real STACKIT VM
1 control-plane / 1 worker infrastructure lifecycle without workload Node readinessSTACKIT_E2E_CREATE_CLUSTER=truecreate and delete a 1 control-plane / 1 worker workload Cluster
Infra-only MachineDeployment worker VM scale up/downSTACKIT_E2E_SCALE_WORKERS=truescale a worker MachineDeployment
Infra-only MachineDeployment worker VM replacement during version upgradeSTACKIT_E2E_UPGRADE_WORKERS=truereplace worker VMs during a MachineDeployment version upgrade

Common required environment:

  • STACKIT_PROJECT_ID
  • STACKIT_REGION
  • STACKIT_NETWORK_ID
  • STACKIT_IMAGE_ID
  • STACKIT_AVAILABILITY_ZONE
  • STACKIT_CREDENTIALS_SECRET_NAME
  • STACKIT_CREDENTIALS_SECRET_NAMESPACE

Useful common options:

  • KUBERNETES_VERSION, for create/scale/topology paths
  • STACKIT_E2E_UPGRADE_FROM and STACKIT_E2E_UPGRADE_TO, for upgrade paths
  • STACKIT_SSH_KEY_NAME, for node SSH keys when a scenario should attach one
  • STACKIT_BASTION_SSH_KEY_NAME, or STACKIT_SSH_KEY_NAME, when STACKIT_E2E_BASTION=true
  • STACKIT_BASTION_ALLOWED_CIDRS, defaulting to 0.0.0.0/0, for bastion SSH ingress
  • STACKIT_E2E_CNI, STACKIT_E2E_CNI_MANIFEST, and CNI-specific variables
  • STACKIT_E2E_TEST_ID, for cleanup traceability

Real Cloud Node Bootstrap

The real workload-cluster e2e path is intentionally allowed to use a generic Ubuntu cloud image during development. In that mode, the e2e fixture adds kubeadm preKubeadmCommands that install and configure containerd, kubelet, kubeadm, and kubectl at runtime before kubeadm joins the node.

Treat this runtime package installation as a development fallback. It proves the provider can pass CABPK-generated cloud-init data through STACKIT user data, but it is slower and less deterministic than a kubeadm-ready image. A production setup should use an image that already contains the expected container runtime and Kubernetes node packages for the selected Kubernetes minor.