Topics Covered:

The Kubernetes Cluster Architecture
Building our Kubernetes Cluster
- Kubeadm Installation and Deep Dive
- Understanding Kubernetes Static Pods
- Understanding CNI
- Working with Kubectl context and kubeconfig
- Working with Role Base Accessed Control
Maintaining the Cluster
- Managing the certs and rotation
- Upgrading the Cluster
- Backing up the etcd

The Kubernetes Architecture

Control Plane

API Server - handles the request from client such as kubectl. Responsible for authentication and authorization of request.
Etcd - stores the state of the cluster and its configurations
Scheduler - schedule a pod to a node.
Controller - runs an infinite loop to maintain the desired state to the current state (e.g. cronjobs, daemonsets, replicasets)

Worker Plane

Kubelet - receives instruction from the scheduler then assigns the Pods to a Container Runtime
Container Runtime - allows a pod/containers to be runnable. Eg. docker, cri-o
Kubeproxy - forward the request to the appropriate service and endpoints.

Building Our Kubernetes Cluster

Kubernetes Installation via kubeadm

devopscube.com/setup-kubernetes-cluster-kub..

Good to know:

Container runtime (either containerd or cri-o). It allows us to run container in host system. Check the image below how container runtime fits in the process. Image from phoenixnap.com

An infographic illustrating the container ecosystem.

Understanding Kubernetes Static Pods

These are the pods that are created when boostrapping a cluster via kubeadm on the kube-system :

coredns - default dns for kubernetes. Provides service discovery and resolving dns names. DNS allows us to map a name to an IP. Allows use of external domain name.
kube-proxy - forward the request for appropriate endpoints and services. acts as a proxy, intercepts a traffic and redirect to specific service.
etcd - store the state of the cluster. Responsible for persisting configuration. (Stores endpoint)
apiserver - handles incoming requests from kubectl and others. Responsible for aut
scheduler - schedules pods to worker nodes
controller - runs an infinite loop to maintain the desired state to the current state (e.g. cronjobs, daemonsets, replicasets)

Understanding Kubernetes Networking Plugin

There are two main purpose of Kubernetes Networking plugin:

Makes sure the cluster have L3 Connectivity. (Routing traffic to different environments [both at pods and node levels] )
Network Policy enforcement
IPAM

Working with Kubectl context and kubeconfig

A Kubernetes context consists of a cluster, a namespace, and a user and is the configuration used to access a specific cluster and namespace
Allows use to give access to specific user
Steps:
- 1. Create a user

    adduser team-readonly
    passwd team-readonly

2. Create keypairs and certificate

    openssl genrsa -out team-readonly.key 2048

    openssl req -new -key team-readonly.key \
    -out team-readonly.csr -subj "/CN=team-readonly"

    sudo openssl x509 -req -in team-readonly.csr \
    -CA /etc/kubernetes/pki/ca.crt \
    -CAkey /etc/kubernetes/pki/ca.key \
    -CAcreateserial \
    -out team-readonly.crt -days 360

3. Update kubeconfig to include the keypair and certificate and team-readonly user


    kubectl config set-credentials team-readonly \
    --client-certificate=team-readonly.crt \
    --client-key=team-readonly.key

4. Create a new context. Including user, namespace and cluster

    kubectl config set-context nontechnical-view \
    --cluster=kubernetes \
    --namespace=databases \
    --user=team-readonly

5. Add RBAC to the user
- Create role / cluster role
- Create rolebinding / cluster rolebinding

    kind: Role
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      namespace: databases  # Same namespace as the one in the context
      name: team-readonly
    rules:
    - apiGroups: ["", "extensions", "apps"]
      resources: ["deployments", "replicasets", "pods", "nodes"]
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] 

    ---
    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: team-readonly-role-binding
      namespace: databases
    subjects:
    - kind: User      # Here we say it's a normal user and not a service account
      name: team-readonly  # Here is where we define the user we created and defined in the context
      apiGroup: ""
    roleRef:
      kind: Role
      name: team-readonly
      apiGroup: ""

Check this: https://kubernetes.io/docs/reference/access-authn-authz/rbac/

Working with Role Base Accessed Control

Different users/groups == different level access. (cluster level, namespace level, resources, verbs access, particular application, api groups etc)
Roles and Cluster roles containes (resources, verbs) that is rolebinded (rolebinding) to users/groups/service accounts.
Elements:
- Cluster role / role
- Cluster rolebinding / rolebinding
- Users Groups and Service Accounts

Maintaining the Cluster

Managing the certs and rotation
Upgrading the Cluster
Backing up the etcd

Those maintenance tasks above have different implementations, you can use a configuration management tool to automate the process.

Cloud Native Philippines