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 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