What is NodePort Service in kubernetes ?

 NodePort:-

1. A NodePort service exposes the service on the IP of each node at a static port. A ClusterIP service is created automatically to route the traffic to the NodePort service. Users can communicate with the service from the outside by requesting <NodeIP>:<NodePort>

2. You can only use ports 30000–32767.

3. You can only have one service per port.

4. If you create a NodePort, then the endpoint service will also be created.

i) The node IP will be connected to nodeport 30010 and the 30010 port will be redirected to port 8081.

ii) 8081 will redirect to the port 80 endpoint.

# kubectl create deployment nodeport-deployment --image=nginx --replicas=2

# kubectl get deploy -o wide

# vim nodeport.yaml

apiVersion: v1

kind: Service

metadata:

  name: nginx-service

spec:

  type: NodePort

  selector:

    app: nodeport-deployment

  ports:

    - protocol: TCP

      port: 8081

      targetPort: 80

      nodePort: 30010

 

for svc

# kubectl get svc nginx-service -o wide

for pods

# kubectl get pods --show-labels

# kubectl get pods -o wide

Test NodePort with NodeIP.

For ClusterIP with endpoint Port.

What is Endpoints Service in k8s cluster ?

 Endpoint Services :

When you create a service in Kubernetes, it automatically creates an endpoint associated with that service. This endpoint is essentially a list of IP addresses and ports of the pods that the service is directing traffic to. So, when one application wants to talk to another application within the cluster, it looks up the endpoint associated with the target service to find out where to send its requests.

Why are required endpoints?

There is a front-end pod and a back-end application pod and all requests from the front-end go to the backend pod, If there is a redeployment in the backend pod, then IP has been changed for backend pods and the front-end pod will not be able to send requests to the backend, Its solution is done from the end-point.

# kubectl run frontend-pod --image=curlimages/curl --command -- sleep 3600

# kubectl run backend-pod --image=nginx

# kubectl get pods -o wide

# kubectl exec  -it frontend-pod -- sh

Curl to backend pods server from frontend pods.

Redeployment then Ip change.

For declarative way

# vim service.yaml

apiVersion: v1

kind: Service

metadata:

   name: clusterip-service

spec:

   ports:

   - port: 8080

     targetPort: 80

# kubectl apply -f service.yaml

# kubectl describe svc clusterip-service

Add the backend IP in the endpoint. But it’s a manual task.

# vim endpoint.yaml

apiVersion: v1

kind: Endpoints

metadata:

  name: clusterip-service

subsets:

  - addresses:

      - ip: 10.244.1.55

    ports:

      - port: 80

# kubectl apply -f endpoint.yaml

# kubectl get ep

# kubectl describe svc clusterip-service

# kubectl exec  -it frontend-pod -- sh

Hit to Endpoint 10.103.190.232:8080

ii)Using Selectors with endpoint in service:

Use case: if there are 500 Pods, we will have to manually define each IP in the endpoint.

Kubernetes allows us to define the list of labels of PODS that need to be added as part of Endpoints.

All Pods that match those labels will be added.

1.     Create deployment.

# vim demo-deployment.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.14.2

        ports:

        - containerPort: 80

# kubectl apply -f demo-deployment.yaml

For pods status :-

# kubectl get pods --show-labels

For deployment status :-

# kubectl get deployments -o wide

For replicaset status :-

# kubectl get rs -o wide

2. Creating Service.

# vim service-selector.yaml

apiVersion: v1

kind: Service

metadata:

   name: service-selector

spec:

   selector:

     app: nginx

   ports:

   - port: 80

     targetPort: 80

# kubectl apply -f service-selector.yaml

# kubectl get svc

# kubectl describe service service-selector

# kubectl get endpoints service-selector

# kubectl scale deployment/nginx-deployment --replicas=10

# kubectl describe service service-selector

# kubectl describe endpoints service-selector

From nodes :-

# curl 10.96.248.224:8080

for Imperative way

Port forwarding of pods.

# kubectl port-forward --address 0.0.0.0 pod/firstpod 8091:80

Port forwarding of services.

# kubectl port-forward --address 0.0.0.0 service/myfistservice 8090:8001

What is a ClusterIP services ?

 Cluster IP Setup:

ClusterIP is the default ServiceType. A Service gets its Virtual IP address using the ClusterIP. That IP address is used for communicating with the Service and is accessible only within the cluster.

# vim mysql.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: mysql

spec:

  replicas: 1

  selector:

    matchLabels:

      app: mysql

  template:

    metadata:

      labels:

        app: mysql

    spec:

      containers:

      - name: mysql

        image: mysql:latest

        ports:

        - containerPort: 3306

        env:

        - name: MYSQL_ROOT_PASSWORD

          value: shashi123

        - name: MYSQL_DATABASE

          value: test

        - name: MYSQL_USER

          value: test

        - name: MYSQL_PASSWORD

          value: test123

# kubectl apply -f mysql.yaml

# vim mysql-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: mysql-service

spec:

  selector:

    app: mysql

  ports:

    - protocol: TCP

      port: 3306

      targetPort: 3306

  type: ClusterIP

# kubectl get all

How to check container IP.

#  kubectl describe pods   mysql-77b47f887-8tjgl

# kubectl apply -f  mysql-service.yaml

# kubectl get pods 

# kubectl exec mysql-77b47f887-8tjgl -it bash

# echo "default_authentication_plugin=mysql_native_password" >> etc/my.cnf

bash-4.4# mysql -u root -p

ALTER USER 'test'@'%' IDENTIFIED WITH mysql_native_password BY 'test123';

# kubectl get svc mysql-service

# kubectl get endpoints

Test DB

# mysql -h 10.104.214.185 -u test -p3306 -p

What is a services in kubernetes ?

 Services:-           

A Kubernetes service can easily expose an application deployed on a set of pods using a single endpoint.

1.There are many types of Services:

i) ClusterIP (default) :- Exposes a service which is only accessible from within the cluster.

ii) NodePort :- Exposes a service via a static port on each node’s IP.

iii) LoadBalancer :- It uses cloud providers’ load balancer. NodePort and ClusterIP services are created automatically to which the external load balancer will route.

iv) Ingress :- Ingress is actually not a type of service. It sits in front of multiple services and performs smart routing between them, providing access to your cluster. Several types of ingress controllers have different routing capabilities. In GKE, the ingress controller creates an HTTP Load Balancer, which can route traffic to services in the Kubernetes cluster based on path or subdomain.

v) ExternalName :-  Maps a service to a predefined externalName field by returning a value for the CNAME record.

vi) Headless :- Services that do not need load balancing and only expose a single IP can create a ‘headless’ service by specifying “none” as the clusterIP.

vii) External IPs :- If there are external IPs that route to one or more cluster nodes.

viii) Endpoint:-  An endpoint is an resource that gets IP addresses of one or more pods dynamically assigned to it, along with a port. 

ix) KubeDNS or Kubernetes DNS:- is a component within the Kubernetes ecosystem that provides Domain Name System (DNS) resolution services for applications running on Kubernetes clusters. It essentially enables the mapping of service names to their corresponding network endpoints within the Kubernetes environment.

2.Two CIDRs are available on a k8s cluster.

1. Pods CIDR :- This specifies the CIDR range allocated for pod IP addresses in the Kubernetes cluster. Pods in the cluster will be assigned IP addresses from this range.

2. Services CIDR :- This specifies the CIDR range allocated for Kubernetes service IP addresses. Services in the cluster will be assigned virtual IP addresses from this range.

--cluster-cidr=192.169.0.0/16

--service-cluster-ip-range=10.96.0.0/12

# kubectl describe pod kube-controller-manager-master -n kube-system

3.Each node in a Kubernetes cluster typically has its own CIDR block assigned for pod IP addresses.

# kubectl get nodes -o custom-columns=NAME:.metadata.name,CIDR:.spec.podCIDR

NAME     CIDR

master   192.169.0.0/24

node-1   192.169.2.0/24

node-2   192.169.1.0/24

4. How to check container IP.

#  kubectl describe pods   <Pods_name>

5. How to update pods subnet CDIR.

# kubectl get ippool -o wide

# curl -L https://github.com/projectcalico/calico/releases/download/v3.27.3/calicoctl-linux-amd64 -o calicoctl

# mv calicoctl /usr/bin/

# chmod +x /usr/bin/calicoctl

# vim ip-pool_change.yaml

apiVersion: projectcalico.org/v3

kind: IPPool

metadata:

  name: new-pool

spec:

  cidr: 172.17.0.0/20

  ipipMode: Always

  natOutgoing: true

# calicoctl apply -f ip-pool_change.yaml

# calicoctl get ippool -o wide

# calicoctl get ippool -o yaml > ippool_new.yaml

# vim  ippool_new.yaml

   disabled: true

# calicoctl apply -f  ippool_new.yaml

# calicoctl get ippool -o wide

# kubectl -n kube-system edit cm kubeadm-config

# x=$(kubectl get pods -n kube-system | awk -F " " '{print $1}')

# kubectl delete pods $x -n kube-system

Restart all worker nodes

# init 6

# kubectl get pods -A -o wide

What is a DaemonSet in Kubernetes.

 

What is a daemonSet ?

Guaranteed Placement: DaemonSets are used to ensure that some or all nodes run a copy of a pod. This is useful for pods that provide node-level services, like log collectors or monitoring agents.

One Pod Per Node: Typically, a DaemonSet will create exactly one instance of a pod on each node in the cluster. This ensures that each node runs the specified pod.

Auto Scaling: When nodes are added to the cluster, DaemonSets automatically create pods on those nodes. Conversely, when nodes are removed, DaemonSets remove the corresponding pods.

Update Strategy: DaemonSets support various update strategies like rolling updates, allowing for controlled updates of the pods across the cluster.

Node Selector: DaemonSets can be configured to run on specific nodes based on node selectors, ensuring that they run only on nodes with certain labels.

Use Cases: DaemonSets are commonly used for cluster-wide services such as logging, monitoring, or networking components that must run on each node.

An example of daemonset is : kube-proxy

Anti-virus pods run each node.

2. What is the difference between Daemonset and Multi Container (sidecar, Adapter, Ambassador) and Static pods?

 DaemonSets ensures that a specific pod runs on each node in the cluster.

Multi Container (sidecar, Adapter, Ambassador) enhances the functionality of the main application container within the same pod. Application container and multi-container will be in the same pods.

Static POD: Created by the kubelet and Deploy control plane components as static  pods,  Ignored by the kube-Scheduler.

apiVersion: apps/v1

kind: DaemonSet

metadata:

  name: my-daemonset

spec:

  selector:

    matchLabels:

      app: my-app

  template:

    metadata:

      labels:

        app: my-app

    spec:

      containers:

      - name: my-container

        image: nginx:latest

 

# kubectl apply -f first.yaml

Get DaemonSets: To view all DaemonSets in the cluster:

# kubectl get ds -o wide

# kubectl get pods -o wide --show-labels

Describe a DaemonSet: To get detailed information about a specific DaemonSet:

# kubectl describe daemonset my-daemonset

Delete a DaemonSet: To delete a DaemonSet:

# kubectl delete -f first.yaml

# kubectl delete ds my-daemonset

What is Deployment and Rollingback in kubernetes.

 What is Deployment ?

Deployment provides replication functionality with the help of ReplicaSets, along with various additional capability like rolling out of changes, rollback changes if required.

Deployment flow :-

 

 

3.1 Benefits of Deployment - Rollout Changes

We can easily roll out new updates to our application using deployments.

Deployments will perform an update in a rollout manner to ensure that your app is not down.

 

1. Rollout nginx to nginx:1.17.3

1. Create a first deployment.

# cat deployment/first.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

  name: test-deployment

spec:

  replicas: 3

  selector:

    matchLabels:

      tier: frontend

  template:

    metadata:

      labels:

        tier: frontend

    spec:

      containers:

      - name: nginx-container

        image: nginx:1.17.3

# kubectl apply -f first.yaml

# kubectl describe deployments test-deployment

# kubectl  get deploy

# kubectl get  rs

# kubectl rollout status deploy test-deployment

# kubectl rollout history deploy test-deployment

# kubectl rollout history deploy test-deployment --revision 2

2.Deployment Strategies types :-

1.Recreate :- 

In this type of very simple deployment, all of the old pods are killed all at once and get replaced all at once with the new ones.

2.RollingUpdate ( Ramped or Incremental ) :-

The rolling deployment is the standard default deployment to Kubernetes. It works by slowly, one by one, replacing pods of the previous version of your application with pods of the new version without any cluster downtime.

3.Canary :-

10 instances, first 2 instance deployed new version & test is done then new version deployed on 8 instances. Full deployment has been done, after that old version instance will be deleted.

4.blue / Green :-

In a blue/green deployment strategy (sometimes referred to as red/black) the old version of the application (green) and the new version (blue) get deployed at the same time. When both of these are deployed, users only have access to the green; whereas, the blue is available to your QA team for test automation on a separate service or via direct port-forwarding.

 3 Benefits of Deployment - Rollback Changes

Sometimes, you may want to rollback a Deployment; for example, when the Deployment is not stable, such as crash looping

 

Deployment ensures that only a certain number of Pods are down while they are being updated.

By default, it ensures that at least 25% of the desired number of Pods are up (25% max unavailable)

Deployments keep the history of revisions that had been made.

 

Rolling back to revision=1

# kubectl rollout undo deploy test-deployment --to-revision=1

# kubectl describe deployments test-deployment

Revision=1 will be removed from the rollout history deployment.

# kubectl rollout history deploy test-deployment

Create an object via CLI :-

1. Create a Deployment:

# kubectl create deployment <deployment-name> --image=<image-name>:<tag>

Generating deployment Manifest via CLI Dry run :-

# kubectl create deployment my-deployment --image=nginx  --replicas 3  --dry-run=client -o yaml

 

# kubectl create deployment --help

2.Get Deployments:

# kubectl get deployments

3.Describe a Deployment:

# kubectl describe deployment <deployment-name>

4.Update a Deployment's Image:

# kubectl set image deployment/<deployment-name> <container-name>=<new-image-name>:<tag>

5.Scale a Deployment:

# kubectl scale deployment <deployment-name> --replicas=<number-of-replicas>

6.Rollout Status of a Deployment:

# kubectl rollout status deployment/<deployment-name>

7.Rolling Back a Deployment:

# kubectl rollout undo deployment/<deployment-name>

8.Pause and Resume a Deployment:

# kubectl rollout pause deployment/<deployment-name>

# kubectl rollout resume deployment/<deployment-name>

9.Edit a Deployment:

# kubectl edit deployment <deployment-name>

10.Delete a Deployment:

# kubectl delete deployment <deployment-name>