Notes on ONTIC request flow, infrastructure fundamentals, Kubernetes basics, and cluster concepts.

Ontic Request Flow

Request Flow Diagram

Fundamentals of Infrastructure

Basic Terms

Server

• A server is just a powerful computer that provides services to other systems like a database, API, and so on.
• Your laptop is technically a server if you run a web app or database on it, for example MongoDB locally.

Instance

• An instance usually refers to a running copy of a machine, application, or database.
• When you open two VS Code windows, each window is an instance of VS Code.
• An instance is typically a VM, but in some cloud architectures like AWS Lambda or Kubernetes, an instance might refer to something lighter than a traditional VM, such as a container or function execution.

Serverless

AWS Lambdas

• It is a cloud computing model where you can run applications without managing servers.
• It does not mean there are no servers. It just means the cloud provider handles the infrastructure for you, so you do not have to worry about provisioning, scaling, or maintaining servers.
• It is kind of like pay-per-use, where you are billed for execution time and not idle time.
• Instead of running a continuously running VM or instance, your code runs only when triggered, for example by an HTTP request, a file upload, or a database change.
• The cloud provider automatically allocates resources as needed and shuts them down when execution is complete.
• It also handles autoscaling for you.
• Serverless is great for applications that need to scale dynamically or respond to events, like APIs, background jobs, or real-time data processing.
• However, it is not ideal for applications that require persistent connections or long-running processes.

Node

• A node is a physical or virtual machine in a distributed system.
• Your laptop is a single node.
• If you run multiple virtual machines or Docker containers, each VM or container can act as a node depending on the system context.

Cluster

• A cluster is a group of machines, which are nodes.
• If you run three Redis containers or multiple MongoDB instances on Docker, they form a cluster.

K8s Terminology

• A Kubernetes cluster is a group of nodes.
• Each node runs multiple pods, which in turn run containers.
• A pod can have one or more containers, for example Redis, MongoDB, and so on.
• A Kubernetes node is a VM or physical machine in the cluster.

K8s Pod vs Node

• In Kubernetes, a node is a machine, while a pod is the smallest deployable unit that runs inside a node.
• A Kubernetes cluster has multiple nodes, each responsible for running pods.
• A pod contains one or more containers.
• Containers inside the same pod share the same network and storage.

Why Do Pods Serve Requests Instead of Nodes?

• A pod contains the actual application, like an Nginx server, Redis, or MongoDB.
• When a request comes in, Kubernetes routes it to the correct pod.
• The node just provides infrastructure like CPU, RAM, and network to run the pods.
• It does not directly process application requests.

The node just hosts the pod. It does not handle HTTP traffic itself.

Node vs Server

• A server is a physical or virtual machine that provides computing resources like CPU, RAM, and storage.
• A node is a logical unit within a system or cluster that performs a specific role.

A node can be a server, but a server is not always considered a node.

• Your laptop can be considered a server if it runs an application like MongoDB or a web server.
• A server can also be a virtual machine, for example an EC2 instance in AWS.
• If you run multiple virtual machines or Docker containers, each VM or container can be called a node in a system.

If multiple nodes share the same IP, they are most likely running on the same server.

Confusing?

• The meaning of node, server, instance, process, and container depends on the system you are working with.
• There is no concept of servers in Kubernetes. Instead it has:
  • Clusters: a group of machines working together
  • Nodes: machines, physical or virtual, inside the cluster
  • Pods: units of deployment that contain containers
  • Containers: the actual runtime environments for applications
• Pods serve requests, not nodes directly. Nodes just provide compute power.

Even though nodes are often physical or virtual machines, which we usually call servers, Kubernetes itself does not refer to them as servers.

• Similarly AWS does not call EC2 instances servers, but in reality they are virtual servers running on AWS infrastructure.
• EC2 instances are generally referred to as cloud servers.

What is K8s?

• Think of Kubernetes, or k8s, as an orchestrator for running applications across multiple machines.

This is what Kubernetes does for applications:

• It manages and distributes workloads across multiple servers.
• If a server crashes, it moves the app to another server.
• If traffic increases, it can automatically add more servers.

Before Kubernetes, you had to:

• Manually install apps on servers
• Restart apps if a server crashed
• Add servers when traffic increased

With Kubernetes:

• Apps run inside containers like Docker
• Kubernetes automatically assigns containers to servers, which are nodes
• If a server crashes, Kubernetes restarts the app on another node

How Kubernetes Works in Simple Terms

Imagine you are deploying a website. Without Kubernetes, you would:

• Set up an EC2 instance
• Install and configure the web server
• Monitor and restart it if it crashes

With Kubernetes, you just:

1. Tell Kubernetes to run your website with 3 copies
2. Kubernetes finds available servers, which are nodes, and runs it
3. If a node fails, Kubernetes moves the website elsewhere
4. If traffic increases, Kubernetes adds more copies automatically

Key Kubernetes Concepts

• Cluster = the whole system, all servers plus Kubernetes managing them
• Node = a single server in the cluster
• Pod = a small unit that holds containers, your app
• Deployment = a way to manage multiple copies of an app
• Service = a way to expose your app to users

Is Kubernetes a Server or an OS?

Neither.

• It is a control system that manages servers
• It runs on top of Linux but is not an OS itself

Kubernetes is a system that manages servers and apps for you.

• It automates deployment, scaling, and failover
• Instead of managing individual servers, like EC2 instances, you manage apps and let Kubernetes handle the rest

Deployment Flow in K8s

The application code is deployed inside containers, which run inside pods in Kubernetes.

• Application code: you write code for a web app, API, or database service
• Containerization: you package the code into a Docker container with all dependencies
• Pods: Kubernetes runs your container inside a pod
• Nodes: the pod runs on a node, which can be a virtual machine, bare metal server, or cloud instance

So pods are an abstraction layer between containers and nodes. Instead of Kubernetes managing containers directly, it manages pods, which:

• Can contain one or multiple containers, usually one
• Have their own networking, IP address and ports
• Can share storage between containers inside them

So containers run inside pods, and pods run on nodes.

Request Flow in K8s

Let’s say you have a web app running on Kubernetes and a user hits https://yourapp.com/api/data.

Request Hits the Kubernetes Load Balancer

Optional

• If the app is exposed via a LoadBalancer Service, like AWS ELB or GCP LB, the request first reaches the cloud provider's load balancer.
• This load balancer forwards the request to a Kubernetes Ingress Controller, like Nginx Ingress or Traefik.

Request Reaches the Kubernetes Ingress Controller

• The Ingress Controller decides which Kubernetes Service should handle the request.
• It looks at the domain and path, for example /api/data, and forwards the request to the right Kubernetes Service.

Service Forwards Request to a Pod

• A Kubernetes Service, usually a ClusterIP or NodePort service, acts as a virtual load balancer inside the cluster.
• It selects a pod from its backend using round-robin or another strategy.
• The service forwards the request to the pod’s container running the actual app.

Pod Receives the Request

• A pod is a small unit in Kubernetes that runs one or more containers.
• The request reaches the correct container inside the pod.
• The container processes the request and may query a database like MongoDB, Redis, or PostgreSQL.

Response Travels Back

• The container processes the request and returns a response, for example JSON data.
• The response flows back through the service, Ingress, and Load Balancer, then reaches the user's browser.

Pod -> Service -> Load Balancer -> User's Browser

Running on Same Infra means?

• Compute
  • Running on the same Kubernetes cluster, but different pods
  • Using the same EC2 instances, AWS, VMs, or physical servers in a non-K8s setup
• Networking
  • Inside the same VPC or subnet, allowing direct communication
  • Using the same service mesh like Istio or Linkerd, or the same API gateway
  • Sharing the same internal DNS for service discovery
• Storage
  • Using the same database, like MongoDB or PostgreSQL, or shared data lake
  • Possibly sharing caches like Redis or Memcached
  • Common message broker like Kafka or RabbitMQ if events are used
• Security and IAM
  • Same IAM roles or policies for access control
  • Shared authentication mechanism like JWT or OAuth
  • Centralized secrets management like AWS Secrets Manager or Vault
• Monitoring and Logging
  • Same logging stack like ELK, Loki, or Datadog
  • Same monitoring tools like Prometheus, Grafana, or New Relic
  • Shared alerting systems like PagerDuty or OpsGenie

What is Cluster?

A cluster generally refers to a group of interconnected servers, or nodes, working together to provide high availability, scalability, and fault tolerance.

Kubernetes Cluster

A Kubernetes cluster is a set of machines, which are nodes, that run containerized applications. It consists of:

• Master nodes which manage the cluster, API Server, Scheduler, Controller, and so on
• Worker nodes which run the actual application containers, which are pods
• Pods which are the smallest deployable unit that runs your application

Example:

• Your backend app and data pipeline might be running as separate pods in the same Kubernetes cluster.

Mongo Cluster

A MongoDB cluster is a distributed database setup that ensures high availability and scalability. It consists of:

• Replica sets: multiple nodes storing the same data for failover, primary plus secondary nodes
• Sharded clusters: data is partitioned across multiple nodes to handle large-scale workloads

Example:

• Your backend might be using a MongoDB replica set so that if one node fails, another takes over.

rs.status()  // Shows replica set members
sh.status()  // Shows sharding details
db.printSlaveReplicationInfo() // Check replication lag from primary to secondary

rs.status()
// Primary -> handles read and write requests
// Secondary -> replicates primary data asynchronously and can serve reads if configured
// Arbiter -> does not store data, only participates in elections

• ONTIC’s MongoDB is not part of a sharded cluster, so there is no sharding enabled, at least in stage.
• db.isMaster() checks which node you are currently on.

If mongo (primary) goes down, mongo2 (secondary) can become the new primary via election.
Read scaling: reads can be offloaded to the secondary if read preferences are configured.

Replica set nodes can run in different ways.

Best practice:

• On separate servers for high availability

• You can check if ONTIC’s replica sets are running on the same nodes or different ones:

ssh mongo
hostname

ssh mongo2
hostname

ssh mongo-arbiter
hostname

# Check if they are on different nodes
hostname && ip a | grep inet

hostname -I

Kafka Cluster

A Kafka cluster consists of multiple Kafka brokers that handle message distribution and storage. It includes:

• Brokers which store and serve messages, or topics
• Producers which publish events or messages
• Consumers which read events or messages
• Zookeeper which manages metadata and leader elections

Example:

• Your backend publishes events to a Kafka topic, and your data pipeline consumes them from the same Kafka cluster.