Kubernetes vs. Docker: It's Not an Either/Or Question

Video Statistics and Information

Video
Captions Word Cloud
Reddit Comments
Captions
hi everyone my name is sai venom and I'm a developer advocate with IBM here at IBM were always enabling developers to be able to use the latest and greatest technologies when developing their applications but a question I almost always seem to be running into is whether or not you should use docker versus kubernetes I think there's the small misconception out there that you have to be using one or the other but the fact is kubernetes allows you to use your existing docker containers and workloads but allows you to tackle some of the complexity issues you run into when moving to scale to better answer this question let's start with a simple cloud native application sketched out up here and let's just say that the front end of this application is something that we wrote with react backed by nodejs we'll say that this database access application a fan of using Java for database access so we'll say Java up here and for accessing external API s maybe we use Python on maybe a flask application that allows us to serve rest endpoints now putting on my hat as a docker ops engineer using a purely docker approach to deploying an application let's take this app and move over to a sample server stack that we have sketched out over here on every service stack you're gonna have the the basics right so we'll have the hardware we'll have the OS which is generally going to be ubuntu when you're working with docker and we'll have the doctor daemon installed on top of that OS that's what allows us to spin up containers so docker actually provides us a number of great tools for working with our containerized applications so once we take these applications create neat docker containers out of them will do docker build docker push up to a registry and then SSH into our stack and do docker run commands or even use doctor compose to spin up our containers so let's take a look at what that would look like so we've got our jsn we've got our java app as well as the Python and let's go ahead and scale out these individual pieces as well so take advantage of all the resources we have so we'll scale them out and we can do this as many times as we want but let's assume that we scale them out twice for now to make effective use of all the resources that we have available so using docker and the tools that docker makes available a simple deployment is very easy but let's imagine that our application starts to get a lot more load a lot more people are hitting it and we realize hey we need to scale out to be able to provide a better user experience so it's an ops engineer my first instinct might be hey I've already got scripts to make this stack let's just simply create new get new hardware and do that exact same deployment multiple times this can fall apart for many reasons when you start moving to scale for example what if your dev team has to create a new micro service to support a new requirement where do we piece those in especially if you already have effective use of the hardware and the ops and dinner would have to find that out and in addition a big advantage of micro service based applications is being able to scale out individual components individually so that's another thing that the ops engineer would have to write scripts for and find the most effective way to scale things out in response to load to identify and address user experience issues when moving to scale so this is where an orchestration tool comes in something like kubernetes which is going to allow you to use your existing darker eyes applications but orchestrate them and do make it more effective use of your servers in space so what we have sketched out down here is a number of boxes which represent a server stack but in the kubernetes land we call them worker nodes so we're gonna have kubernetes installed on every single one of these worker nodes and the main one is going to be the master node whereas the other ones or workers this master node is actually connected to all the worker nodes and decides where to host our applications our docker containers how to piece them together and even manages orchestrating them starting stopping updates that kind of thing I'd say there's three major advantages that could Nettie's provides that I want to walk through deployment making development easier and providing monitoring tools the first step as expected is going to be deployment so coming back to our application architecture let's say we want to deploy that react app about eight times so we'll say we want eight instances each of them let's say we expect it to consume about 128 megabytes and then we can actually specify some other parameters in there as well policies like when to restart that kind of thing and when we box that up what we get is a kubernetes deployment so a kubernetes deployment is not a one-time thing but it's something that grows and lives and breathes with the application and our and our full stack so for example if the react app happens to crash kubernetes will automatically be started to get back to that state that we've identified when we first created that deployment so deployment is always growing and always living with our application so I think we can effectively say that it's made deployment in addition to scaling easier let's talk about development you might be wondering so once we've created like the deployments for each of these individual services and scaled all of them out we have a lots of different micro services out there with different endpoints so for example if our fernández de debase there might be maybe 8 different versions of that Java app that that talk to that database we have to talk to one of them to get our kind of request fulfilled right so what kubernetes does is deploys load balances for all of our micro services that we scaled out and in addition takes it takes advantage of service registry and discovery capabilities to allow our applications to talk to each other using something called a kubernetes service so for each of these kubernetes will also create a service which we can simply label service a B and C obviously you can have more meaningful names for those as well but very simply these applications can now speak to each other just by using those service names that are laid out in kubernetes so essentially I could say that kubernetes has made development easier and the last thing I want to touch on is monitoring kubernetes has a lot of built-in capabilities to allow you to kind of see logs see CPU load all in there neat UI but the fact is it there's sometimes more that you want to see with your application and the open source community out there has developed a number of amazing tools to give you introspection into your running application so the main one I'm thinking about right now is sto and although that's a little bit more of an advanced topic will likely hit that in a future whiteboarding session so back to our main topic using kubernetes versus docker it's definitely not a choice of using one or the other it's one of those things where kubernetes allows you to take advantage of your existing docker workloads and run them at scale tackle real complexities kubernetes is great to get started with even if you're making a small app if you anticipate that one day you'll have to move to scale if you're already taking advantage of docker and containers with your applications moving them onto kubernetes can really help you tackle some of the operations overhead that almost every application is going to run into when moving to scale thank you for joining me today I hope you find this useful and definitely stay tuned for additional whiteboarding sessions in the future
Info
Channel: IBM Technology
Views: 926,157
Rating: undefined out of 5
Keywords: Docker, Kubernetes, containers, Docker vs Kuberbetes, Kubernetes vs Docker, workloads, containerization, deployment, deployments, application, cloud native, react, node.js, java, python, api, os, ubuntu, registry, docker compose, microservices, istio, knative, container orchestration, worker node, master node, monitoring, pods, clusters
Id: 2vMEQ5zs1ko
Channel Id: undefined
Length: 8min 3sec (483 seconds)
Published: Tue Oct 16 2018
Related Videos
Note
Please note that this website is currently a work in progress! Lots of interesting data and statistics to come.