Kubernetes from 10,000 ft: Pt 1 – The Anatomy of Kubernetes

0:08 hello and once again here we are with a webinar from appvia i’m i’m tennis smith at the apvia world 0:15 headquarters it looks like i’m in jail i’m not actually in jail i’m in a room with a nice 0:21 screen on it um and this is salman who’s in sunny cardiff 0:26 uh and you might want to introduce yourself some and talk about your background a little bit for those who are joining us for the first time and 0:33 don’t know much about either one of us of course 1:17 and i’m tennis i’m tennis smith i’m uh was a technical architect now i’m going to be pre-sales here at uh appiah 1:25 i’ve been in the business a long time too many years to count i’ve been working with kubernetes now for three or 1:31 four years and between the two of us we’ve got quite a bit of experience with the technology 1:38 and we’re here to talk about kubernetes from ten thousand feet uh in other words just a brief overview 1:44 of kubernetes and what it is and so uh simon do you wanna share your screen with the 1:55 oh yes the housekeeping 2:08 yes yes 3:35 nice just fine salmon 4:37 sure 4:46 yeah you’re just fine guys 5:06 yes sir 5:22 yeah we’ll want to make sure that the audience can certainly uh understand us before we 5:28 continue on yes yes 5:34 can can somebody ask i mean excuse me can somebody post a question uh whether 5:39 or not they can now hear salman i can hear him just fine naturally but 5:45 it’s more important that the audience can hear him 5:59 that’s right uh if you want some and i can go ahead and 6:04 yeah yeah uh what we’re going to talk about is um 6:10 pretty much three areas we’re going to talk about the the the old classical way of doing things which 6:16 is monoliths and the new paradigm which is microservices and that gives rise to 6:21 the concept of containers and uh oh they’re saying they’re still they’re saying they still can’t hear you 6:27 yet salmon all right well 6:39 okay 6:47 okay all right it’s a yes um what we’re going to talk about is 6:54 as i was saying is initially the concept between a monolithic application and how that’s done a pre 7:01 kubernetes then the concept of microservices and then after that the the the the 7:09 concept of a container and what it is and then we’ll talk about kubernetes and how that is a technology 7:16 that coordinates containers um and this is while salmon is rejoining 7:22 i’m afraid i don’t have any graphics to show you but if you think of it in in these terms that you have 7:28 in the old days an application that had to have all of the 7:34 uh various and sundry uh 7:40 reactions built into the application itself when i say reactions error recovery networking 7:48 security scalability all of those things had to be programmed inside the application itself 7:55 so what you ended up with is a monolithic app that tried to do everything for all time 8:02 uh and react to all situations that’s what i mean by reactive 8:07 along comes the concept of microservices which is where you break down the large 8:13 application into smaller components that would be networked together 8:20 and then you would be able to isolate your problems excuse me 8:25 and in such a way that it it’s no longer one giant uh code bed you would have lots of little 8:32 code bits um the the problem though 8:38 is that those little applications talking to each other through a network 8:44 makes certain things more complex like testing for example and we’re going to go over that 8:51 again i don’t have the graphics at the moment but hopefully you’re following along with me 8:57 that gives rise to the concept of containers and containers are a way to 9:04 shrink wrap so to speak a very small piece of 9:11 well shrink wrap only the things you need the libraries the file system 9:18 the utilities and the application itself 9:23 in one small entity that can be run 9:29 in its own namespace inside an operating system 9:34 and excuse me and it’s isolated from all the other containers running in the same operating system 9:40 and we’ll talk about this a little bit more um in 9:45 in much more detail with a graphic to give you a better idea but the idea of a container is as you 9:52 like i said you have the shrink wrapped components and only what’s needed to run so 9:59 if you think about it when you run classically when you run an application 10:04 inside of a virtual machine or on your laptop or wherever let’s say for example you’re running 10:11 microsoft word you are actually only leveraging a small 10:16 percentage of what’s inside the operating system at any given time you’re using word you’re using some 10:22 subservient libraries and you’re using keyboard interrupt handling and that sort of thing and that’s about 10:28 it the rest of the operating system is sitting there not exactly idle but it’s 10:34 using unleveraged facilities what a container does is this is a way to say okay i only want the application 10:43 i only want its subservient libraries and i want them encapsulated into a single entity and i want it saved off 10:49 into what’s called a container image and then you run that image and that image can 10:56 converse with other containers and they’re standalone entities so what you have is a collection of 11:03 containers that are talking to each other well here is the problem with that 11:08 the problem with that the problem with that is 11:14 the let’s see i’m just getting a message here 11:22 the problem with that is that you have to coordinate among those containers and coordination among 11:28 the containers is difficult you need some overarching up there’s iqbal because 11:34 salmon mr well sorry can we can we try to see if they can see 11:40 can you hear me can you ask people if they can hear me now yes um salman has rejoined can people um 11:47 indicate whether or not they can hear him now let’s see uh 11:53 let’s see if that works the slides i’ve sent you the links to the slides tennis oh thank you slack so 12:00 if you can if you can just open them up and share them yes sir i shall i shall 12:05 maybe kirsten can let’s see if people are messaging or not not yet let me 12:11 tell us there’s the slides for you so maybe you can share them yes sir i certainly will 12:18 all right people can hear me now oh okay i’m not 12:24 sure what happened there people apologies apologies but we’re good to go we are good to go so 12:31 um okay oh thank you very much uh not sure what happened there but you know thank you for joining us thank you very 12:37 much so last thought yes please go ahead yes sir let’s go let’s go sorry about that 12:43 no you know we still gotta have fun go tennis you continue i’m not sure 12:49 where you were oh i was just talking about uh um well first of all we haven’t talked Who is Appvia 12:55 about who appvia is and and uh we are a company that uh offers uh an 13:00 enabling technology for kubernetes without going into great detail just yet and we 13:08 we have technology that enables a lot of efficiencies we’re using things like 13:14 multi-cloud so go ahead to the next slide Monolithic vs Microservices 13:20 okay so monolith versus microservices this is what i was alluding to before 13:26 uh do you want to pick up on this one salmon absolutely yes so i mean i’m sure we’re 13:32 all aware or what we’re doing right now which is we have sometimes we just have one 13:38 massive application or one big solution everything goes in the application we’ve got the business logic the ui the api 13:45 the authentication every piece goes in that and all the testing is written in that case and then 13:52 over time you start to realize that that’s perhaps not the best thing to do because if i want to make changes to an 13:57 application one part of the application maybe the ui i have to ch release everything again 14:02 after regression test everything again becomes a bit of a problem and then what we 14:07 decided as uh as technology that maybe what we can do is probably break things up into smaller 14:13 chunks and they’re independent of one another so we can scale them separately we can 14:18 release them separately the teams don’t really have to rely on one another to say oh um we’re releasing next week can 14:25 you make sure we haven’t broken anything so that’s what the the microservices architecture we’re 14:31 moving towards um anything you want to add attendance on that or will be good no it just 14:38 yeah the main thing is that you went from one big application trying to do everything to lots of little applications that are 14:45 cooperative amongst themselves and that leads to the martin fowler uh 14:51 quote that it’s an architectural style is developing a suite of small services 14:58 and presumably they would be lightweight in character the the idea is that you would not have 15:04 huge pro huge uh apps talking to each other you want lots of little apps you know just a few lines of code talking to 15:10 each other correct and they talk to each other using rest requests they’re perhaps sending some rest requests and monoliths vs microservices 15:17 responses uh i mean we put some some of this up by the way you you will all receive the 15:22 slides so you don’t have to frantically make notes about any of this stuff there’s just some discussion points between monoliths 15:29 and mic services as we were talking about previously really briefly if if i have a monolith i have to make sure if i 15:36 make a change in one part of the application we haven’t broken anything else in the other part of the application 15:43 but in terms of microservices pretty much every component is independent as long as we don’t 15:48 break any of the contracts between the services we’re doing okay so we can 15:54 independently deploy them update them you know move move a lot faster than we 15:59 have to because we don’t really have to sync with the other teams to try and figure out oh should we release this should we release that 16:05 and um should we release our features next week or whatever it might be and i think one 16:10 of the most important things um in my opinion is that uh back in the day when 16:16 i used to work in monoliths if there was an issue in the back end service let’s say the back end logic there was a 16:22 problem with that even the ui would stop working right because everything is part of the same application um 16:28 and then you can’t really serve a a reasonable error page to say oh please come back because we’re having an error here or 16:35 whatever it might be so you know failures can one 16:40 if one part of the application goes down it will definitely take out the other parts of the application because it is one bit 16:46 then in our case in microservices everything is self-contained right so if my back end fails that’s fine the front-end can still 16:52 uh you know give me a reasonable answer maybe maybe if it’s a bank application a loan service is failed but accounts are 16:59 still working so that’s fine we can at least work in in that way and i think one of the last bits i would really 17:06 say with with the microservices architecture we can have whatever 17:11 framework we want to use let’s say you say oh the front end is very good if i can write that and react and let’s say 17:19 you might say oh i need to write some business logic and that really works well with either go or if i’ve got 17:25 something just you know i need to do some bit of machine learning in some parts of you can write that in python and that’s 17:31 absolutely fine because everything is separate we would do that with single development stack for monoliths that was 17:38 kind of hard to do anything you’d like to add tennis yeah it’s just a really uh interesting aspect 17:44 what you just brought up which is let’s say that the ui was written with react like you said and you know next week we 17:51 decided to write it in a completely different package well we just have to modify that one 17:57 microservice or the back end for example we used to be talking to mysql now we’re going to be talking to 18:04 another database uh that’s one microservice that you change and if assuming that the the rest api 18:11 conversations are honored in their contracts the user doesn’t know that and you can just swap them out crosscutting 18:17 absolutely absolutely but it’s not everything is rosy right yeah 18:22 tennis because we’ve got we’ve gone from monoliths to 18:27 microservices and there are some use cases in which the model might make sense uh of course you know there’s a 18:33 tool for everything but now we have a distributed system which we didn’t 18:38 have before right we didn’t have all these components that perhaps deployed in different machines or working 18:44 differently so we’ve added a bit of extra complexity on top of what we were doing before because now i have to start to figure 18:50 out like how do these communicate with one another and when i’m doing some development how do i 18:56 test everything just to make sure everything works fine you know and also like one of the 19:02 things i put we put in here is cross-cutting this is all about i’ve got all these different micro services 19:07 how do i collect the log from all these services and more importantly these services could be written in different 19:14 programming languages so if i collect logs where do i get the libraries from and how do i make sure everything is exactly the same and also 19:21 you know if there’s a circuit breaking or you know fault tolerance how do i do all of that so we started to add 19:29 challenges on top of what we had before uh tennis would you like to add anything more 19:35 no sir that’s that’s uh that’s nothing for that yeah so i think patterns 19:41 so there’s patterns out there uh that help you with some of these challenges for 19:46 microservices um then one of the patterns is the 12 factor apps 19:51 i’m just we’re just going to put it out here we’re not going to go into too much detail about the 12 factor acts but 19:57 basically this if we put six with it there are 12. but these are things we 20:03 can do to make our lives a bit easier when we’re working with microservices 20:08 for example number you know one codebase money deploys so you have one codebase you 20:13 check all the code in and you can from that single code base you can deploy multiple services multiple market 20:19 services you can deploy them in different environments uh you know such and 20:25 so on and so forth the second one which perhaps will become a bit more useful when we talk about containers about 20:30 declaring dependencies i mean there have been times where you’re working on an application 20:36 and one person has developed this application and they tell you oh can you try and test this on your laptop or on 20:42 your machine are you trying to run the application on your machine it could be written in java could be written in python could be 20:47 written in dot that could be written in any language and when you do that things don’t work you test it out and 20:54 like oh things things are not working what’s going on and then you realize they installed a dependency on the 20:59 machine which didn’t which wasn’t on your machine so this is this is a bit about declaring 21:05 dependency it doesn’t say how you declare the dependencies but it just says you make sure you declare all the dependencies 21:11 and i think i’ll i’ll add one more and i will get tennis to add his his points as well like one of the things that 21:18 all of us try to strive is to make sure all environments are similar 21:23 not the same but at least similar for example the dev has to be similar to what the uat should be or 21:29 what the production environment should be and the only reason why we say they should be similar this 12 factor apps 21:35 says it should be similar is because it’s easier to replicate any issues that you might come across in 21:41 production if the dev is so far away from what production is it’s going to be hard to figure out what 21:47 happens when the activation actually lands in production this should what we don’t want is surprises we want 21:52 surprises in dev i don’t know a set environment or uat environment we don’t want any surprises 21:58 in production environment so that’s why we want to keep them similar anything tell us 22:05 yeah exactly you you strive to keep the environmental simplicity as 22:12 as generic vanilla however you want to put it as possible 22:18 and to carry on with the list here you want also your application to be 22:24 stateless in character on the whole now there are some exceptions to this but for the most part what you want is an application that does not have to have a 22:32 lot of uh data retained to tell it what state it’s 22:38 supposed to be and when it comes up that it just comes up and it reads from a queue and that then and processes what it has 22:44 it doesn’t have to to read you know special databases and things like that 22:49 um also which reminds me the fifth point about configuration in 22:55 the environment what you want to do is to try to keep all your your configs in environment variables 23:01 that are passed at runtime to the app as it comes up so that way you can change let’s say you know how 23:08 many threads you’re running in a configuration statement without having to 23:13 uh to do stop and start and those kinds of things 23:18 and finally you want you want a microservice to have fast startup and 23:25 a graceful shutdown in other words you want it to be resilient in the sense that the application 23:32 doesn’t cause problems if you bring up new copies or if you shut down unneeded 23:38 copies um i notice i’m going to am i missing anything let’s see no no absolutely yeah so i think yeah i i 23:45 think it’s i mean there’s more parts but yeah the fast startup is important as well because let’s say your 23:50 application’s running normally and you want to scale up from i don’t know you got five replicas 23:55 running and you want to go up to 100 replicas uh yes and you want to you want to do that really quickly and that’s why 24:00 this part start this far startup is is useful and graceful shutdown it’s just we just don’t want to lose any traffic 24:07 if something something goes wrong right so that’s um that’s what it is um virtual machines 24:12 there’s we could we used to deploy our applications you know we still are deploying 24:18 sometimes our applications in virtual machines and that’s absolutely fine because we just need some resources to be able to 24:24 run them and the thing with virtual machines that i think the diagram will see on your left is 24:30 in the virtual machine you have this technology called the hypervisor which allows you to separate you know 24:35 which allows you to divide a server actual physical server into 24:42 multiple machines multiple virtual machines and that’s absolutely great right 24:47 because i have a machine i have one actual server and i can make it make into smaller virtual machines and i can 24:54 give them to different teams and they can do what they want to do with it and there’s good security isolation because 25:00 whatever happens in one virtual machine doesn’t affect what happens in another virtual machine it’s like as if they are 25:05 actual machines but the only problem or i mean we can’t see the problem the challenge is that 25:11 when i have this virtual machine each machine has to have its own operating system or we call it in in this case we 25:18 call it the guest operating system that you might say that’s fine that’s okay and it seems 25:25 like okay of course i need a bit of an operating system to be able to run it by but that takes about 10 of the resources 25:32 sometimes on that virtual machine to be able to run just the operating system 25:37 and if you add that imagine you have 100 virtual machines and 10 of each of those 25:43 if you add it that adds up to i don’t know however much cpu or memory resources it is that basically adds up 25:49 to some resources that you are just using to run this guest operating system on the other 25:56 hand we have the containers and the containers say you don’t have to have this guest operating system all you need 26:02 to have is container engine you know your dockers or your container d your run times 26:07 as long as you have that you don’t have to have the guest operating system the the container engine will take care of 26:13 it and whatever the host operating system is on that machine it basically uses that 26:18 in order to spin up your applications inside the container tennis would you like to add anything on 26:24 that yeah a couple of things um the the the diagram on the right 26:29 alludes to what i was talking about before which is you know shrink wrapping only those things you need 26:35 to run a particular application and you share actually the operating system kernel and 26:42 can have apps one through three sitting there and it’s much more 26:47 efficient than having an entire operating system as you have on the left just to run one application 26:53 so the the the benefits of the approach on the left 27:01 is a much greater efficiency of operating system leveraging 27:07 uh and a much more bounded collection of things that you have to 27:13 manage in the form of that container as i said that shrink wrapped piece so 27:26 no i think uh i think that’s uh that’s a good point uh as we as we just talked about there’s some limitations because limitations 27:32 you have to use some of the resources for virtual machines and i think one of the things that we haven’t talked about is 27:38 if i have a virtual machine in azure it doesn’t work the same virtual machine won’t work in 27:44 gcp google cloud platform or aws you kind of have to like recreate it 27:49 so basically there are some limitations there are some limitations for for the application but on containers i containerization 27:56 don’t know uh tennis we want to talk about this slide here real quick yeah this is this is um um the process 28:03 of containerization and this slide is meant to depict uh the fact that you are taking only 28:09 those little components that you need in order to run that one application and your your uh extracting it from a larger 28:18 context and saving it off as a container it says the the the graphic says container but 28:24 it’s technically container image and that’s only that’s the only thing that now you have 28:30 to uh manage so all the overhead of the operating system 28:35 and the libraries and the maintenance that what goes with the operating system all that goes away 28:40 yeah i mean you still have to update the base operating system system of 28:46 container when you need to this is another depiction of the same thing using the container you have some sort container image 28:51 of a file system and on that you you do use an operating system of one con 28:58 a piece of the operating system these are the operators not the full thing the piece of the operating system and then 29:03 you have a bit of storage and all you do on top of it you put all your files in and all your dependencies and you 29:10 package it all together into a container and that becomes like i know sometimes this term 29:16 container and image is used interchangeably image is basically a container that’s not running it’s just 29:22 there and a container is basically a running image but i think the takeaway for containers is a 29:29 a container is some sort of uh i think runtime is probably a better term to use 29:34 than an operating system some sort of a runtime let’s say you want to run a java application you have java virtual machine or let’s say you want to run 29:41 python and python runtime your application code so all your code and stuff in all your 29:47 configuration files all your application and any of the dependencies that you are using they’re all defined and they’re 29:53 all included and this goes back to the point that we’re tennis and i were making earlier on in this uh 12-factor 29:59 app one of the things you have to declare your dependencies in order to create a container you create it using 30:05 this file which is called a docker file imagine if you’re using docker and in there it’s just instructions of 30:11 how to install your applications and then basically we’ve got containers which are running and i had just some of container benefits 30:17 the benefits we put on here um depending on uh what we you know what 30:23 kind of container you’re using it’s quite lightweight you can get started really quickly you can stop it really quickly there’s no operating system we 30:29 have to boost boot it’s just the runtime and i think the most important bit is we 30:35 have standardized the way we package and run software so for example 30:42 let’s say if you want to run you know i don’t know net application or a go application on your laptop you need to 30:48 make sure all the frameworks are installed all the things are installed correctly but if i have a container it doesn’t 30:54 matter what the container is i can just do docker run name of the image and it will just run 31:00 so this this you know this standardization of packaging and it’ll run anyway the container will run exactly the way it is running on my 31:06 laptop will run on the our different server will run on uh 31:11 tennis’s machine will run everywhere it’ll run on azure it’ll run on aws 31:16 absolutely absolutely you want to add anything tennis no no that’s that’s that’s pretty much covers it i think 31:22 yeah and you know we can if we are running containers we can try and run multiple containers in a machine and container terms 31:28 basically uh try and save some resources to containers are useful for 31:33 reproducibility we can take them and run them there’s some of these terms the keywords that you might have come across 31:39 before uh like an image and a container we talked about it really briefly images 31:44 just contents of a docker container risk all it includes is a runtime it includes 31:50 your files all your files that you need to run your application and any other dependencies and then the 31:56 container is when you start running the images by the way if you have any questions please feel free to use that 32:02 ask a question to add them and throw in we’ll we’ll try and answer them apart from that you can’t hear me you know 32:09 which was where apologies for that but i think we’re good here and then a couple of 32:14 other uh keywords in terms of uh if someone talks about a container runtime or an engine this is the bit that 32:21 actually people use to start the container or stop the container or build it and then 32:26 if you have containers and images we need to be able to share with others how do we share them we use registries 32:32 think of uh you know like the registries for your dependencies where we store dependencies and stuff and usually we tag an image 32:39 with uh with a version of one sort of another so some of the terms 32:45 but tennis if you want to ask this next question yes um 32:50 that’s containers are wonderful but what happens when you have lots of containers and those containers are 32:56 talking to each other and some of them are coming up and some of them are dropping and some of them 33:02 need to talk to a container on another virtual machine what do you do and that’s where 33:09 excuse me that’s where the concept of uh 33:14 container coordination comes in what happens when you have this situation where you have lots of Kubernetes 33:21 containers and the need to coordinate among them and to scale them 33:27 and to load balance them this is where we introduce the kubernetes 33:33 and kubernetes is as it says here it’s an open source system for 33:39 among other things automating deployment scaling and management of containerized applications 33:45 and think of it as an overarching scaffolding for 33:50 coordination among containers and it’s referred to sometimes as kate’s 33:56 k followed by eight and followed by the letter s because it is k and eight 34:02 letters and s just as an abbreviation um anything you’d want to add uh salmon 34:08 yeah and i think it’s important to also mention that uh the these these things are called container 34:15 orchestrators and kubernetes is not the only one there’s there’s there’s a few more you know there’s uh 34:21 hashicorp nomad and uh um i can’t really think of others because i have them on Container Orchestrators 34:26 the slide here no there’s docker swarm there’s docker swarm and you know there’s some others but 34:32 uh we are focusing on on kubernetes because kubernetes has taken the market share a lot more than the others but 34:38 that’s what we’re going to focus on and yeah these container orchestrators for example kubernetes help with a with a 34:44 lot of things um yeah so you can see the market share for for communities is a 34:49 lot more than some of the other ones you know we’ve got docker compose we’ve got mesos and i mean we’ve got some some of 34:56 the other ones as well so this this is why we are you know kubernetes seems to be like the the 35:02 container orchestrator of choice and so what do you get with with kubernetes uh one of the things 35:08 that we we want to do with our applications is avoid downtime avoid downtime when something crashes or avoid 35:16 downtime even we’re doing updates and this is where kubernetes comes in it helps us with if you’re doing new 35:22 deployments it helps us uh to make sure that we can do rolling updates so we don’t have to take the old one down 35:28 until the next one ends up and that’s where kubernetes is kind of is very very powerful in that sense when you’re 35:34 rolling out new updates if there’s any breaking changes there’s there’s there there are techniques for 35:40 that but also if something if one of your container crashes one of the things that uh tennis mentioned what happens if 35:46 the containers die well you know i don’t want to be woken up at 2 am in the morning and logging 35:52 into cells and starting and stopping the containers and that’s what kubernetes does it will go in and 35:58 it’ll start things up what they’re supposed to be running because it knows the state of the 36:04 cluster at all time and it knows what the desired state of our applications in the cluster 36:10 should be it stores the information and once that stores the information it will always strive to go towards the 36:17 the desired state and we’ll look in into that in more detail next week of how it 36:22 does it what it does um and it’s quite you know that’s how it does self feeling and also i’m gonna i’m 36:29 gonna talk about scalability and then tennis is gonna talk about the bits at the bottom i think that they’ll kind of make sense in here oh yeah um 36:36 in in terms of scalability what kubernetes allows us to do is automatically not just scale the 36:42 applications also scale the cluster if our cluster is too small or 36:47 what a cluster rate so far if we haven’t got enough resources to run an application what kubernetes will do is 36:54 you’ll spin up more resources spin up more virtual machines and attach the cluster 37:00 uh yeah so tell us what about the infrastructure abstract abstraction and development yes 37:07 yeah the interesting thing about kubernetes well let me start with developer velocity basically if if you have a 37:14 kubernetes infrastructure uh configured you can turn around your application 37:21 changes very quickly so the developer doesn’t have to have a lot of understanding about the 37:27 infrastructure they can have just a pipeline to install an app and update it as they need to and 37:34 can do that very rapidly so you can deploy quite quickly on kubernetes without having to worry about uh you 37:41 know do i have to do something a little bit differently because i’m going to be uh 37:47 bringing it up today versus tomorrow and you know there’s there’s no issue with uh trying to make changes to the 37:54 infrastructure the infrastructure is just there so the developer can concentrate on just developing the application 38:01 as far as infrastructure obstruction is concerned what’s interesting about kubernetes is properly implemented kubernetes running 38:08 on azure versus running on aws versus running on gcp are all interchangeable 38:15 in the way the excuse me the applications developed for one would be interchangeable from the other 38:20 so that the the kubernetes environment is abstracted away from the hardware and 38:28 for that matter the provider that’s underneath so as a consequence you have 38:33 a greater chance of portability now you can always write applications to make them providers specific i mean you can 38:39 always include certain things to make them provider for specific but if your goal is true portability 38:46 you can absolutely not have to worry about the infrastructure on which kubernetes is 38:53 running it’s its own ecosystem if you write it for one kind of kubernetes it will run on kubernetes on aws just as 39:00 well as azure finally kubernetes is set up in such a way that 39:06 it leverages the resources that it has is very efficient efficiently it will 39:11 not uh it will uh use 39:16 to the fullest the vms that are associated with east with 39:22 uh with kubernetes in such a way that you you don’t have to constantly try to play catch up with resizing your 39:29 environment for kubernetes now long term of course you have to watch the metrics and that sort of thing but my point is 39:35 is that the metric the environment that you do have it very efficiently leverages anything you’d want to add 39:40 salmon yeah no absolutely i think you tennis has mentioned all this stuff and 39:45 this infrastructure abstraction is something which is which is great right so a lot of times that you know we 39:52 people think about we don’t want to be tied into one cloud provider or another um 39:59 well that’s uh that’s absolutely fine of course this is something that everybody considers when 40:04 when they’re working on the infrastructure and that’s the good thing about kubernetes if we write our applications 40:10 for kubernetes we can run them anywhere i can run run it on my laptop and i can 40:15 run it on on aws i can run in gcp i can run any of those cloud providers that allow me to Kubernetes Applications 40:22 run that and those things don’t change so what does a kubernetes cluster 40:27 actually look like well looks kind of like this we have imagine you have machines Kubernetes Clusters 40:34 and they could be actual physical machines they could be virtual machines they could be raspberry pi’s they could 40:40 be anything as long as they provide memory and resources that’s what a 40:45 kubernetes cluster requires it needs some memory resources there’s some minimum requirements how 40:51 much memory they can have and the way we set this up is we have a cluster in the cluster 40:58 it can include basically one or two things it can include a control plane which is the bit that’s in charge and 41:04 we’ll look into the control plane next week as to how it does that and then the other bit is the actual 41:09 worker notes and the working nodes of the bit where we actually deploy our containers they get deployed into 41:15 into the workloads and the point about a kubernetes cluster is i can have as many worker nodes as i want there are 41:23 some restrictions in cloud providers they they might not depending on the network setup they might only allow you 41:29 200 machines in in a node but in a cluster sorry 200 machines in a 41:35 cluster but the point is you can have as many machines as you like they can be of any size they can be a gpu it can be a 41:42 cpu could be anything you like and also if you want it for resiliency you can 41:47 even have multiple control points and that’s what aws does by default 41:52 if you ask aws to give you a kubernetes cluster it will actually 41:58 spin you up three control planes and each of them will be deployed in different availability zones so if one 42:04 availability zone goes down you still have a control plane that’s that’s up and running and this is basically what a 42:10 cluster looks like and every time we deploy our resources we are communicating with the control plane and 42:15 we’re saying can you deploy this pod or this application or whatever it might be and that that takes our our thing and 42:22 actually deploys into uh the work announced and we’ll look into that next week 42:27 is that is that anything else you want out of tennis uh no Kubernetes Containers 42:32 well a couple of small things yes just uh um when you see on the left control plane the the that’s also a separate 42:39 machine or machines as simon pointed out uh so and the graphic that we’re using 42:46 which which is the profile of a whale with little boxes on top of it that’s the uh graphic for a docker container so 42:54 if you’re confused by that basically think of that as just know the whale with the little containers on that’s just a docker container 43:00 that’s all i just wanted to add that to make sure it was clear yeah absolutely thanks uh thanks for 43:06 clearing that up yeah it’s just running containers but um so a couple of things what are the features Kubernetes Features 43:13 i think so this is one of the last things we’ll discuss in in terms of what we’re going to be talking about what 43:19 does kubernetes help us with and then uh um yeah if you have any questions feel free to ask us i think the important 43:26 also thing the second part of this is next week so definitely do dial in next week and we’ll show you how you can 43:31 deploy your applications in your kubernetes cluster and explain some of the other concepts that are in kubernetes cluster so one of the things 43:38 that we have to do if you know if you don’t have a an automated 43:44 you know container orchestrator is for us to log into machines and say 43:49 i’m going to deploy this application this machine i’m going to deploy my database and that machine and this 43:56 application that machine but with kubernetes kubernetes says you don’t have to worry about that 44:01 you just give me the container and i will decide where it gets placed so it does automate scheduling and it does 44:07 that based on what your requirements for the application are and it’s quite smart 44:12 for example if you have multiple replicas of an application that needs to be deployed in the cluster it won’t take 44:19 all of them and deployed on the same worker note because if that worker node goes down we’ve lost the application 44:26 so it will do and just start distributing the workload it will deploy one of them in the first node maybe the 44:32 another one in the second node and what it’ll try and do is based on what your requirements for the application are the 44:37 the uh the cpu and memory requirement it will try and pack it as close as possible to 44:44 make sure your virtual machine utilization or your machine utilization is high you’re not losing out on much 44:52 um that’s what the the automated scheduling is it’s quite advanced in a sense that you can customize it too 44:59 and one of the things that kubernetes also helps with is that the concept that we talked about earlier on if any time 45:05 my my application crashes it can bring it up without any issues 45:10 and then before tennis talks about auto scaling i’m just going to mention this automated deployment 45:17 in kubernetes you can deploy your applications as part of what’s known as a as a deployment which 45:22 we’ll talk about next week and deployment is just a recipe of what your application looks like how many replicas 45:28 it wants to run what container is running what are the environment variables it needs to use 45:33 and if i say i need to have three replicas running at all times and one of them goes down it will bring it back up 45:39 and also i can release i can make releases in an automated fashion i can do a rolling 45:46 update so if i’m going from version one to version two what kubernetes does is it brings back 45:51 version two brings up version two first and then it says yeah everything is looking good some people start going to 45:58 version two and it’ll start killing some of the possible version once just so you don’t have any down time 46:04 and there’s other different types of uh deployments as well you can do a green blue deployment you can do a canary 46:10 deployment um and in a canary deployment you send some traffic to the older application and 46:16 some traffic to the newer application see how everybody’s doing it is are we getting any errors and if you’re all 46:22 happy you can switch over all the traffic to the new um to the new application and in a green 46:28 blue deployment we basically uh can have two applications running at one time and if there’s a breaking 46:34 change and we want to switch from one to the other we can switch it really quickly uh what about auto scaling 46:40 tennis auto scaling is is a really interesting aspect of kubernetes you can define 46:47 how many minimum and maximum copies of a given uh 46:52 well i’ll say container it’s actually a pod but let’s say container for the sake of argument how many copies of a given application 46:59 can be running at any given time and when there is traffic to justify it 47:05 make new copies to to accommodate that so let’s say you’re running with a 47:10 minimum of two copies of an application and then suddenly there’s a lot of traffic coming in 47:16 you can auto scale that or you can you can arrange kubernetes 47:21 and then auto scale automatically to say 10 copies and then when the traffic volume drops down it goes back to two 47:29 copies so that’s a very powerful feature that once again like salman was saying you don’t have to get up at two in the 47:34 morning to bring up new copies just to accommodate new traffic uh kubernetes has the hooks 47:43 such that it will accommodate that for you and that leads to load balancing which 47:49 is a high availability feature so that uh so that you can 47:54 take your traffic and judiciously 47:59 balance it across different applications so you don’t overrun one application and 48:05 you can have you know three or four different things accepting data at the same time and therefore balancing all 48:12 the work across different worker nodes if you like 48:18 and excuse me and we talked about infrastructure abstraction before i don’t know that there’s really 48:23 very much to add to that other than to say that um 48:29 you can have a generic environment and that it it as 48:34 long as it’s designed to work in kubernetes it can work in kubernetes anywhere um and just like salmon said it 48:41 could work just as easily on a raspberry pi as it would on aws uh anything you would add to that salmon 48:48 yeah i think um like in terms of auto scaling you mentioned about the application over 48:53 scaling also cluster auto scaling you have mentioned it before we can we can define we can define metrics say if if if an 49:01 application if a container takes like longer than two seconds to respond scale up and that’s how we can we can do 49:08 this scaling up so that’s what uh the different features of kubernetes are and Summary 49:13 uh be sure to join us next week on in terms of we’re going to dive in a little bit more 49:18 detail of what all this is so i think a bit of a summary uh as we said we’ve 49:24 been talking about today about how containers can help with with microservices we can you know we we can 49:31 microservices produce a lot of challenges and we want to be able to run all these things together and 49:36 orchestrate them and start them and stop them we can stick them in containers to make sure we can run them 49:43 always without any issues and we can run them in different environments and then we would talk about how you have containers 49:50 and managing multiple containers is a bit of a problem in terms of if all of them go down how do i bring 49:56 them back up and what about if something happens to 50:03 a machine that so our container is running in one machine it needs to talk to a container that’s running in another machine how do we do that communication 50:11 that’s where kubernetes helps and we’ll talk about a number of kubernetes benefits which was um different things 50:17 in terms of auto scaling auto scheduling and uh self recovery or anything because 50:23 that goes bad it can start the containers and also in terms 50:29 of what happens if you know we want to do a deployment with without any 50:35 downtime and this is which is to help go and we’ve got a question come in uh 50:41 actually a few questions okay and i’ll i’ll read them out and then we can we can take them online 50:47 how easy is it to implement this on a small scale um 50:52 for learning purposes they’re asking and what kind of applications would you recommend deploying on 50:58 uh deploying to them to learn how to work with kubernetes um so that’s not that’s not all but we 51:04 can we can we can start with that um you can deploy kubernetes on your laptop MiniCube 51:13 uh if you would like you can also deploy kubernetes on raspberry pi’s there’s a very yes mini cube runs on 51:20 your laptop uh is a wonderful uh uh 51:25 learning tool um so there there are several out there if you go to 51:33 excuse me if you yeah if you if you want to do it for like learning purposes i highly recommend this mini cube if you 51:39 just like make a note of that mini cube stuff you can go in there or you can do a kind and what mini cube does is 51:44 basically spins you a virtual machine that virtual machine just one mode is your control plane and 51:51 it’s your um here’s your working note and everything gets deployed on there and kind is 51:57 kubernetes in docker actually spins up kubernetes inside docker so you can definitely use this on a small scale and 52:03 run them there now what kind of applications you should deploy if you if you want to learn i’m just going to give 52:09 a shout out to coda uh just make a note of me make a note of this stuff the scatter code is 52:15 this is a great platform by the way if you if you if you’re doing it for learning purposes it will spin you up a kubernetes cluster 52:22 inside the browser well it actually spins up in a virtual machine that you don’t see but there’s kubernetes 52:28 introduction courses you can go in here and you can start up it launches the mini cube cluster uh 52:34 on in the browser for you so you don’t have to launch it but definitely definitely give a look uh uh 52:40 try these because there’s examples in here that allows you that helps you to deploy stuff um okay and i 52:45 think there’s another there’s another one i’m gonna uh let me let me quickly find that but what i’ll show you in a K3S 52:52 second as well uh god do you wanna add anything else uh uh yeah the next question was how does kate’s and k3s 52:59 differ and k3s comes from 53:05 rancher and that’s i think that’s mostly meant for iot uh 53:11 it’s a lightweight kubernetes that is primarily i mean is there anything you would add with that 53:17 yeah i think yeah so so the only as as uh as tennis says uh they’re basically 53:23 supposed to do the same thing the only thing is that k3s is is just a single binary uh it’s like a 53:29 lightweight kubernetes disagreement it’s a kubernetes distribution which is a bit more lightweight and it’s a single 53:34 binary which is like less than 40 uh megabytes and they it completely 53:40 implements the the kubernetes api so um but what it doesn’t have is a lot of 53:45 add-ons that you have to perhaps adam yourself so some things in k3s don’t 53:51 exist but um yeah you you’re more than more than welcome to to try things in 53:57 k3s so ka test whatever is easier for you of course there’s more like information out whatever you’re running 54:03 in ka des or k3s will also run in ka test so i think i think that’s absolutely fine 54:09 that’s not no issues whatsoever i’m gonna add one more thing so 54:15 we have some we also have some exercises for for kubernetes um in github which i 54:20 will uh share a link to that you can definitely try on uh for a while while i’m looking for it uh 54:27 i can you just have to give me a second i’m not probably looking for it in in the in the in the github i should 54:34 have i should have had it handy that’s all right and one follow-up question was how applicable are the skills 54:39 uh skill sets learned by deploying one or the other over the or to the other uh 54:45 and the short answer from what’s uh to echo what salman was saying is they 54:50 are very applicable so if you become very skilled with k3s you shouldn’t have any problems going to uh kate’s um i you 54:59 know would start with something like mini cube or raspberry pi or something like that 55:04 especially minicube um because it’s it’s so easy to uh to do these days 55:11 yeah uh definitely if you don’t wanna like uh yeah definitely start with mini 55:16 cube there’s examples out there so many uh things that you can try and find out and we will also release uh 55:23 release some stuff watch out um our blog so we have a blog as well uh if 55:28 i if i head over to app via io if there’s some stuff you wanna touch logs 55:35 such blog if you want to learn a little bit more about kubernetes we have tons of blogs and i think we are also going to put out another blog about getting 55:42 started with kubernetes and what kind of things yes you should look down so we’re going to stick it here so just you know 55:48 keep an eye on this uh um on this uh on this page there’s going to be a blog out 55:54 quite soon uh so that’s that’s that there’s a couple of things if you are interested in if you are using 56:01 kubernetes and uh kubernetes is very complex in order to manage hopefully we answer the questions by the way if you 56:07 have any more questions that was a good question uh if you have any more questions please please feel free to ask 56:12 um one of the things that kubernetes is the problem with kubernetes is kind of hard to manage and 56:19 deploy and get it up and running getting up and running is kind of easy but doing it properly 56:24 make sure it’s secure and all that’s kind of hard but we have a tool called wayfinder 56:29 check it out if you’re interested just head over to appear.io forward slash wayfinder dash trial just go ahead 56:36 over to the website you find it’s cool tool it helps you uh ease a bit of a kubernetes pain when 56:43 you’re getting started anything else you’d like to add tennis on that nose not really it’s it’s um just that it’s 56:50 it really eases the pain of implementing kubernetes to begin with so you can get 56:57 in and start developing applications quickly yeah absolutely that’s right and i think 57:03 i’m going to add a couple more things in here uh yeah please do join next week if you want to 57:08 learn a little bit more about how we deploy applications you know the person who asked that question we were deploying applications next week 57:14 we’re going to be doing that together we’ll be sharing some resources and tennis and i will actually be there in person we’re going to be doing that i 57:21 know this is the first time ever we’ll do this we’ll be there together sitting in one room and talking to you about 57:26 this stuff hopefully you will find that useful so please do sign up for the next one uh which is on next thursday 16th of 57:35 december same time as it is right now if you have any questions feel free to 57:40 ask us i’m going to end my screen here so we can you can see us uh just so we can show you that we’re actually real 57:47 human beings and not just uh some clouds running inside a kubernetes cluster if you have any 57:52 questions about anything feel free to ask us and uh do check out our website at the i o we’ve got some 57:59 use of blogs we have a new release of a product out which helps with kubernetes so 58:06 anything else tennis no sir and uh so far no questions so 58:11 yes uh yeah thank you very much for everyone for joining in we really appreciate that you took your taking time out and 58:18 joining us and yeah uh please to join us for the next one thank you all