# Connect to Redpanda in Kubernetes > For the complete documentation index, see [llms.txt](https://docs.redpanda.com/llms.txt). Component-specific: [streaming-full.txt](https://docs.redpanda.com/streaming-full.txt) --- title: Connect to Redpanda in Kubernetes latest-operator-version: v26.1.4 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "true" page-eol-date: December 22, 2024 latest-console-tag: v3.7.3 latest-connect-version: 4.93.0 docname: kubernetes/networking/k-connect-to-redpanda page-component-name: streaming page-version: "23.3" page-component-version: "23.3" page-component-title: Streaming page-relative-src-path: kubernetes/networking/k-connect-to-redpanda.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/v/23.3/modules/manage/pages/kubernetes/networking/k-connect-to-redpanda.adoc description: Learn how to connect to a Redpanda cluster running in Kubernetes. page-git-created-date: "2024-01-04" page-git-modified-date: "2025-08-20" support-status: past end-of-life --- To work with a Redpanda cluster running in Kubernetes, you can connect clients to the listeners that are exposed by Redpanda brokers. Depending on how the listeners are configured, you can access them from within the Kubernetes cluster and/or from outside the Kubernetes cluster. | API | Purpose | | --- | --- | | Admin API | Operate Redpanda clusters. For example, you can modify the cluster’s configuration, decommission brokers, and place brokers in maintenance mode. | | Kafka API | Interact with the Kafka protocol in Redpanda. | | HTTP Proxy (PandaProxy) | Access your data through a REST API. For example, you can list topics or brokers, get events, and produce events. | | Schema Registry | Store and manage event schemas. For example, you can query supported serialization formats, register schemas for a subject, and retrieve schemas of specific versions. | ## [](#prerequisites)Prerequisites You must have the following: - Kubernetes cluster: Ensure you have a running Kubernetes cluster, either locally, such as with minikube or kind, or remotely. - [Kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl): Ensure you have the `kubectl` command-line tool installed and configured to communicate with your cluster. - Redpanda cluster: [Deploy a Redpanda cluster](https://docs.redpanda.com/streaming/23.3/deploy/deployment-option/self-hosted/kubernetes/). ## [](#connect-to-an-internal-cluster)Connect to an internal cluster To connect a client to Redpanda brokers running in the same Kubernetes cluster, use their [fully qualified domain names](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/networking/k-networking-and-connectivity/#internal-networking) (FQDNs) and the internal port of a listener. Together, the FQDN and internal port are called an endpoint. These endpoints may be secured using TLS and/or authentication. The `rpk` client on each Redpanda broker is pre-configured to connect to the internal Admin API and internal Kafka API of the local Redpanda cluster. To use other clients, such as a Kafka client, you must configure them. ### [](#connect-internally-with-a-local-rpk-client)Connect internally with a local rpk client The `rpk` command-line client, available on each Redpanda broker, allows you to communicate with the internal listeners of both the Admin API endpoint and the Kafka API endpoint. By default, the Redpanda Helm chart configures `rpk` with a local `redpanda.yaml` configuration file located in the `/etc/redpanda/` directory. As a result, you can use `rpk` from inside the container. For example, this command executes the `rpk cluster info` command: ```bash kubectl exec --namespace -- rpk cluster info ``` If you have SASL authentication enabled for the internal Kafka API listeners, you must specify the username, password, and SASL mechanism. ```bash kubectl exec --namespace -- rpk cluster info \ -X user= -X pass= -X sasl.mechanism= ``` You can also use environment variables instead of flags to specify the username, password, and SASL mechanism: ```bash export RPK_USER= export RPK_PASS= export RPK_SASL_MECHANISM= ``` For details about SASL authentication, see [Configure Authentication for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/authentication/k-authentication/). ### [](#connect-to-the-internal-kafka-api)Connect to the internal Kafka API To connect to the internal Kafka API using a client other than `rpk`, you must configure the client with the correct endpoints, authentication credentials, and TLS certificates. You can find the connection details in the `/etc/redpanda/redpanda.yaml` file of any Pod that’s running a Redpanda broker: ```bash kubectl exec --namespace -- cat /etc/redpanda/redpanda.yaml ``` The `rpk.kafka_api.brokers` list contains the internal Kafka API endpoints of the Redpanda brokers: `redpanda.yaml` ```yaml rpk: kafka_api: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local.:9093 - redpanda-1.redpanda.redpanda.svc.cluster.local.:9093 - redpanda-2.redpanda.redpanda.svc.cluster.local.:9093 ``` If the internal listeners have SASL authentication enabled, you must also configure your clients with valid credentials. To find out if a listener has authentication enabled, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the Kafka API has SASL authentication enabled: ```yaml auth: sasl: enabled: true listeners: kafka: port: 9093 # default is "sasl" when empty or "null" authenticationMethod: null ``` For details about SASL authentication, see [Configure Authentication for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/authentication/k-authentication/). TLS files are stored in Secret resources that you can mount onto any Pods that run clients. TLS files may include: - Certificate files (`*.crt`): These files contain the public key and the identity (domain name) and are used for encryption. They can be self-signed or signed by a certificate authority (CA). - Key files (`*.key`): These contain the private key associated with the certificate. The private key should be kept secure and confidential. - CA files: These are certificates of the certificate authorities. They are used to verify if a given certificate is trusted. You can find the names of all TLS Secrets using this command: ```bash join -t $'\t' \ <(kubectl get pod --namespace -o jsonpath="{range .spec.containers[0].volumeMounts[*]}{.name}{'\t'}{.mountPath}{'\n'}{end}" | awk '$2 ~ /^\/etc\/tls\/certs\// {print $1"\t"$2}' | sort) \ <(kubectl get pod --namespace -o jsonpath="{range .spec.volumes[?(@.secret)]}{.name}{'\t'}{.secret.secretName}{'\n'}{end}" | sort) \ | awk 'BEGIN{printf "%-25s\t%-40s\n", "SECRET", "MOUNT PATH"} {printf "%-25s\t%-40s\n", $3, $2}' ``` For example: SECRET MOUNT PATH redpanda-default-cert /etc/tls/certs/default redpanda-external-cert /etc/tls/certs/external Then, you can mount the required Secrets into the Pods that run the clients: ```yaml apiVersion: v1 kind: Pod metadata: name: redpanda-client-pod labels: app: redpanda-client spec: volumes: - name: tls-certs secret: secretName: redpanda-default-client containers: - name: client-container image: example/client-image volumeMounts: - name: tls-certs mountPath: /etc/tls/certs readOnly: true ``` Now, you can configure clients with the mount path to the TLS files in your Secrets. For details about TLS, see [TLS for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/tls/). ### [](#connect-to-the-internal-http-proxy)Connect to the internal HTTP Proxy To connect to the HTTP Proxy, use its configured internal port. To find the port, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the internal port is 8082. ```yaml listeners: http: port: 8082 ``` To test an internal connection, you can use the cURL command-line client inside the container running a Redpanda broker: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics -sS ``` If SASL authentication is enabled, provide a valid username and password using basic authentication: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics -u : -sS ``` If TLS is enabled, specify the HTTPS protocol and pass the path to the `ca.crt` file: ```bash kubectl exec --namespace -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8082/topics --cacert /etc/tls/certs/default/ca.crt -sS ``` > 📝 **NOTE** > > If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the `--cacert` flag. For all available endpoints, see the [HTTP Proxy API](https://docs.redpanda.com/api/doc/http-proxy/). ### [](#connect-to-internal-schema-registry)Connect to internal Schema Registry To connect to the Schema Registry, use its configured internal port. To find the port, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the internal port is 8081. ```yaml listeners: schemaRegistry: port: 8081 ``` To test an internal connection, you can use the cURL command-line client inside the container running a Redpanda broker: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects -sS ``` If SASL authentication is enabled, provide a username and password using basic authentication: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects -u : -sS ``` If TLS is enabled, specify the HTTPS protocol and pass the path to the `ca.crt` file: ```bash kubectl exec --namespace -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8081/subjects --cacert /etc/tls/certs/default/ca.crt -sS ``` > 📝 **NOTE** > > If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the `--cacert` flag. For all available endpoints, see the [Schema Registry API](https://docs.redpanda.com/api/doc/schema-registry). ### [](#connect-to-the-internal-admin-api)Connect to the internal Admin API To connect to the Admin API, use its configured internal port. To find the port, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the internal port is 8081. ```yaml listeners: admin: port: 9644 ``` To test an internal connection, you can use the cURL command-line client inside the container running a Redpanda broker: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:9644/v1/node_config -sS ``` If TLS is enabled, specify the HTTPS protocol and pass the path to the `ca.crt` file: ```bash kubectl exec --namespace -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:9644/v1/node_config --cacert /etc/tls/certs/default/ca.crt -sS ``` > 📝 **NOTE** > > If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the `--cacert` flag. For all available endpoints, see the [Admin API](https://docs.redpanda.com/api/doc/admin). ## [](#connect-to-an-external-cluster)Connect to an external cluster To connect to your Redpanda cluster from outside Kubernetes, the Redpanda cluster must be configured with external access. See [Configure External Access](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/networking/external/). ### [](#rpk-profile)Create an rpk profile An rpk profile contains a reusable configuration for a Redpanda cluster. When running `rpk`, you can create a profile, configure it for a cluster you’re working with, and use it repeatedly when running an `rpk` command for the cluster. When `external.enabled` is set to `true` (default), the Helm chart generates a ConfigMap that contains settings for an `rpk` profile. You can use these settings to connect to the cluster externally. The ConfigMap configures an `rpk` profile using the `listeners.admin.external.default` and `listeners.kafka.external.default` objects in Helm values. 1. [Install `rpk`](https://docs.redpanda.com/streaming/23.3/get-started/rpk-install/). 2. Configure `rpk` to use the profile in the ConfigMap: ```bash rpk profile create --from-profile <(kubectl get configmap --namespace redpanda-rpk -o go-template='{{ .data.profile }}') ``` 3. If you have SASL authentication enabled, you must configure `rpk` with a valid username and password. When you first deploy Redpanda, the Helm chart prints some notes with the commands necessary to configure a username and password locally. For example: ```bash kubectl --namespace get secret -o go-template="{{ range .data }}{{ . | base64decode }}{{ end }}" | IFS=: read -r RPK_USER RPK_PASS RPK_SASL_MECHANISM export RPK_USER RPK_PASS RPK_SASL_MECHANISM ``` 4. If you have TLS enabled, you must save the TLS files to your local filesystem external to the Kubernetes cluster. When you first deploy Redpanda, the Helm chart prints some notes with the commands necessary to save the TLS files locally. For example: ```bash kubectl get secret --namespace -o go-template='{{ index .data "ca.crt" | base64decode }}' > ca.crt ``` For more details about `rpk` profiles, see [rpk Profiles](https://docs.redpanda.com/streaming/23.3/get-started/config-rpk-profile/). ### [](#connect-to-the-external-kafka-api)Connect to the external Kafka API To connect to the external Kafka API using a client other than `rpk`, you must configure the client with the correct broker endpoints, authentication credentials, and TLS certificates. You can find the connection details in the `/etc/redpanda/redpanda.yaml` file of any Pod that’s running a Redpanda broker: ```bash kubectl exec --namespace -- cat /etc/redpanda/redpanda.yaml ``` The `redpanda.advertised_kafka_api` list item called `default` contains the external Kafka API endpoints for the Redpanda brokers: `redpanda.yaml` ```yaml redpanda: advertised_kafka_api: - address: redpanda-0.redpanda.redpanda.svc.cluster.local. port: 9093 name: internal - address: redpanda-0.customredpandadomain.local port: 31092 name: default ``` If the external listeners have SASL authentication enabled, you must also configure your clients with valid credentials. To find out if the Redpanda cluster has authentication enabled, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the Kafka API has SASL authentication enabled: ```yaml auth: sasl: enabled: true listeners: kafka: external: default: # default is "sasl" when empty or "null" authenticationMethod: null ``` For details about SASL authentication, see [Configure Authentication for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/authentication/k-authentication/). TLS files are stored in Secrets that you can mount onto the Pods that are running the clients. TLS files may include: - Certificate files (`*.crt`): These files contain the public key and the identity (domain name) and are used for encryption. They can be self-signed or signed by a certificate authority (CA). - Key files (`*.key`): These contain the private key associated with the certificate. The private key should be kept secure and confidential. - CA files: These are certificates of the certificate authorities. They are used to verify if a given certificate is trusted. You can find the names of all TLS Secrets using this command: ```bash join -t $'\t' \ <(kubectl get pod --namespace -o jsonpath="{range .spec.containers[0].volumeMounts[*]}{.name}{'\t'}{.mountPath}{'\n'}{end}" | awk '$2 ~ /^\/etc\/tls\/certs\// {print $1"\t"$2}' | sort) \ <(kubectl get pod --namespace -o jsonpath="{range .spec.volumes[?(@.secret)]}{.name}{'\t'}{.secret.secretName}{'\n'}{end}" | sort) \ | awk 'BEGIN{printf "%-25s\t%-40s\n", "SECRET", "MOUNT PATH"} {printf "%-25s\t%-40s\n", $3, $2}' ``` SECRET MOUNT PATH redpanda-default-cert /etc/tls/certs/default redpanda-external-cert /etc/tls/certs/external Then, you can save the TLS files to your local file system. For example: ```bash kubectl get secret --namespace redpanda-external-cert -o go-template='{{ index .data "ca.crt" | base64decode }}' > ca.crt ``` Now, you can configure clients with the path to the TLS files. For details about TLS, see [TLS for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/tls/). ### [](#connect-to-the-external-http-proxy)Connect to the external HTTP Proxy To connect to the HTTP Proxy, use its configured external port. To find the port, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the external port on the container is 8082. The external node port on the worker node is 30082. ```yaml listeners: http: external: default: port: 8083 advertisedPorts: - 30082 ``` To test an external connection, you can use the cURL command-line client inside the container running a Redpanda broker: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8083/topics -sS ``` If SASL authentication is enabled, provide a username and password using basic authentication: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8083/topics -u : -sS ``` If TLS is enabled, specify the HTTPS protocol and pass the path to the `ca.crt` file: ```bash kubectl exec --namespace -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8083/topics --cacert /etc/tls/certs/external/ca.crt -sS ``` > 📝 **NOTE** > > If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the `--cacert` flag. For all available endpoints, see the [HTTP Proxy API](https://docs.redpanda.com/api/doc/http-proxy/). ### [](#connect-to-external-schema-registry)Connect to external Schema Registry To connect to the Schema Registry, use its configured external port. To find the port, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the external port on the container is 8084. The external node port on the worker node is 30081. ```yaml listeners: schemaRegistry: external: default: port: 8084 advertisedPorts: - 30081 ``` To test an external connection, you can use the cURL command-line client inside the container running a Redpanda broker: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8084/subjects -sS ``` If SASL authentication is enabled, provide a username and password using basic authentication: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:8084/subjects -u : -sS ``` If TLS is enabled, specify the HTTPS protocol and pass the path to the `ca.crt` file: ```bash kubectl exec --namespace -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:8084/subjects --cacert /etc/tls/certs/external/ca.crt -sS ``` > 📝 **NOTE** > > If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the `--cacert` flag. For all available endpoints, see the [Schema Registry API](https://docs.redpanda.com/api/doc/schema-registry). ### [](#connect-to-external-admin-api)Connect to external Admin API To connect to the Admin API, use its configured external port. To find the port, check the Helm values: ```bash helm get values --namespace --all ``` In this example, the external port on the container is 8084. The external node port on the worker node is 30081. ```yaml listeners: schemaRegistry: external: default: port: 9645 advertisedPorts: - 31644 ``` To test an external connection, you can use the cURL command-line client inside the container running a Redpanda broker: ```bash kubectl exec --namespace -- curl http://redpanda-0.redpanda.redpanda.svc.cluster.local:9645/v1/node_config -sS ``` If TLS is enabled, specify the HTTPS protocol and pass the path to the `ca.crt` file: ```bash kubectl exec --namespace -- curl https://redpanda-0.redpanda.redpanda.svc.cluster.local:9645/v1/node_config --cacert /etc/tls/certs/external/ca.crt -sS ``` > 📝 **NOTE** > > If the broker’s certificate is signed by a well-known, trusted CA, and you’re confident about the integrity of your system’s CA trust store, you don’t need the `--cacert` flag. For all available endpoints, see the [Admin API](https://docs.redpanda.com/api/doc/admin). ## [](#next-steps)Next steps [Configure Listeners in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/networking/k-configure-listeners/) ## [](#suggested-reading)Suggested reading - [About Networking and Connectivity in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/networking/k-networking-and-connectivity/) - [rpk Profiles](https://docs.redpanda.com/streaming/23.3/get-started/config-rpk-profile/) - [Configure Authentication for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/authentication/k-authentication/) - [TLS for Redpanda in Kubernetes](https://docs.redpanda.com/streaming/23.3/manage/kubernetes/security/tls/) - [API and SDK Reference](https://docs.redpanda.com/streaming/23.3/reference/api-reference/) - [Kubernetes Helm Chart Specifications](https://docs.redpanda.com/streaming/23.3/reference/k-helm-index/) - [Kubernetes Custom Resource Definitions](https://docs.redpanda.com/streaming/23.3/reference/k-crd-index/)