Google Summer of Code 2026

The Kubeflow Community plans to participate in Google Summer of Code 2026. This page aims to help you participate in GSoC 2026 with Kubeflow.

What is GSoC?

Google Summer of Code (GSoC) is a global program that offers students stipends for working on open-source projects during the summer.

For more information, see the GSoC FAQ and watch the video below:

How can I participate?

Thank you for your interest in participating in GSoC with Kubeflow!

Please carefully read the following information to learn how to participate in GSoC with Kubeflow.

Key Dates

Here are the key dates for GSoC 2025, the full timeline is available on the GSoC website:

Eligibility

To participate in GSoC with Kubeflow, you must meet the GSoC eligibility requirements:

• Be at least 18 years old at time of registration.
• Be a student or an open source beginner.
• Be eligible to work in their country of residence during duration of program.
• Be a resident of a country not currently embargoed by the United States.

Steps

1. Sign up as a student on the GSoC website.
2. Join the Kubeflow Slack:
   • NOTE: please do not reach out privately to mentors, instead, start a thread in the #kubeflow-contributors channel so others can see the response.
3. Learn about Kubeflow:
   • Read the Introduction to Kubeflow
   • Review the Architecture Overview
   • Consider trying out Kubeflow (not required, can be challenging)
4. Review the project ideas to decide which ones you are interested in:
   • You may wish to attend the next community meeting for the group that is leading your chosen project.
   • NOTE: while we recommend you submit a proposal based on the project ideas, you can also submit a proposal with your own idea.
5. Submit a proposal through the GSoC website between March 16th and March 31st:
   • Please see these guidelines on how to write a good proposal.
   • Kubeflow requests that you use this template for your proposal.
   • You will need to submit PDF version of your proposal on GSoC website before March 30th, 2026.
6. Wait for the results to be announced on May 8th.

Project Ideas

Project 1: Agentic RAG on Kubeflow (Expansion of kubeflow/docs-agent)

Components: Kubeflow Pipelines (KFP), KServe, Manifests (Deployment/Infra), LLM Agents

Mentors: @chasecadet, @tarekabouzeid (Tarek Abouzeid - Kubeflow Platform)

Contributor: Details:

Project Overview & Scope: This project aims to evolve the existing kubeflow/docs-agent from a simple retrieval tool into a robust Reference Architecture for Agentic RAG on Kubeflow. Currently, the tool performs basic lookups. The GSoC contributor will upgrade this to an agentic workflow that can intelligently parse user questions, access the Kubeflow Git repository and Reference Platform Architecture as tools, and provide cited, technical answers. The core goal is “Dogfooding”: We want to use Kubeflow to build the AI that helps users learn Kubeflow.

Key Deliverables (GSoC Scope):

• Agentic Architecture: Implement an agent (using frameworks like LangGraph or Kagent) running on Kubeflow that can query specialized indices (Documentation, GitHub Issues, Platform Architecture).
• Ingestion Pipelines: Build reusable Kubeflow Pipelines (KFP) to scrape, chunk, and index “Golden Data” from our reference architectures, establishing a best-practice pattern for data handling.
• Local Serving via KServe: Demonstrate how to serve the agent’s LLM (e.g., Llama 3) using KServe on the cluster, utilizing Scale-to-Zero to handle bursty workloads efficiently.
• Deployment Reference: Create the Terraform/Manifests required to deploy this entire stack on Oracle Cloud Infrastructure (OCI), serving as a reproducible reference for the community.

Future Vision (Context for the Contributor): While beyond the immediate GSoC scope, this project lays the foundation for advanced capabilities:

• Fine-Tuning & Routing: Future iterations will use KFP to fine-tune specialized “Router” models that direct queries to specific agents.
• Security (MCP & Istio): We envision integrating the Model Context Protocol (MCP) and using Istio sidecars to secure agent-to-tool communication.

The GSoC contributor is building the bedrock layer that these future innovations will stand upon.

Community Value:

• “Golden Data” Standard: By curating the data for this agent, we will identify gaps in our documentation and create a trusted dataset of “verified” configurations that the community can use to benchmark their own internal platforms.
• Helm Alignment: This project will validate the new community Helm charts by acting as a “consumer,” providing feedback on their ease of deployment in a complex GenAI stack.
• Platform Alignment: We will work closely with Tarek Abouzeid to align with the Kubeflow Platform Documentation. The project must clearly separate Core Kubeflow Services (portable) from Cloud-Specific Adapters (OCI), ensuring the agentic architecture remains portable for any user.

Ideas and references:

• Current Repo: kubeflow/docs-agent
• Platform Standards: Kubeflow Platform Docs
• Infrastructure: Terraform OCI Provider Docs

Difficulty: Hard

Size: 350 hours

Skills Required/Preferred:

• Python (Backend, Agent logic)
• Kubeflow (Pipelines, KServe)
• GenAI/LLM Ops (RAG, Vector Databases)
• Infrastructure (Terraform, Docker, Kubernetes)
• Communication (Ability to document architectural decisions clearly)

Project 2: OptimizationJob CRD for Hyperparameter Optimization

Components: kubeflow/katib, kubeflow/sdk, kubeflow/trainer

Mentors: @akshaychitneni, @andreyvelich

Contributor:

Details:

Hyperparameter optimization (HPO) is critical for maximizing model performance in machine learning workflows. While Katib currently provides HPO capabilities through the Experiment CRD, it was designed for broad use cases including Neural Architecture Search (NAS) and arbitrary workloads.

This project aims to design and implement a new OptimizationJob CRD (optimizer.kubeflow.org/v1alpha1) specifically focused on hyperparameter optimization for TrainJobs. The new CRD will provide:

• Tighter TrainJob Integration: Replace unstructured trial specifications with typed TrainJob templates, enabling strong validation
• Shared Initialization: Implement a common initializer pattern that runs once and shares model/dataset artifacts across all trials reducing trial startup time and storage costs
• Simplified API: Focus exclusively on HPO use cases
• Modern Metrics Collection: Support push-based metrics reporting via the Kubeflow SDK
• SDK Alignment: Integrate with OptimizerClient API from KEP-46: Hyperparameter Optimization in Kubeflow SDK

Tracking issue: kubeflow/katib#2605

Difficulty: Hard

Size: 350 hours (Large)

Skills Required/Preferred:

• Go
• Python
• Familiarity with Kubernetes controllers, CRDs
• Basic understanding of machine learning training workflows
• Experience with HPO frameworks

Project #: End-to-End ARM64 Support & Validation on Kubeflow

Components: Manifests (Platform), Kubeflow Pipelines (KFP), Katib, Notebooks, Trainer

Mentors: @chasecadet, @jtu-ampere (Mentor)

Owning Team: ARM Contributions Team

Contributor:

Details:

Context & Vision: As development teams increasingly move to Apple Silicon (M-series chips) and production workloads shift to cost-efficient ARM-based cloud instances (like OCI Ampere, Google Axion, and AWS Graviton ), ARM64 support is a critical requirement for the future of Kubeflow.

Currently, support is fragmented. The ARM Contributions Team aims to close this gap by establishing First-Class Citizen support for ARM64 across the entire Kubeflow Reference Platform. This initiative is not just about compiling binaries; it is about validating the “Kubeflow Platform” experience to ensure it is robust, reproducible, and ready for diverse environments.

Strategic Alignment: This work directly supports the Kubeflow Platform Definition. By validating the end-to-end platform on non-x86 architectures, the team serves as a critical quality gate, ensuring that “Kubeflow” remains a consistent standard regardless of the underlying hardware.

Collaboration & History:

This project builds upon the extensive groundwork laid by the ARM Support Team, who have previously validated and built many of these images. The goal is to upstream this foundational work—porting validated Dockerfiles, build flags, and image tags into the official Kubeflow repositories—effectively making the community’s “best effort” success the official standard. Scope & Deliverables

Scope & Deliverables:

1. Multi-Arch Build System (CI/CD)

   Audit & Standardization: The team will identify every container image in the official kubeflow/manifests release that lacks an ARM64 variant.

   Pipeline Implementation: Update build systems (GitHub Actions/Prow) to generate multi-arch manifests (AMD64/ARM64) automatically on release. The goal is a single tag (e.g., :v2.0.0) that pulls the correct image for the host architecture.

2. Platform Manifest Validation

   Architecture Agnosticism: Ensure official Kustomize manifests do not hardcode architecture-specific SHA hashes or incompatible image tags, ensuring the manifests apply cleanly regardless of the node architecture.

3. Infrastructure: Cloud & Edge

   Cloud Validation (OCI): Leverage Oracle Cloud Infrastructure (OCI) Ampere A1 instances to maintain a persistent “Golden” test environment.

   Stretch Goal: On-Premise & Edge Demonstration: A key stretch goal for this team is to demonstrate Kubeflow running on on-premise ARM hardware.

   The “Why”: This serves as the ultimate proof of Kubeflow’s portability. By successfully deploying to an edge environment (outside of managed cloud services), we demonstrate that Kubeflow is truly infrastructure-agnostic and ready for Edge AI use cases.

4. End-to-End (E2E) Platform QA

   Full Suite Testing: Run the full Kubeflow End-to-End test suite on ARM infrastructure to catch architecture-specific bugs (e.g., generic libc dependencies, JIT compiler issues in TensorFlow/PyTorch).

   Documentation & “Golden Data”: Generate a “Golden Data” set of known-good configurations for running Kubeflow on ARM. This includes documentation on “gotchas” for users running local development clusters on Apple Silicon (Kind/Minikube).

Difficulty: Medium/Hard (Depends on CI/CD complexity)

Size: 350 hours

Tracking & References:

• KFP Issue: Build and publish ARM images for KFP #10309
• Manifests Issue: Support for the aarch64 architecture #2745

Team Capabilities & Stack:

• Docker/Containerization: Deep understanding of multi-arch builds (docker buildx, manifests).
• CI/CD: GitHub Actions (primary), Prow (secondary).
• Kubernetes: Kustomize, Manifest management.
• Go/Python: Ability to debug build scripts and genericize code that assumes x86 architecture.
• Infrastructure: Familiarity with cloud instances and bare-metal/edge hardware configuration.

Project 3: KServe Models Web Application

Components: Kserve, Kubeflow Common Library, Kubeflow Dashboard

Mentors: Griffin Sullivan, Harshit Nayan, Dhanisha Phadate

Contributor:

Details: The project includes improving test coverage and cleanup, adding end-to-end and deployment-level testing, and validating the application through full deployment workflows. It also migrates the repository from KServe to Kubeflow and extends the UI to support KServe v0.16/0.17 features, including LLMInferenceService and InferenceGraph.

This project modernizes the KServe Models Web Application by upgrading Angular from v14 to v16+. The Kubeflow common library will be upgraded first, followed by updates to Dockerfiles, Makefiles, workflows and documentation.

Difficulty: Hard

Size: 350 hours

Skills Required/Preferred:

• Angular & TypeScript
• Kubernetes and CRDs
• Docker and CI/CD
• Kubeflow / KServe (preferred)

Project 4: Platform Scalability and Security

Components: Kubeflow Manifests, Kubeflow Pipelines, Kubeflow Training Operator

Mentors: Julius von Kohout

Contributor:

Details: As Kubeflow scales to environments with 1,000+ namespaces, core bottlenecks emerge. This project focuses on optimizing CRD controllers, improving multi-tenancy security, and hardening the platform. Key work areas include: refactoring the Profile Controller to use Metacontroller for a cleaner plugin system, migrating from Istio Gateway to the Kubernetes Gateway API and enabling Model Registry by default. Many CRD controllers are written inefficiently and struggle with the reconciliation load or block the Kubernetes API server with too many requests. Using “Kubernetes user namespaces” for PSS baseline in the level in PSS restricted will also be an explorative task.

Difficulty: Hard

Size: 350 hours

Related Issues/PR:

• Rootless Kubeflow
• Enable model-registry with UI by default
• Update kserve/kserve manifests from v0.16.0
• Fix kustomize warnings
• Migrate to gateway API
• “zero-trust” security / networking for training jobs
• fix: variable namespaces for networkpolicies
• Recurring Runs Queue Throughput Optimization
• Add securityContext support for container components
• add gRPC metrics to api-server (RPS/latency), optimize execution spec reporting
• ConfigMap-based plugin system for profile controller
• fix(frontend): Prevent Unauthorized Cross-Namespace Artifact Access
• Kubeflow platform pull requests

Skills Required/Preferred:

• Go
• Kubernetes
• Python
• Istio
• Networking
• Linux Security

Project 5: Helm Charts

Components: Kubeflow Manifests, Kubeflow Pipelines, Kubeflow Katib

Mentors: Julius von Kohout, Humair Khan, Dhanisha Phadate

Contributor:

Details: This project continues the KSC-approved initiative to provide Kubeflow platform and standalone components via Helm. The goal is to move beyond Kustomize-only deployments to offer minimalistic, maintainable Helm charts that reflect Kustomize defaults 1:1. Key tasks include: developing and testing Helm charts for KFP and Katib, implementing CI/CD testing infrastructure for Helm-based deployments and coordinating with component maintainers to ensure cross-project consistency.

This project will touch most components and continue the helm chart initiative started by Kunal Dugar who also helped a lot with the testing infrastructure. This will therefore also include working with maintainers of other components such as KFP maintainersfor the KFP helm charts, security and scalability topic or Katib maintainers for Katib helm charts. Some have already open PRs and there was a formal vote by the KSC (Kubeflow steering Committee) that we are moving forward with offering Kubeflow platform and standalone components as helm charts. Therefore it is not just the technical part, but also the coordination effort. The goal is to make minimalistic helm charts that are easy to maintain next to kustomize and only expose sensible settings relevant to most users. For the time being the rendered chart default values must replicate kustomize 1:1. The testing infrastructure has already been set up in the GSOC 2025 efforts in kubeflow/manifests where we already have a few helm charts.

Difficulty: Hard

Size: 350 hours

Related Issues/PR:

• Pipeline Helm Charts
• Helm Chart Templates For Katib
• Helm charts (KEP 831)
• Fix the remaining Kustomize 5 warnings

Skills Required/Preferred:

• Helm
• Kustomize
• Kubernetes
• GitHub Actions
• Bash
• Community Coordination

Project 6: MCP Server for Kubeflow SDK

Components: kubeflow/sdk, kubeflow/trainer

Mentors: @jaiakash, @dhanishaphadate, @abhijeet-dhumal

Contributor: [TBD]

Details: The Kubeflow SDK allows users with limited Kubernetes knowledge to use standard Python APIs to interact with the Kubeflow ecosystem. Documentation: https://sdk.kubeflow.org/en/latest/index.html

Most of us use LLMs to create/debug code for jobs, models, etc., but currently there is no mechanism for the LLM to see TrainJob status, debug a crash loop, or provide consolidated metrics about previous tasks. We want to extend and improve the Developer Experience (DX) with a Model Context Protocol (MCP) server for the Kubeflow ecosystem.

We have a kubeflow/community#936 and an existing MVP for this project. The contributor will extend the MCP server to cover additional use cases, improve error handling, add comprehensive documentation, and potentially integrate with other Kubeflow components like Model Registry.

Core Deliverables:

• MCP tools for TrainJob lifecycle (fine_tune, get_training_job, list_training_jobs, delete_training_job)
• Pre-flight validation (get_cluster_resources, estimate_resources, check_training_prerequisites)
• Job observability (get_training_logs, get_job_events)
• Storage setup (setup_training_storage)

Stretch Goals:

• Policy-based access control (persona-based RBAC)
• Custom trainer support (run_custom_training, run_container_job)
• Integration with Model Registry MCP catalog
• Progress tracking (pending KEP-937)

Tracking issue: https://github.com/kubeflow/sdk/issues/238

Difficulty: Medium

Size: 175 hours (Medium)

Skills Required/Preferred:

• Experience with LLM / MCP development.
• Familiarity with the Kubeflow SDK and Trainer codebase.
• Understanding of the Kubeflow Ecosystem and basic Kubernetes concepts.
• Engage and contribute to Kubeflow community on Slack and GitHub.

Project 7 : Integrate Kubeflow SDK with OpenTelemetry

Components: kubeflow/sdk

Mentors: @kramaranya, @dhanishaphadate, @jaiakash

Contributor:

Details:

The Kubeflow SDK enables users with limited Kubernetes knowledge to interact with the Kubeflow ecosystem using standard Python APIs. As AI/ML workloads become more complex and distributed, observability into pipeline execution, model training, and inference workflows becomes critical.

This project aims to integrate the Kubeflow SDK with OpenTelemetry (OTel) to provide standardized, vendor-neutral telemetry for Kubeflow-based workloads. The integration will enable end-to-end visibility into SDK operations by capturing distributed traces, metrics, and logs across pipeline compilation, submission, execution, and training lifecycles.

The project will also explore leveraging existing OpenTelemetry and Generative AI instrumentation patterns—such as span conventions for model execution, prompt handling, and inference steps—where applicable.

Kubeflow SDK Documentation

Opentelemetry for genAI

Issue

Features Expected:

• Add OpenTelemetry instrumentation to key Kubeflow SDK components
• Enable distributed tracing for pipeline execution and SDK operations
• Collect and export metrics related to AI/ML workloads
• Provide configurable OTel exporters and sampling options
• Documentation and examples demonstrating observability setup and usage
• cover below SDK clients

kubeflow/
├── trainer/       # TrainerClient - distributed training & fine-tuning
├── optimizer/     # OptimizerClient - Katib AutoML & hyperparameter tuning  
├── hub/           # ModelRegistryClient - model artifact management
└── common/        # Shared utilities across clients

Bonus requirement to complete

Difficulty: [intermediate|hard]

Size: [350 hours]

Skills Required/Preferred:

• Python
• Understanding of the Kubeflow Ecosystem (preferred)
• OpenTelemetry (tracing, metrics, logging)
• Distributed systems and observability concepts
• Kubernetes and CRDs

Project 10: Dynamic LLM Trainer Framework for Kubeflow

Components: kubeflow/trainer, kubeflow/sdk

Mentors: @tariq-hasan, @andreyvelich

Contributor:

Details:

Kubeflow Trainer provides Kubernetes-native distributed ML training with a Python-first experience. It currently supports LLM fine-tuning through TorchTune as a built-in backend, but TorchTune is no longer actively adding new features, limiting support for emerging models and post-training methods (DPO, PPO, ORPO).

This project proposes a Dynamic LLM Trainer Framework that decouples Kubeflow Trainer from any single fine-tuning backend. The goal is to introduce a pluggable architecture enabling multiple frameworks to integrate seamlessly while preserving backward compatibility and a simple Python SDK. This builds on the existing plugin architecture in pkg/runtime/framework/plugins/torch/ and extends the BuiltinTrainer pattern in the SDK.

The framework will provide:

• A backend-agnostic LLM Trainer interface, symmetric to TrainingRuntime on the control plane
• Dynamic backend registration for in-tree and external frameworks
• TorchTune refactored as a first-class pluggable backend
• Faster day-0/day-1 support for new models and fine-tuning strategies
• Backward compatibility for existing TorchTune-based workflows

Initial backends to explore:

Beyond in-tree backends, the SDK should support external framework registration, mirroring how TrainingRuntime enables custom runtimes.

This project is well-suited for contributors interested in ML systems, API design, and bridging modern LLM tooling with production Kubernetes platforms.

Tracking issue: kubeflow/trainer#2839

Difficulty: Hard

Size: 350 hours (Large)

Skills Required/Preferred:

• Python, Go
• Familiarity with Kubernetes and Kubeflow Trainer architecture
• Experience with LLM fine-tuning frameworks (TRL, TorchTune, Unsloth)
• Understanding of distributed training concepts
• Interest in API and framework design

Project 11: Composable Kale Notebooks with Visual Pipeline Editor

Components: Kubeflow Kale

Mentors: Eder Ignatowicz, Stefano Fioravanzo

Contributor:

Details: This project extends Kale to support composition of multiple Kale notebooks into a single Kubeflow Pipeline. Each notebook becomes a first-class pipeline unit, with explicit inputs and outputs, allowing users to orchestrate multi-notebook workflows directly from the notebook environment.

A core requirement of the project is a visual editor that enables users to compose, configure, and reason about notebook-based pipelines graphically. The editor will align with existing JupyterLab UI patterns and extension APIs to minimize risk and ensure consistency with the Jupyter ecosystem.

Goals:

• Treat Kale notebooks as first-class pipeline components
• Define notebook-based workflows into a re-usable and shareable format
• Compose multiple Kale notebooks into a single pipeline
• Define explicit inputs and outputs between notebooks (parameters, artifacts)
• Integrate with Kubeflow Pipelines via @dsl.notebook_component
• Provide a visual editor aligned with existing JupyterLab UI patterns
• Support runtime configuration for pipeline execution
• Keep authoring and composition inside JupyterLab

Expected Outcomes:

• A visual pipeline editor integrated into JupyterLab
• A concrete model for Kale notebook composition and execution
• A reference implementation aligned with Kubeflow Pipelines
• Documentation and examples for multi-notebook workflows

Why This Project

Notebook workflows are commonly split across multiple files. Without visual composition, understanding and maintaining these workflows becomes difficult. Aligning the editor with existing JupyterLab UI patterns reduces implementation risk while improving clarity, usability, and maintainability.

Difficulty: Hard

Size: 350 hours

Related Issues/PR:

• Composable Kale Notebooks with Visual Pipeline Editor

Skills Required/Preferred:

• Python (Kale internals, Kubeflow Pipelines DSL)
• JavaScript / TypeScript (visual editor, JupyterLab extensions)
• Familiarity with Jupyter notebooks and pipeline concepts
• Experience or interest in working within established UI frameworks

Project 12: Kubeflow SDK/SparkClient - Batch Jobs, Observability & Production Readiness

Components: kubeflow/sdk (SparkClient), kubeflow/spark-operator

Mentors: @shekharrajak, @tariq-hasan

Contributor:

Details:

The Kubeflow SparkClient provides a unified Python API for running Apache Spark workloads on Kubernetes. The current MVP supports interactive Spark Connect sessions (KEP-107), but lacks batch job submission, usage with other kubeflow SDK Client, kubeflow components and production observability features.

This project extends SparkClient to support the complete Spark workflow on Kubernetes:

1. Batch Job Submission (Core Feature)

Implement submit_job() API for submitting batch Spark jobs via SparkApplication CRD:

• Python function mode: Serialize and execute user-defined functions
• Script mode: Submit existing PySpark/Scala scripts
• Job lifecycle: list_jobs(), get_job(), get_job_logs(), wait_for_job(), delete_job(), and more
• Integration with existing SparkClient patterns (options, validation, error handling)

2. Observability & Monitoring

Build monitoring capabilities for production Spark workloads:

• Metrics collection from Spark REST API (task stats, executor metrics, stage progress)
• Structured event streaming (task completion, failures, stage boundaries)
• Health checking and readiness probes
• Optional Prometheus metrics exporter

3. Data Transfer & Transform reading from Data LakeHouse

Tryout reading and connecting to data warehouse and data lakehouse:

• Real world usecases of ETL jobs
• Transform and enrich the data
• Use Kubeflow components along with SDK SparkClient

4. Documentation & Examples

• API reference documentation (auto-generated)
• Deployment, debug guide
• Troubleshooting guide
• Example notebooks (Jupyter/Colab)
• Examples for connecting to Spark Cluster - EMR/Apache Spark k8s

Technical Architecture:

• CRD builder for SparkApplication (similar to SparkConnect)
• Reuses existing validation, options, and error handling infrastructure
• Use different SDK clients and kubeflow components like Notebook.

Community Value:

• Completes the SparkClient vision from KEP-107
• Enables end-to-end Spark workflows (interactive development, batch & all different usecases)
• Aligns with Kubeflow’s mission of simplifying ML infrastructure
• Provides foundation for future Kubeflow Pipelines integration
• Showcase different ways of using SparkClient with Kubeflow Components

Related Issues/KEPs:

• KEP-107: Spark Client
• Initial SparkClient version
• Spark Operator SparkApplication CRD

Difficulty: Hard

Size: 350 hours (Large)

Skills Required/Preferred:

• Python (Core development)
• Kubernetes (CRDs, API, RBAC)
• Apache Spark (Architecture, Configuration)
• Testing (Unit, Integration, E2E)
• Technical Writing (Documentation)