Kubernetes 101 | Nigel Poulton | Skillshare

Playback Speed


  • 0.5x
  • 1x (Normal)
  • 1.25x
  • 1.5x
  • 2x

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Watch this class and thousands more

Get unlimited access to every class
Taught by industry leaders & working professionals
Topics include illustration, design, photography, and more

Lessons in This Class

18 Lessons (1h 32m)
    • 1. Introduction

      4:14
    • 2. Cloud-native microservices

      5:16
    • 3. Kubernetes cluster

      3:30
    • 4. Kubernetes masters

      4:36
    • 5. Kubernetes Nodes

      5:41
    • 6. Hosted K8s

      4:07
    • 7. Kubernetes as an orchestrator

      3:18
    • 8. Development workflow

      5:07
    • 9. Desired state

      5:46
    • 10. Getting Kubernetes

      5:43
    • 11. Deploying a Pod

      7:52
    • 12. Connecting via a Service

      9:15
    • 13. Using Deployments

      4:57
    • 14. Self healing

      4:13
    • 15. Scaling

      5:08
    • 16. Cloud load-balancers

      4:46
    • 17. Rolling updates

      4:29
    • 18. A really quick recap

      4:08
  • --
  • Beginner level
  • Intermediate level
  • Advanced level
  • All levels
  • Beg/Int level
  • Int/Adv level

Community Generated

The level is determined by a majority opinion of students who have reviewed this class. The teacher's recommendation is shown until at least 5 student responses are collected.

45

Students

--

Projects

About This Class

If you need to get your head around Kubernetes and want to learn and master the fundamentals, get your hands dirty deploying and managing an app on a real Kubernetes cluster… this class is for you!

You’ll learn both the theory and then have the chance to get your hands-on deploying a simple app, demonstrate self-healing, scale it up and down, connect to it from the internet, do a zero-downtime rolling update, and perform a versioned rollback.

Meet Your Teacher

Teacher Profile Image

Nigel Poulton

Making Kubernetes less scary!

Teacher

Class Ratings

Expectations Met?
  • Exceeded!
    0%
  • Yes
    0%
  • Somewhat
    0%
  • Not really
    0%
Reviews Archive

In October 2018, we updated our review system to improve the way we collect feedback. Below are the reviews written before that update.

Why Join Skillshare?

Take award-winning Skillshare Original Classes

Each class has short lessons, hands-on projects

Your membership supports Skillshare teachers

Learn From Anywhere

Take classes on the go with the Skillshare app. Stream or download to watch on the plane, the subway, or wherever you learn best.

Transcripts

1. Introduction: Okay, hi and welcome to Kubernetes Warner one. This is going to be good. And then yeah, we're going to be learning some stuff, but absolutely we're going to have fun doing it. Now then, right off the bat. Okay, let's level set an aim in this course at those of you that are new to Kubernetes. In fact, you don't even really have to have use Docker now in IT or a developer background might be helpful, but you know what, it is not a requirement. So no prior experience necessary. Also, as the title says, it's a 1.0.1 course. This means when you don't, you're not going to be walking away as a Kubernetes guru, sorry about that. But you are going to walk away knowing what Kubernetes is and how it works. And you'll have an idea of some of the things it can do for you so that hopefully you, you'll look into take your first steps with Kubernetes. Well, who am I? I'm Nigel, and if you don't already know, I spend my life teaching the world, Docker and Kubernetes. He's like all this stuff here is mine. And as well as this, I'm out and about on the speaker circuit and I'm delivering workshops and events like Docker Con and what have you. Now. Obviously highly recommend my other stuff for taking the next steps. But then again, I would wouldn't I mean, it's mine are right. But I'll tell you what you be the judge, see how you feel after this course. And if you like this, let me tell you, you're going to love those. Anyway, this is me on Twitter and I'm keen to connect and talk about technology. But I've got to say this right? I'm busy like the rest of you, so I can't be a free technical support. I mean, I'm happy to talk about technology, but complex troubleshooting. Yeah, I'm really sorry. I just don't have the time. Anyway. It look, I've been doing this kind of thing for a long time now. So I'm confident when I say, I think you're gonna like it. And I'm similarly confident that you will walk away feeling that you've learned a lot. But look, I'm waffling. This is how we're doing things. Slice in the course pretty much down the middle, the first half. So maybe an hour or so. We're going to nail the theory like the Kubernetes architecture stuff here. Then in the second half will get hands-on. Now, look, it's a video course, right? It's your call whether you follow along with the hands-on stuff or whether you're just watch totally your core. But what I do not want you to do OK. And trust me on this, do not skip the theory cause it's really important, like I'll be using it to set the scene and prepare you for the hands-on stuff. Because you know what? I have 0 interest in you being able to follow along and being brilliant or type in commands if you don't really understand what's going on, believe me, right? I've been there myself. You pave retraining course. You follow all of the exercises. Sometimes you don't even make a single typo put at the end when you don't, you're actually none the wiser. You have not really learned anything. So like if anybody asked you what the commands in the stuff actually dead. I mean, who knows, right? So I don't want that to be you follow the theory. Well, speaking of the theory, we'll yeah, we'll describe what a cloud native microservices application actually is. Then we'll find out what Kubernetes is. We'll see how it's a cluster and then we'll see how it's an application orchestrator, h2. And I know, right, that is a lot of buzzwords, but it's all good because we'll explain every one of them as we go and as well will contextualize things with a look at a typical workflow of how you take application from code on a developer's laptop to actually be in a running application. Anyway, when we're done with the theory, then it'll be the hands-on. We will spin up a quick test. Kubernetes environment will deploy an app, connect to it, test a failure and say some of the self-healing that goes on. We're scaling up and down, connect to a load balancer and we'll do a rolling update. Now. I know that might sound like a lot of stuff, but we'll be keeping it simple and we'll be explaining everything as we go. Sound good. Let's do it. 2. Cloud-native microservices: Okay, so let's talk about what in the heck, a cloud native microservices up even as now, there's a ton of definitions out there, so I'm going to boil it down for you. Put first things first. Let's wind the clock back a bit. You say, back in the day, we build our applications where we lumped all of the features and logic and the different bits into a single program like a single binary. Now, I'm being high level here. But we take may be the user interface bits, all the middleware stuff, that database backend stuff and the reporting systems and everything that the app ever dreamt of doing. And we'd lumped into a single huge program and we'd install it and back it up and run it and all of that jazz, Yeah. And it was the way we always did things. And it was terrible. And when I say terrible, I am talking about losing entire weekends of your life to it, but not ordinary weekends. These were usually the long holiday weekends. So a common issue was upgrading the thing. I mean, it was so complex that no single person or Ting really new at all or was responsible for it. Which is a bit of a problem yet when you consider the entire thing was lumped and bundled as a single unit. Anyway. So let's say if we needed to patch may be the reporting components. Yeah. Well, no joke. It was all hands on deck for those long weekends, you'd be like pre-warming suppliers and customers and anyone that used the system and telling them that it would be down from five PM on Friday and not back-up until 10:00 PM on Sunday. And the bosses have the CIOs cell phone number on speed dial and half the IT department will be in the office all weekend and living on pizza and coffee. And it was high precious stuff. Anyway. The issues that forced that were architectural right? Everything was tightly coupled. Like we couldn't just take down the reporting bits and patch those independent of the rest of the system. Now, if we wanted to patch the reporting system, we had to take the whole thing down. Anyway. Look, that's how we use the row. And we've got words for applications like that, right? We call them monoliths. And in modern IT, that's like a cuss word, yeah, like if you run monoliths in your organization, you are properly embarrassed about it. You definitely don't tell people. Yeah. Anyway, luck. I'm kind of joking, right? And now most of us still have monoliths kicking around and that's fine, right? Anyway, things are changing and quite a lot different these days because now we've got cloud native microservices. Alright, let's break that down. So the microservices bit means we take all of the logic that we said, yeah, was it like web frontend and middleware and backend and reporting bits here. And we code them, and we've shipped them independently. So we've got the same overall app experience here or the same bits, but the role independent, like maybe there's a special dedicated team that codes and looks after the web bet and another team for the Datastore and another for the reporting system. So they're all coded and shipped independently, but they talk to each other and they form a useful. Now, I've drawn the line around them in dashes on purpose because they are all loosely coupled this time. So what that means is we can rev every component independently. Like it one bit has a bug or a security vulnerability and no, let say the reporting but again, yeah. Well, we can take that down and updated without touching or impacting any of the other bets. Yet, like we said, it all still works together to create the same useful business application. Well, that's the microservices bit, right? Lots of different small or micro services that talk to each other and make up a larger app. Well, the cloud native bit. This means it's built for cloud like demands. So it can scale rapidly up-and-down. And I'm talking that each micro service here can scale independently. Well, as well as that it can self hail and we can do rolling updates and version rollbacks and all that kinda stuff here. But I know lots of buzzwords and will explain all of them in due time. So just don't be overwhelmed by the buzzwords here. Now, something interesting that might not be so intuitive. Cloud native absolutely does not mean it only runs in the public cloud. On the contrary, in fact, and I'd even go so far as to say a requirement of a cloud native app is that it will run anywhere evening your on-premise datacenter. So that's cloud native microservices. Yeah, we build ups from small specialized components. We call these microservices, and these all talk to each other over API's usually, and they form a useful or a meaningful application. And the benefits, each individual part or micro service can be scaled independently and updated independently. And they can self hail and run pretty much anywhere. Good stuff. 3. Kubernetes cluster: Okay, time to focus on Kubernetes. Now, we're gonna think of Kubernetes as two things. One as a cluster and two is an application orchestrator. So on the cluster front, you know what, a cluster is. A cluster, right? It's a bunch of machines. And as long as the Linux, you know what, Kubernetes doesn't really care. So you could have stolen them. I mean, not that I'm recommending me stable, of course, but just to be clear, communities doesn't care. They could be instances in the Cloud, VMs in your datacenter or you know what? There could even be ban metals in your own datacenter just so long as they run Linux, Kubernetes is like, yeah, whatever. Now, I'm saying Linux, but actually windows is a thing with Kubernetes these days. In fact, Windows support in Kubernetes went GA, so generally available and fully supported in Kubernetes is 1.So 14 in the summer of 2019. So yeah, anyway, lock a Kubernetes cluster is a cluster of nodes. And like with most clusters, the same old rules still apply. So we can see on the picture that we divided the cluster into two parts. Here. On the left we've got the control plane nodes, and on the right we've got the worker nodes or suppose words. Ok, so the control plane, think of this as where the Kubernetes brains or the Kubernetes smarts exist. Yeah. Then the work is here. This is where we run our user applications and columnists like the cluster mussel, yeah, which I'll come to in a minute. Now, when we say control plane and Kubernetes is smart, we're talking about the things that make Kubernetes. Kubernetes. Now we'll dig in a bit deeper in a second. But for now we'll wanna make it clear that this is a typical type of cluster, meaning all the usual rules still apply, like there's no hidden magic, that means you don't have to care about things like performance and availability anymore. No, they still apply. I wanna be clear. You're time-honored. Battle tested production cluster rules all still apply. So like on the picture here, we got three notes in the control plane. Availability, three or five is probably recommended and one is better than to avoiding Split Brains. Yeah. Now, don't let the techno babble confuse you. The take-home point is that you need to make sure your cluster nodes are powerful enough. And you need to make sure that if one of them fails, things kept running. Anyway. That's the control plane bits. And the nodes that make up this control plane are generally called Master's or sometimes Head nodes. It's all just jargon though, onto the workers. Now, the reason I'm referring to these as the cluster muscle is this is where we run our user applications. So how fast your apps run in, how well they can scale. That depends a lot on how we provision these workers. So depending on your particular app requirements, some of these workers might be big beefy machines and some might be smaller machines. But remember, when I say machines, I'm talking Linux and Windows machines in the cloud or on prime, and they can be VMs or BAM metals. Now then mentioning windows reminds me, Windows machines are only supported as worker nodes. So the control plane nodes here, they've always gotta be Linux, but the worker nodes here, these can be a mix of Linux and Windows, which I reckon is the super high level. Let's take a bit of a closer look at H will do masters first. 4. Kubernetes masters: Alright then masters. So this is an exploded the oil like a zoomed in view of a master note. So actually one of these here, yeah. Alright, well, starting from the top, a reminder about terminology. We normally call these nodes the master's. But you know what, sometimes you'll hear other names like headnotes or whatever. It all means the same thing, a cluster node running the control plane bits, that's the brains of the cluster. Yeah. Now, if you're running a highly available cluster with three or five masters, each one will be running the same set of replicated services. This way, if any of them fails, the others keep the cluster running. Now, there's more services than these, but for a 101 cost, these are the main ones. So the API server get used to this one, right? It's like the gateway into the cluster. So anytime we want to query the cluster or make a config change or even deploy an app and then update it and all that jazz with, do all of that through the API server. So o sending commands to the API server. Now, without getting too deep for this course, right, it exposes a RESTful HTTP interface and every commanded it receives gets authenticated or authorized and pretty much sanity checks. But talking about issuing commands, I need to take a step back for a second. So we said when we issue commands, Kubernetes is they come in here to the API server, right? Okay, but how do we actually send those commands? Well, for the most part, right, certainly at a 101 level, we use the Kubernetes command line tool called Cube CTL. Now, in true Kubernetes tradition on your probably get used to this. There's like a million ways to pronounce it and you will hear everyone, like I say Cube CTL. But a lot of people say cube control law, cube cut Locke, who be cuddle I'd, and how you name it, right? Anything goes. The important thing, right, is the Kubernetes command line tool. So it's commands like Cube CTL create this and Cube CTL describe that. And Cube CTL delete something. And let's not get ahead of ourselves, right? Will see it all in a hands-on stuff later on. I just wanted to fill in a potential gap there, right? Anyway, we were saying yes Cube CTL commands go to the API server and they get authenticated or authorized and validated. So as an example, right, maybe we issue a command to, I don't know, maybe deploy an app or update an app. Yeah, well, whatever the command is telling Kubernetes to do that gets recorded in the cluster store as a record of intent. Now, the cluster store is a distributed database that's usually based on the open-source product called Etsy day. And it is the only stateful component of the control plane, meaning it keeps configuration data locally on disk. Now, once the intent of the command is persisted into the store, Kubernetes then asks the scheduler to assign the work out. So I think for simplicity's sake, we'll assume that we're deploying a web app. Yeah, and let's say that we want five running instances of it. Well, the scheduler's job is to go and find the best work in notes to run those five web servers. Now, this schedule is looking for things like, well, healthy nodes is a good start. Yeah, It's looking for nodes with the right resources and enough of those resources. Once it's found some nodes, it issues the work tasks to those and the app is deployed. And that's brilliant, right? Put. And this is the magic cube that is doesn't stop there. It then implements background control loops that constantly watched the State of the cluster. And they make sure that what we've asked for is what we've got. Now, we'll come back to this properly in a minute, right? But in this example, I think we said we asked for five web servers. Well, Kubernetes implemented control loop. That makes sure we've always got five anyway, right? I think for us, that's the control plane. It's the brains of the cluster and you'll want it to be highly available. We send our requests or commands to the API server component of it. These get recorded in the cluster store is our desired state. So what we want, the scheduler finds the nodes to run the work. And then in the background there's watched loops making sure that things don't break. And if they do, I should say when they do, Kubernetes fixes it. Brilliant. Well, that'll do for the control plane for now. Let's switch to the worker nodes now. 5. Kubernetes Nodes: Okay, so like the exploded view of the master, this is a zoomed in view of a worker. And every worker node in the cluster runs these same three major components. Now, from a terminology perspective, you can definitely call these workers and people know what you mean. But for the most part we just call them nodes. So masters for the control plane, yeah, uh, nodes for where we run our applications. In fact, sometimes we call the notes cubelets. That's how important this cubelets bit here is. Think of the cubelets as the main Kubernetes agent. Any node that you want as part of the cluster needs to run a cube. But now, I suppose initially the cubelets talks to the control plane and it makes the node CPU and RAM and the likes available to the cluster. So that work can be scheduled to the node, yeah. But it's also watching the control plane and it's talking to it. So the cubelets watches the control plane for new work tasks that it needs to run, and then it reports back on the status of that work. And interestingly, right, all of this talking to the control plane is via the API server. I want to be really clear about this. All communication with the control plane goes through the API server. It's like the Grand Central Station. Yeah. So Assad's humans talking via Cube, CTL or whatever. But then as well, all of the Kubernetes, bits and pieces, literally, everything that talks to anything on the control plane has to go via the API server. Anyway, look, the cubelets, it's the main Kubernetes agent. It runs on every node that wants to be a member of the cluster. If it stops like fails or whatever, yeah, it'll attempt to restart itself. Perfect, continents dead in the water than the node drops out of the cluster and its troubleshooting time. Ok, well look in the middle of the diagram, we've got the Container Runtime. Now, cuban attitudes is an application orchestrator. Yes, it can orchestrate things like VM's and serverless workloads. But for the most part, at a one-to-one level, ok, it orchestrates containerized apps. So that's apps that run as containers like Docker containers. Yeah. Now then we're looking at a work and note here, and we know this is where Kubernetes ones are apps. And we've just said for the most part, those African runners containers. So it makes sense then that every node needs some software to run and manage containers. I'm talking about basic stuff like how to pull a container image from a registry and then how to start and stop and update containers. Well, that piece of software, that's the Container Runtime here. Now, in the beginning of Kubernetes, that Container Runtime was always Docker. So we'd say like yet, Kubernetes plays run our app. The scheduler would find the node that could run it. The cube lit on that node would accept the work and then it would be opted Docker as the Container Runtime. Pull the image and start the container. But that was then, and this is now. And instead of the Container Runtime always being Docker, we've got this thing called the Container Runtime Interface or the CRI. If you're like you're acronyms. Cutting straight to the chase though, this is a plugin layer. The letter say, hey, maybe we don't want Docker on this node, we might need a different Container Runtime. Well, the CI makes that possible. So it is now really easy to say, hey, on this node, let's run may be g visor and here may be cutter, and here may be contained a day. Now, yeah, look, we are a 101 course, so I'm gonna keep this as simple as possible in this case, right, between all these different container runtimes like Katherine, container d, and what heavier choice is a good thing. Each Container Runtime potentially offers different performance characteristics, as well as things like different types of workload isolation. So for example, on the isolation from right, something like gee, visor or cata might offer a more isolated runtime environment than something like Docker. So if you run two workloads next to each other, right? Sometimes isolation of those workloads is important. We know what? That is, a whole topic of its own and we are not going there in this course. Suffice to say the Container Runtime here is the bit that spins up containers and manages them. Well. Last but definitely not least, the cube proxy. This makes sure Kubernetes networking works. Now a little bit of a step to the side here, right? When you build a Kubernetes cluster, part of that operation is to build a POD Network. And you know, well, it's dead simple, right? The POD Network is a big flat network that spans every node. So like you can totally have a cluster where all of the nodes are on different networks in the Likes. But then Kubernetes overlays this big flat network across all of the nodes. Now I'm saying overlay, right? It is usually a VX land overlay, but it can also be BGP. We know what, what's important is this POD Network is what all of our applications sit on. And it's nice and simple and flat, right? So all of our app components sit on it and can talk to each other. Brilliant. Anyway, look behind the scenes, right? Q proxy here performs all of the magic to make that POD Network happen. Things like IP tables and IPBES rules if you interested. But that's nodes. Now we're about to move on to Kubernetes as an orchestrator. Okay. But real quick, before they do that, I just want a quick look at something that's really popular these days. Hosted Kubernetes. 6. Hosted K8s: So we've got this picture, yeah, our Kubernetes cluster and it's sliced into here as a control plane and sort of a data plane like the Kubernetes brains live in this bit and then applications one here only. You know what is coolers? Kubernetes Tech is an i love it, right? I'm a realist and know that technology only really exists to run applications and build businesses, and of course, health care and humanitarian stuff as well. Yeah. But my point is nobody deploys Kubernetes just so they can say, hey, we've got Kubernetes is at least a hope nobody does. You say you deploy it so your applications can run in scale and Healon update and all of that stuff, right? So it's all about the application. But in this application focus world, we really only care about these bits here. I mean, all the control plane stuff as cool as it is, right? Just kind of gets in the way, like just spending time and effort planning and implementing all of the high availability stuff and maybe some of the performance stuff. Yeah. I mean, all it's doing is distracting us from building applications, which is exactly where hosted Kubernetes comes into play. So a hosted Kubernetes service takes the control plane bits here, separated out, draws a kind of line of demarcation and says, I'll tell you what. We'll manage all this control plane stuff for you. And we'll just expose the worker bits. So at a high level without getting into detail, you don't have to give a single thought to the control plane. It's all managed for you. So upgrades, availability, performance, all of that stuff, all taken care of by your cloud provider. Speaking of which all the major providers have a hosted Kubernetes service. The real big ones or Amazon IQ AS elastic Kubernetes service, Azure Kubernetes service, aka S and G k0, the Google Kubernetes engine. But as well, digital ocean, IBM Cloud, these guys have all got them as well. Now I've got to say it's the cloud. So costs apply. Nothing is for free, right? And as well as good as the benefits are, like you can spin up a managed Kubernetes cluster in no time and you don't have all the worry of the control plane. Yeah. Well, on the flip side, you giving up upon to control. So for instance, you're limited to the versions of Kubernetes is supported by a cloud provider. And let's say if you need to set any funky settings on the control plane, you most likely out of lock. So it's great, right? Put it to two-edged sword. The simplicity comes at the cost of configurability. Now then, and it's hard not to get into detail because I wanna tell you sound much, but I don't want to overwhelm you wanna 101 course. Anyway, you might be asking the question, especially if you're a developer. Why do I even have to care about the worker node bets? Like, why can't I just give my application to Kubernetes? And that Kubernetes is take care of everything for me. And that's a great question. And the, something called the virtual cubelets that's heading in that direction. So no real nodes in your cluster, like really cool stuff and one day potentially, no godless Kubernetes is. But I think for us, right, that's potentially really mind blowing stuff. If you're interested though. Google virtual cubelets. Bullock, I'm waffling. Kubernetes is a cluster of machines, mainly Linux, and they can run anywhere. Those individual machines operate as either a masters or workers master's implement all the Kubernetes cleverness and need to be highly available and all the usual cost to goodness. But we don't run our applications there on the master's work nodes. That's where we run our apps. Well hosted Kubernetes services exist on most cloud platforms and they mainly hide the control plane from us. Though other hosted options exist. Right? Magic. Let's now look at how Kubernetes is an application orchestrator. 7. Kubernetes as an orchestrator: Okay, Kubernetes as an application orchestrator. So first up, orchestrator, that suppose word, so what does it mean? Ok, bear with me on this for a minute. It is a bit cheesy, but I think it really drives home the point. So this here is a symphony orchestra, you know, a bunch of different instruments that come together and make hopefully amazing music. Only right now, they're all over the place and they've not got any music to play. So yeah, maybe Cool, put not much use. Well, let's bring in the conductor. So she comes in, puts every instrument in its place, hands out the music, and generally speaking, organizes everything. Like when the start, when to play your particular part went a speedo, went to go loud or quiet all of that jazz, Yeah, jazz. Oh dear. No pun intended there. Anyway. With just a couple of things, the conductor and some music like sheet music. Well, we've gone from Chaos to everyone playing their part and potentially creating a moving piece of music. And it's not too hard to make the leap to Kubernetes, where we've got a bunch of different application services here, all just chill in, in Medellin and really not having a clue what to do or when to run and where to run. So maybe engine X in radius and some OAuth and some custom bits here, all legit code and micro services, right? But no clue how they all come together and what their particular parties. So we throw Kubernetes is into the mix, like the conduct of the air. And then some application configs, think sheet music. And suddenly we've got this proper working up that does something, hopefully something useful. Now, in the case of the orchestra, it needed the conducted come along and organize them, tell them where to say it, who to follow went come in how to play all of that year. And it's kind of the same in Kubernetes with our app. So Kubernetes is for instance, scheduled each component. So like tells them which nodes to run on, which networks to attach to ports to expose all of that goodness. And in the orchestra example, everyone needed a copy of the music. Well, in the application here, every piece needs its own configuration. So what it's supposed to do, and that can be things like serve web pages, do authentication, maybe do searches against the database. Yeah. Which what on their own, these individual jobs might not seem like much. But when they're all running together, we'd get a useful application. Good. Yeah, I hope so cause it was definitely cheesy. But you know what? When I've done this, live in workshops and likes, everyone's always told me that it was good. So hopefully it was useful to you. Anyway. Next up, we're going to take a look at getting code from a developer's laptop to running on Kubernetes. 8. Development workflow: Okay, so an application workflow. So that process of getting code from a developer's laptop all the way to running on a live system. Well, it looks something like this. You write some code off the back of a requirement or an idea. Yeah. Now, Kubernetes doesn't care how you write your code or what languages it's in. So long as it were run on Linux or Windows, we should be good. Well, once the code is done, we package it as a container image post-doc to a registry, and then we're ready to run it, which is why Kubernetes comes in. Now, lock like way over simplified. So let's add a bit of detail. Like we said, you write your code in whatever languages you wanted, that doesn't change. But then this bit here, packaging it as a container image. Yeah, that might be new to you. So a typical workflow would be a developer with Docker desktop on their Mac or Windows laptop. They write that code than they use the Docker tools to build that into an image, which what might sound fancy, but it is pretty much just putting your application code plus any dependencies into a folder on your laptop, run a docker image build command against that. Felder and Docker does the hard work of building an image. When the build complete, you've got this thing that we call an image, right? Like we've hinted that the magic of the image is that it's got everything inside of it that your app needs. So your op code, of course, yeah. Put his well, it has all the dependencies like libraries and OS file system constructs. Meaning everything your app needs in order to run is inside that image. Meaning again, you can pretty much run it anywhere and it will just work. So you write your code, use the Docker tools to package it as an image, then use Docker image push to save it to a registry somewhere. Now a registry is just a place to store your container images and look. You can run you out on prem or in your own virtual private cloud, or you can use an internet-based registry like Docker Hub. The takeaway point though, once your images on a registry, it's ready to be pulled and run in production. Now. Production, yeah, of course, right. So in this process we are missing out a ridiculous number of steps. Say Yeah, like all the things that we do in the real world with a continuous integration or a continuous delivery pipeline. So that's things like automated builds, tests, vulnerability scans, all of that, goodness, yeah, we're just ignoring it to keep the example simple. But yeah, assume all that stuff's don't all the builds and tests and scans than your image goes into a production repository and your registry, and you are ready to deploy, which is where Kubernetes comes in. So at this point your development workflow is done and this is where the operations bits take-over. Now look, there's a lot to Kubernetes and there is no getting away from the fact that it is a pretty steep learning curve. But I wanna take a second just to give you a taste of some of the things Kubernetes offers to help you run your apps. In the picture here we're looking at three Kubernetes resources at Daymond set, at deployment, and a stateful set. I don't want you to concentrate on any detail here. Just take away the big picture. Okay? So a daemon set makes sure that one instance of a particular micro service is always running on every node in the cluster are really common example would be like logging or monitoring services. Yeah, you need it to run on every node. Well, guess what? Use a daemon set to accomplish that. So you'd have your logging or monitoring service, right? You would wrap it in a Kubernetes Damon set. Give it to Kubernetes to deploy. And Kubernetes will make sure that one instance of it runs on every node in the cluster. Brilliant. But if you add more nodes in the future, no worries. Kubernetes sees that and it makes sure that the new nodes get an instance. Good stuff. Well, a deployment is different. These are all about being able to scale, self hail and perform rolling updates. And we're gonna say these later in the hands-on section. So I'm just going to park deployments for now, right? Then the last one that we're showing and remember there's loads more. Okay? Put stateful sets are about deploying and managing the stateful parts of our applications. So these give us things like reliable pod names and ordered startups and the likes. Yeah. But look where high level or don't want to get lost in the detail on just pointing out right, Kubernetes offers loads of ways to deploy and manage the different bits of our apps. Cool, we'll look in summary, we've got three main parts to the workflow. You code your app. You use Docker to package it all up as a container image and push it to a registry. Then you use Kubernetes to deploy and manage it. Simple. Well, one was they were lesson and then we'll get into the examples. 9. Desired state: Right then one thing that we absolutely need to know is that the atomic unit of deployment or scaling and Kubernetes is something called a pod. And passwords can write atomic unit of scheduling. Yeah, Right? Well on the screen here, we can say that full VMware, the atomic unit of scheduling, is the virtual machine for Docker, it's a container and for Kubernetes visits the pod. Brilliant. Well, what that means is if we deploy an application on VMware vSphere, we stamp it out as virtual machines. If we deploy an application to Docker, we stamp it out as containers on guess what? If we deployed the communities? We stamp it out as pods. Now, stumping it out. Yeah. What I'm saying is that all the different parts of our apps on Kubernetes will be running as pods. So I don't know if we've got like a web front-end to our application. Yeah, we need to scale it. We scale it by adding more parts or if we're scaling down, we take parts away. Brilliant. Now then, yes, Kubernetes is an orchestrator of containerized apps. I mean, it can orchestrate virtual machines and serverless workloads as well. But for the most part, Kubernetes orchestrates containerized applications. So applications both from nodes are containers. Only. You can't actually deploy a container directly onto Kubernetes. Seriously, in order for containers run on Kubernetes, it needs to be wrapped in a pod, Yeah. And for the intensive OS now in its 101 course, just think of a pot is a lightweight wrapper around the container. All it does is lets that contain a run on Kubernetes. And now we're going to see them later in a hands-on bits and it'll all become clear then. But I've got one last better theory. Declarative deployments, undesired state versus actual state or proper mouthful. Well, Kubernetes loves us to describe things to it declaratively. Buzzword bingo, right? Would just love these buzzwords. Yeah. Well, on the screen, we've got some requirements. This is what we want. So ten copies of some service based on whatever image exposed on port 8080 with a particular label. That's what we want. And the technical term for that is desired state. Well, we write that in a config file and we give it to Kubernetes, ten replicas of whatever container on this port with that label, Yeah. And we're basically saying, hey, Kubernetes, just go and make this happen plays. And that's it right now. It might seem like nothing but think about it. Compare that to the effort and pain of writing some humungous script with all of the commands and all of the logic to like, well, decide which of the nodes to one the ten replicas on for starters, plus all of the commands and logic to pull the images, all the commands and logic to start the containers joined the networks expose the ports, are the labels, all of that stuff, right? Well, this declarative model has none of that. You just write down what you want, give it to Kubernetes. Let Kubernetes deal with the hard stuff. Yeah. And that's really brilliant, right? But you know what? It's only half of the story. Because you see, because we're declaring what we want to communities instead of just saying, hey, run this long list of commands. Well, because we tell it what we want, Kubernetes records this desired state as a record of intent in the cluster store, then it makes it happen. But after that, it spins up. Watch loops that watch the cluster and constantly making sure that what's actually running on the cluster matches what we want. Now, if it does, so if actual state matches desired state, Brilliant, Right? If it doesn't though, like maybe we've only got eight replicas instead of ten. Will Kubernetes does whatever it can to fix that magic? Well, look just in cakes out snooty, right? Let's say a node failed and we lose two replicas with it. And what the heck, right? It happens at three o'clock in the morning. Well, Kubernetes is knows that we need ten replicas. We've just lost three and it's gone down to seven. So it spins three more up and we're back to ten. Actual state matches desired state problem fixed, right? And no phone call to you in the middle of the night. Lavett? Well, this model is absolutely integral to how Kubernetes works and is one of the things that makes it so great. And this here, this is what it actually looks like. Now, if you've not seen a YAML file like this before and it looks a bit scary, a promise you, it is not okay. Like you never write these files from scratch. In fact, you know, I always just take an old one and modify it. Yeah. But the thing is, once you've seen a few, they start looking a lot simpler. Anyway, look, we're saying ten replicas, so ten pods, Yeah, running this particular image and listening on this port ASI, post-doc to the API server, assuming it passes all of the authentication and authorization gets recorded in the cluster store as our desired state and gets deployed to the cluster. Fabulous. But then, like we said, those reconciliation loops are running in the background and they are always watching the cluster all day, all night, yet probably with a coffee to keep it awake or whatever. Put it constantly watching the cluster. And anytime observed state varies from desired state, Kubernetes tries to fix it. Brilliant promise, right? You will love it. And something else that you love. We're done with the theory. Time to look at some examples. 10. Getting Kubernetes: Okay, so if you want to follow along, you're going to need a Kubernetes cluster and the sample app and lab files. So what we'll do is we'll show you some really easy ways to get Kubernetes. Then we'll show you how to get the lab files. So on the Kubernetes front will look at Docker desktop, play with Kubernetes and Google Kubernetes engine. Now of course, other options exist, and I guess if you've already got a cluster, maybe you can just use that though. Do make sure it's not your production cluster. Anyway, look for Docker desktop. You just come to the Docker website. Or even better, you can just Google Docker desktop. But either way you'll end up somewhere like this. And then you just download the version for you. Now, I am on a Mac right now. So I'll hop they Swan. And then when that's downloaded, it really is just a bit of clicky click Next, Next, Next. Honestly, it couldn't be easier. Anyway, when you don't, you'll get this whale or pear or it'll be down in the right-hand corner if you're on Windows. But clicking it gets you this fancy UI where you come and enable Kubernetes. Now it can take a minute or two to start, but when it's done, bingo, you're in business and you're ready to go get the lab files and crack on with the course. Now, Docker desktop is just for dev and test purposes and you only get a single node cluster C it here a single note acting as master and worker. Now, it's obviously not what you want for production, but it's definitely good enough with development. Okay, so play with Kubernetes. Again, just lashing into Google and follow the link. It wants you to login with, either GetHub on Docker hub, and then you just follow the onscreen instructions and you build a cluster. Now, look, play with Kubernetes is free and it's great. Honestly, I love it. But sometimes it is not super responsive or not can get pretty frustrating. But remember, it's free and the guys behind it are actually doing was a service just by putting it out that oh, you know what as well. If you look up here, this is a timer counting down until your cluster gets deleted. So again, like Docker desktop, it's just a playground. And of course this one has some performance issues at times. But the thing is, it is time-limited. So when not counter hits 0, it is born as not chose to your cluster and anything running on it. But once you clusters boat, honestly, it's lab files and you're ready to go. Okay, last but not least, for getting a cluster and remember, other options exist. But Google Kubernetes engine is a solid option for hosted Kubernetes in the cloud. And I'll actually be running a lot of the demos in the course on it. Anyway. Look, it's cloud service, so it costs money. Do not, under any circumstances, spin up a cluster for this course and then forget about it. Because if you do, you'll get an own welcome Bill. Anyway, as long as you have a Google Cloud account with billing enabled, it's just cloud dot google.com login to the console here, Kubernetes engine and then go through the motions of creating a cluster. So call it whatever you want, decide where you want it. I tend to go for whatever's the lightest when I'm doing a labs. And then under node pool here, it's up to you. But I normally recommend three nodes and a way that goes. Now, it'll take a minute or whatever to build. But when it's done, I'll pay you copy this alone G-Cloud command. And as long as you've got the Google SDK installed with G Cloud, then just give it a quick Rhone. And a Cube CTL get nodes, shows you up and running and ready to crack on. So again, at this point, you've got a Kubernetes cluster. And once you've got the lab files, you are ready to rock and roll. But like I said before, please, whatever you do, don't forget to delete the cluster when you done. Okay, so we've got a sample app on some config files on GitHub. And by the way, don't worry if you don't really know what GetHub is, you don't need to just point your browser hair. If you're interested. The app is in this folder. And then these are the config files down here in the root of the repo. But all you actually need is this link here, press the clipboard button, and then in a terminal window type git clone and paste in the link. And that's it. Or actually no, you know what, you've got a new folder. Cold. Kubernetes is 101 skill share or Scotia for short. O anyway, go into there. And that's the app in the config files. So look, with a cluster on the lab files, you're all set to go, oh, I'm terrible at this. And make sure that any commands that you run later in the course in any of the lab scenarios, okay? Run them from in this folder cuz you need access to the file, say yeah, well, that's it. C'mon. Let's crack on. 11. Deploying a Pod: Okay, so we're gonna ease ourselves in gently. We said already that the atomic unit of deployment on Kubernetes is the pod. And that a pod is just a wrapper around a container that lets it run on Kubernetes. So more pictures. I thought we were done with the slides seriously, right? If you think you're sick of them, they are the bane of my life. So this one will be a really quick one. We start with code, we build it as a container, wrap it in a pod. Lovely. So this is what it looks like getting. Now we're talking, this is a Kubernetes is YAML file. Sometimes we call it a manifest file, but this one is describing a pod. So starting at the bottom, this is what we call the container spec. So it's the container, the pod is gonna run. And then the stuff up here, this is the POD wrapping, Well, the container, but it's pretty simple. If you've done any Docker, you give it a name that arbitrary, right? Call it what you want. This is the image it's based on. So this is what holds all of your application code and its dependencies, Yeah, and expose it on port 8080, dead easy. The apps in here run it as a container, access it on this port and give it this friendly name, boom, that is u container. But in order to run it on Kubernetes, it needs all this stuff here. Yeah, the pod wrapping for want of a better term. Now, I think we'll walk through this one, right, because it's similar on all Kubernetes objects. We always start with API version and kind you can have them in either order, right? But API version v1 and kind pod, you know what? It's not rocket science, we're saying to Kubernetes is billed as a pod and build it on what is essentially a version one of the pod schema. If there's ever like a v2 schema, we'd expect it to have a few more bells and whistles, as is the norm with later versions of things. But yeah, give us a pod based on V1 of the pod schema or pod specification. Then metadata here, we're giving it a name and we'll use this in a minute. Then we given it some labels. Now will see the power of labels a little bit later. But for now, just let me say they are outrageously powerful. But that's it, right? That's our desired state that we banged on about earlier. So instead of writing a man who subscript with tons of commands to do things like pull the container image in commands to start the container, which by the way will be different if you use different container runtimes, yeah. But you'll also need commands to attach it to a network exposing on 8080. All of that complexity air, well, no thanks. We don't want any of that. Instead, we'll just put what we want in a file here, send it to Kubernetes and let Kubernetes figure how to do it. Speaking of which though, let's send it to Kubernetes. Now I've got a copy of the file here in my working directory. If you're following along, either clone the GitHub repo with this command here, or copy the text and put it in a file in your working directory called Pod dot yaml. And then look at the name of the file is arbitrary, but I'm just going to be showing you examples with it called Pod dot yaml. So Cube CTL apply file Pod dot yaml, And that's it. Now behind the scenes Cube CTL has got a config file. It's in a hidden directory in your profile called cube. And then in there it's got a config file, conveniently called config. While in there, it's got things like the clusters, API, endpoint and credentials and stuff. So that Cube CTL knows where to send the command and it can do authentication. Yeah, well, if we do Cube CTL get pods, there it is 101 pod and it's running. So the API server accepted our YAML as a new desired state store, the copy and the cluster store, and the scheduler found a healthy node to run the Piton. Brilliant. Now we can run a Cube CTL, get pods with the wide fly care to see which node it's running on. And a Cube CTL described pods 101 pod. And that will give us a more detailed view that is really nicely formatted. Now, these two commands, Cube CTL get and Cube CTL describe. These are gonna be your best friends, like you were, literally rely on them all the time. Now, a question I get asked all the time at workshops in the likes is, how do we write these YAML files and on there like a ludicrous number of fields and options. Well, to the first on how do we write them? The answer's pretty straightforward. For the most part. You just take an old one, maybe even from the web or somewhere and you modify it like even that super-simple pod yaml that we just did. I didn't type that from scratch. So yeah, normally you will copy an old one and tweak it. Now, the question about knowing all possible fields and options and stuff. You know what, this dead simple answer to that as well. Yeah, most objects have a proper daunting list of options that you can put in the AML, but you don't have to put them in. You just put in the ones that you need. Then the ones that you've left out, Kubernetes is expands them with default values. So you know what, if we run another Cube CTL get pods here, but we switch this option here from wide to YAML. Check that out. That is the fully expanded YAML from the cluster store. And I mean, it is way longer than the ten or 15 lines or whatever that we sent to the API server. So there's annotations and namespace under the container spec. There's well, there's a tone, right? So yeah, Kubernetes fills in any blanks where we don't explicitly set values. Now, haha, yeah, as well though, a bit further down, there's this whole status section here that we don't ever specifying our animals. But I love it, right? Cause it's a great way to reinforce that desired state versus observed state that we cracked on about earlier. So the spec section is basically our desired state. What we've asked Kubernetes is four. The state is block here though, this represents the current observed state of the cluster or the observed state at the time we run the command, Yeah. Well, we've got a container here based on our image. This is what we called it. It's ready running. This is its Ip, literally a ton of stuff. And yeah, that's a pod. We declaratively described it in a simple YAML file. It had a container spec and we wrapped it up as a pod. Then we used Cube CTL to send that YAML to the costas API server. We were obviously authenticated based on what's in the cube config file. The YAML got expanded with all the default values and stuff that we didn't specify. And it got stored in a cluster store. Then the pod defined in it got scheduled to the cluster and it's running. Marvelous. Well, in the next lesson, we'll see how to connect to it. 12. Connecting via a Service: So we've got a pod running, and inside of that there's container running, a simple web application, but we never connect directly to that pod. So we never take its IP or whatever and open up a socket to it. Now, there's a bunch of reasons for this and we'll cover some of them shortly. What we need to know now though, is that to access applications in a pod, we need another Kubernetes is object called a service. And that dead simple, right? Think of a service as humming a front-end and back-end. On the front-end, every service gets a name, an IP and port. And Kubernetes gives a cast iron guarantee that these values will never change. Then on the backend, they have a port and the label selector. Traffic comes in on the front-end. My service on port 30,001 or whatever. And it gets pushed out of the backend on port 8080 in this example, and load balanced across all pods in the cluster with the app, a Web label could not be ESEA. So the example we'll open up got like, I don't know, ten parts may be, but the service is only sending traffic to the ones with the app equals Web label magic. Well, here's a service yaml. We start out with API version and kind again, so that's saying, Hey, Kubernetes, Give me a service, please, and base it on the V1 definition of a service. Yeah. But then the front-end config right first up, we'll give it a name. Now, this gets registered with the internal Kubernetes DNS service. That means the service name is going to be resolvable from within the cluster is SVCs A101. This one is listening on two ports. This is still the front-end, remember? So it's lessening inside the cluster on port 8080 here and outside the cluster. So for connections coming in from external sources on port 30,001. So apps within the cluster can hit S-phase A101 on port 8080 here and reach the front-end of the service. As well. Though. This node port here says to also listen on port 30,001 on every node in the cluster. So we can come in from outside of the cluster and hit any node in the cluster using its name or its IP on port 30,001 and same result, we hit the service, right? Well that's the front-end config, the backend config like where does the traffic get routed to? Well, it goes out of the back on 8080. Again, in this example, it doesn't have to write a copy a different port, but it will go to any pod on the cluster with the API web label, which I think if we look at our pod here. Yep, it is listening on 8080 and it is labeled up as AP equals Web. So if we deploy that service and you're gonna get used to this, right? I've got the FVC YAML file locally here. If you're following along, make sure you've also got it locally. Now, you can call the file names anything you want, right? It doesn't have to be SBC dot yaml. But when you type in the commands, if you've changed the name of the file, make sure you don't just type what I'm typing. Yeah. Well, look, again, it gets sent to the API server, authenticated and authorized. We get an update to our desired state persisted in the cluster store and the service gets created. Looking good. Now, services and not like pods, they don't actually run any of our application code. Basically, there are a bunch of network in stuff, right? So like IP tables or IP VS rules that trap on the use of the services IP address and do whatever networking magic is required to forward or load balanced that traffic to the correct pods that are running our apps. Now like before, and you'll get used to all of this, right? But you can see them with the usual Cube CTL get in Cube CTL describe commands. So there it is, SVCs A101, and they describe gives us a nicely formatted output with a bit more detail. But let's not forget why we created this, right. We said that we never talked to pods directly. We always put a service in front of them and talk to the service. So if you are an application running on the cluster or you know what, you could even have an exact session into an application pod running on your cluster. You would be able to call the name of the service. Ours is SBC 1.0.1 on the services port. Now the internal port, remember was 8080 and you would reach the service. Now, if you're outside of the cluster, maybe you're on your laptop or your an external application client or something, then you just hit the public IP or the public DNS, any of the nodes in the cluster on that port, 30,001, and you'll reach it as well. Well, look, talk is cheap, right? My Kubernetes cluster is in the Google Cloud. So I look up the public IP of one of these nodes. Thank you as always, Gk for your hideously long node names that screw up my columns. And I'll have this external IP though. And we'll put that in a new browser session, 30,001. And there we are as if by magic. Now then look, uh, really don't want to labor the point, but I really, really want you to walk away from this course understanding the fundamentals. So let me be clear, right? This service gets a stable name and IP address on the cluster. When I say stable, right, Kubernetes is super pinky promises that these values will never change while the service exists. The name of the service gets registered with the clusters internal DNS, meaning any parts of your application on the cluster can send traffic to the name of the IP of the service on its port, and it'll reach the service. Once you reach the service, traffic is then load balanced across pods on the cluster with a matching label. But we're not finished, right? Because this particular service that we've created is a node port service. Others do exist, right? But this is a node port service, and that means it gets an extra port, 30,001 in our example that is exposed to the outside world via every node in a cluster. Meaning if you have an external client, like my web browser we just saw, you can hit any node in the cluster on that port and reach the surface. And eventually the application, which like we said, then load balances the traffic, deposing the cluster with the API goes web label, and reach the application. Now, finally, i think right, we can hit any node in the cluster on that port. That node does not need to be running a replica of the pod. Who? Okay, one last thing. So why they're Nigel, do we need to talk to a service instead of directly to pods? Who yeah, great question guide you asked. So imagine this scenario again. Write a bunch of pods on the cluster and you know what, let's lose the ones that don't match our label. Okay, looks like five to me. Let's say the hosting our web front end and demand increases cause whatever, right? We've got a promotion or something, maybe it's Black Friday. Yeah. So we add more to cope with demand. Will, how did the other parts of our app know about these new pods we just added? And it works the same one. We scale down and make some of them go away. I mean, we don't want our developers bloating their code by writing logic to track things like that. Now, so instead we build service. This sits in front of the pods and it offers that guaranteed name, IP and port. So that as we add and remove pods at the bottom here, the service keeps track froze and it literally hide all of the scaling up and down that's going on at the bottom here. Right? So, yeah, like we said about background watch loops before, there's a control loop for the service object in the background that's just sitting there day after night after Day after Night, munching away on popcorn, watching for new pods that match the labels in the service. As new matching pods are added, the service updates its endpoints list. And guess what? As pods go away, it does the same. Always maintaining an up-to-date list of healthy matching pods. Good stuff. And we're done. Yeah. Next up, we're going to talk about self-healing. 13. Using Deployments: Now then so far we have deployed a pod and service. The pot is where our application runs and the service is how we connect to it only. And this grinds on me every time I had the conversation. We never actually deploy pods directly. And here's why write this. Here is a pod wrapping a container and you know what? Literally the only thing that a pod dose first is let the container inside of it run on Kubernetes. You probably remember, we said containers can't run directly on Kubernetes. We've gotta wrap them in a pod. Will magic, that's great. Put pods give us diddly squat. So absolutely 0 when it comes to things like self-healing, scaling, running updates, and versioned rollbacks. For all of that good stuff we need to deployment, which as the picture shows, wraps around a pod. So it's bit like pass the parcel this year. We've got containers wrapping our application code, pods, wrapping our containers, and now a deployment wrapping a pod. And like the picture says, the deployment is what gives us all the good stuff. Well, this is what it looks like. Now, starting down at the bottom here, we've got the same old container right? Unchanged. So we should be getting used to that by now. And then kind of wrapping not we've got a bunch of the pod stuff. So these are the labels that the POD gets so that this service that we created can send traffic to it. Yeah, same as before, right? And then finally, we've got the deployment stuff right at the top here that is wrapping around the POD. Well, going from the top this time we've got our usual scheme aversion and resource kind. So give us a deployment, please. Kubernetes is based on the V1 schema definition in the apps API subgroup. Give the deployment itself a name and some labels. Now these are not to be confused with the POD labels lower down. Okay? But then we get to some interesting stuff. Select a match labels. This here is like the label selected we saw in the services YAML file, right? So it's saying this deployment object is going to manage pods on the cluster with this label API calls web. Then we've got replicas equals one. So when we send this to the API server, it's gonna schedule exactly one pod based on the definition below. Now, that's the scaling bit, right? And we'll come back to it later. In fact, It's actually part of the self-healing as well. But before all of that strategy type is rolling update. So when it comes time to update any of this down here in the pod definition, Kubernetes is gonna do what is called a Rolling Update. Now, I know lots to digest here, right? And will come to each bit in turn. So don't worry, thinking I'm expecting you to grok it all right now, you don't write will come to it all in due time. For now, this is the deployments back here, defining all the good stuff that gives us self-healing, updates, all that kind of jazz, right? Wrapping around a pod, which in turn is hosting a single container. Now then a question I get asked all the time is, can a pod have more than one container? And the answer is, yeah, definitely. But that's pretty advanced use case, right? Where 101 course. So we're just looking at the one container per pod model. But let me just say right, the multiple container per pod model is really powerful and it's leveraged heavily by things like service meshes. Now, there are other things that leverage it as well. But you know what service meshes is a hot topic right now and you know how much we love a good buzzword. Anyway, look, I've got the file locally. If you're following along, you'll needy itself. So you've either clone the GitHub repo or copy and pasted the contents from GitHub into a file. And then it's just our trusty Cube CTL apply command. And I know I'm getting like a broken record now, right? But that goes to the API server, authenticated and authorized, stored in ETC, day unscheduled to the cluster. So Cube CTL just to make sure it's running, which it is, yeah. And then a Cube CTL get pods. Boom. There it is. A brand new pod being managed by the deployment with all the superpowers that come with that, right? So like we say, self-healing, scaling, running updates, rollbacks, all of that, goodness, yeah. In fact, old one-on-one pod here, it's probably filling a bit inferior, but like being stood next to Tony Stark. Yeah. Anyway, you know what, Speaking of superpowers, next up, we're gonna see some self-healing. 14. Self healing: All right, we've got a couple of pods running. This one here is being managed by a deployment. So it's all Tony Stark WAR with superpowers like self-healing and stuff. Yeah. But old 101 part here, that's like me, a bit of an old man with c rho superpowers. I mean, I recently retired from playing football or soccer dependent on where you live. Basically, because my knees have 0 healing power these days. Anyway. One pod managed by a deployment and the other one not. So if we do this here to 101 pod, it's gone right? If we stick a watch on and get pods here. Okay. It's not gone, but it's going to give it a few seconds to do. It is fair to say that is not coming back 0 superpowers. Now then if we look at our deployment here that is managing our remaining POD. What it's saying up here, it's always make sure that there is one of this pod running on the cluster. And it might look pretty simple, right? But believe me, the machinery and the background, like all the watch loops and all the other stuff. Who got Italia? This is the secret ingredient for superpowers. This gives our remaining POD invincibility. Well, sort of we'll see anyway. So if we try and kill it with one of these, take thaws, Homer to it. We'll watch the live action again. Oh, what's this? Look in? Like two containers. And what's all this terminating business authorities had superpowers. Well, what's going on here is that we've just actually killed the pod thaws hammer. Yeah. And as you'd expect with those hammer, the pod died. But what the deployments done in Lockerbie in high level a bit hair, right? But it's created an identical new pod in its place. The only difference actually being this bit on the end of its name here. So one can now write in a way we're kind of cheating. The pod did die and it was replaced with another identical one. So the old ones gone and a new clone, if you like, is in its place. But you know what, from an application perspective, it's not cheating. The application carries on. I mean, your application's not bothered about POD names or anything, right? From the app's perspective, evidence still running. And you know what, right? This is way better when there's like multiple replicas running here and one dies and is immediately replaced. Usually in that situation, the app doesn't skip it beat. Now as well, right? This is the same if something breaks in the cluster, like I know we just did a manual kill of the part of the handwrite bullet. Say a node dies in the cluster and it takes some pods with it. Well, if those pods, Raul Tony stocked up with the deployment. Now panic right? The lost pods get replaced and the world keeps turning, which is brilliant right out lock, you know what? We can even refresh our browser tab here without changing any of the URL. Because what's happened in right is the service object that's doing all of the networking for the Palladia is offering up that super stable endpoint. I suppose we could call the endpoint Tony Stark as well. Yeah, that is guaranteed never to change its invincible, right? And it's always got an up-to-date list of pods that match the labels it's looking for. And obviously the new public got spun up that we just saw there. That's got the same labels. Yeah, so we're all good. And that folks is one aspect of self-healing year. But the cool thing, right? That could have happened at three AM. And Kubernetes fixed it without waking us up off some of that. But you know what, we're far from done next up, scaling. 15. Scaling: So another thing that deployments give us is scaling that ability to say that I need more or less of a particular pod. A thing Gus said earlier, maybe it's the end of the month and report to do so, let's have more pods that support the reporting infrastructure. Or maybe we've got some offers on or something and we're expecting increased traffic. So let's scale up the bits that support browsing and searches in the Likes. Well, if we look at what we've got, yeah, a single deployment called one-on-one deploy and it has got one replica. So the way we scale it up to let say five, to open up the deployment yaml here and look in the real world, right? You're going to be managing this the same way that you manage your code hopefully. So in source control or something, yeah, but you'll check it out and all that jazz, yeah. And then we hope this replicas count here to five. Come up here and we'll save our changes. And then we just reapply that to the cluster and check it back into version control, Of course, yeah. But it's literally updating that Yammer, which is our source of truth, and then reissuing it to the API server that gets registered as a new desired state up from one replica to five. The background control loop notices, hey, we want five, but we've actually only got one. So it spins up for more. And there we have it five pods. Now, we can, if we want scale using the Cube CTL scale command. But I don't think that's the Kubernetes way. And I'll tell you why, right? Doing it like that is the imperative way, not the declarative way. So imagine with me, right, that you manage a Kubernetes cluster with a bunch of apps and there's a P1 going on. Yeah. So it's like red alert all hands to battle stations and you're typing away looking at events and logs and your bosses hanging over your shoulder and her bosses constantly on the phone in his Bedlam, right. But it's great. Yeah. I mean, you've got all over pay one. They're really hard to beat action and excitement. And you know what? You tend to learn a ton. Anyway, look, it's all going down like that, right? You making changes on the fly imperatively. Yeah. Just changing stuff as you go. And let's say the issue and I'm making this up, right, but let's say the issue was the network port that your app is operating on is not working. Anyway, you change the port that you use on the fly. So on the command line without checking out your YAML file, without updating the Yammer file, and without reapplying that back to the cluster. Anyway, so you change the network port on the fly and it is Q celebrations, right? You've been high-five the bosses by new drinks after work and amid all the adoration and general going crazy, you forget that you change the port in live to like 9 thousand or something, put you left. It is 8080 in your YAML file. And the reason this is bad, right? Is because what is live on the cluster no longer matches you. Yaml and Kubernetes has no way of knowing this. Well, let's wind the clock forward a bit and say it's a week or whatever later and you are pushing a new image to the app. So if all you normal procedure, right, because this is not a P1 anymore, so this is all controlled. Yeah. You check out the YAML, you update the version of the image used, and you push the YAML to the cluster. Only. You didn't notice that the Yamaha still says the old port 8080, which is broken and no longer works. So when you redeploy it, yeah, you get you new image, but you also get the old broken port back. A. Now a promise here. What is high-fiving year or buying your drinks this time? So make an imperative changes like that isn't generally recommended. We know what i'm waffling. We've now got five replicas with a background watcher just staring at the cluster all day, making sure that desired state matches our actual observed state. Now, of course, it's the same if we scaled down the number, write, update the YAML, push it back to the API server. Fabulous. Only, you know what, it's all a bit manual, isn't it? I mean, it requires me or you are a human being to do the work. Well, fortunately, Kubernetes has auto-scaling technologies. The horizontal pod auto scaler that can look for how busy your pods are and scale up and down dynamically. And there is a cluster auto scaler that can scale up and down the number of nodes in your cluster. Again, dynamically based on whether there's enough capacity in the current set of the cluster to spin up new pods in the Likes. Now, unfortunately, those topics are beyond the scope of this 101 course. Anyway, lock for now in this one I one cause that is scaling. Coming up. Next, we're going to integrate the app with a cloud based load balancer. Bring it on. 16. Cloud load-balancers: Now then, I'm sorry. If you are following along on your laptop with Docker desktop, or if you're following along with play with Kubernetes, you will not be able to follow this lab. This lab will only work if your cluster is on a public cloud or magic Sandbox as well, which runs on a public cloud. Anyway, minds on the Google Cloud, on Google Kubernetes engine. So I'm good to go now, not being able to follow along. I'm really sorry about but you know what? Just watch. Okay. You're still get it. This is not hard what we're about to do. Anyway, look, we've got a simple app deployed, five replicas here of a simple web server. And we've got a Kubernetes service that is providing stable networking for the replicas. But the type of service that we've got is a node port service, which if we cast our minds back, lets us access our app via a name or an IP from inside the cluster on port 8080, which is all good. But if we want to access from outside, then we need the name or the public IP of at least one of our nodes. Then with our configuration, we hit it on port 30,001 and will come in. That's fine, right. But let's be honest, it's a bit rubbish really. I mean, who wants to keep track of node names or IPAs? Yeah. So a much slicker way would be to fronted all with a load balancer. And seriously, doing that couldn't be easier. In fact, I'm embarrassed at how easy it is. So this YAML here, which is going to look very familiar, It's going to integrate those with a Cloud load balancer. So anyway, look same outside my old API version and kind we know all about those. Give it a name and a label. And then a front-end configuration here saying port 8080 on whatever we get as our Cloud load balancer. And then load balancing out of the backend of the service on 8080 to any pod with the API equals wed label. So we've seen all this, right? The only real difference from the last service we deployed is this load balancer type here. So like I said, if you're on a cloud platform and all the big ones apply AWS Azure, Google, digital ocean, IBM Cloud, you name it right by setting a single word here. Load balancer, Kubernetes is gonna go away, talk to your cloud. Habit provision, an internet facing load balancer that accepts traffic on port 8080 and make sure it gets load balanced across all of the pods running your app also on port 8080. I mean, how cool is that right now, the policy, I don't have too much, right? I think the take-home point is that with embarrassingly little effort, we get a full-on, highly available internet facing load balancer integrated with our app. Again, a freakin, love it. Anyway, look, I've got the file locally. Yeah. Meaning it's time for our old friend Cube CTL apply. Tell it the file and away it goes. Now, if I stick a watch on this command here, probably are akin in less than a minute. And I'm going to edit the video, right? So you don't have to stare at the screen waiting, put in about a minute, these pending value here under the external IP is going to change to a proper valid public IP like that. And we can hit that on port 8080, whom and as if by magic, right, that's our app. So all web app running in a container, wrapped in a pod in turn, wrapped in a deployment on our private Kubernetes cluster, fronted by a Kubernetes service that gives a stable IPN point integrated with a cloud native load balancing, right? I mean, that's a lot of good stuff, right? Put you know what? It is so simple, we're seeing it here in a one-to-one cause. I mean, how excellent is that? I think you'll agree it is most excellent. And you know what, right? Let's not forget that service is constantly watching to make sure it's got the very latest list of pods to balance to o. And you know what, it only load balances to healthy pods. And we are literally scratching the surface. Come on. Hopefully that wasn't too loud if you're listening on headphones. But you know what, we're still not done. I mean, we nearly r, but not quite. One last thing, a rolling update. 17. Rolling updates: Okay, last proper lesson. We've got a simple web app running on Kubernetes, and we've seen itself, we'll scale up and just that we've seen it connect to an internet facing Cloud load balancer. Well, let's see how we can do a rolling update. So as things stand, if we look at the deployment, we should see on the containers, the image version. Anyway, up here we've got five replicas. So five pods running a container based on that image. But let's say we've made an updated image and it's passed all integration tests and the likes. And the last step is to roll it out to the cluster. Well, deployment, do this without even breaking a sweat. And the way we do it is the declarative way. So we go back to the YAML here and c here on the replicas, we've got a strategy Rolling Update. Well actually I'm going to paste these lines in. Alright. So this block that I'm highlighting, this gives us some control over how the rolling update happens. What we're saying is when we update anything in the template block further down, do a rolling update. That means one replica at a time. Men ready seconds here it says, After updating each replica, before doing the next one, wait ten seconds. Now, maybe in the real world you'd say a few minutes or something. The idea though, is to give you some control and let you paste the rollout year. Well, Max unavailable says while the update is happening, never go more than one below what we're asking for. Now. We're asking for five. So never go more than one below that. So nevertheless than for now with maximum available was like two, then Kubernetes would be allowed to go down to three during the update. And likewise for Mac surge, never go more than one more than what we're asking for. Now. You know what, right? There's loads more options including probes and tests and likes that make sure that after you've updated a pod, it's actually working. Yeah. But you know what? First now we've got some Rolling Update settings. And I think probably the one that will say have the most effect is the 10-second wait after each update. But let's come down here and change the image version from 1.So 0 to two. Save that. Now, when we post it to the API server will have a new desired state of yes, five pods. But this time, all five will be wanting to run the 2.0. image, the background reconciliation loop. We'll notice that doesn't match what is actually on the cluster. So it'll fix things only the min ready seconds and the other values that we mentioned will exert control over how the update happens. So let's do this, right? And I've got a command here that will monitor the update that's ready to go. And away we go. Let's run this one. Okay. Look, I'm a, go ahead and accelerate the video in the background because we've got this 10 second cool off period. Yeah. And a promise. It wouldn't be fun listening to me singing to fill in the time. So yeah, Well, look, we can see it's methodically stepping through each replica. Now. It's stepping through two at a time here because max unavailable and Max surge are both set to 11 plus one is two. Anyway, if I start refreshing the browser tab here, we should see sometimes I get the updated version and sometimes the older one. And eventually or five replicas will be up-to-date. An all will get is the new version. And that ladies and gents four rows on 101 course. That will do. Now. Honestly, there's a ton more like it seems never ending. Kubernetes is a vast platform and it is still evolving. And then there's stuff that we've looked at is stable and we can rely on all of that stuff. Put Kubernetes does a lot more and I won't lie. It can be daunting and the learning curve can be hard. Anyway, we've covered a lot. So stick around for a quick recap of the major take home points. Plus, I'll point you to some places that'll help take you to the next level. 18. A really quick recap: Alright, then where did we start? Yeah, we defined what a cloud native microservices app is. It's just a modern way to build a useful application from lots of specialized parts that we loosely coupled using APIs on just because they're called cloud native does not mean they are just for the cloud. In fact, I'd even go so far as to say a tenet of cloud native is probably the ability to run anywhere including your on-premises data centers. I mean, as long as you're running Kubernetes there, yeah. Anyway, we said that Kubernetes is the de facto platform for running cloud native apps. And that Kubernetes is two things. It's a cluster and it's an application orchestrator. So the cluster is like the substrate or the platform, if you will, that we've run our apps on. It consists of masters that run all of the Kubernetes is smart and logic. And it's got a bunch of work nodes where we run our user applications. Now, look, it's irregular world cluster at the end of the day. So we need to think about things like availability and security and performance and all of that. Goodness, yeah. Now, on the application orchestrate different Kubernetes can deploy and manage our applications. For us, we said the preferred pattern is called the declarative pattern, where we define what we want any YAML file. And we'll at Kubernetes do the hard work for us. So the way that works is Kubernetes keeps a record of what we want as something called desired state. And it runs a bunch of watched loops that watch the different aspects of our cluster and our apps. And basically, they are constantly checking that what is running on the cluster is what we want. Whenever observed state strays away from that desired state, Kubernetes does everything in its power to bring everything back in line with the desired state. And what else did we say? Yeah, we said that we write our applications like normal, use Docker tooling to build them as container images and then use Kubernetes to deploy and run them. Now, yes, Kubernetes orchestrates containerized application, which is just techno jargon for applications that run inside of containers. Yeah, only containers can't run direct beyond Kubernetes. First, we need to package them as Potts. Now, we can further augment pods with lots of things, right? But the one that we looked at was the deployment. And that gives pods superpowers, Yeah, like the ability to sell, fail and scale and even do 0 downtime updates. And that was those. That's all we've got time for. But oh my goodness, there is so much more. But it is a great time to be learning Kubernetes. Now, if you like books of God, somebody might like Quickstart Kubernetes, ESEA is at about the level of this course. But if you're ready to move to the next level than the Kubernetes book here is regularly listed as a bestseller on Amazon and it's got the most star ratings of any book on Kubernetes. Oh, and it's updated annually, so it is always up to date. Now, you can get it as an eBook on Kindle and Leanpub, a paperback on Amazon. There are Spanish, simplified Chinese, and Russian editions available and an audio version, but that's just an English. Oh, my goodness. Do you know what? There's even a cling on tribute addition. No joke though. The Klingon edition, it is just the front cover and the intro that are in calling on the rests in English. Anyway, look, time is short and I'm starting to waffle. Feel free to connect with me. I'm a can't be free tech support, but I am more than willing to connect and help you work you first steps. So don't be shy. Let's connect anyway. Look, thanks for spending your time with me. Good luck with your career. And like I said, keep in touch.