My First Week With Kubernetes
Tags: kubernetes, devops
Published: 2023-02-27 22:18:46

---
title: My First Week With Kubernetes
published: true
date: 2023-02-27 19:06:27 UTC
tags: Kubernetes,DevOps
canonical_url: https://eng.ctrlstack.com/my-first-week-with-kubernetes/
---

 ![My First Week With Kubernetes](https://images.unsplash.com/photo-1633613286880-dae9f126b728?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=MnwxMTc3M3wwfDF8c2VhcmNofDN8fGZydXN0cmF0aW9ufGVufDB8fHx8MTY3NzUyNDUzNg&ixlib=rb-4.0.3&q=80&w=2000)

Though my first week with Kubernetes was years ago, I still remember that initial first week of pain and confusion.  I put this post together in memory of that week :-)

Initially, Kubernetes can feel highly complicated to use.  Kubernetes can be intimidating and encourage people to refrain from using it directly and delegating tasks to the more experienced Kubernetes members of the team.

I'm here today to tell you that we all hit speedbumps when first using Kubernetes.  I am sharing my experience to help new people realize they're not alone in their frustration.

I'll go into detail on each of these, but to summarize, the five speedbumps I hit were:

- Installing `kubectl`
- SSH Tunneling
- K8S Credentials
- Basic K8S Commands
- Deploying Updated Code to Cluster

If you have different experiences or frustration, please share them here or with me directly here or on [Twitter](https://twitter.com/CS_0010?ref=ctrlstack-engineering-blog), or [LinkedIn](http://www.linkedin.com/in/chrisshellenbarger?ref=ctrlstack-engineering-blog).

**First Speedbump: Installing kubectl**

I'm used to installing the latest version of an application and expecting it to work better than previous versions.   However, with `kubectl`, I learned that `kubectl` versions only work with +/- 1 major version of the corresponding control plane APIs.

My lack of knowledge of the term 'control plane' contributed to my confusion.   I later learned that this meant the server version of the management APIs used to manage Kubernetes.

Said more simply, your Kubernetes client needs to be within one major version of the Kubernetes cluster.

The pain can continue if you have clusters spanning over three major versions.  Then, you have to switch your `kubectl` client version depending on the Kubernetes cluster you're working with.

I now know there are tools for quickly switching Kubernetes versions.  But, I have yet to spend the time to learn them as our current clusters are all within a range supported by a single client.

**Second Speedbump: SSH Tunneling**

Once I installed `kubectl`, I discovered I needed a route to the Kubernetes clusters from my work computer.

I needed to create an ssh tunnel to access the network that the Kubernetes cluster was running in.

This is a security best practice, of course.  However, it added to the confusion I was already experiencing while initially learning to use Kubernetes.

**Third Speedbump: K8S Credentials**

Once I could talk with the Kubernetes Cluster, I needed to configure the credentials of my client to properly authenticate with the APIs.

To this day, I still can't remember what I had to do.   I vaguely remember the senior engineer on the team sending me his `kubectl` configuration and cryptographic keys.

I put these in the location that I was instructed, and then I could run basic `kubectl` commands.  Yay!  I was on the right path!

**Fourth Speedbump: Basic K8S Commands**

Now I was connected and could execute authenticated commands to `kubectl`, but wtf commands was I supposed to use?

Looking through examples, I saw a lot of usages of the get and describe commands combined with the various Kubernetes resource types (pods, services, ingress, etc.).

I attempted to view my pods but received nothing in response.  I then learned the concept of namespaces, added the namespace to my commands, and finally received results.

I needed clarification to determine what other resources I could query for and describe.  I needed to figure out what terms to use on Google.   Eventually, I figured out that you could run `kubectl api-resources` and get a list of resources.  Still, for the longest time, I used trial and error.

**Note** :  You can add `--namespaced=true` or `--namespace=false` to the `kubectl api-resources` command to view the resources grouped by namespace.

**Fifth Speedbump: Deploying Updated Code to Cluster**

The CI/CD build would build and push a new image to a Docker repository, but how did that image get rolled out to our cluster?

I was told that to roll the new code out, I would have to issue a delete pod command, effectively restarting the pods, which would cause the new image to be pulled and the new code to be rolled out.

Then, how did I know I didn't miss any of the pods?  I'd look at the running times for the pods and ensure that they all had been restarted recently.

In reality, pod run duration times don't tell you what code is running.  But, at the time, it was the best I could do, given my limited knowledge of Kubernetes.

## This was just the beginning.

This was just the beginning of my journey with Kubernetes.  Many people reading this have had, are currently experiencing, or are about to have similar experiences using Kubernetes.  

I'd love to connect and share experiences here, on [Twitter](https://twitter.com/CS_0010?ref=ctrlstack-engineering-blog), [LinkedIn](http://www.linkedin.com/in/chrisshellenbarger?ref=ctrlstack-engineering-blog), or any other network you may be a part of.

I have much more to share about my experiences with Kubernetes.  I encountered the above things within the first week of using Kubernetes for production code.