What to Run in Kubernetes? The Ultimate Guide

I get constantly involved into discussions whether something is a good candidate to run in or be managed by kubernetes it's getting repetitive and boring so today I will explain what is and what isn't a good candidate to run in or be managed by [Music] kubernetes now I hope you notice that I said run in or be managed by kubernetes that part is importantance is kubernetes manages resources which might or might not be running inside the same cluster Argo CD resource might be managing other resources in a different cluster and those resources might or might not be containers cross plan resources might be managing aw cc2 instances Atlas operator might be managing database schemas in a server that is running in Azure let's say hence something might run in or be managed by kubernetes or it could be bought now let's start with what kubernetes is not the primary purpose of kubernetes is not to be a thingy that runs containers nor it is a cluster operating system as many like to call it that does not mean that it is not those things it often is used exclusively for those purposes but that's mostly because many did not understand its true goals or its true potential the point is that being a thingy the trans containers and being a cluster os are not its primary purposes the primary objective and the main benefit is something completely different now for me to explain what kubernetes is and to give an answer to the question whether kubernetes is a good choice for this or that I need you to forget that kubernetes exists I'm going to talk about something completely completely different something that you probably already know yet something that is very important for the latter part of this story so hang tight while I explain backend applications and apis and a few other things that have nothing to do with kubernetes yet things that are likely going to lead us towards the answer of the big question we can a user that wants to reach some application which for the sake of Simplicity and my inability to come up with creative names I will call backend how does a user reach that backend application that's an easy question to answer we build an API on top of it so the user calls the API and the API forwards the request to the back end or the API is part of the back end the back end responds and the user gets the information that they wanted now with typically not have only one application in the system there are others which I will all all call backends the second one also has its own API that allows users to talk to the same can be said for the third up not only that users can talk to those backends but also other backends can talk to those through their apis so far so good right I did not tell you anything you did not already know now over time the number of API grows and we start facing problems with too many apis typically we would solve those with an API Gateway that would become a single entry point into the system with its main job being to forward requests to the right place now to be honest we are abandoning that idea in favor of even based architectures instead of an API Gateway and a bunch of API which have an even store like for example kfka and the single API the direction becomes inversed beans do not wait for requests anymore except maybe when queries are concerned instead they can listen to events that match specific criteria we humans and other processes can now keep sending requests to that single API and they will be stored as events unless we are issuing queries we get AK acknowledgement as an answer that essentially means something like understood it's it will be done relax one of the beckons that are listening for events will realize that specific event type is something that it should handle and do something about it once it's done it will post another event acknowledging that it finished doing whatever it was doing other beckons might respond to that event and do something themselves what I just described is a simplified version of an even driven architecture where all components are decoupled from each other and communicate by listening to events and posting events that might be similar to the architecture of your system especially if you're running its scale and now comes the important question what type of workload can those backend applications be what can they do well the short answer is anything it's completely up to you to decide what each of those does there are no restrictions as to what can and what cannot be one of those back ends the only limitation or to be more precise a requirement is for each of those to be able to listen to and post events outside that it can be anything you want it's completely up to you to decide now remember that answer remember that I said that your backend applications can be anything you want anything that answer will become very important in a few minutes now comes another question what happens if you replace the word beckon with controller everything stays the same except the name of those processes that listen to events and post events what happens is that we just described kubernetes let that sink in for a moment this architecture which you were probably already using for your own applications is the same architecture that kubernetes uses each of those controllers is watching for specific events one for example might be subscribed to events related to deployments another one might be watching for pods others could be watching for databases database schemas awcc TOs and so on and so forth a controller can be anything it subscribes to events of a specific type and it does something when it receives those events just as your backck application can be anything you want it to be a kubernetes controller can be anything from a high level perspective both are the same thing however there is one restriction that applies to kubernetes controllers and not to your backend applications controllers can run only as containers while your backand apps can run as anything they could be running in containers or directly in VMS as AWS lambdas or anything else kubernetes controllers do not have that luxury at least not today they're processes listening to events and running in containers now that should not be a problem since almost anything can run in a container these days so far we got to the conclusion that a controller can be anything and that means well anything if you need to manage applications running in containers Define them as deployments which will ultimately end up managing containers now you might say hold on it needs to be a stateless application to run well in kubernetes that's not true at all that misconception comes from early days of kubernetes when we did not have many controllers now we do have controllers for almost anything you just need to install them since only a few are baked into kubernetes itself if you need a database all you need is a controller that controller might end up managing resources which will result in a database running as containers in the same cluster that's what for example cmpg or Cloud native pogress does or you might have a controller that will manage a database as awsrds that's what for example crossplane does if you need to manage databas schemas well you know the answer you need a controller that will manage database schemas the important thing to not is that controller is just code packaged in a container image it can be anything the only important restriction is that it needs to be capable of listening to kubernetes events and the use whether there is something it should do so far the answer to what is a good candidate to run in or be managed by kubernetes the answer is well the only only limitations are temporary if there is no controller that enables you to run a specific type of workload that something is not a good candidate to run in or be managed by kubernetes now new controllers are popping up almost every day so such a potential issue is probably temporary until someone or maybe you write a controller for it controllers themselves are reacting to specific events and events are created through the API when we had additional controllers we often need to expand the API and we do that by adding custom resource definitions or crds we interact with the API by sending it data this part is very important since there are dozens of ways we can interact with systems and in this case the only option is by sending data to the API it is not by sending it code or by sending it imperative commands it is data in data out out that data is defined as kubernetes resources or custom resources so that might be the only real limitation if the type of the workload you would like to run or manage by kubernetes cannot be defined as data it is not a good candidate to run in kubernetes now I might argue that everything is ultimately data and that we should be able to describe anything as such if that's the case there should be no limit to what can run or be managed by kubernetes however that might also mean that we might need to change the way we represent workloads the best way as we know to represent data is through a declarative format kubernetes happens to like yam precisely for that reason that's how we feed it data you are free to Define it in any other way you want just as long as you can convert it into a declarative yaml format before feeding it to kubernetes if you like go write it in go if you prefer Helm write it as a Helm template if you think that jonet is the way to go write it in jonet as long as that something can be converted into yaml you're fine so data is the real limitation if something cannot be represented as data it cannot be fed to kubernetes through its API and hence it cannot run in it or be managed by it and here's a question for you do you know of an example of something that cannot be represented as data actually here's another one what is an example of a workload that is better represented as something other than data if you can answer any of those two questions you will have the answer as to what is not a good candidate to run in or be managed by kubernetes for everything else well you know the main benefit of kubernetes is a uniform API it's an attempt to standardize the way we interact with different applications and different systems the end result is a single API that can serve almost any purpose through that API and the controllers kubernetes is effectively a control plane that manages whatever the controllers manage so whenever I hear kubernetes is not good fit for this or that my answer is you either do not understand what kubernetes is or there is no crd and the controller that does that kubernetes did not change what we do but how we interact with the tools that do something that is its real power so the next time someone asks you whether something can be run in or be managed by kubernetes check whether there is a crd and a controller for that something and whether that something can be managed as data thank you for watching see you in the next one cheers

Channel: DevOps Toolkit

Views: 8,378

Keywords: CI/CD, CRD, Cloud Computing, Cloud Native Applications, Container Deployment, Container Orchestration, Containerization, Containerizing Applications, Controller, Deploying Applications in Kubernetes, DevOps, Distributed Systems, Docker, Infrastructure Management, Kubernetes, Kubernetes CRD, Kubernetes Controllers, Kubernetes Custom Resource Definitions, Kubernetes Deployment, Microservices Architecture, Scalability

Id: DWGXnz9NBC0

Length: 12min 59sec (779 seconds)

Published: Mon Oct 30 2023