Skip to content

Helm integration #58

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

bussyjd
Copy link

@bussyjd bussyjd commented Apr 23, 2025

This PR introduces the first stage of Helm integration into the MCP server, following the project’s architectural guidelines of using the Helm Go SDK (not the Helm CLI) for native Kubernetes and Helm operations.

Key Features:

  • Adds a new pkg/helm package that abstracts Helm operations using the Helm Go SDK.
  • Implements listing of Helm releases across namespaces.
  • Exposes new MCP server methods for:
    • Listing all Helm releases (helmReleasesList)
    • Listing Helm releases in a specific namespace (helmListInNamespace)
  • Filters out chart templates and files from the returned release data for clarity and performance.
  • Updates API and internal logic to support this integration.

Motivation

  • This is the foundation for Helm support in MCP, enabling multi-namespace release visibility and setting the stage for future enhancements such as repository management, install/uninstall, and chart discovery.

How to Test
npx @modelcontextprotocol/inspector@latest $(pwd)/kubernetes-mcp-server

Roadmap / Next Steps

Future PRs will add:

  • Helm repo add/remove/update
  • Helm install (with dry-run support)
  • Helm uninstall
  • Helm search hub (chart discovery)

Related Issue
Closes #55

@manusa
Copy link
Owner

manusa commented Apr 26, 2025

Thanks for contributing, I'll review it ASAP

Comment on lines +15 to +24
type Helm struct {
settings *cli.EnvSettings
}

// NewHelm creates a new Helm instance (optionally for a specific kubeconfig)
func NewHelm() *Helm {
return &Helm{
settings: cli.New(),
}
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good start, but it's inconsistent with the current behavior and usage of client-go.

It's a requirement that helm shares the settings used by client-go and are resolved here:

func resolveKubernetesConfigurations(kubernetes *Kubernetes) error {
// Always set clientCmdConfig
pathOptions := clientcmd.NewDefaultPathOptions()
if kubernetes.Kubeconfig != "" {
pathOptions.LoadingRules.ExplicitPath = kubernetes.Kubeconfig
}
kubernetes.clientCmdConfig = clientcmd.NewNonInteractiveDeferredLoadingClientConfig(
&clientcmd.ClientConfigLoadingRules{ExplicitPath: pathOptions.GetDefaultFilename()},
&clientcmd.ConfigOverrides{ClusterInfo: clientcmdapi.Cluster{Server: ""}})
var err error
if kubernetes.IsInCluster() {
kubernetes.cfg, err = InClusterConfig()
if err == nil && kubernetes.cfg != nil {
return nil
}
}
// Out of cluster
kubernetes.cfg, err = kubernetes.clientCmdConfig.ClientConfig()
if kubernetes.cfg != nil && kubernetes.cfg.UserAgent == "" {
kubernetes.cfg.UserAgent = rest.DefaultKubernetesUserAgent()
}
return err
}

genericclioptions.ConfigFlags internally uses a clientConfig (clientcmd.ClientConfig).

Once the cli.EnvSettings are fully resolved, the private fields should match those that we use internally in kubernetes-mcp-server.

so we probably want some sort of logic that overrides some of the settings after doing cli.New().

I did something similar here:

https://github.com/manusa/helm-java/blob/33107680bfaa1a2614f2693449ab13c6a8b54d14/native/internal/helm/helm.go#L58-L92

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add Helm Support to MCP Server
2 participants