Successfully reported this slideshow.
Your SlideShare is downloading. ×

Kubernates best Practices

Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Ad
Upcoming SlideShare
what is OSI model
what is OSI model
Loading in …3
×

Check these out next

1 of 12 Ad

More Related Content

More from jeetendra mandal (20)

Recently uploaded (20)

Advertisement

Kubernates best Practices

  1. 1. •When defining configurations, specify the latest stable API version. •Configuration files should be stored in version control before being pushed to the cluster. This allows you to quickly roll back a configuration change if necessary. •It also aids cluster re-creation and restoration. •Write your configuration files using YAML rather than JSON. Though these formats can be used interchangeably in almost all scenarios, YAML tends to be more user-friendly. •Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. •See the guestbook-all-in-one.yaml file as an example of this syntax. •Note also that many kubectl commands can be called on a directory. For example, you can call kubectl apply on a directory of config files. •Don't specify default values unnecessarily: simple, minimal configuration will make errors less likely. •Put object descriptions in annotations, to allow better introspection
  2. 2. Use the Latest Version You must always have the latest stable version of production cluster. The new releases have many features, and most importantly, patches to previous issues. It helps you in keeping your cluster away from Older versions also do not get enough support from community. So, it is better to update the cluster on Kubernetes.
  3. 3. Version Control for Configuration Files Configuration files related to your deployment, other files should be stored in a version control before being pushed to a cluster. Doing so allows you who made the changes and implement a change improve your cluster’s stability and security.
  4. 4. Use Namespaces By default, there are three different namespaces in Kubernetes default, kube-public and kube-system. Namespaces are very your Kubernetes cluster and keeping it secured from other same cluster. If your Kubernetes cluster is large (hundreds of teams are working on it, you need to have separate example, you should create different namespaces for production teams. This way, the developer having access to namespace won’t be able to make any changes in the by mistake.
  5. 5. Set Resource Requests/Limits One of the challenges with the Kubernetes cluster is that the application might fail while deploying it to the production cluster just because that cluster has limited available resources. This problem mostly occurs when you have not set up resource requests and limits. Without it, pods are free to utilize resources as per their needs. This way, if pods begin to consume more memory and CPU on the node, then either the node might crash or new pods might fail to establish. Therefore, it is important to set both requests and limits where the memory should be defined in mebibytes or megabytes, while the CPU in millicores.
  6. 6. Use Labels A Kubernetes cluster includes multiple elements like services, networks, etc. Maintaining all of these resources and keeping interact with each other in a cluster is cumbersome. This is Kubernetes labels are key-value pairs that organize your For example, let’s say you are running two instances of one are similarly named, but each application is used by different development and testing). You can help your teams applications by defining a label which uses their team’s name ownership.
  7. 7. Readiness and Liveness Probes Readiness and liveness probes are strongly recommended; it is almost them than to forego them. These probes are essentially health checks. Readiness probe Ensures a given pod is up-and-running before allowing the load to get the pod is not ready, the requests are taken away from your service the pod is up. Liveness probe Verifies if the application is still running or not. This probe tries to from it and then check its health. If there is no response, then the on the pod. The liveness probe launches a new pod and starts the check fails.
  8. 8. Audit Your Logs Regularly The logs of any system have a lot to tell, you just have analyze them well. In Kubernetes, auditing the logs important in order to identify any vulnerability or threat request data made on the Kubernetes API is stored in This file is stored at /var/log/audit.log with the policy present at /etc/kubernetes/audit-policy.yaml
  9. 9. Scalability When it comes to scalability, organizations mostly think of scaling Kubernetes up not down. It is alright to think of expanding Kubernetes architecture as the company expands. But you should focus on setting up such an architecture that can grow or shrink as per the usability. You should never run Kubernetes components idle, wasting both money and time. Horizontal Pod Autoscaler and Cluster Autoscaler can help you adjust volumes of node and pod dynamically.
  10. 10. Use Smaller Container Images A beginner developer often makes the mistake of going image, which consists of up to 80% packages and need. We recommend choosing smaller docker images storage space. This helps you pull and build the image smaller the docker image, the fewer the chances of
  11. 11. THANK YOU Like the Video and Subscribe the Channel

×