Using ChatGPT to learn Kubernetes and OpenShift

As I am writing this, the hype about ChatGPT seems to reach new heights every day. Much of what I read starts out with the question “Will the machines take over our jobs?” and ends with something like “It’s not quite there – yet!”. I won’t even try to predict where this is all going and will also refrain from pointing out that this system has obvious flaws. Instead, I would like to share what I have seen it do with respect to creating configurations for Kubernetes and, in my case, OpenShift. And I found it to be quite useful in quickly creating solid example deployments, which can serve at least as a starting point for further, more detailed work. 

I started out with what is probably one of the most common examples of learning how to deploy a workload on a Kubernetes cluster: deploying nginx, an open web server. 

This ask lets it generate a set of YAML definitions, specifically, a DeploymentConfig resource, a Service resource and a Route resource. All pretty straight forward so far. 

A nice touch is that it also adds a brief explanation about what it did, and that makes it especially useful if you are new to Kubernetes and want to educate yourself.

One thing that you should keep in mind here is that the hostname "example.com" is only a placeholder for what a usable hostname is in the case of your environment, so you'll have to adjust that if you want to deploy this YAML in your cluster. One option to simply remove the hostname parameter from the YAML, which will cause a working URL to be generated.  

An additional consideration is that the YAML as generated will probably not get the pod deployed, because the standard nginx container requires running with privileges and by default will not work, since it will be associated with the restricted SCC. You will have to associate the default service account with the privileged SCC. And guess what? You can ask ChatGPT to tell you how and it will give you a fairly comprehensive explanation, together with the command you execute against your cluster to do it: 

Note also that it knows the difference between Kubernetes and OpenShift, because it generates resource definitions that are only used in OpenShift, for example, a Route. If you ask it to do the same, but for Kubernetes, it will generate different resources, for example, a Service resource of type LoadBalancer.

My next goal was to start adding additional features to this initial deployment, beginning with making it highly available. Note that ChatGPT keeps the state of the conversation, in other words, it remember that I had asked about deploying nginx before.

“can you update these YAML definitions to make the deployment highly available across three nodes in the cluster”

And it promptly makes updates to the YAML, and explains what they are afterwards:

 

So it actually interprets what it means to say “highly available” and maps it to additional configurations like a liveliness probe or the session affinity. Of course, we can have a lengthy discussion about whether this is truly living up to the requirement to be “highly available”, but at the very least, it points out some interesting settings that play a role in it, and which you can then adjust further.

However, there is an error in this: when setting the externalTrafficPolicy to 'local', it should also change the service type to LoadBalancer. I assume this is a bug? I also stumbled over the node selector pointing to a label that my cluster doesn't have. I'm not sure if this is yet another bug, or if my cluster is not properly configured. I think this comes down to the fact that you cannot assume to use these YAML files unchanged in your environment, you may have to make adjustments. And that can be another learning experience in itself!

What’s next? How about some specific settings for memory and CPU.

“can you update those definitions with appropriate definitions for cpu and memory to allow for increased load”

If nothing else, this gives me placeholders for those values in the configuration, and those can then be adjusted as well.

And as before, I get a brief introduction into what was added and why. This makes it turn into a sort of interactive tutorial, where I can ask questions as I go and see the various parameters being added and explained.

“can we now update all this to be exposed with https, and use the OpenShift cluster's default cert for the endpoint?”

Yes, it can, and adds yet another nice brief explanation:

So we deployed a workload, made it highly available, gave it some additional memory and CPU and exposed it via HTTPS. Now I wondered if I can add a storage example, so I asked it to forget about nginx (which is basically stateless), deploy a MySQL instance instead and give it storage.

“can you generate the same set of YAMLs, with the same characteristics, but for a stateful deployment of a MySQL instance, including the use of dynamically allocated persistent storage?”

Since it is a machine answering my requests, it has unlimited patience and thus went to work right away and created a new set of YAML definitions, this time adding a PersistentVolumeClaim, and as a nice bonus, it knew where to mount it:

One thing I noticed right away was that the replica number went from 3 to 1. It also removed the liveliness and readiness probes that were in the previous configurations. So it didn’t know how to deploy MySQL in a highly available fashion? Let’s put that to a test.

“please change the definition so that MySQL is deployed in a highly available configuration with a single primary and two replicas”

 

So, pretty much all it did was to change the replica number from 1 to 3. Apparently, it didn’t realize that additional configuration is needed to create a proper setup for MySQL the way I wanted it. Maybe I needed to give more specific instructions? The fact that it added more capacity to the storage volume was a nice touch, though. I’ll leave any further poking at this for some other time.

But before I let it all go, I wanted to try one more thing, namely to not have it hardcode the MySQL password into the YAML, and pull it from a secret instead (which, in my opinion, it should have done right away). And that part worked like a charm.

What would be really cool is if it could remember some standard things that I always like to see in my deployments, for example, high availability, or no hardcoded secrets, and if consequently I won’t have to define these things explicitly anymore. That would constitute a ‘learning’ model, wouldn’t it? Unfortunately, it doesn’t seem to do that, when I started a new chat and asked for a deployment of MySQL, it started out with the same basic configuration as before.

In closing, I found ChatGPT to be a great tool for learning, and learn in a very interactive way that might work better than finding tutorials and examples on the web and follow those. You can navigate the world of Kubernetes as you see fit. At least for that purpose, this tool is ideal. However, it isn't always 100% correct (which it freely admits, doesn't it?), and I also found that, at least in my case, it didn't deliver the same outcome when I asked for the same thing, but with different words. Which may be another area to explore further in itself.

Image by Alexandra_Koch from Pixabay.