Kubernetes Building Blocks

k8s Object Model

Object model representing different persistent entities in the k8s cluster.
Those entities describes:
- What containerized applications we are running and on which node.
- Application resources consumption.
- Different policies attached to applications, like restart/upgrade policies, fault tolerance, etc.
With each object we declare our intent spec section.
k8s system manages the status section for objects, where it records the actual state of the object.
k8s Control Plane tries to match the object's actual state to the object's desired state.
example of k8s object are:
- Pods
- ReplicaSets
- Deployments
- Namespaces
- etc.
Object defined below the spec field.
Object's configuration has to be submitted to the K8s API server.
The spec section describes the disired state, along with some basic information, such as the object's name.
The API request to create an object must have the spec section, as well as other details.
API servcer accepts object definition files in a JSON format.
Normally we use YAML format for the definition, then kubectl will convert into JSON payload and sent to the API server.

Example of Deployment object's configuration in YAML :

apiVersion: apps/v1
kind: Deployment
metadata:
    name: nginx-deployment
    labels:
        app: nginx
spec:
    replicas: 3
    selector:
        matchLabels:
            app: nginx
    template:
        metadata:
            labels:
                app: nginx
        spec:
            containers:
            - name: nginx
              image: nginx:1.15.11
              ports:
              - containerPort: 80

apiVersion field:
- first required field.
- it specifies the API endpoint on the API server
- must match an existing version for the object type defined.
kind :
- the second required field.
- specifying the object type. ( Deployment ), but it can be Pod, Replicaset, Namespace, Service, etc.
metadata :
- the third required field.
- holds the object's basic information.
spec (the first level, not the spec.template.spec)
- defining the desired state of the Deployment object.
- in example: 3 Pods are running at any given time.
- Pods are created using the Pods Template defined in spec.template.
- A nested object, such as the Pod being part of a Deployment, retains its metadata and spec and loses the apiVersion and kind - both being replaced by tempalte.
- In spec.template.spec we define the desired state of the Pod.
- Example Pod creates a single container running the nginx:1.15.11 image from Docker Hub
- Once the Deployment object is created, the k8s system attatches the status field to the object.

Pods

The smallest and simpletst k8s object.
the unit of deployment in k8s
represent a single instance of the application.
A logical collection of one or more containers, which:
- Are scheduled together on the same host with the Pod
- Share the same netwrok namespace
- Have access to mount the same external storage (volumes)
Pods are ephemeral in nature.
Pods do not hava the capability to self-heal by themselves.
Controllers handle Pod's replication, fault tolerance, self-healing etc.
Example of controllers are Deployments, ReplicaSets, ReplicaitonControllers etc.
We attatch a nested Pod's specification to a controller object using the Pod Template.
Example of a Pod object's configuration in YAML format:
```
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
labels:
    app: nginx
spec:
containers:
- name: nginx
    image: nginx:1.15.11
    ports:
    - containerPort: 80
```
- apiVersion field must specify v1 for the Pod object definition.
- The second required field is kind specifying the Pod object type.
- The third required field metadata, hold the object name and label.
- the fourth required field spec marks the beginning of the block defining the desired state of the Pod object - also named the PodSpec
- From Example above: it create a single container running the nginx:1.15.11 imge from Docker Hub.

Labels

Labels are key-value pairs attatched to k8s object e.g. Pods, ReplicaSets.
Labels are used to organaize and select a subset of objects based on the requirements in palce.
Many objects can have the same Label(s).
Labels(s) do not provide uniqueness to objects.
Controllers use Labels to logically group together decoupled objects, rather than using object's names or IDs.
- In the image above, we have used two label keys: app and env.
- The lavel *evn=dev logically selects and groups the top two Pods.
- The Label app=frontend logically selects and groups the left two Pods.
- We can select one of the four Pods - bottom left, by selecting two Labels: app=frontend and env=qa

Label Selectors

Controller use Label Selectors to select a subset of objects. K8s support two types of Selectors:
Equality-Based Selectors
- allow filtering of objects based on Label keys and values.
- Matching is achieved using the = , ==(equals, used interchangeably), or !=(not equals) operators.
  Example: env==dev or env=dev selecting the objects where the env Label key is set to value dev
Set-Based Selector
- filtering of ojbects based on a set of values.
- We can use In, NotIn operators for Label values.
- Uses Exists, DoesNotExist operators for Label keys.
- Example: env in (dev, qa) . <-- selecting objects where the env Label is set to either dev or qa
- Example: !app <-- select objects with no Label key app.

ReplicationControllers (ref)

No longer a recommended method.

Example:

apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
    app: nginx
template:
    metadata:
    name: nginx
    labels:
        app: nginx
    spec:
    containers:
    - name: nginx
        image: nginx
        ports:
        - containerPort: 80

it is a controller that ensures a specified number of replicas of a Pod is running at any given time.
if there are more Pods than the desired count, a replication controller would terminate the extra Pods.
If there are fewer Pods, then the replication controller would create more Pods to match the desired count.
Generally, we don't deploy a Pod independently, as it would not be able to re-start itself if terminated in error.
The recommended method is to use some type of replication controllers to create and manage Pods.
The default controller is a Deployment which configures a ReplicaSet to mange Pod's lifecycle.

ReplicaSets

A ReplicaSet is the next-generation ReplicationController.

Example :

apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
    app: guestbook
    tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
    matchLabels:
    tier: frontend
template:
    metadata:
    labels:
        tier: frontend
    spec:
    containers:
    - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3

It support both equality- and set-based selectors. (whereas ReplicationController s only supoort equality-based Selectors)
With the help of ReplicaSet, we can scale the nubmer of Pods running a specific container application image.
Scalling can be accomplished manually or through the use of an autoscaller
Example of graphical representaiton of a ReplicaSet, where we have set the replica count to 3 for a Pod.

ReplicaSet (Current State and Desired State are the same)
Assume that one of the Pods is forced to terminated(due to insufficient resoruces, timeout, etc) and the current state is no longer matching the desired state.

ReplicaSet (Current State and Desired State are different)
The ReplicaSet will detect that the current state is no longer matching the desired state. The ReplicaSet will create an additional Pod, thus ensuring that the current state matches the desired state.
ReplicaSet (Creating a Pod to Match Current an Desired States)
A Deployment automatically creates a ReplicaSet, which then creates a Pod.
There is no need to manage ReplicaSets and Pods separately.
The Deployment will manage them on our behalf.

Deployment.

Deployment objects provide declaration updatesto Pods and ReplicaSets.
The Deployment Controller is part of the master node's controller manager.
It ensure that the current state always matches the desired state.
It allows for seamless application updates and downgrades through rollouts and rollbacks.
It directly manages its ReplicaSets for application scaling.
Example:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
    app: nginx
spec:
replicas: 3
selector:
    matchLabels:
    app: nginx
template:
    metadata:
    labels:
        app: nginx
    spec:
    containers:
    - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
```
Deployment (ReplicaSet A Created)
- A new Deployment creates ReplicaSet A which then creates 3 Pods
- each Pod template configured to run one nginx:1.7.9 container image.
- In this case, the ReplicaSet A is associated with nginx: 1.7.9 representing a state of the Deployment.
- This particular state is recorded as Revision 1.
- Now, in the Deployment, we change to Pods' Template and we update the container image from nginx:1.7.9 to nginx:1.9.1.
- The Deployment triggers a new ReplicaSet B for the new container image versioned 1.9.1.
- This association represents a new recorded state of the Deployment, Revision 2
- The transition between the two ReplicaSets from A to B or from Revision 1 to Revision 2 is a Deployment rolling update.
  Deployment (ReplicaSet B Created)
- Once ReplicaSet B and its 3 Pods versioned 1.9.1 are ready, the Deployment starts actively managing them.
- The Deployment keeps its prior configuration states saved as Revisions which play a key factor in the rollback capability of the Deployment - returning to a prior known configuration state.
- In example, if the performance of the new nginx:1.9.1 isn't satisfactory, the Deployment can be rolled back to a prior Revision. In this case Revision 2 back to Revision 1 running nginx:1.7.9

Namespaces.

If multiple users and teams use the same k8s cluster, we can partition the cluster into virtual sub-cluster using Namespaces.
The names of the resources/objects created inside a Namespace are unique, but not across Namespaces in the cluster.

To list all the Namespaces.

$ kubectl get namespace
NAME              STATUS    AGE
default           Active    2d
kube-node-lease   Active    2d
kube-public       Active    2d
kube-system       Active    2d

Generally, k8s creates four default Namespaces:
- kube-system
  contains the objects created by the k8s system, mostly the control plane agents.
- kube-public
  is a special namespace, which is unsecured and readable by anyone, used for special purposes such as exposing public(non-sensitive) information about the cluster.
- kube-node-lease
  The newest Namespace. Holds node lease objects used for node heartbeat data.
- default
  contains the objects and resources create by administrators and developers. By default, we connect to the default Namespace.
Good practice, is to create more Namespace to virtualize the cluster for users and developer teams.
With Resource Quotas, we can divide the cluster resources within Namespaces.

Demo

create deployment.

$ kubectl create deployment mynginx --image=nginx:1.15-alpine
error: no matches for kind "Deployment" in version "extensions/v1beta1"

if we see that, chances are mismatch version as it says about version.
Cehck kubectl version.

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.1", GitCommit:"d4ab47518836c750f9949b9e0d387f20fb92260b", GitTreeState:"clean", BuildDate:"2018-04-12T14:26:04Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.2", GitCommit:"59603c6e503c87169aea6106f57b9f242f64df89", GitTreeState:"clean", BuildDate:"2020-01-18T23:22:30Z", GoVersion:"go1.13.5", Compiler:"gc", Platform:"linux/amd64"}

Tha it is, Client is versioned 1.10.1, while server is 1.17.2
Download kubectl

$ curl -LO https://storage.googleapis.com/kubernetes-release/release/v1.17.0/bin/windows/amd64/kubectl.exe

$ which kubectl
/cygdrive/c/ProgramData/chocolatey/bin/kubectl

$ mv kubectl.exe "c:\ProgramData\chocolatey\bin"

$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.0", GitCommit:"70132b0f130acc0bed193d9ba59dd186f0e634cf", GitTreeState:"clean", BuildDate:"2019-12-07T21:20:10Z", GoVersion:"go1.13.4", Compiler:"gc", Platform:"windows/amd64"}

Create deployment one more time.

$ kubectl create deployment mynginx --image=nginx:1.15-alpine
deployment.apps/mynginx created

To get deployment, replicaSet, Pod we can use

$ kubectl get deploy,rs,po
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mynginx   1/1     1            1           5m58s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mynginx-7d5785cdbd   1         1         1       5m58s

NAME                           READY   STATUS    RESTARTS   AGE
pod/mynginx-7d5785cdbd-bg8nm   1/1     Running   0          5m58s

to filter it with label

$ kubectl get deploy,rs,po -l app=mynginx
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mynginx   1/1     1            1           6m11s

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mynginx-7d5785cdbd   1         1         1       6m11s

NAME                           READY   STATUS    RESTARTS   AGE
pod/mynginx-7d5785cdbd-bg8nm   1/1     Running   0          6m11s

Now let's scale the previous deployment's replica to 3

$ kubectl scale --replicas=3 deploy/mynginx
deployment.apps/mynginx scaled

Verified the result

$ kubectl get deploy,rs,po -l app=mynginx
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mynginx   3/3     3            3           11m

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mynginx-7d5785cdbd   3         3         3       11m

NAME                           READY   STATUS    RESTARTS   AGE
pod/mynginx-7d5785cdbd-9tsrv   1/1     Running   0          47s
pod/mynginx-7d5785cdbd-bg8nm   1/1     Running   0          11m
pod/mynginx-7d5785cdbd-ms2xx   1/1     Running   0          47s

To describe deployment.

$ kubectl describe deploy mynginx
Name:                   mynginx
Namespace:              default
CreationTimestamp:      Mon, 24 Feb 2020 11:43:00 +0700
Labels:                 app=mynginx
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               app=mynginx
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=mynginx
  Containers:
   nginx:
    Image:        nginx:1.15-alpine
    Port:         <none>
    Host Port:    <none>
    Environment:  <none>
    Mounts:       <none>
  Volumes:        <none>
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    True    NewReplicaSetAvailable
  Available      True    MinimumReplicasAvailable
OldReplicaSets:  <none>
NewReplicaSet:   mynginx-7d5785cdbd (3/3 replicas created)
Events:
  Type    Reason             Age    From                   Message
  ----    ------             ----   ----                   -------
  Normal  ScalingReplicaSet  14m    deployment-controller  Scaled up replica set mynginx-7d5785cdbd to 1
  Normal  ScalingReplicaSet  3m34s  deployment-controller  Scaled up replica set mynginx-7d5785cdbd to 3

Check rollout history

$ kubectl rollout history deploy mynginx
deployment.apps/mynginx
REVISION  CHANGE-CAUSE
1         <none>

Revision 1 is associated to nginx:1.15-alpine and replicaSet of replicaset.apps/mynginx-7d5785cdbd
To get more details on revision 1

$ kubectl rollout history deploy mynginx --revision=1
deployment.apps/mynginx with revision #1
Pod Template:
  Labels:       app=mynginx
        pod-template-hash=7d5785cdbd
  Containers:
   nginx:
    Image:      nginx:1.15-alpine
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

but no revision 2

$ kubectl rollout history deploy mynginx --revision=2
error: unable to find the specified revision

Now let's update nginx image version. (Update can be downgrade or upgrade)

$ kubectl set image deployment mynginx nginx=nginx:1.16-alpine
deployment.apps/mynginx image updated

Check history

$ kubectl rollout history deployment mynginx
deployment.apps/mynginx
REVISION  CHANGE-CAUSE
1         <none>
2         <none>

Check revision 1 first

$ kubectl rollout history deployment mynginx --revision=1
deployment.apps/mynginx with revision #1
Pod Template:
  Labels:       app=mynginx
        pod-template-hash=7d5785cdbd
  Containers:
   nginx:
    Image:      nginx:1.15-alpine
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

Check revision 2

$ kubectl rollout history deployment mynginx --revision=2
deployment.apps/mynginx with revision #2
Pod Template:
  Labels:       app=mynginx
        pod-template-hash=5dfd47c855
  Containers:
   nginx:
    Image:      nginx:1.16-alpine
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

Check k8s objects of our app

$ kubectl get deployment,rs,pod -l app=mynginx
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mynginx   3/3     3            3           29m

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mynginx-5dfd47c855   3         3         3       4m47s
replicaset.apps/mynginx-7d5785cdbd   0         0         0       29m

NAME                           READY   STATUS    RESTARTS   AGE
pod/mynginx-5dfd47c855-n5ckf   1/1     Running   0          4m36s
pod/mynginx-5dfd47c855-nqz6r   1/1     Running   0          4m47s
pod/mynginx-5dfd47c855-vx9kl   1/1     Running   0          4m37s

we have the same deployment.
we have 3 pods are running.
the original replicaSet(7d5785cdbd) is now scaled down to zero.
the original replicaSet is recorded.

Let's rollback to revision 1

$ kubectl rollout undo deployment mynginx --to-revision=1
deployment.apps/mynginx rolled back

Let's check revision history

$ kubectl rollout history deployment mynginx
deployment.apps/mynginx
REVISION  CHANGE-CAUSE
2         <none>
3         <none>

Revision 1 (which is the original version) becomes Revision 3

$ kubectl rollout history deployment mynginx --revision=3
deployment.apps/mynginx with revision #3
Pod Template:
  Labels:       app=mynginx
        pod-template-hash=7d5785cdbd
  Containers:
   nginx:
    Image:      nginx:1.15-alpine
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>


$ kubectl rollout history deployment mynginx --revision=1
error: unable to find the specified revision


$ kubectl rollout history deployment mynginx --revision=2
deployment.apps/mynginx with revision #2
Pod Template:
  Labels:       app=mynginx
        pod-template-hash=5dfd47c855
  Containers:
   nginx:
    Image:      nginx:1.16-alpine
    Port:       <none>
    Host Port:  <none>
    Environment:        <none>
    Mounts:     <none>
  Volumes:      <none>

Check deployment object.

$ kubectl get deployment,rs,pod -l app=mynginx
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/mynginx   3/3     3            3           42m

NAME                                 DESIRED   CURRENT   READY   AGE
replicaset.apps/mynginx-5dfd47c855   0         0         0       18m
replicaset.apps/mynginx-7d5785cdbd   3         3         3       42m

NAME                           READY   STATUS    RESTARTS   AGE
pod/mynginx-7d5785cdbd-8625s   1/1     Running   0          6m58s
pod/mynginx-7d5785cdbd-fc69n   1/1     Running   0          7m
pod/mynginx-7d5785cdbd-fcb55   1/1     Running   0          6m55s

the original replicaSet is now scaled up to three.
the second replicaSet is now scaled down to zero.
by default, we can perform up to 10 consecutive rolling updates. And then we can then rollback to any one of those 10 recorded states.
Rolling updates and rollbacks are not specific for deployment only.

$ kubectl rollout --help
Manage the rollout of a resource.

 Valid resource types include:

  *  deployments
  *  daemonsets
  *  statefulsets

Examples:
  # Rollback to the previous deployment
  kubectl rollout undo deployment/abc

  # Check the rollout status of a daemonset
  kubectl rollout status daemonset/foo

Available Commands:
  history     View rollout history
  pause       Mark the provided resource as paused
  restart     Restart a resource
  resume      Resume a paused resource
  status      Show the status of the rollout
  undo        Undo a previous rollout

Usage:
  kubectl rollout SUBCOMMAND [options]

Use "kubectl <command> --help" for more information about a given command.
Use "kubectl options" for a list of global command-line options (applies to all commands).