•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
•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
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
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.
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
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
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
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.
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.
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
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
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.
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
Like the Video and Subscribe the Channel