Check out a free preview of the full Complete Intro to Containers (feat. Docker) course

The "Kubernetes Fundamentals" Lesson is part of the full, Complete Intro to Containers (feat. Docker) course featured in this preview video. Here's what you'd learn in this lesson:

Brian explains that Kubernetes is used for production workload and is useful when a lot of containers and different services are involved with complex relationships with each other, and goes over the fundamental terminology and concepts of Kubernetes.


Transcript from the "Kubernetes Fundamentals" Lesson

>> All right so that was darker compose, this is very much more and one misses primary useful to you and your day to day basis, and it's much more oriented towards development the kind of experience as an NCICD kind of experience. Kubernetes is very much oriented towards production workloads.

Kubernetes was written for production workloads, you probably don't typically want to run Kubernetes on your computer for just a slew of reasons that we'll talk about. So Kubernetes. This section I'm just gonna tell you the kind of the high level concepts of Kubernetes, and then I'm gonna show you kind of a cheap way to get introduced to Kubernetes.

So first of all, you'll likely see Kubernetes often abbreviated as k8s, k-8-s, cuz there's 8 characters between k and s, that's where that comes from. People are lazy and can't remember how to spell it. Especially for non-English speakers, it can be difficult to remember How to spell Kubernetes, so that's why its often abbreviated that way.

So, Kubernetes. I like to tell people that I think containers are simple and more easy and everyone should know how to use containers in docker, and things like that. Kubernetes is hard, and it's difficult. And not everyone should know how to use Kubernetes. But I'm gonna show you how to do it just so you understand what it is and so you can know when to reach for it and when you definitely do not wanna reach for it.

Like for me personally, I compare this to Redux and react, right, Redux, it's really difficult and not always necessary and people still wanna know it. So I'm going to teach you how to use Redux,and I'm gonna tell you not to use it, [LAUGH] for the most part, and that's kind of what my point here with Kubernetes as well.

Is that, it's difficult, It's hard. It's a complicated product that solves a complicated problem. And for the most part, you don't normally need it unless you are a big company that's shipping big, micro service oriented architecture. This was created at Google for Google problems and most of us don't necessarily have Google problems on the day to day Okay?

So, let's talk about when you would wanna use it. Kubernetes is useful if you have a lot of containers, a lot of different kind of services, right? Like we have the web services, the DB service. And you have all these various different services and they have complex relationships between each other.

That's when Kubernetes is very, very useful because you can define these relationships, you can define the security rules, it scales out very well. That's another thing that Kubernetes is very good at doing. It's very good at taking one container and making that 100 containers and then going back down to one container, right?

It's very, very good at checking the health of your containers. So if you have like, 40 containers, and one of them starts going wonky or something like that. It can detect that via health checks and say cool, that container, shut that one down, spin one up, put it back in its place.

So it's really good at stuff like that. These are all very, very production oriented and Kind of problems, right? Let's go over some of the fundamental concepts and terminology of Kubernetes cuz you kind of have to understand this to be able to use Kubernetes. So when you spin up a Kubernetes cluster of any variety, the first thing is it's gonna have a master and that's kind of like a central control pod.

That controls everything else in the service. So a lot of cloud providers won't charge you for the master. So I know Azure and Google Cloud Platform don't charge you for the master. But Amazon does actually. So they will actually charge you for the notes that it's running inside of Kubernetes to control everything else.

That's for AKS and which is Azure Kubernetes Service and GKE Google's Kubernetes Engine, but Elastic Kubernetes Service which is the Amazon one does charge you for the master. You can also run Kubernetes without using like AKS or or GKE or anything like that. Just on VMs yourself and run your own stuff, it's just hard, right?

Cuz you have to not now manage not only all the various different pods and nodes and things like that, you also have to manage the hosts which is more work. What about a bunch of companies do it? Okay. So that's what the master is. It's like the central control plane, like when you tell Kubernetes hey, scale this up, to ten nodes.

You're gonna talk to the master and then the master is gonna do all the work for you. So it's like the brain. I think that's a good analogy. It's the brain of the Kubernetes cluster. Okay, the next thing that you need to know about is nodes which is not to be confused with no Node.js.

There's no relation between the two. These are actually like the worker endpoints, but the nodes that are actually gonna be doing the work for you. And they're the ones that actually talked to master. So one node can contain multiple containers, right? Just like a VM can have multiple containers running on it.

But it's like these kinda endpoints that are managing all these kind of workloads for you. Some of your nodes will just be one container as well and that's also can be normal as well. Particularly if you have either small nodes or you have containers that take a lot of resources.

So, if you're running a Node.js server like we are, you'll likely have many containers on one node. That is kinda frequently what will happen. So technically a node is just like a deploy target. It can be a VM. It could be another container. It could be a little bare metal server.

It's it's relatively unimportant of what the node is as long as it can except containers, okay? So at that point then we have things that are called pods. And it's basically a deployment use of the unit that cannot be separated. So I'm trying to think of a good example of that.

Let's say you had this micro service that talk to this micro service under to strongly linked together. Maybe it's like a password service in a user service and they can't really be separated. Cuz they need to deployed together. That would be considered a pod, right. So be like two or three containers that are atomic right.

They can't be split apart so you deploy them as one pod. It's not always the case, a lot of times your pod will only be one container, like it will just be one service that you're running, but frequently it can also be multiple things together. And then you'll have this pod that talks to this pod and all those pods talking together will make a service at the end of that you'll have a user service that people will talk to.

So let's talk about what a service is. When you have pods and when you have these containers, they will be talking to each other and those kind of routing things will dynamic because you'll be spinning up pods and destroying pods and likely to be able to be doing all sorts of different things.

And at any given time you don't actually know how many containers will be running at any given time. So that's when services become useful, because services are like a group of pods together that make up one service. So you'll have let's say, like a checkout service. And then you can have your cart service, talk to this the checkout service, and they talk to each other on these one URLs.

They are consistent despite the fact that these services don't are totally separate from each other. They can talk to each other in a consistent way. You define those as a service. That kinda makes sense? We're getting to the point where, there's just a lot of stuff coming at you.

I'm trying to teach you Kubernetes which again, there should be like a five day course just on Kubernetes in like a half hour. So just it is complicated. If you feel like it is complicated, it is because it is complicated, right? So just be aware of that. Okay, and then at the end of that you have what's called a Deployment, which is what you described to Kubernetes, here's the things that I would like to go out.

And then you can have multiple different deployments you can have, you can roll back deployments. It's kind of like a delta between, or like a change set of, I had this and now I wanna go here, right? So you're defining like something that's different and if that Deployment goes wrong and you say hey, roll that chain set back to where it was before the broke, right and then you can deploy more deployments as well.

So you're kind of defining differences over time in your cluster.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now