Over the course of the last week, I learned…

  • Docker
  • Kubernetes

Docker

I finished the [[Docker Training Course for the Absolute Beginner]] this week.

The main takeaways from the final sections of the course revolved around the Docker Engine, Storage, Networking, and the Registry.

This was extremely valuable as it cleared up for me so many things I’ve only passively dealt with up to this point as I’ve deployed containers in my homelab. Now, I have a much better understanding.

I know where Docker’s default location for storing volumes is located and the difference between volume and bind mounts. I have a much better understanding of networking. Eg, I know that the default network created by Docker is a bridge network and typically has the 172.17.x.x subnet. Especially exciting is that I understand how to create my own user-defined network by simply entering the following on the command line

docker network create \
  --driver bridge \
  --subnet 182.18.0.0/16
  custom-isolated-network

I don’t know why, but I find it magical that I can type that into my computer and create a network as simple as that.

Finally, I am glad to have a much better understanding of how the Docker Registry works as well as how to deploy a private registry. To deploy a private registry, one can run a Docker registry image. Of course you can.

docker run -d -p 5000:5000 --name registry registry:2

Once you’ve got a local private registry, you can push and pull your images there instead of to the default Docker Registry. Incredibly handy and valuable to know how this all works.

That concludes my foray into learning about Docker for now. I will continue to brush up on my knowledge but now that I’m done with this beginner course, my attention shifts back to Kubernetes.

Kubernetes

The central piece of my learning revolves around Kubernetes. Though I am sprinkling in the basics and Docker as outlines above, my primary focus is on Kubernetes and attaining my administration certification. As I mentioned before, I yearn to learn Kubernetes and the surrounding components that will make me a great administrator so I can’t simply study Kubernetes all the time.

With that in mind, here’s what I learned about Kubernetes this week.

I started yet another course on Kubernetes this week. It’s the CKA Course by TechWorld with Nana. They recently revamped the content and I was on the waiting list to be notified when it was ready. As soon as I got the email, I signed up and hit the ground running. I’m so glad I did. Based on my current knowledge and the format of this new course, I’m learning a lot of new things as well as reinforcing other things I’ve learned along the way.

One major difference between the KodeKloud CKA course and the TechWorld CKA course is that with the TechWorld course, we start off by creating, from scratch, our own cluster on three AWS EC2 instances. This exercise alone, and the explanations of the core structure and components has been tremendously helpful for my comprehension. To be fair, we did cover these elements of creating a cluster from scratch in the KodeKloud course but it was theoretical-heavy, a bit abstract, didn’t happen until nearly the end of the course, and ultimately rife with complexity. With TechWorld, it’s literally the first thing we do and for me, it’s a much more powerful way to learn.

I’ll summarize some of the highlights of my TechWorld CKA course below.

After a high level overview of Kubernetes which was helpful to review, we dove into understanding TLS certificates, how they factor into a cluster, and what we’ll be doing with them to allow the cluster components to securely talk to each other.

Then we moved on to provisioning our infrastructure. We set up three AWS EC2 instances and configured them with an Ubuntu foundation.

Through this process, i gained some hands on experience with AWS, EC2 in particular, and got a really solid understanding of how to configure the control plane and worker nodes. Creating my own cluster on the cloud from scratch has given me a very solid understanding of what is happening and why.

For instance, my understanding of static pods is now much deeper. We can’t leverage the API Server and Scheduler to schedule pods on the control plane if those don’t exist, right? That’s why we need to generate static pod manifests, place them in the /etc/kubernetes/manifests directory, and let Kubelet do it’s thing as we bootstrap the cluster.

Again, I know we covered these topics in the KodeKloud course, and I’m definitely not knocking the course, but there is something about the approach that TechWorld is taking that simply resonates more with me. I understand this so much better after having gone through it this time around.

I then learned how to install kubeadm. We disable memory swapping, open ports via configuring security groups, and setting up hostnames for the nodes. The Kubernetes docs are thorough in this respect and it was helpful to have a course instructor pointing out the sections to really pay attention to.

Finally, we went in depth on Container Runtimes and the Container Runtime Interface. My understanding of this topic has increased tremendously as I can now capture in writing, as I have done in my Zettelkasten, why we might go with containerd and whey Kubernetes moved away from only supporting Docker containers as it did in the beginning.

That’s a wrap for this week’s learnings. If you made it this far, thanks for reading! See you next week with another wrap up.