VMware Code Stream brings a great feature to manage Kubernetes clusters via tasks in Code Stream pipelines. If you’re familiar with Kubernetes and comfortable working with K8s YAML definition files. You should find that working with Kubernetes tasks and pipelines in VMware Code Stream will come fairly natural.
In this post we’ll run through a simple pipeline example using Kubernetes tasks that will deploy an Nginx pod, expose a service, and create an ingress resource. we’ll use a few different methods to read a YAML definition and deploy a resource. Lastly we’ll clean-up and delete the resources we created.
Before you start with creating a Kubernetes pipeline in Code Stream you first need a Kubernetes endpoint to a K8s cluster. The process of creating an endpoint is a straight forward one. You can find the steps I used in a previous post Creating A Kubernetes Endpoint In VMware Code Stream.
Creating a Kubernetes pipeline
Once you have that endpoint created you’re good to starting creating a pipeline. Head over to Pipelines in Code Stream and select Blank Canvas under the New Pipeline dropdown.
Give the pipeline a Name, Description, and select the same Project which you selected for the Kubernetes endpoint created above. (Pipelines can only use endpoints created in the same project).
Creating your first Kubernetes task
Within the pipeline, drag your first Kubernetes task onto the canvas of your first Stage.
This is where the interesting part starts. Click on Task0 on the Kubernetes task you just created. This will bring up the task info on the right pane window.
There’s a few key items we plan on working with here. The first is Kubernetes cluster. This will become the K8s endpoint we created above. Pull down -Select Endpoint- and select the endpoint you created.
Next is the Kubernetes Action we want to perform. Anyone that has used kubectl from the CLI will know of these actions. We plan on creating an Nginx container so we change the default action from Get to Create.
The last key piece of information we need is the Source Type. This is our actual YAML code that will do something. We have two options here. Source Control and Local definition. We’ll cover off both options but for this first task we will select Local definition. This will present us with a Local YAML definition section to put your code into. Unless you’re a masochist you probably don’t want to be writing your coding from scratch in this little box. Instead your best option here is just to paste your code from a working YAML definition you have into this window or have it read from a file. The code that I’m pasting in creates a simple Nginx deployment with two replicas. You can find this up on my GitHub codestream-k8s-demo repo.
Next let’s drag a new task onto our stage that will create a Service for this Deployment. We’ll use the same endpoint and action but this time under Source type let’s use Source Control.
When you select Source Control we are presented with two new fields. A Git endpoint to use and a File path. In my example I already have a Git endpoint created to a repository, so I select that from the dropdown. Inside my repository I have several YAML definition files. As they’re in the root of my repository I just type in the name of the YAML file I wish to run. This YAML definition can also be found up on my GitHub codestream-k8s-demo repo.
For the third and final task of this stage we will create an ingress resource. For the Source type we will revert back to Local definition.
I specifically wanted to highlight an Ingress resource due to an interesting issue I ran into recently. Kubernetes recommends you always use the latest apiVersion for a resource. For an Ingress resource in Kubernetes 1.20 that would be networking.k8s.io/v1 but unfortunately Code Stream won’t accept this apiVersion. So we have to use extensions/v1beta1. I detail the issue in a previous post here.
We should now have three tasks in our stage. We can go ahead and give the stage and tasks more descriptive names. Finally under the Actions pull down we can Enable the pipeline.
Executing the pipeline
At this point we are ready to run the pipeline. Back on the Actions pull down we select Run. Then head over to Executions and select our pipeline execution. Hopefully you get sometime similar to below with a Completed Status. You can also verify in Kubernetes that your resources created correctly.
Clicking on one of the tasks allows to you see additional information. Such as the input YAML code used and the Output result.
Now that we have a successful build of a Kubernetes deployment, service, and ingress resource. You can move onto performing things like user acceptance testing on these Kubernetes resources. That might involve creating a new stage and performing connectivity testing, load testings, etc.
Deleting what are created
We’re going to skip the UAT stage part and do something a little less exciting. We’re going to assume you’ve successfully deployed your resources and successfully completed your UAT and are now ready to move onto cleaning up and deleting the resources we created.
So first let’s create a new Stage below our current one by clicking on the New Stage box on the design canvas. This will create a new Stage for us to create Tasks in.
Next we clone the three tasks we created earlier by clicking the plus icon in the top right corner of each task. Then drag each task down onto the new stage we create in the same order.
We now click on each of these new cloned tasks and change the Action from Create to Delete. We can also update the task names from Deploy to Delete.
Once done you should have something similar to below.
As we did previously, We can click on the Actions pull down menu and select Run. Then head over to Execution and view our latest pipeline run.
Conclusion
And there we have it. We’ve covered the basics. We built something, we deleted something. Obviously you can now use your imagination on what additional things are possible. You could do some kind of user acceptance testing stage after the build. Or use some pre-existing Jenkins jobs that a Kubernetes task will then deploy. It really comes down to what your goals and objectives of the pipeline are.
When it comes to Kubernetes tasks I really like the simplicity of their use in Code Stream. If you understand how to work with K8s YAML files you’ll have no trouble adapting them to work within Code Stream. Then once you have the fundamentals down you can start to work with things like Input values and passing parameters on the pipeline.