Goal

The primary objective of this project is to deploy a ec2 instance in a secure single-tier architecture using IAC code (Terraform) through Gitlab CI pipeline.

Pre-Requisites

Before starting the deployment, ensure you have the following:

• Sign up for an Amazon Web Services (AWS) Free Tier account.

• Create IAM role with EC2 and s3 full admin role access

• Get aws access key and secret key

• Gitlab Account and Repository

Folder structure

Deployment

• Create new bucket in s3 and add bucket name in backend.tf file

terraform {
  backend "s3" {
   bucket = "aws-ec2-creation-tfstate"
   region="us-east-1"
   key="terrform.tfstate"
}
  }

• Add aws access key and secret key in GitLab repository environment variable setting> CICD> variable

• Create GitLab account token from below path and add in environment variable setting > access tokens> project access tokens> add token

• Create .gitlab-ci.yml file and write pipeline code as mentioned in file

• Commit the changes to main branch

Validation

• check the aws account and verify ec2 and s3 created

• Ensure ec2 accessible from outside of aws

AWS Single Tier architecture Diagram

The complete CICD pipeline code is available in GitLab repo .

IAM Role:

1. create IAM role with access to s3 and ec2

Networking and security:

1. Create 1 VPC

2. Create 4 subnet

   • Create 1 public subnet (app-tier) in az1

   • Create 1 public subnet (app-tier) in az2

   • Create 1 private subnet (db-tier) in az1

   • Create 1 private subnet (db-tier) in az2

3. Create 1 Internet Gateway attach to VPC

4. Create 1 Route table in VPC

   • Create 1 route table and attach to igw

   • Associate to app-tier public subnet (az1, az2)

5. Create 3 security group in VPC

   • sg-1 for load balancer with inbound rule http→80, my laptop IP

   • sg-2 in public subnet for app tier with inbound rule http→80, my laptop IP and http→80, sg-1

   • sg-3 in private subnet for db tier with inbound rule tcp→3306, sg-2

Database Deployment:

1. Create subnet group in RDS add 2 private subnet for db tier

2. Create aws RDS instance

Load Balancing and Auto scaling deployment:

1. Create AMI create AMI from running app tier instance

2. Create target group

3. Create LB

4. Create launch template

5. Create auto scaling

The complete terraform code for this project is available in my GitHub repo.

In Kubernetes, a Pod is the smallest and simplest deployable unit. It represents a single instance of a running process (or group of tightly coupled processes) in a cluster. Here’s a breakdown of Pods:

Key Concepts of Pods:

1. Atomic Unit of Deployment

• A Pod is the smallest deployable unit in Kubernetes.

• It can contain one or more tightly coupled containers (usually one main container + optional sidecar containers).

2. Shared Resources

Containers in a Pod share:

• The same network namespace (same IP & port space).

• The same storage volumes (can access the same files).

• The same Linux namespace (PID, UTS, IPC).

3. Lifecycle

• Pods are ephemeral—they can be created, destroyed, and recreated dynamically.

• If a Pod dies, Kubernetes can restart it (if configured) or replace it.

4. Managed by Controllers

• Pods are typically managed by higher-level controllers like:

  • Deployments (for stateless apps)

  • StatefulSets (for stateful apps)

  • DaemonSets (for node-level agents)

  • Jobs/CronJobs (for batch processing)

5. Networking

• Each Pod gets a unique cluster-internal IP.

• Containers in a Pod communicate via localhost (since they share a network stack).

6. Storage

• Pods can have Volumes (e.g., emptyDir, configMap, PersistentVolumeClaim) that are shared among containers.

Key Commands:

Imperative Method:

1. Create Pod

   Kubectl run podname --image imagename

   

2. List pod

   Kubectl get pods

   Kubectl get po

   Kubectl get pods -o wide

   

3. Login into pod

   kubectl exec -it podname - sh

   

4. Delete Pod

   Kubectl delete pod podname

   kubectl delete pod pod1 pod2

   

5. Describe Pod

   Kubectl describe pod podname

6. Update Pod

   Kubectl edit pod podname

7. Dry run command

   kubectl run --image=nginx --dry-run=client

   kubectl run --image=nginx --dry-run=client -o yaml

   kubectl run --image=nginx --dry-run=client -o yaml > podnew.yml

8. Troubleshoot pod

   Kubectl logs podname

   Kubectl events podname

Declarative Method:

1. Create pod manifest file in yaml format

   pod-manifest.yaml

   

Kubectl create -f pod-manifest.yml or

Kubectl apply -f pod-manifest.yml

ReplicaSets:

In Kubernetes, a ReplicaSet is a workload controller that ensures a specified number of identical Pod replicas are running at all times. It is a replacement for the older ReplicationController, with added support for set-based label selectors.

Key Features of a ReplicaSet

1. Ensures High Availability

• Maintains a stable set of Pods (e.g., always keeps 3 replicas running).

• If a Pod crashes, the ReplicaSet creates a new one.

2. Load balancing &Scaling

• You can manually scale up/down the number of replicas.

• Pod can be deployed in multiple worker node for one replica

3. Self-Healing

• If a node fails, the ReplicaSet reschedules Pods on healthy nodes.

4. Label-Based Selection

• Uses selectors to identify which Pods it manages.

• Supports both equality-based (`=, !=`) and set-based (`in, notin, exists`) selectors.

5. Not Meant for Direct Use

• Typically managed by higher-level controllers like Deployments (which create and manage ReplicaSets for rolling updates).

Key Commands:

1. Create replicaset

   replicaset-manifest.yaml

   

kubectl apply -f replicaset-manifest.yaml

2. List Replicaset

   kubectl get replicaset

   kubectl get rs

   

3. Describe replicaset

   kubectl describe replicaset nginx-rs

4. Update replicaset

   kubectl replace-f replicaset-manifest.yaml

5. Delete Replicaset

   kubectl delete replicaset nginx-rs

6. Scale replicas: 3 ways

   Kubectl scale rs/nginx-rs --replicas=5

   kubectl scale replicas=5 -f replicaset-manifest.yaml

   

   Edit the yaml file and save

   Kubectl edit rs/nginx-rs

   Kubectl apply -f relicaset.yaml

   Kubectl replace -f replicaset.yaml

Deployment:

A Deployment is a high-level Kubernetes controller that manages ReplicaSets and provides declarative updates to Pods. It is the most common way to deploy and manage stateless applications in Kubernetes, offering features like rolling updates, rollbacks, and scaling.

Key Features of Deployments

1. Manages ReplicaSets

• Creates and controls ReplicaSets, which in turn manage Pods.

• Ensures the desired number of Pods are running (`replicas`).

2. Rolling Updates & Rollbacks

• Updates Pods incrementally (zero downtime).

• Can roll back to a previous version if something goes wrong.

3. Self-Healing & Scalability

• Automatically replaces failed Pods.

• Supports manual and automatic scaling (e.g., with HPA).

4. Declarative Updates

• You define the desired state, and Kubernetes handles the rest.

Key Commands:

1. Create Deployment

   deployment-manifest.yaml

   

   kubectl apply -f deployment-manifest.yaml

2. List deployment

   kubectl get deployment

   kubectl get all

   

3. Delete deployment

   kubectl delete deployment

4. Describe deployment

   kubectl describe deployment nginx-deploy

   

5. Update image:

   kubectl set image deploy/nginx-deploy nginx=nginx:1.20

6. View rollout status

   kubectl rollout status deployment/nginx-deploy

7. View rollout history

   kubectl rollout history deployment/nginx-deploy

   

8. Rollback to previous version

   kubectl rollout undo deployment/nginx-deploy

   kubectl rollout undo deployment/nginx-deploy --record

9. Rollback to specific revision

   kubectl rollout undo deployment/nginx-deploy # to previous version

   kubectl rollout undo deployment/nginx-deploy --to-revision=2

10. Scaling:

    # Manual scaling

    kubectl scale deployment nginx-deploy --replicas=5

    # Auto-scaling (requires metrics server)

    kubectl autoscale deployment nginx-deploy --min=2 --max=10 --cpu-percent=80

Comparison:

1. Container Orchestration & Management

• Manages the lifecycle of containers (Docker, containerd, etc.) at scale.

• Automates deployment, scaling, and failover of applications.

2. Scalability & High Availability

• Horizontal Scaling: Easily scale applications up or down based on demand.

• Self-Healing: Automatically restarts or replaces failed containers.

• Load Balancing: Distributes traffic efficiently across containers.

3. Portability & Multi-Cloud Support

• Runs on any cloud (AWS, GCP, Azure) or on-premises.

• Avoids vendor lock-in by providing a consistent environment.

4. Declarative Configuration (Infrastructure as Code)

• Uses YAML/JSON manifests to define desired state.

• Kubernetes ensures the actual state matches the declared state.

5. Service Discovery & Networking

• Automatically assigns IPs/DNS names to containers.

• Supports internal and external networking (Ingress, Services).

6. Storage Orchestration

• Manages persistent storage (local, cloud, or network-attached).

• Supports dynamic volume provisioning.

7. Automated Rollouts & Rollbacks

• Supports Canary Deployments, Blue-Green Deployments, and Rolling Updates.

• If an update fails, Kubernetes rolls back to the previous stable version.

8. Resource Optimization

• Efficiently allocates CPU, memory, and storage to applications.

• Prevents resource starvation and improves cluster utilization.

9. Extensibility & Ecosystem

• Custom Resource Definitions (CRDs) allow extending Kubernetes for custom workloads.

• A vast ecosystem of tools (Helm, Istio, Prometheus, ArgoCD) integrates seamlessly.

10. Security & Compliance

• Role-Based Access Control (RBAC) for fine-grained permissions.

• Secrets management for sensitive data.

• Network policies to control pod-to-pod communication.

Kubernetes vs. Other Orchestration Tools

Kubernetes is the most widely adopted container orchestration platform, but alternatives like Docker Swarm, Apache Mesos, and HashiCorp Nomad exist. Below is a detailed comparison:

1. Kubernetes vs. Docker Swarm

2. Kubernetes vs. Apache Mesos

3. Kubernetes vs. HashiCorp Nomad

4. Kubernetes vs. OpenShift (Red Hat)

Summary: Which Orchestration Tool Should You Use?

Hope this info is useful for you. Will come up with more interesting concepts soon!

Thanks !

Kubernetes follows a client-server architecture with a control plane (master nodes) that manages worker nodes where containers are deployed. Here's a detailed breakdown:

Control Plane Components (Master Nodes)

1. API Server (kube-apiserver)

• Central management entity

• Exposes the Kubernetes API (REST interface)

• Validates and processes and executes all API requests

• Only component that directly interacts with etcd

• Enforces security policies

• Facilitates interaction between all components

2. etcd

• Distributed, Consistent and highly-available key-value store

• Stores all cluster data (configuration, state, metadata)

• Implements watches for change notifications

• Single source of truth for all k8s components

• Only API server talks to etcd and other components interact via api server

3. Scheduler (kube-scheduler)

• Watches for newly created Pods with no assigned node

• Selects a node for Pods to run on based on:

  1. Resource requirements

  2. Affinity/anti-affinity specifications

  3. Taints and tolerations

  4. Data locality

  5. Volume restrictions

  6. Distributes workloads across cluster

4. Controller Manager (kube-controller-manager)

• Core components of K8s. Runs controller processes that regulate cluster state to ensure the cluster’s actual state matches the desired state declared in api server

  1. Node Controller

     • Monitors node status (ready/not ready)

     • Handles node failure

     • Sync node information from cloud providers

  2. Replication Controller

     • Maintain correct number of pods for replicaSets/Deployments

     • Creates. deletes Pods to match spec.replicas

  3. Endpoints Controller

     • Populates Endpoints objects (links Servces to Pods)

  4. Service Account & Token Controllers

     • Manages service accounts tokens for API server

  5. Namespace Controller

     • Handles namespace lifecycle (creation/deletion)

     • Cascades deletion of resources in a namespace

  6. Persistent Volume Controller

     • Binds PersistentVolumeClaims to PersistentVolumes

     • Handles dynamic provisioning

5. Cloud Controller Manager (optional)

• Integrates with cloud provider APIs

• Manages cloud-specific controllers:

  1. Node Controller (for cloud instances)

     • Auto discovers new VM

     • Handles node labeling/tainting

     • Implements cloud provider health checks

  2. Route Controller (for networking)

     • Configure cloud networking routes between pods

  3. Service Controller (for load balancers)

     • Implements service type

       • LoadBalncer (cloud-native LB)

       • NodePort with cloud integration

Worker Node Components

1. kubelet

• Primary "node agent" that runs on each worker

• Creates, modifies and deletes containers based on Pod specs from API server and ensures containers are running healthy

• Ensures containers are running in a Pod

• Handles container restarts(crash loop backoff)

• Reports node and Pod status back to control plane

• Communicates with container runtimes via CRI

• Enforces Pod security standards

• Mounts Volume

• Configures Pod networking

• Manages container DNS

2. kube-proxy

• Network proxy that maintains network rules

• Service abstraction Implementation

  1. Translates service definitions (ClusterIP, NodePort, LoadBalancer) into actual network rules

• Performs connection forwarding or load balancing

• Implements Service IPs using iptables/IPVS

3. Container Runtime

• Software that runs containers. such as

  1. Docker(deprecated)

  2. Containerd(default)

  3. CRI-O(from linux)

• Responsible for pulling images, starting/stopping containers

• Kubernetes communicates with container runtime through Container Runtime Interface (CRI)

Addons (Optional Components)

1. DNS (CoreDNS)

• Default Cluster DNS server

• Provides name resolution for Services and Pods and other cluster resources

• Replaces kube-dns in k8s v1.13+

2. Dashboard

• Web-based Kubernetes UI

3. Ingress Controller

• Provides external access to Services

• Implements ingress rules (Nginx, Traefik, etc.)

4. Container Network Interface (CNI) Plugins

• Implements pod networking

• Enabling communication between containers, Pods and external services

• Examples: Calico, Flannel, Weave Net

Data Flow

1. User submits manifest via kubectl to API Server

2. API Server validates and stores state in etcd

3. Scheduler assigns Pods to nodes

4. kubelet on assigned node pulls Pod spec

5. kubelet instructs container runtime to launch containers

6. kube-proxy sets up networking rules

7. Controllers continuously monitor and reconcile state