> For the complete documentation index, see [llms.txt](https://cortex-docs.paloaltonetworks.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://cortex-docs.paloaltonetworks.com/kubernetes-security/kspm-limitations-and-system-components.md).
# KSPM limitations and system components
Refer to KSPM components and limitations for essential details on system architecture, resource requirements, and operational constraints when setting up your environment.
{% hint style="info" %}
**Note**
The CPU and memory limits can be adjusted to align with your resource needs. For configuration steps, refer to [Configure Kubernetes Connector resource limits](https://app.gitbook.com/s/SqNMu2K0VWh4WXps5pCW/configure-kubernetes-connector-resource-limits).
{% endhint %}
### KSPM system components
**Core components (continuously running)**:
| Component name | Description | Type | Priority Class\*\* | Replicas | CPU (Req/Limit) | Memory (Req/Limit) |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ------------------ | -------- | --------------- | ------------------ |
| cortex-manager | This is the system's central engine that continuously monitors and aligns the cluster. It ensures the actual state of your deployment always matches your requested settings by automatically correcting any discrepancies. | Deployment | cortex-critical | 1 | 50m / 100m | 100Mi / 200Mi |
| cortex-admission | The cortex-admission acts as the system validator. It reviews every request to ensure it meets safety and configuration standards before allowing it to proceed. | Deployment | cortex-critical | 3 | 50m / 100m | 150Mi / 200Mi |
| cortex-monitoring | The cortex-monitoring component provides visibility into the health and performance of the system. It tracks metrics, logs, and health checks, acting as an early warning system that alerts operators of bottlenecks or failures. | Deployment | cortex-high | 1 | 30m / 100m | 100Mi / 200Mi |
**Scheduled components**:
| Component name | Description | Type | Priority Class | Schedule/Trigger | CPU (Req/Limit) | Memory (Req/Limit) |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- | -------------- | -------------------- | --------------- | ------------------ |
| cortex-syncer | The cortex-syncer ensures that information stays consistent across different environments (like the cloud and your local cluster) by constantly updating and matching records. | CronJob | cortex-high | Every hour | 50m / 150m | 50Mi / 200 Mi |
| cortex-job-orchestrator | It handles the scheduling and sequencing of background jobs, ensuring they run in the right order and at the right time without overlapping. | CronJob | cortex-high | Daily (configurable) | 25m / 50m | 75Mi / 100Mi |
| cortex-node-vm-discovery | It automatically scans the environment to identify and catalog all Virtual Machines (VMs) and nodes that need to be managed or protected. | Job\* | cortex-high | Ephemeral | 15m / 50m | 50Mi / 100Mi |
| cortex-inventory-collector | It gathers a detailed inventory or list of all hardware and software components currently running in the cluster so you always know what you have. | Job\* | cortex-high | Ephemeral | 25m / 50m | 50Mi / 100Mi |
| cortex-compliance-node-scanner | It checks individual nodes against industry security standards to ensure the underlying servers are configured safely and legally.
Note: The scanner is integrated into the host-scanner pod from connector version 2.0.x
| Job\* | cortex-high | Ephemeral | 25m / 100m | 50Mi / 100Mi |
| cortex-host-scanner | It performs deep scans of the host operating system to find vulnerabilities, misconfigurations, or hidden security threats. | Job\* | cortex-high | Ephemeral | 300m / 1000m | 50Mi / 13Gi |
| cortex-scan-result-publisher | It processes the raw scan results, normalizes them, and publishes them to the Cortex Cloud console so findings are ready to view. This component runs as part of the host-scanner pod. | Job\* | cortex-high | Ephemeral | 30m / 50m | 50Mi / 500Mi |
\*Spawned as ephemeral processes by the job-orchestrator.
**Optional components**:
| Component name | Description | Type | Priority Class | Scaling behavior | CPU (Req/Limit) | Memory (Req/Limit) |
| --------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | --------------- | ---------------- | --------------- | ------------------ |
| cortex-realtime | The cortex-realtime is the system's high-speed streaming engine. It provides instantaneous data processing and analysis, allowing the cluster to react to security events or configuration changes the moment they occur.
Refer to the Realtime Protection section in Onboard the Kubernetes Connector
| DaemonSet | cortex-critical | 1 pod per node | 200m / 1500m | 600Mi / 2Gi |
\*\* A **PriorityClass** is a non-namespaced Kubernetes resource that defines an importance level for pods. This influences their scheduling order and determines if they can evict (preempt) lower-priority pods during resource scarcity to ensure security continuity.
The following PriorityClasses are defined for the Kubernetes Connector:
* cortex-critical (Value: 1,000,010,000): Highest priority for mission-critical security components, including cortex-manager, cortex-admission-controller, and cortex-realtime.
* cortex-high (Value: 100,000,000): High priority for all other KSPM workloads, ensuring they are prioritized over standard, non-essential application traffic.
### KSPM limitations
**Supported operating systems**: Linux
{% hint style="info" %}
**Note**
Windows and Unix are not supported.
{% endhint %}
**Supported CPU architecture**:
* AMD64 (x86\_64)
* ARM64 (aarch64)
**Technical specifications**
* CPU units: 1000m = 1 CPU core
* Memory units: Mi = Mebibytes, Gi = Gibibytes
---
# 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 dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://cortex-docs.paloaltonetworks.com/kubernetes-security/kspm-limitations-and-system-components.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
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.