DEV Community: Aisalkyn Aidarova

interview questions

Aisalkyn Aidarova — Fri, 19 Jun 2026 00:03:18 +0000

This is a very large topic. For a DevOps/SRE interview, these are the most common questions with answers and explanations.

1. What is an Operating System (OS)?

Answer

An Operating System is software that manages hardware resources and provides services for applications.

Examples:

Linux
Windows
macOS

Responsibilities

Process management
Memory management
File management
User management
Network management
Device management

Real Example

When you open Chrome:

OS allocates RAM.
OS schedules CPU.
OS accesses files from disk.
OS handles network traffic.

2. What are the main Linux Components?

Answer

Linux consists of:

Kernel

Core of Linux.

Responsible for:

CPU scheduling
Memory management
Device drivers
Networking

Shell

Examples:

Bash
Zsh
Sh

Responsible for:

Executing commands

File System

Stores:

Files
Directories

System Libraries

Allow applications to communicate with the kernel.

User Space Applications

Examples:

nginx
docker
kubectl

3. Explain Linux Boot Process

Answer

BIOS/UEFI starts
GRUB bootloader loads
Linux kernel loads
systemd starts
Services start
Login prompt appears

4. What is CPU?

Answer

CPU = Central Processing Unit

It executes instructions.

Think of CPU as the brain of the computer.

Responsibilities

Calculations
Running applications
Scheduling processes

Check CPU

lscpu

top

htop

5. What is RAM?

Answer

RAM = Random Access Memory

Temporary storage used by running applications.

Example

Application running:

CPU processes data
RAM stores active data

Check RAM

free -h

top

vmstat

6. Difference Between RAM and Disk

RAM	Disk
Temporary	Permanent
Faster	Slower
Lost after reboot	Saved after reboot

7. What is a Process?

Answer

A process is a running program.

Example:

ps -ef

Show all processes.

8. What is a Thread?

Answer

A thread is a lightweight execution unit inside a process.

Example:

Google Chrome:

One process
Many threads

9. Linux Directory Structure

What is / ?

Root directory.

Important Directories

/etc

Configuration files

Examples:

/etc/passwd
/etc/hosts

/var

Logs

Examples:

/var/log

/home

User files

/tmp

Temporary files

/bin

Basic commands

/usr

Installed applications

/opt

Third-party applications

/dev

Devices

Example:

/dev/sda

/proc

Kernel information

10. What is a File?

Everything in Linux is treated as a file.

Examples:

Regular file
Directory
Device
Socket

Check:

ls -l

11. File Permissions

Example:

-rwxr-xr-x

Meaning

Owner:

rwx

Group:

r-x

Others:

r-x

Change permissions

chmod 755 file

12. Network Troubleshooting Questions

Check IP

ip a

Check Routing

ip route

Check DNS

nslookup google.com

dig google.com

Check Connectivity

ping google.com

Check Port

nc -zv host 443

Check Open Connections

ss -tulpn

Trace Network Path

traceroute google.com

13. What is DNS?

Answer

DNS converts:

google.com

142.250.x.x

Without DNS you would need to remember IP addresses.

14. TCP vs UDP

TCP

Reliable

Examples:

HTTPS
SSH

UDP

Faster

Examples:

DNS
Video streaming

15. What is AWS?

Answer

Amazon Web Services is a cloud platform that provides:

Compute
Storage
Networking
Security

Pay only for what you use.

16. What is EC2?

Answer

Amazon EC2 is a virtual machine in AWS.

Used for:

Applications
Databases
Containers

17. What is Elastic IP?

Answer

Static public IP address.

Used when:

Public IP must not change.

Example:

Bastion host
Web server

18. What is EBS?

Answer

Amazon EBS = Block Storage

Think:

Virtual hard drive attached to EC2.

Features

Persistent
Fast
Single AZ

19. What is EFS?

Answer

Amazon EFS = Shared File System

Many EC2 instances can mount the same storage.

Uses

Shared application files
Kubernetes persistent storage

20. EBS vs EFS

EBS	EFS
Block Storage	File Storage
One EC2	Many EC2
Single AZ	Multi-AZ
Faster	Shared

21. What is S3?

Answer

Amazon S3

Stores:

Images
Videos
Backups
Logs

Unlimited scale.

22. What is CloudFront?

Answer

Amazon CloudFront

CDN service.

Caches content close to users.

Benefits

Faster websites
Lower latency
DDoS protection

23. What is Load Balancer?

Answer

Distributes traffic among servers.

Example:

1000 users
      |
     ALB
   /     \
EC2     EC2

24. What is ALB?

Answer

Application Load Balancer

Works at:

HTTP
HTTPS

Can route:

/app
/api
/images

to different targets.

25. What is NLB?

Answer

Network Load Balancer

Works at:

Used for:

High performance
Millions of requests

26. ALB vs NLB

ALB	NLB
Layer 7	Layer 4
HTTP/HTTPS	TCP/UDP
Path Routing	No Path Routing
Web Apps	High-performance apps

27. What is Auto Scaling Group?

Answer

Automatically adds or removes EC2 instances.

Example:

CPU > 70%

2 EC2 → 4 EC2

Traffic decreases:

4 EC2 → 2 EC2

28. What is Reserved Instance?

Answer

Commit for:

1 year
3 years

Receive large discount.

Used for predictable workloads.

29. What is Spot Instance?

Answer

Unused AWS capacity.

Up to 90% cheaper.

Can be terminated anytime.

Best for:

Batch jobs
CI/CD
Testing

30. What is Dedicated Host?

Answer

Physical server dedicated only to one customer.

No other AWS customers share that hardware.

Used for:

Compliance
Licensing requirements

31. What is Security Group?

Answer

Virtual firewall for EC2.

Example:

Allow:

22 SSH
80 HTTP
443 HTTPS

Deny everything else.

32. What is VPC?

Answer

Virtual network in AWS.

Contains:

Subnets
Route tables
Security groups
EC2

33. What is NAT Gateway?

Answer

Allows private instances to access internet.

Internet cannot initiate connections to them.

34. What is Route Table?

Answer

Network map telling traffic where to go.

Example:

0.0.0.0/0
→ Internet Gateway

35. What is Internet Gateway?

Answer

Allows public subnet resources to access internet.

36. Production Troubleshooting Question

Interviewer:

Application is down. What do you check?

Answer

Step 1

Check DNS

nslookup app.company.com

Step 2

Check Load Balancer

Target healthy?

Step 3

Check EC2

systemctl status nginx

Step 4

Check Ports

ss -tulpn

Step 5

Check Logs

journalctl -xe

tail -f /var/log/nginx/error.log

Step 6

Check Resources

top
free -h
df -h

Step 7

Check Network

ping
curl
traceroute

37. Top Linux Commands Every DevOps Engineer Must Know

pwd
ls
cd
mkdir
rm
cp
mv
cat
less
head
tail
grep
find
chmod
chown
ps
top
htop
kill
df -h
du -sh
free -h
ip a
ip route
ping
curl
wget
dig
nslookup
systemctl
journalctl
ssh
scp
tar
gzip
unzip

These cover roughly 80–90% of the Linux, AWS, networking, and troubleshooting questions commonly asked in DevOps, SRE, Platform Engineer, and Cloud Engineer interviews.

The Foundation: AWS VPC CNI Deep Dive

Aisalkyn Aidarova — Thu, 18 Jun 2026 12:20:19 +0000

Let’s remove the training wheels. We are going to break down exactly how these concepts operate mechanically under the hood, how bytes physically travel through an AWS environment, and what a Senior DevOps Engineer (6+ Years Experience) writes, debugs, and architects daily in production.

You cannot understand EKS Services without understanding how Pods get their IPs. Vanilla Kubernetes uses an "overlay network" (like Flannel or Calico vxlan), encapsulating packets inside packets. EKS does not do this by default. It uses the native AWS VPC CNI.

Under the Hood

Every Pod is a first-class citizen in your AWS VPC. It gets a real, routable IP address pulled directly from your AWS Subnet's CIDR block.

The aws-node DaemonSet: Runs on every worker node. It consists of two components: the CNI Plugin (which wires up network interfaces) and the IPAMD (IP Address Management Daemon).
Warm Pools: ipamd keeps a pool of Elastic Network Interfaces (ENIs) and secondary IPv4 addresses pre-attached to your EC2 worker nodes so that when a Pod schedules, it gets an IP instantly.

+--------------------------------------------------------------+
| Worker Node (EC2 Instance)                                   |
|  [Primary ENI (eth0)] -> Host Node IP (10.0.1.50)           |
|                                                              |
|  [Secondary ENI (eth1)]                                      |
|     |-- Secondary IP 1 -> Assigned to Pod A (10.0.1.61)      |
|     |-- Secondary IP 2 -> Assigned to Pod B (10.0.1.62)      |
+--------------------------------------------------------------+

Senior Architectural Engineering: The IP Exhaustion Problem

Every EC2 instance size has a hard limit on how many ENIs and secondary IPs it can host. For example, a t3.medium can attach 3 ENIs, and each ENI can hold 6 IPs.

$$\text{Max Pods} = (\text{ENIs} \times (\text{IPs per ENI} - 1)) + 2$$

A t3.medium maxes out at 17 Pods. If your subnet is small (e.g., a /24), a few large nodes will completely consume your subnet's IP addresses, preventing scaling.

Senior Solutions implemented at 6+ years:

Prefix Delegation: Instead of allocating individual secondary /32 IPs, ipamd allocates entire /28 blocks (16 IPs) to the ENI. This increases pod density per node dramatically (up to the K8s recommended 110 pods per node).
Custom Networking: You configure the VPC CNI to assign Pod IPs from an entirely separate, non-routable secondary VPC CIDR block (e.g., 100.64.0.0/16 CGNAT space), saving your primary corporate subnet IPs for the actual EC2 nodes.

2. ClusterIP & `kube-proxy` Core Mechanics

When you define a ClusterIP service, Kubernetes creates a stable virtual IP address. But this IP does not exist on any physical network card. It is a ghost IP.

The Linux Kernel Data Path (`iptables` vs `IPVS`)

Every node runs a daemon called kube-proxy. It watches the Kubernetes API server for new Services and EndpointSlices (the real IPs of the backend pods matching your service selector).

[Pod A] ---> Tries to talk to ClusterIP (10.100.0.15:80)
                 |
          (Linux Kernel intercept via Netfilter)
                 |
     [iptables / IPVS Rules Engine]
                 |
     (Changes Destination IP via DNAT)
                 |
                 v
         [Pod B Real IP (10.0.1.62:8080)]

iptables Mode (Default): kube-proxy writes sequential sequential O(N) evaluation rules inside the Linux kernel's Netfilter stack. When a packet leaves a pod targeting a ClusterIP, the kernel intercepts it, executes a DNAT (Destination Network Address Translation), and swaps the ClusterIP with a randomly selected healthy Pod IP.
The 6-Year Gotcha: At large scales (over 5,000 services), iptables causes massive CPU overhead because every single network packet must traverse a massive, sequential list of rules.
Production Fix: Senior engineers switch kube-proxy to IPVS (IP Virtual Server) mode. IPVS utilizes a Netfilter hash table O(1), allowing lookup times to remain completely flat regardless of how many thousands of microservices exist in the cluster.

3. NodePort: The Multi-Hop Bridge

A NodePort service allocates a port across every worker node (30000-32767).

The Hidden Packet Flow

If an external client hits Node-1-IP:32145, the traffic path looks like this:

Packet arrives at Node 1.
Node 1's iptables catches port 32145 and maps it internally to the corresponding ClusterIP.
The rule randomly selects a backend pod. If that pod happens to live on Node 2, Node 1 performs an SNAT (Source NAT) and forwards the packet across the AWS network to Node 2.
Node 2 delivers it to the Pod.

Senior Structural Problem: `externalTrafficPolicy`

Notice the extra network hop between Node 1 and Node 2. This increases latency and erases the client's real IP address (the pod sees Node 1's IP as the source).

Senior engineers modify the service manifest:

spec:
  type: NodePort
  externalTrafficPolicy: Local # <--- CRITICAL

Local policy: Forces the node that receives the traffic to only route it to pods living on that exact same node. If no local pods exist, the packet is dropped. This preserves the original Client IP and removes the inter-node network hop.

4. Ingress & AWS Load Balancer Controller (Enterprise Tier)

An Ingress is a collection of Layer 7 (Application Layer) routing rules. In EKS, you deploy the AWS Load Balancer Controller, an open-source operator that sits in your cluster, watches for Ingress objects, and calls AWS APIs to create an Application Load Balancer.

Architectural Deep Dive: Target-Type Modes

A Senior Engineer carefully chooses between two design modes using annotations:

`alb.ingress.kubernetes.io/target-type: instance`

The ALB targets the EC2 worker nodes using a NodePort.

Path: Client $\rightarrow$ ALB $\rightarrow$ NodePort (EC2 Instance) $\rightarrow$ kube-proxy (iptables) $\rightarrow$ Pod IP.
Cons: Double hopping, higher latency, complex health checking.

`alb.ingress.kubernetes.io/target-type: ip`

The ALB bypasses the EC2 instances completely and targets the Pods directly. This is only possible because the AWS VPC CNI gives Pods real VPC IPs.

Path: Client $\rightarrow$ ALB $\rightarrow$ Pod IP directly.
Pros: Blazing fast, zero kube-proxy interference, cleaner health checks, direct traffic pattern.

[Internet Client]
       |
       v
  [AWS ALB]
       |
       +-----------------------+ (Target Type: IP)
       |                       |
       v                       v
[Pod 1 (10.0.1.61)]     [Pod 2 (10.0.1.62)]

5. Egress Architechture & Security Boundaries

Managing outbound traffic is a massive part of auditing and compliance (PCI-DSS, SOC2).

The Infrastructure Layer

Pods live on nodes inside Private Subnets. When they call an external API (e.g., Salesforce, GitHub), the traffic passes from the Pod $\rightarrow$ ENI $\rightarrow$ Private Subnet Route Table $\rightarrow$ AWS NAT Gateway (living in a Public Subnet) $\rightarrow$ Internet.

The NAT Gateway maps the internal IP to a single public Elastic IP (EIP).

The Senior Level Layer-7 Security Problem

Standard Kubernetes NetworkPolicies operate at Layer 3/4 (IP and Port). They cannot inspect domain names. If a malicious dependency slips into your application code, it can easily exfiltrate data to a domain like malicious-attacker.com over standard port 443, bypassing standard network policies.

Senior Design Implementations:

Deploy Cilium utilizing eBPF to implement L7 network policies:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: restrict-egress-to-stripe
spec:
  endpointSelector:
    matchLabels:
      app: payment-processor
  egress:
  - toFQDNs:
    - matchName: "api.stripe.com" # <--- Only allow out to this domain
    toPorts:
    - ports:
      - port: "443"
        protocol: TCP

6. Real-World Troubleshooting Playbook for a Senior Engineer

When an application times out inside EKS, a Senior Engineer does not guess; they trace the network stack systemically.

                  [Is DNS Resolving?]
                     /          \
                (No) /            \ (Yes)
                    v              v
     Check CoreDNS Logs       [Can Pod contact ClusterIP?]
     Verify NodeLocal Cache       /          \
                             (No) /            \ (Yes)
                                 v              v
                     Check kube-proxy rules    Check Ingress / ALB Targets
                     Verify EndpointSlices     Verify Security Groups

1. "My Ingress returns a 502 Bad Gateway"

Senior Action: Check the AWS ALB Target Group status via the AWS console or CLI. If targets are unhealthy, check the Kubernetes Pod Readiness Probes. If the container's readiness probe fails, the AWS Load Balancer Controller removes the Pod IP from the ALB Target Group, causing a 502.
Security Group Check: Ensure the Security Group attached to the ALB allows inbound traffic to the Worker Node/Pod security groups on the application port.

2. "Intermittent DNS Resolution Timeouts (5-second delays)"

Senior Action: This is a famous Linux kernel bug involving glibc tracking concurrent UDP requests (ndots problem).
Resolution: Deploy NodeLocal DNSCache as a DaemonSet to handle DNS lookup requests locally on the node via a loopback interface (169.254.20.10), cutting out connection tracking overhead entirely.

3. "The Pod can't connect to an AWS RDS Database outside the cluster"

Senior Action:
Run kubectl get pod -o wide to determine the Pod's actual IP.
Check the AWS Security Group assigned to the RDS instance. Ensure it allows ingress from the Pod's specific IP block (or the Security Group assigned directly to the Pod if using Security Groups for Pods via Branch ENIs).
Verify that the routing tables in the EKS node's subnets point correctly to the VPC subnets hosting the database.

k8s: svc

Aisalkyn Aidarova — Thu, 18 Jun 2026 12:16:38 +0000

2. ClusterIP: The Internal Phone Extension

From Scratch (The Analogy)

Imagine a team of accounting workers inside the building. They move desks constantly (in Kubernetes, Pods are destroyed and recreated with new internal IPs all the time). If the sales team needs to call accounting, they can't memorize individual desk numbers. Instead, management sets up a permanent internal phone extension: Dial 400 for Accounting. No matter which desk the accounting workers move to, dialing 400 always routes you to an available accountant.

6-Year DevOps Level

ClusterIP is the default Kubernetes service type. It exposes the service on an internal cluster-only IP.

The Mechanics: It creates a stable virtual IP (VIP) and DNS entry (e.g., my-svc.my-namespace.svc.cluster.local) inside the cluster.
How it actually routes traffic: It relies on kube-proxy. A senior engineer knows that kube-proxy usually runs in IPVS or iptables mode, modifying the Linux kernel netfilter rules on each node to intercept traffic hitting the ClusterIP and randomly (or via round-robin) forward it to a real Pod backing IP.
Senior Gotcha: ClusterIPs are non-routable outside the cluster. If an application cannot talk to a database via ClusterIP, a senior engineer checks CoreDNS logs, reviews Endpoints or EndpointSlices (kubectl get endpointslices) to ensure backend pods are actually marked "Ready" by their readiness probes.

3. NodePort: The Dedicated Backdoor

From Scratch (The Analogy)

Now, say an external vendor needs direct access to a specific internal system. The building manager decides to open a very specific side door on the outside of the building—say, Door Room 32000. Anyone from the outside world can walk up to any side wall of the building, find Door 32000, and they will be instantly tunneled straight to that internal team's desk.

6-Year DevOps Level

NodePort builds on top of ClusterIP. It opens a specific port (by default, between 30000-32767) on every single virtual machine (Worker Node) in your cluster.

The Mechanics: If you target http://<Any-Node-IP>:32000, the node's network stack receives the traffic and routes it to the underlying ClusterIP service.
Senior Perspective: In enterprise production, you almost never expose NodePorts directly to the public internet because it's a security risk and requires clients to track ephemeral EC2 instance IPs.
The "Why": Why do we need it? Because external Enterprise Load Balancers (like AWS ALBs or NLBs) use NodePorts as target groups to bridge public traffic into the private cluster network.

4. Ingress vs. ALB (AWS Load Balancer Controller)

From Scratch (The Analogy)

Having 50 different side doors (NodePorts) for 50 different services is chaotic. Instead, you build a Grand Front Lobby (The Ingress) with a single front door. A receptionist sits there. When a visitor walks in and says, "I want to go to /shipping," the receptionist looks at a rulebook and directs them to the elevator. If a visitor says, "I want to go to /billing," they are directed to a different floor.

6-Year DevOps Level

An Ingress is just a Kubernetes specification (a set of routing rules based on HTTP paths or hostnames). It does nothing by itself without an Ingress Controller to execute it.

In AWS EKS, the golden standard is the AWS Load Balancer Controller, which automatically provisions an AWS ALB (Application Load Balancer) in your AWS account when you apply an Ingress manifest.

# A Senior Engineer's Ingress Spec
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: app-ingress
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/target-type: ip # KEY SENIOR CONFIG
spec:
  ingressClassName: alb
  rules:
  - http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 80

Deep Dive - Target-type instance vs ip: * instance mode routes traffic from the ALB -> NodePort on the EC2 worker node -> kube-proxy -> Pod. This adds an extra network hop.
ip mode (leveraging AWS VPC CNI) routes traffic directly from the ALB into the Pod's private IP. This completely bypasses NodePort and kube-proxy, slashing latency and maximizing performance. A 6-year veteran designs for target-type: ip.

5. Egress: Leaving the Building Safely

From Scratch (The Analogy)

Workers inside the building occasionally need to look up info on the public internet or send mail out. However, you don't want just any worker downloading random files or leaking data. The building has a strictly managed Outbound Mailroom (Egress Gateway) that checks where packets are going before letting them leave the building.

6-Year DevOps Level

Egress refers to traffic originating inside the cluster going out (to the internet, or to a legacy database outside the cluster).

The Setup: In a secure EKS setup, worker nodes live in Private Subnets. Their outbound path goes through an AWS NAT Gateway assigned to a static Elastic IP (EIP). External third-party APIs often require you to whitelist these specific EIPs.
Advanced Egress Control: A senior engineer knows that standard K8s network policies cannot restrict outbound traffic by domain name (e.g., blocking everything except api.stripe.com). To solve this, a 6-year veteran implements tools like Cilium (Egress Gateway) or a service mesh like Istio to enforce Layer 7 egress filtering, preventing data exfiltration if a container is compromised.

6. What Else is in the EKS Service & Networking Stack?

To interview or operate at a 6-year senior level, you must master these additional critical components of the EKS network ecosystem:

A. AWS VPC CNI Plugin (The Ground Floor)

Unlike standard vanilla Kubernetes which uses overlay networks (like Flannel), EKS uses the AWS VPC CNI. Every Pod gets a real, routable IP address directly from your AWS VPC subnet.

The Senior Problem (IP Exhaustion): Because pods use real VPC IPs, large clusters can easily run out of IPs in a standard subnet.
The Senior Solution: You must know how to configure Custom Networking (assigning secondary, non-routable CIDR blocks like 100.64.0.0/8 to pods) and enable Prefix Delegation (allocating /28 IP blocks to network interfaces to increase pod density per EC2 node).

B. CoreDNS & NodeLocal DNSCache

How do pods resolve domains? They hit the CoreDNS pods running in the cluster. At scale, thousands of pods spamming CoreDNS creates a massive bottleneck. Senior engineers deploy NodeLocal DNSCache, running a tiny DNS agent on every single node to cache queries locally and prevent intermittent connection timeouts.

C. Pod Identities (The Modern Security Layer)

Pods often need to talk to other AWS services (like S3 buckets or DynamoDB).

Old way: IRSA (IAM Roles for Service Accounts) which required complex OIDC providers and trust policies.
New standard: EKS Pod Identities. It optimizes performance and simplifies credential mapping by running an agent on the node that maps AWS IAM roles directly to K8s service accounts seamlessly.

D. AWS VPC Lattice (The Future of Cross-Cluster Mesh)

A cutting-edge DevOps engineer knows that managing traditional Service Meshes (like Istio or Linkerd) brings massive operational overhead. Amazon handles this natively via Amazon VPC Lattice using the Kubernetes Gateway API. It allows sidecar-less, fully managed service-to-service communication, traffic splitting, and IAM-level authentication across multiple distinct EKS clusters and AWS accounts.

Summary Checklist for a Senior DevOps Engineer

Feature	Primary Purpose	Key Senior Architectural Focus
ClusterIP	Internal Pod-to-Pod communication.	`kube-proxy` performance (`iptables` vs `IPVS`), `EndpointSlices` scaling.
NodePort	Direct external access via node IP.	Use primarily as a target for legacy external LBs; minimize public exposure.
Ingress / ALB	Layer 7 HTTP/HTTPS routing.	Use AWS Load Balancer Controller with `target-type: ip` for direct routing.
Egress	Outbound traffic control.	NAT Gateway management, static IP whitelisting, L7 domain filtering (Cilium/Istio).
VPC CNI	IP Allocation to Pods.	Prefix delegation, Custom Networking to prevent IP exhaustion.

To deepen your understanding of how these routing mechanisms translate to real-world cloud infrastructure, this AWS Load Balancer Controller deep dive covers advanced ingress, namespace isolation, and DNS architectures natively inside EKS.

interview questions with answers

Aisalkyn Aidarova — Wed, 17 Jun 2026 23:52:16 +0000

This is a very good foundation interview set. A DevOps engineer with 5–7 years of experience should be able to explain all of these clearly.

Infrastructure Fundamentals

What is Hardware?

Answer:
Hardware is the physical component of a computer system.

Examples:

CPU
RAM
SSD
Network Card (NIC)
Motherboard
Hard Drive

Without hardware, software cannot run.

What is Software?

Answer:
Software is a collection of programs and instructions that run on hardware.

Examples:

Linux
Windows
Docker
Kubernetes
Jenkins
Nginx

Hardware = Physical machine

Software = Instructions running on machine

CPU

What is CPU?

Answer:
CPU (Central Processing Unit) is the brain of the computer.

Responsibilities:

Execute instructions
Process calculations
Run applications
Manage processes

Example:

When you run:

kubectl get pods

CPU processes that command.

How do you check CPU usage?

top

htop

mpstat

RAM

What is RAM?

Answer:
RAM is temporary memory used by running applications.

Examples:

Kubernetes Pods
Docker Containers
Nginx
Java Applications

When server reboots, RAM is cleared.

How do you check memory usage?

free -h

Example:

free -h

Output:

Mem: 16Gi  10Gi  2Gi  4Gi

How to check memory consumers?

top

ps aux --sort=-%mem

SSD

What is SSD?

Answer:
SSD (Solid State Drive) is permanent storage.

Used for:

Operating System
Logs
Databases
Files

Advantages:

Faster than HDD
No moving parts

IP Address

What is IP Address?

Answer:
IP Address uniquely identifies a device on a network.

Example:

192.168.1.10

Similar to a home address.

Without IP, devices cannot communicate.

Difference between Public and Private IP

Private:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

Public:

Accessible from internet.

Example:

54.12.34.56

Port

What is Port?

Answer:
Port identifies a service running on an IP address.

Example:

192.168.1.10:80

IP = House

Port = Apartment Number

Common Ports

Port	Service
22	SSH
80	HTTP
443	HTTPS
53	DNS
3306	MySQL
5432	PostgreSQL
6379	Redis

Protocol

What is Protocol?

Answer:
Protocol is a set of communication rules.

Examples:

HTTP
HTTPS
TCP
UDP
SSH

Difference between TCP and UDP

TCP:

Reliable
Ordered
Connection oriented

Examples:

HTTP
HTTPS
SSH

UDP:

Fast
No delivery guarantee

Examples:

DNS
Video Streaming

OSI Model

Explain OSI Model

Layer	Name
7	Application
6	Presentation
5	Session
4	Transport
3	Network
2	Data Link
1	Physical

Layer 7

Application Layer

Examples:

HTTP
HTTPS
FTP

Layer 4

Transport

Protocols:

Layer 3

Network

Responsible for:

Routing
IP Addressing

Devices:

Router

Layer 2

Data Link

Responsible for:

MAC Addresses

Devices:

Switch

Layer 1

Physical

Examples:

Cables
Fiber
Ethernet

EC2

What is EC2?

Answer:
Amazon EC2 is a virtual server in AWS.

Used to run:

Linux
Applications
Databases
Docker

Example:

Launch Ubuntu server.

Install Nginx.

Access via browser.

ASG

What is Auto Scaling Group?

Answer:
ASG automatically adds or removes EC2 instances.

Benefits:

High Availability
Scalability
Self Healing

Example:

Traffic increases.

ASG:

2 EC2 → 4 EC2 → 8 EC2

ALB

What is Application Load Balancer?

Answer:
ALB distributes HTTP/HTTPS traffic across multiple targets.

Works at:

OSI Layer 7

Supports:

Host-based routing
Path-based routing

Example:

/api/users → User Service

/api/orders → Order Service

NLB

What is Network Load Balancer?

Answer:
NLB works at:

Layer 4

Handles:

Very fast.

Millions of connections.

Target Group

What is Target Group?

Answer:
Target Group contains backend servers.

Example:

ALB
 ↓
Target Group
 ↓
EC2 Instances

Health checks are performed against targets.

Security Group

What is Security Group?

Answer:
Virtual firewall for AWS resources.

Controls:

Inbound Traffic
Outbound Traffic

Example:

Allow:

22 SSH
80 HTTP
443 HTTPS

EBS

What is EBS?

Answer:
Elastic Block Store.

Persistent disk attached to EC2.

Similar to:

SSD attached to server

Use cases:

Databases
Application storage

EFS

What is EFS?

Answer:
Elastic File System.

Shared storage.

Multiple EC2 instances can mount same filesystem.

Example:

EC2-1
EC2-2
EC2-3
   ↓
   EFS

S3

What is S3?

Answer:
Object Storage Service.

Stores:

Images
Videos
Backups
Logs

Characteristics:

Durable
Highly Available
Unlimited Scale

Cookies

What are Cookies?

Answer:
Small files stored in browser.

Used for:

Login Sessions
User Preferences
Tracking

Example:

User logs in.

Cookie stores session identifier.

Persistent Volume (PV)

What is Persistent Volume?

Answer:
Persistent storage in Kubernetes.

Pod can restart without losing data.

Example:

Pod
 ↓
PVC
 ↓
PV
 ↓
EBS

Linux Commands

Check Disk Usage

df -h

Shows:

Filesystem
Size
Used
Available

Check Filesystem Size

lsblk

Check Memory

free -h

Check CPU

top

Check Processes

ps aux

Kill Process

kill -9 PID

Search File

find / -name nginx.conf

Check Port

ss -tulpn

netstat -tulpn

Current Directory

pwd

List Files

ls -la

Copy

cp file1 file2

Move

mv old new

Delete

rm -rf folder

Change Permissions

chmod 755 file

Change Ownership

chown ubuntu:ubuntu file

Systemd

What is systemd?

Answer:
systemd is Linux service manager.

Manages:

Services
Boot process
Logs

Examples:

nginx
docker
kubelet

systemctl

Start Service

sudo systemctl start nginx

Stop Service

sudo systemctl stop nginx

Restart Service

sudo systemctl restart nginx

Service Status

systemctl status nginx

Enable On Boot

sudo systemctl enable nginx

journalctl

What is journalctl?

Answer:
Reads systemd logs.

View Logs

journalctl

Service Logs

journalctl -u nginx

Real-Time Logs

journalctl -fu nginx

apt

What is apt?

Answer:
Ubuntu package manager.

Install package

sudo apt install nginx -y

Update repository

sudo apt update

Upgrade packages

sudo apt upgrade -y

sudo

What is sudo?

Answer:
Runs command as root.

Example:

sudo apt update

Network Troubleshooting

Check IP Address

ip a

Check Routing Table

ip route

Test Connectivity

ping 8.8.8.8

DNS Test

nslookup google.com

dig google.com

Trace Route

traceroute google.com

Check Open Ports

ss -tulpn

Test TCP Port

telnet hostname 80

nc -zv hostname 80

Real Interview Scenario

Question: Website is down. How do you troubleshoot?

Answer:

Check process

ps aux | grep nginx

Check service

systemctl status nginx

Check logs

journalctl -u nginx

Check port

ss -tulpn | grep 80

Check disk

df -h

Check memory

free -h

Check CPU

top

Check connectivity

ping
curl
nc

Check firewall/security group
Check DNS

nslookup
dig

Check load balancer health checks
Verify backend application is responding

This troubleshooting flow is exactly the type of answer expected from a mid-to-senior DevOps/SRE engineer during interviews.

Lecture: Architectural Masterclass — Kubernetes Networking In-Depth

Aisalkyn Aidarova — Mon, 15 Jun 2026 06:45:32 +0000

Kubernetes networking operates on a fundamental principle: Every Pod gets its own unique, routable IP address. In traditional infrastructure, multiple applications on a single server have to share an IP address and fight over port allocations (e.g., App A uses port 8080, App B must use 8081). In Kubernetes, every Pod behaves like a distinct physical server or virtual machine on the network, eliminating port conflicts entirely.

1. The Four Layers of Kubernetes Networking

To understand how data flows through a cluster, we must break networking down into four distinct communication boundaries.

Layer 1: Container-to-Container Networking (Within the Same Pod)

The Mechanism: All containers inside a single Pod share the exact same network namespace. This means they share the same IP address, MAC address, and port space.
How they talk: They communicate with each other over the local loopback interface (localhost).
Real-World Use Case: A frontend application container talks to a local logging sidecar container on localhost:9000.

Layer 2: Pod-to-Pod Networking (Same Node vs. Across Nodes)

The foundational rule of Kubernetes networking is that any Pod must be able to communicate with any other Pod without utilizing Network Address Translation (NAT), regardless of which machine they live on.

On the Same Node: The virtual network interfaces (veth pairs) of the Pods are plugged into a local virtual bridge (like cbr0 or docker0) running on the host OS. Traffic flows across the bridge directly from one Pod's virtual interface to another.
Across Different Nodes: This requires a Container Network Interface (CNI) plugin. The CNI builds an overlay network (an encrypted or encapsulated tunnel using protocols like VXLAN or Geneve) or routes traffic natively using BGP. When Pod A on Node 1 sends a packet to Pod B on Node 2, the CNI encapsulates the packet inside a standard host-to-host physical packet, transmits it across the underlying data center network, and unpacks it on the destination node.

2. Deep Dive into the Container Network Interface (CNI)

Kubernetes does not have a built-in network provider. Instead, it exposes an interface specification called the CNI. When a Pod is created, the local kubelet agent calls the configured CNI plugin to provision a virtual network interface and assign an IP address.

As an engineer, choosing the right CNI determines cluster performance, security, and scalability:

Flannel: A lightweight overlay network provider. It uses standard VXLAN encapsulation. It is simple to configure but lacks advanced features like Network Policies.
Calico: An enterprise-grade provider that routes packets natively via Layer 3 using BGP (Border Gateway Protocol) without encapsulation overhead. It features a highly robust implementation of Kubernetes Network Policies.
Cilium: The modern industry standard. Cilium completely skips traditional Linux IPTables routing by leveraging eBPF (Extended Berkeley Packet Filter) directly inside the Linux Kernel. It routes packets at near-native hardware speeds and provides deep cryptographic visibility and security profiling.

3. Layer 3: Pod-to-Service Networking (The East-West Traffic Engine)

Because Pods are ephemeral, relying on individual Pod IPs for long-term internal routing is impossible. If a Pod crashes, its replacement gets a completely different IP.

A Service provides a stable, permanent IP address and DNS name that fronts a collection of identical Pods.

The Role of Kube-Proxy

Services are completely abstract concepts; they do not possess a real physical network interface or a network cable. They are managed by kube-proxy, a network daemon running on every single worker node.

When a Service is created, the control plane assigns it a virtual IP called a ClusterIP. kube-proxy watches the API server for these objects and immediately writes routing rules into the node's underlying operating system kernel using one of three modes:

IPVS Mode (IP Virtual Server): The modern production standard. It operates using netfilter hooks inside the Linux kernel to implement true Layer 4 load balancing via an efficient $O(1)$ hash table lookup. It scales to tens of thousands of services without degrading network performance.
IPTables Mode: The historical default. kube-proxy sequentially appends netfilter firewall rules for every service in the cluster. While functional, it operates on a linear lookup model ($O(N)$). If a cluster grows to thousands of services, evaluating millions of sequential IPTables rules for every single packet significantly degrades system performance and consumes excessive CPU.
Userspace Mode: The legacy model. Traffic is routed out of kernel space, up into the user application space of kube-proxy, and back down to the kernel. This double-context switch introduces severe latency and is completely deprecated in production environments.

CoreDNS: Service Discovery

Every time a Service is provisioned, the internal cluster DNS engine (CoreDNS) automatically registers a DNS entry mapped directly to that Service's virtual ClusterIP:

$$\texttt{..svc.cluster.local}$$

This allows an application to reliably communicate with an internal database using a static hostname like postgres-db.production instead of tracking shifting IP addresses.

4. Layer 4: Exposing Workloads to the Outside World (North-South Traffic)

To accept external requests from clients sitting outside the cluster boundary, you must transition from internal networking to external publishing models.

Service Types

ClusterIP: The default mode. It exposes the service on an internal-only cluster IP. This means the service is completely unreachable from outside the cluster network.
NodePort: Opens a dedicated high-order port (by default between 30000-32767) across the physical network interface of every single worker node in the cluster. External clients can hit any node's public IP address on that specific port to be automatically routed inside to the target application Pods.
LoadBalancer: The enterprise standard for cloud-based clusters. It instructs Kubernetes to reach out to your cloud provider's API (such as AWS, Google Cloud, or Azure) and provision a dedicated physical Cloud Load Balancer. The cloud load balancer automatically routes external public traffic into your cluster's underlying NodePort or ClusterIP networks.

5. Ingress Controllers and the Gateway API

While a Cloud LoadBalancer service works well, creating a unique cloud load balancer for every individual microservice becomes highly cost-prohibitive and complicated to manage. This is where edge routing abstractions step in.

The Ingress Architecture

An Ingress Controller acts as an application-layer (Layer 7) reverse proxy and application load balancer running right inside your cluster. You provision a single Cloud Load Balancer pointing directly to your Ingress Controller (e.g., Nginx Ingress, Traefik, AWS ALB Controller).

The Ingress Controller reads incoming HTTP requests, looks at the host header and URI path, and performs intelligent routing based on declarative rules:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: API-routing-ingress
spec:
  ingressClassName: nginx
  rules:
  - host: company.com
    http:
      paths:
      - path: /users
        pathType: Prefix
        backend:
          service:
            name: user-service
            port:
              number: 8080
      - path: /billing
        pathType: Prefix
        backend:
          service:
            name: billing-service
            port:
              number: 9000

The Next Generation: Gateway API

As clusters scale across massive engineering organizations, the traditional Ingress resource breaks down because infrastructure configurations (like TLS certificates) and routing mechanisms are tightly coupled into a single file.

The Gateway API splits this monolithic structure into modular roles:

GatewayClass: Created by cluster administrators to define the underlying proxy infrastructure type (e.g., Envoy, Istio).
Gateway: Managed by the infrastructure operations team to define the public-facing entry points, listening ports, and global TLS certifications.
HTTPRoute / TCPRoute: Managed independently by software development teams to map their specific microservice endpoints behind the pre-established Gateway.

6. Securing the Network via Network Policies

By default, Kubernetes network design assumes complete trust—any Pod can send traffic to any other Pod across any namespace. To build a secure enterprise environment, you must implement a zero-trust architecture using Network Policies. Network Policies act as stateful firewalls for your Pods, controlling traffic at Layer 3 and Layer 4.

⚠️ Crucial Operational Warning: Network Policies are purely declarative specifications. If your cluster is running a CNI plugin that does not support network policies (such as raw Flannel), your Network Policy manifests will be successfully saved to the API server, but they will be completely ignored, leaving your cluster entirely wide open.

📄 Production Example: Isolating a Database Pod

This policy isolates any Pod tagged with app: backend-db. It implements a default-deny rule for all traffic, explicitly allowing incoming packets (Ingress) exclusively from Pods matching the label app: api-server on port 5432.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: db-security-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-db
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-server
    ports:
    - protocol: TCP
      port: 5432

7. The Engineer's Guide to Network Troubleshooting

When an internal application fails to communicate over the network, a professional DevOps engineer uses a systematic triage strategy to isolate the root cause.

Step 1: Validate Pod-to-Pod Connectivity

Verify if the low-level overlay network is functional by passing traffic directly between Pod IPs.

# Get the raw IP addresses of your source and destination pods
kubectl get pods -o wide

# Execute an interactive ping or curl directly from one container to the destination Pod IP
kubectl exec -it target-pod-name -- curl http://<destination-pod-ip>:port/healthz

If this fails: The issue resides in your CNI overlay encapsulation, or a strict Network Policy is explicitly blocking the path.

Step 2: Validate Service VIP Transformation

Verify if kube-proxy is properly load balancing requests over the Service abstraction layer.

# Fetch the virtual ClusterIP of your service
kubectl get svc

# Attempt to communicate directly with the ClusterIP
kubectl exec -it target-pod-name -- curl http://<cluster-ip>:port/healthz

If Step 1 succeeds but Step 2 fails: The kube-proxy daemon on that specific node is likely frozen, or its local IPTables/IPVS routing tables have desynchronized. Check the health of the kube-proxy pods inside the kube-system namespace.

Step 3: Validate DNS Service Discovery

Verify if CoreDNS is successfully translating network hostnames to virtual cluster IPs.

# Execute a DNS lookup inside an application container
kubectl exec -it target-pod-name -- nslookup postgres-service.production.svc.cluster.local

If Step 2 succeeds but Step 3 fails: The internal CoreDNS deployment is misconfigured or overwhelmed. Check the deployment logs using kubectl logs -n kube-system deployment/coredns.

Production-Grade K8s — Configs, Networking, and Health

Aisalkyn Aidarova — Mon, 15 Jun 2026 06:33:34 +0000

1. Decoupling Code from Configuration (ConfigMaps & Secrets)

In a true DevOps pipeline, you never hardcode database URLs or passwords inside your container image. If you change a configuration variable, you shouldn't have to rebuild your entire Docker image.

Kubernetes solves this with two resources:

ConfigMaps: For non-sensitive data (e.g., application logs settings, database hostnames).
Secrets: For sensitive data (e.g., API keys, database passwords). Note: Standard K8s secrets are only Base64 encoded, not strongly encrypted by default. In enterprise environments, we back them up with tools like AWS Secrets Manager or HashiCorp Vault.

📄 Lab Blueprint: Injecting Configuration into Pods

Show your students how a Pod consumes a ConfigMap as an environment variable.

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_HOST: "db.production.company.com"
  LOG_LEVEL: "debug"
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: api-server
        image: my-registry/api:v1.0
        env:
        - name: DB_HOST
          valueFrom:
            configMapKeyRef:
              name: app-config
              key: DATABASE_HOST

2. Advanced Traffic Management: Services & Ingress

Your pods are up, and they have their configurations. But how does a customer on the internet actually view the website?

Pods are ephemeral; they die and change IP addresses constantly. We need a permanent, stable entry point.

The Routing Chain

[ External User Request ] 
           │
           ▼
┌──────────────────────────┐
│    Ingress Controller    │  <-- Routes traffic based on domain name (e.g., app.com)
└──────────┬───────────────┘
           │
           ▼
┌──────────────────────────┐
│     ClusterIP Service    │  <-- Acts as the permanent internal Load Balancer
└──────────┬───────────────┘
           │
           ▼
 ┌──────────────────┐
 │ Target Pods (1-3)│  <-- The actual running application instances
 └──────────────────┘

ClusterIP Service: The internal load balancer. It gives your group of pods a single, permanent internal IP address.
Ingress Controller (e.g., Nginx, Traefik): The reverse proxy sitting at the edge of your cluster. It reads incoming HTTP requests and routes them based on the domain name or URL path (e.g., routing traffic hitting /api to the backend pods, and / to the frontend pods).

3. The Production Pillars: Health Probes

A professional DevOps engineer never assumes an application is working just because the container status says Running.

What happens if an app experiences a Java Out-Of-Memory deadlock? The container stays "alive," but it cannot handle customer traffic. Kubernetes handles this using Probes (automated health checks run by the node's kubelet).

The Two Critical Probes

Probe Type	What it asks the container	What happens if it fails	Real-World Use Case
Readiness Probe	"Are you ready to receive live user traffic right now?"	The Ingress stops sending traffic to this specific pod, but does not restart it.	Waiting for a heavy application to load its cache or connect to the database on boot.
Liveness Probe	"Are you still alive and healthy, or are you frozen/deadlocked?"	Kubelet instantly terminates the pod and spins up a fresh replica.	Automatically fixing an application that has completely frozen or stopped responding.

📄 Classroom Demo: Implementing Probes

spec:
  containers:
  - name: production-app
    image: company/app:v2
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 15
      periodSeconds: 10
    readinessProbe:
      httpGet:
        path: /ready
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 5

4. Resource Allocation: Requests vs. Limits

If you do not specify boundaries, a single malfunctioning container with a memory leak can steal all the RAM on a physical server, causing all other critical tenant pods on that machine to crash.

Requests: The guaranteed floor. The minimum amount of CPU/Memory the container needs to boot up. The scheduler uses this to pick a node.
Limits: The absolute ceiling. The maximum amount of resource the container is allowed to take.

⚠️ Critical Interview Question Warning for Students:
If a container breaks past its CPU Limit, Kubernetes throttles its speed (the app slows down).
If a container breaks past its Memory Limit, the Linux kernel immediately terminates it with an OOMKilled (Out of Memory Killed) error status.

What is a Deployment Controller? (The Fleet Manager)

Aisalkyn Aidarova — Mon, 15 Jun 2026 06:29:58 +0000

To understand how a Deployment Controller works, we have to look past the technical jargon and understand the core problem it solves in the real world.

Imagine you own a high-end shipping company that delivers packages using a fleet of delivery vans.

The Containers (The Packages): Your application code (like a website or an API) is packed inside a standard container (like Docker).
The Pods (The Delivery Vans): In Kubernetes, you don't run containers directly. You put them inside a Pod. Think of a Pod as a delivery van. The van carries the package, protects it, and moves it around.
The Worker Nodes (The Highways/Garages): These are the actual physical or virtual servers (computers) where your vans drive and operate.

Now, if you only have one van, what happens if it gets a flat tire or crashes? Your delivery stops. If suddenly 10,000 customers order packages at the exact same time, one van isn't enough. You need someone in a control tower managing the fleet.

That control tower is the Deployment Controller.

In Kubernetes, a Controller is a background process that runs an infinite loop. It works exactly like a home thermostat. You set the thermostat to 72°F (your Desired State). The thermostat looks at the room's actual temperature (the Current State). If it’s 68°F, it turns on the heat until it hits 72°F.

A Deployment Controller does this for software. You tell it: "I want exactly 3 vans (Pods) running my website at all times."

If a server crashes at 3:00 AM and one of your vans disappears, the Deployment Controller instantly notices:

$$\text{Current State (2)} \neq \text{Desired State (3)}$$

It doesn't wake up a human. It automatically orders a new van to be built on a healthy server within milliseconds. This is called Self-Healing.

2. Deep Dive: What a Professional DevOps Engineer Knows Behind the Scenes

While a beginner just knows that a Deployment keeps an app running, a professional DevOps engineer with years of experience understands the underlying mechanics, architecture, and exact order of operations.

A Deployment doesn't actually manage Pods directly. It manages a middle layer called a ReplicaSet.

[ Deployment ] 
      │
      ▼
 [ ReplicaSet ] 
   ├── Pod 1
   ├── Pod 2
   └── Pod 3

The Deployment handles the strategy of how your application updates (e.g., changing from version 1 to version 2).
The ReplicaSet handles the number of duplicates (ensuring exactly 3 copies are alive).

The Step-by-Step Lifecycle of a Deployment

When a DevOps engineer writes a configuration file (YAML) and sends it to Kubernetes using the command line (kubectl apply -f deployment.yaml), a highly choreographed sequence occurs:

The Guard (API Server): The request enters the central brain of Kubernetes (the API Server). It checks who you are and if you have permission to deploy software.
The Ledger (Etcd): Once approved, the configuration is saved into a super-secure database called etcd. This database holds the absolute truth of the entire system.
The Brain (Deployment Controller): The Deployment Controller constantly watches this database. It sees the new request, creates a ReplicaSet object, and writes it back to the database.
The Count (ReplicaSet Controller): The ReplicaSet Controller sees its new assignment, realizes it needs to create 3 Pods, and writes 3 blank Pod blueprints into the database.
The Matchmaker (Scheduler): The Scheduler looks at these blank Pod blueprints. It reviews all available servers in your cloud network, checks which servers have enough CPU and memory, and assigns each Pod to a specific server.
The Captain (Kubelet): On each individual server, a small agent program called a kubelet is watching. It sees that a Pod has been assigned to its machine. It immediately tells the container software (like Docker/containerd) to download the application code and start running it.

3. Real-World Production Strategies (Advanced DevOps Mastery)

As you grow into a professional role, your job shifts from just "making it work" to "ensuring zero downtime when millions of people are using it." This is where Deployment strategies matter.

Rolling Updates (The Default Strategy)

Imagine you need to upgrade all your delivery vans from Version 1 to Version 2. You can't just destroy all Version 1 vans at once, or your business shuts down for 10 minutes.

A Deployment Controller performs a Rolling Update:

It spins up one new Version 2 van.
Once it confirms the new van is working perfectly, it destroys one old Version 1 van.
It repeats this step-by-step until the whole fleet is upgraded. Result: The users utilizing your website never notice a single second of downtime.

Proactive Safeguards: Readiness & Liveness Probes

A great DevOps engineer never trusts that software is working just because it booted up. Sometimes an application starts, but it's frozen inside because it can't connect to the database.

To fix this, you configure Probes (automated health checks) inside the deployment:

Liveness Probe: The controller continuously knocks on the container's door. If the container stops answering, the controller assumes it is deadlocked and restarts it.
Readiness Probe: During an update, the controller checks if the new Version 2 van is actually ready to take real customer orders. If the app takes 30 seconds to load its data, the controller waits patiently before routing live traffic to it.

4. Summary: The Mindset Shift to Become a Professional

To transition from a beginner to a high-level DevOps Engineer, you must stop thinking about software as something you install manually on a computer.

Instead, your job is to write code that describes the perfect infrastructure environment, and let automation engines like the Deployment Controller do the heavy lifting of maintaining, scaling, and repairing that environment 24/7.

The Kubernetes Architecture: Behind the Scenes

Aisalkyn Aidarova — Mon, 15 Jun 2026 06:26:17 +0000

To truly master Kubernetes, a DevOps engineer must look past the kubectl CLI and understand the internal components. When you run a command or deploy a manifest, a highly coordinated workflow occurs between the Control Plane (the brains) and the Worker Nodes (the muscle).

The Control Plane (Master Components)

kube-apiserver: The front door to the cluster. It exposes the Kubernetes API and is the only component that talks directly to the cluster storage. Every tool (kubectl, CI/CD pipelines, internal controllers) communicates through it.
etcd: A distributed, consistent key-value store. This is the single source of truth for your cluster. It records the exact state of every single resource. Pro-Tip: If you lose your etcd backups, you lose your cluster.
kube-scheduler: The matchmaker. It watches for newly created Pods that have no assigned node and selects the best Worker Node for them to run on based on resource availability, constraints, and affinity rules.
kube-controller-manager: The engine behind the controllers. It packages the actual control loops (Deployment controller, Node controller, Endpoints controller) that continuously regulate the state of the cluster.

The Worker Nodes (Data Plane)

kubelet: The captain of the node. It runs on every machine in the cluster, ensuring that containers are running in a Pod and healthy according to the instructions given by the Control Plane.
kube-proxy: The network supervisor. It maintains network rules on nodes, allowing network communication to your Pods from inside or outside the cluster.
Container Runtime: The software responsible for running containers (most commonly containerd or CRI-O).

2. Step-by-Step Lifecycle: What Happens When You Run `kubectl apply`?

To diagnose infrastructure issues effectively, a DevOps engineer must understand the exact chain of events that occurs when a manifest is deployed.

Step 1: Authentication & Authorization

You execute kubectl apply -f deployment.yaml. The request hits the kube-apiserver. The API server validates your identity (Certificate, Token, or OIDC) and checks your Role-Based Access Control (RBAC) permissions to ensure you are allowed to create deployments in that namespace.

Step 2: Mutating & Validating Admission Control

Before saving anything, the API server passes the YAML through Admission Controllers:

Mutating webhooks modify the request (e.g., automatically injecting sidecar containers for service meshes or default resource limits).
Validating webhooks enforce compliance (e.g., rejecting the deployment if it runs as the root user or uses an unapproved container registry).

Step 3: Etcd Storage (The State Recorded)

Once validated, the API server writes the desired state of the Deployment into etcd.

Step 4: The Controller Manager Steps In

The Deployment Controller (inside the manager) notices a new Deployment object in etcd via a watch stream. It realizes the Deployment demands a ReplicaSet, but none exists yet. The controller instructs the API server to write a ReplicaSet object to etcd.

In turn, the ReplicaSet Controller notices this new object, sees you requested replicas: 3, and generates definitions for 3 individual Pods, saving them to etcd.

Step 5: Scheduling the Pods

At this stage, the 3 Pods exist in etcd but have a status of Pending because their nodeName field is blank. The kube-scheduler detects these unassigned pods, evaluates the nodes for available CPU/Memory, and selects optimal hosts. It updates the Pod definitions in etcd with the assigned node names.

Step 6: Node Execution via Kubelet

The kubelet running on the selected worker node watches the API server. It notices a Pod has been assigned to its specific node.

Kubelet calls the Container Runtime Interface (CRI) to pull the container image and start the containers.
It interacts with the Container Network Interface (CNI) plugin to assign a unique cluster IP address to the Pod.
It provisions storage via the Container Storage Interface (CSI) if persistent volumes are required.

Step 7: Continuous Reconciliation

Once running, the kubelet reports back to the API server that the pod status is Running. The controller manager confirms that the Current State (3 active pods) matches the Desired State (3 requested pods). The reconciliation loop is temporarily satisfied.

3. What a DevOps Engineer Must Know to Manage K8s Production

Being a DevOps engineer requires moving past basic YAML configurations and managing day-to-day production realities.

A. Resource Management & Scheduling Controls

Improperly configured pods can destabilize an entire cluster. You must always define resource boundaries.

Requests: The absolute minimum CPU and Memory a container needs to boot. The Scheduler uses this number to place the Pod on a node.
Limits: The maximum threshold a container is allowed to consume. If a container breaks past its memory limit, the Linux kernel kills it with an OOMKilled (Out Of Memory) error.
Affinity & Taints: You must know how to dictate placement. Use Taints and Tolerations to repel pods from specific nodes (e.g., keeping regular apps off expensive GPU nodes). Use Node Affinity to attract pods to specific instances.

B. Networking, Ingress, and Service Architecture

Pods are ephemeral—they die and change IPs constantly. To expose applications reliably, you must master the layers of K8s networking:

[ Internet ] ---> [ Ingress Controller ] ---> [ ClusterIP Service ] ---> [ Pod Replicas ]

ClusterIP: The default service type. It exposes the service on an internal cluster-only IP. Best for internal communication between microservices.
NodePort: Exposes the service on a static port across each Node's IP.
LoadBalancer: Integrates with your cloud provider (AWS, GCP, Azure) to provision an enterprise-grade external cloud load balancer automatically.
Ingress Controllers (Nginx, Traefik, ALB): Acting as an application-layer reverse proxy, an Ingress controller routes external HTTP/HTTPS traffic to internal services based on paths or domain names (e.g., api.company.com/v1).

C. Troubleshooting & Day-2 Operations

When production breaks, you must know exactly where to look. Memorize this troubleshooting matrix:

If a Pod Status is...	It usually means...	Your Next Command Should Be...
`CrashLoopBackOff`	The application code is crashing immediately after startup (misconfiguration, missing env variables, database down).	`kubectl logs <pod-name> --previous`
`ImagePullBackOff`	Typo in the image name, wrong tag, or the cluster doesn't have the permission/credentials to pull from a private registry.	`kubectl describe pod <pod-name>`
`Pending`	The scheduler cannot find a node that has enough free CPU or Memory to satisfy the Pod's Requests.	`kubectl describe pod <pod-name>` (Check the events at the bottom)
`OOMKilled`	The container tried to consume more memory than its explicitly declared Limit.	`kubectl describe pod <pod-name>`

Kubernetes - From ECS 3-Tier Arch to Production Microservices

Aisalkyn Aidarova — Mon, 08 Jun 2026 03:30:31 +0000

1. What We Built Already

Students already created:

Frontend Container
        ↓
Backend Container
        ↓
RDS PostgreSQL

Infrastructure:

Users
  ↓
ALB
  ↓
ECS Fargate
  ↓
Frontend Container
  ↓
Backend Container
  ↓
RDS PostgreSQL

Technologies:

Docker
ECS Fargate
ECR
RDS
AWS Networking
Security Groups

This is called:

Three-Tier Architecture

2. Problem with Traditional Backend

Initially companies create:

One frontend
One huge backend
One database

But when traffic grows:

Problems appear:

Backend becomes huge
One bug crashes entire backend
Difficult deployments
Scaling becomes expensive
One team changes code → affects everyone
Downtime during deployments

Example:

Netflix cannot keep:

1 giant backend

Instead they split services.

3. What Are Microservices?

Instead of:

backend-service

We split into:

auth-service
payment-service
course-service
student-service
notification-service

Each service:

independent
deploys separately
scales separately
owned by different teams

This is:

Microservice Architecture

4. What is Kubernetes?

Kubernetes (K8s)

Kubernetes is:

Container Orchestration Platform

It manages:

containers
scaling
networking
deployments
recovery
updates

Automatically.

Created by:

Google

Based on:

Borg system

Now maintained by:

CNCF

5. Why Companies Use Kubernetes

Companies need:

high availability
scaling
self healing
automation
rolling updates
multi-cloud portability

Kubernetes solves these problems.

Used by:

Netflix
Uber
Spotify
Airbnb
Amazon
Banks
Healthcare companies

6. ECS vs Kubernetes

ECS	Kubernetes
AWS only	Multi-cloud
Easier	More complex
Faster to start	Industry standard
Less control	Very flexible
AWS manages much	You manage more
Simple learning curve	Steeper learning curve

7. ECS Flow

In ECS we did:

Docker Build
    ↓
Push to ECR
    ↓
Task Definition
    ↓
ECS Service
    ↓
Running Containers

AWS handled:

orchestration
scheduling
networking

8. Kubernetes Flow

In Kubernetes:

Docker Build
      ↓
Push to ECR
      ↓
Deployment YAML
      ↓
Pods
      ↓
Services
      ↓
Ingress

Kubernetes uses YAML configuration.

9. Kubernetes Architecture

Main components:

Control Plane
    ↓
Worker Nodes
    ↓
Pods

10. Control Plane

Control Plane = brain of Kubernetes

Components:

API Server
Scheduler
Controller Manager
etcd

Responsibilities:

manage cluster
schedule pods
maintain desired state

11. Worker Nodes

Worker Nodes run applications.

Inside nodes:

kubelet
container runtime
kube-proxy

Worker nodes host:

Pods

12. What is a Pod?

Pod = smallest Kubernetes object.

A Pod contains:

one or more containers

Example:

Pod
 ├── frontend container
 └── helper container

Usually:

1 container per pod

13. Why Pods?

Pods provide:

shared networking
shared storage
lifecycle management

Containers inside pod communicate using:

localhost

14. Deployment

Deployment manages pods.

Example:

Deployment
      ↓
ReplicaSet
      ↓
Pods

Responsibilities:

scaling
rolling updates
self healing
restarting failed pods

15. ReplicaSet

ReplicaSet ensures:

desired pods = running pods

Example:

3 replicas requested
1 pod crashes
Kubernetes creates new pod automatically

16. Kubernetes Self-Healing

If pod crashes:

Kubernetes:

detects failure
recreates pod
restores application

Automatically.

This is:

Self-Healing Infrastructure

17. Kubernetes Services

Pods change IPs constantly.

Service gives:

stable endpoint
internal communication

Types:

ClusterIP
NodePort
LoadBalancer

18. ClusterIP

Default service.

Internal communication only.

Example:

frontend → backend-service

Inside cluster only.

19. NodePort

Exposes service on node port.

Example:

NodeIP:30080

Mostly for labs/testing.

20. LoadBalancer

Creates cloud load balancer.

In AWS:

creates ALB/NLB automatically

Used for production.

21. Ingress

Ingress controls:

HTTP routing
domains
SSL
path routing

Example:

/api → backend
/admin → admin-service

Ingress acts like:

Smart Traffic Router

22. Kubernetes Networking

Each Pod gets:

its own IP

Pods communicate directly.

Kubernetes provides:

internal DNS
service discovery

Example:

backend-service.default.svc.cluster.local

23. Kubernetes Storage

Containers are temporary.

Databases need persistence.

Kubernetes uses:

Persistent Volumes
Persistent Volume Claims

BUT:

Production companies usually keep databases outside cluster:

RDS

Aurora

Cloud SQL

24. Why RDS Outside Kubernetes?

Reasons:

easier backups
managed failover
better stability
managed scaling
less operational risk

Very common architecture:

EKS + RDS

25. Kubernetes Scaling

Kubernetes can scale automatically.

Using:

HPA

Horizontal Pod Autoscaler.

Example:

CPU > 70%
Pods scale from 2 → 10

26. Rolling Updates

Without downtime.

Old pods terminate gradually.

New pods start gradually.

Users never notice deployment.

This is:

Zero Downtime Deployment

27. Production Kubernetes Architecture

Production flow:

Users
  ↓
CloudFront
  ↓
ALB
  ↓
Ingress
  ↓
Frontend Pods
  ↓
Backend Microservices
  ↓
RDS PostgreSQL

Monitoring:

Prometheus
Grafana
Loki
CloudWatch

CI/CD:

GitHub Actions
Jenkins
ArgoCD

28. Kubernetes Security

Production security:

RBAC
IAM Roles
Secrets
Network Policies
Private Subnets
TLS/SSL

Never store passwords in code.

Use:

Kubernetes Secrets
AWS Secrets Manager

29. Kubernetes YAML

Kubernetes uses YAML files.

Example structure:

apiVersion:
kind:
metadata:
spec:

Main files:

deployment.yaml
service.yaml
ingress.yaml

30. Example Deployment YAML

apiVersion: apps/v1
kind: Deployment

metadata:
  name: frontend

spec:
  replicas: 2

  selector:
    matchLabels:
      app: frontend

  template:
    metadata:
      labels:
        app: frontend

    spec:
      containers:
      - name: frontend
        image: nginx
        ports:
        - containerPort: 80

31. Important kubectl Commands

Create resources:

kubectl apply -f deployment.yaml

View pods:

kubectl get pods

View services:

kubectl get svc

Describe pod:

kubectl describe pod pod-name

View logs:

kubectl logs pod-name

32. EKS (Elastic Kubernetes Service)

AWS Managed Kubernetes.

AWS manages:

Control Plane
High availability
etcd

We manage:

worker nodes
deployments
pods

33. Why Companies Love EKS

Benefits:

Kubernetes without managing masters
AWS integration
IAM integration
ALB integration
CloudWatch integration

Very common in enterprise.

34. ECS vs EKS in Production

ECS:

simpler
faster
easier for AWS-only environments

EKS:

portable
more powerful
more enterprise demand
industry standard

35. Real Production Example

E-commerce company:

Microservices:

auth-service
order-service
payment-service
inventory-service
notification-service

Each service:

independent deployment
independent scaling

Traffic spike:

only payment-service scales

Huge advantage.

36. Monitoring Kubernetes

Observability stack:

Prometheus → metrics
Grafana → dashboards
Loki → logs
Alertmanager → alerts

Your current stack already matches production patterns.

37. CI/CD Pipeline

Modern deployment flow:

Developer
   ↓
GitHub
   ↓
GitHub Actions
   ↓
Docker Build
   ↓
Push to ECR
   ↓
Deploy to EKS

38. Interview Questions

Common DevOps interview questions:

What is Pod?
Difference between ECS and EKS?
What is Deployment?
What is Service?
What is Ingress?
What is HPA?
What happens when pod crashes?
Difference between container and pod?

39. Career Impact

Kubernetes skills are highly demanded.

Roles:

DevOps Engineer
SRE
Platform Engineer
Cloud Engineer
Kubernetes Administrator

40. Final Architecture Summary

Current:

3-Tier ECS Architecture

Future:

Production Kubernetes Microservices Platform

Final production vision:

Users
 ↓
CloudFront
 ↓
ALB
 ↓
Ingress
 ↓
Frontend Pods
 ↓
Microservices
 ↓
RDS
 ↓
Monitoring Stack

This is real enterprise architecture used in production today.

full agile by claude

Aisalkyn Aidarova — Wed, 03 Jun 2026 06:09:24 +0000

Here's the full Agile roadmap. Navigate using the tabs at the top — each view is designed for a different stakeholder:

The five tabs give you:

Overview — epic cards at a glance, each clickable to generate deeper breakdowns
Epics & features — all 7 epics expandable, 28 features with priority ratings and descriptions
User stories — filterable by epic, each with full acceptance criteria in testable format
Sprints — all 9 sprints expandable with tasks, story points per task, tags, dependencies, and a checkable testing checklist
Timeline — visual Gantt-style bar chart showing cadence and point distribution across 18 weeks

A few architectural decisions baked into the prioritization worth calling out:

Sprint 1 is deliberately a zero-feature sprint. Nothing ships to users — only foundation work. RLS policies, CI/CD, schema migrations, and fixing the broken UI states must land before any feature development begins, or you'll be retrofitting security onto live user data.

Payments are Sprint 7 (not Sprint 1) by design. You need working auth, lecture delivery, and an admin panel before charging students. Trying to wire Stripe before those are stable creates refund complexity and support burden.

The testing checklist for each sprint is written as executable statements, not vague phrases — each item should map to an actual test case or manual QA step in your project management tool.

When you're ready to move forward, say the word and I can generate the actual code for any specific sprint, starting with Sprint 1's Supabase schema and RLS policies.

agile from claude

Aisalkyn Aidarova — Wed, 03 Jun 2026 05:59:50 +0000

Now I have everything I need. Let me produce a comprehensive architectural analysis report as a rendered document.Now I have everything needed for a comprehensive analysis. Let me build this as an interactive report.Here's the full architectural assessment. Click each numbered section to expand it. A few things I want to call out as your senior architect:

The single most important insight: What exists today is a marketing site with auth scaffolding, not an LMS. The UI shows placeholder states — "Loading projects…", an expired countdown, empty module pages — which means the real product build starts from sprint 1.

Three decisions that will define everything:

Adopt Supabase RLS before a single real student record enters the database. Retrofitting row-level security after data exists is painful and risky. Design the policies in Sprint 1 alongside the schema.
Use Mux for video, not S3 or YouTube. 128 lectures × ~45 minutes is a serious media operation. You need adaptive bitrate, resume position tracking, and per-minute billing — Mux is purpose-built for exactly this use case.
Remove /admin/projects/ from the public nav immediately. This is a security hygiene issue that should be fixed before any other feature work.

The 9-sprint roadmap is realistic for a small team (2–3 engineers). Sprints 1–5 get you to a functional LMS that can onboard Batch 4. Sprints 6–9 harden it for scale and add community features.

When you're ready, I can generate the code for any specific sprint or component — starting with the Supabase schema + RLS policies, the Next.js route group structure, or the Stripe enrollment flow.

website plan

Aisalkyn Aidarova — Wed, 03 Jun 2026 05:46:47 +0000

Yes — absolutely.

If you give Claude ONLY the URL of your website:
JumpToTech DevOps School

Claude can already:

analyze structure
detect pages
understand your business model
identify missing functionality
create Agile roadmap
create sprint planning
suggest architecture
suggest UI improvements
suggest database structure
detect UX issues
recommend enterprise workflow

Your website already has:

landing page
modules
lectures
student portal
registration
announcements
discussions
LMS concept
admin logic idea
DevOps branding
course structure (JumpToTech)

So Claude has enough context to become your:

Product Manager
Scrum Master
Senior Architect
Technical Lead

BUT…

The MOST IMPORTANT thing:

Do NOT ask:

“Build my website.”

Instead ask Claude like enterprise company.

THIS IS THE CORRECT WAY

STEP 1 — Ask Claude to Analyze

Prompt:

Analyze this website:
https://www.jump2techdevops.com

I am building a DevOps LMS platform using:
- Next.js
- Supabase
- Tailwind
- Vercel

Please analyze:
1. Current architecture
2. Missing functionality
3. UX problems
4. Scalability issues
5. Recommended folder structure
6. Database structure
7. Agile sprint roadmap
8. MVP vs future features
9. Enterprise best practices

Do NOT generate code yet.
Act like senior software architect.

This is the FIRST thing.

STEP 2 — Ask for Agile Plan

Then:

Create Agile roadmap for this LMS project.

Split into:
- Epics
- Features
- User stories
- Sprints

Prioritize:
1. Stability
2. Authentication
3. Lecture system
4. Admin panel
5. Student experience
6. Payments
7. Scalability

Each sprint should:
- have goal
- tasks
- estimated complexity
- dependencies
- testing checklist

Now Claude becomes Scrum Master.

STEP 3 — Build Sprint-by-Sprint

Then ONLY work on ONE sprint.

Example:

We are now working ONLY on Sprint 1.

Goal:
Fix navigation and lecture system.

Current problems:
- lecture not clickable
- admin/modules redirects incorrectly
- preview broken

Please:
1. explain probable root cause
2. create debugging checklist
3. create implementation plan
4. generate only necessary code changes

THIS is the key.

YOUR WEBSITE SHOULD BE BUILT LIKE THIS

EPIC 1 — FOUNDATION

routing
navbar
footer
responsive layout
dark/light mode

EPIC 2 — AUTHENTICATION

login
register
student/admin roles
protected routes

EPIC 3 — LMS CORE

modules
lectures
markdown rendering
progress tracking

EPIC 4 — ADMIN PANEL

create module
edit lecture
upload files
analytics

EPIC 5 — STUDENT EXPERIENCE

dashboard
certificates
quizzes
notes

EPIC 6 — BUSINESS

Stripe
subscriptions
coupons
invoices

EPIC 7 — DEVOPS

Docker
CI/CD
ECS
monitoring
backups

MOST IMPORTANT FOR AI CODING

You need these files FIRST:

PROJECT_DOCS/

Inside:

architecture.md

Frontend: Next.js
Backend: Supabase
Auth: Supabase Auth
Hosting: Vercel
Storage: Supabase Storage

routes.md

/
/modules
/modules/[slug]
/admin
/admin/modules
/admin/lectures
/dashboard

database.md

users
modules
lectures
progress
payments

coding-rules.md

- Use TypeScript
- Use App Router
- Reusable components only
- No duplicated UI
- Mobile-first

AI performs MUCH better with this.

BEST TOOL COMBINATION FOR YOU

Claude

Use for:

architecture
debugging
sprint planning
backend logic
technical decisions

Antigravity / Lovable

Use for:

frontend pages
animations
responsive design
visual sections

VS Code + GitHub

Use for:

version control
rollback
manual fixes

VERY IMPORTANT

Right now your website is already at:
“startup MVP stage”

Meaning:

not prototype anymore
now architecture matters

So random prompting becomes dangerous.

Now you need:

Agile
documentation
Git discipline
sprint isolation
reusable components
stable releases

Exactly like enterprise engineering.

MY RECOMMENDATION FOR YOUR NEXT 48 HOURS

DO NOT add new features.

ONLY:

Sprint Stabilization

Fix:

module navigation
lecture clickability
admin routing
lecture rendering
markdown support

Then freeze system.

Commit stable version.

Only after that continue.

That is exactly how real SaaS teams work.