How To Use Warp’s Agentic Programming To Manage Kubernetes Clusters
Warp is an agentic development environment, an AI-powered, terminal-first environment for DevOps engineers and site reliability engineers (SREs).
While tools like Cursor, Windsurf and Kiro can be used to deploy applications and perform DevOps tasks, they are code-first IDEs with an inbuilt terminal. But Warp takes a different approach by bringing agents to the terminal and embedding an editor within it, which makes it an ideal choice for performing administrative and DevOps tasks.
To prove its prowess for admin tasks, I will show you how to install Kubernetes 1.33 cluster on a set of virtual machines (VMs) without running a single command. We will leverage Warp’s agent to set up the cluster through a comprehensive and elaborate prompt. It not only installs Kubernetes, but also configures Calico for networking and a local path provisioner for storage. Since we are using the same workflow as vibe coding but for DevOps, I am calling this approach VibeOps.
Since AI agents are nondeterministic, your results may vary. But in my experiments, I found consistent outcomes in most of the scenarios.
Following up from last week’s post, this tutorial assumes that you already have Multipass installed on your system. For background and context, refer to my article published in The New Stack.
Let’s start by configuring Multipass VMs on a Mac with Apple Silicon. Once the environment is ready, we will launch Warp and run the prompt to set up the Kubernetes cluster.
Step 1: Launching Multipass VMs on macOS
We will start by launching the first node that acts as the control plane. This node has to meet the prerequisites of at least four CPU cores and 8GB of RAM to run the control plane. All the nodes will run Ubuntu 22.4, aka Jammy Jellyfish.
|
1 |
multipass launch -c 4 -m 8G -n node-1 jammy |
Let’s now launch the remaining two nodes of the cluster:
|
1 2 |
multipass launch -c 2 -n node-2 jammy multipass launch -c 2 -n node-3 jammy |
Verify VMs with the following command:
|
1 |
multipass list |
The next step is to load Multipass’s internal SSH key into your SSH agent so the agent can easily connect to its VMs without typing a password or manually specifying a key.
|
1 |
sudo ssh-add "/var/root/Library/Application Support/multipassd/ssh-keys/id_rsa" |
Verify that you can successfully SSH into the nodes before proceeding further:
|
1 |
ssh ubuntu@192.168.2.2 |
Step 2: Prompting Warp to Set up a Kubernetes Cluster
Now that the VMs are ready, we can kick off the installation task by sending a prompt to the Warp agent. I didn’t change the model and accepted the default settings during the installation.
I use the prompt below to set up the cluster.
You have access to the following ARM64 Ubuntu servers: 192.168.2.2, 192.168.2.3, 192.168.2.4. The username is ubuntu. Install a Kubernetes v1.33 cluster by using the correct package location. Install the control plane on 192.168.2.2 and make all nodes as worker nodes. Use kubeadm to install and configure the cluster. Use Calico (with standard manifests) for networking and Rancher local-path-provisoner for storage. On the control plane, configure ~/.kube/config file and verify the installation of the cluster. Finally, configure local kubectl to talk to the cluster. Write fast, compact and efficient scripts for this task and execute them.
This is a comprehensive prompt that includes everything you need to install and configure an active Kubernetes cluster. We give enough hints such as ARM64 architecture, Kubernetes version, kubeadm tool, the IP addresses, networking and storage choices and finally, asking the agent to configure the local kubectl command. These steps are essentially the same that an experienced Kubernetes engineer would follow to install the cluster.
Paste the prompt and hit Enter to start the guided installation process. Warp will prompt you to accept running commands that manipulate the cluster or the configuration. Change to a directory where you would like to store the intermediate scripts generated by the agent. In my case, it is the ~/Downloads folder.
Within a few seconds, Warp agent creates an action plan and asks for your permission to create and execute the scripts.
Once the scripts are created, it will start the execution.
Meanwhile, my Downloads folder is populated with the scripts generated by Warp’s agent.
Feel free to explore these scripts while the agent is busy executing them. Keep an eye on the Warp terminal to see if everything is working as expected.
After accepting and running the scripts, Warp was able to set up the cluster, configure networking and storage, and even copy the kube config file to the local Mac to configure kubectl CLI.
The agent verified the cluster by launching an NGINX pod and a storage volume before confirming the installation. It also removed the taint from the control plane node to make it schedulable. It finally confirmed the setup by showing the steps it followed, which is assuring. The whole process took about 8 minutes, which is much faster than manual installation.
I tried the same prompt with a set of bare metal machines and got the cluster working. I could even configure MetalLB with an extension to the prompt. I was also able to debug the cluster by simulating errors like deleting the kubelet and stopping the service on the nodes.
My next step is to try setting up a GPU cluster based on the NVIDIA GPU operator. Stay tuned for the findings and results of this experiment in a follow-up post soon!
