Kubernetes

Introduction TL;DR: Kubeflow is an ecosystem for running reproducible ML workflows on Kubernetes—from notebooks and pipelines to distributed training and model serving. (Kubeflow) In practice, “using Kubeflow” means wiring together Profiles/Namespaces, Notebooks, Pipelines (KFP), training (Trainer), tuning (Katib), and serving (KServe) with clear operational boundaries. (Kubeflow) 1) What “Kubeflow” is in 2026: Projects vs Platform Kubeflow can be installed as standalone projects (e.g., Pipelines-only) or as the integrated Kubeflow AI reference platform. The official “Installing Kubeflow” guide explicitly frames these as two installation methods. (Kubeflow) ...

Introduction TL;DR MoE activates only a small subset of expert FFNs per token (conditional computation), scaling total capacity without proportional per-token compute. In Transformers, the mainstream pattern is replacing the dense FFN/MLP with an MoE FFN (router + experts). Production bottlenecks often come from routing imbalance, capacity overflow (drops), all-to-all communication, and memory bandwidth; serving requires observability and cluster tuning. Why it matters: MoE is a combined model + distributed-systems problem, not just a modeling trick. ...

Introduction TL;DR: Kubernetes Volumes provide a durable storage solution to solve the ephemeral nature of container filesystems, ensuring data persists even when a Pod restarts. The core of Kubernetes storage is an abstraction layer consisting of three key objects: PersistentVolume (PV), PersistentVolumeClaim (PVC), and StorageClass. An administrator defines available storage as a PV, a user requests storage with a PVC, and a StorageClass enables the dynamic, automatic provisioning of PVs to satisfy PVCs, streamlining storage management in cloud environments. By default, a container’s filesystem is ephemeral. Any data created inside a container is lost when the container is terminated and restarted. To run stateful applications like databases, it’s essential to have a mechanism for persistent storage. Kubernetes Volumes address this by decoupling the storage lifecycle from the Pod lifecycle. A Volume is essentially a directory, accessible to the containers in a Pod, whose data can be preserved across container restarts. ...

Introduction TL;DR: The Kubernetes NodePort service exposes an application to external traffic by opening a specific port on every node in the cluster. It maps an external port (default range: 30000-32767) to an internal service’s port, allowing access via <NodeIP>:<NodePort>. NodePort is a straightforward way to expose services, primarily used for development, testing, or demo purposes, as it lacks the production-grade features of LoadBalancer or Ingress. The Kubernetes NodePort is a fundamental service type that provides external access to applications running within a cluster. In Kubernetes, Pods are ephemeral and have dynamic IP addresses, making direct access unreliable. Services solve this by providing a stable endpoint. A NodePort service builds upon the internal-only ClusterIP service by making that service accessible from outside the cluster through a static port on each worker node’s IP address. ...

Kubernetes Pod Resource Management: Requests, Limits, and QoS Question: “How do I control CPU and memory usage for Pods in Kubernetes?” If resource limits are not set, a single Pod can consume excessive CPU or memory, causing instability across the cluster. Kubernetes provides Requests and Limits to manage resources effectively.

In this guide, we’ll explore Longhorn, a lightweight, reliable, and open-source distributed block storage system for Kubernetes. You’ll learn what Longhorn is, how it works, how to install it using Helm, and how to monitor it with Grafana and Prometheus. Table of Contents 1. What is Longhorn? Longhorn turns the local disks of your Kubernetes cluster nodes into persistent volumes — making stateful apps like databases possible in Kubernetes. Think of it this way: ...