Kubernetes Environments
A Kubernetes environment represents the namespace in your Kubernetes cluster where StreamSets engines are deployed.
Your Kubernetes administrator must create a namespace in the cluster and allow resources that run in that namespace outbound access to Control Hub. You then create a Kubernetes environment in Control Hub that represents the namespace. When you activate the environment, Control Hub generates a StreamSets Kubernetes agent installation script and YAML file. You can use the script or the YAML file to launch an agent in the namespace.
While the environment is in an active state, the StreamSets Kubernetes agent periodically checks with Control Hub to retrieve requests. When you create and start a deployment for the environment, the agent communicates with Control Hub to provision the Kubernetes resources needed to run engines and to deploy engine instances to those resources.
When you deactivate the environment, the IBM StreamSets Kubernetes agent is deleted from the namespace. When you activate the environment again, you must use the agent installation script or YAML file to relaunch the agent.
Before you create a Kubernetes environment, your Kubernetes administrator must complete several prerequisites.
Kubernetes Agent
An IBM StreamSets Kubernetes agent is an application that runs in your Kubernetes cluster. An agent communicates with Control Hub to provision the Kubernetes resources needed to run engines and to deploy engine instances to those resources.
When you activate a Kubernetes environment, Control Hub generates a Kubernetes agent installation script and YAML file. You can use the script or the YAML file to launch the agent in the namespace.
The agent runs as a Kubernetes deployment with a single pod. Each Kubernetes environment that you create in Control Hub corresponds to a single IBM StreamSets Kubernetes agent that runs in the specified Kubernetes namespace. Run only a single agent in each namespace.
The agent uses encrypted REST APIs to communicate with Control Hub, initiating outbound connections to Control Hub over HTTPS. The agent sends requests and information to Control Hub. Control Hub does not directly send requests to the agent. Instead, the agent regularly checks with Control Hub to retrieve requests, such as creating or updating Kubernetes deployments in the namespace.
When you start a Control Hub deployment that belongs to the Kubernetes environment, the agent retrieves that request and creates and monitors a YAML file describing the required resources. The YAML file creates a single Kubernetes deployment and secret in the Kubernetes namespace. The YAML file also creates a horizontal pod autoscaler if the Control Hub deployment is configured to allow legacy autoscaling. The Kubernetes deployment then creates a replica set to ensure that enough pods are created, with each pod running a single engine instance.
When you update a Control Hub deployment that belongs to the Kubernetes environment, the agent retrieves the update request from Control Hub, and then the modified YAML file applies the updates to the engine instances running in the Kubernetes deployment.
Example
The following diagram illustrates how Control Hub objects correspond to resources in your Kubernetes cluster. In this example, Control Hub includes a single Kubernetes environment and two deployments that belong to that environment. One deployment is configured for one engine instance, and the other is configured for two engine instances.
- Deployment 1 corresponds to the Control Hub Kubernetes environment and includes a single pod that runs the IBM StreamSets Kubernetes agent.
- Deployment 2 corresponds to one child Control Hub deployment and includes a single pod that runs one engine instance.
- Deployment 3 corresponds to the other child Control Hub deployment and includes two replicated pods, each of which runs an identical engine instance.

Kubernetes Agent Versions
When you create a Kubernetes environment, you define the IBM StreamSets Kubernetes agent version to use. As a best practice, use the latest released version.
Version 1.4.0
On December 10, 2025, the IBM StreamSets Kubernetes agent version 1.4.0 was released.
Version 1.4.0 includes several critical bug fixes and security patches.
Version 1.3.2
On October 15, 2025, the IBM StreamSets Kubernetes agent version 1.3.2 was released.
Version 1.3.2 includes several critical bug fixes and security patches.
Version 1.3.1
On April 23, 2025, the IBM StreamSets Kubernetes agent version 1.3.1 was released.
Version 1.3.1 includes several critical bug fixes and security patches.
Version 1.3.0
On March 21, 2025, the IBM StreamSets Kubernetes agent version 1.3.0 was released.
With version 1.3.0, you can configure full autoscaling for Control Hub Kubernetes deployments.
Version 1.3.0 also includes several critical bug fixes and security patches.
Version 1.2.1
On November 11, 2024, the IBM StreamSets Kubernetes agent version 1.2.1 was released.
Version 1.2.1 includes several critical bug fixes and security patches.
Version 1.2.0
On September 9, 2024, the IBM StreamSets Kubernetes agent version 1.2.0 was released.
Version 1.2.0 includes several critical bug fixes and security patches.
Version 1.1.2
On April 10, 2024, the IBM StreamSets Kubernetes agent version 1.1.2 was released.
Version 1.1.2 includes several critical bug fixes and security patches.
Version 1.1.1
On October 18, 2023, the IBM StreamSets Kubernetes agent version 1.1.1 was released.
Version 1.1.1 includes several critical bug fixes and security patches.
Version 1.1.0
On June 29, 2023, the IBM StreamSets Kubernetes agent version 1.1.0 was released.
Version 1.1.0 supports configuring engines to use a proxy server by defining the proxy properties in the Control Hub Kubernetes deployment.
Fixed Issue
- When upgrading an existing Kubernetes agent from version 1.0.0, a significant delay of 5-10 minutes occurs before the upgraded agent reconnects with Control Hub. During that time, the Control Hub Kubernetes environment indicates that the agent has been lost and that any functionality relying on the agent will be delayed until it reconnects. However, existing Control Hub Kubernetes deployments and engines continue to function normally.
Version 1.0.0
On February 10, 2023, the IBM StreamSets Kubernetes agent version 1.0.0 was released.
Known Issue
- Version 1.0.0 does not support configuring engines to use a proxy server by
defining the proxy properties in the Control Hub Kubernetes deployment. Workaround: Upgrade to Kubernetes agent version 1.1.0 or later. Or, complete the following steps to configure engines to use a proxy server:
- Create a YAML file that defines a ConfigMap for the engine proxy
properties, where
<namespace-name>is the Kubernetes namespace where the engines are deployed.For example:apiVersion: v1 data: http.nonProxyHosts: <pipe-separated no proxy hosts> no_proxy: <comma-separated no proxy hosts> http.proxyHost: <proxy host> http.proxyPassword: <password> http.proxyPort: "<port>" http.proxyUser: <proxy user> http_proxy: http://<proxy user>:<password>@<proxy host>:<port> https.proxyHost: <proxy host> https.proxyPassword: <password> https.proxyPort: "<port>" https.proxyUser: <proxy user> https_proxy: http://<proxy user>:<password>@<proxy host>:<port> kind: ConfigMap metadata: name: <config-map-name> namespace: <namespace-name> - Run the following command to apply the YAML and create the ConfigMap
in the Kubernetes
cluster:
kubectl -n <namespace-name> apply -f <config-map-name>.yaml - In Control Hub, edit the Kubernetes deployment. Use advanced
mode to edit the YAML file, adding the following
envFromfield to the deployment container, after the existing- envfield:envFrom: - configMapRef: name: <config-map-name>
- Create a YAML file that defines a ConfigMap for the engine proxy
properties, where
Resources Created for the Agent
- Deployment with a single pod that runs the agent
- Secret that contains the authentication token used by the agent to communicate with IBM StreamSets
- Service account
- Role
- Role binding
When you use Control Hub to deactivate the Kubernetes environment, the agent deployment and secret are deleted. The service account, role, and role binding are not deleted.
When you activate the environment again, you must use the agent installation script or YAML file to relaunch the agent. The script or YAML file recreates the deployment and secret for the agent and then reuses the existing service account, role, and role binding. If those resources have been manually deleted, the script or YAML file creates the resources again.
Permissions Granted to the Agent
| Resource | Permissions |
|---|---|
| Deployments | Get, list, create, patch, delete |
| Replica sets | Get, list, create, patch, delete |
| Pods | Get, list, create, patch, delete |
| Secrets | Get, list, create, patch, delete |
| Horizontal pod autoscalers | Get, list, create, patch, delete Note: Horizontal pod autoscalers are used only when a Control Hub deployment is
configured to use legacy autoscaling.
|
Feature Versions
When you create a Kubernetes environment, you select the feature version to use for that environment and for all deployments created for the environment. Later feature versions might require additional Kubernetes permissions or require a restart of engines belonging to the deployments.
When creating a new environment, use the latest feature version. When a new feature version is available, change your existing environments to use the new feature version as soon as possible.
When needed, you can change an existing environment to use a previous feature version. However, changing to a previous feature version disables any newer features not available in the selected feature version.
Kubernetes environments include the following feature versions:
| Feature Version | Description |
|---|---|
| KUBERNETES_2024_06_14 | Includes all features available in the initial feature version, as
well as support for the following enhancements:
|
| KUBERNETES_2023_02_10 | Initial version. |
Changing to a Later Feature Version
To change an existing Kubernetes environment to use a later feature version, you must edit the environment to enable the feature version.
After saving the edited environment, Control Hub restarts all deployments belonging to the environment, causing the StreamSets Kubernetes agent to replace all of the existing pods.
Prerequisites
- Verify that your existing Kubernetes cluster meets the StreamSets requirements.
- Create a namespace for the exclusive use of the Kubernetes environment.
- Allow the required inbound and outbound traffic to the StreamSets resources that run in the namespace.
- Configure the Kubernetes command-line tool so that it can run commands against the Kubernetes cluster.
Verify Cluster Requirements
- The Kubernetes server must be version 1.22 or later.
- The cluster can access the internet.
- Each node in the cluster is set up with the minimum requirements for the
deployed engine type.
The IBM StreamSets Kubernetes agent deploys engine instances as Docker images. As such, the requirements for a Kubernetes deployment are the same as for a self-managed deployment for a Docker image installation. For the list of minimum requirements for each engine type, see the Data Collector documentation or the Transformer documentation.
- Kubernetes secrets are safely secured in the cluster, which might require additional cluster configuration as described in the Kubernetes documentation.
- If you plan to configure a Control Hub Kubernetes deployment to use legacy
autoscaling, the Kubernetes cluster has a running metrics server or
an equivalent server. Important: Ensure that the metrics server is correctly configured to report accurate and timely metrics. If the server is slow to report metrics, the horizontal pod autoscaler is also slow to adjust to changes in CPU usage.
For more information about metrics servers, see the Kubernetes documentation.
Create a Namespace
Create a namespace in your Kubernetes cluster.
You can use an existing namespace. However, as a best practice, create a new namespace for the exclusive use of each Control Hub Kubernetes environment.
Do not create deployments or pods within the namespace. After you create and activate the Kubernetes environment and then launch the IBM StreamSets Kubernetes agent in the namespace, the agent communicates with Control Hub to provision the required Kubernetes resources in the namespace.
For instructions on creating a namespace in Kubernetes, see the Kubernetes documentation.
Allow Inbound and Outbound Traffic
If the Kubernetes cluster resides behind a firewall, allow the required inbound and outbound traffic to the Kubernetes resources provisioned for the environment. Or if you use Kubernetes network policies, create a network policy that defines the required ingress and egress rules to the resources.
- The IBM StreamSets Kubernetes agent requires outbound connections to StreamSets Control Hub. For the complete list of Control Hub DNS names to allow, see Firewall Configuration.
- The IBM StreamSets engines require all inbound and outbound connections as listed in Firewall Configuration.
Configure kubectl
Configure the Kubernetes command-line tool, kubectl, so that it can
communicate with your Kubernetes cluster.
For details about accessing Kubernetes clusters, see the Kubernetes documentation.
The user who runs the command that launches the IBM StreamSets Kubernetes agent in the cluster must have the following minimum permissions within the namespace that the agent runs in:
| Resource | Permissions |
|---|---|
| Deployments | Get, list, create, patch, delete |
| Pods | Get, list, create, patch, delete |
| Replica sets | Get, list, create, patch, delete |
| Roles | Get, list, create, patch, delete |
| Role bindings | Get, list, create, patch, delete |
| Secrets | Get, list, create, patch, delete |
| Service accounts | Get, list, create, patch, delete |
| Horizontal pod autoscalers | Get, list, create, patch, delete Note: Horizontal pod autoscalers are used only when a Control Hub deployment is
configured to use legacy autoscaling.
|
Configuring a Kubernetes Environment
Configure a Kubernetes environment to define where to deploy IBM StreamSets engines in your Kubernetes cluster.
To create a new environment, click in the Navigation panel, and then click the Create
Environment icon:
.
To edit an existing environment, click in the Navigation panel, click the environment name, and then click Edit.
Define the Environment
Define the environment essentials, including the environment name and type, and optional tags to identify similar environments.
Configure the Environment
Specify the version of the IBM StreamSets Kubernetes agent to deploy, enter the name of the Kubernetes namespace created as a prerequisite by your Kubernetes administrator, and optionally define Kubernetes labels to apply to provisioned Kubernetes resources.
Share the Environment
By default, the environment can only be seen by you. Share the environment with other users and groups to grant them access to it.
Review and Activate the Environment
You've successfully finished creating the environment.
Launching the Agent
After activating a Kubernetes environment, you launch the IBM StreamSets Kubernetes agent so that it runs in the Kubernetes namespace specified in the environment.
- From the installation script.
- From the YAML file.
Launching the Agent from the Installation Script
You can launch the IBM StreamSets
Kubernetes agent using the installation script that Control Hub
generates. The installation script automatically retrieves the agent YAML file from Control Hub, and
then uses the Kubernetes command-line tool, kubectl, to create a deployment
for the agent based on the YAML file.
Launching the Agent from the YAML File
You can launch the IBM StreamSets
Kubernetes agent using the YAML file that Control Hub
generates. Use the Kubernetes command-line tool, kubectl, to create a
deployment for the agent based on the YAML file, as you do with other Kubernetes
applications.
Retrieving the Installation Script
You can retrieve the installation script generated for a Kubernetes environment.
- In the Control Hub Navigation panel, click .
- Locate the Kubernetes environment that you want to launch an agent for.
-
In the Actions column, click the
More icon (
) and then click Get Install
Script.
-
Click the Copy to Clipboard icon (
),
and then click Close.
Retrieving the YAML File
You can retrieve the YAML file generated for a Kubernetes environment.
- In the Control Hub Navigation panel, click .
- Locate the Kubernetes environment that you want to launch an agent for.
-
In the Actions column, click the
More icon (
) and then click View
Generated YAML.
-
Click the Copy to Clipboard icon (
),
and then click Close.
Using a Proxy Server for Kubernetes
- IBM StreamSets Kubernetes agent - Configure the Kubernetes agent to use a proxy server when you configure the Kubernetes environment.
- IBM StreamSets engines - Configure the engines to use a proxy server when you configure the Control Hub Kubernetes deployments that belong to the Kubernetes environment.
Configure the Agent to Use a Proxy Server
To configure a Kubernetes agent to use a proxy server for an existing Kubernetes
environment, retrieve the YAML file generated for a Kubernetes environment and edit
the YAML file to define the proxy properties. Then use the Kubernetes command-line
tool, kubectl, to apply the changes to the running IBM StreamSets Kubernetes agent.
Configure Engines to Use a Proxy Server
To configure IBM StreamSets engines to use a proxy server for an existing Control Hub Kubernetes deployment, you must stop the deployment.
After editing the deactivated deployment to modify the proxy properties, you start the deployment. The IBM StreamSets Kubernetes agent communicates with Control Hub to provision the Kubernetes resources again, deploying and launching new engine instances that use the updated proxy properties.
Monitoring the Agent
To view environment details, click an environment name in the Environments view.
When you need additional monitoring information about the agent, use the Kubernetes
command-line tool, kubectl, to access Kubernetes log
files for the pod where the Kubernetes agent runs.
Agent Status
You can view the status of an IBM StreamSets Kubernetes agent from the list of environments in the Environments view or from the environment details.
The following table describes each agent status:
| Agent Status | Description |
|---|---|
| Agent-Online | Agent is running in the Kubernetes cluster and is communicating regularly with Control Hub. |
| Agent-Error | Agent is running in the Kubernetes cluster, but has encountered an error. View the agent event logs for additional information. |
| Agent-Offline | Agent has been gracefully shut down or has not yet been launched. |
| Agent-Lost | Agent has not communicated with Control Hub for some time. The agent has either lost its connection with Control Hub or has unexpectedly shut down. If the agent reports an Agent-Lost status after you have deactivated the environment, you might need to delete the unresponsive agent. |
Event Logs
When you view the details of a Kubernetes environment, you can view event logs for the IBM StreamSets Kubernetes agent. The event logs list all events related to the agent launched for the environment, including errors that might occur when launching the agent.
Event logs display messages only about the current activation of the environment. Each time you deactivate and then activate the environment, the previous event logs are removed.
To view agent event logs, click a Kubernetes environment name in the Environments view and then locate the Agent Event Logs section in the environment details.
The following image shows sample event logs for a Kubernetes agent:

Accessing Kubernetes Log Files
You can use the Kubernetes command-line tool, kubectl, to access
Kubernetes log files for the pod where the IBM StreamSets
Kubernetes agent runs.
First, run the following kubectl command to retrieve the name of the
pod, where <namespace_name> is the name of the Kubernetes namespace
created for the environment:
kubectl [-n <namespace_name>] get pods
Control Hub uses the following format to name the pod for the agent:
streamsets-agent-dep-<Control_Hub_deployment_ID><pod_UID>
kubectl [-n <namespace_name>] logs pod/<pod_name>Modifying the Agent Log Level
If the agent log file does not provide enough troubleshooting information, you can modify the log level to display messages at another severity level.
- TRACE
- DEBUG
- INFO
- WARN
- ERROR
- FATAL
To modify the log level, retrieve the YAML file generated for a Kubernetes environment and edit
the YAML file to customize the log format. Then use the Kubernetes command-line tool,
kubectl, to apply the changes to the running IBM StreamSets Kubernetes agent.
Deleting an Unresponsive Agent
When you deactivate a Kubernetes environment, the IBM StreamSets Kubernetes agent is automatically deleted from the namespace for you. However, in rare situations, the agent can become unresponsive and you must retrieve and run an uninstallation script to shut down and delete the agent from the Kubernetes namespace.
For example, if the agent has lost the connection with Control Hub or has unexpectedly shut down, IBM StreamSets cannot gracefully shut down and delete the agent when you deactivate the environment.
Upgrading the Agent
You can upgrade an existing Kubernetes environment to use a later IBM StreamSets Kubernetes agent version. As a best practice, use the latest released version.
- In the Control Hub Navigation panel, click .
-
In the Actions column of the Kubernetes environment,
click the More icon (
) and
then click Edit.
- In the Edit Environment dialog box, expand the Configure Environment section.
- Select a later Kubernetes agent version.
- Click Save.
- To apply the changes to your Kubernetes cluster, use the agent installation script or YAML file to launch the Kubernetes agent again.