> For the complete documentation index, see [llms.txt](https://petercheng7788.gitbook.io/developer-note/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://petercheng7788.gitbook.io/developer-note/devop/kubernetes.md).
# Kubernetes
## Introduction
* It is a container orchestration tool to sustain high availability, scalability, but also used for disaster recovery (backup and restore)
## Architecture
* A cluster is made up of a **master node and couples of worker node**
### Namespace
* Namespaces are **intended for use in environments with many users spread across multiple teams**, or projects. For clusters with a few to tens of users, you should not need to create or think about namespaces at all. Start using namespaces when you need the features they provide.
* Namespaces are a way to **divide cluster resources** between multiple users
* Prevent resource starvation: By setting resource quotas, you can prevent individual pods or containers from consuming too many resources and causing resource starvation for other pods or containers running on the same node.
* Ensure fair resource allocation: Resource quotas can ensure that each namespace or user on the cluster receives a fair share of the available resources, preventing any one user or application from monopolizing resources.
* Enforce compliance and governance: Resource quotas can be used to enforce compliance and governance policies, such as limiting the amount of data that can be stored in a particular namespace or restricting the use of certain types of resources.
### Worker Node
* Each nodes contains kubelet. It is used to faciliate the communication with master node. For instance, kubelet receives the signal of starting container and uses the container runtime to start the pod and monitors its life cycle, including readiness and liveliness probes and reports back to kube-APIserver.
* Worker node is a actual work happening, it has containers of different applications deployed on it
### Master Node
* For **kube-APIserver**, you can **accept commands that view or change the state of the cluster**, including launching pods, so that you can use the kubectl command frequently
* **Etcd** is the clusters database, includes all of the cluster configuration data and more dynamic information, such as what nodes are part of the cluster, what pods should be running and where they should be running.
* **Kube-scheduler** is responsible for **scheduling pods onto nodes**, it discovers a pod object that doesn't yet have an assignment to a node, it chooses a node and simply writes the name of that node into the pod object.
* **Kube-controller-manager** continuously monitors the state of the cluster through kube APIserver, Whenever the current state of the cluster doesn't match the desired state, kube-controller-manager will attempt to **make changes to achieve the desired state**.
## Volume
* There are several types of volume
### emptyDir
* Temporary storage that exists only during pod lifetime
* Data is lost when pod is deleted
```yaml
volumes:
- name: cache-volume
emptyDir: {}
```
### hostPath
* Mounts a directory from the host node's filesystem
* Data persists pod restarts but tied to specific node
* Good for accessing node logs or docker socket
```yaml
volumes:
- name: docker-socket
hostPath:
path: /var/run/docker.sock
```
### ConfigMap
* For mounting configuration data as files
* Read-only by default
```yaml
volumes:
- name: config-volume
configMap:
name: my-config
```
### Azure Key Vault CSI Driver Volume
* Type: `csi` (Container Storage Interface).
* It uses the **Secrets Store CSI Driver to reach out to Azure Key Vault** (authenticated using `kvcreds-hk01-r-intl-ifa01`) which is **Kubernetes Secret that stores the authentication credentials used by the Azure Key Vault Secrets Store CSI Driver**
* It **mounts the secrets/certificates defined in the `secretProviderClass`** (`spc-app-ifa-integration-pro-api-deployment`) directly into your application container as read-only files.
{% code title="" %}
```yaml
volumes:
- name: secrets-store-inline
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: spc-app-ifa-integration-pro-api-deployment
nodePublishSecretRef:
name: kvcreds-hk01-r-intl-ifa01
```
{% endcode %}
### PersistentVolume (PV) and PersistentVolumeClaim (PVC)
* For persistent storage that survives pod restarts
```yaml
volumes:
- name: data-volume
persistentVolumeClaim:
claimName: my-pvc
```
```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteOnce # Can be mounted as read-write by a single node
resources:
requests:
storage: 10Gi # Requesting 10GB of storage
storageClassName: standard # What kind of storage to use
```
#### Storage Class
* Defines what type of storage you want
* Determines storage characteristics like:
* Performance (IOPS, throughput)
* Reliability
* Backup policies
* Cost tier
* Here is an example
```yaml
# Storage Class Definition
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: fast-storage
provisioner: diskplugin.csi.alibabacloud.com
parameters:
type: cloud_essd # The type of storage
reclaimPolicy: Delete # how to handle when storage is deleted
---
# PVC using the Storage Class
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: database-storage
spec:
storageClassName: fast-storage
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100Gi
---
# Pod using the PVC
apiVersion: v1
kind: Pod
metadata:
name: database-pod
spec:
containers:
- name: database
image: mysql:5.7
volumeMounts:
- name: storage
mountPath: /var/lib/mysql
volumes:
- name: storage
persistentVolumeClaim:
claimName: database-storage
```
## Volume Mount
* To attach the volume to the container path
```yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: counter
spec:
replicas: 3
selector:
matchLabels:
app: counter
template:
metadata:
labels:
app: counter
spec:
containers:
- name: counter
image: "kahootali/counter:1.1"
# Mount volume to container path
volumeMounts:
- name: counter
mountPath: /app/
# Declare the volume
volumes:
- name: counter
persistentVolumeClaim:
claimName: counter
```
## Resource Management
```yaml
resources:
limits:
cpu: 500m
memory: 1024Mi
requests:
cpu: 500m
memory: 1024Mi
```
* Resource Management can be declared as a part of deployment file
* A resource request is the amount of CPU and memory that a container requires to run, and it is used by Kubernetes to allocate resources to the container when it is scheduled to run on a node. When a container with a resource request is scheduled to run on a node, Kubernetes will find a node that has enough available resources to meet the container's request, and then allocate those resources to the container.
* A resource limit, on the other hand, is the maximum amount of CPU and memory that a container is allowed to consume. If a container exceeds its resource limit. When a process in the container tries to consume more than the allowed amount of memory, the system kernel terminates the process that attempted the allocation, with an out of memory (OOM) error.
## Health Detection
```yaml
livenessProbe:
httpGet:
path: /v1/health
periodSeconds: 300
successThreshold: 1
failureThreshold: 5
readinessProbe:
httpGet:
path: /v1/health
```
* Liveness probes are crucial for ensuring your application stays up and running. If a liveness probe fails, Kubernetes will restart the pod to restore service.
* Readiness probes check if your application is ready to receive requests. If a readiness probe fails, Kubernetes will remove the pod’s IP address from the service load balancer. This ensures no requests are forwarded to the pod until it becomes ready again.
## Service Discovery
* A cluster-aware DNS server, such as CoreDNS, watches the Kubernetes API for new Services and creates a set of DNS records for each one. If DNS has been enabled throughout your cluster then all Pods should automatically be able to resolve Services by their DNS name.
* For example, if you have a Service called `my-service` in a Kubernetes namespace `my-ns`, the control plane and the DNS Service acting together create a DNS record for `my-service.my-ns`. Pods in the `my-ns` namespace should be able to find the service by doing a name lookup for `my-service` (`my-service.my-ns` would also work).
## Commands
```bash
# get pod list
kubectl get pods --namespace
# get the pod details
kubectl describe pod -n
# get the log of pod
kubectl logs -n
# go into the shell
kubectl exec --stdin --tty -- /bin/bash
# port forward
kubectl port-forward :
```
## References
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}
{% embed url="" %}