Cluster Administration and Extension

In previous chapters, we familiarized ourselves with basic DevOps skills and Kubernetes objects. This included looking at many areas, such as how to containerize our application and deploy our containerized software into Kubernetes. It is now time to gain a deeper insight into Kubernetes cluster administration.

In this chapter, we'll learn about the following topics:

• Utilizing namespaces to set administrative boundaries
• Using kubeconfig to switch between multiple clusters
• Kubernetes authentication
• Kubernetes authorization
• Dynamic admission control
• Kubernetes Custom Resources Definition (CRD) and controllers

While minikube is a fairly simple environment, we will use the Google Kubernetes Engine (GKE) in this chapter. For cluster deployment in GKE, please refer to Chapter 11, Kubernetes on GCP.

...

Kubernetes namespaces

We already learned about Kubernetes namespaces in Chapter 3, Getting Started with Kubernetes, which are used to divide the resources from a cluster into multiple virtual clusters. Namespaces make each group share the same physical cluster with isolation. Each namespace provides the following:

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

Now, let's learn how to use context to switch between different namespaces.

Context

Context is the concept of the combination of cluster information, a user for authentication, and a namespace. For example, the following is the context information...

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 and the kubectl config current-context command to check the context you're currently using. The following is an example of a GCP cluster in a kubeconfig file:

# kubectl config view
apiVersion: v1
clusters:  
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://35.0.0.200
  name: gke_devops-with-kubernetes_us-central1-b_cluster
contexts:
- context:
    cluster: gke_devops-with-kubernetes_us-central1-b_cluster
    user: gke_devops-with-kubernetes_us-central1-b_cluster
  name: gke_devops-with-kubernetes_us-central1-b_cluster
current-context: gke_devops-with-kubernetes_us-central1-b_cluster
kind: Config
preferences: {}
users:
- name: gke_devops-with-kubernetes_us-central1-b_cluster
  user:
    auth-provider:
      config:
...

Service account

In Kubernetes, there are two kinds of user account: service account and user account. All the requests to the API server are sent either by a service account or a user account. Service accounts are managed by the Kubernetes API. In contrast, user accounts are not managed and stored in Kubernetes. The following is a simple comparison of service and user accounts:

	Service account	User account
Scope	Namespaced	Global
Used by	Processes	Normal user
Created by	API server or via API calls	Administrators, not by API calls
Managed by	API server	Outside the cluster

By default, a Kubernetes cluster creates different service accounts for different purposes. In GKE, there are a bunch of service accounts that have been created:

// list service account across all namespaces
# kubectl get serviceaccount --all-namespaces
NAMESPACE     NAME                      ...

Authentication and authorization

Authentication and authorization are important components in Kubernetes. Authentication verifies users and checks that the user is who they claim 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 access control when it receives a request:

Access control in the Kubernetes API server

When the request goes to the API server, first 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 moves into the authentication stage. In Kubernetes, authentication...

Admission control

Admission control takes place before Kubernetes processes the request and after authentication and authorization is passed. It's enabled when launching an API server by adding the --admission-control parameter. Kubernetes recommends having the following plugins within the cluster if the cluster version is greater than or equal to 1.10.0:

--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota

The following sections introduce these plugins and why we need them. For the latest information about supported admission control plugins, please visit the official documentation: https://kubernetes.io/docs/admin/admission-controllers.

NamespaceLifecycle...

Custom resources

Custom resources, which were first introduced in Kubernetes 1.7, were designed as an extension point to let users create custom API objects and act as native Kubernetes objects. This was done so that users could extend Kubernetes to support the custom objects for their application or specific use cases. Custom resources can be dynamically registered and unregistered. There are two ways to create custom resources: by using a CRD or aggregated API. CRDs are much easier, while an aggregated API requires additional coding in Go. In this section, we'll learn how to write a CRD from scratch.

Custom resources definition

Creating a Custom Resources Definition (CRD) object includes two steps: CRD registration...

Summary

In this chapter, we learned about what namespace and context are, including how they work, and a how to switch between a physical cluster and virtual cluster by setting the context. We then learned about an important object—service account, which provides the ability to identify processes that are running within a pod. Then, we familiarized ourselves with how to control access flow in Kubernetes. We learned what the difference is between authentication and authorization, and how these work in Kubernetes. We also learned how to leverage RBAC to have fine-grained permission for users. In addition, we looked at a couple of admission controller plugins and dynamic admission controls, which are the last goalkeepers in the access control flow. Finally, we learned about what the CRD is and implemented it and its controller via the operator SDK (https://github.com/operator...