Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://docs.stacklok.com/toolhive/guides-k8s/deploy-operator-helm below:

Deploy the operator | Stacklok Docs

Helm is the officially supported method to install the ToolHive operator in a Kubernetes cluster.

• A Kubernetes cluster (current and two previous minor versions are supported)
• Permissions to create resources in the cluster
• kubectl configured to communicate with your cluster
• Helm (v3.10 minimum, v3.14+ recommended)

The ToolHive operator requires Custom Resource Definitions (CRDs) to manage MCPServer resources. The CRDs define the structure and behavior of MCPServers in your cluster.

helm upgrade -i toolhive-operator-crds oci://ghcr.io/stacklok/toolhive/toolhive-operator-crds

This command installs the latest version of the ToolHive operator CRDs Helm chart. To install a specific version, append --version <VERSION> to the command, for example:

helm upgrade -i toolhive-operator-crds oci://ghcr.io/stacklok/toolhive/toolhive-operator-crds --version 0.0.7

To install the ToolHive operator using default settings, run the following command:

helm upgrade -i toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator -n toolhive-system --create-namespace

This command installs the latest version of the ToolHive operator CRDs Helm chart. To install a specific version, append --version <VERSION> to the command, for example:

helm upgrade -i toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator -n toolhive-system --create-namespace --version 0.1.1

Verify the installation:

kubectl get pods -n toolhive-system

After about 30 seconds, you should see the toolhive-operator pod running.

Check the logs of the operator pod:

kubectl logs -f -n toolhive-system <TOOLHIVE_OPERATOR_POD_NAME>

This shows you the logs of the operator pod, which can help you debug any issues.

You can customize the operator installation by providing a values.yaml file with your configuration settings. For example, to change the number of replicas and set a specific ToolHive version, create a values.yaml file:

values.yaml

operator:
  replicaCount: 2
  toolhiveRunnerImage: ghcr.io/stacklok/toolhive:v0.1.8 

Install the operator with your custom values:

helm upgrade -i toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator\
  -n toolhive-system --create-namespace\
  -f values.yaml

To see all available configuration options, run:

helm show values oci://ghcr.io/stacklok/toolhive/toolhive-operator

The ToolHive operator supports two distinct deployment modes to accommodate different security requirements and organizational structures.

Cluster mode provides the operator with cluster-wide access to manage MCPServer resources in any namespace. This is the default mode and is suitable for platform teams managing MCPServers across the entire cluster.

Characteristics:

• Full cluster-wide access to manage MCPServers in any namespace
• Uses ClusterRole and ClusterRoleBinding for broad permissions
• Simplest configuration and management
• Best for single-tenant clusters or trusted environments

To explicitly configure cluster mode, include the following property in your Helm values.yaml file:

values.yaml

operator:
  rbac:
    scope: 'cluster'

Reference the values.yaml file when you install the operator using Helm:

helm upgrade -i toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator \
  -n toolhive-system --create-namespace
  -f values.yaml

This is the default configuration used in the standard installation commands.

Namespace mode restricts the operator's access to only specified namespaces. This mode is perfect for multi-tenant environments and organizations following the principle of least privilege.

Characteristics:

• Restricted access to only specified namespaces
• Uses ClusterRole with namespace-specific RoleBindings for precise access control
• Enhanced security through reduced blast radius
• Ideal for multi-tenant environments and compliance requirements

To configure namespace mode, include the following in your Helm values.yaml:

values.yaml

operator:
  rbac:
    scope: 'namespace'
    allowedNamespaces:
      - 'team-frontend'
      - 'team-backend'
      - 'staging'
      - 'production'

This example lets the operator manage MCPServer resources in the four namespaces listed in the allowedNamespaces property. Adjust the list to match your environment.

Reference the values.yaml file when you install the operator using Helm:

helm upgrade -i toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator \
  -n toolhive-system --create-namespace
  -f values.yaml

Verify the RoleBindings are created:

kubectl get rolebinding --all-namespaces | grep toolhive

You should see RoleBindings in the specified namespaces, granting the operator access to manage MCPServers. Example output:

NAMESPACE        NAME                                           ROLE
team-frontend    toolhive-operator-manager-rolebinding          ClusterRole/toolhive-operator-manager-role
team-backend     toolhive-operator-manager-rolebinding          ClusterRole/toolhive-operator-manager-role
staging          toolhive-operator-manager-rolebinding          ClusterRole/toolhive-operator-manager-role
production       toolhive-operator-manager-rolebinding          ClusterRole/toolhive-operator-manager-role
toolhive-system  toolhive-operator-leader-election-rolebinding  Role/toolhive-operator-leader-election-role

You can switch between cluster mode and namespace mode by updating the values.yaml file and reapplying the Helm chart as shown above. Migration in both directions is supported.

To verify the operator is working correctly:

kubectl get crd | grep toolhive


kubectl get deployment -n toolhive-system toolhive-operator


kubectl get serviceaccount -n toolhive-system
kubectl get clusterrole | grep toolhive
kubectl get clusterrolebinding | grep toolhive


kubectl get pods -n toolhive-system

kubectl logs -n toolhive-system <TOOLHIVE_OPERATOR_POD_NAME>

To upgrade the ToolHive operator to a new version, use the same command you used to install it:

helm upgrade toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator -n toolhive-system --reuse-values

This upgrades the operator to the latest version available in the OCI registry. If you have a custom values.yaml file, include it with the -f flag:

helm upgrade toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator -n toolhive-system --reuse-values -f values.yaml

To uninstall the operator and CRDs, run the following commands:

helm uninstall toolhive-operator -n toolhive-system
helm uninstall toolhive-operator-crds

This removes all the Kubernetes components associated with the chart and deletes the release. You'll need to delete the namespace manually if you used Helm to create it.

See Run MCP servers in Kubernetes to learn how to create and manage MCP servers using the ToolHive operator in your Kubernetes cluster. The operator supports deploying MCPServer resources based on the deployment mode configured during installation.

• Kubernetes introduction - Overview of ToolHive's Kubernetes integration
• ToolHive operator tutorial - Step-by-step tutorial for getting started using a local kind cluster

If you encounter an authentication error when pulling the Helm chart, it might indicate a problem with your access to the GitHub Container Registry (ghcr.io).

ToolHive's charts and images are public, but if you've previously logged into ghcr.io using a personal access token, you might need to re-authenticate if your token has expired or been revoked.

See the GitHub documentation to re-authenticate to the registry.

If the operator pod is not starting or is in a CrashLoopBackOff state, check the pod logs for error messages:

kubectl get pods -n toolhive-system


kubectl describe pod -n toolhive-system <TOOLHIVE_OPERATOR_POD_NAME>
kubectl logs -n toolhive-system <TOOLHIVE_OPERATOR_POD_NAME>

Common causes include:

• Missing CRDs: Ensure the CRDs were installed successfully before installing the operator. The operator requires the CRDs to function properly.
• Configuration errors: Check your values.yaml file for any misconfigurations
• Insufficient permissions: Ensure your cluster has the necessary RBAC permissions for the operator to function
• Resource constraints: Check if the cluster has sufficient CPU and memory resources available
• Image pull issues: Verify that the cluster can pull images from ghcr.io

If the CRDs installation fails, you might see errors about existing resources or permission issues:

kubectl get crd | grep toolhive


kubectl delete crd <CRD_NAME>

To reinstall the CRDs:

helm uninstall toolhive-operator-crds
helm upgrade -i toolhive-operator-crds oci://ghcr.io/stacklok/toolhive/toolhive-operator-crds

If you encounter permission errors when creating the toolhive-system namespace, create it manually first:

kubectl create namespace toolhive-system

Then install the operator without the --create-namespace flag:

helm upgrade -i toolhive-operator oci://ghcr.io/stacklok/toolhive/toolhive-operator -n toolhive-system

If Helm cannot find the chart, ensure you're using the correct OCI registry URL and that your Helm version supports OCI registries (v3.8.0+):

helm version


helm pull oci://ghcr.io/stacklok/toolhive/toolhive-operator

If you're experiencing network timeouts or connection issues:

• Verify your cluster has internet access to reach ghcr.io
• Check if your organization uses a proxy or firewall that might block access
• Consider using a private registry mirror if direct access is restricted

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4