> For the complete documentation index, see [llms.txt](https://docs.ilert.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ilert.com/ai-and-agents/mcp/hosted/kubernetes.md).

# Kubernetes

Give an agent access to a Kubernetes cluster by deploying ilert-kube-agent with Helm or Terraform.

#### Required permissions

<table><thead><tr><th width="177.515625">Tool</th><th width="178.515625">Required Permission</th><th>Description</th></tr></thead><tbody><tr><td><code>list_pods</code></td><td><code>get</code>, <code>list</code></td><td>Gets name, status and namespace of pods (containers) in the Kubernetes cluster. Useful for finding pods that are not running or terminated/crashing containers.</td></tr><tr><td><code>describe_pod</code></td><td><code>get</code></td><td>Describe the configuration and status as well as other insightful information about a pod (container) in a Kubernetes cluster. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>fetch_pod_logs</code></td><td><code>get</code></td><td>Fetch tailing logs of a pod (container) in a Kubernetes cluster. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>fetch_previous_pod_logs</code></td><td><code>get</code></td><td>Fetch the previous tailing logs of a pod (container) in a Kubernetes cluster. This method is useful to investigate why a given pod crashed or has restarted. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>patch_cpu_workload_by_pod</code></td><td><code>patch</code></td><td>Update CPU request and limit of a workload related to a pod (container) in a Kubernetes cluster. Useful for fixing errors caused by low compute limits usually resulting in bad service performance or slow responses. Returns the name of a pod of the new rollout or null if a timeout occurs or no patch is applied. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>patch_memory_workload_by_pod</code></td><td><code>patch</code></td><td>Update the memory (ram) request and limit of a workload related to a pod (container) in a Kubernetes cluster. Useful for fixing errors caused by low memory limits usually resulting in bad service performance or OOM killed or crashes/unresponsiveness. Returns the name of a pod of the new rollout or null if a timeout occurs or no patch is applied. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>scale_workload_by_pod</code></td><td><code>patch</code></td><td>Set a new replica size for a workload related to a pod. Returns the name of a pod belonging to the workload or null if no pod was found after timeout. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>delete_pod</code></td><td><code>delete</code></td><td>Delete a pod. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr><tr><td><code>rollback_workload_by_pod</code></td><td><code>patch</code></td><td>Rollback a workload related to a pod (container) in a Kubernetes cluster. Useful for rolling back to a previous version of a workload. Returns the name of a pod of the new rollout or null if a timeout occurs or no rollback is applied. Only use this tool when you have a valid, existing pod name. If the pod name is unknown, use <code>list_pods</code> first to find available pods.</td></tr></tbody></table>

#### Deploy ilert-kube-agent

The Kubernetes MCP server requires deploying the ilert-kube-agent in your Kubernetes cluster. The ilert-kube-agent can be deployed using Helm or Terraform.

**Option 1: Deploy using Helm**

{% stepper %}
{% step %}
Add the ilert Helm repository:

```bash
helm repo add ilert https://ilert.github.io/charts/
helm repo update
```

{% endstep %}

{% step %}
Deploy ilert-kube-agent:

```bash
helm upgrade --install --namespace kube-system \
    ilert-kube-agent ilert/ilert-kube-agent \
    --set config.settings.apiKey="<YOUR ILERT API KEY>"
```

{% endstep %}

{% step %}
Generate an HTTP API secret (httpAuthorizationKey) to activate API mode:

```bash

# Generate a random secret
openssl rand -hex 32
```

{% endstep %}

{% step %}
Set the HTTP API secret in the Helm values or update the deployment:

```bash
helm upgrade --install --namespace kube-system \
    ilert-kube-agent ilert/ilert-kube-agent \
    --set config.settings.apiKey="<YOUR ILERT API KEY>" \
    --set config.settings.httpAuthorizationKey="<YOUR GENERATED SECRET>"
```

{% endstep %}
{% endstepper %}

**Option 2: Deploy using Terraform**

{% stepper %}
{% step %}
Use the ilert-kube-agent Terraform module:

```hcl
module "ilert_kube_agent" {
  source = "ilert/ilert-kube-agent/kubernetes"
  
  api_key = "<YOUR ILERT API KEY>"
  http_authorization_key = "<YOUR GENERATED SECRET>"
}
```

{% endstep %}

{% step %}
Generate an HTTP API secret (httpAuthorizationKey) to activate API mode:

```bash

# Generate a random secret
openssl rand -hex 32
```

{% endstep %}

{% step %}
Apply the Terraform configuration:

```bash
terraform init
terraform apply
```

{% endstep %}
{% endstepper %}

For more details, see the [ilert-kube-agent documentation](https://github.com/iLert/ilert-kube-agent).

{% hint style="info" %}
**Note:** The HTTP API secret (httpAuthorizationKey) is required to activate API mode, which enables the MCP server to communicate with the ilert-kube-agent. Make sure to securely store this secret as it will be needed when connecting the Kubernetes integration in ilert.
{% endhint %}

#### Connect Kubernetes with agent

To connect Kubernetes with your AI SRE agent:

{% stepper %}
{% step %}
Navigate to **Agents** in the ilert navigation menu
{% endstep %}

{% step %}
Open the agent detail view for the agent you want to configure
{% endstep %}

{% step %}
Go to the **Tools** tab
{% endstep %}

{% step %}
Under the **ilert hosted MCP servers** section, locate the **Kubernetes** card
{% endstep %}

{% step %}
Click **Connect** on the Kubernetes card
{% endstep %}

{% step %}
In the connection dialog that appears:

* **Select connector:** Choose "Create new connector" (or select an existing connector if you have one)
* **Type:** Select **Bearer Token** from the dropdown
* **Secret name:** Enter a name for your connector (e.g., "Kubernetes Production" or "Kubernetes Main")
* **Secret value:** Enter the HTTP API secret (httpAuthorizationKey) you generated when deploying ilert-kube-agent
* **Host URL:** Enter the URL where your ilert-kube-agent is accessible (e.g., `https://ilert-kube-agent.kube-system.svc.cluster.local:8080` or your external URL)
  {% endstep %}

{% step %}
Click **Connect** to complete the connection
{% endstep %}

{% step %}
After connecting, you can enable or disable specific tools needed for alert investigation, such as:

* `list_pods` - Get name, status and namespace of pods in the Kubernetes cluster
* `describe_pod` - Describe configuration and status of a pod
* `fetch_pod_logs` - Fetch tailing logs of a pod
* `fetch_previous_pod_logs` - Fetch previous logs of a pod (useful for investigating crashes)
* `patch_cpu_workload_by_pod` - Update CPU request and limit of a workload
* `patch_memory_workload_by_pod` - Update memory request and limit of a workload
* `scale_workload_by_pod` - Set a new replica size for a workload
* `delete_pod` - Delete a pod
* `rollback_workload_by_pod` - Rollback a workload to a previous version
  {% endstep %}
  {% endstepper %}

The Kubernetes integration is now connected and ready to use for root cause analysis.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ilert.com/ai-and-agents/mcp/hosted/kubernetes.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.