Kubernetes

Kubernetes uses a declarative model where users define the desired state of their system (e.g., 'run 5 replicas of this container') in YAML or JSON manifests. The control plane continuously observes the cluster's actual state and reconciles it with the declared desired state. This is managed by core controllers like the Deployment controller. For example, if a Pod crashes, the controller automatically starts a new one to match the declared replica count.

The kube-scheduler is responsible for placing Pods onto available Nodes in the cluster. It automatically makes scheduling decisions based on:

• Resource requests and limits (CPU, memory).
• Affinity/Anti-affinity rules (e.g., spread Pods across zones).
• Taints and tolerations (for dedicating nodes to specific workloads).
• Custom policies and scoring. This automated bin packing maximizes resource utilization across the cluster, efficiently placing workloads where resources are available.

Kubernetes provides robust self-healing mechanisms to maintain application availability:

• Restarts containers that fail.
• Replaces Pods that do not pass health checks.
• Reschedules Pods when nodes die.
• Exposes user-defined liveness and readiness probes. For deployments, it supports automated update strategies like rolling updates and blue-green deployments via Deployment objects, allowing zero-downtime application upgrades and easy rollbacks.

Kubernetes abstracts Pod IP volatility with the Service object, which provides a stable IP address and DNS name for a dynamic set of Pods. It automatically load-balances traffic across healthy Pods. Core service types include:

• ClusterIP: Internal service within the cluster.
• NodePort: Exposes the service on a static port on each node.
• LoadBalancer: Provisions an external cloud load balancer.
• Ingress: Manages external HTTP/S traffic with routing rules, often using controllers like ingress-nginx.

Kubernetes can automatically scale applications and the cluster itself based on demand:

• Horizontal Pod Autoscaler (HPA): Scales the number of Pod replicas based on observed CPU utilization, memory, or custom metrics.
• Vertical Pod Autoscaler (VPA): Adjusts the CPU and memory requests/limits of Pods based on usage history.
• Cluster Autoscaler: For cloud environments, automatically adds or removes nodes from the cluster to match resource needs for pending Pods.

Kubernetes is designed to be extended. The Custom Resource Definition (CRD) API allows users to define new resource types (e.g., Database, MLModel). The Operator Pattern uses these CRDs along with custom controllers to package and automate the management of complex, stateful applications (like databases or message queues), encoding human operational knowledge into software. This turns Kubernetes into a universal control plane for any workload.

A set of tightly or loosely connected computers, known as nodes, that work together as a single system to provide increased processing power, storage capacity, and reliability for parallel computing workloads.

• Master Node: Hosts the control plane components (API server, scheduler, controller manager) that manage the cluster state.
• Worker Nodes: Run the actual application workloads in Pods. For simulation, these are often GPU-equipped servers.
• Kubernetes Role: Turns a collection of physical or virtual machines into a unified, programmable compute fabric.

The practice of aggregating computing power, typically using clusters of servers or supercomputers, to solve complex computational problems beyond the capability of a single machine. Kubernetes is increasingly used to manage modern, cloud-native HPC workloads.

• Traditional vs. Kubernetes HPC: Traditional HPC uses schedulers like Slurm for tightly-coupled MPI jobs. Kubernetes excels at managing loosely-coupled, containerized workloads like parallel simulation jobs, offering superior flexibility and DevOps integration.
• Use Case: Running thousands of parallel physics simulations for robotic policy training, each in its own container.

A cloud computing feature that automatically adjusts the amount of computational resources allocated to an application based on its current demand. In Kubernetes, this occurs at two levels:

• Horizontal Pod Autoscaler (HPA): Scales the number of Pod replicas based on observed CPU/memory usage or custom metrics.
• Cluster Autoscaler: Adds or removes worker nodes from the cluster itself based on the resource needs of pending Pods.
• Simulation Impact: Allows a training pipeline to dynamically scale from 10 to 10,000 parallel simulation instances as needed, optimizing cost and speed.

A Kubernetes extension mechanism that allows users to create and manage new types of resources, called Custom Resources, which behave like native Kubernetes objects (e.g., Pods, Deployments).

• Purpose: Enables the Kubernetes API to be extended for domain-specific applications. For example, you could define a SimulationJob CRD.
• Operator Pattern: CRDs are typically managed by a corresponding Controller (Operator), which contains the operational logic to manage the custom resource's lifecycle.

A method of packaging, deploying, and managing a Kubernetes application using a custom controller and Custom Resource Definitions (CRDs) to encode human operational knowledge into software.

• How it Works: The Operator is a custom controller that watches for changes to specific Custom Resources (e.g., RobotSimulationCluster) and takes actions to ensure the real-world state matches the desired state declared in the resource.
• Simulation Example: An operator could automate the complex setup, scaling, and tear-down of a distributed simulation environment, handling tasks like loading terrain assets and distributing physics engines across nodes.