Kubernetes Best Practices | For Interview

hello guys and girls raj here back with another video in this video we are going to go over kubernetes best practices so one of the feedback i get from my students and viewers is when the search for kubernetes best practices a lot of best practices come up so how to answer this question in a interview so in this video i'm going to go over five key best practices that you should definitely mention in your interview alright let's get started the first best practice is use kubernetes namespace so namespaces create multiple virtual cluster boundary within one physical cluster it also provides scope for naming so if we look into this in a detail one eks cluster can have multiple name spaces and you can see team a and team b can have the same deployment app name web server app in two different name spaces but in the same eks cluster another huge advantage of namespace is physical separation of resource requirement so let's say team c is running a badly optimized application you could allocate specific amount of cpu and memory to this namespace so that it doesn't spill over or use up cpu and memory from namespace a and namespace b and it is also useful for namespace specific accesses which brings us to the second best practice and this is the most important best practice which is implement resource requests and limits so resource requests and limit is a way to request certain amount of cpu and memory for your containers so i have a separate video going over detail on this separately i'm going to give a link up top and this is how scaling is controlled so let's say this container is requesting cpu of 500 millicard and 256 maybe bytes of memory so basically this is requesting a half of one vcpu and 256 mega megabytes of memory and the limits is one vcpu and 512 megabytes of memory so this container cannot use more than these limits so going back to the previous example where you have an application which is running a badly optimized app so you can set resources for namespaces using resource quotas for example the kind is resource quota and you can see request.cpu and request that memory and limit start cpu and that memory restricts how much cpu and memory that namespace can use so one thing to keep in mind when cpu reaches limit it will throttle so the container will throttle so you might observe slowness for your program but memory is not a throttleable resource so when memory reaches limit pod will be evicted so keep an eye out in the monitoring system and if you see a container is reaching the memory limit frequently then you know you need to adjust the memory limit in that pod spec file proper requests and limits save cost as well because you ensure that a container doesn't take up or doesn't reserve more cpu and memory which is needed so this is generally the biggest cost factor for the applications running on production and there are a lot of tools to help you on that under the hood the metric server tells you how much cpu and memory are being used for the container but to do this manually would be very difficult so there are a lot of tools available in the market such as cloud watch container insights for aws you have cube cost i i personally used cubecast highly recommend it cloudhealth kubernetes research report etc so if you mention some of this to the interviewer interviewer will be very impressed next kubernetes best practice is use readiness and liveness probes so these help in health check of your kubernetes parts so you are probably thinking well raj replica set restores parts right so if you have a replica set set to 3 and if a part goes down a replica set will bring a pot up and everything will be up and running so what's the big deal about readiness and liveness well let's imagine that your app app takes a minute to warm up and start your service won't work until it is up and running even though the process has started you will also have issues if you want to scale up this deployment to have multiple copies a new copy should not receive traffic until it is fully ready but by default kubernetes starts sending it traffic as soon as the process inside the container starts by using a readiness probe kubernetes waits until the app is fully started before it allows the service to send traffic to the new copy and for liveness let's imagine another scenario where your app has a nasty case of deadlock causing it to hang indefinitely and stop serving requests maybe going back to the previous example let's say your pod reaches cpu limit and is throttling very badly but because the container is still running uh kubernetes thinks everything is fine and continues to send requests to this pod by using a liveness probe kubernetes detects that the app is no longer serving requests and restarts the offending pod there are different types of probes using which you can do readiness and liveness checks the most common is the http probes you can create a lightweight http server inside your application to respond to liveness probe so kubernetes pings a path and if it gets a http response in the 200 or 300 range it marks the app as healthy otherwise it is marked as unhealthy moving on to the next best practice you should always secure your kubernetes so this one you kind of demonstrating your high level understanding of kubernetes um so when it comes to kubernetes security there are two different kinds of security uh make sure you you tell interviewer that uh okay i know about the application security so this one people will mention right application security as in security or pod name space node using rbac irsa etc but the other big kind of kubernetes security is the security of the devops pipeline so you can do that by implementing proper authorization you scan the repository you scan running container also you can mention that if your application has additional security compliance such as fedramp hipaa sock etc choose proper aws accounts uh for to fulfill this for example if the application requires to be fed ramp high compliant then they need to run in golf cloud the last best practice is to implement day two operations so implement a detective control so collect and analyze audit logs and alarm on certain behavior also understand kubernetes termination life cycle there may be reasons why kubernetes might terminate perfectly healthy container so if you are updating your application or if you drain a node kubernetes will terminate all pods so it is very important that you use rolling update with rolling update kubernetes slowly terminates old pods while spinning up new ones so your application can still serve traffic while the update is going on it is also important that your application handle termination gracefully so that there is minimal impact on the end user and the time to recovery is as fast as possible this means that your application needs to handle the termination signals so when kubernetes is trying to terminate a pod it sends some signal to the pod and your app should be able to handle it and begins to save something if it needs to save shut down a process gracefully etc finish any work which is left and any other similar tasks also make sure there's the incident response plan in place you should be able to identify and isolate any pod or node in case something bad happens and you should always run load and penetration testing before you implement your application in production those are the five best practices for your kubernetes interview all right guys and girls that's the video if you find this video useful please do all the youtube stuff like this video subscribe comment also actually in the comment let me know if there are other questions that's in your mind for kubernetes that you want me to go over all right guys and girls that's it for this video i'll see you guys and girls in the next video bye

Channel: Cloud With Raj

Views: 4,029

Keywords:

Id: p4ZJMPUdm4c

Length: 10min 34sec (634 seconds)

Published: Sat Feb 06 2021