K8s with Kind Cluster Notes:

------------------------------

while (1) {kubectl get all;sleep 5;cls}

agenda:
-------
* Intro to kubernetes
* Setup kind local cluster
* Pods
* Replicaset
* Deployment
* services
* namespace
* probes
* configMap and secreat
* persitance volume and statefullness
* HPA - Horizontal pod autoscaling
* ingress

--------------------
Intro to kubernetes
--------------------

What is cloud native application development?

--------------------------------------------
an approach to develop mordern s/w (folling 12 factor/15 factor app)
HA, Scalable, responsive, fault tolerent
speed ang agility

Docker pre req?

-------------
Docker arch, docker images, containers, networking, port mapping, volumens, exec,
docker file etc

Docker vs k8s
Docker provide OS level abstraction
K8S provide infrastructure abs on cloud

What is docker?
open source plateform for packing the app + all dependencies + run time
server
seperate app from underlying host
OS abstraction

What is kubernetes?
Kubernetes is an open-source container orchestration system for automating
software deployment,
scaling, and management.

Originally designed by Google, the project is now maintained by the Cloud

Native Computing Foundation.

The name Kubernetes originates from Ancient Greek, meaning 'helmsman' or

'pilot'

container orchestration engine

 k8s manage life cycle of application
cluster of nodes
admin : will manage the cluster
dev : will use tools to develop cloud native app

kubernetes which is provided by cloud provide

kubernetes setup:

local setup: docker + kubectl + minikube/kind

cloud setup :

The four major Kubernetes providers are:

Google Kubernetes Engine (GKE):
Closely follows the latest changes in the Kubernetes open-source
project;

Azure Kubernetes Service (AKS):

Known for rich integration points to other Azure services

Amazon Elastic Kubernetes Service (Amazon EKS):

One of the late players in the Kubernetes arena; a strong option
due to AWS;

DigitalOcean Kubernetes (DOKS): The new Kubernetes service in the market.

https://k21academy.com/docker-kubernetes/kubernetes-installation-options/

How to do local setup while learing k8s:

---------------------------------------
kind cluster config
1. install kubectl (client utilty to interact with k8s infra)
2. kind cluster

kubernetes Arch:
-----------------
Master: also called control plan (1-more master for HA)
Worker: 1 to many (5000) to make a cluster

components of k8s:

Master node / control plan

-----------------------------
API server:
* Most important component, user intract with api server using
imparative/decleartive commands
* The API server is a component of the Kubernetes control plane
that exposes the Kubernetes API.
* The API server is the front end for the Kubernetes control
plane.
etcd:
* Consistent and highly-available key value store used as
Kubernetes'
backing store for all cluster data.
kube-scheduler:
* Workload scheduler
* Control plane component that watches for newly created Pods
with no assigned node,
and selects a node for them to run on.

kube-controller-manager:
* A process that continously monitor workload/nodes etc
* desired state vs current state kubernetes

Worker Node:
-----------
kubelet:
* An agent that runs on each node in the cluster.
It makes sure that containers are running in a Pod.
* It create and manage container inside a pod

* The kubelet takes a set of PodSpecs that are provided through

various mechanisms
and ensures that the containers described in those PodSpecs are
running and healthy.
The kubelet doesn't manage containers which were not created by
Kubernetes.

kube-proxy:
*kube-proxy is a network proxy that runs on each node in your
cluster,
implementing part of the Kubernetes Service concept.

* kube-proxy maintains network rules on nodes

* handle conmmunication among the nodes within the cluster

*These network rules allow network communication to your Pods

from network sessions
inside or outside of your cluster.

Container runtime:
*A fundamental component that empowers Kubernetes to run
containers effectively.
It is responsible for managing the execution and lifecycle of
containers within the Kubernetes
environment.

Kubernetes supports container runtimes such as containerd, CRI-O,

and any other implementation of the Kubernetes CRI (Container
Runtime Interface).

kubernetes working process:

-------------------------------

1. API server expose API to interact with kubernetes (using Kubectl)

2. Workload is the application that we want to run.

let assume we want to run 2 instances of nginx server

developer write yaml file and send req to api server

|
API server validate the request
|
API server authenticate/authorize the request
|
 API server store it into etcd db
etcd container all info about cluster
|
API server talk to the scheduler if he can run
2 intance of nginx
|
scheduler choose 2 worker node to run the workload and schedule it on worker
node
|
controller manager responsible for continously monitoring
the state of cluster.let assume one pod dies then,
controller manager find we need 2 instance and one is down
|
controller talk to API server
|
Scheduler pick another node to run the nginx instance

worker node how it works?

As JRE is required to run java app

in same way docker runtime is required to run container
docker of CRI is required on each node
|
let scheduler pick node1 and node2 to run 2 instance of nginx
|
API server inform kubelet (agent) (That is waiting for instruction of api
server) to run
intance of app1 and app2 then kubelet will create and manage containers

tools for local development

---------------------------
kubectl : command line utlility to intract with API server
command line tool to intract with kubernete master / API server

Kind: kind is used to create local cluster

to setp a kubernetes cluster for development and testing
kind vs minikube

verify installation:
kind version
kubectl version --output=yaml

Note: command remain same no matter what tool we are using :)

-----------------------
Setup kind local cluster
------------------------

docker system prune -af

docker network ls

ls ~/.kube/config

Step 1: create cluster configuration file

01-cluster.yaml
----------------
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: dev-cluster
nodes:
- role: control-plane
extraPortMappings:
- containerPort: 30001
hostPort: 30001
protocol: TCP
- role: worker
- role: worker

step 2: create kind cluster

-----------------------------
kind create cluster --config 01-cluster.yaml

to delete cluster:
kind delete cluster --name dev-cluster

What it do?
This will create local cluster with 3 nodes
1 master and 2 worker node

docker ps
command will list nodes
dev-cluster-worker-1
dev-cluster-worker-2
dev-cluster-control-plan-3
It will also create a bride network to conn bw different nodes

cat ~/.kube/config
will give information where the cluster, ip networking is running

Now kubectl able to talk to master check command

kubectl version --output=yaml

-------------
get all notes in the cluster

kubectl get nodes

to delete the cluster

kind delete cluster --name dev-cluster

Exploring kind cluster

-----------------------
docker ps

docker exec -it <cid> bash now we are inside the master node

cd /etc/kubernetes/manifests
ls -l will display all yaml file related to master node
 ps -aux process running within control plan

Now explore worker node:

-------------
Pods
-------------
* Pods are the smallest deployable units of computing that you can create and
manage in Kubernetes.

* A Pod (as in a pod of whales or pea pod) is a group of one or more

containers,

* with shared storage and network resources, and a specification for how to
run the containers

* collection of containers that can run on k8s

* workload is an application running on k8s cluster

* Pod is basic building block to create workload

* A pod can run one/ more containers

* only one of the container contain app other container run as helper
container

https://k21academy.com/docker-kubernetes/kubernetes-pods-for-beginners/

Command K8s
------------

to create k8s cluster

kind create cluster --config 01-cluster.yaml

to delete k8s cluster

kind delete cluster --name dev-cluster

get nodes in the cluster

kubectl get nodes

get pods in default ns

kubectl get pod

Pod hello world:

---------------
step 1: start cluster
step 2: create yaml file
step 3: run the command

Main Component of Pod manifest file:

 apiVersion:
kind:
metadata:
spec:

01-simple-pod.yaml
---------------
apiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: mypod
spec:
containers:
- name: mypod
image: nginx
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80

kubectl create -f 01-simple-pod.yaml

kubectl apply -f 01-simple-pod.yaml

kubectl get pod

kubectl describe pod

give valuable informatation to debug pod

watch -t -x kubectl get pod

watch -t -x kubectl get all

kubectl get pod/my-pod

kubectl get pod my-pod
kubectl get pod --show-labels

kubectl delete -f 01-simple-pod.yaml

02-falling-pod.yaml
------------------
apiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: mypod
spec:
containers:
- name: mypod
image: nginx:12
 resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80

create simple pod: 02-falling-pod.yaml : ImagePullBackOff

----------------------------------------
kubectl apply -f 02-failing-pod.yaml
kubectl describe pod

multiple pods:
03-multiple-pod.yaml
------------------------
apiVersion: v1
kind: Pod
metadata:
name: pod-1
labels:
dept: dept-1
team: team-a
spec:
containers:
- name: nginx
image: nginx
---
apiVersion: v1
kind: Pod
metadata:
name: pod-2
labels:
dept: dept-2
team: team-a
spec:
containers:
- name: nginx
image: nginx
---
apiVersion: v1
kind: Pod
metadata:
name: pod-3
labels:
dept: dept-3
team: team-b
spec:
containers:
- name: nginx
image: nginx

kubectl apply -f 03-multiple-pods.yaml

kubectl get pods
kubectl describe pod
getting an specfic pod
kubectl get pod pod-1

kubectl describe pod pod-1

pod displaying lables

kubectl get pod --show-labels

kubectl get pod -l dept=dept-1

kubectl get pod -l team!=team-a
kubectl get pod -l dept=dept-1,team=team-a

kubectl get pod pod-1 -o wide

kubectl get pods --output=wide

kubectl get pod pod-1 -o yaml

deleting an specfic pod

kubectl delete pod pod-2 delete/describe/get all works

kubectl delete pod/pod-2

Port forwarding
------------------
04-port-forwarding.yaml
-----------------------
apiVersion: v1
kind: Pod
metadata:
name: mypod
labels:
name: mypod
spec:
containers:
- name: mypod
image: nginx
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 80

create a tunnel from our machine to Pod

kubectl create -f 04-pod-port.yaml

kubectl get pod
kubectl port-forward my-pod 8080:80
agenda:
-----------
Replicaset
deployment
Deployment Strategy
Services
Namespace
probes

----------------
Replicaset
----------------

What is replicaset?
A ReplicaSet's purpose is to maintain a stable set of replica Pods running at
any given time.
As such, it is often used to guarantee the availability of a specified number
of identical Pods.

A ReplicaSet ensures that a specified number of pod replicas are running at

any given time.

desired state vs current state

Note: Deployment is a higher-level concept that manages ReplicaSets and

provides declarative updates to
Pods along with a lot of other useful features.
Therefore, we recommend using Deployments instead of directly using
ReplicaSets

metadata:
name: empapp
labels:
name: empapp
spec:
containers:
- name: empapp
image: rgupta00/empapp:1.1
resources:
limits:
memory: "128Mi"
cpu: "500m"
ports:
- containerPort: 8080

Example:
01-simple-rs.yaml
-----------------
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-rs
spec:
 selector:
matchLabels:
app: my-app
replicas: 3
template:
metadata:
name: my-pod
labels:
app: my-app
spec:
containers:
- name: nginx
image: nginx

kubectl create -f 01-simple-rs.yaml

kubectl get rs
kubectl get all
kubectl get pod --show-labels

kubectl delete pod my-rs-j9k6l

new pod is create as we have mentioned desire count =3

kubectl delete rs my-rs

will delete replicaset

What happen if label is not matching pod label is not matching with Replicaset
---------------------------------------------------------------------------------
02-mismatch.yaml
-----------------
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: my-rs
spec:
selector:
matchLabels:
app: my-app-foo
replicas: 3
template:
metadata:
name: my-pod
labels:
app: my-app
spec:
containers:
- name: nginx
image: nginx

kubectl apply -f 02-mismatch.yaml

The ReplicaSet "my-rs" is invalid: spec.template.metadata.labels: Invalid value:

map[string]string{"app":"my-app-foo"}: `selector` does not match template `labels`
Note: You can have multiple labels but one must match

Replicaset with existing pod

---------------------------
let say we have desire state =3
if we alreay have 1 pod otherwise with same labels, and then running kubectl apply
-f 01-mismatch.yaml
then only 2 pod will be create

kubectl apply -f 02-multiple-pods.yaml

kubectl apply -f 03-existing-pod-manager.yaml

What happen if desire count is =2 and you alreay have 3 container running with same
labels
then one pod is deleted

---------------------
Deployment
---------------------
What is deployment?

A Kubernetes Deployment tells Kubernetes how to create or modify instances of

the pods that hold
a containerized application.

Deployments can help to efficiently scale the number of replica pods,

enable the rollout of updated code in a controlled manner,
or roll back to an earlier deployment version if necessary.

What are the benefits of using a Kubernetes Deployment?

Kubernetes saves time and migrate errors by automating the work and
repetitive manual functions involved in deploying, scaling, and updating
applications in production.

Since the Kubernetes deployment controller continuously monitors the health

of pods and nodes,
it can make changes in real-time—like replacing a failed pod or bypassing
down nodes—to ensure
the continuity of critical applications.

Deployments automate the launching of pod instances and ensure they are
running as
defined across all the nodes in the Kubernetes cluster.

Faster deployments with fewer errors.

Very Important:
---------------
 Deployement ----> replicaset --> pod

01-simple-deploy.yaml
-----------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deploy
spec:
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: nginx
image: nginx

kubectl apply -f 01-simple-deploy.yaml

kubectl get all

exec inside pod

kubectl exec -it pod/my-deploy-5c5b7bc6d7-bvwpc bash

kubectl get deployment

describe deployment:
kubectl describe deploy

getting logs of specific container that is inside a pod:

kubectl logs deploy/my-deploy will show log of any one container that is
running inside a pod
kubectl logs pod/my-deploy-5c5b7bc6d7-bvwpc

port forwarding:
kubectl port-forward deploy/my-deploy 8080:80

02-deploy-rs.yaml
--------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
spec:
selector:
matchLabels:
app: empapp-service
replicas: 2
template:
metadata:
 labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
ports:
- name: "app-port"
containerPort: 8080

kubectl describe pod

give valuable informatation to debug pod

Deployment revision
--------------------
Note : if we are changing no of pods that is managed in a deployment it dont
change
deployment revision

Whenever we update the pod template then ur are changing application

configuration and it is consider new revision

Exmaple 1: if u are just changing the desire pod count it is not consider new
revision
Example 2: if u change the version of application it is conider new
deployment

https://spacelift.io/blog/kubernetes-deployment-strategies

kubectl apply -f 02-deploy-rs.yaml

kubectl get all

exec inside pod

kubectl exec -it pod/my-deploy-5c5b7bc6d7-bvwpc bash

kubectl get deployment

port forwarding
kubectl port-forward deploy/empapp-deploy 8080:8080

Annotations in kubernetes:
---------------------------
have special meaning for k8s
it is the way to pass some editional informationation using anntations

annotations:
kubernetes.io/change-cause: "deploying v3"

way to tell kubernete to show change cause when showing rollout history
kubectl rollout history deploy
03-deploy-rollout.yaml
---------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v3"
spec:
selector:
matchLabels:
app: empapp-service
replicas: 2
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.3
imagePullPolicy: Always
ports:
- name: "app-port"
containerPort: 8080

kubectl apply -f 02-deploy-rs.yaml

kubectl get all

exec inside pod

kubectl exec -it pod/my-deploy-5c5b7bc6d7-bvwpc bash

kubectl get deployment

port forwarding
kubectl port-forward deploy/empapp-deploy 8080:8080

Rollout history
---------------
Switching from 1.1 to 1.2

checking rollout history:

-------------------------
kubectl rollout history deploy

let assume there is bug in 1.2 and we want to migrate from 1.2 to 1.1

kubectl rollout undo deploy/empapp-deploy

if you want to see more details:

kubectl rollout history deploy --revision=1

if we want to go to an specific version: (imp)

kubectl rollout undo deploy/empapp-deploy --to-revision=2

now if we do port forwarding we switch version to previous version

kubectl port-forward deploy/empapp-deploy 8080:8080

Min ready seconds:

------------------
spring boot may take few second before it ready
we can put this inforation in deployment file

health check and probes: will be proper way to do this

will be done latter

Ex: 04-min-ready-seconds.yaml
-----------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v1"
spec:
minReadySeconds: 10
selector:
matchLabels:
app: empapp-service
replicas: 2
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
ports:
- name: "app-port"
containerPort: 8080

Recreate strategy
-----------------
05-deploy-recreate.yaml
-------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v2"
spec:
minReadySeconds: 10
strategy:
 type: Recreate
selector:
matchLabels:
app: empapp-service
replicas: 2
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.2
ports:
- name: "app-port"
containerPort: 8080

strategy:
type: Recreate

Switching from v1 to v2
kubectl rollout history deploy

In this strategy extra pod are not created

already existing pod first deleted and then new one are created

Ex: 05-deploy-recreate.yaml

RollingUpdate strategy with maxSurge: 1 or 100%

------------------------------------------------------
maxSurge: 1 and maxSurge: "100%"

Note: temparory pod count get double once all pod are ready old pod are deleted
that is the
meaning of maxSurge of 100%

What is the meaning of maxSurge:1 we are ok with one extra pod

spec:
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1

Switching from v1 to v2
kubectl rollout history deploy

06-deploy-max-surge.yaml
------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v2"
spec:
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: "100%"
selector:
matchLabels:
app: empapp-service
replicas: 3
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.2
ports:
- name: "app-port"
containerPort: 8080

maxUnavailable
----------------
spec:
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0

here we are saying dont create extra pod it is

ok if one pod is not available during rolling update

07-deploy-max-unavailable.yaml
-------------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v2"
spec:
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 0
maxUnavailable: 1
selector:
matchLabels:
app: empapp-service
replicas: 3
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.2
ports:
- name: "app-port"
containerPort: 8080

-----------------------
Service
-----------------------

* Logical abstraction for a set of pods

* A single reliable network endpoints to access pods
statble IP address
DNS name

we get statble ip address and dns name to access the application

during rolling update when once pod recread its ip address changes
it create problem if one pod connect to that pod

logicall group a set of pod so that another application can

connect using logical name

Type of services
------------------
* clusterIP (within)
* NodePort (External)
* Load balancer(External)

watch -t -x kubectl get all

kubectl apply -f 01-nodeport-service.yaml

kubectl get all

service/empapp-svc NodePort 10.96.170.39 <none> 8080:30001/TCP 113

now we can connect to the service using

curl localhost:30001/hello-world

http://localhost:30001/hello-world

01-nodeport-service.yaml
---------------------------

apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v1"
spec:
minReadySeconds: 10
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: "100%"
selector:
matchLabels:
app: empapp-service
replicas: 3
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
ports:
- name: "app-port"
containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: empapp-svc
spec:
type: NodePort
selector:
app: empapp-service
ports:
- port: 8080
targetPort: 8080
nodePort: 30001

--------------------
Namespace
---------------------
get all existing namespaces
 ---------------------------------
kubectl get ns

NAME STATUS AGE

default Active 4h2m
kube-node-lease Active 4h2m
kube-public Active 4h2m
kube-system Active 4h2m
local-path-storage Active 4h2m

namespace started with kube are reserved for kubernetes cluster

kube-system is super important

let see what is running under kube-system

kubectl get all -n kube-system

to get all pods from all namespaces: (imp)

kubectl get pod --all-namespaces

creating namespace
----------------------
kubectl create ns dev
kubectl create ns qa

get pod in dev ns

-------------------
kubectl get pod -n dev

apply yaml config for dev ns

-------------------------
kubectl apply -f 01-ns-demo -n dev

get all resouces in dev ns

-------------------
kubectl get all -n dev

delete all resouces from dev ns

-------------------------
kubectl delete -f 01-ns-demo -n dev

delete all resources from qa namespace

----------------------------
kubectl delete ns qa

01-ns-demo.yaml
-----------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
namespace: dev
annotations:
kubernetes.io/change-cause: "deploying v1"
spec:
minReadySeconds: 10
 strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: "100%"
selector:
matchLabels:
app: empapp-service
replicas: 3
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
ports:
- name: "app-port"
containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
name: empapp-svc
spec:
type: NodePort
selector:
app: empapp-service
ports:
- port: 8080
targetPort: 8080
nodePort: 30002

understanding kube-system
-----------------------------

kubectl get pod -n kube-system

it gives lods of pod running under kube-system as pod

kindnet is CNI plugin to provide networking amongs different nodes
CoreDNS is a dns server translate logical name to ip address

NAME READY STATUS RESTARTS

AGE
coredns-5d78c9869d-jhzcl 1/1 Running 0
4h12m
coredns-5d78c9869d-nq26f 1/1 Running 0
4h12m
etcd-dev-cluster-control-plane 1/1 Running 0
4h12m
kindnet-hbc26 1/1 Running 0
4h12m
kindnet-n9wkw 1/1 Running 0
4h12m
kindnet-p4vps 1/1 Running 0
4h12m
kube-apiserver-dev-cluster-control-plane 1/1 Running 0
4h12m
kube-controller-manager-dev-cluster-control-plane 1/1 Running 0
4h12m
kube-proxy-6t68m 1/1 Running 0
4h12m
kube-proxy-kql6j 1/1 Running 0
4h12m
kube-proxy-xjnxm 1/1 Running 0
4h12m
kube-scheduler-dev-cluster-control-plane 1/1 Running 0
4h12m

probes:
---------
pods are consider to be live and health as soon as container started by pod
if pod is ready
service will send request to to the pod
rollingUpdate will terminate older pods
we should ensure that our pods are live and ready to avoid any surprises.

01-startup-prob.yaml
--------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v1"
spec:
minReadySeconds: 10
selector:
matchLabels:
app: empapp-service
replicas: 2
template:
metadata:
labels:
app: empapp-service
spec:
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
startupProbe:
httpGet:
path: /
port: 8080
periodSeconds: 1
failureThreshold: 3
ports:
- name: "app-port"
containerPort: 8080

port forwarding
kubectl port-forward deploy/empapp-deploy 8080:8080
02-startup-tcpsocket.yaml
------------------------
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: mongo
image: mongo
startupProbe:
tcpSocket:
port: 27017
periodSeconds: 1
failureThreshold: 5

03-startup-exec.yaml
----------------------
# prefer httpGet / tcpSocket
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: nginx
image: nginx
startupProbe:
exec:
command:
- "cat"
- "/usr/share/nginx/html/index.html"
periodSeconds: 1
failureThreshold: 3

# create a separate healthcheck

# /bin/healthcheck

# exec:
# command:
# - "/bin/healthcheck"

04-liveness-probe.yaml
------------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v1"
spec:
minReadySeconds: 10
selector:
matchLabels:
app: empapp-service
 replicas: 2
template:
metadata:
labels:
app: empapp-service
spec:
terminationGracePeriodSeconds: 1
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
resources:
limits:
memory: "128Mi"
cpu: "500m"
startupProbe:
httpGet:
path: /
port: 8080
periodSeconds: 1
failureThreshold: 3
livenessProbe:
httpGet:
path: /
port: 8080
periodSeconds: 1
failureThreshold: 3
ports:
- name: "app-port"
containerPort: 8080

05-readiness-probe.yaml
--------------------
apiVersion: apps/v1
kind: Deployment
metadata:
name: empapp-deploy
annotations:
kubernetes.io/change-cause: "deploying v1"
spec:
minReadySeconds: 10
selector:
matchLabels:
app: empapp-service
replicas: 2
template:
metadata:
labels:
app: empapp-service
spec:
terminationGracePeriodSeconds: 1
containers:
- name: empapp-service
image: rgupta00/empapp:1.1
resources:
limits:
memory: "128Mi"
cpu: "500m"
startupProbe:
httpGet:
 path: /
port: 8080
periodSeconds: 1
failureThreshold: 3
livenessProbe:
httpGet:
path: /
port: 8080
periodSeconds: 1
failureThreshold: 3
readinessProbe:
httpGet:
path: /
port: 8080
periodSeconds: 1
failureThreshold: 3
ports:
- name: "app-port"
containerPort: 8080

kubectl apply -f
kubectl describe pod/empapp-deploy-6bd885cff7-8wnvw
readness probe failed

Configmap and secret:

----------------------
In Kubernetes, ConfigMaps and Secrets are tools used to manage
configuration data and sensitive information in containerized applications:

ConfigMaps
Used to store non-sensitive configuration data, such as environment
variables or configuration files. ConfigMaps store data as key-value pairs,
and are typically defined in a YAML file. ConfigMaps are a good way to store
configuration data that might change across different deployment environments.

Secrets
Used to store sensitive information, such as passwords,
API keys, or TLS certificates. Secrets store data as base64-encoded data,
and are encrypted at rest. Secrets are created independently of the pods that use
them,
which reduces the risk of the secret being exposed

kubectl apply -f .\01-simple-cm.yaml

kubectl get all

kubectl get cm

kubectl get cm -o yaml

kubectl logs my-pod

01-simple-cm.yaml
---------------------
apiVersion: v1
kind: ConfigMap
metadata:
name: app-properties
data:
appUrl: "http://my-app-service"
timeout: "30"
---
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
resources:
limits:
memory: "128Mi"
cpu: "500m"
env:
- name: "request.timeout"
valueFrom:
configMapKeyRef:
name: app-properties
key: timeout
- name: "application.url"
valueFrom:
configMapKeyRef:
name: app-properties
key: appUrl
args:
- env

02-inject-cm-as-env.yaml
------------------------
now we want to insert all key-value in one go as env

apiVersion: v1
kind: ConfigMap
metadata:
name: app-properties
data:
appUrl: "http://my-app-service"
timeout: "30"
---
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
resources:
 limits:
memory: "128Mi"
cpu: "500m"
envFrom:
- configMapRef:
name: app-properties
args:
- env

02-inject-cm-as-env.yaml
------------------------
now we want to insert all key-value in one go as env

03-inject-cm-as-file.yaml
-------------------------
how to store multiline string as a file inside the pod
kubectl get cm
kubectl get cm kube-root-ca.crt -o yaml

kubectl apply -f .\03-inject-cm-as-file.yaml

03-inject-cm-as-file.yaml:
------------------------
apiVersion: v1
kind: ConfigMap
metadata:
name: app-properties
data:
application.properties: |
appUrl=http://my-app-service
timeout=30
a.b.c.d=something
username=raj
---
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
terminationGracePeriodSeconds: 1
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
resources:
limits:
memory: "128Mi"
cpu: "500m"
volumeMounts:
- name: config-volume
mountPath: /usr/share/props
args:
- sleep
- "3600"
volumes:
- name: config-volume
configMap:
name: app-properties
kubectl get all

now observe file inside container:

---------------------------------
kubectl exec -it my-pod -- bash
ls
cd /usr/share/props

Secret:
--------------------------
same as configMap but it is for sensitive data
value is base64 encoded
use cases:
ssh key file
basic credentials
etc

docker run -it ubuntu

echo raj | base64

echo -n raj | base64
cmFq

echo -n admin123 | base64

YWRtaW4xMjM=

Example:
04-simple-secret.yaml
--------------------
apiVersion: v1
kind: Secret
metadata:
name: app-secret
data:
username: cmFq
password: YWRtaW4xMjM=
---
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
restartPolicy: Never
containers:
- name: ubuntu
image: ubuntu
resources:
limits:
memory: "128Mi"
cpu: "500m"
env:
- name: "app_username"
valueFrom:
secretKeyRef:
name: app-secret
 key: username
- name: "app_password"
valueFrom:
secretKeyRef:
name: app-secret
key: password
args:
- env

now run it:

-----------
kubectl apply -f .\04-simple-secret.yaml
kubectl get all
kubectl get secret -o yaml
kubectl get pod
kubectl logs my-pod

Resource Management & Auto Scaling

-----------------------------------
how we can get cpu memory usages of pods?

kubectl top nodes

install materix service:

-----------------------

kubectl apply -f .\metrics-server.yaml

check if matrix server is install and ready:

----------------------------------------------

kubectl get pod -n kube-system

now try command to check cpu and memory usages:

--------------------------------------------

kubectl top nodes

NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%

dev-cluster-control-plane 143m 0% 676Mi 5%
dev-cluster-worker 37m 0% 234Mi 1%
dev-cluster-worker2 32m 0% 180Mi 1%

kubectl apply -f .\01-deploy-cpu-memory-usage.yaml

Now apply cpu usages:

kubectl top pods

now increse no of replica to 50, then run

now some of the pod is in pending state

kubectl get all

kubectl describe pod/my-deploy-76d58cdd59-22nr2

Warning FailedScheduling 84s

default-scheduler 0/3 nodes are available: 1 node(s) had untolerated
taint
{node-role.kubernetes.io/control-plane: }, 2 Insufficient cpu.
preemption: 0/3 nodes are available: 1 Preemption is not helpful for
scheduling, 2 No preemption victims found for incoming pod.

HPA template:
-------------
HPA stands for Horizontal Pod Autoscaler,
a Kubernetes feature that automatically scales the number of pods in a deployment
or replica set.
HPA is designed to handle varying user traffic by scaling up and down to meet
demand

https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale-
walkthrough/

hpa-template.yaml
----------------
it is monitoring the deployment and scale the pod the horizontally automatically
till now we are manually update no of pod
but we want to scale automatically in weekday less and in weekend is more

HorizontalPodAutoscaler: used to monitor deployment

kubectl apply -f 02-deploy-for-hpa.yaml

kubectl apply -f 03-hpa.yaml

kubectl get all

kubectl get hpa

kubectl exec -it demo-pod -- bash

ab -n 2000 -c 5 http://ngnix/

Ingress:
---------

Step 1:
----------
Nginx Ingress Controller
Applying below resource:

kubectl apply -f
https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/
provider/kind/deploy.yaml

delete old cluster to create new one:

kind delete cluster --name dev-cluster

create new cluster:

 kind create cluster --config .\01-cluster.yaml

docker ps

Example1:02-simple-ingress
-------------------

kubectl get ing

curl localhost

https://www.harness.io/blog/kubernetes-services-explained