Skip to main content
Katib Experiment is the Kubernetes-native resource for automated hyperparameter tuning. A single Experiment manifest declares the complete optimization workflow: which hyperparameters to search, which metric to optimize, which search algorithm to use, and how to run each trial. After you submit the manifest, Katib launches many trials across the cluster, collects metrics, and orchestrates the search automatically so you can find the best configuration without manual trial-and-error.
A presentation slide titled "What is a Katib Experiment?" describing Katib as the central resource for automated hyperparameter tuning on Kubernetes. The slide shows a hexagon telescope icon and five feature cards: automated workflow, how trials run, hyperparameter search space, optimization objective, and runs on Kubernetes.
Core components of a Katib Experiment
  • Objective metric: the metric Katib optimizes (for example, minimize loss or maximize accuracy).
  • Search algorithm: the exploration strategy (e.g., Random Search, Grid Search, Bayesian Optimization).
  • Parameter (search) space: ranges and types for each hyperparameter.
  • Trial template: the Kubernetes workload template that runs each training trial and how sampled parameters are injected.
A presentation slide titled "Experiment Components" showing four rounded cards: Objective Metric, Search Algorithm, Parameter Space, and Trial Template. Each card gives a short description about what to optimize (loss/accuracy), how Katib explores hyperparameter space, allowed hyperparameter ranges, and how training jobs run on Kubernetes.
Define the search space The search space constrains which hyperparameter values Katib can try. You typically define numeric ranges, discrete choices, or categorical values. For example, when tuning a decision-tree-based model you might vary the number of estimators and maximum depth; Katib will sample combinations from those feasible ranges.
A presentation slide titled "Define the Search Space" showing feasible ranges for two hyperparameters with blue slider bars: n-estimators (50–200) and max-depth (3–15). The slide includes a "FEASIBLE RANGE (min → max)" label and a © KodeKloud copyright in the corner.
Trial template and parameter injection Each trial is a standalone Kubernetes workload. The trial template shows how to run your training job and how sampled parameters are substituted into the container command or environment. Below is an example fragment of a trial template command where Katib injects sampled parameters:
Submitting and running an Experiment Once your Experiment YAML is ready, submit it to the cluster:
Katib will create Trials, schedule training jobs, collect metrics, and continue the search until stopping criteria are met (e.g., max trials, max time, or converged objective).
Ensure you use the correct namespace for your Katib installation (commonly kubeflow — lowercase) when running kubectl commands.
Monitoring Katib Use standard Kubernetes commands to inspect Experiments and watch Trials as they run:
Benefits of using Katib Katib automates what would otherwise be manual experimentation. Instead of single-threaded trial-and-error, you get:
  • Parallel trials across the cluster
  • Continuous metric aggregation and evaluation
  • Built-in search algorithms and pluggable strategies
  • Kubernetes-native scheduling and resource management
A presentation slide titled "What We Achieved with Katib" comparing "Before" and "With Katib" outcomes. It shows three swaps: trial-and-error guessing → automated tuning, one model at a time → distributed experimentation, and hours of babysitting jobs → Kubernetes-native scheduling.
Further reading and references This Kubernetes-native approach to hyperparameter tuning is a central idea in modern MLOps: automate repetitive experimentation, scale with Kubernetes, and accelerate model development by letting Katib explore the configuration space for you.

Watch Video