Add support for including sidecar containers with Kafka and zookeeper pods

[dinesh-murugiah]

Type of change
Enhancement / new feature

Description
Proposal: Sidecar Container Support for Strimzi Kafka Operator
Overview
This proposal introduces native support for sidecar containers in Strimzi Kafka clusters, allowing users to deploy additional containers alongside Kafka, for monitoring, logging, security, and other operational purposes. This can also be extended to support sidecar addition for Zookeeper, and other Strimzi-managed components

1. Purpose of the Change
   Problem Statement
   Currently, users who need to run sidecar containers (monitoring agents, log forwarders, security scanners, etc.) alongside Kafka components must:

Manually modify generated Pod specifications after deployment
Use external tools like admission controllers or mutating webhooks
Create custom operators or controllers
Fork and modify Strimzi code
These approaches are fragile, complex, and break the declarative nature of Kubernetes resource management.

Solution
Introduce first-class sidecar container support through the Strimzi CRD API, enabling users to:

Declaratively define sidecar containers in their Kafka/KafkaConnect/etc. specifications
Leverage Strimzi's existing container management, security, and lifecycle features
Maintain compatibility with GitOps workflows and Kubernetes-native tooling
Use Cases
Monitoring: Prometheus exporters, APM agents, custom metrics collectors
Logging: Log forwarding agents (Fluent Bit, Filebeat), log processors
Security: Vulnerability scanners, compliance agents, secret managers
Networking: Service mesh sidecars, network policy agents, traffic analyzers
Data Processing: Stream processors, data transformation agents
2. Thought Process and Justification for Model Classes
Design Philosophy
We follow Strimzi's established pattern of providing user-friendly APIs that get converted to Kubernetes-native resources. This requires two distinct model layers:

2.1 Strimzi API Models (SidecarContainer, SidecarProbe)
Purpose: User-facing API optimized for declarative configuration

Key Design Decisions:

public class SidecarContainer {
// User-friendly string-based image pull policy
private String imagePullPolicy; // "Always", "IfNotPresent", "Never"

// Simplified probe configuration
private SidecarProbe livenessProbe;
private SidecarProbe readinessProbe;

// Direct field access - no nested complexity
private List<ContainerEnvVar> env;
private List<ContainerPort> ports;

}

public class SidecarProbe {
// String ports for user simplicity
private String httpGetPort; // "8080" or "http-port"
private String tcpSocketPort; // "9090" or "metrics"

// Flattened fields - no nested action objects
private List<String> execCommand;
private String httpGetPath;

}

This proposal provides a comprehensive, production-ready sidecar container solution that maintains Strimzi's high standards for usability, reliability, and Kubernetes integration.

Checklist

Please go through this checklist and make sure all applicable tasks have been done

• Write tests
• Make sure all tests pass
• Update documentation
• Check RBAC rights for Kubernetes / OpenShift roles
• Try your changes from Pod inside your Kubernetes and OpenShift cluster, not just locally
• Reference relevant issue(s) and close them after merging
• Update CHANGELOG.md
• Supply screenshots for visual changes, such as Grafana dashboards

[scholzj]

Thanks for the PR. However, as I explained in the duplicate issue you opened, this requires a proper proposal to be opened, discussed, and approved: https://github.com/strimzi/proposals. This PR also seems ot be pretty limited in terms of what is needed for a fully functional sidecars as you would likely need to be able to modify port exposured, share volumes, etc.

[dinesh-murugiah]

@scholzj thanks for the suggestion and feedback i have sent a proposal for review

regarding:

This PR also seems ot be pretty limited in terms of what is needed for a fully functional sidecars as you would likely need to be able to modify port exposured, share volumes, etc.

this PR does allow exposing network ports , and there is no limitation in sharing volumes between containers of the pod

[scholzj]

@scholzj thanks for the suggestion and feedback i have sent a proposal for review

regarding:

This PR also seems ot be pretty limited in terms of what is needed for a fully functional sidecars as you would likely need to be able to modify port exposured, share volumes, etc.

this PR does allow exposing network ports , and there is no limitation in sharing volumes between containers of the pod

I do not think it allows the remapping of the ports to allow integration of things such as proxies etc. In any case, if it does, please describe it in the proposal.

[ppatierno]

Triaged on 27.11.2025: we should discuss the proposal first and if it makes sense to have this addition within Strimzi operator and how. So @dinesh-murugiah we'll close this PR for now, so that based on the outcome from the proposal a new one maybe will be opened.