TelcoCloud Training

24/09/2026

𝗘𝘅𝗰𝗹𝘂𝘀𝗶𝘃𝗲 𝗢𝗽𝗲𝗻𝗦𝗵𝗶𝗳𝘁 𝗖𝗼𝗻𝗰𝗲𝗽𝘁 𝟮 - "OpenShift Routes"

In K8s, setting up an ingress is a DIY route setup with an office intercom (internal svc) system.
While in OpenShift, it is like pressing a single button to hire a dedicated concierge and install an illuminated front door with a custom business sign.

An OpenShift Route is an out-of-the-box mechanism that exposes an internal application running in your cluster to the outside world using a public, human-readable URL

This is possible via a single 'oc expose svc' command, and there is no equivalent of 'oc expose' in plain K8s

This single command creates a custom OpenShift API object called a Route. The built-in OpenShift HAProxy router detects it automatically, maps the domain to your internal service, and immediately begins routing incoming HTTP/HTTPS traffic.

In telco cloud deployments, OpenShift Routes and oc expose provide instant, automated, and secure North-South ingress for management plane and OSS/BSS APIs, removing the operational overhead of third-party ingress controllers at distributed edge sites.

22/09/2026

𝗘𝘅𝗰𝗹𝘂𝘀𝗶𝘃𝗲 𝗢𝗽𝗲𝗻𝗦𝗵𝗶𝗳𝘁 𝗖𝗼𝗻𝗰𝗲𝗽𝘁 𝟭 - "OpenShift Project"

If a K8s namespace is an unmarked plot in an Open Field, then
An OpenShift project is a fully furnished hotel room with keycard access

An OpenShift Project is an enterprise wrapper built around a standard Kubernetes Namespace. While a namespace simply isolates resources, a project adds built-in multi-tenancy, access control (RBAC), and user self-service.

'oc new-project' automatically creates a namespace, sets context, generates default Service Accounts, RoleBindings, and Security Context Constraints (SCCs), and can set a few more defaults.

For telcos, an OpenShift project acts as an isolated, carrier-grade sandbox that safely isolates diverse vendor CNFs (5G Core, vRAN) on a shared cluster with built-in multi-tenancy, strict resource guarantees, and automated RBAC out of the box.

17/09/2026

Do you know that OpenShift has emerged as a de facto or default CaaS layer of the cloud infrastructure, whether it be public or private, but have you ever wondered that there are some concepts and commands that are only available in OpenShift and not available in plain Kubernetes?

And these questions are very common in any OpenShift or platform-related interview.

In my upcoming series of posts, I will describe such concepts and commands. Stay tuned & connected -

𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘀 𝘁𝗵𝗮𝘁 𝗮𝗿𝗲 𝗼𝗻𝗹𝘆 𝗽𝗮𝗿𝘁 𝗼𝗳 𝗢𝗽𝗲𝗻𝗦𝗵𝗶𝗳𝘁-

Project
Route
ClusterOperator
MachineConfig/MachineConfigPool
ImageStream / ImageStreamTag
Etc.....................

𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘀 𝘁𝗵𝗮𝘁 𝗮𝗿𝗲 𝗼𝗻𝗹𝘆 𝗽𝗮𝗿𝘁 𝗼𝗳 𝗢𝗽𝗲𝗻𝗦𝗵𝗶𝗳𝘁 & 𝗻𝗼𝘁 𝗞𝟴𝘀-

oc project/oc new-project
oc new-app
oc import-image / oc tag
oc status
oc whoami / oc login / oc logout
oc adm
oc expose
Etc......................

03/09/2026

What are 𝗞𝟴𝘀 𝗖𝗦𝗜𝘀 (𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲)?

Official definition: In Kubernetes, whenever a Pod needs a database disk attached, Kubernetes uses the CSI driver as the universal adapter to provision, attach, and mount that volume seamlessly.

Here is an easy explainer -

Imagine buying a high-end laptop (Kubernetes):

The Laptop (Kubernetes Cluster): Built to compute and orchestrate, but it shouldn't need custom internal circuitry built into its motherboard for every single brand of external hard drive on the market.

The External Hard Drive (Storage Provider / Cloud Disk): A physical external drive (AWS EBS, Ceph, NetApp) holding all your persistent files.

The USB Standard (CSI): A universal standard interface. As long as the drive manufacturer follows the USB protocol, you can plug in a drive from any vendor, mount it to your filesystem, read/write files, safely unmount it, and take it to another machine.

𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗦𝘁𝗼𝗿𝗮𝗴𝗲 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲 (𝗖𝗦𝗜) is the standardized plug-and-play standard that lets Kubernetes attach, detach, and manage external storage (like AWS EBS, Google Persistent Disks, Azure Disks, Ceph, or NetApp) without having hardcoded vendor code inside Kubernetes itself.

𝗪𝗵𝗮𝘁 𝗖𝗦𝗜 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗗𝗼𝗲𝘀 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 - Provisioning, Attaching (ControllerPlugin), Mounting (NodePlugin), Snapshots & Resizing

01/09/2026

What are 𝗞𝟴𝘀 𝗖𝗡𝗜𝘀 (𝗖𝗼𝗻𝘁𝗮𝗶𝗻𝗲𝗿 𝗡𝗲𝘁𝘄𝗼𝗿𝗸 𝗜𝗻𝘁𝗲𝗿𝗳𝗮𝗰𝗲)?

𝗢𝗳𝗳𝗶𝗰𝗶𝗮𝗹 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻 - CNI is a standardized specification that defines how Kubernetes attaches a network to newly created Pods.

Here is an easy explanation -

Imagine a large, newly built apartment building (a Kubernetes Worker Node):

The Apartment (The Pod): A unit where tenants (containers) live. When a tenant moves in, the apartment needs electricity, running water, and a mailbox.

The Building manager (Kubernetes / Kubelet): Manages the building. When a new tenant moves into an apartment but, the manager doesn't wire the pipes or cables themselves.

The Telecom Technician (The CNI Plugin): The manager calls a certified telecom technician.

The technician:
- Pulls an Ethernet cable from the building's central utility closet directly into the new apartment (creates virtual network interfaces).
- Assigns the apartment a unique phone number/mailbox address (allocates a Pod IP).
- Tests the connection to ensure the tenant can call any other apartment in the city directly (configures routing rules).
- When the tenant moves out, the technician disconnects the line and reclaims the number for future tenants (cleans up network resources).

Kubernetes itself does not know how to configure network cards, set up IP routes, or assign IP addresses to containers. Instead, Kubernetes sets the rule: "Every Pod must get its own unique IP address and be able to talk to any other Pod without NAT." It then delegates the actual job of plugging the Pod into the network to a CNI plugin (like Calico, Flannel, or Cilium).

𝗪𝗵𝗮𝘁 𝗖𝗡𝗜 𝗔𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗗𝗼𝗲𝘀 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 - IP Address Management (IPAM), Plumbing Interfaces, Routing & Traffic Flow, Security & Network Policies

29/08/2026

𝗥𝗲𝗱 𝗛𝗮𝘁 𝗢𝗽𝗲𝗻𝗦𝗵𝗶𝗳𝘁 has been named a Leader in the 2026 Gartner Magic Quadrant for Cloud-Native Application Platforms for the third consecutive year, based on the company’s Completeness of Vision and Ability to Execute.

Let me explain why -

1. OpenShift was already an excellent container manager, managing CNFs much better than the vanilla K8s distributions

2. After VMware's demolition by Broadcom, the whole VM market was empty & OpenShift played a nice shot by integrating virtualization management in the same platform. Now, every VM enterprise running VMware is migrating to Red Hat OpenShift virtualization for managing their VMs.

3. Cashing in on the AI hot wave at a perfect time by providing end-to-end management of LLMs with OpenShift AI

4. OpenShift delivers a consistent, enterprise-grade hybrid cloud experience because it is natively integrated and available as a managed service on AWS, Azure, Google Cloud, and IBM Cloud, while also supporting flexible, self-managed deployments on-premises or in private clouds.

Check out the full story on the news link

This recognition marks the third consecutive year that Red Hat has been positioned in the Leaders quadrant, reflecting the company’s Completeness of Vision and Ability to Execute.

27/08/2026

Do you know 𝘄𝗵𝗶𝗰𝗵 𝗞𝟴𝘀 𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘀 𝘀𝗼𝗹𝘃𝗲 𝘄𝗵𝗮𝘁 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺? Well, here is the list in the context of Telco workloads.

𝗖𝗼𝗿𝗲 𝗪𝗼𝗿𝗸𝗹𝗼𝗮𝗱𝘀 & 𝗖𝗼𝗺𝗽𝘂𝘁𝗲

Pod: The smallest deployable unit, packaging one or more containers (e.g., a microservice processing 5G call-session data).
Small explainer 9 - Do you know 𝘄𝗵𝗶𝗰𝗵 𝗞𝟴𝘀 𝗰𝗼𝗻𝗰𝗲𝗽𝘁𝘀 𝘀𝗼𝗹𝘃𝗲 𝘄𝗵𝗮𝘁 𝗯𝘂𝘀𝗶𝗻𝗲𝘀𝘀 𝗽𝗿𝗼𝗯𝗹𝗲𝗺? Well, here is the list in the context of Telco workloads.

𝗖𝗼𝗿𝗲 𝗪𝗼𝗿𝗸𝗹𝗼𝗮𝗱𝘀 & 𝗖𝗼𝗺𝗽𝘂𝘁𝗲

Pod: The smallest deployable unit, which runs the code, like a 5G call session.

Deployment: Creates replaceable pods like cattle. Maintain replicas. Rolling updates and self-healing for stateless applications, like subscriber billing portals.

StatefulSet: Creates irreplaceable pods like pets, guarantees stable network IDs (db-0, db-1) for stateful backends, like telecom subscriber databases.

DaemonSet: Runs a copy of a pod on every cluster node, like logs, monitoring, or telecom node-level telemetry.

Finally, each one of the above will create a pod

𝗡𝗲𝘁𝘄𝗼𝗿𝗸𝗶𝗻𝗴 & 𝗧𝗿𝗮𝗳𝗳𝗶𝗰 𝗥𝗼𝘂𝘁𝗶𝗻𝗴

Service (ClusterIP / NodePort / LoadBalancer): Provides a stable virtual IP and internal DNS name for a set of pods.

Ingress: Cluster-wide layer-7 URL-based routing to manage external subscriber traffic

NetworkPolicy: Layer 3 & 4 routing within the cluster to isolate sensitive payment gateways or core telecom signaling networks from general enterprise traffic.

𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 & 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆

ConfigMap: Injects non-sensitive data (feature flags or routing tables) into the workload.

Secret: Injects sensitive data (API tokens, passwords, keys) into the workloads.

RBAC (Role & RoleBinding) & ServiceAccount: What access rights do human and machine users have in the cluster

𝗦𝘁𝗼𝗿𝗮𝗴𝗲 & 𝗣𝗲𝗿𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝗲

PersistentVolume (PV) & PersistentVolumeClaim (PVC): Acts like an external HDD to the CNF.

StorageClass: Dynamically provisions and attaches high-speed block or file storage to the CNF

𝗦𝗰𝗮𝗹𝗲, 𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴 & 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆

Namespace: Logical partition of a physical cluster, used in multi-tenancy (e.g., separating Dev, Staging, and Production).

Taints, Tolerations & NodeAffinity: Pod scheduling on specific nodes, like control plane pods on normal nodes & user plane pods on SRIOV-enabled nodes

Custom Resource Definition (CRD) & Operator: Encodes human domain knowledge into software automation (e.g., orchestrating an entire 5G Core Network function lifecycle) directly inside the Kubernetes control plane.
Deployment: Ensures zero-downtime rolling updates and self-healing for stateless enterprise services, like subscriber billing portals.

StatefulSet: Guarantees stable network IDs and ordered persistence for mission-critical stateful backends, like telecom subscriber databases.

DaemonSet: Runs a copy of an agent on every cluster node to guarantee cluster-wide log shipping, security monitoring, or telecom node-level telemetry.

Finally, each one of the above will create a pod

𝗡𝗲𝘁𝘄𝗼𝗿𝗸𝗶𝗻𝗴 & 𝗧𝗿𝗮𝗳𝗳𝗶𝗰 𝗥𝗼𝘂𝘁𝗶𝗻𝗴

Service (ClusterIP / NodePort / LoadBalancer): Provides a stable virtual IP and internal DNS name so upstream services can consistently reach dynamic backend pods without tracking individual IP changes.

Ingress / Gateway API: Acts as the smart traffic controller at the cluster edge to manage external subscriber traffic and URL-based routing.

NetworkPolicy: Layer 3 & 4 routing within the cluster to isolate sensitive payment gateways or core telecom signaling networks from general enterprise traffic.

𝗖𝗼𝗻𝗳𝗶𝗴𝘂𝗿𝗮𝘁𝗶𝗼𝗻 & 𝗦𝗲𝗰𝘂𝗿𝗶𝘁𝘆

ConfigMap: Injects non-sensitive data (feature flags or routing tables) into microservices without requiring container rebuilds.

Secret: Securely stores and delivers sensitive credentials, API tokens, and encryption keys to meet enterprise compliance standards.

RBAC (Role & RoleBinding) & ServiceAccount: Restricts user and machine access strictly by business role, preventing unauthorized changes to core network functions.

𝗦𝘁𝗼𝗿𝗮𝗴𝗲 & 𝗣𝗲𝗿𝘀𝗶𝘀𝘁𝗲𝗻𝗰𝗲

PersistentVolume (PV) & PersistentVolumeClaim (PVC): Decouples physical enterprise SAN/NAS storage infrastructure from application logic, allowing databases to retain subscriber call records even if pods crash.

StorageClass: Dynamically provisions and attaches high-speed block or file storage on demand to meet varying throughput SLAs for high-volume billing or logging.

𝗦𝗰𝗮𝗹𝗲, 𝗦𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴 & 𝗥𝗲𝗹𝗶𝗮𝗯𝗶𝗹𝗶𝘁𝘆

Namespace: Partitions physical cluster resources into isolated virtual environments to support enterprise multi-tenancy (e.g., separating Dev, Staging, and Production).

Taints, Tolerations & NodeAffinity: Pins performance-sensitive telecom network functions (e.g., DPDK-enabled packet processing) exclusively to specialized bare-metal or high-throughput hardware nodes.

Custom Resource Definition (CRD) & Operator: Encapsulates complex, automated operational knowledge (e.g., orchestrating an entire 5G Core Network function lifecycle) directly inside the Kubernetes control plane.

22/08/2026

Small explainer 9 - 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗖𝗥𝗗𝘀 𝗮𝗻𝗱 𝗢𝗽𝗲𝗿𝗮𝘁𝗼𝗿𝘀

Official definition - They are extended controllers managing new API objects

Here is an easy explanation-

𝗧𝗵𝗲 𝗞𝘂𝗯𝗲𝗿𝗻𝗲𝘁𝗲𝘀 𝗖𝗼𝗿𝗲: Preset Coffee options like Latte, Cappuccino, et.

𝗖𝗥𝗗: A new custom button installed on the machine labeled "Brew Espresso" along with a slot to specify temperature and bean roast. It defines what you can ask for, but doesn't brew anything on its own.

𝗢𝗽𝗲𝗿𝗮𝘁𝗼𝗿: An automated robot barista standing by the machine. The moment someone presses "Brew Espresso", the Barista reads the recipe, grinds the specific beans, monitors the extraction pressure, and cleans the steam wand afterward.

Now replace the following in this concept

Preset options (Latte, Cappuccino, etc) - Standard K8s objects like pods, services, deployments, etc.

CRD - An extension mechanism that registers a new object type with the Kubernetes API

Operator - A custom controller running inside the cluster that continuously monitors the new CRD and automatically reconciles the desired state with the actual state.

More details in the picture below

20/08/2026

Small explainer 8 - 𝗘𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗶𝗻 𝗞𝟴𝘀 𝗶𝘀 𝗮 𝗟𝗶𝗻𝘂𝘅 𝗰𝗼𝗻𝗰𝗲𝗽𝘁 𝗶𝗻 𝘁𝗵𝗲 𝗯𝗮𝗰𝗸𝗴𝗿𝗼𝘂𝗻𝗱

How many of us can correlate each Kubernetes concept to its corresponding Linux process in the background?

Kubernetes is essentially a distributed control plane that automates the creation and lifecycle of Linux namespaces, cgroups, and iptables rules across many machines — nothing more magical than that.

For ex -

1. Container is Linux (Namespaces + cgroups)
2. Pods are a shared Linux namespace
3. K8s services are Linux iptables
4. Container Image is an OverlayFS
......and the list goes on

Kubernetes doesn't invent new technology — it orchestrates existing Linux kernel features at scale. Here's the mapping:

15/08/2026

On Independence Day, a thought for infra folks:

True independence in tech isn't just about who owns the hardware — it's about who controls the stack.

Every time we choose open standards over proprietary lock-in — OpenStack over closed clouds, Kubernetes over walled gardens, GitOps over manual gatekeeping — we're building digital sovereignty into the systems we run.

This , here's to architectures that give teams freedom to choose, scale, and own their infrastructure destiny.