Cluster Administration

We've learned most of our basic DevOps skills with Kubernetes in previous chapters, from how to containerize our application to deploying our containerized software into Kubernetes seamlessly via continuous deployment. Now, it's time to have a deeper insight into how to administer a Kubernetes cluster.

In this chapter, we'll learn:

• How to utilize namespaces to set administrative boundaries
• Using kubeconfig to switch between multiple clusters
• Kubernetes authentication
• Kubernetes authorization

While minikube is a fairly simple environment, we will use the Google Container Engine (GKE) and self-hosted cluster in AWS as the example, instead of minikube in this chapter. For the detailed setting, please refer to Chapter 9, Kubernetes on AWS, and Chapter 10, Kubernetes on GCP.

Kubernetes namespaces

Kubernetes has a namespace concept to divide the resources from a physical cluster to multiple virtual clusters. In this way, different groups could share the same physical cluster with isolation. Each namespace provides:

• A scope of names; object name in each namespace is unique
• Policies to ensure trusted authentication
• Ability to set up resource quotas for resource management

Namespaces are ideal for different teams or projects in the same company, so different groups can have their own virtual clusters, which have the resource isolation but share the same physical cluster. Resources in one namespace are invisible from other namespaces. Different resource quotas could be set to different namespaces and provide different levels of QoS. Note that not all objects are in a namespace, such as nodes and Persistent Volumes, which belong to entire clusters.

...

ResourceQuota

By default, pods in Kubernetes are resource-unbounded. Then the running pods might use up all the compute or storage resources in a cluster. ResourceQuota is a resource object that allows us to restrict the resource consumption that a namespace could use. By setting up the resource limit, we could reduce the noisy neighbor symptom. The team working for project1 won't use up all the resources in the physical cluster.

Then we can ensure the quality of service for other teams working in other projects which share the same physical cluster. There are three kinds of resource quotas supported in Kubernetes 1.7. Each kind includes different resource names, (https://kubernetes.io/docs/concepts/policy/resource-quotas):

• Compute resource quota (CPU, memory)
• Storage resource quota (requested storage, Persistent Volume Claims)
• Object count quotas (pods, RCs, ConfigMaps...

Kubeconfig

Kubeconfig is a file that you can use to switch multiple clusters by switching context. We can use kubectl config view to view the setting. The following is an example of a minikube cluster in a kubeconfig file.

# kubectl config view
apiVersion: v1
clusters:  
- cluster:
    certificate-authority: /Users/k8s/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /Users/k8s/.minikube/apiserver.crt
    client-key: /Users/k8s/.minikube/apiserver.key

Just like what we learned previously. We could use kubectl config use-context to switch the cluster to manipulate. We could also use kubectl config --kubeconfig=<config file name> to specify which kubeconfig file we'd like to...

Service account

Unlike normal users, service account is used by processes inside a pod to contact the Kubernetes API server. By default, a Kubernetes cluster creates different service accounts for different purposes. In GKE, there are bunch of service accounts that have been created:

// list service account across all namespaces
# kubectl get serviceaccount --all-namespaces
NAMESPACE     NAME                         SECRETS   AGE
default       default                      1         5d
kube-public   default                      1         5d
kube-system   namespace-controller         1         5d
kube-system   resourcequota-controller     1         5d
kube-system   service-account-controller   1         5d
kube-system   service-controller           1         5d
project1      default                      1         2h
...  

Kubernetes will create a default service account in each...

Authentication and authorization

Authentication and authorization are important from DevOps' point of view. Authentication verifies users and checks if the users are really who they represent themselves to be. Authorization, on the other hand, checks what permission levels users have. Kubernetes supports different authentication and authorization modules.

The following is an illustration that shows how the Kubernetes API server processes the access control when it receives a request.

Access control in API server

When the request comes to API server, firstly, it establishes a TLS connection by validating the clients' certificate with the certificate authority (CA) in the API server. The CA in the API server is usually at /etc/kubernetes/, and the clients' certificate is usually at $HOME/.kube/config. After the handshake, it goes to the authentication stage. In Kuberentes...

Admission control

Admission control takes place before Kubernetes processes the request and after authentication and authorization are passed. It's enabled when launching API server by adding --admission-control parameter. Kubernetes recommends officially to have the following plugins with the cluster if the cluster version is >= 1.6.0.

--admission-control=NamespaceLifecycle,LimitRanger,ServiceAccount,PersistentVolumeLabel,DefaultStorageClass,DefaultTolerationSeconds,ResourceQuota  

The following introduces the usage of these plugins, and why should we need them. For more latest information about supported admission control plugins, please visit official document https://kubernetes.io/docs/admin/admission-controllers.

Namespace life cycle

...

Summary

In this chapter, we learned what is namespace and context and how do they work, how to switch between physical cluster and virtual cluster by setting the context. We then learned about the important object—service account, which provides to identify the processes running within a pod. Then we get to know how to control access flow in Kubernetes. We learned what the difference are between authentication and authorization, and how they work in Kubernetes. We also learn how to leverage RBAC to have fine-grained permission to users. At the end, we learned a couple of admission controller plugins, which are the last goalkeepers in the access control flow.

AWS is the most major player in public IaaS providers. We've used it lots as self-hosted cluster examples in this chapter. In next chapter Chapter 9, Kubernetes on AWS, we'll finally learn how to deploy the...