Top ten tips for using kubernetes

1. Bash Auto-refill for KUBECTL commands
This is probably the easiest thing to do in the kubernetes process, but it's also one of the most useful. To add the auto-refill feature, if you use bash, simply execute the following command:

echo "source <(kubectl completion bash)" >> ~/.bashrc

It will add an auto-complete command to your. bashrc file. So each shell window you open supports this feature. I found that auto-completion is especially useful for some long parameters, such as--all-namespaces.
2. Add default memory and CPU limits to each namespace
It's people who make mistakes. We assume someone wrote an app, and he opens a database connection every second, but it doesn't shut down. This enables a memory leak application in the cluster. Assuming that we deploy the application to a cluster with no quota set, the application crash a node.
To avoid this situation, Kubernetes allows you to set a default limit for each namespace. To do this is simple, we just need to create a yaml of limit range and apply it to a specific namespace. Here is an example:

  apiversion: v1   
  kind: limitrange   
  metadata:    
    name: mem-limit- range   
  spec:   
     limits:   
    -   default:   
         memory:   512mi   
      defaultrequest:    
        memory:   256mi   
         type: container 
       

Create a Yaml file of that content and apply it to any namespace you want to apply, such as namespace Limit-example. Once the quota is used, any application deployed to the namespace will be given a default 512Mi memory limit if the quota is not actively set.
3. Kebelet can you clear the Docker image for me?
This is a feature that Kubelet has implemented by default. If flag is not set when Kubelet is started, it is automatically garbage collected when the/var/lib/docker directory reaches 90% capacity. This is excellent, but it does not have a default setting for Inode thresholds (before Kubernetes 1.7).
You may encounter/var/lib/docker using only 50% disk space, but the inode is all out of use. This can cause a variety of problems for the work nodes. If you run the Kubelet version between 1.4 and 1.6, you'll need to add the following flag to Kubelet:

--eviction-hard
=memory.available<100Mi,nodefs.available<10%,nodefs.inodesFree<5%

If the Kubelet version is 1.7 or higher, it has this configuration by default. 1.6 The Inode usage is not monitored by default, so you have to add that flag to solve the problem.
4. Although the Minikube is Mini, the local use is powerful
Minikube is definitely the easiest way to start a kubernetes cluster locally. You just have to follow this [1] guide to download everything.
Once all the components have been installed, you can simply run the following command:

minikube start

After the command is executed, you will have a running kubernetes cluster locally.
There is a trick when you want to build an app locally and run it locally. When you build a Docker image locally, if you do not run other commands, your image will be built on your local computer.
In order for the Docker image you build to push directly to the local kubernetes cluster, you need to inform the Docker machine using the following command:

eval $(minikube docker-env)

This will allow you to directly push locally built apps to your local cluster.
5. Do not open kubectl privileges to everyone
This may be an obvious thing, but when multiple team deployments are applied to the same cluster, and this scenario is Kubernetes's goal, do not open a generic kubectl to everyone. My advice is to isolate the team based on namespace and then use RBAC policies to limit the ability and access to only that namespace.
After the permissions are controlled, you may become crazy, for example, to read, create, and delete pods based on pods only. But one of the things that needs to be done is to access only the administrator credentials, which can isolate who can manage the cluster and who can only deploy the app on the cluster.
I am looking forward to a separate blog post for a more detailed analysis of this topic.
6. Pod Interrupt budget (POD disruption budgets) is your friend.
How do we ensure that 0 outages are applied in the Kubernetes cluster?
Poddisruptionbudgetpoddisruptionbudgetpoddisruptionbudget
The cluster is updated. The node will be labeled Drain and the pod will be removed, which cannot be avoided. So we should set up a PDB for each deployment to ensure that there is at least one instance. We can use a simple yaml to create a PDB, apply it to the cluster, and use a tag selector to determine which resources the PDB covers.
Note: The PDB is only responsible for resources that are voluntarily interrupted, and some of these errors, such as hardware failures, do not work.
The PDB example is as follows:

apiVersion: policy/v1beta1  
 kind: PodDisruptionBudget  
 metadata:  
   name: app-a-pdb  
 spec:  
   minAvailable: 2  
   selector:  
       matchLabels:  
         app: app-a

The two fields that need the most attention are matchlabels and minavailable.
The Matchlabels field is used to determine whether a deployment can be associated to this PDB.
For example, if I have a deployment with a label app:app-a, and another deployment with a label app:app-b, the PDB in the example will only work on the first deployment.
The Minavailable field is the basis for kubernetes to operate in certain scenarios, such as when node is tagged with a drain tag. Assuming that App-a is running on Node1, if Node1 is tagged with drain, kubernetes will only purge those with at least 2 instances.
This allows you to control the number of running instances at any time.
7. Is your app still alive and available?
Kubernetes allows us to define probes for Kubelet to confirm that our pods and apps are healthy.
Kubernetes offers two types of probes, readiness probes and liveness probes.
The readiness probe is used to confirm whether the container is acceptable for flow.
The liveness probe is used to confirm that the container is healthy, or that it needs to be restarted.
These configurations can be easily appended to the deployment yaml, and can be customized with time-outs, retry attempts, delay times, and so on. To learn more about how to use them, please read this article [2].
8. Label all Things
Labeling is one of the cornerstones of kubernetes. It leaves the object and object loosely coupled and allows us to query the object based on the label. You can even use the Go client to monitor events based on tags.
You can almost do anything with tags, and one of the best examples is multiple environments in the same cluster.
We assume that you use the same cluster in the dev and QA environments. This means that you will be running a APP-A application at the same time as the dev and QA environments.
The simplest way to achieve this is to use the service object, where one chooses the pod with the label app:app-a and Environment:dev, and the other, the pod with the label app:app-a and Environment:qa.
The advantage of this is that two of the same apps, each with a different endpoint, support simultaneous testing.
9. Active Cleanup
Kubernetes is a very, very powerful system, but as with other systems, it will eventually fall into disarray. Kubelet must do whatever you tell it to do, and it also checks itself.
Of course, Kubernetes has a service that cannot be connected, and the system will not hang up because it supports the scaling capacity. But once a service is extended to tens of thousands of endpoint, Kubelet will suddenly become paralyzed.
Simply put, whatever reason you need to remove a deployment (or something else), you must make sure that you clean up everything that is relevant to it.
10. Do you love the Go language?
The last point is what I personally think is most important: continuing to learn the go language.
Kubernetes was written by go, and all of its plugins were written in go, and they even wrote a client for the go language. Client-go can be used to do all kinds of interesting things. You can use it to expand the kubernetes according to your hobby. such as data collection, deployment engines, or a simple cleanup application.
Learn this go client and use it in Kubernetes, which is the biggest recommendation I give to every user who uses Kubernetes.
Original link:

1. https://kubernetes.io/docs/tasks/tools/install-minikube/

2. https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

Original link: https://hackernoon.com/top-10-kubernetes-tips-and-tricks-27528c2d0222

Top ten tips for using kubernetes