# CKA study: day 3-5

## Workloads

Linked with Pods explained in [the last post](https://won.hashnode.dev/cka-study-day-2), we will continue to explore workload resources in k8s. These will include: `ReplicaSet`, `Deployment` for now.

### ReplicaSet

`ReplicaSet`, which is replacing `ReplicationController`, ensures a specified number of specific pods are running in the cluster. Hence when there is room for multiple pods, it can provide **High Availability**(HA) for the application. Even if only one pod is running, it provides basic **Disaster Recovery**(DR) and keeps the application downtime as small as possible. Other uses include **Load-balancing**(LB) followed by a need to **scale out** the application.

### Deployment

Rather than using `ReplicaSet` directly, it is recommended to use `Deployment` as a kind of wrapper when dealing with *stateless* applications: where it doesn't matter if pods are replaced suddenly. Deployments create a `ReplicaSet` every time it is revised, and the number retained is [adjustable](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#clean-up-policy) by `spec.revisionHistoryLimit` (default is 10). Having several backups enables seamless **rollbacks**/**rolling updates**. Pods in outdated ReplicaSets all stop to preserve resources. (help: [abbreviations of resource types](https://kubernetes.io/docs/reference/kubectl/#resource-types))

```bash
# deployment named example with nginx image and 5 replicas
kubectl create deploy example --image=nginx -r 5
```

## Networking

We touched on this topic a little on [day 2](https://won.hashnode.dev/cka-study-day-2#heading-kube-proxy) when discussing `kube-proxy`. There are vast improvements ongoing with [CNI](https://github.com/containernetworking/cni) that I don't quite understand, so later I will make another post about that.

### Services

Again this blog [post](https://mayankshah.dev/blog/demystifying-kube-proxy/#services) by Mayank Shah is gold. There are three `ServiceTypes` for publishing a service. `Question: where does ingress fall into this?`

* `NodePort`: as the name suggests, a virtual port to handle I/O of a node.
    
* `ClusterIP`(default): internal I/O for a cluster. `NodePort` also uses `ClusterIP` internally.
    
* `LoadBalancer`: uses an external cloud provider's load balancer to handle the traffic.
    

You might look into `metallb` for using `LoadBalancer` on local, but with `k3s`(❤️) it comes [built-in](https://docs.k3s.io/networking#service-load-balancer).

## Namespaces

> Kubernetes namespaces are comparable to Linux namespaces. However, **Kubernetes manages namespaces in a declarative style**. The simple clean-up process is central to managing operations at scale and the cluster management add-ons such as [role-based access control (RBAC)](https://kubernetes.io/docs/reference/access-authn-authz/rbac/), making namespaces even more powerful. - Red Hat Cloud Blog, [K8S namespaces demystified](https://cloud.redhat.com/blog/kubernetes-namespaces-demystified-how-to-make-the-most-of-them)

## Scheduling

### Manual

### Node Selectors

### Taints and Tolerations

### Node (Anti)Affinity

## Lab notes

```bash
# count number of pods in default namespace
kubectl get po --no-headers | wc -l

# image of a ReplicaSet named 'new-replica-set'
kubectl get rs/new-replica-set -o jsonpath="{..image}"

# create service named webapp-service as a NodePort
# with port=8080, targetPort=8080, nodePort=30080
# and selector simple-webapp from service-definition-1.yaml
kubectl create svc nodeport webapp-service --tcp=8080 --node-port=30080 --dry-run=client -o yaml | kubectl set selector --local -f - 'name=simple-webapp' -o yaml > service-definition-1.yaml && kubectl create -f service-definition-1.yaml

# create pod named httpd with httpd:alpine image and
# expose it via port 80 on a new service with the same name
kubectl run httpd --image=httpd:alpine && kubectl create svc clusterip httpd --tcp=80 --dry-run=client -o yaml | kubectl set selector --local -f - 'run=httpd' -o yaml | kubectl create -f -

# get default kube-scheduler status
kubectl get pods -n kube-system -l component=kube-scheduler

# check for taints on a node named node01
kubectl get no/node01 -o jsonpath='{..taints}'

# taint the node named node01
kubectl taint no node01 spray=mortein:NoSchedule
```

If there are more elegant ways, please leave a comment. I would love to know them.