Kubernetes Resource Requests and Limits

Requests define the minimum resourczs (CPU/memory) guaranteed to a container. Kubernetes uses requests to:

• Schedule Pods on nodes with sufficient resources
• Reserve resources for stable performance
  Example: requests: {cpu: "0.5", memory: "256Mi"} reserves half a CPU core and 256MB RAM.

Limits cap the maximum resources a container can use:

• Exceeding CPU limits causes throttling
• Exceeding memory limits triggers OOM kills
  Example: limits: {cpu: "1", memory: "512Mi"} prevents the container from using >1 CPU core or 512MB RAM.

Horizontal Pod Autoscaler (HPA) Scaling

HPA automatically adjusts Pod replicas based on observed metrics, solving dynamic workload demands.

How HPA Works:

1. Metric Collection: Every 15–30 seconds, HPA checks:

• CPU/memory utilization
• Custom metrics (e.g., HTTP requests per second)

2. Calculation: Compares current vs. target metrics:

desired_replicas = ceil[current_metric_value / target_metric_value]

3. Scaling Decision:

• Scales up if utilization > target
• Scales down if utilization < target

4. Action: Updates replica count in Deployment/StatefulSet

Scaling Based on Resource Metrics:
HPA uses resource requests to calculate utilization percentages:

CPU utilization % = (Actual CPU usage / CPU request) × 100

Example: If a Pod requests 0.5 CPU cores and uses 0.4 cores, utilization is 80%.

Example: Node.js App with HPA

# Deployment with resource requests
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nodejs-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: app
        image: node:18
        resources:
          requests:
            cpu: "0.5"
            memory: "256Mi"
          limits:
            cpu: "1"
            memory: "512Mi"

# HPA Configuration

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nodejs-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nodejs-app
  minReplicas: 3
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

Behavior:

• If average CPU usage across Pods exceeds 70% of requested CPU (0.35 cores), HPA adds replicas
• If usage drops below 70%, HPA removes replicas (minimum 3)
• Pods never exceed 1 CPU core (limit)

Key Advantages of HPA

1. Cost Efficiency: Scales down during low traffic
2. Performance Stability: Maintains response times under load
3. Automation: Eliminates manual scaling interventions
4. Multi-Metric Support: Scales based on:

• CPU/memory utilization
• Custom app metrics (e.g., queue length)
• External metrics (e.g., Cloud Pub/Sub backlog)

Limitations

• Requires accurate resource requests for effective scaling
• Scaling delay (typically 30–60 seconds)
• Doesn’t adjust container-level resources (use VPA for vertical scaling)

First Principles Summary

Problem: Static resource allocation struggles with variable workloads, causing either:

• Over-provisioning (wasted resources)
• Under-provisioning (poor performance)

Solution:

• Requests/Limits: Isolate applications and prevent resource starvation
• HPA: Dynamically align resources with actual demand using metrics

This combination enables efficient, self-healing infrastructure that responds to real-time workload changes while maintaining stability.

Kubernetes simplifies application deployment by abstracting infrastructure management and automating container orchestration, unlike AWS EC2 or ECS, which require more manual intervention. Let’s break this down with a situational example:

Situational Example: Deploying a Web Application

Scenario

A team wants to deploy a containerized Node.js web app with Redis caching. Here’s how the process differs across platforms:

1. AWS EC2 Approach

Steps Required:

1. Provision EC2 Instances: Manually launch and configure VMs (e.g., Ubuntu).
2. SSH into VMs: Log into each instance to install Docker, clone the GitHub repo, and build the image:

git clone https://github.com/your/app.git
docker build -t my-app .
docker run -d -p 3000:3000 my-app

1. Manual Scaling: Repeat steps for each new instance during traffic spikes.
2. Load Balancing: Manually configure an Elastic Load Balancer (ELB).

Problems:

• Time-Consuming: Repetitive setup for each VM.
• Error-Prone: Manual steps risk inconsistencies.
• No Self-Healing: If a VM crashes, the app stays down until manually restarted.

2. AWS ECS Approach

Steps Required:

1. Create a Task Definition: Define the Docker image, ports, and environment variables in JSON/YAML.
2. Configure ECS Cluster: Use EC2 instances or Fargate (serverless) to host containers.
3. Deploy Service: ECS pulls the image from Docker Hub and runs containers.

Improvements Over EC2:

• Automated Container Orchestration: ECS manages container lifecycle.
• Integration with AWS Services: Auto-scaling and load balancing via Application Load Balancer (ALB).

Limitations:

• AWS Lock-In: Tightly coupled with AWS APIs and tools.
• Limited Customization: Less control over infrastructure compared to Kubernetes.

3. Kubernetes Approach

Steps Required:

1. Define a Deployment: Declare the desired state in a YAML file:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: your-dockerhub-username/web-app:latest
        ports:
        - containerPort: 3000

2. Apply the Configuration:

kubectl apply -f deployment.yaml

3. Kubernetes Automates:

• Pulls the image from Docker Hub.
• Schedules pods across nodes.
• Monitors health and restarts failed containers.
• Scales replicas up/down based on traffic.

Key Advantages:

• No SSH or Manual Setup: Kubernetes manages nodes; you only define the desired state.
• Self-Healing: Restarts crashed containers automatically.
• Cloud-Agnostic: Same configuration works on AWS, GCP, or on-premises.
• Declarative Management: Focus on what to deploy, not how.

Why Kubernetes is Easier

Real-World Workflow Comparison

Task: Roll out a new version of the app.

EC2/ECS:

• Update the Docker image tag in the task definition or rebuild on VMs.
• Manually deploy or use ECS service updates.
• Risk downtime during rollout.

Kubernetes:

• Update the image field in the deployment YAML.
• Run kubectl apply.
• Kubernetes performs a zero-downtime rolling update.

Why Avoid SSH?

Kubernetes eliminates the need to SSH into nodes because:

1. Immutable Infrastructure: Nodes are treated as disposable; issues are resolved by replacing pods, not debugging VMs.
2. Declarative API: All changes are made via kubectl or GitOps tools (e.g., Argo CD).
3. Centralized Logs/Metrics: Use tools like Prometheus/Grafana instead of SSH-based debugging.

When to Use Which?

• EC2: Legacy apps not yet containerized.
• ECS: Simple AWS-centric apps with minimal customization needs.
• Kubernetes: Complex, cloud-agnostic microservices requiring granular control.

By automating image management, scaling, and self-healing, Kubernetes reduces operational toil and lets developers focus on writing code rather than managing infrastructure.

In React, controlled components manage their state using React’s state, while uncontrolled components manage their state internally within the DOM, accessed via refs

Controlled component

React’s state handles the form data, and the component updates the state when the input value changes. The input’s value is explicitly set through the value prop, ensuring React controls the input's value. An onChange event handler updates the state whenever the input value changes.

Controlled components offer predictability as the component manages the state of the form elements. We can perform real-time validation on the form data within the component's state

Uncontrolled Component

The input’s value is managed by the DOM itself, not by React state. You access the input’s value directly from the DOM, typically using a ref. We can perform validation on the input data only after the form is submitted , as the component doesn't have direct access to the form data in its state. uncontrolled components are not predictable

What’s an Abstract class in typescript ?

An abstract class in TypeScript serves as a blueprint for other classes and cannot be instantiated directly. It is primarily used to define common behaviors and properties that can be shared among derived classes. Here’s a breakdown of the syntax and purpose of abstract classes:

Syntax of Abstract Classes

To declare an abstract class, you use the

abstract

keyword before the class definition. Inside an abstract class, you can define abstract methods, which do not have an implementation and must be implemented by any subclass that extends the abstract class.

Example Syntax

typescriptabstract class Animal {
    *// Abstract method (no implementation)*
    abstract makeSound(): void;

    *// Concrete method (with implementation)*
    move(): void {
        console.log("Moving...");
    }
}

Key Points:

• Abstract Class Declaration: Use the abstract keyword before the class keyword.
• Abstract Methods: Methods declared with abstract do not have a body and must be implemented in derived classes.
• Concrete Methods: You can also include regular methods with implementations that can be inherited by subclasses.
• Cannot Instantiate: You cannot create an instance of an abstract class directly, which prevents its use without a concrete subclass.

Purpose of Abstract Classes

1. Common Interface: Abstract classes provide a common interface for all subclasses. This ensures that all derived classes implement certain methods, promoting consistency across related classes.
2. Code Reusability: They allow you to define shared behavior in one place (the abstract class), reducing code duplication in subclasses. For example, if multiple classes share common properties or methods, these can be defined once in the abstract class.
3. Polymorphism: Abstract classes enable polymorphism, allowing you to treat instances of derived classes as instances of the base abstract class. This is useful for designing systems where you want to handle different types of objects through a common interface.

Example of Usage

typescriptabstract class Shape {
    abstract calculateArea(): number;
}

class Rectangle extends Shape {
    constructor(private width: number, private height: number) {
        super();
    }

    calculateArea(): number {
        return this.width * this.height;
    }
}

class Circle extends Shape {
    constructor(private radius: number) {
        super();
    }

    calculateArea(): number {
        return Math.PI * this.radius * this.radius;
    }
}

const shapes: Shape[] = [new Rectangle(5, 10), new Circle(7)];
shapes.forEach(shape => {
    console.log(shape.calculateArea());
});

Conclusion

Abstract classes are a powerful feature in TypeScript that help organize code through inheritance, enforce method implementation in subclasses, and promote code reuse. They are particularly useful in large applications where maintaining consistency across related classes is essential.

What is an HTTP Server?

An HTTP server is a specific type of web server that understands and processes HTTP requests. When a user enters a URL in their browser, the browser sends an HTTP request to the server hosting the website. The server then retrieves the requested resource (such as an HTML page, image, or video) and sends it back to the browser, which displays it to the user.

Functions of a Web Server

• Serving Static Content: Delivers files like HTML doc, images, and videos directly to users.
• Dynamic Content Generation: Processes requests that require real-time data retrieval from databases or application servers.
• Logging and Security: Records access logs for monitoring and security purposes, and can implement various security measures.

Why Do We Need Web Servers?

Web servers are essential for several reasons:

• Hosting Websites: They store and serve the files necessary for websites.
• Data Processing: They can execute server-side scripts to generate dynamic content.
• Resource Management: They handle multiple requests simultaneously, allowing many users to access content without significant delays.

Relationship Between HTTP Server, Domain Name, IP Address, and Port

Domain Name

A domain name is a human-readable address (like www.example.com) that points to an IP address. It simplifies navigating the internet since users do not need to remember numerical IP addresses.

IP Address

An IP address is a unique numerical label assigned to each device connected to a network. When you enter a domain name in your browser, a Domain Name System (DNS) translates it into an IP address so your browser can locate the appropriate web server.

Port

A port is a communication endpoint on a server. By default, HTTP uses port 80 and HTTPS uses port 443. When your browser makes an HTTP request, it typically connects to these ports on the server specified by the IP address.

The Process of Accessing a Website

1. User Enters Domain Name: The user types a domain name into their web browser.
2. DNS Lookup: The browser checks its cache for the corresponding IP address. If not found, it queries a DNS server to resolve the domain name into an IP address.
3. Establishing Connection: The browser establishes a connection with the web server at the resolved IP address on the appropriate port (usually 80 for HTTP or 443 for HTTPS).
4. Sending HTTP Request: The browser sends an HTTP request to the web server asking for specific resources (like an HTML page).
5. Server Response:

• The web server receives the request through its HTTP server component.
• It processes the request, retrieves necessary files (static or dynamic), and sends them back as an HTTP response.

6. Displaying Content: The browser receives the response and renders the webpage for the user to view.

This entire process happens in seconds, enabling seamless browsing experiences across the internet.