Kubernetes

Intro
- Kubernetes or K8S(eight characters between k to s)
- It is a container orchestration/managment tool like docker swarm in docker, it was initially created by google but later it was made open source.
- Docker swarm is docker container orchestration tool with docker only while kubernetes is container orchestration tool that is compatible with any container tools.
- Using kubernetes we can handle all the production related challenges like load balancing, scaling, rolling updates, failover scenarios etc.
- When you install an application on a docker container, it will difficult to monitor and check its status, if there is an issue either restart, or recreate or redeploy on container.
- Kubernetes will monitor all the containers 24 hours. if there is an issue kubernetes can redeploy or restart containers.
- Liveness probe: define time period on which kubernetes will check the containers are running or not in the specified interval.
- Rediness Probe: Define time period on which kubernetes will check the application are running or not and accessible or not in the specified interval.
- It will manage containers. Manage loads. Automate deployments.
- It is cluster platform where you will have multiple master/control plane and worker nodes/data plane.
- It gives Autohealing feature where any pod/container get deleted or corrupted than automatically it creates a new one.
- It provies autoscaling feature.
- It provides enterprise level support.
- It provides network/firewall security.
- These above features are not available in Docker container, but few covers in docker swarm.
- code
  - code
  - code
  - code

Kubernetes Cluster Architecture & Components / Addons / Plugins / Extensions / Objects:

Cluster: Consist of Control Plane & Master Nodes.
- Cluster Configuration:
  - Cluster can be confugured on prem or on cloud using various tools such as kubeadm, KOPS, file method etc.
  - Single node or multi node cluster can be configured for various usage like testing, development, production.
  - If cluster is configured with kubeadm than system will create all components and its relevant pods, while if you choose to configured with file system than we have to create each component manually.
  - First master node/control plane is configured and then all Data plane/worker nodes join to master node.
  - kubeadm tool configuration:
    
    Kubeadm tool can be used to perform cluster configuration, it will configure all components and integrate with worker nodes.
    
    worker nodes can join with master node using kubeadm join followed by key.
  - File method configuration:
    
    In this method all components will be configured manually. It will be done using yaml file. Use this method to separate components in different pods.
  - Kops (AWS) can be used to configure cluster instead of tedeous process with kubeadm or file method.
  - Free Access to cluster: killercoda
  - Kubernetes service providers:
    
    EKS - AWS
    
    AKS - Azure
    
    GKE - Google
  - Controlling Cluster: Administration of cluster can be performed remotely.
    
    Windows:
    
    Linux:
- Upgrade:
  - Before performing upgrade take backup.Take backup of configuration (/etc/kubernetes/manifest) and kubernetes database ETCD (/var/lib/etcd )
  - Should upgrade master node first and should not upgrade all at a time.
  - during upgrade kubernetes keep backup as well at /tmp (it keeps in the same node, if node get crashed then backup will not be available)
  - During upgrade master node services like api-server, etcd, scheduler etc which are running on pods will get restarted and it will give downtime. To avoid must have High Availability.
  - Keep node in draining mode so that new pods will not be created on node during upgrade.
  - If cluster consist of hundreds of nodes then upgrade will be performed using automation tool using Ansible, Terraform, shell script, python script etc..
  - Cannot roll back if upgrade get failed.
  - certificate also get upgraded. worker nodes communicate with master nodes using certificate. (certificate error then run rm -rf $HOME/.kube || true )
  - visit https://v1-29.docs.kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
  - To check the version run
    
    $kubeadm version
    
    $kubectl version
    
    $kubelet --version
  - Determine which version to upgrade to:
    
    $apt update,
    
    $apt-cache madison kubeadm
    
    image
  - Upgrade the first control plane/master node:
    
    Step 1: run the following command, change x with the latest patch version
    
    sudo apt-mark unhold kubeadm && \ sudo apt-get update && sudo apt-get install -y kubeadm='1.29.4-2.1' && \ sudo apt-mark hold kubeadm
    
    step2: Verify that the download works and has the expected version:
    
    $kubeadm version (v1.29.4)
    
    Step 3: Verify the upgrade plan (This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. It also shows a table with the component config version states.)
    
    $kubeadm upgrade plan
    
    image kubeadm_plan
    
    Step 4: Choose a version to upgrade to, and run the appropriate command.
    
    $kubeadm upgrade apply v1.29.4 (can upgrade to kubeadm version)
    
    image
    
    Step 5: Manually upgrade your CNI provider plugin
    
    Step 6: upgrade the other master nodes of cluster: $sudo kubeadm upgrade node
    
    Step 7: Drain the node:
    
    $kubectl drain master --ignore-daemonsets
    
    Upgrade the kubelet and kubectl:
    
    Step 1: upgrade both kubelet and kubectl by running
    
    sudo apt-mark unhold kubelet kubectl && \
    sudo apt-get update && sudo apt-get install -y kubelet='1.29.4-2.1' kubectl='1.29.4-2.1' && \
    sudo apt-mark hold kubelet kubectl
    
    Step 2: Restart the kubelet
    
    $sudo systemctl daemon-reload
    
    $sudo systemctl restart kubelet
    
    Step 3: uncordoned the node (Bring the node backonline)
    
    $kubectl uncordon master
    
    $kubectl get nodes (master node is upgraded to v1.29.4)
    
    certificate error: after resetting cluster master node, got an error
    
    rm -rf $HOME/.kube || true
    mkdir -p $HOME/.kube
    sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    sudo chown $(id -u):$(id -g) $HOME/.kube/config
    
    Run the above commands after running kubeadm init
  - Worker Node Upgrade:
- Cluster Reset & Node Delete:
  - Image
  - Master Cluster node reset.
    
    $kubeadm reset
    
    After reset the services will be deleted like, API-Server connection lost, kubelet closed, configuration file deleted, certification file deleted, etcd will be deleted.
    
    if etcd database exist in another node then it will not be deleted and to reset database run run $kubeadm reset etcdctl del
    
    After reset perform the following
    
    $kubeadm init
  - Worker cluster node reset
    
    $kubeadm reset (it will reset the entire cluster node, if need to reset on different stages of cluster follow below)
    
    It will be part of cluster but will come out of working stage.
    
    $kubeadm join
  - Reset can also be done on different stages as well, .
    
    Preflight: $kubeadm reset preflight
    
    update-cluster-status: $kubeadm reset update-cluster-status
    
    remove-etcd-member: $kubeadm reset-etcd-member
    
    cleanup-node: $kubeadm reset cleanup-node
    
    if you use the above commands only then it will reset the entire cluster node, reset stages are use to skip any stage like
    
    $kubeadm reset --skip-phases preflight
    
    $kubeadm reset --skip-phases update-cluster-status
    
    $kubeadm reset --skip-phases remove-etcd-member
    
    $kubeadm reset --skip-phases cleanup-node
- Cluster Token & CA Public Key:
  - CA & public key combination is used to join worker nodes to master nodes. After master node configurtion bootstrap generates the token and ca public key.
  - When you configure master node using kubeadm init, it generates kubeadm join token+CA key, which will be use on worker nodes to join master node.
  - kubeadm join 192.168.171.50:6443 --token yclr1v.52d0nqes4gau7qpk \
    --discovery-token-ca-cert-hash sha256:2e6b96b1299559c84dbe79d896d02be59c50c57048a821c69c82b05894ab767e
  - create kubeadm join command if lost:
    
    $kubeadm token create --print-join-command
  - 192.168.171.50:6443: This is API-Server ip and port number:
    
    When a worker node joins with the above command, it first contact with API server and then it varifies token & CA
  - --token xxxxx: default token
    
    This token is valid for 5 hours
    
    $kubeadm token list
    
    Generate custom token: Custom tokens are generated to keep separate woker nodes for different projects.
    
    $kubeadm token create
    
    $kubeadm token create --ttl 30m (token will expire after 30 minutes)
    
    $kubeadm token create --ttl 0 (token will never expire)
  - discovery-token-ca-cert-hash sha256:xxxxxx: default CA public key
    
    on google search: kubernetes token > in the bottom click kubeadm join and select token based discovery with CA pinning, copy command and run on master node.
    
    $openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'
  - skip CA cert public key to join master node:
    
    jldf
  - Disable Auto approval: When worker node join to master node, API-Server checks token and CA public key and auto approved when it matches. it is use if kubeadm join key is compromised.
    
    Required approval to join master node:
  - Check all nodes are working on master node:
    
    $kubectl -n kube-system get pods
- Delete Worker Node
  - Delete with kubeadm:
  - Go to worker node and run $kubeadm reset
  - Go to master node and run $kubeadm delete node node-name
  - To rejoin user $kubeadm join xxxxx xxxx command.
- Error on Worker Node
  - If the --kubeconfig flag is set, then only that file is loaded. The flag may only be set once and no merging takes place.
  - If $KUBECONFIG environment variable is set, then it is used as a list of paths (normal path delimiting rules for your system). These paths are merged. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list.
  - Otherwise, ${HOME}/.kube/config is used and no merging takes place (/root/.kube/config if using sudo).
  - $sudo cp /etc/kubernetes/kubelet.conf /root/.kube/config & $sudo kubectl get nodes
Components of Control Plane/Worker Nodes:
- Control Plane /master node:
  - API Server:
    
    It is the front end of the kubernetes cluster, any user or tools must come first to api server.
    
    communication between worker node to master node where request first comes to API server in the master node.
    
    You can keep API server/etcd/scheduler/controller on one or multiple master nodes. In Docker Swarm it is not possible to keep in different nodes.
    
    API server perform the following tasks
    
    Authentication:
    
    Authorization:
    
    Admission Control:
    
    Watch for Updates:
    
    To view the API-server pod in a KinD-cluster.
    
    $kubectl get pods -o wide -n kube-system
  - ETCD Database:
    
    location of etcd database /var/lib/etcd in which snap & wal folders
    
    It stores all the information in key value form.
    
    ETCD perform the following tasks:
    
    WAL
    
    Protobuf
    
    Raft Consensus
    
    Data Not Encrypted
  - Kube Scheduler:
    
    It schedule the pods creation and decide which node to be allocate.
    
    it perform the following tasks
  - Controller Manager & Cloud Controller Manager:
    
    It checks and make sure the desired state of pods is maintained. If we have defined desired state of pods =5, than it make sure the cluster maintain 5 pods at any time.
    
    It perform the following tasks:
    
    Node Controller:
    
    Service Controller:
    
    Namespace Controller:
    
    Daemon set Controller:
    
    Cronjob Controller:
    
    Custom Controllers:
    
    Cloud Controller Manager:
    
    This is not required in order to run the cluster.
    
    If cluster is configured on cloud and it make sure it talk to public cloud using API.
  - Configuration File:
    
    Location : /etc/kubernetes
    
    admin.conf
    
    controller-manager.conf
    
    kubelet.conf
    
    manifests
    
    etcd.yaml
    
    kube-apiserver.yaml
    
    kube-controller-manager.yaml
    
    kube-scheduler.yaml
    
    pki (it contains all keys)
    
    apiserver.crt
    apiserver-kubelet-client.key
    front-proxy-ca.key
    apiserver-etcd-client.crt
    ca.crt
    front-proxy-client.crt
    apiserver-etcd-client.key
    ca.key
    front-proxy-client.key
    apiserver.key
    etcd (ca.crt healthcheck-client.crt peer.crt server.crt ca.key healthcheck-client.key peer.key server.key)
    sa.key
    apiserver-kubelet-client.crt
    front-proxy-ca.crt
    sa.pub
    
    scheduler.conf
- Data Plane / worker nodes:
  - Kubelet:
    
    is a program which is responsible for executing kubernetes commands. The kubelet is an agent that runs on each worker node and is responsible for managing the node's containers, ensuring they run in the desired state. It communicates with the master node's API server to receive instructions about pod deployment and health checks.
    
    It monitors the health of node and pods.
    
    Kubelet instructs the runtime to pull the image from the repository and run the pod.
  - Container Runtime:
    
    Kubernetes supports various container runtimes like Docker, containerd, CRI-O, POD man, rocket etc. The container runtime (e.g., Docker) is responsible for pulling container images, creating and managing containers based on the specifications provided by the kubelet.
    
    find out the container runtime used on a node
    
    $kubectl get nodes -o wide (check under container)
    
    Migrate Docker Engine nodes from dockership to cri-dockered:
    
    What is cri-dockerd?
    In Kubernetes 1.23 and earlier, you could use Docker Engine with Kubernetes, relying on a built-in component of Kubernetes named dockershim. The dockershim component was removed in the Kubernetes 1.24 release; however, a third-party replacement, cri-dockerd, is available. The cri-dockerd adapter lets you use Docker Engine through the Container Runtime Interface.
    
    Find out which container service is used in cluster:
    
    Logon to node.
    
    $ctr -n k8s.io containers list (kubernetes cluster installed containerd not docker)
    
    which_container1.jpg
  - Kube-Proxy & CNI:
    
    It is traffic director in kubernetes cluster, it take care of traffic from service to pod routing.
    
    Routing table is maintained by kube proxy.
    
    User request to access applicaiton running on a pod than request reach to pod via service.
    
    It provides IP addresses to Pods. This component maintains network rules (iptables or other mechanisms) on each worker node. It performs network routing and load balancing, enabling communication between different pods and services across the cluster.
    
    Kube-proxy main funcitons:
    
    Service to pod routing rules.
    
    Load Balancing
    
    Health Checks
    
    CNI: Container Network Interface: main functions are
    
    Assigning IP Address to PODS
    
    Assigning Network Interfaces to PODS
    
    IPAM (IP Address Management): assign ip, check deleted pods and re assign IP etc..
    
    Network Policy Enforcement: Restrict communication between pods
    
    POD to POD networking
    
    CNI make sure all pods can communicate with each other while Kube-proxy define routing routes.
    
    There are some CNI Plugins can perform the functions of kube-proxy, ex., calico and CEM
    
    kube-proxy & CNI Integration:
    
    kube-proxy_CNI_Intigration
    
    Python Frontend to Redis Service:
    
    The Python frontend attempts to connect to the Redis Service using the Service’s DNS name. DNS name to IP translation is primarily performed by CoreDNS, which replaced kube-DNS as the default DNS server within Kubernetes.
    
    kube-proxy’s Role:
    
    Interception: kube-proxy on the node where the Python frontend Pod is running intercepts the outgoing network traffic destined for the Redis Service’s ClusterIP.
    
    Service-to-Pod Mapping: kube-proxy determines which specific Redis Pod should handle the request by referring to the Service’s Endpoint object, which contains the IP addresses of all healthy backend Pods. kube-proxy performs:
    
    Load Balancing: It selects a Redis Pod based on the load balancing strategy defined for the Service (e.g., round-robin or IPVS-based algorithms).
    
    Health Checks: Ensures that the Redis Pod selected for routing is healthy and available to handle requests.
    
    Traffic Redirection: kube-proxy redirects the traffic from the Python frontend Pod to the chosen Redis Pod by modifying the packet’s destination IP and port.
    
    CNI’s Role:
    
    Network Setup: CNI ensures that all Pods, including the Python frontend and Redis Pods, are assigned unique IP addresses within the cluster and can communicate seamlessly.
    
    Traffic Routing:
    
    From Python Frontend to Redis Pod: CNI ensures that the traffic routed by kube-proxy can traverse the cluster’s network infrastructure correctly to reach the selected Redis Pod.
    
    Pod-to-Pod Communication: The CNI plugin implements the network routes and rules that enable communication between Pods across different nodes.
    
    Redis Pod Response:
    
    The selected Redis Pod processes the request and sends the response directly back to the originating Python frontend Pod.
    
    Direct Return: Kubernetes networking ensures the return traffic takes the reverse path directly, avoiding kube-proxy, because the connection has already been established.
    
    Return Path:
    
    The response traffic from the Redis Pod is sent directly to the Python frontend Pod, using the same network setup provided by CNI.
    
    Direct Communication: Since the communication is already established, kube-proxy is not involved in the return path.
    
    Key Roles in This Interaction:
    
    CNI (Container Network Interface):
    
    Provides the fundamental networking infrastructure, including IP address assignment, routing, and connectivity for all Pods in the cluster.
    
    Ensures traffic between Pods on the same or different nodes is routed correctly through the cluster network.
    
    kube-proxy:
    
    Acts as a traffic director for requests made to Services.
    
    Implements the routing and load-balancing logic for traffic sent to the Redis Service, ensuring requests are forwarded to a healthy Redis Pod.
    
    Redis Service:
    
    Serves as a stable abstraction layer, hiding the dynamic nature of Pod IP addresses from the Python frontend.
    
    Provides a consistent entry point (ClusterIP or DNS) for communication with the Redis deployment and handles load balancing via kube-proxy.
  - PODS/Containers
    
    PODS:
    
    A POD is the smallest and most basic deployable unit in the kubernetes. It is a logical boundary in which containers are created.  POD can have muliple containers.  Pod is a wrapper of container.
    
    Containers:
    
    containers are created within a pod, in kubernetes you cannot deploy app directly in the containers, first it create a pod and within a pod it creates a cotainer. Application runs on containers.
    
    If there are multiple containers running on a pod it shares Networking (Namespace) and storage.
    
    Share networking means if you have two containers in a pod, when you login on one container, you can access the other container by using localhost.
    
    If you assing a storage and map it to pods than contents of shared folder can be accessible from both containers.
    
    Pause Container:
    
    When a request is generated to deploy an application using image, a pod is created. when pod is created a pause container along with application container is also created.
    
    Pause container maintian namespace in which all containers information stored. Namesspace are
    
    IP Assign to POD:
    
    IP will be assign to POD from clusterIP, it can be access within a cluster.
    
    Deployment:
    
    You can have multiple pods to maintain HA (High Availability) and load balancing, if any pod gets deleted than application can be accessible running on other pods.
    
    Docker does not have applican running on mulitple containers as one containers gets failed than application still accessible with other containers.
    
    It offers:
    
    Replica management:
    
    Rolling updates and Rollbacks: updating the version of image without downtime.
    
    Declarative configuration:
    
    To access an application stored in container, request comes to pod which has an IP address and information of other containers in namespace which will be forwarded accordingly.
    
    For any reason any container is deleted/corrupt, a new container will be created.
    
    For redundancy multiple containers of an application can be created within a pod.
    
    In docker we defind all argument in command line while creating like: docker run -d or -t or -it container name -d image name -p port number -v volume mount -network xyx
    
    in kubernetes we can define all arguments in pod.yaml
    
    kubectl is the command line tool for kubernetes.
    
    communication between pods:
    
    kube-proxy_CNI_Intigration
    
    Python Frontend Pod Sends Request:
    
    The Python frontend Pod sends a request to the Redis service (e.g., redis-service:6379).
    
    kube-proxy Intercepts Traffic:
    
    kube-proxy intercepts the traffic and looks up the Redis Service’s endpoints to find a healthy Redis Pod.
    
    Traffic Forwarded to Redis Pod:
    
    After finding a healthy Redis Pod, kube-proxy forwards the request to that Redis Pod.
    
    Redis Pod Processes the Request:
    
    The Redis Pod processes the request and sends the response directly back to the Python frontend Pod.
    
    This process ensures seamless communication between services in the Kubernetes cluster, with kube-proxy handling the routing of traffic to the appropriate Pods.
    
    Additional Considerations:
    
    CNI Plugins: Some advanced CNI plugins (e.g., Calico, Cilium) can offload service-to-pod routing directly, potentially reducing kube-proxy’s role.
    
    Service Type Impact: Depending on the Service type (e.g., ClusterIP, NodePort, or LoadBalancer), the traffic path and kube-proxy’s role might differ slightly. We will discuss Service Types in detail in future lessons.

Add-Ons, Extensions, Plugins, Objects: CNI, CRI, CSI, Ingress controller,

Kubernetes Core components
- plugins_addons1.jpg
- Control Plane components:
  - API Server: The central control plane component that validates and processes REST API requests, enforcing security policies and forwarding requests to relevant components.
  - Scheduler: Assigns Pods to nodes based on resource availability and scheduling policies.
  - Controller Manager: Runs control loops to maintain the desired state (e.g., replication, endpoint management).
  - etcd: A distributed, consistent key-value store that persistently stores all cluster state and configuration data.
  - Cloud Controller Manager: Manages cloud-provider-specific integrations such as external load balancers, persistent storage provisioning, and node lifecycle management.
- Node Components:
  - kubelet: The primary node agent that ensures containers are running as expected.
  - kube-proxy: Maintains network rules on each node, enabling seamless service discovery and communication between Pods.
- While the Kubernetes Core provides essential orchestration functionalities, additional features like networking, storage, monitoring, and security are implemented via external components.

Plugins: CNI, CRI, CSI

CNI (Container Network Interface), CRI (Container Runtime Interface), and CSI (Container Storage Interface) are standardized interfaces that define how networking, runtime, and storage components interoperate with Kubernetes. These interfaces adhere to specifications that are developed and maintained by the Kubernetes community under the governance of the CNCF. Although the CNCF endorses these standards, it is the community that actively defines and updates the specifications.
plugins_addons2.jpg
Container Network Interface (CNI): Configures Pod networking and IP allocation.
Container Storage Interface (CSI): Manages external storage solutions.
Container Runtime Interface (CRI): Allows Kubernetes to interact with various container runtimes (e.g., containerd, CRI-O).

CNI Plugins (Networking):

Plugin	Description
Calico	Supports network policies and BGP routing; ideal for security-focused environments.
Cilium	High-performance with eBPF-based networking; excels in observability and security.
Flannel	Lightweight and simple; lacks network policy support.
Weave Net	Provides encrypted pod-to-pod communication; supports multi-cluster setups.

Responsibilities:
- Assigns IP addresses to pods.
- Enables communication between pods across nodes.
- Manages network policies for security and isolation.
- Supports service discovery and DNS resolution.
- Integrates with cloud and on-prem networking solutions.
- Provides network metrics and observability features.

CRI Plugins (Container Runtimes):

Plugin	Description
containerd	Default for most Kubernetes setups; lightweight, optimized, and follows OCI standards.
CRI-O	Minimal runtime designed for Kubernetes; integrates tightly with OpenShift.
Kata Containers	Uses lightweight VMs for security; ideal for isolating untrusted workloads.
gVisor (by Google)	User-space sandboxing for enhanced security; limits direct host access.

Reponsibilities:
- Pulls container images from registries.
- Starts, stops, and deletes containers.
- Manages container networking via CNI integration.
- Handles logging and monitoring of containers.
- Allocates resources like CPU and memory to containers.
- Ensures compatibility with Kubernetes via standardized gRPC APIs.

CSI Plugins (Storage):

Plugin	Description
Amazon EBS CSI	Provides block storage for Kubernetes workloads on AWS; supports dynamic provisioning.
Azure Disk CSI	Offers high-performance, persistent storage for Kubernetes on Azure.
Google PD CSI	Integrates with Google Cloud Persistent Disks; supports snapshots and resizing.
Ceph RBD CSI	Ideal for scalable, distributed storage; supports snapshots and cloning.
Portworx CSI	Enterprise-grade storage with high availability, backups, and replication.
OpenEBS CSI	Lightweight and cloud-native storage for Kubernetes; optimized for local PVs.
Longhorn CSI	Rancher’s distributed block storage for Kubernetes; supports snapshots and disaster recovery.

Reponsibilities:
- Dynamically provisions persistent storage for workloads.
- Supports mounting and unmounting of storage volumes.
- Handles volume resizing, snapshots, and backups.
- Ensures data persistence across pod restarts.
- Integrates with various cloud and on-prem storage providers.
- Manages access controls and multi-node storage sharing.

Add-Ons: Ingress Controller
- Add-ons enhance Kubernetes with additional functionalities:
- Ingress Controllers: Handle external access, load balancing, and routing.
- Monitoring Tools: Observability tools like Prometheus and Grafana.
- Service Meshes: Solutions like Istio and Linkerd enhance inter-service communication.
- Code
- Code
Third-Party Extensions
- Third-party tools and solutions integrate seamlessly into Kubernetes:
- Helm: Kubernetes package manager for simplified deployment.
- Prometheus: Monitoring and alerting system for cloud-native applications.
- Istio: Service mesh for security, traffic management, and observability.
- Code
- Code
Refrences:
Container Network Interface (CNI) Specification
Container Storage Interface (CSI) Specification
Container Runtime Interface (CRI) Specification
Kubernetes Add-Ons and Extensions

How Kubernetes components communicate:
- Deployment workflow of an application:
  - deployment_workflow.jpg
  - Kubectl/CICD tool:
    
    By using the above method you deploy the application on kubernetes cluster, the request goes to API server.
    
    Kubectl will check the syntax of yaml file like indentation errors, check basic kubernetes schema.
    
    Forward the request to api server.
  - api-server:
    
    When a request is generated to deploy an applicaiton, request first comes to api-server.
    
    It authenticate and authorize the user request.
    
    It check the full schema refers to the set of rules and structure that define how objects (pods, deployment, services etc) should be formatted and configured in their yaml/json file.
    
    It validates the permission and store the information what kind of pod need to be created.
  - ETCD:
    
    Api server will store the deployment Information inside ETCD.
  - Controller Manager:
    
    Deployment controller: It will check the number of desired pods/containers and will inform to api server for any discrepencies. In the above example replica set =5, api server will create replica set object and inform to ETCD to update the records.
    
    Replica set controller gets active once replica set object is created.
    
    Deployment Controller / replica set controllers are part of controller manager.
    
    The information of deployment with replica set object is stored in ETCD.
    
    No POD has been created until now.
  - Scheduler:
    
    API server send request to scheduler to find the pod on which deployment can be done. It will check/analyse the suitable worker nodes to create pod. It could be on number of pods.
    
    It will update information in ETCD.
  - Kubelet:
    
    The request of pods object will be sent to kubelet of selected pod to create pod.
  - Container Runtime:
    
    Kubelet instruct container runtime to perform the requirement.
    
    It will first pull the image from repository.
    
    Secondly it will create network with the help of CNI plugin.
    
    Third it will mount the required volume.
    
    It will create and start the containers.
  - Kube-Poxy:
    
    once the pod is created then kube proxy will enable network rules.
    
    Once the pods are created than it send information to api-server.
    
    API-Server will send information to ETCD database to update.
    
    API-server will send information of pods creation to user.
  - 1. User Initiates Deployment Creation
    
    Command:
    The user runs kubectl apply -f python-frontend-deployment.yaml to create a new Deployment.
    
    kubectl Action:
    
    Validates the YAML file for:
    
    Syntax (e.g., proper formatting, indentation).
    
    Basic Kubernetes schema correctness (e.g., valid API versions, resource definitions).
    
    Sends the validated Deployment object to the API Server.
    
    2. API Server Actions
    
    The API Server receives the validated Deployment object and performs the following tasks:
    
    Authentication and Authorization:
    Verifies that the user has the correct permissions to create the Deployment.
    
    Validation:
    Ensures the Deployment object conforms to the complete Kubernetes schema.
    
    Storage:
    
    Stores the desired state of the Deployment in etcd (the cluster’s database).
    This includes details such as the Deployment's metadata, desired number of Pods, and Pod template.
    
    Response:
    
    Returns a success message (e.g., "deployment created") to the user.
    
    3. Deployment Controller Workflow
    
    The Deployment Controller is part of the Controller Manager and ensures that the desired number of Pods are running in your cluster.
    
    How It Works
    
    The Deployment Controller continuously watches the API Server for any changes to Deployment objects.
    
    It compares the desired state (e.g., number of Pods defined in the Deployment) with the actual state (number of Pods currently running in the cluster).
    
    What Happens When Desired State Differs?
    
    If the actual number of Pods doesn’t match the desired state:
    
    ReplicaSet Creation:
    
    The Deployment Controller instructs the API Server to create a ReplicaSet object.
    
    The API Server stores the ReplicaSet object in etcd.
    
    Pod Creation:
    
    The ReplicaSet Controller monitors the ReplicaSet object via the API Server (not directly in etcd).
    
    If Pods are needed (e.g., scaling or Pod failure):
    
    The ReplicaSet Controller instructs the API Server to create the required Pod objects.
    
    The API Server stores the new Pod objects in etcd (the cluster’s database).
    
    Note:
    
    At this stage, only the Pod objects are created and stored in etcd.
    
    The actual containers inside these Pods will be created later when the Kubelet starts managing the Pods on the assigned nodes.
    
    Status Update:
    
    The Deployment Controller updates the Deployment object in the API Server to reflect the current state, including:
    
    The number of available Pods: These are Pods that have been created but might not be running yet.
    
    The number of ready Pods: These are Pods that are up and running, and their containers have passed health checks. A Pod is considered "ready" only when all of its containers are running and healthy.
    
    4. Scheduler's Role
    
    The Scheduler is responsible for assigning unscheduled Pods (Pods without a nodeName) to appropriate nodes.
    
    How It Works
    
    The Scheduler watches the API Server for Pod objects with no nodeName.
    
    For each unscheduled Pod:
    
    The Scheduler selects a suitable node based on:
    
    Resource availability (e.g., CPU, memory).
    
    Node affinities (to be discussed later).
    
    Taints and tolerations (to be discussed later).
    
    The Scheduler updates the Pod object in the API Server, adding the nodeName to indicate where the Pod will run.
    
    The updated Pod object is stored in etcd via the API Server.
    
    5. API Server Updates the Pod Status
    
    The API Server receives the node selection from the Scheduler.
    
    It updates the Pod object in etcd with the nodeName to indicate the assigned node.
    
    6. Kubelet's Role
    
    The Kubelet on the assigned node monitors the API Server for changes to Pod objects.
    
    How It Works
    
    The Kubelet detects the new Pod scheduled to its node by watching the API Server.
    
    The Kubelet retrieves the Pod object from the API Server, which includes details about:
    
    Container specifications.
    
    Network and volume configurations.
    
    Kubelet Actions
    
    Container Runtime Interface (CRI):
    The Kubelet interacts with the container runtime (e.g., containerd, CRI-O) to:
    
    Pull container images from the registry.
    
    Configure networking using the CNI plugin.
    
    Mount volumes specified in the Pod definition.
    
    Create and start containers inside the Pod.
    
    Health Monitoring:
    
    The Kubelet continuously monitors the health of the containers and updates their status in the API Server.
    
    These updates are stored in etcd.
    
    7. Pod Running
    
    Once the containers are running, the Pod is live on the assigned node.
    
    Deployment Controller:
    
    Manages the ReplicaSet, ensuring it is configured to maintain the desired state.
    
    Does not directly monitor or recreate Pods; this is the responsibility of the ReplicaSet Controller.
    
    ReplicaSet Controller:
    
    Monitors the Pods via the API Server.
    
    If a Pod fails or is terminated, the ReplicaSet Controller detects the discrepancy and takes action to recreate the missing Pod to maintain the desired state.
    
    Key Points:
    
    The Kubelet monitors the containers' health and status on the assigned node.
    
    It reports the containers' running status to the API Server.
    
    The API Server updates the Pod's status in etcd to reflect the current state of the containers.
- Find out which container services is used in cluster
  - Login to node and run
    
    $ctr -n k8s.io containers list (kubernetes cluster installed containerd not docker)
    
    which_container1.jpg
  - code
  - code

Installation, configuration, setup of kubernetes cluster

Types of kubernetes installation:
- kubernetes installation can be performed in two ways
  - using kubeadm tool
  - using file method
On-Premises Ubuntu VMs multinode cluster using kubeadm and Cloning VMs. Video.
On-Premises Ubuntu 22.04 LTS VMs multinode cluster using kubeadm tool.
- Create 3 ubuntu VMs (windows not supported) and Perform Step-1 to Step-7 on all VMs.
- Step 1 Prerequisite:
  - Minimal Install Ubuntu 22.04, Create 3 ubuntu VM one master node and 2 worker nodes, Download ubuntu from https://ubuntu.com/download/desktop (20.04 LTS)
  - Minumum 2 GB RAM, 2 CPU, 30 GB Disk.
  - Sudo user with admin rights: $sudo su
  - Internet connectivity
- Step 2: Assing IP and Set Hostname, hosts file
  - Manual IP in Ubuntu 192.168.171.50 (51 & 52), 255.255.255.0, GW:192.168.171.2
  - $sudo hostnamectl set-hostname master, $sudo hostnamectl set-hostname worker1, $sudo hostnamectl set-hostname worker2
  - $exec bash
  - $sudo vi /etc/hosts (add IP & hostname of all nodes, 192.168.171.50 master, 192.168.171.51 worker1, 192.168.171.52 worker2) save and exit.
- Step 3 : Disable Swap and Kernel Parameters
  - Kubernetes does not support swap memory, kubernetes will not store run time data in swap memory, it store in physical memory.
  - $sudo swapoff -a
  - $sudo sed -i '/ swap / s/^$.*$$/#\1/g' /etc/fstab
  - $sudo tee /etc/modules-load.d/containerd.conf <<EOF
    overlay
    br_netfilter
    EOF
  - $sudo modprobe overlay
  - $sudo modprobe br_netfilter
  - run tee command
  - $sudo tee /etc/sysctl.d/kubernetes.conf <<EOT
    net.bridge.bridge-nf-call-ip6tables = 1
    net.bridge.bridge-nf-call-iptables = 1
    net.ipv4.ip_forward = 1
    EOT
  - Reload the above changes
  - $sudo sysctl --system
- Step 4: Install Containerd Runtime (Docker)
  - First install dependencies for containerd runtime:
  - $sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates
  - Enable Docker Repository:
  - $sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg
  - $sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
  - Run the following apt command to install containerd
  - $sudo apt update
  - sudo apt install -y containerd.io
- Step 5: Configure containerd so that it starts using systemd as cgroup
  - $containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
  - $sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml
  - Restart & Enable Containerd
  - $sudo systemctl restart containerd
  - $sudo systemctl enable containerd
- Step 6: Kubernetes package is not available in the default Ubuntu 22.04 package repositories. So we need to add Kubernetes repository. run following command to download public signing key,Step 6: Add APT repository for Kubernetes:
  - $sudo apt-get update
  - $sudo apt-get install -y apt-transport-https ca-certificates curl gpg
  - $curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.31/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
  - Run the following command echo command to add kubernetes apt repository.
  - $echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.31/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
  - Kub0ern0etes v102.0023201 was02 available, replace this version with new higher version if available.
- Step 7: Install Kubectl, Kubeadm, Kubelet
  - $ sudo apt update
  - $ sudo apt install -y kubelet kubeadm kubectl
  - $ sudo apt-mark hold kubelet kubeadm kubectl
- Perform Step 8 on Master Node only:
- Step 8: Install Kubernetes Cluster
  - $sudo kubeadm init --control-plane=master
  - After the initialization is complete, you will see a message with instructions on how to join worker nodes to the cluster. Make a note of the kubeadm join command for future reference.
    - kubeadm join master:6443 --token sprb01.byn0v48rbmwodr8c \
      --discovery-token-ca-cert-hash sha256:46f3a54131c98e4d934e18aa82629395ea800607834e92d97bca607efaa5fec8
  - So, to start interacting with cluster, run following commands on the master node,
  - $ mkdir -p $HOME/.kube
  - $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  - $ sudo chown $(id -u):$(id -g) $HOME/.kube/config
  - run following kubectl commands to view cluster and node status:
  - $ kubectl cluster-info
  - $ kubectl get nodes
- Step 9: Join worker nodes to the Cluster.
  - Run on each worker node the following command to join cluster.
  - kubeadm join master:6443 --token sprb01.byn0v48rbmwodr8c \
    --discovery-token-ca-cert-hash sha256:46f3a54131c98e4d934e18aa82629395ea800607834e92d97bca607efaa5fec8
  - create kubeadm join command if lost:
    - $kubeadm token create --print-join-command
- Step 10: check cluster nodes on master node
  - $kubectl get nodes (it will show all nodes)
  - nodes status is 'Not Ready', so to make it active. must install CNI (Container Network Interface) or network add-on plugs like Calico, Flannel and Wwave-net.
- Step 11: Install CNI (Container Network Interface) or network add-on plugs like Calico, Flannel and Wwave-net.
  - $ kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/manifests/calico.yaml
  - Verify the status of pods in kube-system namespace:
  - $ kubectl get pods -n kube-system
  - $kubectl get nodes
- Step 12: Deploy nginx application and test it.
  - $ kubectl create deployment nginx-app --image=nginx --replicas=2
    - deployment.apps/nginx-app created
  - Check the status of nginx-app deployment
  - $ kubectl get deployment nginx-app
    - NAME READY UP-TO-DATE AVAILABLE AGE
      nginx-app 2/2 2 2 38s
  - Expose the deployment as NodePort,
  - $kubectl expose deployment nginx-app --type=NodePort --port=80
    - service/nginx-app exposed
  - Run following commands to view service status
  - $kubectl get svc nginx-app
  - $kubectl describe svc nginx-app
- Step 13: Access nginx application
  - $ curl http://<woker-node-ip-addres>:31885
  - $ curl http://192.168.171.51:31246:31885
- Lost kubeadm join key: run this to create new token $kubeadm token create --print-join-command
On-Premises Ubuntu multinode cluster using file system.
- code
- code
- code
- code
On Premises Centos multinode cluster using kubeadm
- Step 1: Create 3 VMs of CentOS : windows not supported (one master node, 2 worker nodes with min 2 GB RAM, 2 CPU and 30 GB Disk)
- Step 2: Swap Memory should be off on all nodes: Kubernetes does not support swap memory, process or runtime data should not save in swap memory but should be stored in physical memory.
  - On Ubuntu machine:
  - $swapon -s (Displays the status of swap and location)
  - $swapoff /swapoff (it is temporary)
  - $vi /etc/fstab (remove the line in centos: /dev/mapper/centos-swap). remove the line /swapfile in ubuntu) save it. permanent swapfile off
- Step 3: Ports should be enabled:
  - check firewall status: By default firewall is enabled in centos:
  - On ubuntu:
  - $systemctl status ufw
  - $add the following ports in firwall or disable firewall
  - $systemctl stop ufw
  - Hostname:
  - $hostname (it will display hostname)
  - $hostname set-hostname master(it will set hostname master)
  - $bash
  - Enter DNS address or enter IP adddress in hosts file.
  - $cd /etc/hosts
  - $vi hosts (add ip addresses of all nodes, master & worker nodes)
- Step 4: Install docker on all nodes, start, enable, Kubernetes used docker to create containers. Kubernetes used docker to create containers.
  - on ubuntu: $apt install docker.io
  - On CentOS: sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo and then $sudo yum install docker-ce-docker-ce-cli containerd.io
  - start/enable docker on all nodes: $systemctl enale docker, $systemctl start docker
  - $docker info
- Step 5: On Master node only: Install, start, enable Kubeadm (cluster setup), kubelet (manage cluster components ), kubectl (commands start with kubectl),
  - Go to google and search kubernetes kubeadm install: go to link
  - Step1: Debian based distribution (for ubuntu, debian or hypriotOS),
    - copy and run:
      sudo apt-get update # apt-transport-https may be a dummy package; if so, you can skip that package sudo apt-get install -y apt-transport-https ca-certificates curl gpg
  - Step 2: Download the public signing key:
    - curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
  - Sep 3: Add the appropriate Kubernetes apt repository. Please note that this repository have packages only for Kubernetes 1.28; for other Kubernetes minor versions, you need to change the Kubernetes minor version in the URL to match your desired minor version (you should also check that you are reading the documentation for the version of Kubernetes that you plan to install).
    - echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
  - Step 4: Update the apt package index, install kubelet, kubeadm and kubectl, and pin their version:
    - sudo apt-get update sudo apt-get install -y kubelet kubeadm kubectl sudo apt-mark hold kubelet kubeadm kubectl
- $systemctl enable kubelet
- $systemctl start kubelet
- code

On cloud Ubuntu VMs Cluster Setup with Script (Aditya Jaiswal)

Create 3 ubuntu VM machines on cloud (windows not supported), one as a master node and two as a worker nodes.
Ensure you have root access on both the master and workder nodes.

Step 1: On master and worker nodes, run the script on both master and workder nodes.

#!/bin/bash

# Update package lists
sudo apt-get update

# Install Docker
sudo apt install docker.io -y
sudo chmod 666 /var/run/docker.sock

# Install dependencies for Kubernetes
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
sudo mkdir -p -m 755 /etc/apt/keyrings

# Add Kubernetes apt repository and key
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list

# Update package lists again
sudo apt update

# Install Kubernetes components
sudo apt install -y kubeadm=1.28.1-1.1 kubelet=1.28.1-1.1 kubectl=1.28.1-1.1

$vi 1.sh (paste script)
$sudo chmod +x 1.sh
$./1.sh

Step 2: Setting up Master node:

#!/bin/bash

# Initialize Kubernetes master
sudo kubeadm init --pod-network-cidr=192.168.0.0/16

# Configure kubectl for current user
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# Deploy Calico network plugin
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# Deploy NGINX Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.49.0/deploy/static/provider/baremetal/deploy.yaml

run the script on master node only.
$vi 2.sh (paste script)
$sudo chmod +x 2.sh
$./2.sh

Step 3: Swapoff (error will through that swap file is enabled)
- Temporarily swapoff in ubuntu: $swapon -s (it will show the location of swapfile) $swapoff /swapfile
- Temporarily swapoff in Centos: $swapon -s (/dev/dm-1) $swapoff /dev/dm-1
code
code

On Cloud AWS Ubuntu VMs Cluster Setup with KOPS
- Click for Installation steps from Valaxy Tech:
- Click for Installation Steps from Abhishek.
- Dependencies Required:
  - python 3
  - AWS CLI: it is required python.
  - Kubectl
- Step 1: Create a VM /use laptop:
  - Step 1.1: Using AWS VM, login to AWS console and enter credentials.
  - Click EC2/Instances/Launch Instances/k8s-management\Take Amazon linux (CLI is installed by default). create a VPC/subnet/security group/internet gateway etc.. launch Instance
  - To connect, open ssh tool(mobaXterm), enter Public IP in remote host, specify name = ec2-user, click advanced SSG setting/user private key and define location of keypair and ok.
  - Run aws configure (requested to enter AWS access key and secret key), we will define IAM role and assign to user.
  - Create a IAM role with the following roles.
    - Go to IAM/roles/create role/choose service EC2/ search following roles and assign
    - IAM Full Access
    - S3 Full Access
    - Route 53 Full Access
    - EC2 Full Access
    - Amazon VPC Full Access
    - Enter role name:kops-iam-role and create role.
    - Assign role to user: Go to EC2 Instance/select instance/click actions/security/modify IAM role, select kops-iam-role and update iam role.
  - Run aws configure:
    - access key: just enter
    - secret key: just enter
    - Region = eu-west-2
    - Output format = table
  - Step 1.2 : Using local VM or Laptop:
    - Install AWS CLI on your local computer. This machine should be linux O/S.
  - Step 1.3: DNS Configuration (Private / Public)
    - Go to Route 53/create hosted zones/
    - Enter domain name: stardistributors.co.uk or stardistributors.local
    - if using private hosted zone, select Zone and vpcID to which it will redirect traffic, create
- Step 2: Install AWSCLI
  - AWSCLI is installed by default in Amazon Linux image. for other VMs run the following
  - #curl https://s3.amazonaws.com/aws-cli/awscli-bundle.zip -o awscli-bundle.zip
    apt install unzip python
    unzip awscli-bundle.zip
    #sudo apt-get install unzip - if you dont have unzip in your system
    ./awscli-bundle/install -i /usr/local/aws -b /usr/local/bin/aws
- Step 3: Install kubectl
  - #curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
    #chmod +x ./kubectl
    #sudo mv ./kubectl /usr/local/bin/kubectl
  - #kubectl Error: if you still get command not found then move file to /bin folder sudo mv /usr/local/bin/kubectl /bin/
  - #kubectl version
- Step 4: Create an IAM user/role with Route53, EC2, IAM and S3 full access: done in step 1.1
- Step 5: Attach IAM role to ubuntu server : Done in step 1
- Step 6: Install kops
  - Install kops on ubuntu instance: It will create VMs (one master and 2 worker nodes) and it creates all pods for kubernetes components.
  - #curl -LO https://github.com/kubernetes/kops/releases/download/$(curl -s https://api.github.com/repos/kubernetes/kops/releases/latest | grep tag_name | cut -d '"' -f 4)/kops-linux-amd64
    #chmod +x kops-linux-amd64
    #sudo mv kops-linux-amd64 /usr/local/bin/kops
  - #kops version, Error: if you still get command not found then move file to /bin folder sudo mv /usr/local/bin/kopsl /bin/
  - #kops version
- Step 7: Create a Route53 private hosted zone (you can create Public hosted zone if you have a domain): done in step 1.3
- Step 8: Create S3 bucket
  - #aws s3 mb s3://dev.k8s.stardistributors.local
  - #aws s3 ls
- Step 9: Expose environment variable:
  - #export KOPS_STATE_STORE=s3://dev.k8s.stardistributors.local
- Step 10: Create sshkeys before creating cluster: to ssh master node in the cluster
  - #ssh-keygen
- Step 11: Create kubernetes cluster definitions on S3 bucket: store information in the S3 bucket.
  - #kops create cluster --cloud=aws --zones=eu-west-2a --name=dev.k8s.stardistributors.local --dns-zone=stardistributors.local --dns private
  - or
  - #kops create cluster --name=dev.k8s.stardistributors.local --state=s3://dev.k8s.stardistributors.local --zones=eu-west-2a --node-count=1 --node-size=t2.micro --master-size=t2.micro --master-volume-size=8 --node-volume-size=8
- Step 12: Create kubernetes cluser
  - #kops update cluster dev.k8s.stardtributors.local --yes
- Step 13: Validate your cluster
  - #kops validate cluster
- Step 14: To list nodes
  - #kubectl get nodes
- Step 15: Deploying Nginx Container
  - kubectl run sample-nginx --image=nginx --replicas=2 --port=80
  - kubectl get pods
  - kubectl get deployments
- Step 16: Expose the deployment as service. This will create an ELB in front of those 2 containers and allow us to publicly access them:
  - kubectl expose deployment sample-nginx --port=80 --type=LoadBalancer
  - kubectl get services -o wide
- Step 17: Delete cluster
  - kops delete cluster dev.k8s.valaxy.in --yes
Platform as a Service - GKE, EKS, AKS
- Azure, Google, AWS provides platform as a service where these companiese maitain infrastructure. You will configure kubernetes on their platform.
- Google GKE - Google Kubernetes Engine
  - login to google cloud. Activate it by providing bank card details, activate free trial, https://console.cloud.google.com/
  - open google cloud console paralelly.
  - click navigation menu> kubernetes engine> create cluster > create
  - GKE standard > configure
    
    Cluster name: cluster-1
    
    location type: zonal
    
    control plane version: Released channel
    
    create
    
    observe: Cluster size is 3, one master and 2 nodes. Cluster is created
- AWS EKS - Elastic Kubernetes Service Cluster Setup
  - It is a managed control plane in AWS. AWS provides High Available kubernetes cluster.
  - Step 1: Create a user in AWS IAM, create a custom policy and default policies attach to user.
    
    Create a user:
    
    Log in to the AWS Management Console.
    
    Navigate to the IAM dashboard.
    
    Click on "Users" in the left sidebar.
    
    Click on the "Add user" button. IAM users are created in global Region.
    
    Enter a username of your choice.
    
    Provide user access to the AWS Management Console: select
    
    select iam user, set a password for the user.
    
    select assign polices directly to user:
    
    search the following policies and attach it to user.
    
    Search the default policies
    
    AmazonEC2FullAccess
    
    AmazonEKS_CNI_Policy
    
    AmazonEKSClusterPolicy
    
    AmazonEKSWorkerNodePolicy
    
    AWSCloudFormationFullAccess
    
    IAMFullAccess
    
    star-eks-policy (custom policy to allow visual editor)
    
    Create a custom policy:
    
    click on create policy: select json and enter the following code
    
    {
    "Version": "2012-10-17",
    "Statement": [
    {
    "Sid": "VisualEditor0",
    "Effect": "Allow",
    "Action": "eks:*",
    "Resource": "*"
    }
    ]
    }
    
    save the policy: star-eks-policy (select this policy as well)
    
    next and create user: https://533267324249.signin.aws.amazon.com/console
    
    Create Access keys:
    
    Go to user created (eks-user)/security credentials/ access keys/ create access keys/command line interface and download both the keys .csv file.
  - Step 2: Create a VM and run the script to automate the installation of AWSCLI, kubectl, and eksctl;
    
    create ubuntu, 20.04, t2medium, 20GB disk
    
    access vm through mobaexterm.
    
    $sudo apt update
    
    create a script and paste the commands
    
    $vi install_tools.sh
    
    #!/bin/bash # Install AWSCLI curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" sudo apt install -y unzip unzip awscliv2.zip sudo ./aws/install # Install kubectl curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/amd64/kubectl chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin kubectl version --short --client # Install eksctl curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp sudo mv /tmp/eksctl /usr/local/bin eksctl version
    
    $sudo chmod +x install_tools.sh
    
    $./install_tools.sh
  - Step 3: Connect to AWS using CLI with user eks-user
    
    open mobaexterm and conenct to VM with user ubuntu
    
    $aws configure
    
    AWS access key Id = paste it from downloaded key of user (eks-user)
    
    AWS secret key = paste it
    
    Default region name = eu-west-2 (region where VM is created)
    
    Default output format =
    
    connected to AWS VM
  - Step 4: Create EKS cluster with eksctl : copy and paste the below command , cloudformation will create cluster.
    
    Either you can create with portal by choosing eks cluster or using eksctl command line utility and copy and paste the below command (will take 10 minutes), cloudformation will create cluster.
    
    eksctl create cluster --name=star-eks --region=eu-west-2 --zones=eu-west-2b,eu-west-2c --without-nodegroupEKS (cluster "star-eks" in "eu-west-2" region is created without nodegroup/worker node. it will be created separately, see below).(will take 5 to 10 minutes)
    
    eksctl create cluster --name=star-eks --region=eu-west-2 --zones=eu-west-2b,eu-west-2c --fargate (cluster "star-eks" in "eu-west-2" region is created with nodegroup/worker node)
    
    eksctl utils associate-iam-oidc-provider (open Id connect provider) paste the following
    
    eksctl utils associate-iam-oidc-provider \
    --region eu-west-2 \
    --cluster star-eks \
    --approve
    
    Create nodegroup (workdernodes)
    
    eksctl create nodegroup --cluster=star-eks \
    --region=eu-west-2 \
    --name=node2 \
    --node-type=t3.medium \
    --nodes=3 \
    --nodes-min=2 \
    --nodes-max=4 \
    --node-volume-size=20 \
    --ssh-access \
    --ssh-public-key=key-london \
    --managed \
    --asg-access \
    --external-dns-access \
    --full-ecr-access \
    --appmesh-access \
    --alb-ingress-access
    
    in the above node name = node2 of t3.medium will be created, 3 nodes will be created and at any time min 2 nodes will be available and if required it goes to 4 by autoscaling.
    
    ssh-public-key = key-london (key used to create vm)
    
    cloudformation will create nodegroup (worker nodes).
  - Step 5: check number of nodes
    
    $kubectl get nodes (there will be 3 worker nodes)
  - Step 6: Open Inbound traffic
    
    Go to AWS services/eks/star-eks/Networking/cluster security group/select communication between the control plane and worker nodes /edit inbound rules and define all traffic. save it
  - Step 7: create service account, role, bind role with service account, generate token
    
    Create service account
    
    apiVersion: v1
    kind: ServiceAccount
    metadata:
    name: jenkins
    namespace: webapps
    
    Create role
    
    apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: app-role namespace: webapps rules: - apiGroups: - "" - apps - autoscaling - batch - extensions - policy - rbac.authorization.k8s.io resources: - pods - secrets - componentstatuses - configmaps - daemonsets - deployments - events - endpoints - horizontalpodautoscalers - ingress - jobs - limitranges - namespaces - nodes - pods - persistentvolumes - persistentvolumeclaims - resourcequotas - replicasets - replicationcontrollers - serviceaccounts - services verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    
    Bind Role with service account
    
    apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: app-rolebinding namespace: webapps roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: app-role subjects: - namespace: webapps kind: ServiceAccount name: jenkins
    
    Generate token using service account in the namespace
    
    create a namespace
    
    $kubectl create namespace webapps
    
    apiVersion: v1
    kind: Secret
    type: kubernetes.io/service-account-token
    metadata:
    name: mysecretname
    annotations:
    kubernetes.io/service-account.name: myserviceaccount
    
    To view secret run
    $kubectl -n webapps describe secret mysecretname
  - Delete cluster
    
    eksctl delete cluster --name star-eks --region eu-west-2
    
    Delete VM as well
- Azure AKS- Azure Kubernetes Service
  - login to Azure portal: https://portal.azure.com
- AWS EKS Cluster setup:
  - Install AWS CLI:
    - on your laptop / local VM / AWS VM through we can configure EKS cluster on AWS
    - Get Security Credentials (AWS Security Key, Security Access Key) of a user from AWS(click on user top right corner on aws console and security credentials/ AWS command CLI/ and create keys)
    - ubuntu@ip-172-31-37-97:~$ sudo apt up
    - $curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
      sudo apt-get install unzip -y
      unzip awscliv2.zip
      sudo ./aws/install
    - $aws configure
    - Enter access key and secret access key, Region (eu-west-2)
  - Clone Repository of EKS with Terraform:
    - $git clone https://github.com/AbdulAziz-uk/EKS_with_Terraform.git
    - $cd EKS_with_terraform: This folder container
    - RBAC
    - main.tf: It contains all the codes to create VPC and EKS
    - output.tf: It outputs cluster id, nodegroup id, vpc id, subnet id.
    - variable.tf: It contains ssh key of AWS
  - Install Terraform:
    - $sudo vim terraform.sh
    - paste the below script
      
      #!/bin/bash
      # Script to install Terraform on an instance
      
      # Update package list and install dependencies
      sudo apt-get update && sudo apt-get install -y gnupg software-properties-common
      
      # Add HashiCorp GPG key
      wget -O- https://apt.releases.hashicorp.com/gpg | \
      gpg --dearmor | \
      sudo tee /usr/share/keyrings/hashicorp-archive-keyring.gpg > /dev/null
      
      # Verify the key fingerprint
      gpg --no-default-keyring \
      --keyring /usr/share/keyrings/hashicorp-archive-keyring.gpg \
      --fingerprint
      
      # Add HashiCorp repository to sources list
      echo "deb [signed-by=/usr/share/keyrings/hashicorp-archive-keyring.gpg] \
      https://apt.releases.hashicorp.com $(lsb_release -cs) main" | \
      sudo tee /etc/apt/sources.list.d/hashicorp.list
      
      # Update package lists
      sudo apt update
      
      # Install Terraform
      sudo apt-get install terraform -y
      
      ## Verify installation
      terraform -v
    - make script executable
    - $sudo chmod +x terraform.sh
    - Run Script
    - $sudo sh terraform.sh (it will install terraform)
    - $terraform --version
  - Configure EKS on AWS:
    - Initialize the terraform.
    - ubuntu@ip-172-31-37-97:~/EKS_with_Terraform$ terraform init
    - Run terraform plan:
    - ubuntu@ip-172-31-37-97:~/EKS_with_Terraform$ terraform plan
    - Run Terraform apply:
    - ubuntu@ip-172-31-37-97:~/EKS_with_Terraform$ terraform apply --auto-approve
    - It will create 19 resources:
  - Configure Kubeconfig: We will be able to access the cluster.
    - ubuntu@ip-172-31-37-97:~/EKS_with_Terraform$aws eks --region eu-west-2 update-kubeconfig --name star-cluster
    - Added new context arn:aws:eks:eu-west-2:034646250868:cluster/star-cluster to /home/ubuntu/.kube/config
  - Install kubectl: We can communicate with cluster and perform commands
    - ubuntu@ip-172-31-37-97:~/EKS_with_Terraform$curl -LO https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl
      sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl
      kubectl version --client
  - Install eksctl:
    - ubuntu@ip-172-31-37-97:~/EKS_with_Terraform$curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
      sudo mv /tmp/eksctl /usr/local/bin
      kubectl version --client
  - Associate iam-oidc-provider:
    - ubuntu@ip-172-31-37-97:~$ eksctl utils associate-iam-oidc-provider --region eu-west-2 --cluster star-cluster --approve
  - Create IAM Service Account for EBS CSI Driver:
    - ubuntu@ip-172-31-37-97:~$eksctl create iamserviceaccount \
      --region ap-south-1 \
      --name ebs-csi-controller-sa \
      --namespace kube-system \
      --cluster star-cluster \
      --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
      --approve \
      --override-existing-serviceaccounts
  - Deploy Add-Ons
    - EBS CSI Driver:
    - ubuntu@ip-172-31-37-97:~$kubectl apply -k "github.com/kubernetes-sigs/aws-ebs-csi-driver/deploy/kubernetes/overlays/stable/ecr/?ref=release-1.11"
    - NGINX Ingress Controller:
    - ubuntu@ip-172-31-37-97:~$kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
    - cert-manager:
    - ubuntu@ip-172-31-37-97:~$kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.12.0/cert-manager.yaml
Minikube Single Node Cluster -On Prem
- Mainly it is use for Testing and Training purpose, it can be installed on your laptop/desktop (Windows, Linux, Mac OS).
- All components will install in a single node. Hardware must support virtualization and enabled.
- Windows:
  - Hypervisor should be installed.
  - Install Minikube
  - Install Kubectl.
  - Support Hyper-v or Virtualbox
  - run minikube start
  - a VM is created in hypervisor in which cluster configured.
  - LAB:
    
    Details of configuration.
    
    2 CPUs or more
    
    2GB of free memory
    
    20GB of free disk space
    
    Internet connection
    
    Container or virtual machine manager, such as: Docker, QEMU, Hyperkit, Hyper-V, KVM, Parallels, Podman, VirtualBox, or VMware Fusion/Workstation
    
    run systeminfo on command prompt to check hypervisor is supported.
    
    Step 1: Download package
    
    Download and run the installer minikube-installer.exe click latest release.
    
    Add the minikube.exe binary to your path: open powershell command as administrator and run:
    
    $oldPath = [Environment]::GetEnvironmentVariable('Path', [EnvironmentVariableTarget]::Machine)
    if ($oldPath.Split(';') -inotcontains 'C:\minikube'){
    [Environment]::SetEnvironmentVariable('Path', $('{0};C:\minikube' -f $oldPath), [EnvironmentVariableTarget]::Machine)
    }
    
    Step 2: start your cluster
    
    PS:\minikube start or PS:\minikube start --memory=4096 --driver=hyperkit
    
    It will create Hyper-v VM.
    
    It will prepare kubernetes on docker.
    
    Step 3: Interact with your cluster
    
    If kubectl is not installed than install kubectl.
    
    PS:\minikube status
    
    PS:\kubectl get cs or
    
    PS:\minikube ip
    
    PS:\kubectl get nodes
    
    PS:\kubectl get po -A
    
    PS:\minikube kubectl -- get po -A
    
    PS:\kubectl get nodes
    
    PS:\kubectl get nodes -o wide
    
    Step 4: Deploy hello-minukube
    
    PS:\kubectl create deployment hello-minikube --image=kicbase/echo-server:1.0
    
    PS:\kubectl expose deployment hello-minikube --type=NodePort --port=8080
    
    default port on pods 8080
    
    PS:\kubectl port-forward service/hello-minikube 7080:8080
    
    http://localhost:7080/
    
    Deploy nginx
    
    PS:\kubectl run web-server --image=nginx
    
    PS:\kubectl get pods
    
    PS:\kubectl get pods -o wide
    
    localhost:8080
    
    PS:\minikube stop
    
    Deploy Pod with yaml
    
    Go to https://kubernetes.io/docs/concepts/workloads/pods/
    
    create a yaml file pod1.yaml and paste the follwing:
    
    apiVersion: v1
    kind: Pod
    metadata:
    name: nginx
    spec:
    containers:
    - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80
    
    C:\kubectl create -f pod1.yaml
    
    C:\kubectl get pods
    
    C:\minikube ssh (login to cluster)
    
    To debug the errors:
    
    C:\kubectl describe pod nginx
    
    C:\kubectl logs nginx
    
    C:\kubectl delete pod nginx
    
    Deploy xxx
- Linux:
  - Hypervisor should be installed.
  - Minikube and kubectl should be installed.
  - KVM or virtualbox should be installed.
  - run minikube start
  - a VM is created in hypervisor in which cluster configured.
- Mac OS:
  - Hypervisor should be installed.
  - Minikube and kubectl should be installed.
  - support HyperKit, virtualbox, VMWare Fusion
  - run minikube start
  - a VM is created in hypervisor in which cluster configured.
- If Hypervisor is not installed, than install docker and run minikube start --driver=none, it creates a container and use minkube image to configure cluster. It works only with Linux and Mac OS only. Both support kernel.
- code
Free kubernetes service:
- kubeless kubernetes: You will get readymade cluster. It can be use for Testing or Training purpose
  - Access: https://labs.play-with-k8s.com/ login and create a cluster.
  - login with github or docker account, it is valid for 3 hours only and after that all will be deleted.
- https://killercoda.com/login
KIND- Configure kubernetes Cluster on Docker containers - on prem
- KinD: Kubernetes in Docker, running kubernetes cluster on docker container. For multinode cluster like 1 master/control plane and 2 worker nodes/data plane than docker will create 3 containers.
- Difference between EKS,AKS,GKE vs KinD: EKS,AKS,GKE are cloud based kubernetes cluster which is managed by AWS, Azure, Google and it uses VM while KinD is container based and managed by client. Kind is light weight.
- KinD Setup on Ubuntu, KinD documentation for instruction. Quick Guide/Installation. click installation and select type of installation,
- Pre-requisite: Docker desktop up and running in a VM:
  - Docker Desktop up and running: click for installation steps:-Install Docker Desktop on Ubuntu.
    
    Install using the apt repository
    
    # Add Docker's official GPG key:
    sudo apt-get update
    sudo apt-get install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
    
    # Add the repository to Apt sources:
    echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    sudo apt-get update
    
    Install the docker package:
    
    $sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    
    $sudo usermod -aG docker ubuntu (ubuntu is the current user)
    
    $newgrp docker
    
    $sudo chmod 660 /var/run/docker.sock
    
    Install using DEB package: Alternatively, open a terminal and run:
    
    $systemctl --user start docker-desktop
  - Installing kubectl: kubernetes.io/docs
    
    kubectl: click for Installation steps
    
    sudo apt-get update # apt-transport-https may be a dummy package; if so, you can skip that package sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
    
    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.34/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg sudo chmod 644 /etc/apt/keyrings/kubernetes-apt-keyring.gpg # allow unprivileged APT programs to read this keyring
    
    # This overwrites any existing configuration in /etc/apt/sources.list.d/kubernetes.list echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list sudo chmod 644 /etc/apt/sources.list.d/kubernetes.list # helps tools such as command-not-found to work correctly
    
    sudo apt-get update
    sudo apt-get install -y kubectl
    
    $kubectl version --client (if you run $kubectl version than it will not show version of kubernetes)
    
    Client Version: v1.34.1
    Kustomize Version: v5.7.1
  - KinD tool Installation:
    
    # For AMD64 / x86_64
    [ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-amd64
    # For ARM64
    [ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-arm64
    chmod +x ./kind
    sudo mv ./kind /usr/local/bin/kind
    
    $ kind version
    
    kind v0.29.0 go1.24.2 linux/amd64
- KinD Installation without IP defined (system will assign 127.0.0.1:port):
  - # For AMD64 / x86_64
    [ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-amd64
    # For ARM64
    [ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-arm64
    chmod +x ./kind
    sudo mv ./kind /usr/local/bin/kind
  - run the above command in ubuntu VM where docker is installed already.
  - ubuntu@sonarqube:~$ kind version
  - kind v0.29.0 go1.24.2 linux/amd64
  - Create single node Kubernetes cluster:
  - ubuntu@sonarqube:~$ kind create cluster --name=star-single-node
    
    cluster info:
    
    ubuntu@sonarqube:~$kubectl cluster-info --context kind-star-single-node
    
    ubuntu@sonarqube:~$kind get clusters or
    
    ubuntu@sonarqube:~$kubectl config current-context
    
    Deploy Nginx:
    
    ubuntu@sonarqube:~$kubectl create deployment webserver --image nginx
    
    ubuntu@sonarqube:~$kubectl get pods -o wide
  - Create Multi node kubernetes cluster: 1 control-plane and 3 worker nodes
    
    Go to Kind Documentation/configuration and copy configuration:
    
    kind: Cluster
    apiVersion: kind.x-k8s.io/v1alpha4
    # One control plane node and three "workers".
    #
    # While these will not add more real compute capacity and
    # have limited isolation, this can be useful for testing
    # rolling updates etc.
    #
    # The API-server and other control plane components will be
    # on the control-plane node.
    #
    # You probably don't need this unless you are testing Kubernetes itself.
    nodes:
    - role: control-plane
    - role: worker
    - role: worker
    - role: worker
    
    Create a yaml file and paste the configuration: vim multi-node-cluster.yaml
    
    save and exit
    
    $ kind create cluster --name star-multi-node --config=multi-node-cluster.yaml
    
    $kind -h
    
    Error:
    
    Solution: run the following commands and than run the command to create cluster:
    
    echo fs.inotify.max_user_watches=655360 | sudo tee -a /etc/sysctl.conf echo fs.inotify.max_user_instances=1280 | sudo tee -a /etc/sysctl.conf sudo sysctl -p
    
    ubuntu@sonarqube:~$ kind create cluster --name star-multi-node --config=multi-node-cluster.yaml
    
    ubuntu@sonarqube:~$kubectl get nodes
    
    Deploy nginx:
    
    kubectl create deployment nginx --image=nginx
    
    Port Mapping:
    
    kubectl port-forward pod/POD_NAME 8888:80 (nginx port is 80 and forwarding to 8888)
    
    Access Nginx:
    
    open browser: http://localhost:888
  - Create Multi node kubernetes cluster: 3 control-plane and 6 worker nodes
    
    Go to Kind Documentation/configuration and copy configuration:
    
    kind: Cluster
    apiVersion: kind.x-k8s.io/v1alpha4
    # One control plane node and three "workers".
    #
    # While these will not add more real compute capacity and
    # have limited isolation, this can be useful for testing
    # rolling updates etc.
    #
    # The API-server and other control plane components will be
    # on the control-plane node.
    #
    # You probably don't need this unless you are testing Kubernetes itself.
    nodes:
    - role: control-plane
    - role: control-plane
    - role: control-plane
    - role: worker
    - role: worker
    - role: worker
    - role: worker
    - role: worker
    - role: worker
    
    Create a yaml file and paste the configuration: vim multi-node-cluster.yaml
    
    save and exit
    
    ubuntu@sonarqube:~$ kind create cluster --name star-3multi-6node --config=multi-node-cluster.yaml
- KinD Installation with custom IP and port number:
  - Install Docker:
    
    Install using the apt repository
    
    # Add Docker's official GPG key:
    sudo apt-get update
    sudo apt-get install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
    
    # Add the repository to Apt sources:
    echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    sudo apt-get updatecd
    
    Install the docker package:
    
    sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    
    sudo usermod -aG docker ubuntu (ubuntu is the current user)
    
    newgrp docker
    
    sudo chmod 660 /var/run/docker.sock
    
    Install using DEB package: Alternatively, open a terminal and run:
    
    $systemctl --user start docker-desktop
  - Install kind cli:
    
    # For AMD64 / x86_64
    [ $(uname -m) = x86_64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-amd64
    # For ARM64
    [ $(uname -m) = aarch64 ] && curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.29.0/kind-linux-arm64
    chmod +x ./kind
    sudo mv ./kind /usr/local/bin/kind
    
    run the above command in ubuntu VM where docker is installed already.
    
    $ kind version
    
    kind v0.29.0 go1.24.2 linux/amd64
  - Create a yaml file = kind.yaml
    
    $ vim kind.yaml
    
    kind: Cluster
    apiVersion: kind.x-k8s.io/v1alpha4
    networking:
    apiServerAddress: "192.168.171.201"
    apiServerPort: 58350
    nodes:
    - role: control-plane
    - role: worker
    - role: worker
    
    save & exit (give IP address same as your VM IP:192.168.171.201)
  - Create KinD cluster using yaml file.
    
    $kind -h
    
    $ kind create cluster --config kind.yaml
    
    $ kubectl cluster-info
    
    Error: Command 'kubectl' not found, but can be installed with:
  - Install kubectl:
    
    ubuntu@kubernetes:~$ curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
    
    ubuntu@kubernetes:~$ chmod +x ./kubectl
    
    ubuntu@kubernetes:~$ sudo mv ./kubectl /usr/local/bin/kubectl
    
    ubuntu@kubernetes:~$ kubectl cluster-info kind
  - Create namespace, service account, token and bind service account with admin in kubernetes.
    
    ubuntu@kubernetes:~$ kubectl create namespace jenkins
    
    buntu@kubernetes:~$ kubectl create sa jenkins --namespace=jenkins
    
    There is a secret is available for service account (token) run the command to get
    
    ubuntu@kubernetes:~$ kubectl secret $(kubectl describe serviceaccount jenkins --namespace=jenkins | grep Token | awk '{print $2}') --namespace=jenkins
    
    copy the token.
    
    ubuntu@kubernetes:~$ kubectl create rolebinding jenkins-admin-binding --clusterrole=admin --serviceaccount=jenkins:jenkins --namespace=jenkins
- KinD Installation with Custom IP & extraPortMapping for nodePortIP Service.
  - KinD runs in Docker Contianer, so you cannot directly access the application using NodePort in your computer's network without extra port mapping.
  - ExtraPortMapping tells Docker to map the Container's Ports (NodePorts) to map ports on your computer so that you can access the application using nodeport IP.
  - kind with extra port mapping video.
  - Pre-Requisite:
  - Install Docker: check above pre-requisite section
  - Install KinD: check above pre-reequisite section
  - VM IP:
    
    $ifconfig (192.168.171.105) IP of VM
    
    $ip a|grep s3
    
    2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    inet 192.168.171.105/24 brd 192.168.171.255 scope global noprefixroute ens33
  - Create a yaml file & paste the below code.
    
    $vim kind_with_extraPortMapping.yaml
    
    apiVersion: kind.x-k8s.io/v1alpha4
    
    kind: Cluster
    
    name: star
    
    networking:
    
    apiServerAddress: "192.168.171.105"
    
    apiServerPort: 6445
    
    nodes:
    
    - role: control-plane
    
    extraPortMappings:
    
    - containerPort: 30001
    
    hostPort: 30001
    
    protocol: TCP
    
    - containerPort: 30002
    
    hostPort: 30002
    
    protocol: TCP
    
    - containerPort: 30003
    
    hostPort: 30003
    
    protocol: TCP
    
    - containerPort: 30004
    
    hostPort: 30004
    
    protocol: TCP
    
    - containerPort: 80 #If this port is already used (do not use)
    
    hostPort: 80
    
    protocol: TCP
    
    - containerPort: 8080 #If this port is already used (with jenkins, do not use)
    
    hostPort: 8080
    
    protocol: TCP
    
    - role: worker
    
    - role: worker
    
    $kind -h
    
    $kind create cluster --config kind_with_extraPortMapping.yaml
    
    kind_with_extraPortMapping1.jpg
    
    $kubectl cluster-info
    
    $kubectl cluste-info --context kind-star-kind
  - Run Deployment and access the application using NodePort IP.
    
    Create a namespace:
    
    $kubectl create namespace star
    
    Create a deployment web-server using image nginx
    
    $kubectl -n star create deployment web-server --image=nginx
    
    deployment.apps/web-server created
    
    $kubectl -n star get all
    
    kind_with_extraPortMapping2.jpg
    
    Expose the deployment to port 80
    
    $kubectl -n star expose deployment web-server --port 80
    
    $kubectl -n star get all
    
    kind_with_extraPortMapping3.jpg
    
    Service/web-server, type=ClusterIP = 10.96.200.225
    
    Expose the service to NodePort:
    
    $kubectl -n star patch svc web-server -p '{"spec": {"type": "NodePort"}}'
    
    service/web-server patched
    
    $kubectl -n star get all or $kubectl -n star get svc
    
    kind_with_extraPortMapping4.jpg
    
    NodePort, IP = 10.96.200.225, port = 80:31555/TCP
    
    $curl 192.168.171.105:31555 (it will not connect to this port)
    
    While creating KinD we have defined port numbers 30001, 30002, 30003, 30004, 30005
    
    here port has been defined 315555, we need to edit service web-server and change port expose port to either 30001 or any defined.
    
    $kubectl -n star edit svc web-server
    
    change port, save & exit
    
    kind_with_extraPortMapping5.jpg
    
    $kubectl -n star get svc
    
    Access the application:
    
    $curl 192.168.171.105:30001 or http://192.168.171.105:30001
    
    kind_with_extraPortMapping6.jpg
    
    Delete Cluster:
    
    Get cluster name:
    
    $kind get clusters (star-kind)
    
    $kind delete cluster --name star-kind
- For multiple cluster setup click here and Context commands.
  - KinD_multiple_Cluster.jpg
  - For specific version (V1.31.4) check on KinD site or github
  - KinD_multiple_Cluster1.jpg
  - $kind -h
  - $kind create cluster --name kind-dev --config multi_cluster.yaml
  - $kind create cluster --name kind-stage --config multi_cluster.yaml
  - $kind create cluster --name kind-prod (This imperative method will take latest version as we have not specified yaml file, it creates only one node=control-plane)
  - $kubectl get nodes
    
    one control-plane node as user is in kind-dev cluster.
    
    user is managing three clusters.
  - Context: ties user with the cluster.
  - Get the commands for configuration.
    
    $kubectl config -h
  - List of clusters:
  - $kubectl config current-context (Display the current-context)
  - $kubectl config delete-cluster
  - $kubectl config delete-context
  - $kubectl config delete-user
  - $kubectl config set-cluster
  - $kubectl config set-context
  - $kubectl config use-context
  - $kubectl config view
  - View config file which has all the info about cluster, user
  - $kubectl config view
  - location of config file = $~/.kube/config
  - view config file=$~/.kube/cat config
- Integration KIND cluster with Jenkins:
  - Go to jenkins page:
  - Eliminate Executor: click on Build Executor Status (0 of 2 executors busy)>click on node / Configure/number of executor=0,label =any text, Usage=Only build jobs with label expressions matching this node/ apply
  - check dashboard
  - To use Kubernetes cluster as agent perform the following steps:
  - Install Plugin:
    
    Go to Manage Plugin and search in available kubernetes (This plugin integrates Jenkins wiht Kubernetes) select and install (it will install 5 other plugins as depedencies)
    
    restart jenkins
    
    Setup Node/Cloud:
    
    Manage Jenkins/Cloud/New Cloud/select kubernetes, Cloud name=kubernetes click create. Enter the required details
    
    select websocket and enter jenkins url = http://192.168.171.202:8080/
- KinD installation on Windows:
- KinD installation On Mac:
Access & Manage Cluster Remotely
- Windows
  - To manage and control cluster, get remote connection.
  - After cluster configuration there will be a admin.conf file is created at /etc/kubernetes/admin.conf
  - copy the file and paste it in local computer by creating a folder .kube in user folder and rename the file to config
  - Install kubectl for windows/linux/mac OS: click here
    
    Create a folder local C:\users\username\kubernetes and paste kubectl here
    
    set environment variable: system/advanced system settings/Environment Variable/user variable/ new/Variable name: PATH, Variable Value: paste path
  - Create a folder .kube in local system in C:\users\username
  - Paste the admin.conf file and change name to config. use winscp to copy file.
  - Go to kubernetes master node: /etc/kubernetes/ copy admin.conf (it can bring with winscp), use sftp, hostname - ip of master node, user name and password
  - Paste it in C:\users\username\.kube\admin.conf (rename it to config)
- Linux
  - Code
Kubectl:
- It is a command line tool for kubernetes to execute commands on kubernetes cluster.
- for installation https://kubernetes.io/docs/tasks/tools/
After kubernetes VM restart, start following services
- Code
Remove node from cluster and rejoin
- List nodes:
  - $kubectl get nodes
- First Drain the node
  - $kubectl drain <node-name>
  - Error: unable to drain node "worker1" due to error: cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore): kube-system/calico-node-7nqpz, kube-system/kube-proxy-xdn4v, continuing command...
    There are pending nodes to be drained:
    worker1 cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore): kube-system/calico-node-7nqpz, kube-system/kube-proxy-xdn4v
  - You might have to ignore daemonsets and local-data in the machine: try following
  - $kubectl drain <node-name> --ignore-daemonsets --delete-local-data or
  - $kubectl drain <node-name> --ignore-daemonsets
- Delete the node:
  - $kubectl delete node <node-name>
- Reset the cluster:
  - $kubeadm reset (If you are using kubeadm and would like to reset the machine to a state which was there before running kubeadm join then run)
- Join the cluster:
  - $kubeadm token create --print-join-command
  - copy the command and run on worker node to join.
Removing Kubernetes completely
- $kubeadm reset
- sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*
code
- Code
code
- Code

PODs/Labels/Namespace/POD Limit/Taint & Tolerations/Autoscaling/configmaps/secrets/Replication/Service/storage

Single & Multi container PODs Creation: Imperative & Declarative Method

Pods/replication/services/objects can be created with Imperative & Declarative Methods.
- Impearative method: It is command based method where you enter command in along with arguments.
- Declarative method: Set of commands defined in a file (manifest/definition file) in yaml/jason format and execute the file.
  - These files contains 4 top level fields
  - apiVersion: can be considered as a code library. every kubernetes object depends on this code library for handling different activities related to that object.
  - kind: This is used to specify what kubernetes objects has to be created. Each of this kubernetes onjects depend on a specific api version.
  - metadata: Data about the data is called metadata. Here we store user defined information about kubernetes objects. ex. Name, author, supporting platforms etc..
  - spec: This is location where information about the container/services is stored. name of container, port mapping, environment variablel etc..
  - Status:
  - apiVersion: Depending on kubernetes objects that is creating, corresponding code library can use.
    - kind apiVersion
      
      Pod v1
      
      Service v1
      
      Namespace v1
      
      Replica Controller v1
      
      ReplicaSet apps/v1
      
      Deployment apps/v1
  - Comparision of tope level elements of yaml file in docker compose, ansible and kubernetes.
    - Docker Compose Ansible Kubernetes
      
      version:
      services: - Name:
      hosts:
      tasks: apiversion:
      kind:
      metadata:
      specs:
Create a single container pod with Imperative method:
- Get the syntax for creating a pod
  - $ kubectl run -h (it will list all the options can be used)
- Create a POD: nginx, mysql
  - $kubectl run web-server --image=nginx:latest
    - (web-server = pod name, --image = nginx:latest (latest version of nginx image is used, if latest is not defined than it takes latest by default))
  - port:
    - $kubectl run web-server --image=nginx:latest --port=5701
  - set environment variable "DNS_DOMAIN=cluster" & --env="POD_NAMESPACE=default
    - $kubectl run web-server --image=nginx:latest --env="DNS_DOMAIN=cluster" --env="POD_NAMESPACE=default
  - set label and environment
    - $kubectl run web1 --image=nginx --labels="app=star,env=dev"
    - $kubectl get pods -o wide --show-labels
  - Run in foreground, don't restart it if it exits
    - kubectl run -i -t busybox --image=busybox --restart=Never
  - Create My SQL Pod:
    - $kubectl run --image mysql:5 dbserver --env MYSQL_ROOT_PASSWORD=India123
  - rm
    - $kubectl run web-server --rm -it --image=nginx -- /bin/bash
    - --rm is used to automatically delete pod when you exit from pod.
    - exit
      pod "web-server1" deleted from default namespace
  - restart=Never
    - --restart=Never
    - If pod failed, do not restart automatically
  - labels:
    - --labels=key=value
    - labels does not support in deployment with imeparative commands.
  - it
    - -it
    - start the interactive terminal
  - /bin/bash or /bin/sh
    - -- /bin/bash or --/bin/sh
    - Terminal start with bash
  - resolv.conf
    - get the nameserver which resolve dns name or perform name resolution in container.
    - #cat /etc/resolv.conf (run this command from a container)
  - Code
- Create a deployment and service with imperative method:
  - Create Deployment:
    - $kubectl create deployment -h (it will list all options & arguments)
    - Run the above with dry run: it will check the syntax and schema is correct, it will not create the deployment.
      
      kubectl create deployment backend-deploy \
      --image=hashicorp/http-echo \
      --replicas=3 \
      --port=5678 \
      --dry-run=client
      
      deployment.apps/backend-deploy created (dry run), it does not create deployment but gives output of command.
    - Run with dry run server: it will send request to api server and check the syntax and format is correct.
      
      kubectl create deployment backend-deploy \
      --image=hashicorp/http-echo \
      --replicas=3 \
      --port=5678 \
      --dry-run=server
      
      deployment.apps/backend-deploy1 created (server dry run)
    - Create the backend deployment:
      
      $kubectl create deployment backend-deploy \
      --image=hashicorp/http-echo \
      --replicas=3 \
      --port=5678 \
      
      To view the above imperative command in yaml file: run
      
      $kubectl create deployment backend-deploy \
      --image=hashicorp/http-echo \
      --replicas=3 \
      --port=5678 \ -o yaml > backend-deployment1.yaml
      
      check $cat backend-deployment1.yaml (it uses some additional arguments)
  - Create ClusterIP (backend Service ): Expose the above deployment
    - $ kubectl expose service -h (it will list all options & arguments)
    - Run with dry run server: it will send request to api server and check the syntax and format is correct.
      
      $kubectl expose deployment backend-deploy \
      --type=ClusterIP \
      --port=9090 \
      --target-port=5678 \
      --name=backend-svc \
      --dry-run=client -o yaml > backend-svc.yaml
    - Create the Service:
      
      $kubectl expose deployment backend-deploy \
      --type=ClusterIP \
      --port=9090 \
      --target-port=5678 \
      --name=backend-svc \
  - Create frontend-deployment:
    - $kubectl create deployment frontend-deploy \
      --image=nginx \
      --replicas=3 \
      --port=80 \
  - Create NodePort (frontend-svc): Expose the above deployment
    - kubectl expose deployment frontend-deploy \
      --type=NodePort \
      --port=80 \
      --target-port=80 \
      --nodePort: 30001
      --name=frontend-svc \
- Edit
  - $kubectl edit pod pod_name
- Port Forwarding:
  - $kubectl port-forward pod_name 8080:80
- Namespace:
  - $kubectl create namespace star
  - $kubectl get ns
  - $kubectl delete namespace star
- View POD
  - $kubectl get pods
  - web-server 1/1 Running 0 31s (1/1 means 1 pod has 1 container)
- Access the POD:
  - $kubectl exec -it web-server -- /bin/bash (To get into pod in interactive mode)
  - $kubectl exec -it web-server -c container_name -- /bin/bash (if multiple container in pod)
  - $kubectl exec -it web-server -c container_name -- /bin/bash (To get into pod in interactive mode with a particular container, if multiple containers)
- Delete Pod:
  - $kubectl delete pod pod_name
- Logs
  - $kubectl logs pod_name
- Location of html file in nginx
  - /usr/share/nginx/html
Create a single container pod with dry-run:
- It will not apply the command but will execute and give the command outcome.
- $kubectl run web-server3 --image=nginx --dry-run=client
- pod/web-server3 created (dry run), it did not create the pod.
- Create a pod with dry-run and save it in yaml file.
  - $kubectl run web-server4 --image=nginx --dry-run=client -o yaml > web-server.yaml

Create single & multi container pods with Declarative method using (YAML) file:

Master- Create a single pod
- To get code syntax
  - $kubectl explain pod (for more details check in Declarative section above)
  - Google search kubernetes pod creation yaml
- Create a yaml file
  - $vim web1.yaml (use vim for colour coding in yaml file)
  - Enter the code:
    
    apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: web-server1
    
    labels:
    
    env: Dev
    
    type: frontend
    
    Author: AbdulAziz
    
    spec:
    
    containers:
    
    - name: star-server1
    
    image: nginx
    
    ports:
    
    - containerPort: 80
- Deploy the code:
  - $kubectl apply -f web1.yaml
  - $Kubectl run web-server1 --image=nginx : When you deploy an application in kubernetes first it creates a pod and than it creates two containers (pause & nginx containers)
  - Pause container: which stores Pod's IP address and a namespace, namespace bind with IP address.
  - nginx container: It will be created for application deployment and add it with the namespce.
  - further deployment containers will be created in the same pod and add it will the same namespace of pause container. it means all the containers of pod use the same network/IP address.
- List of pod
  - $kubectl get pods (pods information)
  - $kubectl get pods -o wide (extended pods information )
  - It will show 1/1 one pod and one container and will not show pause container.
- Access the pod:
  - $kubectl exec -it podname -- /bin/bash (To get into pod in interactive mode) or $kubectl exec -it podname -- /sh
  - $kubectl exec -it podname -c container_name -- /bin/bash (if multiple container in pod)
  - $kubectl exec -it podname -c container_name -- /bin/bash (To get into pod in interactive mode with a particular container, if multiple containers)
  - root@web-server2:/# ls -ltr (you are in pod web-server2, run ls -ltr for files and folders)
- Edit pod details:
  - $kubectl edit pod podname
  - Make correction and save it.
- Details of the pod & containers:
  - $kubectl describe pod podname
  - pod_describe.jpg
  - It will show complete details of pod, containers, conditions, volumes, etc..
    
    Name:
    
    Namespace:
    
    Priority:
    
    Service Account:
    
    Start Time:
    
    Annotations:
    
    Status:
    
    IPs:
    
    Containers:
    
    Container ID:
    
    Image:
    
    Image ID:
    
    Port:
    
    Host Port:
    
    Args:
    
    State:
    
    Started:
    
    Ready:
    
    Restart Count:
    
    Environment:
    
    Mounts:
    
    Conditions:
    
    Type:
    
    PodReadyToStartContainers:
    
    Initialized:
    
    Ready
    
    ContainersReady:
    
    PodScheduled:
    
    Volums:
    
    QoS Class:
    
    Node-Selectors:
    
    Tolerations:
    
    Events:
- Delete pod:
  - $kubectl delete pod podname
- Show label of a pod:
  - Labels are define to PODs to use them as reference, in replication we define to manage pods with their label name.
  - Show Labels:
    
    $kubectl get pod --show-labels
    
    web-server2 1/1 Running 0 37m env=lab,type=frontend (it has two labels)
    
    $kubectl run web-server --image=nginx (Pod will be created using default label, run=web-server)
  - Remove label:
    
    $kubectl label pod web-server run- (it will remove label run=web-server and will show <none>)
  - Add label:
    
    $kubectl label pod web-server team=dev (label team=dev will be assign)
Pause Container:
- When a pod is created a pause container is also created, whcih can be check in the node $docker container ls
  - first a pause container gets created which contain namesapce and then your desired container gets created.
  - when you delete a container then both container and pause container gets deleted.
Creating 2 pods of different image (one pod two containers):
- Deploy nginx and tomcat
- Create a pod with multiple containers, in first container run tomcat and second container run nginx,
- Both containers will use same network (pause container) and have same IP address.
- It is possible than you can deploy both tomcat and nginx in same container but not advisable.
- $vim dual-pods.yaml
  - apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: dual-pods
    
    spec:
    
    containers:
    
    - name: webserver-tomcat
    
    image: tomcat
    
    - name: webserver-nginx
    
    image: nginx
- $kubectl apply -f dual_pods.yaml
- $kubectl get pods
Creating 2 pods of same image (one pod two containers):
- $vim multicontainers2.yaml
  - apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: star-multicontainers
    
    spec:
    
    containers:
    
    - name: firstcontainer
    
    image: nginx
    
    - name: secondcontainer
    
    image: nginx
- $kubectl apply -f multicontainers2.yaml
- $kubectl get pods
- Error: Kubernetes will try to deploy two containers but only one will work and another will get an error.
  - CrashLoopBackoff Error:
  - multicontainer1.jpg
  - Check details of pods to get more information.
  - $kubectl describe pod podname
  - multicontainer2.jpg
  - solution: Edit multicontainers.yaml and add args: ["sleep", "3600"] on first container.
    - apiVersion: v1
      
      kind: Pod
      
      metadata:
      
      name: star-multicontainers
      
      spec:
      
      containers:
      
      - name: firstcontainer
      
      image: nginx
      
      args: ["sleep", "3600"]
      
      - name: secondcontainer
      
      image: nginx
  - $kubectl apply -f multicontainers.yaml
  - $kubectl get pods
  - star-multicontainers 2/2 Running 0 6s
  - Now both containers are running with same image.
Creating 3 pods (one pod three containers):
- Deploy web, app and database containers in a pod
- 2 containers with same image: It is possible it will deactive one of the container if it is not active.

Multi-Container Pods

More Details: https://github.com/AbdulAziz-uk/kubernetes-complete-tutorial/tree/main/Day%2021%20-%20Multi-Container%20Pods
multi_container_pod1.jpg
Share network namespaces (e.g., containers communicate within a pod via localhost).
Can access shared storage volumes (volumes are attached to pod and mount to containers).
multi_container_pod2.jpg
Init Containers:
- Init containers are startup containers designed to run before the main application container. They perform initialization tasks like:
  - Preparing configurations or environments.
  - Waiting for dependencies like APIs or databases to be ready.
  - Performing pre-checks to ensure proper startup conditions.
- How Init Containers Work?
  - They always run to completion (success or failure).
  - Run sequentially, one after the other.
  - If any init container fails, the main container never starts.
- Use Cases:
  - Database readiness: Verify connection or schema migration before app startup.
  - External API health checks: Ensure critical APIs are reachable.
    
    Lab:
    
    check API availability before main application start
    
    The application depends on the availability of https://kubernetes.io. Ensure this API is accessible before launching the main application.
    
    $vim init_container1.yaml
    
    apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: init-demo
    
    spec:
    
    initContainers:
    
    - name: check-api
    
    image: curlimages/curl:latest
    
    command:
    
    - sh
    
    - -c
    
    - |
    
    echo 'Checking API availability...'
    
    sleep 25
    
    until curl -s https://kubernetes.io > /dev/null; do
    
    echo 'Waiting for API...'
    
    sleep 5
    
    done
    
    echo 'API is accessible, proceeding to main-app container!'
    
    containers:
    
    - name: main-app
    
    image: nginx:latest
    
    Explanation:
    
    Init Container (check-api):
    
    Uses the curlimages/curl image to run curl commands.
    
    sh -c → Runs the entire script inside a shell, allowing multiple commands and loops.
    
    | (Block Scalar) →
    
    This is a YAML multi-line block indicator.
    
    It allows you to write multiple lines of commands in a more readable, clean format, instead of squeezing everything into a single line.
    
    Everything under | is treated as a single string, preserving line breaks.
    
    It improves readability when commands are complex (loops, conditions, multiple steps).
    
    Inside the block:
    
    echo 'Checking API availability... → Prints an initial message indicating that the init container is starting the API availability check.
    
    sleep 25 → Introduces a deliberate 25-second delay, giving you time to observe the init container behavior before it proceeds.
    
    until curl -s https://kubernetes.io > /dev/null →
    
    Sends a silent HTTP request to https://kubernetes.io.
    
    -s suppresses progress/output.
    
    > /dev/null discards output, keeping logs clean.
    
    Retries until a successful response is received (exit code 0).
    
    do echo 'Waiting for API...'; sleep 5; done →
    
    Inside the loop, prints "Waiting for API...", waits 5 seconds, and retries.
    
    done marks the end of the loop body—everything inside do ... done repeats until the condition is met.
    
    echo 'API is accessible, proceeding to main-app container!' →
    
    Placed after done, meaning it only runs once the loop exits successfully.
    
    Clearly signals in logs that the API is reachable and the init container has completed, allowing the main container to start.
    
    Main Container (main-app):
    
    Starts only after the init container finishes its task.
    
    Prints a message confirming the app has started and remains idle for demonstration purposes.
    
    Run the above lab:
    
    Apply the Yaml:
    
    $kubectl apply -f init_container1.yaml
    
    Check Pod status:
    
    $kubectl get pods -o wide
    
    NAME READY STATUS RESTARTS AGE
    init-demo 0/1 Init:0/1 0 9s
    
    Observe the pod in the Init phase while the init container performs its checks.
    
    Inspect logs of the init container:
    
    $kubectl logs init_container1 -c check-api
    
    View the logs showing messages like:
    
    "Checking API availability..."
    
    "Waiting for API..."
    
    "API is accessible!"
    
    Once the Init Container Completes:
    
    The main container starts successfully
    
    $kubectl logs init_container1 -c main-app
    
    $kubectl describe pod init-demo
    
    Extended Lab: Two Init Containers (API + Service Check) before main application start:
    
    In addition to checking the external API (https://kubernetes.io) in th above case, ensure that an internal Kubernetes Service (main-app-svc) is also available before the main application starts.
    
    $vim init_container2.yaml
    
    apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: init-demo-2
    
    labels:
    
    app: main-app
    
    spec:
    
    initContainers:
    
    - name: check-api
    
    image: curlimages/curl:latest
    
    command:
    
    - sh
    
    - -c
    
    - |
    
    echo 'Checking external API availability...'
    
    sleep 25
    
    until curl -s https://kubernetes.io > /dev/null; do
    
    echo 'Waiting for external API...'
    
    sleep 5
    
    done
    
    echo 'External API is accessible, proceeding to next init container!'
    
    - name: check-svc
    
    image: curlimages/curl:latest
    
    command:
    
    - sh
    
    - -c
    
    - |
    
    echo 'Checking main-app Service availability...'
    
    until nslookup main-app-svc.default.svc.cluster.local; do
    
    echo 'Waiting for Service DNS resolution...'
    
    sleep 5
    
    done
    
    echo 'Service is reachable, proceeding to main-app container!'
    
    containers:
    
    - name: main-app
    
    image: nginx:latest
    
    $vim init_container2_service.yaml
    
    apiVersion: v1
    
    kind: Service
    
    metadata:
    
    name: main-app-svc
    
    spec:
    
    selector:
    
    app: main-app
    
    ports:
    
    - protocol: TCP
    
    port: 80
    
    targetPort: 80
    
    Explanation:
    
    Init Container 1 (check-api):
    
    Same as the previous demo: checks availability of https://kubernetes.io before proceeding.
    
    Init Container 2 (check-svc):
    
    sh -c →
    
    Invokes a shell (sh) to run the entire block of commands as a single script.
    
    echo 'Checking main-app Service availability...' →
    
    Prints a message indicating the start of the Service availability check.
    
    until nslookup main-app-svc.default.svc.cluster.local > /dev/null; do →
    
    Uses nslookup to check if the DNS entry for the Service main-app-svc.default.svc.cluster.local is resolvable.
    
    until loop keeps running until DNS resolution succeeds (i.e., until nslookup returns exit code 0).
    
    > /dev/null discards any output, keeping logs clean.
    
    echo 'Waiting for Service DNS resolution...' →
    
    Prints a message while waiting, so you can monitor progress.
    
    sleep 5 →
    
    Adds a 5-second delay before retrying, to avoid spamming DNS queries.
    
    done →
    
    Ends the loop; the script continues once DNS resolution is successful.
    
    echo 'Service is reachable, proceeding to main-app container!' →
    
    Once the Service is resolvable, this message is printed, and the init container completes successfully.
    
    In-Summary:
    
    This init container is ensuring that the Kubernetes Service main-app-svc is DNS-resolvable and available before starting the main container.
    
    It blocks the main container until that condition is met—perfect use of an init container to handle dependency readiness.
    
    Main Container (main-app):
    
    Starts after both init containers have successfully completed their checks.
    
    How to run this lab:
    
    Apply the Service YAML:
    
    $kubectl apply -f init_container2_service.yaml
    
    Apply the Pod YAML:
    
    $kubectl apply -f init_container2.yaml
    
    Check Pod Status:
    
    $kubectl get pods
    
    Inspect Logs of Both Init Containers:
    
    $kubectl logs init-demo-2 -c check-api
    
    $ kubectl logs init-demo-2 -c check-svc
    
    Check Main Container Logs:
    
    $ kubectl logs init-demo-2 -c main-app
  - File or directory initialization: Create required directories or files for the app.
  - Fetching secrets/configurations: Download secrets from external systems.
  - Cleaning up temporary files: Ensure temporary files from previous runs are removed.
Sidecar Pattern:
- The Sidecar Pattern involves containers that extend or complement the main container's functionality. Sidecars run alongside the primary container and operate independently.
- References:
  - Kubernetes Official Docs - Init Containers
  - Kubernetes Blog - The Distributed System Toolkit: Patterns
- Use Cases:
  - Logging: Collect logs and send them to central systems (e.g., Fluentd, Fluent Bit).
  - Monitoring: Export metrics for tools like Prometheus.
  - Proxying: Handle incoming traffic (e.g., Envoy, Istio, AWS App Mesh).
  - Data synchronization: Sync files or configurations to external locations.
- A sidecar proxy can intercept network traffic flowing into the pod, provide telemetry data, or encrypt the communication.
- Lab: Sidecar Container for API Health Check and Logging
  - This example illustrates a Sidecar Container that monitors the main application by periodically checking its health endpoint and logging the health status.
  - Your main application is running, and you want a lightweight container to act as a health-check monitor and log the status of the main app's health.
  - $vim sidecar.yaml
    
    apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: sidecar-logging-demo
    
    spec:
    
    containers:
    
    # Main application container
    
    - name: main-app
    
    image: nginx:latest
    
    ports:
    
    - containerPort: 80
    
    # Sidecar container
    
    - name: health-logger
    
    image: curlimages/curl:latest
    
    command:
    
    - sh
    
    - -c
    
    - |
    
    while true; do
    
    curl -s http://localhost:80 > /dev/null && echo 'Main app is healthy' || echo 'Main app is unhealthy'
    
    sleep 5
    
    done
  - Explanation:
    
    Main Application Container (main-app):
    
    Uses the nginx image to simulate an application.
    
    Listens on port 80.
    
    Sidecar Container (health-logger):
    
    Uses the curlimages/curl image to perform health checks. Certainly! Here's the improved bullet-style explanation including the || operator explanation clearly:
    
    Uses the sh shell with -c flag to execute the entire script as a single command.
    
    Starts an infinite loop using while true; do ... done to continuously check the main app's health.
    
    Sends a silent HTTP request to http://localhost:80 using curl -s to check if the main app is reachable.
    
    Redirects the output to /dev/null to discard response content and keep logs clean.
    
    Uses && echo 'Main app is healthy' to print the message only if the curl command succeeds (exit code 0).
    
    Uses || echo 'Main app is unhealthy' to print the message only if the curl command fails (non-zero exit code).
    
    && and || are logical operators; && executes the next command on success, while || executes the next command on failure.
    
    Waits for 5 seconds after each check using sleep 5 before repeating the loop.
    
    Continuously monitors the main container’s health over the shared network namespace within the pod.
  - Run this lab:
  - Apply the YAML:
    
    $kubectl apply -f sidecar.yaml
  - Check Pod Logs:
    
    $kubectl logs sidecar-logging-demo -c health-logger
  - Simulate Failure:
    
    To simulate app unavailability:
    
    $kubectl exec -it sidecar-logging-demo -c main-app -- /bin/sh
    
    Once inside the container:
    
    kill 1
    
    Check the sidecar container logs again:
    
    $kubectl logs sidecar-logging-demo -c health-logger
    
    Main app is unhealthy
    
    Main app is unhealthy
Ambassador Pattern:
- The Ambassador Pattern involves containers that act as proxies between the pod and external systems. Unlike the sidecar pattern, the ambassador is focused on handling external communication.
- Use Cases:
  - API Gateways: Proxy external client requests to internal services, routing traffic based on paths or headers (e.g., /api/orders to Order Service).
  - Connection Management: Optimize and pool connections to external resources like databases or APIs, ensuring efficient usage (e.g., managing PostgreSQL connections).
  - Security: Terminate TLS or add authentication layers (e.g., handling OAuth token validation before forwarding requests).
- An ambassador container can proxy requests to databases (e.g., Amazon RDS), external queues (e.g., Amazon SQS), or cloud services like Azure API Gateway.
- Code
Adapter Pattern:
- The Adapter Pattern involves containers that transform or normalize data between the main container and an external system. These are ideal for applications requiring data compatibility adjustments.
- Use Cases:
  - Metric transformation: Convert custom application metrics into standard formats like Prometheus.
  - Log normalization: Process and format logs for external systems.
- An adapter container collects JSON-based metrics from the app, converts them to Prometheus format, and makes them available for scraping.
- Code

Difference: Init Vs Sidecar Vs Ambassar Vs Adapter Containers:

Aspect	Init Containers	Sidecar / Ambassador / Adapter Containers
Lifecycle	Run to completion before main container starts	Run alongside main container, continue as long as the pod runs
Order of Execution	Always run before the main container, in sequence if multiple	Start in parallel with the main container
Dependency on Success	Main container won’t start unless all init containers complete successfully	Main container can run independently of helper containers (but may rely on their functionality)
Restart Behavior	Re-run only if they fail before completion	Restart policies apply same as main container (`Always`, `OnFailure`, etc.)
Purpose	Setup, preparation, environment bootstrapping, preconditions check	Enhance, complement, or adapt runtime behavior of the main container
Resource Consumption	Consume resources temporarily, freed once completed	Consume resources throughout the pod’s lifetime
Common Use-Cases	- Database migrations - Configuration fetch - Waiting for dependencies - Permission setup	- Log collection - Proxying (Service Mesh) - External communication handling (Ambassador) - Metrics/log format adaptation
Visibility to Main Container	Prepare shared volumes or environment, not visible as active containers	Main container and helpers can interact live via shared network & volumes
Network Behavior	Share network namespace, but only active until completion	Share network namespace, actively communicate during pod lifetime
Fail Impact	Pod won’t proceed if init fails	If they fail, pod continues, but functionality (e.g., logging, proxying) may degrade

Code

Definition File Example3: Create a pod definition file which creates a pod from postgress docker image and container name should be mydb, this container should be created in a pod name postgress-pod. Give the labels as author: aziz type: database.
- - $sudo vim pod-definition2.yml
  ---
  apiVersion: v1
  kind: Pod
  metadata:
  name: postgress-pod
  labels:
     author: aziz
     type: database
  spec:
  containers:
     - name: mydb
  image: postgres
  ...
  - $kubectl create -f pod-definition2.yml
  - code
  - code

Definition File example4: create pod definition file which will start a pod in which can have mysql container, the name of pod should be sql-pod and also pass necessary environment variables.

$sudo vim pod-definition4.yml

---
apiVersion: v1
kind: Pod
metadata:
name: sql-pod
labels:
   author: aziz
   type: database
spec:
containers:
   - name: mysql
     image: mysql:5
     env:
      - name: MYSQL_ROOT_PASSWORD
        value: India123
...

$kubectl create -f pod-definition4.yml
- $kubectl delete -f pod-definition4.yml
code
code

Definition File example5: Create a pod definition file which will start a pod in which can have jenkins and port mapping 8080.

$sudo vim pod-definition5.yml

---
apiVersion: v1

kind: Pod
metadata:
name: jenkins-pod
labels:
author: aziz
spec:
containers:
   - name: myjenkins
   image: jenkins/jenkins
   ports:
      - containerPort: 8080
        hostPort: 8080
...

In docker container we define port in run command -p 8080:5050 where 8080 is default container port mapped to 5050,

here container port is 8080 which is mapped to 8080 so you can access from your laptop with 8080 port.

$kubectl create -f pod-definition5.yml
- To access the jenkins.
  - $kubectl get pods -o wide (get the node on which pod is running).
  - $kubectl get nodes -o wide (take the public IP of node on which pod is running.
  - browser: publicIP:8080
  - open port 8080
    - $gcloud compute firewall-rules create jenkinsrule --allow tcp:8080
kompose Install: Implementing docker compose in kuberntes is called kompose, we can create multi container architecture as defined in the docker compose file. Deployed that in kubernetes cluster.
- search in google kompose install, choose from digitalocean site https://www.digitalocean.com/community/tutorials/how-to-migrate-a-docker-compose-workflow-to-kubernetes
code

Definition File Example6: Create a docker compose file for linking 3 replicas of wordpress with one replica of mysql.

$sudo vi docker-compose.yml

---
version: '3'
services:
mydb:
   image: mysql:5
    environment:
     MYSQL_ROOT_PASSWORD: India123
mywordpress:
   image: wordpress
   ports:
     - 9090:80
   deploy:
    replicas: 3
...

To start all the services from the above compose file
- $kompose up
- To delete all the services
  - $kompose down
code
code

Definition File example9: Create RelicaSet file whch will create 4 replicas of httpd pods and these replicas should be selected based on type = webserver

$sudo vim definition_example9.yml

---
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: httpd-rs
labels:
author: aziz
type: webserver
spec:
replicas: 4
selector:
matchLabels:
type: webserver
template:
metadata:
name: httpd-pod
labels:
type: webserver
spec:
containers:
- name: myhttpd:
image: httpd
ports:
-containerPort: 80
hostPort: 8888
...

$kubectl create -f rs-definition-example9.yml
- $kubectl get pods -o wide
Scaling: You can add / remove number of replicas from ReplicasSet
- In the above example make replicaset = 6. edit the definition_ecample9.yml and change replicas: 6
- $kubectl replace -f rs-definition-example9.yml
- You can scale number from command without editing definition file.
- $kubectl scale --replicas=3 -f rs-definition-example9.yml

Replication of PODS: Replication Controller, Replicaset, Deployment

When a single pod is created, when it gets deleted or crashed than there is no mechanism to recreate automatically to avoid service disruption.
If a pod/container gets deleted/crashed than appliation running inside will not be accessible. To avoid disruption or downtime, we can replicate the pods so that application can be assible even one of the pods get deleted..
To maintain the desired number of pods in a Kubernetes cluster, you can use a Replication Controller, ReplicaSet, Deployment.
These resources ensure that a specified number of pod replicas are running at all times. If any pod gets deleted or fails, Kubernetes will automatically create a new one to replace it.
When a new pod is created than a new IP address will be assign, if we have used the IP address in some integration than we need to manually change the IP address.
To avoid this manual work, we create a service on top of replication and an IP assign to this service which we access. This service than forward the request to attached pods(endpoints) using round robin method.

It is use to control pods. It is similar like Autoscaling in VMs where any VM gets deleted than a new VM created. In kubernetes we call controller.

Types of Replication: More details on these topics click mirantis
Replication Controller:
- Replication Controller:
  - A Replication Controller is a structure that enables you to easily create multiple pods, then make sure that that number of pods always exists. If a pod does crash, the Replication Controller replaces it.
  - There could be lot of pods in a nodes, controller will manage those pods with the defined label name. label is a key value pair.
  - Replication controller will mange pods with only one label.
  - High Level elements used in replication controller yaml file:
    
    apiVersion:
    kind:
    metadata:
    spec:
    replicas:
    selector:
    template:
    
    Replicas: specify the desired number of pods.
    
    Selector (Equality based):
    
    It is like a filter and select specific pod with label name. In the selector area we defind the key: value pair which is the label of pod. The selector field ensures that only pods with the matching labels of pods are managed by the RC. Equality based selector means equal to one value, we can define only one key value like (team: dev),
    
    Whatever values are defined in this section should & must be defined in temlate/labels. in the above we have defined only team: dev
    
    template: Until this section we define properties of replcation controller, here we define what kind of pod configuration. Which image should be use for creation of pods. name of the pod, label's key value details. This key value details should be same as entered in selector area.
  - Go to kubernetes site to get help to write yaml file: https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/
  - To get fields for yaml file
  - $kubectl api-resources or $kubectl api-resources | grep replicationcontroller (it will give list of all resources & objects with api version, short name, kind etc..)
  - $kubectl explain rc (it will give details of specific details of rc)
  - Lab:
  - Create a nginx pod with label team: dev
    
    $kubectl run web-server1 -l team=dev --image=nginx
    
    This will create a pod using nginx image and label will be team=dev
    
    $kubectl get pods -o wide --show-labels
    
    $kubectl describe pod web-server1
  - Creating Replication Controller with Declarative method using YAML file, replicas=3
    
    $vim rc. yaml
    
    vim rc.yaml
    
    $kubectl apply -f rc.yaml
    
    replicationcontroller/star-rc created
    
    $kubectl get pods
    
    $kubectl get rc
    
    $kubectl describe rc star-rc ( to get full details of RC)
    
    Show list of all pods belongs to rc
    
    $kubectl get pods --selector=team=dev
- Commands used in Replication Controller:
  - List Replication Controllers:
    
    $kubectl get rc
  - List of Pods:
    
    $kubectl get pods
    
    star-rc1-948s9 1/1 Running 0 26m
    star-rc1-9ts28 1/1 Running 0 26m
    star-rc1-v9vw9 1/1 Running 0 26m
    
    it creates 3 pods with replication controller name along with some random name
  - To get fields of metadata run
    
    $kubectl explain rc --recursive | less : take the required field for metadata and spec
  - Get Replication Controller Pods:
    
    $kubectl get pods --selector=team=dev
  - Display details of rc
    
    $kubectl describe replicationcontroller/nginx
  - To list all the pods that belong to the ReplicationController
    
    $pods=$(kubectl get pods --selector=app=nginx --output=jsonpath={.items..metadata.name}) echo $pods
  - Update a Replication Controller:
    
    $kubectl replace -f rc.yaml
  - Expose Replication Controller as a Service (Load Balancer):
    
    $kubectl expose rc <rc name> --port=80 --target-port=8080 --type=LoadBalancer
  - Dry Run for Updates:
    
    $kubectl apply -f rc.yaml --dry-run=client
  - Export Replication Controller YAML:
    
    $kubectl get replicationcontroller <rc name> -o yaml > rc_export.yaml
  - Scale a Replication Controller:
    
    $kubectl scale --replicas=5 replicationcontroller <rc name>
  - Pod existing with same lebel:
    
    If pods with same lebel exist, while creating RC, it check the labels and include the existing pod and creating the remaining pods to meet desired value.
    
    $kubectl get pods --show-labels (env=dev)
    
    If you run the above replication controller (rc.yaml) file, it will create two new pods, a pod with labels team=dev is already exist will be included to made desired value =3.
    
    only one label can be use in replication controller.
  - How to check replication is running on pods:
    
    $kubectl describe star-rc-tvj78
    
    Controlled By: ReplicationController/star-rc (check this line)
  - Deleting a ReplicationController and its Pods:
    
    $kubectl delete rc star-rc
    
    $kubectl delete -f rc.yaml
  - Deleting a ReplicationController without affecting pods:
    
    $kubectl delete rc <replication-controller-name> --cascade=orphan
  - Create replicas with command for Replication Controller
    
    $kubectl create deployment web-server --image=nginx --replicas 4
  - Show rc pods with label name
    
    $kubectl get pods --show-labels
    
    $kubectl get rc --show-labels
  - Set Annotations on Replication Controller:
    
    $kubectl annotate replicationcontroller <rc name> key1=value1 key2=value2
  - Change pod's Lebel name
    
    if you want to keep any pod, change its label $kubectl label pod web-server team- (when you change label name a new pod will be created to maintian desired replicas=3 )
    
    give new label $kubectl label pod webserver team=abc
- Rolling Update / POD Verion Upgrade: It is use to update the version of image(nginx) used in pod.
  - 1 Master and 1 worker node in a cluster.
  - Create a node and delete to check if a new pod is creating:
    
    $watch kubectl get pod (open another window and run the following)
    
    $kubectl run web-server --image=nginx (in another window where we ran watch command, shows the progress)
    
    $kubectl get rc
    
    Delete pod to check it recreates: $kubectl delete pod web-server(if it is not recreates means there is no controller is configured) or run the following
    
    kubectl describe pod web-server (if controller is configured than an entry will be there)
  - During rolling update, a new replication controller will be created and a new pod will be created and old one from old replication controller get deleted.
  - once all pods got created in new replication controller then old replication controller get deleted.
  - on top of replication controller there will be service created which receive request and forward it to replication controller.
  - when old replication controller get deleted then its name will be transferred to new replication cotroller during this time there will be a downtime.
  - for any reason if the update got failed then there is no way to go back as old replication controller got deleted.
  - Rolling update is not supported in new kubernetes version, it is supported upto 1.14 version. It can be achieved by installing some plugins.
  - kubernetes version 1.14 supports rolling update of replication controller. for newer version need to install some plugins.
  - Rollout Status of Replication Controller:
    
    $kubectl rollout status replicationcontroller <rc name>
  - Rolling Update of Replication Controller:
    
    $kubectl set image replicationcontroller <rc name> <container name>=<new-image>
    
    $kubectl set image replicationcontroller star-rc nginx=nginx 1.1.9
  - Pause and Resume a Replication Controller:
    
    $kubectl rollout pause replicationcontroller <rc name>
    
    $kubectl rollout resume replicationcontroller <rc name>
  - Rollback to a previous Revision:
    
    $kubctl rollout undo replicationcontroller <rc name>
  - Rollback to a specific Revision:
    
    $kubctl rollout undo replicationcontroller <rc name> --to-revision=<revision number>
  - Rolling update with Imperative Method:
    
    $kubectl set image rc star-rc webserver=nginx:1.22 (defining container name)
- Multiple key value in selector:
  - whatever values we define in selector should & must define in template/labels, otherwise it will give error:
  - error: The ReplicationController "star-rc" is invalid: spec.template.metadata.labels: Invalid value: map[string]string{"team":"dev"}: `selector` does not match template `labels`
  - Enter label:
  - when you run this yaml, it will create 3 new pods as existing pods will not be included which is created earlier has got only team=dev and not environment=testing.
  - You can have more labels in template/labels but whatever is defined in selector must be available in template/labels.
- Scale up/down Rplication Controller:
  - with imperative method
    - $kubectl scale rc star-rc --replicas=5
  - Scale up rc with edit command:
    - $kubectl edit rc star-rc
    - change the value, save & exit
  - Scale up rc with yaml file edit.
    - $vim rc.yaml
    - change the replicas desired value, save & exit
    - $kubectl apply -f rc.yaml
- Delete RC:
  - $kubectl delete rc star-rc
  - $kubectl delete -f rc.yaml

Replica Set:

It manages all pods of nodes of any label, unlike in replication controller manages only one label name.
No Rolling update (update the verison of image used in pod), it is allowed in replication controller.
The number of replicas defined is 3, if there is any existing pod with same label then replica set will take that pod and create the remaining pods (2).
High level elements of Replica Set.
- apiVersion:
  kind:
  metadata:
  spec:
  replicas:
  selector:
  matchLabels:
  template:
- replicas: This is used to specify the desired count of pods.
- selector (label): it is used for identifying pods based on specific labels and make them part of the current replicaset. You can use mulitple lebel values in selector. We have matchLabels and MatchExpression in selector.
  - MatchLabels (equality based selector): Whatever values we enter in selector, same should be enter in labels. In Replica Set you can enter multiple values.
  - MatchExpression: it is a list, (we use key, operator and value)
  - - key: team
    - Operator: In, NotIn, Exists, DoesNotExist
    - Values: either it could be nginx or apache
      - - dev
      - - prod
- template: stores information about what is inside of a pod? like container name, image name, ports etc.

It is a combination of multiple pods with scaling feature.

MatchLabels- rs.yaml

apiVersion: apps/v1

kind: ReplicaSet

metadata:

spec:

replicas: 3

selector:

matchLabels:

team: dev

app: star

template:

metadata:

labels:

team: dev

app: star

spec:

containers:

- name: webserver2

image: nginx

ports:

- containerPort: 80

          MatchExpressions: rs1.yaml

apiVersion: apps/v1

kind: ReplicaSet

metadata:

spec:

replicas: 4

selector:

matchExpressions:

- key: team

operator: In

values:

- dev

- prod

template:

metadata:

labels:

team: dev

spec:

containers:

- name: webserver2

image: nginx

ports:

- containerPort: 80

matchLabels
- Check any pods with label team=dev & app=star exist. It will include in the RS and create the remaining pods to equal the desired state.
- $vim rs.yaml
  - $kubectl apply -f rs.yaml (click for yaml details from kubernetes)
- Run yaml file
  - $kubectl apply -f rs.yaml
  - replicaset.apps/star-rs created
- $kubectl get rs --show-labels
- $kubectl describe rs star-rs
matchExpressions: (set based)
- Check any pods with team where value = dev or prod and create rs with 4 replicas.
- $kubectl apply -f rs1.yaml
- $kubectl get rs star-rs1 -o wide

matchExpressions Example:
- Yaml for the above labels and selectors

Scale up/down Rplica Set:
- with imperative method
  - $kubectl scale rs star-rs --replicas=5
- Scale up rs with edit command:
  - $kubectl edit rs star-rs
  - change the value, save & exit
- Scale up rs with yaml file edit.
  - $vim rs.yaml
  - change the replicas desired value, save & exit
  - $kubectl apply -f rs.yaml
Delete RS:
- $kubectl delete rs star-rs
- $kubectl delete -f rs.yaml
No Rolling Update in Replica Set:
Commands:
- Create and yaml file and paste the code
  - $vim rs.yaml
- Creation of Replica set through yaml file.
  - $kubectl apply -f rs.yaml
- List Replica Set and get detail information
  - $kubectl get rs
  - $kubectl describe rs star-rs
- List of Pods:
  - $kubectl get pods
- Remove labels
  - $kubectl label pod nginx-7c8sk team- (it remove label team for the pod nginx-7c8sk), it will remove label but will create another pod to keep desired value = 4
  - $kubectl label pod dev team=dev (it will label team=dev to pod dev)
- Delete Replicaset:
  - $kubectl delete -f rs.yaml
  - $kubectl delete rs star-rs
- Do not delete any one pod from replica set
  - change the label name to any name and when you delete rs it will not delete that pod because label name is not mentioned in rs.yaml
  - $kubectl label pod dev team=abc
  - $kubectl delete -f rs.yaml (dev pod with label team=abc will not be deleted and rs will be deleted along with pods whose label names are dev & prod)

Deployment & Deployment strategies:

Deployment:

It manages all pods of nodes of any label.
Rolling update is possible and there will be no downtime.
Deployment will be created on top of replica set.
When you run rolling update, a new replica set will be created and a new pod with defined version will be created and old one get deleted. now deployment has two replica set and it will forward traffic to both replica sets.
Once all pods created and old pods get delted,it will keep old replica set which can be use for undo in case of update gives errors.
The number of replicas defined in yaml file (3), if there is any existing pod with same label then replication will take that pod and create the remaining pods (2).
Replicaset uses elements like replicas, selector, template.
- replicas: This is used to specify the desired count of replicas.
- selector: it is used for identifying pods based on specific labels and make them part of the current replicaset.
- template: stores information about what is inside of a pod? like container name, image name, ports etc.
It is a combination of multiple pods with scaling feature.

Create Deployment:

apiVersion: apps/v1

kind: Deployment

metadata:

labels:

app: webserver

spec:

replicas: 4

selector:

matchLabels:

app: webserver

template:

metadata:

labels:

app: webserver

spec:

containers:

- name: nginxpod

image: nginx

ports:

- containerPort: 80

ReplicaSet with 3 replicas is created, labels team=prod has been used. you an define multiple labels using matchExpressions, if any pod is deleted then it will be created automatically to maintain desired value.

operator = In or NotIn can be used to included or exclude labels. if both define then NotIn will take precedence.

Go to kubernetes/deployment.

Creating Pods with deployment using Imperative method.
- Creating nginx pods with Replication Controller with Imperative method:
  - $kubectl create deployment $deploymentname --image $image --replicas $replicacount
Creating Pods with deployment using declarative method.
- $vim deployment.yaml
- $kubectl apply -f deployment.yaml
- $kubectl get deployment (shows list of deployment)
Expose the port to access from outside:
- Next let's go ahead and expose the pods to outside network requests so we can call the nginx server that is inside the containers:
- $kubectl expose deployment star-deployment --port=30001 --target-port=80 --type=NodePort
- service/star-deployment exposed:
- $kubectl get svc
- $kubectl describe deployment star-deployment
- Access the application with port number:
- http://[HOST_NAME OR HOST_IP]:[PROVIDED PORT]
- http://192.168.171.101:30001

Scaling: scale up/down of pods through yaml file:
- Go to deployment.yaml file and change replicas = desired number and run $kubectl apply -f deployment.yaml
Rolling Update/Roll out:
- $kubectl describe deployment/star-deployment (check details of deployment, version of image etc)
- $kubectl rollout status deployment/star-deployment (deployment "star-deployment" successfully rolled out)
- $kubectl rollout history deployment/star-deployment (it will show history of rollout, REVISION 1 & CHANGE-CAUSE <none>)
  - deployment.apps/star-deployment
    REVISION CHANGE-CAUSE
    1 <none>
  - REVISION: it shows the revision number of rollout, it is the first rollout or first time deployment has been configured.
  - CHANGE-CAUSE: it shows message is recorded while deployment.
- set CHANGE-CAUSE:
  - $kubectl apply -f deployment.yaml --record=true (sytem will add command used to deploy in change-cause instead of <none>)
  - $kubectl rollout history deployment/star-deployment
  - Make changes and run deployment again to check version:
    - A new replica set will be created and new pods will be created and old pods get deleted one by one, once all pods get created and attached with new replica set, traffic will sent using the new replica set. deployment will have two replica sets.
    - Method 1: edit the yaml file and change image: nginx:1.25 to nginx:1.26 and run the yaml file
      
      $kubectl apply -f deployment.yaml --record=true
      
      $kubectl get deployments (it shows no change)
      
      $kubectl get rs (there will be two replica set, previous version of rs and new version rs )
      
      $kubectl rollout history deployment/deployment
      
      $kubectl describe deployment/deployment (check OldReplicaSets and NewReplicaSet details)
    - Method2: define in command
      
      $kubectl set image deployment.apps/deployment nginx=nginx:1.26
      
      $kubectl get deployment, rs, pod
    - Method3: edit the deployment
      
      $kubectl edit deployment.apps/deployment (scroll down, find spec: containers - image and edit image version) save it
  - Errors: If you mention wrong image number then it will remain with the last image, it tries with first pod and when got error then it will remain with the current image version and will not change remaining pods.
Rollback to previous version of Deployment:
- when you run history command $kubectl rollout history deployment.apps/deployment, where you can view all previous rolluts version numbers, to go back to previous version run
  - $kubectl rollout history deployment.apps/deployment --revision=1 (check details of revision 1, 2, 3 .....), select to which revision go back to
  - $kubectl rollout undo deployment.apps/deployment (if you do not mention revision then it goes back to previous number)
  - $kubectl rollout undo deployment.apps/deployment --to-revision=1 (it will go back to revision 1)
Pause Rollout Deployment:
- rollout will not execute until it resume
  - $kubectl rollout pause deployment.apps/deployment
  - $kubectl rollout resume deployment.apps/deployment (once it is resumed it will start rollout)
Delete deployment:
- $kubectl delete deployment/deployment (all pods, rs and deployment get deleted)
Commands:
- $kubectl explain deployment --recursive | less (to get details of deployment)
  - $kubectl get deployment : list deployment configured
  - $kubectl get deployment,rs,pod : list deployment, replicationset, pods, it will show first deployment, than replica set then list of pods.
  - $kubectl apply -f deployment.yaml --record=true
  - root@master:~# kubectl get deployment,rs,pod
    NAME READY UP-TO-DATE AVAILABLE AGE # deployment
    deployment.apps/replication-deployment 3/3 3 3 3m30s # deployment name = replication-deployment
    
    NAME DESIRED CURRENT READY AGE # replica set
    replicaset.apps/replication-deployment-d556bf558 3 3 3 3m30s # replica set name= deployment+replicaset number
    
    NAME READY STATUS RESTARTS AGE # list of pods
    pod/replication-deployment-d556bf558-gffs7 1/1 Running 0 3m30s # pod name = deployment+rs+pod name
    pod/replication-deployment-d556bf558-kqwh7 1/1 Running 0 3m30s
    pod/replication-deployment-d556bf558-mx8h8 1/1 Running 0 3m30s
  - $kubectl describe deployment/deployment name
  - $kubectl rollout history deployment/deployment
  - $kubectl rollout history deployment/deployment --revision=2 (check details for a particular revision)

Deployment Strategies: Rolling deployment, recreate, canary/blue&green deployment

Three ways you can define strategy to deploy kubernetes deployment.

Rolling Deployment:

When you perform rolling upate/roll out to a new version then a new replica set get created and once a pod with newer version created than it start deleted the old pod. If the pods are in high number than it will take longer time. You can define strategy that instead of creating one pod at a time creates number of pods. The strategies can be define in rolling updates are:

Max Surge: value = 2 (preferred), you can enter value or percentage.
- Max Unavaibale: value = nil
- In the above strategy first new 2 pods will be created and than it will delete old 2 pods.
- Max Surge: value =
- Max Unavaibale: value = 2
- In the above strategy first new 2 pods will be deleted and than it creates 2 new pods in new replica set. The pods status will be unavailable. it is prefered to use value in max surge and no value in max unavilable.
As soon as a new pod is started to create then it will start remove from old replica. pod is creating and terminating which leaves number of pods in running status are less. once all pods are created and deleted then old replica set will not be active and not be deleted. It is used by default.
if there number of pods which may take longer time to finish. to minimise time there are two ways can be performed
define strategy in yaml file to make sure the new pod first completely created then start removing old pods.
deployment.yaml

Replication Deployment, nginx 1.14

apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
labels:
app: webserver
spec:
replicas: 4
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: nginxpod
image: nginx:1.14
ports:

Rolling update with rolling deployment,nginx 1.22

apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
labels:
app: webserver
spec:
replicas: 4
strategy:
rollingUpdate:
maxSurge: 0
maxUnavailable: 3
type: RollingUpdate
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: nginxpod
image: nginx:1.22
ports:

Step 1: Deploy replication with nginx1.14
$kubectl explain deployment --recursive | less (to get details of deployment)
$kubectl apply -f deployment.yaml --record=true
Current deployment with nginx version 1.14 is running in the cluster.
Step 2: Rolling update with rolling deployment and upgrade nginx to 1.22
edit the deployment.yaml file and insert rolling deployment code.
$kubectl apply -f deployment.yaml --record=true
we run rolling deployment where nginx update to 1.22, it will delete 3 pods first and than will create 3 new pods of version 1.22 as max unavailbale:3 is defined and there is no max surge.
$kubectl rollout history deployment/deployment
if we enter maxSuge:1 and maxUnavailable:0 then all pods will be available and a new pod with new version will be created and one old pod get deleted.

Recreate Deployment:

When you execute roll out than no new replica set will be created. It deletes existing pod and create new pod with new version. This method is fast but not reliable and there will be downtime.

$kubectl explain deployment --recursive | less (to get details of deployment)
deployment.yaml

Create deployment with nginx 1.14

apiVersion: apps/v1
kind: Deployment
metadata:
name: deployment
labels:
app: webserver
spec:
replicas: 4
strategy:
type: Recreate
selector:
matchLabels:
app: webserver
template:
metadata:
labels:
app: webserver
spec:
containers:
- name: nginxpod
image: nginx:1.14
ports:
- containerPort: 80

Rolling update with recreate deployment to nginx1.22

$kubectl explain deployment --recursive | less (to get details of deployment)
$kubectl apply -f deployment.yaml --record=true
It will deploy 4 pods with nginx 1.14
Perform rolling update with recreate method: enter code for recreate and run
$kubectl apply -f deployment.yaml --record=true
It will remove all pods with older version and create a new replica set with new pods of newer version.

Canary or Blue&Green or Red&Black Deployment:
- - In this method you create two deployments, one is used as Blue and another one as green.
  - You will attach ingress controller on top of both deployment.
  - You will attach a DNS server on top of ingress controller. it will point to internet.
  - Ingress controll will communicate with services on both deployment.
  - We configure ingress controller that it sends traffic to green deployment, once we perform roll out on blue deployement than we configure ingress controller to send traffic to blue deployment.
  - LAB:

Service: ClusterIP, NodePort, External Name, Load Balancer
- To access Pods within a cluster than it can be access with its private IP address assigned from cluster pool. To access from outside cluster either enable port forwarding or assing public IP address using LB, Ingress Controller service.
- If you have pods for web, database which can integrate with private IP address, if a pod get deleted and recreate it with replication configured than manually we need to assign new IP address for integration.
- To overcome with the change of IP address in pods we can use service, which is applied on top of replica set, a separate IP will be assigned to service which can be use for all communiction.
- Service will map the ips of pods. Users will use service IP address to access applications on pods.
- A Service in Kubernetes is an abstraction that defines a logical set of pods and a policy by which to access them. It enables network access to a set of pods. You cannot have two services at the same time.
- There are three types of kubernetes service:
  - ClusterIP (Private IP communication between pods within a cluster):
    
    A private IP assigned to service-ClusterIP from the cluster pool which is use to access between pods through service. If pods recreated than a new IP will be assign to POD which will affect the communication as it used ClustIP.
    
    All Internal communication within a cluster is done with this clusterIP instead of pod IP.
    
    Applications are deployed on pods which can also be access directly using PODS IP but when pod gets deleted a new IP will be assing to Pods and required manually change the IP.
    
    In this method user's from outside cannot access application due to private IP has been assigned. To access from outside a service NodePort or load balancer or Ingress controller etc can be use.
    
    Lab2: Create pods for web and Database, Create Cluster IP service, login to web pod and access database with service-Cluster IP.
    
    db_deployment:
    
    $vim db_deployment.yaml
    
    apiVersion: apps/v1
    
    kind: Deployment
    
    metadata:
    
    name: db-server
    
    labels:
    
    team: dev
    
    spec:
    
    replicas: 1
    
    selector:
    
    matchLabels:
    
    team: dev
    
    template:
    
    metadata:
    
    labels:
    
    team: dev
    
    spec:
    
    containers:
    
    - name: mysql
    
    image: mysql:latest
    
    ports:
    
    - containerPort: 3306
    
    env:
    
    - name: MYSQL_ROOT_PASSWORD
    
    value: Trustu786
    
    - name: MYSQL_DATABASE
    
    value: stardatabase
    
    $kubectl apply -f db_deployment.yaml
    
    $kubectl describe deployment/db-server
    
    Get into db-server deployment pod and access to web-server deployment pod
    
    $kubectl exec -it db-server-658899c4cb-vmmv6 -- /bin/bash
    
    curl the web_deployment
    
    $curl 172.16.235.168 (if curl is not installed, install $apt-get update, $apt-get install curl) , html code displayed.
    
    change directory to /usr/share/nginx/html
    
    Create with Impertive method:
    
    $kubectl run --image mysql:5 db-server --env MYSQL_ROOT_PASSWORD=India123
    
    Create Service ClusterIP for db:
    
    create service and access the db_deployment with service IP:
    
    Service can be created with command line or yaml
    
    with Command:
    
    $kubectl expose deployment db-server --type=ClusterIP --port 80 --target-port=80 (Pod's front end port 80,backend port 80)
    
    service/db-server exposed, check service is created
    
    $kubectl get all -owide (service has been created and IP assigned 10.107.108.132)
    
    with yaml file db_service.yaml
    
    apiVersion: v1
    
    kind: Service
    
    metadata:
    
    name: db-clusterip
    
    spec:
    
    type: ClusterIP
    
    selector:
    
    team: dev
    
    ports:
    
    - protocol: TCP
    
    port: 3306
    
    targetPort: 3306
    
    $kubectl apply -f db_service.yaml
    
    $kubectl get svc
    
    db-clusterip ClusterIP 10.96.128.249 <none> 3306/TCP 7m45s
    
    From Web-deployment pod access db-deployment using service IP.
    
    $curl 10.107.108.132 (accessed, html code displayed)
    
    $kubectl describe service db-server
    
    Target pod/db_deployment POD IP = 10.107.108.131
    
    service_clusterIP IP = 10.107.108.132
    
    if you delete the pod then a new pod will be created with a new IP (10.107.108.135) but you can still access db_deployment POD with service IP 10.107.108.132
    
    Edit db_deployment.yaml file and make replica=4 and run the yaml file.
    
    4 pods has been created with 4 IPS with port 80 only, when you access the db_deployment pods you use service IP 10.107.108.132 and it will redirect to any pod of 4.
    
    apache_deployment:
    
    $vim apache_deployment.yaml
    
    apiVersion: apps/v1
    
    kind: Deployment
    
    metadata:
    
    name: apache-server
    
    labels:
    
    team: dev
    
    spec:
    
    replicas: 3
    
    selector:
    
    matchLabels:
    
    team: dev
    
    template:
    
    metadata:
    
    labels:
    
    team: dev
    
    spec:
    
    containers:
    
    - name: httpd
    
    image: httpd:latest
    
    ports:
    
    - containerPort: 80
    
    env:
    
    - name: MYSQL_HOST
    
    value: db-service
    
    - name: MYSQL_USER
    
    value: root
    
    - name: MYSQL_PASSWORD
    
    value: Trustu786
    
    - name: MYSQL_DATABASE
    
    value: stardatabase
    
    $kubectl apply -f apache_deployment.yaml
    
    Create Service - ClusterIP for apache.
    
    $vim apache_service.yaml
    
    apiVersion: v1
    
    kind: Service
    
    metadata:
    
    name: apache-service
    
    spec:
    
    type: ClusterIP
    
    selector:
    
    team: dev
    
    ports:
    
    - protocol: TCP
    
    port: 80
    
    targetPort: 80
    
    $kubectl apply -f apache_service.yaml
    
    $kubectl get svc
    
    $kubectl get pods
    
    clusterIP1.jpg
    
    Get into one of the apache pod
    
    $kubectl exec -it apache-server-5fd845754c-2bg4m -- /bin/bash
    
    root@apache-server-5fd845754c-2bg4m:/usr/local/apache2#
    
    Database details: $env | grep MYSQL
    
    root@apache-server-5fd845754c-2bg4m:/usr/local/apache2# mysql -h db-server -u root -p
    
    bash: mysql: command not found
    
    Install msql:
    
    root@apache-server-5fd845754c-2bg4m:/usr/local/apache2#apt-get update
    
    root@apache-server-5fd845754c-2bg4m:/usr/local/apache2#apt-get install default-mysql-client
    
    root@apache-server-5fd845754c-2bg4m:/usr/local/apache2# mysql -h db-service -u root -p
    
    Error: ERROR 2026 (HY000): TLS/SSL error: self-signed certificate in certificate chain
    
    root@apache-server-5fd845754c-2bg4m:/usr/local/apache2# mysql -h db-service -u root -p --skip-ssl
    
    MySQL [(none)]> show databases;
    
    This is the internal connectivity between the pods with the help of cluster IP
    
    $vim web_deployment.yaml
    
    $kubectl apply -f web_deployment.yaml
    
    $kubectl describe deployment/web-server
    
    get into web_deployment pod:
    
    $kubectl exec -it web-server-57567b9bb5-tm62n -- /bin/bash
    
    curl the db_deployment
    
    $curl 172.16.235.129 (if curl is not installed, install $apt-get update, $apt-get install curl) , html code displayed.
    
    we access the db_deployment with pod IP, in case pod get deleted then a new pod will be created with a new IP (172.16.235.131). (to test delete the db pod)
    
    Create Service ClusterIP:
    
    create service and access the web_deployment with service IP:
    
    in the above service in db service was created with command line, here it will be created with yaml file. Go to google: kubernetes service create, syntax for creating service with yaml
    
    $vim websvc.yaml (paste the syntax and make necessary change)
    
    $kubectl apply -f websvc.yaml (service is created)
    
    web_deployment pod can be accessed with service IP 10.102.145.37
    
    Edit web_deployment.yaml and make replicas = 4, run web_deployment.yaml and check details.
    
    $kubectl describe service web-service
    
    From master node curl both service IP's of web & db deployment.
    
    Delete Service ClusterIP & Deployment:
    
    $kubectl delete service apache-service
    
    $kubectl delete service web-service
    
    $kubectl delete service db-deployment
    
    $kubectl delete service web-deployment
    
    Default ClusterIP service:
    
    When you configure the cluster, control plane components (api server, etcd, controller manager, Sceduler) and worker nodes (kube proxy, kubectl, Runtime Engine) created , which communicate with each other using this kubernetes ClusterIP.
    
    $kubectl get service
    
    if you delete this ClusterIP service, it will recreate it.
    
    $kubectl describe service kubernetes.
    
    There is only one Endpoint IP, when cluster is configured with kubeadm where all components runs on pods using same master node IP.
    
    It is master node IP. All pods use master node IP.
    
    $kubectl -n kube-system get pods -o wide (all components using same ip)
  - Node Port: (Access the pods from outside the netowrk using port number)
    
    Explanation
    
    Create frontend/backend deployment and frontend/backend service using Imperative method:
    
    Create frontend Deployment:
    
    $kubectl create deployment -h (it will list all options & arguments)
    
    Run the above with dry run: it will check the syntax and schema is correct, it will not create the deployment.
    
    kubectl create deployment backend-deploy \
    --image=hashicorp/http-echo \
    --replicas=3 \
    --port=5678 \
    --dry-run=client
    
    deployment.apps/backend-deploy created (dry run), it does not create deployment but gives output of command.
    
    Run with dry run server: it will send request to api server and check the syntax and format is correct.
    
    kubectl create deployment backend-deploy \
    --image=hashicorp/http-echo \
    --replicas=3 \
    --port=5678 \
    --dry-run=server
    
    deployment.apps/backend-deploy1 created (server dry run)
    
    Create the backend deployment:
    
    $kubectl create deployment backend-deploy \
    --image=hashicorp/http-echo \
    --replicas=3 \
    --port=5678 \
    
    To view the above imperative command in yaml file: run
    
    $kubectl create deployment backend-deploy \
    --image=hashicorp/http-echo \
    --replicas=3 \
    --port=5678 \ -o yaml > backend-deployment1.yaml
    
    check $vim backend-deployment1.yaml (it uses some additional arguments)
    
    Create ClusterIP (backend-svc ): Expose the above deployment
    
    $ kubectl expose service -h (it will list all options & arguments)
    
    Create the Service:
    
    $kubectl expose deployment backend-deploy \
    --type=ClusterIP \
    --port=9090 \
    --target-port=5678 \
    --name=backend-svc \
    
    Create frontend-deployment:
    
    $kubectl create deployment frontend-deploy \
    --image=nginx \
    --replicas=3 \
    --port=80 \
    
    Create NodePort (frontend-svc): Expose the above deployment
    
    kubectl expose deployment frontend-deploy \
    --type=NodePort \
    --port=80 \
    --target-port=80 \
    --nodePort: 30001
    --name=frontend-svc \
    
    Code
    
    Create frontend/backend deployment and frontend/backend service using Declerative method using YAML:
    
    frontend-deployment.yaml
    
    $kubectl apply -f frontend-deployment.yaml
    
    frontend-svc.yaml
    
    $kubectl apply -f frontend-svc.yaml
    
    backend-deployment.yaml
    
    $kubectl apply -f backend-deployment.yaml
    
    backend-svc.yaml
    
    $kubectl apply -f backend-svc.yaml
    
    Code
    
    nodeport.jpg
    
    Explanation:
    
    To access the application from internet, use nodeport where a port & public IP will bind with service (nodeport). In this service clusterIP is also assgined.
    
    Port is assigned to cluster IP. To access the application on pods user must add port to cluster IP. To avoid these use load balancer.
    
    Lab:
    
    web_deployment
    
    $vim web_deloyment (for testing nginix image used)
    
    $kubectl apply -f web_deployment.yaml
    
    db_deployment
    
    $vim db_deployment.yaml
    
    $kubectl apply -f db_deployment.yaml
    
    Create service nodeport
    
    $kubectl expose deployment web-server --type=NodePort --name=star-nodeport
    
    NodePort service is created with port 30091 (this port will expose to every node), cluster IP = 10.96.0.1 and front end port 80
    
    $kubectl describe service web-server
    
    To test: open browser and enter 192.168.171.50:30091 or 192.168.171.51:30091 (Master_node IP/worker_nod IP: 30091), two pods has been created on worker1 (172.16.235.150, 172.16.235.152) and traffic send to these pods using round robin method. every time need to define port along with IP in nodeport, to avoid this use load balancer.
    
    To test traffic forwarding to pods follow these.
    
    $kubectl exec -it web-server-57567b9bb5-hl59l -- /bin/bash (Enter into the pod 172.16.235.150)
    
    $cd /usr/share/nginx/html and $vim index.html (pod1) save it ($apt-get update $apt-get install vim)
    
    $kubectl exec -it web-server-57567b9bb5- -- /bin/bash (Enter into the pod 172.16.235.152)
    
    $cd /usr/share/nginx/html and $vim index.html (pod2) save it ($apt-get update $apt-get install vim)
    
    Now access in browser and see on which POD query send to. it uses round robin method to send traffic.
    
    Open browser 192.168.171.200:30091 or 192.168.171.201:30091 (from master and worker nodes), every time need to assign port number, to avoid use load balancer.
  - Load Balancer (MetalLB): Access the pods from outside using internet
    
    Bind the loadbalancer IP with clusternode IP along with port number. This load balancer was used by client not from kubernetes.
    
    Kubernetes has provided loadbalancer (metalLB). service type use load balancer.
    
    For every deployment you will need a separate load balancer. If you have large number of deployments then large number of load balancers required, to overcome this ingress controller can be use.
    
    Lab:
    
    web_deployment
    
    $vim web_deloyment (for testing nginix image used)
    
    $kubectl apply -f web_deployment.yaml
    
    db_deployment
    
    $vim db_deployment.yaml
    
    $kubectl apply -f eb_deployment.yaml
    
    Create service Load Balancer
    
    $kubectl expose deployment db-server --type=LoadBalancer --name=star-loadbalncerdb
    
    $kubectl describe service db-server
    
    $kubectl expose deployment web-server --type=LoadBalancer --name=star-loadbalancerweb (separate load balancer for every deployment, to overcome use ingress controller service.)
    
    service: LoadBalancer has been created but EXTERNAL_IP is pending because there is no load balancer is configured as VM are used.
    
    MetalLB Configuration:
    
    To setup load balancer from kubernetes (metalLB): If you use cloud kubernetes like gke, aks, etc no need to configure load balancer separately as they provide LB service.
    
    Go to google and search metallb loadbalancere: click here
    
    kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml
    
    click on configuration of metallb site and copy code (change ip pool)
    
    apiVersion: metallb.io/v1beta1
    kind: IPAddressPool
    metadata:
    name: first-pool
    namespace: metallb-system
    spec:
    addresses:
    - 192.168.173.100-192.168.173.200
    
    $vim metallb.yaml (paste the above code)
    
    $kubectl apply -f metallb.yaml (now it will assign public IP to Load Balancer
    
    open browser and access with load balancer IP. (192.168.171.100), check within the VM of vmware.
    
    $kubectl -n metallb-system get pod
PODs Limit
- In any master/worker nodes you can create 110 pods by default which can be scaleup/down.
  - $kubectl describe node nodename
  - In Allocatable pods : 110
  - Increase POD limit:
    - cd /var/lib/kubelet/ and edit file config.yaml (if you do not find maxPods than add entry maxPods: 123)
    - Find where is config.yaml file $systemctl status kubelet (--confi=/var/lib/kubelet/config.yaml)
    - check parameter maxPods: enter desired number (save and exit)
    - $systemctl restart kubelet
- Code

Labels and assign memory limit

$vim 1.yaml (two servers are deploying webserver1 & webserver2 in a pod web-server1)
- $vim 2.yml (//server deployed in a pod with memory limit) (https://kubernetes.io/docs/tasks/configure-pod-container/assign-memory-resource/)

//1.yaml

apiVersion: v1
kind: Pod
metadata:
name: web-server1
spec:
containers:
- name: webserver1
image: tomcat
- name: webserver2
image: nginx

//2.yaml

apiVersion: v1
kind: Pod
metadata:
name: memory-demo

spec:
containers:
- name: webserver1
image: nginx
resources:
requests:
memory: "100Mi"
limits:
memory: "200Mi"

it is key value paire, where keys are predefined but under labels you can define your own keys and values.
- $kubectl create -f web-server1.yml or $kubectl apply -f web-server1.yml
- $kubectl get pods
- $kubectl describe pod web-server1
- $kubectl delete -f web-server1.yml
check memory limit:
- $kubectl top pod memory-demo --namespace=default
Error: Metrics API not available
- Solution: If you use one master node, run this command to create the metrics-server:
- $kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
- If you have high availability then run
- $kubectl apply -f https://raw.githubusercontent.com/pythianarora/total-practice/master/sample-kubernetes-code/metrics-server.yaml

Create pods with memory limit

$sudo vi memory_limit2.yaml

apiVersion: v1
kind: Pod
metadata:
name: memory-demo
labels:
author: aziz
spec:
containers:
- name: webserver1
image: nginx
resources:
requests:
memory: "100Mi"
limits:
memory: "100Mi"
- name: webserver2
image: tomcat
resources:
requests:
memory: "100Mi"
limits:
memory: "200Mi"

$kubectl create -f memory_limit2.yml
- $kubectl get pods
- $kubectl get pods memory_limit2 --show-labels (it will show label of pods as well)
apiVersion,kind, metadata & spec in same line.
In metadata: name & labels in same line while author with one space
In spec: -name, image,resources in same position, requests & limites in same position and memory in same position.

Namespce

In Kubernetes, namespaces provide a mechanism for isolating groups of resources within a single cluster.
Pods are the most fundamental resources you can use inside your Kubernetes cluster for your workloads. They are namespaced, meaning they are always created inside a Kubernetes namespace.
A namespace in Kubernetes is a logical partition within a cluster that helps organize and isolate resources. Namespaces enable:
- Isolation & Security: Separate workloads to prevent unwanted interactions.
- Avoiding Naming Conflicts: Resources with the same name can exist in different namespaces.
- Resource Management: Apply resource quotas and limits at the namespace level.
- Application Segregation: Separate environments (e.g., dev, test, prod) or projects.
- Organizational Clarity: Manage resources by teams, departments, or projects.
Analogy to Understand Namespaces:
- Imagine a large house where four families live together:
- Without namespaces, all families share common spaces, leading to no privacy, security, or organization.
- When you create rooms for each family, each family has its own space, improving isolation, security, and organization.
- Relating to Kubernetes:
- The large house is the Kubernetes cluster.
- The families are applications or workloads.
- Rooms are namespaces, providing segregation and control over resources.

Default Namespaces in Kubernetes:

When you run $kubectl get namespaces, you’ll see these default namespaces:

Namespace	Purpose
default	Kubernetes includes this namespace so that you can start using your new cluster without first creating a namespace.
kube-system	The namespace for objects created by the Kubernetes system. Holds Kubernetes control plane components (e.g., kube-dns, kube-proxy).
kube-public	This namespace is readable by all clients (including those not authenticated). Publicly accessible data, primarily used for cluster information.
kube-node-lease	Heartbeats of nodes in the cluster, used by the control plane for node health.

Creating a namespace
- Imperative method:
  - $kubectl create namespace star-ns
- Declarative method:
  - # star-ns.yaml
    
    apiVersion: v1
    
    kind: Namespace
    
    metadata:
    
    name: star-ns
  - $kubectl apply -f star-ns.yaml
$kubectl get pods -n star-ns
$kubectl get services -A (list of all services in cluster)
code

Manual Scheduling, pods on control plane, and Static PODS
- Before we dive into Manual scheduling and Static pods, it's essential to recall how the Kubernetes scheduler works.
- scheduler1.jpg
- The Kubernetes Scheduler is responsible for automatically placing pods on available worker nodes based on factors like:
  - Resource availability (CPU, memory).
  - Taints and tolerations (node & pods restrictions)
  - Affinity and anti-affinity rules
- Manual Scheduling:
  - Manual scheduling means scheduling a pod to a particular node using the nodeName field in the pod’s YAML manifest. This completely bypasses the Kubernetes scheduler.
  - However, can we bypass the scheduler and manually assign pods to nodes? Yes! This is where manual scheduling comes in.
  - Why manual scheduling of pods needed?
    - Troubleshooting & Debugging: Helps diagnose scheduling issues by placing a pod on a specific node.
    - Testing Node-Specific Workloads: Ensures an application runs on a specific node (e.g., a database pod requiring an SSD).
    - Kubernetes Scheduler Is Disabled: If the scheduler is down, you can manually schedule pods as a fallback.
    - Guarantees that a pod runs on a particular node.
    - Useful when a workload requires special hardware or node-specific configurations.
    - Helps troubleshoot why a pod isn't scheduled automatically.
  - Lab: Creating a Pod on a particular node:
    - $kubectl get nodes
    - Cluster consist of one control palne and two worker nodes (worker & worker2)
    - pod_specific_node.yaml
    - apiVersion: v1
      
      kind: Pod
      
      metadata:
      
      name: nginx-manual-pod
      
      spec:
      
      nodeName: kind-worker2 # Assign pod to a specific worker2 node
      
      containers:
      
      - name: nginx
      
      image: nginx
    - $kubectl apply -f pod_specific_node.yaml
    - $kubectl get pods -o wide (pod is created on node kind-worker2)
    - KIND allows scheduling on the control plane because it has no default taints.
- Pods creating on conrol plane (master node):
  - By default, workloads are placed on worker nodes. However, you can manually schedule a pod on the control-plane node.
  - We know that the scheduler is bypassed when performing manual scheduling. control-plane node has a taint that prevents creating pods with scheduler unless unless they have a matching toleration defined otherwise manually assign a pod to the control-plane node.
  - apiVersion: v1
    
    kind: Pod
    
    metadata:
    
    name: nginx-manual-pod
    
    spec:
    
    nodeName: kind-control-plane # Create pod on control plane node
    
    containers:
    
    - name: nginx
    
    image: nginx
- Static Pods:
  - Why do we need?
  - Essential for Control Plane Components: kube-apiserver, etcd, and scheduler run as static pods.
  - Static pods are created and managed by the Kubelet on a node, not by the Kubernetes API server/scheduler.
  - Static pods are defined in /etc/kubernetes/manifests/
  - Unlike regular pods, static pods are not managed by the Kubernetes API server, meaning you cannot modify them using kubectl commands. Instead, they are directly managed by the kubelet on each node, and any changes require modifying or deleting the static pod manifest file on the node itself.
  - Static pods can be defined on any node, including both control plane and worker nodes. However, they are not scheduled by the Kubernetes Scheduler—instead, they are directly managed by the kubelet running on the node where their manifest exists.
  - When a static pod is created, the kubelet automatically generates a corresponding "mirror pod" on the Kubernetes API server. These mirror pods allow static pods to be visible when running kubectl get pods, but they cannot be controlled or managed through the API server.
  - How Mirror pod works:
    - The Kubelet detects static pod manifests from /etc/kubernetes/manifests/.
    - It creates and manages the static pod independently from the Kubernetes control plane.
    - To ensure visibility in kubectl get pods, Kubelet creates a "mirror pod" on the API server.
    - However, this mirror pod is read-only—it cannot be modified, deleted, or controlled using kubectl.
  - The name of the mirror pod follows this pattern: <static-pod-name>-<node-hostname>(nginx-static-pod-kind-worker2)
  - Lab: Creating a static Pod in control plane node:
    - Accessing Static Pods in Production vs. KIND, How to Access Static Pod Manifests in Production Clusters.
    - In a production Kubernetes cluster, nodes are typically virtual machines (VMs) or physical servers running on cloud providers (AWS, GCP, Azure) or on-premises infrastructure.
    - Since these are actual machines, you would SSH into the node to access the static pod manifests.
      The static pod manifests are stored in the directory:
      /etc/kubernetes/manifests/
      To view or edit a static pod manifest in a production cluster:
      ssh user@worker-node-ip
      sudo vi /etc/kubernetes/manifests/static-pod.yaml
    - In KinD cluster, docker creates containers for control plane and nodes, first get into control plane node and go to /etc/kubernetes/manifests/
    - $docker ps
    - static_pod1.jpg
    - $docker exec -it kind-control-plane bash (in docker we use bash while in kubernetes we define -- /bin/bash)
    - static_pod2.jpg
    - As we are in control plane container, we do not have kubectl installed, create the pod with command and store it in static-pod.yaml
    - cat <<EOF > /etc/kubernetes/manifests/static-pod.yaml
      apiVersion: v1
      kind: Pod
      metadata:
      name: nginx-static-pod
      spec:
      containers:
      - name: nginx-container
      image: nginx
      ports:
      - containerPort: 80
      EOF
    - It will create a static pod and store the above command in static-pod.yaml file.
    - Verify that pod is running.
    - open another window and run $kubectl get pods
    - static_pod3.jpg
    - kubelet pick up the yaml manifest file (static-pod.yaml) and created the pod.
  - Lab: Creating a static pod in worker nodes:
    - $docker exec -it kind-worker bash
    - cat <<EOF > /etc/kubernetes/manifests/static-pod1.yaml
      apiVersion: v1
      kind: Pod
      metadata:
      name: nginx-static-pod1
      spec:
      containers:
      - name: nginx-container1
      image: nginx
      ports:
      - containerPort: 80
      EOF
  - Delete static pod:
    - When you delete static pod $kubectl delete pod nginx-static-pod-kind-control-plane, it gets recreated althrough there is no replicas is mentioned.
    - Why Does kubectl delete Not Permanently Remove Static Pods?
      
      kubectl delete pods nginx-static-pod-my-second-cluster-control-plane
      
      This deletes the pod, but it will be recreated!
      
      Since static pods are managed directly by the kubelet, it detects their absence and automatically recreates them if their YAML files still exist.
      
      To permanently remove a static pod, delete its manifest file:
      
      $rm /etc/kubernetes/manifests/static-pod.yaml
      
      Once the YAML file is removed, the kubelet stops recreating the pod.

Taints & Tolerance

In Kubernetes, Taints and Tolerations help control which pods can be scheduled on which nodes. They allow cluster administrators to prevent certain workloads from running on specific nodes while allowing exceptions when necessary.
Taints and tolerations only apply during scheduling. If a pod is already running on a node, adding a taint will not remove the existing pod (unless you use the NoExecute effect).
Taint: Taints are applied to nodes
A Taint is applied to a node to indicate that it should not create certain pods unless they explicitly tolerate it.
use cases:
- Dedicated Nodes:
- Isolating Critical Nodes:
- Preventing Scheduling on Control Plane Nodes
- Maintenance Mode
- Node Resource Constraints
Apply a taint:
- $kubectl taint nodes <node-name> <key>=<value>:<effect>
- Example:
- $kubectl taint nodes kind-worker storage=ssd:NoSchedule
- $kubectl taint nodes kind-worker2 storage=hdd:NoSchedule
- These commands taint kind-worker to only allow pods that tolerate storage=ssd:NoSchedule and kind-worker2 to only allow pods that tolerate storage=hdd:NoSchedule

Effects of taint:

Effect	Behaviour
NoSchedule	New pods will not be scheduled unless they have a matching toleration.
PreferNoSchedule	Kubernetes tries to avoid scheduling pods but doesn’t enforce it strictly.
NoExecute	Existing pods without a matching toleration will be evicted from the node.

Lab:
- taint1.jpg
- taint has been applied on nodes with color=green, color=blue and color=purple.
- tolerations will be define in pods creation command or yaml with key, operator, value and effects.
- Effects plays an important role on which it will decide on which pod should it be created.
- $kubectl get nodes (there are three nodes: kind-control-plane, kind-worker, kind-worker2)
  - $kubectl taint node kind-worker color=green:NoSchedule
  - NoSchedule is the effect of this taint, any pod needs to be created on this node sould have toleration that is color=green, new pods will only be created where color=green is defined.
  - node/kind-worker tainted.
  - $kubectl describe node kind-worker
  - taint2.jpg
  - $kubectl taint node kind-worker2 color=blue:NoSchedule
  - node/kind-worker2 tainted.
  - create a pod without defining tolerations:
  - $kubectl run web-server --image =nginx
  - $kubectl get pods (status is pending, why? because no tolerations has been define for pod as pod is tainted)
  - Deploy with yaml file and define tolerations using effects.
  - $vim deploy_taint1.yaml (effect=NoSchedule)
    - apiVersion: apps/v1
      
      kind: Deployment
      
      metadata:
      
      name: star-app1
      
      spec:
      
      replicas: 3
      
      selector:
      
      matchLabels:
      
      app: star-app1
      
      template:
      
      metadata:
      
      labels:
      
      app: star-app1
      
      spec:
      
      tolerations:
      
      - key: "color"
      
      operator: "Equal"
      
      value: "green"
      
      effect: "NoSchedule"
      
      containers:
      
      - name: star-app1-container
      
      image: nginx
    - The value of effect must be sam to value defined in taint (In taint we defined NoSchedule)
    - $kubectl apply -f deploy_taint1.yaml
    - $kubectl get pods -o wide
    - star-app1-55b986694b-48hn9 1/1 Running 0 7s 10.244.2.20 kind-worker <none> <none>
      star-app1-55b986694b-gjj6p 1/1 Running 0 7s 10.244.2.21 kind-worker <none> <none>
      star-app1-55b986694b-jzwx4 1/1 Running 0 7s 10.244.2.19 kind-worker <none> <none>
    - pods are created in kind-worker node where we have define taint.
    - change the color=blue and run the deployment, 3 pods will be created in kind-worker2 node. first 3 pods with green color will be deleted as effect="NoSchedule" it means any new pods creating should have tolerance match with tolerace value.
- Multiple taints:
- Remove & re-apply taint on worker node:
  - Check the taint applied on node
  - $kubectl describe node node_name | grep -i taint
  - take the node name, taint_name
  - $kubectl taint node <node_name> <taint_name>-
  - Apply taint again
  - $kubectl taint node <node_name> <taint_name>-
  - Remove - sign at the end.
- Remove & re-apply taint on control-plane node:
  - By default taint is applied on control-plane node: To check
    - $kubectl describe node node_name | grep -i taint
    - Taints: node-role.kubernetes.io/control-plane:NoSchedule
    - To remove taint from control-plane node (apply - at the end)
    - $kubectl taint node <node_name> <taint_name>-
    - $kubectl taint node kind-control-plane node-role.kubernetes.io/control-plane:NoSchedule-
    - node/kind-control-plane untainted
    - apply taint
    - $kubectl taint node kind-control-plane node-role.kubernetes.io/control-plane:NoSchedule
- Code
Tolerations: Tolerations are applied to pods.

Node Selector, Affinity and anti-Affinity

In Kubernetes, scheduling decisions determine where a pod runs within the cluster. While Kubernetes has a built-in scheduler that automatically assigns pods to nodes, administrators often need to influence scheduling decisions to ensure specific workloads run on designated nodes.
To achieve this, Kubernetes provides label-based scheduling techniques such as:

More details on github: https://github.com/AbdulAziz-uk/kubernetes-complete-tutorial/blob/main/Day%2017/README.md

Node Selector (Basic): Assigns pods to nodes based on simple key-value labels.
- Nodes must have specific labels for the pod to be scheduled.
- If no node matches the label, the pod remains in a Pending state.
- Only supports exact key-value matching (no advanced logic).

Node Affinity and Anti-Affinity (Advanced): Provides more flexibility, including soft preferences and multiple conditions.

It allows hard constraints (must match) and soft preferences (prefer but not mandatory).
It enables complex AND/OR conditions for node selection.
It supports set-based expressions (In, NotIn, Exists, etc.), unlike nodeSelector.
How it works:
Step 1: Assign Labels to nodes:
Step 2: Define node selector in pod spec.
Step 3: Pods are scheduled only on nodes matching the label.
Limitation of node selector:

Limitation	Explanation
Strict Placement	If no node matches the label, the pod remains in the Pending state.
No Preferences	It does not allow "soft" preferences—either a node matches or it does not.
No or Condition	You cannot specify "schedule on nodes with `storage=ssd` OR `storage=hdd`".

Lab: Three pods cluster (kind-control-plane, kind-worker and kind-worker2)
check existing label on nodes:
- $kubectl get nodes --show-labels
- $kubectl describe node node_name
Label a node:
- $kubectl lebel nodes node_name label'skey=pair
- $kubectl label nodes kind-worker storage=ssd
Deploy a pod with node selector:
- $vim node_selector1.yaml
- apiVersion: apps/v1
  
  kind: Deployment
  
  metadata:
  
  name: ns-deploy
  
  spec:
  
  replicas: 3
  
  selector:
  
  matchLabels:
  
  app: app1
  
  template:
  
  metadata:
  
  labels:
  
  app: app1
  
  spec:
  
  nodeSelector:
  
  storage: ssd
  
  containers:
  
  - name: nginx
  
  image: nginx
$kubectl apply -f node_selector1.yaml
Pods will only be scheduled on kind-worker node because it has the label storage=ssd.
whatever label is defined in nodes should & must have same defined in pod spec.
If no node has storage=ssd, the pods remain in the Pending state. both node and pod spec has the same key=value pair.

Unlabel a node:
- $kubectl label nodes kind-worker storage-
When you do deployment, pods will be in pending state because labels from node has been deleted but nodeSelector is still defined in yaml file.

Node Affinity: defining multiple key=value for node selector.

Step 1: Assign multiple Labels to nodes: (storage=ssd, env=prod)
Step 2: Define node selector in pod spec.
Step 3: Pods are scheduled only on nodes matching the label.
Lab: Three pods cluster (kind-control-plane, kind-worker and kind-worker2)
check existing label on nodes:
- $kubectl get nodes --show-labels
- $kubectl describe node node_name
Label a node:
- $kubectl lebel nodes node_name label'skey=pair
- $kubectl label nodes kind-worker2 storage=ssd env=prod
Deploy a pod with node selector: The pod will only be scheduled if a node has both storage=ssd and env=prod.
AND condition: where you define both key values, both values must exist in node label.
- $vim affinity.yaml
- apiVersion: apps/v1
  
  kind: Deployment
  
  metadata:
  
  name: ns-deploy
  
  spec:
  
  replicas: 3
  
  selector:
  
  matchLabels:
  
  app: app1
  
  template:
  
  metadata:
  
  labels:
  
  app: app1
  
  spec:
  
  affinity:
  
  nodeAffinity:
  
  requiredDuringSchedulingIgnoredDuringExecution:
  
  nodeSelectorTerms:
  
  - matchExpressions:
  
  - key: storage
  
  operator: In
  
  values:
  
  - ssd
  
  - key: env
  
  operator: In
  
  values:
  
  - prod
  
  containers:
  
  - name: nginx
  
  image: nginx
$kubectl apply -f affinity.yaml
Pods will only be scheduled on kind-worker node because it has the label storage=ssd & env=prod.
whatever label is defined in nodes should & must have same defined in pod spec in AND operator used.
Deploy a pod with node selector: The pod will only be scheduled if a node has either storage=ssd or storage=hdd
or condition: where you define one key value in spec, two values defined in node labels.
- $vim affinity.yaml
- apiVersion: apps/v1
  
  kind: Deployment
  
  metadata:
  
  name: ns-deploy
  
  spec:
  
  replicas: 3
  
  selector:
  
  matchLabels:
  
  app: app1
  
  template:
  
  metadata:
  
  labels:
  
  app: app1
  
  spec:
  
  affinity:
  
  nodeAffinity:
  
  requiredDuringSchedulingIgnoredDuringExecution:
  
  nodeSelectorTerms:
  
  - matchExpressions:
  
  - key: storage
  
  operator: In
  
  values:
  
  - ssd
  
  - hdd
  
  containers:
  
  - name: nginx
  
  image: nginx
$kubectl apply -f affinity.yaml
Pods will only be scheduled on kind-worker2 node because it has the label storage=ssd

Operators: In, NotIn, Exists, DoesNotExist, Gt, Lt

Operator	Behavior
`In`	Matches if the node’s label exists in the provided values.
`NotIn`	Matches if the node’s label does not exist in the provided values.
`Exists`	Matches if the node has the specified key, regardless of its value.
`DoesNotExist`	Matches if the node does not have the specified key.
`Gt`	Matches if the label’s value is greater than the specified number.
`Lt`	Matches if the label’s value is less than the specified number.

affinity:

nodeAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

nodeSelectorTerms:

- matchExpressions:

- key: storage

operator: In

values:

- ssd

- hdd

- key: env

operator: NotIn

values:

- dev

- key: high-memory

operator: Exists

- key: dedicated

operator: DoesNotExist

- key: cpu

operator: Gt

values:

- "4"

- key: disk

operator: Lt

values:

- "500"
Explanation:

Condition	Effect
`storage In (ssd, hdd)`	✅ Pod can be scheduled if the node has storage=ssd OR storage=hdd.
`env NotIn (dev)`	✅ Pod is not scheduled on nodes labeled `env=dev`.
`high-memory Exists`	✅ Pod can be scheduled only on nodes that have a `high-memory` label.
`dedicated DoesNotExist`	✅ Pod avoids nodes with `dedicated` label.
`cpu Gt 4`	✅ Pod can be scheduled only on nodes with CPU > 4.
`disk Lt 500`	✅ Pod can be scheduled only on nodes with disk < 500.

Code

Taint & Toleration Vs Affinity
- Code
Request Limit and Limit Range
- Code
Autoscaling HPA & VPA
- autoscaling1.jpg
- Scaling refers to adjusting the resources available to an application based on its demand/load. The key objective is to ensure the app has enough resources to handle current traffic, without wasting resources when demand is low.
- Elastic Scaling: We want the ability to scale up when load increases and scale down when load decreases.
- Types of Scaling
  - Horizontal Scaling
    - scale out: Adding more instances or pods when load increases.
    - scale In: Removing instances/pods when load decreases.
  - Vertical Scaling
    - scale up: Increasing CPU/Memory resources of the existing pod or VM.
    - scale down: Reducing CPU/Memory.
    - Vertical scaling often requires a restart of the resource (pod/VM) because:
      
      VM: The OS needs to recognize new resources.
      
      Pod: Kubernetes needs to recreate the pod with updated resource requests/limits.
- Horizontal Scaling:
  - Manual: Increase or decrease replicas manually by
    - Declarative method: Edit the Deployment YAML (replicas field)
    - Imperative method: $kubectl scale deploy deployment_name --replicas=2
  - Automatic:
    - Use HPA (Horizontal Pod Autoscaler) to automatically adjust replica count based on CPU, memory, or custom metrics.
- Vertical Scaling:
- Code
Labels:
- When you create deployment than pods will be created on worker nodes & master node if taint is disabled. It will be distributed and created in all nodes.
- If you want all pods to be created on a particular node than it can be achieved with label.
- Set label on each node and define label when creating deployment.
- We create namespace for logical isolation in a cluster.
- Number of pods will be created on all nodes but under the same namespace, when you search pods with namespace than it wlll list all pods with the same namespace.
- you can bind number of nodes with a namespace so that number of pods will be created with the same namespace in those defined nodes.
- Set Label:
  - $kubectl label node master node=star1
  - $kubectl label node worker1 node=star2
  - $kubectl describe node master
- Deploy all nodes on worker1 node using label node=star1
  - $vim label1.yaml
  - apiVersion: v1
    kind: Pod
    metadata:
    name: prod-server
    spec:
    containers:
    - image: nginx
    name: prod-server
    nodeSelector:
    node: "star1
  - $kubectl apply -f label1.yaml
  - pods are deployed on master node only.
- Deploy all nodes on master node using label node=star2
  - $vim label1.yaml
  - apiVersion: v1
    kind: Pod
    metadata:
    name: prod-server
    spec:
    containers:
    - image: nginx
    name: prod-server
    nodeSelector:
    node: "star2"
  - $kubectl apply -f label2.yaml
  - pods are deployed on worker1 node only.
- Bind Labels with namespace.
  - When you deploy, all pods will be created on nodes which are bind with labels
  - Create a name space:
    - $kubectl create namespace dev-team &
    - $kubectl create namespace prod-team
    - $kubectl get namespace
    - $kubectl delete namespace dev-team
    - $kubectl delete namespace prod-team
  - Deployment
    - $kubectl create deployment -n dev-team web-server --image=nginx --replicas=3
    - $kubectl create deployment -n prod-team db-server --image=nginx --replicas=3
  - list pods from namespace dev-team and prod-team:
    - $kubectl get pods -n dev-team
    - $kubectl get pods -n prod-team
    - Pods are creating in master and worker node,
    - Delete:
    - $kubectl delete deployment web-server -n dev-team
    - $kubectl delete deployment db-server -n prod-team
  - Pods should be created in one node only.
    - Perform the following steps in api server
    - $cd /etc/kubernetes /manifests
    - $etc/kuberntes/manifests vim kube-apiserver.yaml
    - add parameter at line - --enable-admission-plugins=NodeRestriction,PodNodeSelector
    - save and exit (there will be short downtime)
  - Now bind nodes in namespace (dev-team and prod-team)
    - Will bind master node with dev-team and worker1 node with prod-team
    - $kubectl edit namespace dev-team
    - after line name: dev-team
    - annotations:
    - scheduler.alpha.kubernetes.io/node-selector: "node=star1" save and exit
    - $kubectl edit namespace prod-team
    - after line name: prod-team
    - annotations:
    - scheduler.alpha.kubernetes.io/node-selector: "node=star2" save and exit
  - Create Deployment
    - $kubectl create deployment dev-server -n dev-team --image=nginx --replicas=3
      
      all pods will be created in master node
    - $kubectl create deployment prod-server -n prod-team --image=nginx --replicas=3
      
      All pods will be created in worker1 node
  - Remove labels:
    - $kubectl label node master node-
    - $kubectl label node worker1 node-
  - Remove namespace selector
    - $kubectl edit namespace dev-team (remove both lines annotations & scheduler.alpha.kubernetes.io/node-selector: node=star1
    - $kubectl edit namespace dev-team (remove both lines annotations & scheduler.alpha.kubernetes.io/node-selector: node=star2
  - Remove binding
    - $cd /etc/kubernetes/manifests
    - $etc/kubernetes/manifests vim kube-apiserver.yaml and remove PodNodeSelector
    - There will be downtime for few minutes.
- Code
Configmap:
- A ConfigMap is an API object used to store non-confidential data in key-value pairs.
- $vim configmap.yaml
  - apiVersion: v1
    
    kind: ConfigMap
    
    metadata:
    
    name: example-config
    
    data:
    
    key1: value1
    
    key2: value2
- code
- code
Secrets:
- A Secret in Kubernetes is an object that allows you to store sensitive information, such as passwords, OAuth tokens, and ssh keys. They are stored in a base64 encoded format.
- ConfigMap stored non-confidential data.
- Code
Context:
- When you set context it will set default namespace, when you deploy it will applied to set namespace and do not need to enter -n namespace,
- $kubectl config set-context --current --namespace=namespace1
- Now when you depoloy it will be deployed on namespace1.
- code
- Code

Pod Deletion/Termination Signals, Restart Policy, Image Pull Policy, Pod life cycle, Common Errors

This section provides understanding of Kubernetes Pod lifecycle, status transitions, termination behavior, restart and image pull policies. It also covers common pod errors like ImagePullBackOff and CrashLoopBackOff with troubleshooting tips, ensuring you can effectively debug and manage pods in any Kubernetes environment.

Deletion / Termination:

Pod_Termination1.jpg
What Happens When You Run $kubectl delete pod?
Kubernetes initiates a graceful termination sequence rather than an abrupt shutdown.
- SIGTERM: As soon as the delete command is issued, Kubernetes sends the SIGTERM signal to the main process of each container inside the pod. This signal tells the application: “It’s time to shut down gracefully. Please wrap up any ongoing tasks.”
- Termination Grace Period: By default, Kubernetes waits for 30 seconds (configurable via terminationGracePeriodSeconds in the pod spec) for the container to exit gracefully.
- SIGKILL: If the container does not exit within this grace period, Kubernetes sends a SIGKILL signal to force an immediate shutdown.
Containers are typically provided with a graceful shutdown period during termination to allow the application to handle the termination signal (e.g., SIGTERM) appropriately. This mechanism ensures that important operations, such as closing active connections, flushing cached data, or completing ongoing tasks, are carried out before the container stops.
Lab: Pod running an NGINX server. With a graceful shutdown enabled in container code, it might finish serving current requests and close connections cleanly when receiving a SIGTERM. If it takes too long—over the grace period—SIGKILL will terminate it immediately.
- $vim pod_termination1.yaml
  
  apiVersion: v1
  
  kind: Pod
  
  metadata:
  
  name: nginx-graceful
  
  spec:
  
  terminationGracePeriodSeconds: 30
  
  containers:
  
  - name: nginx
  
  image: nginx:latest
$kubectl apply -f pod_termination1.yaml
Force Delete pod.
$kubectl delete pod nginx-graceful --force=true --grace-period=0
This forces the pod to terminate immediately, and under the hood, it behaves similarly to sending a SIGKILL signal to the container's process.
- --force=true bypasses the normal graceful deletion process.
- --grace-period=0 tells Kubernetes not to wait and to immediately kill the pod.
- Kubernetes doesn't directly send UNIX signals itself but delegates this to the container runtime (like containerd or Docker).
When Kubernetes receives this forceful deletion request:
- It immediately removes the pod from the API server (even if it's still running on the node).
- It then asks the container runtime to kill the container without giving the app time to shut down gracefully, similar to a SIGKILL.
$kubectl delete pod mypod --force=true
- without specifying --grace-period=0, it still tries to respect the pod's default termination grace period (which is usually 30 seconds) unless overridden by the pod's spec.
- To force immediate termination (equivalent to SIGKILL):

Command	API Server (Pod object)	Kubelet (Container termination)	Grace Period Behavior	Explanation
`kubectl delete pod mypod`	Deletes Pod gracefully	Kubelet follows normal process	Graceful shutdown	Pod object removed, Kubelet gracefully stops container (SIGTERM, waits for grace period, then SIGKILL).
`kubectl delete pod mypod --force=true`	Deletes Pod immediately	Kubelet still respects terminationGracePeriodSeconds	Graceful unless explicitly overridden	Pod object deleted immediately, but Kubelet still monitors the running container and honors the grace period.
`kubectl delete pod mypod --force=true --grace-period=0`	Deletes Pod immediately	Kubelet kills container immediately	No grace period, immediate SIGKILL	Pod deleted from API server, Kubelet stops monitoring and forcefully kills the container instantly.

Restart Policies:
Image Pull Policies:
- Reference: Kubernetes Official Documentation: Container Images
Pod Lifecycle phases:
- Reference: Kubernetes Official Documentation: Pod Lifecycle
Debugging Common Pod Errors:

code
- - code

Configuration of other kubernetes services

Kubernetes Storage: PV (Persistence Volume), PVC (Persistence Volume Claim)
- A volume is created and attach to database. data is stored in these volumes. If in case of pod is deleted or need to create a new pod so that data can be retrieved from this volumes.
- When a new pod is created then ephemral (temp) storage is created and attach to pod, it store downloads and other data. when pod is deleted than this runtime data is also get deleted.
- kubernetes offered persistent volume to store the data. persistent volume could be local hard drive, which can be mounted to pods. if the pod get deleted and it will recreated but it could be recreated in different node so storage is in different node.
- Types of storage can be use a persistent volume.
  - NFS
    - Create NFS server on ubuntu:
  - SCSI:
  - AWS S3: AWS EBS
  - Azure volume:
  - Redhat: Gluster
  - other supported volumes
- Create PV: click here
  - $kubectl get pv (to check any PV exist)
  - $vim pv.yaml (click here for yaml file)
  - $kubectl apply -f pv.yaml
  - $kubectl get pv
  - $kubectl describe pv sta-volume
- PVC: Persistence Volume Claim: It is the small volume created in persistent volume.
  - Create PVC (persistent volument claim)
  - $kubectl get pvc
  - $vim pvc.yaml (click here for yaml file)
  - $kubectl get pvc
  - $kubectl describe pv star-pvc
- Deploying WordPress and MySQL with Persistent Volumes and inside use pvc which is inside pv and pv is inside nfs volume.
  - $vi pv_deployment.yaml , click here for yaml file
  - $kubectl apply -f pv-deployment.yaml
  - $kubectl get deployment
  - $kubectl get pod
- code
Code
- Code
- code
Code
- Code
- code
Code
- Code

Resource Quota (namespace):

It applies on namespace. You can set the quota on cluster resources on the basis of namespace.
You can allocate the resources for entire namespace, you cannot limit on pods/containers which can be done by limit range.
Namespace is created to isolate the pods for different departments or projects. you can allocate the resources to each namespace/project.
Suppose you have cluster capacity 500 GB memory, 500 TB Disk, 500 CPU, 3 projects running on cluster which is isolated with namespace (namespace1,2,3 namely).
You can set the resourcdes quota for these projects like memory 100GB, pods 100, cpu 50, secret 10, configmap 20, all components should be created withing this quota.

Apply namespace:

$kubectl get namespace (list of namespaces)

NAME STATUS AGE
default Active 11d
kube-node-lease Active 11d
kube-public Active 11d
kube-system Active 11d
metallb-system Active 3d22h

The above is default namespace list.
$kubectl create namespace namespace1 (create for namespace2 & namespace3)

Check quota :
- $kubectl -n namespace1 get quota (no resources found for the namespace)

Apply quota: https://kubernetes.io/docs/concepts/policy/resource-quotas/

$vim namespace1_quota.yaml & create for namespace2 & namespace3

apiVersion: v1
kind: ResourceQuota
metadata:
name: project3-quota # Set a name here, for example "my-quota"
namespace: namespace3 # Specify the namespace
spec:
hard:
pods: 5
configmaps: 10
secrets: 10
services: 10
requests.cpu: 2
requests.memory: 8Gi

$kubectl -n namespace1 apply -f namespace1.yaml
$kubectl -n namespace1 get quota
$kubectl -n namespace1 describe quota
$kubectl run -n namespace1 web-server1 --image=nginx (one pod is created and one more capacity is remaining)
$kubectl -n namespace1 describe quota
when you create a pod and its limit has been used then it will create the services which has not been mentioned in quota yaml file.
increase quota limit by editing yaml file.
define memory and cpu limit.

apiVersion: v1

kind: ResourceQuota

metadata:

namespace: namespace1

spec:

hard:

pods: "2"

configmaps: "10"

secrets: "10"

services : "10"

persistentvolumeclaims: "50"

limits.memory: "800Mi"

limits.cpu: "10"

When you define memory and cpu limit in quota, while creating a pod you need to define memory and cpu as well.

code
code
code

Limit Range (Container, POD, Volume):

By default, containers run with unbounded compute resources on a Kubernetes cluster. Using Kubernetes resource quotas, administrators (also termed cluster operators) can restrict consumption and creation of cluster resources (such as CPU time, memory, and persistent storage) within a specified namespace. Within a namespace, a Pod can consume as much CPU and memory as is allowed by the ResourceQuotas that apply to that namespace. As a cluster operator, or as a namespace-level administrator, you might also be concerned about making sure that a single object cannot monopolize all available resources within a namespace.
You can define min / max size limit range on pods / containers / volumes so that available resources can be distribute easily.
For more details visit
In the Resource Quota we have applied overall limit of 5GB RAM, 50GB HDD, 50 CPU to namespace, pods are created within a namespace.
When you deploy in this namespace than limit of pods can be applied through limit range so that pods should not exceed limit.
We can define min and max limit of each pod while creating.

If you do not define namespace while creating limit range than it will applied to default namespace.

Apply limit range on containers:

$kubectl get limitrange (To get list of limitrange configured)
Example of cpu only:

For Kubernetes documentation
Cluster details
- $kubectl get nodes (Master and Worker1)Apply limit range on containers.
Create a namespace
- $kubectl create namespace limitrange-demo
Set Context
- we do not need to define namespace everytime, as it has been set to limitrange-demo namespace instead of default namespace.
- $kubectl config set-context --current --namespace=limitrange-demo
- $kubectl config get-contexts
- $kubectl config delete-context kubernetes-admin@kubernetes

Limit min/max cpu for containers:

$vim limitrange_cpu_1.yaml
- apiVersion: v1
  kind: LimitRange
  metadata:
  name: cpu-resource-constraint
  spec:
  limits:
  - max: # max and min define the limit range
  cpu: "500m"
  min:
  cpu: 100m
  type: Container
$kubectl apply -f limitrange_cpu_1.yaml
$kubectl describe limitrange
$kubectl delete 0f limitrange_cpu_1.yaml
Default request and default limit has been not defined but it took max. you can set default request and default limit.

$vim limitrange_cpu_2.yaml

apiVersion: v1
kind: LimitRange
metadata:
name: cpu-resource-constraint
spec:
limits:
- default: # If you do not define max cpu while creating container, it will take default as max
cpu: "700m"
defaultRequest: # If you do not define min cpu while creating container, it will take defaultRequest as min
cpu: "110m"
max: # max milicore cpu a container can get
cpu: "800m"
min:
cpu: "100m" #min milicore cpu a container can get
type: Container

$kubectl apply -f limitrange_cpu_2.yaml
$kubectl describe limitrange

Test: Deploy nginx container

$vim limitrange_pod1.yaml

apiVersion: v1
kind: Pod
metadata:
name: busybox1
spec:
containers:
- name: busybox-cnt01
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]
resources:
requests:
cpu: "100m"
limits:
cpu: "500m"

It is creating a pod with the name busybox1, container name busybox-cnt01, image busybox, describe command to run , define min 100Mi and max 200Mi cpu.
pod will be created as defined pod range is within the limit of limitrange defined in limitrange_cpu_2.yaml (min 110m max 700m)
$kubectl apply -f limitrange_pod1.yaml
pod has been created as limit within defined range.
$kubectl delete -f limitrange_pod1.yaml
Exceed limit range: edit the file and define max cpu limit 900M(limitrange defined min 100M and max 800M

apiVersion: v1
kind: Pod
metadata:
name: busybox1
spec:
containers:
- name: busybox-cnt01
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]
resources:
requests:
cpu: "100m"
limits:
cpu: "900m"

$kubectl apply -f limitrange_pod1.yaml
Error: maximum cpu usage per Container is 800m, but limit is 900m
Remove min and max values and run, it will apply default values defined in limitrange. (110m and 700m)

apiVersion: v1
kind: Pod
metadata:
name: busybox1
spec:
containers:
- name: busybox-cnt01
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]

$kubectl apply -f limitrange_pod1.yaml
$kubectl delete -f limitrange_pod1.yaml

Total 4 containers are creating in this example, if you add all four containers cpu which will be more than defined max cpu vlaue, so it will give error that max cpu limit is exceeded.

$vim limitrange_pod1.yaml

apiVersion: v1
kind: Pod
metadata:
name: busybox1
spec:
containers:
- name: busybox-cnt01 #first container
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]
resources:
requests:
cpu: "100m"
limits:
cpu: "900m"
- name: busybox-cnt02 #second container
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt02; sleep 10;done"]
resources:
requests:
cpu: "100m"
- name: busybox-cnt03 #third container
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt03; sleep 10;done"]
resources:
limits:
cpu: "500m"
- name: busybox-cnt04 #fourth container
image: busybox:1.28
command: ["/bin/sh"]
args: ["-c", "while true; do echo hello from cnt04; sleep 10;done"]

$kubectl apply -f limitrange_pod1.yaml
Error from server (Forbidden): error when creating "limitrange_pod1.yaml": pods "busybox1" is forbidden: maximum cpu usage per Container is 800m, but limit is 900m
first container max cpu is defined 900m, change it to 500m and run.
$kubectl apply-f limitrange_pod1.yaml
$kubectl describe pod (check all four container cpu details)

Example of cpu and memory:
- $ vim limit-mem-cpu-per-container.yaml (create a yaml file) download yaml file.
- $kubectl create namespace limitrange-demo (create namespace)
- $kubectl config set-context --current --namespace=limitrange-demo (set context, it will set default namespace, you will not required to enter -n namespace while deployment)
- In the above min,max, default memory and cpu has been defined.
- default values is the max value when no values has been defined while creation. defaultRequest is the min values if no values has been defined.
- limit is applying on container
- $kubectl apply -f limit-mem-cpu-per-container.yaml
- $kubectl get limitrange
- $kubectl describe limitrange
- Deploy a container to check the defined min/max cpu & memory setup.
- $vim limit-range-pod-2.yaml
- $kubectl apply -f limit-range-pod-2.yaml
- $kubectl describe pods podname (check the memory and cpu allocation)
- edit yaml file and check with exceeding max limit of cpu/memory or below limit of cpu/memory. (cpu max limit changed to 900)
- Error from server (Forbidden): error when creating "limit-range-pod-2.yaml": pods "busybox1" is forbidden: maximum cpu usage per Container is 800m, but limit is 900m
- Deploy a container to check teh defined min/max cpu & memory limit on multiple pods.
- $vim limit-range-pod-1.yaml
- $kubectl apply -f limit-range-pod-1.yaml
- $kubectl describe pods podname (check details)

Apply limit range on pods:

$kubectl get limitrange
Cluster details
- $kubectl get nodes (Master and Worker1)Apply limit range on containers.
Create a namespace
- $kubectl create namespace limitrange-demo
Set Context
- we do not need to define namespace everytime, as it has been set to limitrange-demo namespace instead of default namespace.
- $kubectl config set-context --current --namespace=limitrange-demo

Limit min/max cpu for pods: https://k8s.io/examples/admin/resource/limit-mem-cpu-pod.yaml

$vim limit_mem_cpu_per_pod.yaml
Note: You can define max and min values in pod limit range but you cannot define default (max) & defaultRequest(min) values in pod as it can be define in container limit range.
if default values specified than you get following error:
- Error: default: Forbidden: may not be specified when 'type' is 'Pod'
- Error: defaultRequest: Forbidden: may not be specified when 'type' is 'Pod'
If you define max value in limitrange yaml file than while deploying you must define max value.

apiVersion: v1

kind: LimitRange

metadata:

spec:

limits:

- max:

cpu: "2"

memory: "2Gi"

min:

cpu: "1"

memory: "1Gi"

type: Pod

$kubectl apply -f limit_mem_cpu_per_pod.yaml
$kubectl get limitrange
$kubectl describe limitrange

Deploy a pod:

$vim limitrange_pod2.yaml

apiVersion: v1

kind: Pod

metadata:

spec:

containers:

- name: busybox-cnt01

image: busybox:1.28

command: ["/bin/sh"]

args: ["-c", "while true; do echo hello from cnt01; sleep 10;done"]

resources:

requests:

memory: "100Mi"

cpu: "100m"

limits:

memory: "200Mi"

cpu: "500m"

$kubectl apply -f limitrange_pod2.yaml
pod limit defined memory min 100Mi and max 200Mi, cpu min 100m and max 500m
$kubectl describe pods
limit we have defined in limit range cpu 500m & memory 200Mi, requested to create pod with memory 100Mi and cpu 100 m, pod is created successfully.
$kubectle delete -f limitrange_pod2.yaml
Make changes in the limitrange yaml file and test it.
- if you define only min values than it will assing min values to pod.
- if you define only max values than it will assign max values to pod.
- if you define both min and max values than it will assing min values to pod.
- If no min & max values define in yaml file will get an error:
  - Error from server (Forbidden): error when creating "limitrange_pod2.yaml": pods "busybox2" is forbidden: [maximum cpu usage per Pod is 2. No limit is specified, maximum memory usage per Pod is 2Gi. No limit is specified]
- if you define multiple pods in yaml file and it will calculate all pods limit and will not create if values exceeded max.

Apply limit range on storage/volumes:
- In Pods/container we do not assign storage directly, first we create a persistent volume (storage), and in PV we create persistent volume claim (a portion in PV) and attach to pod/volumes.
- We set limit range on PVC.
- Cluster details
  - $kubectl get nodes (Master and Worker1)Apply limit range on volumes (PVC).
- Check limitrange created
  - $kubectl get limitrange
- Create a namespace
  - $kubectl create namespace starnamespace
- Limit min/max storage resources: https://k8s.io/examples/admin/resource/storagelimits.yaml
  - $vim storagelimits.yaml
    - apiVersion: v1
      
      kind: LimitRange
      
      metadata:
      
      name: storagelimits
      
      spec:
      
      limits:
      
      - type: PersistentVolumeClaim
      
      max:
      
      storage: 2Gi
      
      min:
      
      storage: 1Gi
  - $kubectl apply -f storagelimits.yaml -n starnamespace (defining namespace as context has not been set)
  - $kubectl describe limitrange -n starnamespace
- Create a persistent volume claim:
  - $vim pvc.yaml : https://k8s.io/examples/admin/resource/pvc-limit-lower.yaml
  - apiVersion: v1
    
    kind: PersistentVolumeClaim
    
    metadata:
    
    name: pvc-limit-lower
    
    spec:
    
    accessModes:
    
    - ReadWriteOnce
    
    resources:
    
    requests:
    
    storage: 1Gi
  - $kubectl apply -f pvc.yaml -n starnamespace
  - $kubectl get pvc -n starnamespace
  - Status is pending as there is no Persistent Volume configured.
  - $kubectl describe pvc -n starnamespace:
  - Error: No persistent volume is available.
- Create persistent volume in Ubuntu:
  - $sudo apt-get install nfs* -y

Code
- Code
- code
Code
- Code
- code
Code
- Code
- code
- code
Code
- code
- code
- code
Code
- Code
- code
code
- code
- code
- code
code
- code
- code
- code

Kubernetes Commands & Troubleshooting: click for cheat sheet of kubernetes commands.

$kubectl: It is a program which is responsible for executing kubernestes commands on cluster. It should be install on system where commands are executing.

apply		It applies changes to Kubernetes resources defined in YAML or JSON files
	kubectl apply -f deployment.yaml	This command applies the code specified in the deployment.yaml file to the cluster.
	kubectl apply -f deployment.yaml --record	This command applies the changes specified in the deployment.yaml file to the deployment and records the changes in the revision history.
	kubectl apply -f pod.yaml --namespace=my-namespace	This command applies the configuration specified in pod.yaml to the namespace my-namespace.
	kubectl apply -f deployment.yaml --namespace=my-namespace --record	This command applies the changes specified in deployment.yaml to the deployment in the namespace my-namespace and records the changes.
	kubectl apply -f ./my-resources/ --recursive	This command applies all YAML files located in the my-resources directory and its subdirectories
	kubectl apply -f pod.yaml --validate=true	This command validates the pod.yaml file before applying changes to the cluster.
	kubectl apply -f pod.yaml --dry-run=client	This command checks if the configuration in pod.yaml can be applied without actually applying it.

annotate		This command adds or updates annotations on Kubernetes resources.
	kubectl annotate pod my-pod description="This is my pod"	This command adds the annotation description="This is my pod" to the pod named my-pod
alias	alias k=kubectl	it sets k as alias for kubectl, you can run k get nodes instead of kubectl get nodes.
api-resources		This command lists all available API resources.
ai-versions
attach
auth
	kubectl api-resources	This command lists all the API resources supported by the Kubernetes API server.
config
completion
cp
create		This command is used to create Kubernetes resources from files or stdin.
	kubectl create -f pod.yaml	This command creates a pod using the configuration specified in the pod.yaml file
	kubectl create namespace my-namespace	This command creates a new namespace named my-namespace
	kubectl create -f ./my-resources/	This command creates Kubernetes resources defined in all .yaml files located in the my-resources directory.
	kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=passw0rd	This command creates a secret named my-secret with two key-value pairs: username=admin and password=passw0rd.
	kubectl create deployment my-deployment --image=my-image:tag	This command creates a deployment named my-deployment using the image my-image:tag.
	kubectl create secret generic my-secret --from-file=./my-secret-file	This command creates a generic secret named my-secret from the contents of the file my-secret-file.
	kubectl create service nodeport my-service --tcp=80:8080	This command creates a NodePort service named my-service to expose a deployment on port 8080.
	kubectl create -f pod.yaml --dry-run=client	This command validates the configuration in pod.yaml without actually creating the pod.
	kubectl create role my-role --verb=get --resource=pods	This command creates a role named my-role with permissions to get pods within the namespace.
	kubectl create serviceaccount my-service-account	This command creates a service account named my-service-account within the current namespace.
	kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2	This command creates a config map named my-config with two key-value pairs: key1=value1 and key2=value2.
cluster-info		It displays cluster info such as server URL and Kubernetes version.
cluster-info	kubectl cluster-info	This command displays information about the Kubernetes cluster.
delete


debug	kubectl describe pod podname kubectl logs podname
describe

edit
exec
explain
expose

kubectl get: It is used to retrieve Kubernetes resources. For instance:
kubectl get pods (This command retrieves all pods in the current namespace).

kubectl describe: This command provides detailed information about a Kubernetes resource. For example:
kubectl describe pod my-pod
This command describes the pod named my-pod, displaying detailed information including its status, containers, and events.

kubectl delete: It is used to delete Kubernetes resources. For instance:
kubectl delete pod my-pod
This command deletes the pod named my-pod.

kubectl exec: This command executes commands inside a running container in a pod. For example:
kubectl exec -it my-pod -- /bin/bash
This command starts an interactive shell (/bin/bash) inside the pod named my-pod.

kubectl logs: It retrieves the logs of a pod. For instance:
kubectl logs my-pod
This command displays the logs of the pod named my-pod.

kubectl port-forward: This command forwards one or more local ports to a pod. For example:
kubectl port-forward my-pod 8080:80
This command forwards local port 8080 to port 80 on the pod named my-pod.

kubectl scale: It scales the number of replicas of a resource. For instance:
kubectl scale --replicas=3 deployment/my-deployment
This command scales the number of replicas of the deployment named my-deployment to 3.

kubectl edit: This command edits the resource definition in a text editor. For example:
kubectl edit pod my-pod
This command opens the resource definition of the pod named my-pod in a text editor, allowing you to make changes.

kubectl rollout: This command manages rollouts of updates to Kubernetes resources. For example:
kubectl rollout status deployment/my-deployment
This command checks the status of the rollout for the deployment named my-deployment.

kubectl label: It adds or updates labels on Kubernetes resources. For instance:
kubectl label pod my-pod app=backend
This command adds the label app=backend to the pod named my-pod.

kubectl rollout history: This command views rollout history of a deployment. For instance:
kubectl rollout history deployment/my-deployment
This command displays the rollout history of the deployment named my-deployment.

kubectl rollout undo: It rolls back a deployment to a previous revision. For example:
kubectl rollout undo deployment/my-deployment
This command rolls back the deployment named my-deployment to the previous revision.

kubectl apply --dry-run: It simulates the apply of configuration without actually executing it. For example:
kubectl apply -f pod.yaml --dry-run=client
This command checks if the configuration in pod.yaml can be applied without actually applying it.

kubectl get pods -o wide: It retrieves pods with additional details including node name and IP address. For instance:
kubectl get pods -o wide
This command displays pods along with additional details such as the node they are running on and their IP addresses.

kubectl describe node: This command provides detailed information about a Kubernetes node. For example:
kubectl describe node my-node
This command describes the node named my-node, displaying detailed information including its capacity, allocatable resources, and conditions.

kubectl rollout pause: It pauses a rollout of a deployment. For instance:
kubectl rollout pause deployment/my-deployment
This command pauses the rollout of the deployment named my-deployment.

kubectl rollout resume: This command resumes a paused rollout of a deployment. For example:
kubectl rollout resume deployment/my-deployment
This command resumes the paused rollout of the deployment named my-deployment.

kubectl delete namespace: It deletes a Kubernetes namespace and all resources within it. For instance:
kubectl delete namespace my-namespace
This command deletes the namespace named my-namespace along with all resources within it.

kubectl get events: This command retrieves events from the cluster. For example:
kubectl get events
This command retrieves all events from the cluster, displaying information such as type, reason, and message.

kubectl get pods --show-labels: It displays additional labels associated with pods. For instance:
kubectl get pods --show-labels
This command displays pods along with all labels associated with them.

kubectl exec -it my-pod -- ls /app: This command executes a command (ls /app) inside a running container in a pod interactively. For example:
kubectl exec -it my-pod -- ls /app
This command lists the contents of the /app directory inside the pod named my-pod.

kubectl edit deployment: This command opens the deployment configuration in a text editor, allowing you to make changes. For example:
kubectl edit deployment/my-deployment
This command opens the configuration of the deployment named my-deployment in a text editor.

kubectl rollout restart: It restarts a rollout of a deployment by reapplying the current configuration. For instance:
kubectl rollout restart deployment/my-deployment
This command restarts the rollout of the deployment named my-deployment.

kubectl rollout status: This command checks the status of a rollout for a deployment. For example:
kubectl rollout status deployment/my-deployment
This command checks the status of the rollout for the deployment named my-deployment.

kubectl exec -it my-pod -- sh -c 'echo $ENV_VAR': This command executes a shell command (echo $ENV_VAR) inside a running container in a pod. For instance:
kubectl exec -it my-pod -- sh -c 'echo $ENV_VAR'
This command prints the value of the environment variable ENV_VAR inside the pod named my-pod.

kubectl get pods --field-selector=status.phase=Running: This command retrieves pods with a specific status phase, such as Running. For instance:
kubectl get pods --field-selector=status.phase=Running
This command retrieves all pods in the current namespace that are in the Running phase.

kubectl delete pod --grace-period=0 --force my-pod: It forcefully deletes a pod without waiting for the grace period. For example:
kubectl delete pod --grace-period=0 --force my-pod
This command forcefully deletes the pod named my-pod without waiting for the grace period to elapse.

kubectl describe service: This command provides detailed information about a Kubernetes service. For instance:
kubectl describe service my-service
This command describes the service named my-service, displaying detailed information including its endpoints and selectors.

kubectl get deployment -o yaml: This command retrieves deployments and outputs the result in YAML format. For instance:
kubectl get deployment -o yaml
This command retrieves all deployments in the current namespace and outputs the result in YAML format.

kubectl scale deployment: This command scales the number of replicas of a deployment. For example:
kubectl scale deployment/my-deployment --replicas=3
This command scales the deployment named my-deployment to have 3 replicas.

kubectl rollout history deployment: It displays the revision history of a deployment. For instance:
kubectl rollout history deployment/my-deployment
This command shows the revision history of the deployment named my-deployment.

kubectl rollout undo deployment --to-revision=: This command rolls back a deployment to a specific revision. For example:
kubectl rollout undo deployment/my-deployment --to-revision=3
This command rolls back the deployment named my-deployment to the third revision.

kubectl logs -f my-pod: This command streams the logs of a pod continuously. For instance:
kubectl logs -f my-pod
This command continuously streams the logs of the pod named my-pod to the terminal.

kubectl get svc: It retrieves information about services in the cluster. For example:
kubectl get svc
This command retrieves information about all services in the current namespace.

kubectl get pods -n : This command retrieves pods from a specific namespace. For instance:
kubectl get pods -n my-namespace
This command retrieves all pods from the namespace my-namespace.

kubectl delete -f pod.yaml: It deletes resources specified in a YAML file. For example:
kubectl delete -f pod.yaml
This command deletes the resources specified in the pod.yaml file.

kubectl rollout status deployment/my-deployment: This command checks the status of a deployment rollout. For instance:
kubectl rollout status deployment/my-deployment
This command checks the status of the rollout for the deployment named my-deployment.

kubectl exec -it my-pod -- /bin/bash: This command starts an interactive shell inside a pod. For example:
kubectl exec -it my-pod -- /bin/bash
This command opens an interactive shell (/bin/bash) inside the pod named my-pod, allowing you to execute commands within it.

kubectl rollout history deployment/my-deployment --revision=3: It displays details of a specific revision in the rollout history of a deployment. For instance:
kubectl rollout history deployment/my-deployment --revision=3
This command shows details of the third revision in the rollout history of the deployment named my-deployment.

kubectl rollout undo deployment/my-deployment --to-revision=2: This command rolls back a deployment to a specific revision. For example:
kubectl rollout undo deployment/my-deployment --to-revision=2
This command rolls back the deployment named my-deployment to the second revision.

kubectl logs my-pod --tail=100: This command retrieves the last 100 lines of logs from a pod. For example:
kubectl logs my-pod --tail=100
This command retrieves the last 100 lines of logs from the pod named my-pod.

kubectl get services -o wide: It retrieves services with additional details including node port and cluster IP. For instance:
kubectl get services -o wide
This command retrieves services along with additional details such as node port and cluster IP.

kubectl get pods --field-selector=status.phase!=Running: This command retrieves pods with a status phase other than Running. For example:
kubectl get pods --field-selector=status.phase!=Running
This command retrieves all pods in the current namespace that are not in the Running phase.

kubectl delete pod my-pod --force --grace-period=0: It forcefully deletes a pod without waiting for the grace period. For example:
kubectl delete pod my-pod --force --grace-period=0
This command forcefully deletes the pod named my-pod without waiting for the grace period to elapse.

kubectl describe service my-service: This command provides detailed information about a Kubernetes service. For instance:
kubectl describe service my-service
This command describes the service named my-service, displaying detailed information including its endpoints and selectors.

kubectl expose deployment my-deployment --type=LoadBalancer --port=80 --target-port=8080: It exposes a deployment as a service with a specified type, port, and target port. For example:
kubectl expose deployment my-deployment --type=LoadBalancer --port=80 --target-port=8080
This command exposes the deployment named my-deployment as a LoadBalancer service on port 80, targeting port 8080 on the pods.

kubectl get deployments -l app=my-app: This command retrieves deployments labeled with app=my-app. For example:
kubectl get deployments -l app=my-app
This command retrieves all deployments labeled with app=my-app.

kubectl rollout pause deployment/my-deployment: It pauses the rollout of a deployment. For instance:
kubectl rollout pause deployment/my-deployment
This command pauses the rollout of the deployment named my-deployment.

kubectl rollout resume deployment/my-deployment: This command resumes the rollout of a deployment. For example:
kubectl rollout resume deployment/my-deployment
This command resumes the paused rollout of the deployment named my-deployment.

kubectl logs my-pod --container=nginx: It retrieves logs from a specific container within a pod. For instance:
kubectl logs my-pod --container=nginx
This command retrieves logs from the container named nginx within the pod my-pod.

kubectl get pods --sort-by=.metadata.creationTimestamp: It retrieves pods sorted by creation timestamp. For instance:
kubectl get pods --sort-by=.metadata.creationTimestamp
This command retrieves all pods in the current namespace sorted by their creation timestamp in ascending order.

kubectl describe persistentvolumeclaim my-pvc: This command provides detailed information about a persistent volume claim. For example:
kubectl describe persistentvolumeclaim my-pvc
This command describes the persistent volume claim named my-pvc, displaying detailed information including its status and storage class.

kubectl rollout status deployment/my-deployment --watch: It continuously monitors the status of a deployment rollout. For instance:
kubectl rollout status deployment/my-deployment --watch
This command continuously monitors the status of the rollout for the deployment named my-deployment.

kubectl get pods --field-selector=status.phase=Pending: This command retrieves pods with a status phase of Pending. For example:
kubectl get pods --field-selector=status.phase=Pending
This command retrieves all pods in the current namespace that are in the Pending phase.

kubectl rollout restart deployment/my-deployment: This command restarts a rollout of a deployment by reapplying the current configuration. For example:
kubectl rollout restart deployment/my-deployment
This command restarts the rollout of the deployment named my-deployment.

kubectl label namespace my-namespace env=dev: It adds a label to a namespace. For instance:
kubectl label namespace my-namespace env=dev
This command adds the label env=dev to the namespace named my-namespace.

kubectl delete deployment my-deployment: This command deletes a deployment. For example:
kubectl delete deployment my-deployment
This command deletes the deployment named my-deployment.

kubectl get pods --namespace=my-namespace: It retrieves pods from a specific namespace. For instance:
kubectl get pods --namespace=my-namespace
This command retrieves all pods from the namespace my-namespace.

kubectl describe secret my-secret: This command provides detailed information about a secret. For example:
kubectl describe secret my-secret
This command describes the secret named my-secret, displaying detailed information including its type and data.

kubectl delete service my-service: It deletes a service. For instance:
kubectl delete service my-service
This command deletes the service named my-service.

kubectl get nodes: This command retrieves information about nodes in the cluster. For example:
kubectl get nodes
This command retrieves information about all nodes in the cluster.

kubectl rollout history deployment/my-deployment --revision=3: This command displays details of a specific revision in the rollout history of a deployment. For example:
kubectl rollout history deployment/my-deployment --revision=3
This command shows details of the third revision in the rollout history of the deployment named my-deployment.

kubectl top pods: It displays resource usage (CPU and memory) of pods in the cluster. For instance:
kubectl top pods
This command displays resource usage of all pods in the cluster.

kubectl explain pod: This command provides documentation about the Pod resource, including all its fields and their descriptions. For example:
kubectl explain pod
This command displays detailed documentation about the Pod resource.

kubectl delete namespace my-namespace: It deletes a namespace and all resources within it. For instance:
kubectl delete namespace my-namespace
This command deletes the namespace named my-namespace along with all resources within it.

kubectl get pv: This command retrieves information about persistent volumes in the cluster. For example:
kubectl get pv
This command retrieves information about all persistent volumes in the cluster.

kubectl rollout status deployment/my-deployment --timeout=2m: It checks the status of a rollout and waits for a specific timeout before exiting. For instance:
kubectl rollout status deployment/my-deployment --timeout=2m
This command checks the status of the rollout for the deployment named my-deployment and waits for a maximum of 2 minutes.

kubectl get secrets: It retrieves information about secrets in the cluster. For instance:
kubectl get secrets
This command retrieves information about all secrets in the current namespace.

kubectl rollout undo deployment/my-deployment --to-revision=2 --dry-run: It simulates rolling back a deployment to a specific revision without actually performing the rollback. For example:
kubectl rollout undo deployment/my-deployment --to-revision=2 --dry-run
This command simulates rolling back the deployment named my-deployment to the second revision without actually performing the rollback.

kubectl exec -it my-pod --container=my-container -- /bin/bash: This command starts an interactive shell inside a specific container within a pod. For example:
kubectl exec -it my-pod --container=my-container -- /bin/bash
This command opens an interactive shell (/bin/bash) inside the container named my-container within the pod named my-pod.

kubectl describe persistentvolume my-pv: This command provides detailed information about a persistent volume. For example:
kubectl describe persistentvolume my-pv
This command describes the persistent volume named my-pv, displaying detailed information including its capacity and access modes.

kubectl get events --sort-by=.metadata.creationTimestamp: This command retrieves events sorted by creation timestamp. For example:
kubectl get events --sort-by=.metadata.creationTimestamp
This command retrieves all events in the current namespace sorted by their creation timestamp in ascending order.

kubectl describe ingresses.extensions: It provides detailed information about an Ingress resource. For instance:
kubectl describe ingresses.extensions
This command describes all Ingress resources in the current namespace, displaying detailed information about each Ingress.

kubectl rollout undo deployment/my-deployment --dry-run=client: It simulates rolling back a deployment to the previous revision without actually performing the rollback. For example:
kubectl rollout undo deployment/my-deployment --dry-run=client
This command simulates rolling back the deployment named my-deployment to the previous revision without actually performing the rollback.

kubectl scale deployment/my-deployment --replicas=5 --record: This command scales the number of replicas of a deployment to 5 and records the change. For example:
kubectl scale deployment/my-deployment --replicas=5 --record
This command scales the deployment named my-deployment to have 5 replicas and records the change.

kubectl delete secret my-secret: It deletes a secret. For instance:
kubectl delete secret my-secret
This command deletes the secret named my-secret.

kubectl get ingress: This command retrieves information about Ingress resources in the cluster. For example:
kubectl get ingress
This command retrieves information about all Ingress resources in the current namespace.
Get the commands related with configuration:
- $kubectl config -h
Context- Multiple cluster
- Get the list of clusters.
- How to set default cluster.

Pods crashing and restarting with CrashLoopBackOff
- Issue could be related with resources are not available to run pod
Pods crashing and restarting with ImagePullBackOff
- Usually it happend if image cannot be pulled.
- $kubectl describe pod podname (check error)
- $kubectl edit pod podname (it will open editor like, make correction)
code
- code
  - code
  - code
code
- code
  - code
  - code
code
- code
  - code
  - code
code
- code
  - code
  - code

Projects

Configuration of kubernetes cluster, jenkins, sonarqueb, nexus, deployed

Phase 1: create infrastructure: Ubuntu 22.04 LTS, min 4GB, 2 CPU, 30 GB Disk.

Create 3 VMS for Kubernetes Cluster (1 Master & 2 Nodes), Scan for Vulnerabilities and Issues.

allow the following ports:

SMTP 25
- Custom TCP 3000-10000
- HTTP 80
- HTTPS 443
- SSH 22
- Custom TCP 6443
- SMTPS 465 (Email notification to be send to Gmail Account)
- Custom TCP 30000 - 32767 (This range is used for deployment of application in kubernetes)
Ensure you have root access on both the master and workder nodes.
Ensure Swapoff

Step 1: run the script on both master and workder nodes. or You can run each command one by one.

#!/bin/bash

# Update package lists
sudo apt-get update

# Install Docker
sudo apt install docker.io -y
sudo chmod 666 /var/run/docker.sock

# Install dependencies for Kubernetes
sudo apt-get install -y apt-transport-https ca-certificates curl gnupg
sudo mkdir -p -m 755 /etc/apt/keyrings

# Update package lists again
sudo apt update

# Install Kubernetes components
sudo apt install -y kubeadm=1.28.1-1.1 kubelet=1.28.1-1.1 kubectl=1.28.1-1.1

$vi 1.sh (paste script)
$sudo chmod +x 1.sh
$./1.sh

Step 2: Setting up Master node: Run the script on master node only

#!/bin/bash

# Initialize Kubernetes master
sudo kubeadm init --pod-network-cidr=192.168.0.0/16

# Configure kubectl for current user
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

# Deploy Calico network plugin
kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml

# Deploy NGINX Ingress Controller
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.49.0/deploy/static/provider/baremetal/deploy.yaml

$vi 2.sh (paste script)
$sudo chmod +x 2.sh
$./2.sh

Step3: run kubeadm join command on worker nodes to join the master node.
- kubeadm join 172.31.9.190:6443 --token ls529u.ykksgopsic7kuh9h \
  --discovery-token-ca-cert-hash sha256:fe1d1adc7057d4c48dd6ff8eb41498b18d12e7ab3b5d7f25a346bcb504a567c1
on master node run $kubectl get nodes
Step 4: Scanning Kubernetes Cluster:
- Kubeaudit and Trivy can be use for scanning kubernetes.
- Go to https://github.com/Shopify/kubeaudit/releases
- copy link address of version: kubeaudit_0.22.1_linux_amd64.tar.gz
- $wget https://github.com/Shopify/kubeaudit/releases/download/v0.22.1/kubeaudit_0.22.1_linux_amd64.tar.gz
- $tar -xvzf kubeaudit_0.22.1_linux_amd64.tar.gz
- $sudo mv kubeaudit /usr/local/bin/
- $kubeaudit all (it will scan the whole cluster and give errors, there might be some errors because RBAC is not setup and service account is not created etc..)

Create a VM for Jenkins Tools:
- Update apt respository and install JDK.
  - $sudo apt-get update
  - $sudo apt install openjdk-17-jre-headless (install java if it is not installed)
- Download: In google search jenkis download and click jenkins download and deployment(https://www.jenkins.io/download/), click Ubuntu/Debian and copy the url. (Jenkins Debian Packages)
  - #wget -O /usr/share/keyrings/jenkins-keyring.asc \https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
  - #
```
echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \
    https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
    /etc/apt/sources.list.d/jenkins.list > /dev/null
```
  - $apt-get install jenkins
  - $sudo systemctl start jenkins
  - $ sudo systemctl enable jenkins
  - $sudo systemctl status jenkins
Create a VM for SonarQube Server
- $sudo apt update
- $sudo apt install openjdk-17-jre-headless
- Install Docker (it can be installed with sudo apt install docker.io but it did not install all plugins, ce-certificate etc.) it is recommended to install by
- Go to google and search install docker on ubuntu (https://docs.docker.com/engine/install/ubuntu/)
- copy the apt's repository, open a file $vi docker.sh (paste it), $sudo chmod +x docker.sh $./docker.sh
- # Add Docker's official GPG key:
  sudo apt-get update
  sudo apt-get install ca-certificates curl
  sudo install -m 0755 -d /etc/apt/keyrings
  sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
  sudo chmod a+r /etc/apt/keyrings/docker.asc
  
  # Add the repository to Apt sources:
  echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  sudo apt-get update
- Install docker
- $sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
- Check docker running
- $sudo docker run hello-world
- Assign permission to other users
- $sudo chmod 666 /var/run/docker.sock
- Install sonarqube:
- $docker run -d --name sona -p 9000:9000 sonarqube:lts-community
- Access:
- http://ip:9000:9000
Create a VM for Nexus Server with min 4GB RAM, 2CPU, 20GB Disk.
- $sudo apt update
- $sudo apt install openjdk-17-jre-headless
- Install Docker (it can be installed with sudo apt install docker.io but it did not install all plugins, ce-certificate etc.) it is recommended to install by
- Go to google and search install docker on ubuntu (https://docs.docker.com/engine/install/ubuntu/)
- copy the apt's repository, open a file $vi docker.sh (paste it), $sudo chmod +x docker.sh $./docker.sh
- # Add Docker's official GPG key:
  sudo apt-get update
  sudo apt-get install ca-certificates curl
  sudo install -m 0755 -d /etc/apt/keyrings
  sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
  sudo chmod a+r /etc/apt/keyrings/docker.asc
  
  # Add the repository to Apt sources:
  echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
  $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
  sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
  sudo apt-get update
- Install docker
- $sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
- Check docker running
- $sudo docker run hello-world
- Assign permission to other users
- $sudo chmod 666 /var/run/docker.sock
- Install Nexus
- $docker run -it --name nexus3 -p 8081:8081 sonatype/nexus3 (if no tag given it will install latest, it will run in interactive mode so can view progress)
- Access:
- http://ip:8081
Create a VM for Monitoring

Phase 2: Git Repository:
- Login to Github
  - new repository: name=Boardgame, private, create repository.
  - Install gitbash in local computer: visit https://git-scm.com/downloads
  - copy url : https://github.com/stardistributors/Boardgame.git
  - Go to local computer where you have source code of Boardgame: right click and open gitbash (access needed)
  - c:/git clone https://github.com/stardistributors/Boardgame.git
  - select sign in: select option token
    - generate token in github, click on profile/settings/developer settings/personal access token/token(classic), select required repo and generate.
  - push source code
Phase 3: Setup CICD
- CICD - Jenkins:
  - Install the following plugins
    - eclipse temurin installer
      config file provider
      Pipeline maven integration
      sonarQube Scanner
      Docker
      Docker pipeline
    - Docker Build Step
      kubernetes
      kubernetes CLI
      kubernetes credentials
      Kubernetes client API
    - maven integration
  - Configure plugins: go to tools
    - jdk: Name=jdk17, automatically, from adoptium.net , version=jdk-17.09+9
    - SonarQube Scanner= Name=sonar, version=5.0.1.3006,
    - Maven Installtion= Name=maven3, Install Automatically=install from apache, version=3.6.1
    - Docker Installation = Name=docker, install automatically=download from docker, version = latest
  - Create CICD Pipeline
    - new item, name = Boardgame, pipeline
  - Best Practice
    - Discard old builds (max number of old builds=2)
    - select hello-world script and make necessary changes.
    - click here for complete script.
      
      trivy install
      
      File System Scan: scan for vulnarability and find out any critical data in code, Trivy plugin is not availble so it need to be installed, install it in jenkins server.
      
      run this command in jenkins server. $sudo vi trivy.sh $sudo chmod +x trivy.sh $./trivy.sh
      
      sudo apt-get install wget apt-transport-https gnupg lsb-release
      wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
      echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
      sudo apt-get update
      sudo apt-get install trivy -y
      
      or run this only(if above script gives an error)
      
      wget https://github.com/aquasecurity/trivy/releases/download/v0.18.3/trivy_0.18.3_Linux-64bit.deb
      sudo dpkg -i trivy_0.18.3_Linux-64bit.deb
    - Sonarqube webhook script for Quality Gate:
      
      script { waitForQualityGate abortPipeline: false, credentialsId: '----' }
    - Publish Artifact to nexus
      
      Add repository URL in pom.xml file
      
      go to pom.xml file and add
      
      <distributionManagement>
      
      <repository>
      
      <id>maven-releases</id>
      
      <url>http://ip:8081/repository/maven-releases/</url>
      
      </repository>
      
      <snapshotRepository>
      
      <id>maven-snapshots</id>
      
      <url>http://ip:8081/repository/maven-snapshots/</url>
      
      </snapshotRepository>
      
      </distributionManagement>
      
      commit changes and save
      
      now add the credentials:
      
      go to jenkins/manage jenkins/managed files: add new config,
      
      select global maven settings.xml
      
      Id=global settings
      
      search server and remove --> and paste in earlier lines and add server details
      
      <server>
      <id>maven-releases</id>
      <username>admin</username>
      <password>Trustu786</password>
      </server>
      
      <server>
      <id>maven-snapshots</id>
      <username>admin</username>
      <password>Trustu786</password>
      </server>
      
      open pipeline syntax and select withmaven:provide maven environment
      
      maven=maven3
      
      jdk=jdk17
      
      globalmavensettings Config = myglobalSettings
      
      Generate script.
      
      open pipeline syntax and select with docker registry: Sets up Docker registry endpoint
      
      Docker Registry URL =
      
      Registry credentials= +add: name=aziz27uk, password = Yezdani6! (docker hub credentials)
      
      Docker installation = docker
      
      generate script
      
      Create service account for docker deployment.(RBAC)
      
      go to https://github.com/jaiswaladi246/EKS-Complete/blob/main/Steps-eks.md
      
      copy creating service account.
      
      Go to master node and create vi svc.yaml
      
      paste the content.
  - Security Measures
  - Deployment of Application
  - Mail notification of pipeline status
Phase 4: Monitoring
- System Level Monitoring
  - Application Level Monitoring

Full Stack BoardGame
- click for details
  - code
  - code
Microservice using multi branch pipeline
- The entire project is divided into 11 micro services parts, modification of any part will be easy, it can independently be deployed and cannot effect to other service.
  - Github repository: There are 13 different branches and each branch represents one service. https://github.com/stardistributors/Microservice.git
    - main: it contain deployment-service.yml file which is use to deploy the application on EKS cluster.
    - infra-steps: branch is responsible to setup EKS setup on AWS.
    - adservice:
    - cartservice:
    - checkoutservice:
    - currencyservice:
    - emailservice:
    - frontend:
    - loadgenerator:
    - paymentservice:
    - productcatalogservice:
    - recommendationservice:
    - shippingservice:
  - Step1: Infrastructure creation on AWS:
    - Create ubuntu 20.04 LTS, t2.large, 25 GB Disk
    - ports open
      
      25 - SMTP
      
      3000 - 10000 (application services runs on these ports)
      
      80 - HTTP
      
      443 -HTTPS
      
      22 - SSH
      
      6443 - Custom
      
      465 - SMTPS (google)
      
      27017 - Custom
      
      30000-32767 Custom
    - To access EKS cluster, define the following user in IAM.
      
      create eks user and attach the following policies:
      
      AmazonEC2FullAcess
      
      AmazonEFSCSIDriverPolicy
      
      AmazonEKS_CNI_Policy
      
      AmzonEKSClusterPolicy
      
      AmazonEKSWorkerNodePolicy
      
      AWSCloudFormationFullAccess
      
      eks-req
      
      IAMFullAccess
    - Configure EKS cluster
  - code
  - code
EKS cluster setup & Deployment of 10 Tier Microservice Application
- Step 1: Create a user in AWS IAM, create a custom policy and default policies attach to user.
  - Create a user:
    - Log in to the AWS Management Console.
      
      Navigate to the IAM dashboard.
      
      Click on "Users" in the left sidebar.
      
      Click on the "Add user" button. IAM users are created in global Region.
      
      Enter a username of your choice.
      
      Provide user access to the AWS Management Console: select
      
      select iam user, set a password for the user.
      
      select assign polices directly to user:
      
      search the following policies and attach it to user.
    - Search the default policies
      
      AmazonEC2FullAccess
      
      AmazonEKS_CNI_Policy
      
      AmazonEKSClusterPolicy
      
      AmazonEKSWorkerNodePolicy
      
      AWSCloudFormationFullAccess
      
      IAMFullAccess
      
      star-eks-policy (custom policy to allow visual editor)
    - Create a custom policy:
      
      click on create policy: select json and enter the following code
      
      {
      "Version": "2012-10-17",
      "Statement": [
      {
      "Sid": "VisualEditor0",
      "Effect": "Allow",
      "Action": "eks:*",
      "Resource": "*"
      }
      ]
      }
      
      save the policy: star-eks-policy (select this policy as well)
    - next and create user: https://533267324249.signin.aws.amazon.com/console
    - Create Access keys:
      
      Go to user created (eks-user)/security credentials/ access keys/ create access keys/command line interface and download both the keys .csv file.
  - Step 2: Create a VM and run the script to communicate with EKS cluster, Install AWSCLI, kubectl, and eksctl
    - create ubuntu, 20.04, t2Large, 20GB disk
    - access vm through mobaexterm.
    - $sudo apt update
    - create a script and paste the commands
    - $vi install_tools.sh
    - #!/bin/bash # Install AWSCLI curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip" sudo apt install -y unzip unzip awscliv2.zip sudo ./aws/install # Install kubectl curl -o kubectl https://amazon-eks.s3.us-west-2.amazonaws.com/1.19.6/2021-01-05/bin/linux/amd64/kubectl chmod +x ./kubectl sudo mv ./kubectl /usr/local/bin kubectl version --short --client # Install eksctl curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp sudo mv /tmp/eksctl /usr/local/bin eksctl version
    - $sudo chmod +x install_tools.sh
    - $./install_tools.sh
  - Step 3: Connect to AWS using CLI with user eks-user
    - open mobaexterm and conenct to VM with user ubuntu
    - $aws configure
    - AWS access key Id = paste it from downloaded key of user (eks-user)
    - AWS secret key = paste it
    - Default region name = eu-west-2 (region where VM is created)
    - Default output format =
    - connected to AWS VM
  - Step 4: Create EKS cluster: There are many wasy to create EKS cluster, go to aws console and create or create a user or root account and assign roles and copy and paste the below command (will take 10 minutes), cloudformation will create cluster.
    - eksctl create cluster --name=star-eks \
      --region=eu-west-2 \
      --zones=eu-west-2b,eu-west-2c \
      --without-nodegroup
    - EKS cluster "star-eks" in "eu-west-2" region is ready, created without nodegroup which is workernode. only master node is created, it will be created separately.
    - eksctl utils associate-iam-oidc-provider (open Id connect provider) paste the following
      
      eksctl utils associate-iam-oidc-provider \
      --region eu-west-2 \
      --cluster star-eks \
      --approve
    - Create nodegroup (workdernodes)
      
      eksctl create nodegroup --cluster=star-eks \
      --region=eu-west-2 \
      --name=node2 \
      --node-type=t3.medium \
      --nodes=3 \
      --nodes-min=2 \
      --nodes-max=4 \
      --node-volume-size=20 \
      --ssh-access \
      --ssh-public-key=key-london \
      --managed \
      --asg-access \
      --external-dns-access \
      --full-ecr-access \
      --appmesh-access \
      --alb-ingress-access
      
      in the above node name = node2 of t3.medium will be created, 3 nodes will be created and at any time min 2 nodes will be available and if required it goes to 4 by autoscaling.
      
      ssh-public-key = key-london (key used to create vm)
      
      cloudformation will create nodegroup (worker nodes).
  - Step 5: check number of nodes
    - $kubectl get nodes (there will be 3 worker nodes)
  - Step 6: Open Inbound traffic
    - Go to AWS services/eks/star-eks/Networking/cluster security group/select communication between the control plane and worker nodes /edit inbound rules and define all traffic. save it
  - Step 7: Setup jenkins to deploy application to kubernetes cluster
    - $sudo apt update
    - $sudo apt install openjdk-17-jre-headless
    - $sudo vi jenkins.sh
    - sudo wget -O /usr/share/keyrings/jenkins-keyring.asc \
      https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
      echo "deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc]" \
      https://pkg.jenkins.io/debian-stable binary/ | sudo tee \
      /etc/apt/sources.list.d/jenkins.list > /dev/null
      sudo apt-get update
      sudo apt-get install jenkins
    - $sudo chmod +x jenkins.sh
    - $./jenkins.sh
    - Access on browser: http://publicIP:8080
    - Install the following plugins:
      
      Eclipse Temurin installer
      
      kubernetes
      
      kubernetes CLI
      
      Docker
      
      maven integration
      
      the following are dependent plugins which is also installed
      
      kubernetes client API
      
      Authentication token API
      
      kubernetes credentials
      
      metrics
      
      cloud statistics
      
      docker commons
      
      Apache HttpComponents Client 5xAPI
      
      Docker API
      
      Loading Plugin Extenstions
  - Step 8: create service account, role, bind role with service account, generate token
    - Create namespace
      
      $kubectl create namespace devops
    - Validate the yaml code on https://www.yamllint.com/
    - Create service account
      
      $vi service_account.yml (paste the following code)
      
      apiVersion: v1
      kind: ServiceAccount
      metadata:
      name: jenkins
      namespace: devops
      
      $kubectl apply -f service_account.yml
    - Create Role:
      
      apiVersion: rbac.authorization.k8s.io/v1
      kind: Role
      metadata:
      name: app-role
      namespace: devops
      rules:
      - apiGroups:
      - ""
      - apps
      - autoscaling
      - batch
      - extensions
      - policy
      - rbac.authorization.k8s.io
      resources:
      - pods
      - secrets
      - componentstatuses
      - configmaps
      - daemonsets
      - deployments
      - events
      - endpoints
      - horizontalpodautoscalers
      - ingress
      - jobs
      - limitranges
      - namespaces
      - nodes
      - pods
      - persistentvolumes
      - persistentvolumeclaims
      - resourcequotas
      - replicasets
      - replicationcontrollers
      - serviceaccounts
      - services
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
    - Bind Role with Service Account
      
      apiVersion: rbac.authorization.k8s.io/v1
      kind: RoleBinding
      metadata:
      name: app-rolebinding
      namespace: webapps
      roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: app-role
      subjects:
      - namespace: webapps
      kind: ServiceAccount
      name: jenkins
    - Generate Token using service account in the namespace
      
      apiVersion: v1
      kind: Secret
      type: kubernetes.io/service-account-token
      metadata:
      name: mysecretname
      annotations:
      kubernetes.io/service-account.name: jenkins
      
      $
    - To view secret file run
      
      $kubectl -n devops describe secret mysecretnam
      
      copy the token which will be use for authentication.
  - Step 9: Install docker
    - $sudo apt install docker.io
    - $sudo chmod 666 /var/run/docker.sock or $sudo usermod -aG docker jenkins & $sudo newgrp docker
    - $systemctl restart docker
    - $systemctl enable docker
  - Step 10: create a pipeline
    - jenkins/new item/ name = 10-Tier, pipeline
    - Groovy script: click pipeline syntax to open snippet generator
      
      connection between jenkins and kubernetes: select withKubeConfig: Configure Kubernetes CLI (kubectl)
      
      Credentials: click add, secret text and paste the token which ws copied from secret file.
  - Step 11: run the following command to create config file
    - $aws eks update-kubeconfig --region eu-west-2 --name star-eks
secretsanta-generator
- code
  - code
  - code
Python Webapp
- code
  - code
  - code
Shopping Cart
- - Phase 1: create infrastructure: Ubuntu 22.04 LTS, min 16GB, 2 CPU, 100 GB Disk.
    
    Create 2 VMS (ubuntu) for Kubernetes Cluster on premises (1 Master & 1 Node)
    
    First VM for kubernetes master node- 2CPU, 16 GB RAM, 50GB Disk.
    
    Second VM for kubernetes Worker1 node - 1CPU, 8GB RAM, 30GB Disk.
    
    Third VM for Jenkins, Sonar, Nexus, OWASP Dependency check, Trivy - 4CPU, 32GB RAM, 100 GB Disk.
    
    allow the following ports:
    
    SMTP 25
    
    Custom TCP 3000-10000
    
    HTTP 80
    
    HTTPS 443
    
    SSH 22
    
    Custom TCP 6443
    
    SMTPS 465 (Email notification to be send to Gmail Account)
    
    Custom TCP 30000 - 32767 (This range is used for deployment of application in kubernetes)
    
    Perform Step-1 to Step-7 on all nodes.
    
    Step 1 Prerequisite:
    
    Minimal Install Ubuntu 22.04, Create 2 ubuntu VM one master node and 1 worker node, Download ubuntu from https://ubuntu.com/download/desktop (20.04 LTS)
    
    Sudo user with admin rights: $sudo su
    
    Internet connectivity
    
    Step 2: Assing IP and Set Hostname, hosts file
    
    Manual IP in Ubuntu 192.168.171.50 (51), 255.255.255.0, GW:192.168.171.2
    
    $sudo hostnamectl set-hostname master, $sudo hostnamectl set-hostname worker1.
    
    $exec bash
    
    $sudo vi /etc/hosts (add IP & hostname of all nodes, 192.168.171.50 master, 192.168.171.51 worker1) save and exit.
    
    Step 3 : Disable Swap and Kernel Parameters
    
    $sudo swapoff -a
    
    $sudo sed -i '/ swap / s/^$.*$$/#\1/g' /etc/fstab
    
    $sudo tee /etc/modules-load.d/containerd.conf <<EOF
    overlay
    br_netfilter
    EOF
    
    $sudo modprobe overlay
    
    $sudo modprobe br_netfilter
    
    run tee command
    
    $sudo tee /etc/sysctl.d/kubernetes.conf <<EOT
    net.bridge.bridge-nf-call-ip6tables = 1
    net.bridge.bridge-nf-call-iptables = 1
    net.ipv4.ip_forward = 1
    EOT
    
    Reload the above changes
    
    $sudo sysctl --system
    
    Step 4: Install Containerd Runtime (Docker)
    
    First install dependencies for containerd runtime:
    
    $sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates
    
    Enable Docker Repository:
    
    $sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg
    
    $sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
    
    Run the following apt command to install containerd
    
    $sudo apt update
    
    sudo apt install -y containerd.io
    
    Step 5: Configure containerd so that it starts using systemd as cgroup
    
    $containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
    
    $sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml
    
    Restart & Enable Containerd
    
    $sudo systemctl restart containerd
    
    $sudo systemctl enable containerd
    
    Step 6: Kubernetes package is not available in the default Ubuntu 22.04 package repositories. So we need to add Kubernetes repository. run following command to download public signing key,Step 6: Add APT repository for Kubernetes:
    
    $curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
    
    Run the following command echo command to add kubernetes apt repository.
    
    $echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
    
    Kubernetes v1.28 was available, replace this version with new higher version if available.
    
    Step 7: Install Kubectl, Kubeadm, Kubelet
    
    $ sudo apt update
    
    $ sudo apt install -y kubelet kubeadm kubectl
    
    $ sudo apt-mark hold kubelet kubeadm kubectl
    
    Perform Step 8 on Master node only
    
    Step 8: Install Kubernetes Cluster
    
    $sudo kubeadm init --control-plane=master
    
    After the initialization is complete, you will see a message with instructions on how to join worker nodes to the cluster. Make a note of the kubeadm join command for future reference.
    
    kubeadm join master:6443 --token sprb01.byn0v48rbmwodr8c \
    --discovery-token-ca-cert-hash sha256:46f3a54131c98e4d934e18aa82629395ea800607834e92d97bca607efaa5fec8
    
    So, to start interacting with cluster, run following commands on the master node,
    
    $ mkdir -p $HOME/.kube
    
    $ sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
    
    $ sudo chown $(id -u):$(id -g) $HOME/.kube/config
    
    run following kubectl commands to view cluster and node status:
    
    $ kubectl cluster-info
    
    $ kubectl get nodes
    
    Step 9: Join worker nodes to the Cluster.
    
    Run on each worker node the following command to join cluster.
    
    kubeadm join master:6443 --token sprb01.byn0v48rbmwodr8c \
    --discovery-token-ca-cert-hash sha256:46f3a54131c98e4d934e18aa82629395ea800607834e92d97bca607efaa5fec8
    
    Step 10: check cluster nodes on master node
    
    $kubectl get nodes (it will show all nodes)
    
    nodes status is 'Not Ready', so to make it active. must install CNI (Container Network Interface) or network add-on plugs like Calico, Flannel and Wwave-net.
    
    Step 11: Install CNI (Container Network Interface) or network add-on plugs like Calico, Flannel and Wwave-net.
    
    $ kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/manifests/calico.yaml
    
    Verify the status of pods in kube-system namespace:
    
    $ kubectl get pods -n kube-system
    
    $kubectl get nodes
    
    Create a VM for Jenkins Tools (install sonrqube+trivy+nexus on same vm or separately):
    
    Update apt respository and install JDK.
    
    $sudo apt-get update
    
    $sudo apt install openjdk-17-jre-headless (install java if it is not installed)
    
    Download: In google search jenkis download and click jenkins download and deployment(https://www.jenkins.io/download/), click Ubuntu/Debian and copy the url. (Jenkins Debian Packages)
    
    #wget -O /usr/share/keyrings/jenkins-keyring.asc \https://pkg.jenkins.io/debian-stable/jenkins.io-2023.key
    
    #
    echo deb [signed-by=/usr/share/keyrings/jenkins-keyring.asc] \ https://pkg.jenkins.io/debian-stable binary/ | sudo tee \ /etc/apt/sources.list.d/jenkins.list > /dev/null
    
    $apt-get install jenkins
    
    $sudo systemctl start jenkins
    
    $ sudo systemctl enable jenkins
    
    $sudo systemctl status jenkins
    
    Create a VM for SonarQube Server
    
    $sudo apt update
    
    $sudo apt install openjdk-17-jre-headless
    
    Install Docker (it can be installed with sudo apt install docker.io but it did not install all plugins, ce-certificate etc.) it is recommended to install by
    
    Go to google and search install docker on ubuntu (https://docs.docker.com/engine/install/ubuntu/)
    
    copy the apt's repository, open a file $vi docker.sh (paste it), $sudo chmod +x docker.sh $./docker.sh
    
    # Add Docker's official GPG key:
    sudo apt-get update
    sudo apt-get install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
    
    # Add the repository to Apt sources:
    echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    sudo apt-get update
    
    Install docker
    
    $sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    
    Check docker running
    
    $sudo docker run hello-world
    
    Assign permission to other users
    
    $sudo chmod 666 /var/run/docker.sock
    
    Install sonarqube:
    
    $docker run -d --name sona -p 9000:9000 sonarqube:lts-community
    
    Access:
    
    http://ip:9000:9000
    
    Create a VM for Nexus Server with min 4GB RAM, 2CPU, 20GB Disk.
    
    $sudo apt update
    
    $sudo apt install openjdk-17-jre-headless
    
    Install Docker (it can be installed with sudo apt install docker.io but it did not install all plugins, ce-certificate etc.) it is recommended to install by
    
    Go to google and search install docker on ubuntu (https://docs.docker.com/engine/install/ubuntu/)
    
    copy the apt's repository, open a file $vi docker.sh (paste it), $sudo chmod +x docker.sh $./docker.sh
    
    # Add Docker's official GPG key:
    sudo apt-get update
    sudo apt-get install ca-certificates curl
    sudo install -m 0755 -d /etc/apt/keyrings
    sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc
    sudo chmod a+r /etc/apt/keyrings/docker.asc
    
    # Add the repository to Apt sources:
    echo \
    "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \
    $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
    sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
    sudo apt-get update
    
    Install docker
    
    $sudo apt-get install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
    
    Check docker running
    
    $sudo docker run hello-world
    
    Assign permission to other users
    
    $sudo chmod 666 /var/run/docker.sock
    
    Install Nexus
    
    $docker run -it --name nexus3 -p 8081:8081 sonatype/nexus3 (if no tag given it will install latest, it will run in interactive mode so can view progress)
    
    Access:
    
    http://ip:8081
    
    Create a VM for Monitoring
  - Phase 2: Git Repository:
    
    Login to Github
    
    repository: name=shopping-cart. (https://github.com/stardistributors/shopping-cart.git)
  - Phase 3: Setup CICD
    
    CICD - Jenkins:
    
    Install the following plugins
    
    eclipse temurin installer
    config file provider
    maven integration
    pipeline maven integration
    sonarQube Scanner
    Docker
    Docker pipeline
    Docker Build Step
    kubernetes
    kubernetes CLI
    kubernetes credentials
    Kubernetes client API
    
    Configure plugins: go to tools
    
    jdk: Name=jdk17, automatically, from adoptium.net , version=jdk-17.09+9
    
    SonarQube Scanner= Name=sonar-scanner, version=5.0.1.3006,
    
    Maven Installtion= Name=maven3, Install Automatically=install from apache, version=3.6.1
    
    Docker Installation = Name=docker, install automatically=download from docker, version = latest
    
    Create CICD Pipeline
    
    new item, name = shopping-cart, pipeline
    
    Explanation of groovy script stages:
    
    Best Practice
    
    Discard old builds (max number of old builds=2)
    
    click here for complete script.
    
    trivy install
    
    File System Scan: scan for vulnarability and find out any critical data in code, Trivy plugin is not availble so it need to be installed, install it in jenkins server.
    
    run this command in jenkins server. $sudo vi trivy.sh $sudo chmod +x trivy.sh $./trivy.sh
    
    sudo apt-get install wget apt-transport-https gnupg lsb-release
    wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
    echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
    sudo apt-get update
    sudo apt-get install trivy -y
    
    or run this only(if above script gives an error)
    
    wget https://github.com/aquasecurity/trivy/releases/download/v0.18.3/trivy_0.18.3_Linux-64bit.deb
    sudo dpkg -i trivy_0.18.3_Linux-64bit.deb
    
    Publish Artifact to nexus
    
    Add repository URL in pom.xml file
    
    go to pom.xml file and add
    
    <distributionManagement>
    <repository>
    <id>maven-releases</id>
    <url>http://192.168.171.52:8081/repository/maven-releases/</url>
    </repository>
    <snapshotRepository>
    <id>maven-snapshots</id>
    <url>http://192.168.171.50:8081/repository/maven-snapshots/</url>
    </snapshotRepository>
    </distributionManagement>
    
    commit changes and save
    
    now add the credentials:
    
    go to jenkins/manage jenkins/managed files: add new config,
    
    select global maven settings.xml
    
    Id=global settings
    
    search server and remove --> and paste in earlier lines and add server details
    
    <server>
    <id>maven-releases</id>
    <username>admin</username>
    <password>Trustu786</password>
    </server>
    <server>
    <id>maven-snapshots</id>
    <username>admin</username>
    <password>Trustu786</password>
    </server>
    
    open pipeline syntax and select withmaven:provide maven environment
    
    maven=maven3
    
    jdk=jdk17
    
    globalmavensettings Config = myglobalSettings
    
    Generate script.
    
    open pipeline syntax and select with docker registry: Sets up Docker registry endpoint
    
    Docker Registry URL = (keep blank if docker hub registry is public)
    
    Registry credentials= +add: name=aziz27uk, password = Yezdani6! (docker hub credentials)
    
    Docker installation = docker
    
    generate script
    
    Create service account for docker deployment.(RBAC)
    
    go to https://github.com/stardistributors/shopping-cart/blob/main/Steps-eks.md
    
    copy creating service account.
    
    Go to master node and create $vi svc-account.yaml (paste the code)
    
    apiVersion: v1 kind: ServiceAccount metadata: name: jenkins namespace: webapps
    
    $kubectl apply -f svc-account.yml
    
    copy create role
    
    $vi role.yml (paste the code)
    
    $kubectl apply -f role.yml
    
    copy bind the role to service account
    
    $vi bind.yml (paste the code)
    
    $kubectl apply -f bind.yml
    
    Generate token using service account in the namespace, copy code
    
    apiVersion: v1
    kind: Secret
    type: kubernetes.io/service-account-token
    metadata:
    name: mysecretname
    annotations:
    kubernetes.io/service-account.name: jenkins
    
    $vi secret.yml (paste the above code)
    
    First create a namespace: $kubectl create namespace webapps
    
    $kubectl apply -f secret.yml -n webapps (in the code namespace has not been define so define it in command)
    
    Get the details of secret
    
    $kubectl -n webapps describe secret mysecretname (copy token which is used for authentication to deploy application to kubernetes)
    
    jenkins/global credentials/secret text, paste the token, name=k8-auth
    
    generate code using withKubeConfig:Cofigure Kubernetes CLI (kubectl), find url from $cd root, $cd .kube, $cat config (get server url, name) use these information in generating code
    
    run Build now
    
    Mail notification of pipeline status
  - Phase 4: Monitoring
  - Access: open browser http://192.168.171.50:30813 (check console output for port number) deployment stuck in deploying as there is not enough resources on worker1 node.
  - Taint disabled: worker1 has not suffecient space to deploy application, so taint need to disable on master node so pod can be deployed on master node.
    - Check taint status: $kubectl describe node master
    - $kubectl taint nodes --all node-role.kubernetes.io/control-plane-

Deploying a MongoDB and a web-based MongoDB management tool called "mongo-express"

apiVersion: v1
kind: ConfigMap
metadata:
  name: mongodb-configmap
data:
  db_host: mongodb-service

apiVersion: v1
kind: Secret
metadata:
  name: mongodb-secret
type: Opaque
data:
  username: dXNlcm5hbWU=
  password: cGFzc3dvcmQ=

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongodb
  labels:
    app: mongodb
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongodb
  template:
    metadata:
      labels:
        app: mongodb
    spec:
      containers:
      - name: mongodb
        image: mongo
        ports:
        - containerPort: 27017
        env:
        - name: MONGO_INITDB_ROOT_USERNAME
          valueFrom:
            secretKeyRef:
              name: mongodb-secret
              key: username
        - name: MONGO_INITDB_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: mongodb-secret
              key: password

apiVersion: v1
kind: Service
metadata:
  name: mongodb-service
spec:
  selector:
    app: mongodb
  ports:
    - protocol: TCP
      port: 27017
      targetPort: 27017

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mongo-express
  labels:
    app: mongo-express
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mongo-express
  template:
    metadata:
      labels:
        app: mongo-express
    spec:
      containers:
      - name: mongo-express
        image: mongo-express
        ports:
        - containerPort: 8081
        env:
        - name: ME_CONFIG_MONGODB_ADMINUSERNAME
          valueFrom:
            secretKeyRef:
              name: mongodb-secret
              key: username
        - name: ME_CONFIG_MONGODB_ADMINPASSWORD
          valueFrom:
            secretKeyRef:
              name: mongodb-secret
              key: password
        - name: ME_CONFIG_MONGODB_SERVER 
          valueFrom: 
            configMapKeyRef:
              name: mongodb-configmap
              key: db_host

apiVersion: v1
kind: Service
metadata:
  name: mongo-express-service
spec:
  selector:
    app: mongo-express
  type: LoadBalancer  
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081
      nodePort: 30000

These YAML configuration are Kubernetes manifest file that defines various resources for deploying a MongoDB database and a web-based MongoDB management tool called "mongo-express." Let's break down the different sections and resources defined in this configuration:

ConfigMap (mongodb-configmap):
- apiVersion: v1: Specifies the Kubernetes API version for this resource.
  - kind: ConfigMap: Defines a ConfigMap resource, which is used to store configuration data.
  - metadata: Metadata for the ConfigMap, including its name.
  - data: This section contains key-value pairs of configuration data. In this case, it defines a key db_host with the value mongodb-service. This configuration data can be used by other components in the Kubernetes cluster.
- Secret (mongodb-secret):
  - apiVersion: v1: Specifies the Kubernetes API version for this resource.
  - kind: Secret: Defines a Secret resource, which is used to store sensitive data, typically in base64-encoded form.
  - metadata: Metadata for the Secret, including its name.
  - type: Opaque: Specifies that this Secret is a generic, opaque secret (not specific to TLS certificates).
  - data: This section contains key-value pairs of sensitive data. It includes a username and password, both base64-encoded. These credentials are likely used for authenticating to the MongoDB database.
- Deployment (mongodb):
  - apiVersion: apps/v1: Specifies the Kubernetes API version for this resource.
  - kind: Deployment: Defines a Deployment resource, which manages the desired state of a set of pods.
  - metadata: Metadata for the Deployment, including its name and labels.
  - spec: Defines the desired state and configuration of the Deployment. It specifies that one replica of the MongoDB pod should be running.
  - containers: Specifies the containers running in the pod. In this case, there is a container named "mongodb" based on the "mongo" image. It also sets environment variables for the MongoDB root username and password using values from the "mongodb-secret."
- Service (mongodb-service):
  - apiVersion: v1: Specifies the Kubernetes API version for this resource.
  - kind: Service: Defines a Service resource, which provides network access to pods.
  - metadata: Metadata for the Service, including its name.
  - spec: Defines the selector to match pods (based on labels) and the port mapping. This service exposes port 27017 and is likely used to access the MongoDB database.
- Deployment (mongo-express):
  - Similar to the "mongodb" Deployment, this defines a Deployment for "mongo-express," a web-based MongoDB management tool.
  - It specifies one replica of the "mongo-express" pod, sets environment variables for the MongoDB admin username and password (using values from "mongodb-secret"), and specifies the "mongo-express" image.
- Service (mongo-express-service):
  - Defines a Service resource for "mongo-express" with a LoadBalancer type, meaning it can be accessed externally.
  - It exposes port 8081, which is likely the port used for accessing the "mongo-express" web interface. The nodePort is set to 30000, indicating that it will be exposed on this port on the cluster nodes.

In summary, this YAML configuration sets up a Kubernetes cluster with a MongoDB database and a web-based MongoDB management tool (mongo-express). It uses ConfigMaps and Secrets to manage configuration and sensitive data and defines Services to allow external access to the MongoDB and mongo-express components.

code
code

Deploying 2048 Game App on AWS EKS Cluster, Configure Ingress Controller| ALB |
- code
Code
- code
Code
- code
Code
- code
Code
- code
Code
- code
Code
- code
Code
- code
Code
- code
Code
- code

Videos:

kind	apiVersion
Pod	v1
Service	v1
Namespace	v1
Replica Controller	v1
ReplicaSet	apps/v1
Deployment	apps/v1

Docker Compose	Ansible	Kubernetes
version: services:	- Name: hosts: tasks:	apiversion: kind: metadata: specs:

Kubernetes

1. User Initiates Deployment Creation

2. API Server Actions

3. Deployment Controller Workflow

How It Works

What Happens When Desired State Differs?

4. Scheduler's Role

How It Works

5. API Server Updates the Pod Status

6. Kubelet's Role

How It Works

Kubelet Actions

7. Pod Running