GitHub user marcusaram added a comment to the discussion: 📢 CloudStack Kubernetes Flavors — A Reference Guide I Wish I Had When I Started
Sure, at a high level. Small correction, we switched to Cilium instead of Calico: **Talos Images**. The operator picks a Talos version and image type in the portal. We build the schematic through the Talos Image Factory and register the result once as a CloudStack template. **Provisioning**. Each cluster is driven by a small reconcile loop in the plugin. Every step is idempotent and its progress is stored, so a crash or restart just resumes. The steps, in order: 1. Create an isolated network for the cluster and get a public IP. 2. Add CloudStack load balancer rules on 6443 (Kubernetes API) and 50000 (Talos API), so there is no separate VIP to manage. 3. Set anti-affinity groups: strict for control planes. 4. Generate the cluster secrets and machine configs with the Talos Go library. Patches set the install disk and the cluster's own installer image, turn off the default CNI and kube-proxy, and turn on the external cloud provider. 5. Deploy the VMs from the template, with the machine config passed as userdata. 6. Bootstrap the first control plane through the Talos API (via the LB on 50000), wait until it's healthy, then fetch the kubeconfig. **Add-ons**. The plugin creates a dedicated CloudStack service account per cluster, scoped to the customer's project. Its keys feed the CloudStack CCM and the CloudStack CSI driver. We install Cilium (kube-proxy replacement plus ingress) and CSI with Helm and apply the CCM manifest, all from the plugin, with no GitOps tooling. **Day 2**. All of it runs through the Talos API from the portal: Scaling workers: new VMs come up with the worker config. Removed workers are reset and their VMs destroyed. Talos OS upgrades: node by node, workers first, using the factory installer image for the target version. The portal waits for each node to report the new version and be healthy, and offers rollback to the previous boot partition. Kubernetes upgrades: node by node, control planes first. The new version is applied to the live machine config without a reboot, the portal waits for each node to be Ready on it, then refreshes the cluster's built-in manifests. It rolls back automatically if a node stalls. Customers get the kubeconfig and all these actions in their panel, and state is kept encrypted on the portal side. GitHub link: https://github.com/apache/cloudstack/discussions/13638#discussioncomment-18823731 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
