Is Kubernetes Too Complicated?

I'm here today to give a talk about Kubernetes. This is my first in-person conference presentation, so you might understand that I'm a little nervous, but I think that's normal. I chose Kubernetes as the topic for my first talk because I'm truly passionate about it. I'm fascinated by Kubernetes. And I'm sure all of you in the audience also share my fascination since you chose to be here today and not somewhere else, and I appreciate that.

Let's start by introducing myself. My name is Julia. I work as a global technologist in the product strategy team at Veeam. In addition, I'm an AWS Community Builder, so there's a good chance I'll be creating some content on EKS in the future. Nothing against AKS or GKE, of course. I also organize a bi-weekly meetup in New York City called 'New York Code and Coffee', and you're all more than welcome to join if you're ever in New York.

Now, a warning - this is not a technical talk. I'm sorry to disappoint you if you came here expecting to see a demo or learn how to expose an API with Kubernetes or something along those lines. For those who came for more technical content, there are numerous amazing speakers who will be giving more technical talks throughout today and tomorrow. Just check out the schedule, they're going to be amazing.

Today, I'm here to share my personal journey in learning Kubernetes, and hopefully, I can inspire those who want to learn it as well.

So, why did I decide to learn Kubernetes? This time last year, I was doing an online coding boot camp called '100 Devs' and while working on some really cool applications with Node and React, I came across this word - Kubernetes. And I wondered, what is that word? I wanted to learn more, so I started researching. I couldn't understand anything, started Googling more, still couldn't understand anything. In hindsight, I probably went about it the hard way because I jumped straight into Kubernetes without learning about containers first. But, what really helped me was getting involved in the community and asking for help. I made many friends who encouraged me to keep learning and I was able to delve deeper into DevOps, CI/CD, Docker, and Kubernetes. It all started to click when I was able to run my first Kubernetes locally.

Fast forward to October, I had the amazing opportunity to attend KubeCon in Detroit. I was amazed by the whole community getting together and discussing Kubernetes and other Cloud native tools. It was truly an incredible experience to be part of that and I'm very grateful for the opportunity. I even recorded a vlog, which you all might want to check out later.

Seeing the community get together like that made me want to contribute more. So, I started helping out with the localization project in Kubernetes. If you didn't know, there are hundreds of people translating the project, particularly the documentation, into various languages and they keep it up to date with all the releases.

It's truly amazing.

And eventually, I was invited to be a keynote at All Day DevOps, which turned out to be a great experience for me.

So, the Kubernetes learning curve... The Kubernetes learning curve is immense. People on the outside might even get intimidated to get started, judging from all the tragic, funny memes out there. This graph implies that you have to learn way more before you can get anything to work with Kubernetes. It also gives the impression that it takes less time to learn more features, which is not true. But at least, the emotional journey of learning Kubernetes is portrayed accurately.

Kubernetes is also like an iceberg: you learn the basics, only to realize there's more to learn. And then once you learn more, there's still more to know. So you're always like, "What am I learning?" I'm probably at this stage where the guy is growing a beard by now.

And look at the terminology! Yes, the terminology... It's confusing. There's kubelet, scheduler, stateful set, coordinate, Ingress, control plane, config map, RBAC... I could only put a few on the slides, but you know there's a lot more. I feel like we could build a whole encyclopedia just with Kubernetes terminology.

And when people are getting started with Kubernetes, they're overloaded with this terminology and the theory of how Kubernetes works, which can be very overwhelming. So don't look at it as a roadblock. Just keep going, and soon things will start to make sense.

What is Kubernetes? Kubernetes is a system for managing and orchestrating containerized applications in clusters. Essentially, Kubernetes allows you to take a set of virtual or physical machines and transform them into clusters to run your containers. Kubernetes is very useful if your application consists of multiple independent services and you need to host them at scale.

And what I mean by containers is they are a way to package and deliver the application code, so they simplify the developer's workflow. Otherwise, imagine all the dependencies in the local host to manage...

One caveat before I move forward is: Kubernetes is very powerful, but that does not mean that every team and every app should use it. It can solve a lot of problems, but it's only for certain cases. So if you have a small app that only 10 people use, Kubernetes might not be the best solution for you.

So if you're still confused about Kubernetes, let me help by starting to give you a simple analogy about renting rooms in a house.

So, imagine you own a house with nine rooms, and you want to rent out three of the rooms. You have two choices: you can post ads online and manage everything yourself, or you can hire someone to do it for you. Because you're a busy person, you decide to go with an agency to take care of everything for you. Your contract with the agency states that at all times, three rooms should be available for rent, and the agency can pick the rooms. Each room will have two beds. Now, this is important to remember, because the bed is the most essential aspect of a rental room, as it's the bare minimum required for a guest to be able to spend a night comfortably.

Every time a guest leaves, the room needs to be cleaned. If there are too many booking requests, like during a holiday season for instance, then booking availability can increase from three to nine rooms. And it's great because you all can make more money! The agency will also provide a special phone number that is meant just for the house.

Now, to manage the property, the agency hires employees to take care of your requirements. So, when a room is booked, one of the employees ensures that it's in good condition, cleans it afterwards, and so on.

The agency keeps all the information about employees, rooms, beds, bookings, etc., in a system. And they also keep track of the employees' time off in order to allocate another employee to the room should the current employee fall ill or go on vacation. And when a guest makes a reservation for a room, the agency contacts the employees via their direct line and then provides instructions to ensure that the room is prepared. The guest arrives, gets the keys, and sleeps in the bed at night. The room is cleaned afterwards, and the cycle repeats.

But what does Kubernetes have to do with this? It's very similar to the Kubernetes architecture. By hiring an agency, you have achieved a similar automation to what Kubernetes provides.

So, say you're an app developer instead of a rental house owner. The node, also known as worker node (I put 'N' because there can be several worker nodes), is the house, and the rooms are the pods. The beds are containers - a package containing all the dependencies and components required to run the application.

So to recap, the node is essentially the machine that runs one or more pods. Now, as the agency's employees ensure the rooms are fully functional, in Kubernetes, the Kubelet is a component that runs on each node and is responsible for maintaining the desired state of the containers on that node.

The agency is the control plane. And just as the agency decides which rooms should be rented and when, the kube-scheduler decides which pods run in which node based on what resources are available and its requirements. Like the agency decides what to do when an employee is off, the kube-controller decides what to do when a node goes down, or when the machine stops working for any reason.

The agency's systems, where all the details are recorded about how many rooms to rent, how many beds are available, which employee is doing what, etc., correspond to the etcd data storage. That's where configuration data is stored. For example, if you need three pods to be up on time. The etcd database is highly available and designed to continue functioning even if one or more of its nodes fail.

The agency has an internal phone line, like I mentioned, that communicates with the rental house. Similar to the API server, the Kubelet receives instructions from the API about which container to run and how to manage them, and also monitors the state of the container and reports back to the API server with information about the health and status of the containers.

Then, the API server is also responsible for processing RESTful API requests from clients such as kubectl. The API server communicates with other cluster components such as etcd, the scheduler, and the controller-manager to ensure consistency and reliability of the cluster state. The API server is a critical component of the cluster, providing the main point of interaction between the cluster and its users.

The rental house itself also has a phone line, which is the kube-proxy. The kube-proxy runs on each node and is responsible for forwarding the networking traffic to and from other pods on that node.

In Kubernetes, a deployment includes your set of requirements, such as how many pods you need to be running, what resources (CPU, for example) you need, and so on. Kubernetes ensures these requirements are satisfied without manual intervention.

And remember about that extra clause in the agreement that, when too many rooms are booked, you can grow more rooms? This is equivalent to auto-scaling in Kubernetes. That means Kubernetes can scale your services, giving you more pods as your application users increase. So just as you can make more rooms available if more guests are trying to book, you can create more pods.

Great, yes over there. So, is Kubernetes really complicated?

Hey, I say it depends. I was practicing this talk a few days ago with my friends in New York, and they are not technical, so they didn't understand anything. They were like, at the end of the presentation, "So, what is Kubernetes?" And I had to explain everything again. But for people who are into tech, I would say, like, you just have to start slowly, take one step at a time.

And, also, this is funny. I ran a poll on Twitter, and 38% of the people find Kubernetes complicated, and 37.3% - almost 38% - don't even know what Kubernetes is. And this is only 574 people out of the 7153. So all those other people, they didn't even want to bother answering the poll. Probably, they don't know what Kubernetes is.

Kubernetes has gained a reputation for being tricky to learn, confusing for newcomers, and unwieldy for simpler use cases. However, pushing through the initial learning curve puts you at the forefront of cloud-native application deployments and gives you a better understanding of how the architect system works.

So, if you start - if you want to start your learning journey, it's a good idea to narrow your objectives and focus on what you want to achieve with Kubernetes. But what I recommend, and what has worked for me, is to start by familiarizing yourself with the basics of containers and containerization. So, start with that. I jumped to Kubernetes right away, but then I came back to learn more about containers.

Also, get a good understanding of how Kubernetes fits into the containerization ecosystem and its key components, such as pods, replication, controllers, and services. Then, set up a local development environment, such as Minikube, to practice deploying and managing containers with Kubernetes. Once you feel you understand how it works, explore more advanced topics like scaling, self-healing, and configuring storage and networking in a Kubernetes cluster.

And, meanwhile, keep working on real-world projects, because nothing beats hands-on learning.

Now, some resources that helped me learn throughout my journey. First, while you're learning, look at the Kubernetes documentation. It's the best place to go when you're starting out. And don't forget to join the Slack community of Kubernetes, and also go on Twitter. There's a lot of people willing to help, ask questions. You know, just interact with the community. They're all amazing.

And these are some of the key resources that helped me. Some videos on YouTube, these ones are great. And also, Kubecampus - they have a hands-on lab that you can use. You don't even have to, you know, download anything. You can do it from your browser, and it's great, especially for beginners that want to start learning.

And that's it. I wasn't going to open for questions, but since you're better than my friends from New York - you're a better audience, and you laughed at my jokes - I'll open for you. I'll make an exception.

And the QR code is for the slides. So, whoever wants the slides or the resources, they are in the notes, and you can just scan it.

Yes, thank you.

Any questions? No technical, please. A question there. I'm joking. You can ask technical questions.

Yeah, so, I guess like every so often when you're trying to learn something new in Kubernetes, there's always like just a new thing going on. Like, service mesh, or like some other new technology coming from vendors. Do you have any, like, process to, like, kind of navigate those as well, or like, just how to - when should you do a deep dive, or when should that be a fad or things like that?

So, again, I would say, community. I talk a lot. I have a lot of friends that are in the cloud-native space, and every time I learn something new - I see a new term that I don't know - I ask them, because they are my first go-to resource. They explain to me, you know, overall, "Is it worth learning? Is it for my level? Because I'm still a beginner." So, and then they explain. And after that, I keep researching on Google, YouTube. But I would say, like, first, talk to your peers, friends, community, post on Twitter like, "What is this term? Is it worth it? Is it important if I want to - if I want to run a cluster, if I want..." So, I would say, community is at the heart of the cloud-native and Kubernetes as well.

I really loved your presentation and you asking the right question. I see the more Kubernetes becomes mainstream, and more of us devs have to use it, the more we find out it doesn't have the developer experience we need. It's just too low level, low abstraction. So we need something on top of it to work with it. So, having a PaaS on it or somebody builds something for us, then yes, it makes sense. Because I just drop my code and say, "Here, run it for me." So on. I really like it. So, we'll see what comes now when the community picks more up and creates services more on top of it. I think Rancher, they have something. He will explain about it some April. Maybe later. Yeah, so, thanks again for your session.

So, what's next on your education journey?

Next, probably diving deeper into kubernetes for sure. And also, learning more about AWS, since I'm an AWS Community Builder, and it's gonna be one of my focuses in my new job. So, doing that, but Kubernetes is one of my passions, and I'll still be learning. I'll see everyone at KubeCon in Amsterdam. If you're going, yeah, I'll see you there.

So, yeah, any other questions? One here, thank you.

Oh yeah, so, so, all this low-level stuff. So, I went through the same similar thing, and, so, when you go downstairs, and you go to all those vendors and stuff, and they offer like solutions to host things, and, you know, all these cloud-native stuff, so when should you go from low level to that? To things like Rancher? To things like, you know, stuff that they're selling down there? Like, should you even care about what a service mesh is, a cloud proxy, if you have something like that, or when should you make that jump or whatever?

It depends. Are you looking to only learn, or do you need to use those tools for your job? Or, you know, or even use those tools if you want to run your application on top of them. If it's just learning, I would say probably, yeah, I think like you can always learn everything, you know, it's worth learning. Talk to them at the booths, etc. But, for work, I think like just focus on one thing. But, go down and talk to them, maybe. We have one of the representatives here, and he's gonna give a talk, right? Yes.

So, yeah, I'm not sure if I answered your question, but thank you.

Well, I think that's it. Thank you. So… Oh, one more. I just tried downloading the slides from the QR code there, and I can't tell whether my phone is just having difficulty displaying the entirety of the file, or if it's an older rev of these slides. Would you mind flipping back to that learning roadmap of more or less five bullet points towards the bottom? Of course. Of course. Thank you. But, I'll check about the QR code to do the link or something later. Yeah, thank you, everyone.