LIVE: Hot Issues - Kemini Amanor interviews ECG Managing Director Julius Kpekpena || 03-05-2026

[0:00]Hello, this is a video about using GitHub Actions with a Kubernetes cluster. My name is Scott Lowe, I'm a staff technologist at VMware. And you can find me on Twitter and on my website. Before we dive into the actual meet of the topic, I did want to make sure and give credit to two individuals whose work I leveraged heavily in preparing for this video. One is Jesson and the other is Lucas. So thank you to both of them, you can see their GitHub repos there on the slide. So what is it that we're going to cover in this video? I'm going to start by talking a little bit about what GitHub Actions are just in case you're not familiar. Then we're going to talk about a specific type of workflow called a continuous deployment workflow. And this is going to be the focus of the hands-on portion of the video. Then we'll talk about how GitHub Actions communicate with a Kubernetes cluster, how that communication is secured, and then we'll dive into the demo portion of the video. So what exactly are GitHub Actions? GitHub Actions are a CI CD platform that's built directly into GitHub. It provides a way for you to automate, build, test, and deploy pipelines right there in your GitHub repo. GitHub Actions are driven by something called an event, which is anything that happens inside of your GitHub repo. So pushing code, creating a pull request, things like that. These events then trigger workflows. Workflows are made up of jobs, and jobs are made up of steps, and each step runs a specific action. Now the important thing to keep in mind, an action could be a simple shell script, or it could be a container image that executes a more complex set of commands. So it could be as simple or as complex as it needs to be. All of this is defined using a YAML syntax, and then it's stored in your GitHub repo. So specifically, what we're going to be talking about today is something called a continuous deployment workflow. And the way that this works is you'll typically start by creating a pull request against a development branch, which is going to trigger a set of tests to make sure that the code that you're trying to add to the repo works properly. Once those tests have all passed, you'll merge that development branch into the main branch, and that merge into the main branch is going to trigger a second workflow. And this second workflow is going to build a new container image, it's going to store that container image in a container registry. Then it's going to use a tool called Kustomize to update the Kubernetes manifests that are also stored in the repo to point to that new image. Then it's going to use Cube CTL to apply those updated manifests to the Kubernetes cluster. And finally, it's going to update the status of the GitHub deployment so that you can go into GitHub and see whether that deployment was successful or not. So how does GitHub Actions actually talk to a Kubernetes cluster? What's the mechanism behind that? Well, inside the GitHub repo, you'll store your Kubernetes manifests, and you'll also store the GitHub workflow file. When the workflow gets triggered, it's going to grab those manifests and it's going to talk to the Kubernetes API using Cube CTL. So it's effectively leveraging the Cube CTL apply command to push those manifests to the cluster. Now, the important part of this is how is that communication secured. And the way that that works is using a service account that exists in the Kubernetes cluster. So you create a service account and then you create a role and a role binding that binds that role to the service account. And then in GitHub, you'll store the Cube config file that points to the Kubernetes API along with a token for that service account as a GitHub secret. So that GitHub secret gets injected into the workflow and used by Cube CTL to authenticate to the Kubernetes API. All right, let's go ahead and dive into the demo portion of the video. So this is the GitHub repo that we're going to be using for the purposes of the demo. Right now you can see that it has three branches, a main branch, a development branch, and a feature branch. The main branch has a single workflow file, this push to main workflow, that's what's going to handle the continuous deployment. The development branch has two workflow files, that push to main workflow and then a tests workflow that runs a set of tests. And the feature branch has those same two workflow files plus an additional workflow file that's going to run a different set of tests. All of these branches also have a Cube directory and this Cube directory is where we're storing our Kubernetes manifests. So if we look in here, we'll see a deployment.yaml and a service.yaml, these are the standard Kubernetes manifests. And then we also have a Kustomization.yaml file that Cube CTL and Kustomize use to merge these together. You'll also notice that we have a GitHub actions workflows directory, and this is where all the workflows are stored. So if we open this up, you'll see our test.yaml, the test feature.yaml and the push to main.yaml. Now, the first thing that we need to do is we need to set up the service account in the Kubernetes cluster so that GitHub Actions can communicate with the cluster. To do that, I'm going to start by switching over to the terminal and I'm going to copy and paste a series of commands here. First, I'm going to create a namespace called GitHub Actions. Then I'm going to create the service account inside that namespace called GitHub Actions. Then I'm going to create the role that has the permissions that we need, and you can see this role allows us to get, list, watch, create, update, patch, and delete deployments, services, and pods. This is a pretty broad set of permissions. If you were doing this in a production environment, you would want to be a little bit more judicious about what permissions you're granting here. But for the purposes of this demo, this works perfectly fine. Then I'm going to create the role binding that binds that role to the service account. And then finally, I'm going to extract the secret for the service account. And then I'm going to copy the contents of that secret, and then I'm going to use that to create a new GitHub secret. So I'm going to copy that value, I'm going to switch over to the browser and go into the settings for the repo. I'm going to click on secrets, then I'm going to click on new repository secret, and I'm going to give this a name of Cube config. And then I'm going to paste in the value of that secret. So now we have that secret, now we're going to create a second secret. This second secret is going to hold our Docker hub username, which we're going to use to push the container image to Docker hub. So I'll go back to the new repository secret, I'll call this Docker username, and I'll type in my Docker hub username. And then I'm going to create a third secret that's going to hold my Docker hub token. So I'll call this Docker token, and I'll paste that in. Okay, so now that we have all the secrets in place, we've got the service account defined in the cluster. Now we're ready to actually make a code change and watch this workflow unfold. So I'm going to switch over to the code, I'm currently on the feature branch, and I'm going to open up app.py. I'm going to modify this just slightly to say feature branch version. I'm going to save this file and then I'm going to stage it. And then I'm going to commit this change with a useful commit message, change to feature branch version. And then I'm going to push this to the feature branch. Now, because we've pushed a change to a feature branch, this is going to trigger a workflow. So I'm going to switch over to the browser and look at the actions tab, and we'll see that a test workflow has started to run. This test workflow is going to run a set of tests to make sure that the code that we're adding to the repo is functional and correct. You can see that it's building the image, it's running the test, it's pushing the image. And that has completed and it succeeded. So now that we've confirmed that the code works, we're going to create a pull request. So I'll switch over to the pull request tab, and I'm going to click on new pull request. And I'm going to create a pull request to merge the feature branch into the development branch. So I'll leave the title and comments as is, I'll click create pull request. And because we've created a pull request to merge into the development branch, this is also going to trigger a test workflow. So if we go back to the actions tab, we'll see there's a new test workflow that has started to run. This test workflow runs slightly different tests than the test on the feature branch, but the net result is the same. If these tests all pass, then we know that our code is working correctly. You can see it's building the image, it's running the tests, it's pushing the image. It has now completed and it has succeeded. So now that we've confirmed the code works from both the feature branch and from the development branch perspective, we're ready to merge this. So I'll go back to the pull requests tab, I'll click on the pull request that we just created, and I'll click merge pull request. And I'll click confirm merge. So now that we've merged the feature branch into the development branch, we're ready to merge the development branch into the main branch. And this is what's going to trigger our continuous deployment workflow. So I'll go back to pull requests, new pull request, and I'll switch the base from development to main. And I'll switch the compare from feature to development. And I'll click create pull request. Now, we will have another test workflow run here, but we've already seen that, so we don't need to actually watch that happen. I'll go ahead and click merge pull request, confirm merge. And now this merge into the main branch is going to trigger our continuous deployment workflow. So if we go back to the actions tab, you'll see there's a push to main workflow that has started to run. And this is the workflow that's actually going to deploy our code to the Kubernetes cluster. So we'll click on that and we can watch the various steps here. So it's checking out the repo, it's setting up Docker, it's building the image. Now it's pushing the image to Docker Hub, which has completed. Now it's setting up Kustomize, it's generating the manifest with Kustomize. Then it's going to deploy to the Kubernetes cluster. And then finally, it's going to update the GitHub deployment status. And it looks like all of these steps have completed successfully. So now if we go into our Kubernetes cluster, we should be able to see the results of this deployment. So I'm going to go back to the terminal, and I'm going to use Cube CTL to get the deployments in the GitHub Actions namespace. And we see that we have a deployment there called Python app. I'm then going to get the services in that same namespace, and we'll see we have a service there called Python app. And then I'm going to get the pods in that namespace, and we'll see a single pod running there also called Python app. And then finally, I'm going to get the logs from that pod. And when we get the logs from that pod, we'll see that it says hello world feature branch version. This confirms that the change that we made on the feature branch that propagated up through the development branch and into the main branch has now been successfully deployed to the Kubernetes cluster. So our continuous deployment workflow worked exactly as expected. To recap what we covered in this video, we talked about what GitHub Actions are, we talked about a specific type of workflow, a continuous deployment workflow. We talked about how GitHub Actions communicate with a Kubernetes cluster and how that communication is secured. And then we watched a demo of a continuous deployment workflow in action. I hope this has been useful to you and I encourage you to check out my website and find me on Twitter.