# Deploy Redpanda Console on 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: Deploy Redpanda Console on Kubernetes latest-redpanda-tag: v26.2.1 latest-console-tag: v3.9.0 latest-operator-version: v26.2.1 # EOL = End-of-Life (support lifecycle status) page-is-nearing-eol: "false" page-is-past-eol: "false" page-eol-date: July 28, 2027 latest-connect-version: 4.104.0 docname: console/kubernetes/deploy page-component-name: streaming page-version: "26.2" page-component-version: "26.2" page-component-title: Streaming page-relative-src-path: console/kubernetes/deploy.adoc page-edit-url: https://github.com/redpanda-data/docs/edit/main/modules/deploy/pages/console/kubernetes/deploy.adoc description: Deploy Redpanda Console on Kubernetes using the Redpanda Operator, Helm charts, or YAML manifests. page-topic-type: how-to personas: platform_operator learning-objective-1: Deploy Redpanda Console on Kubernetes using the Redpanda Operator, Helm charts, or YAML manifests learning-objective-2: Configure TLS and SASL authentication for Redpanda Console learning-objective-3: Verify and scale a Redpanda Console deployment page-git-created-date: "2025-08-15" page-git-modified-date: "2026-07-28" support-status: supported --- This page shows you how to deploy Redpanda Console as a standalone service on Kubernetes using the Redpanda Operator (Console custom resource), Helm charts, or YAML manifests. > 📝 **NOTE** > > When you deploy a Redpanda cluster using the [Redpanda Operator or Redpanda Helm chart](https://docs.redpanda.com/streaming/current/deploy/redpanda/kubernetes/k-production-deployment/), Redpanda Console is automatically deployed alongside your cluster. > > Use this standalone deployment guide only when you need to: > > - Connect to a Redpanda cluster running outside Kubernetes. > > - Deploy Redpanda Console independently from your Redpanda cluster. > > - Deploy multiple Redpanda Console instances for different environments. After reading this page, you will be able to: - Deploy Redpanda Console on Kubernetes using the Redpanda Operator, Helm charts, or YAML manifests - Configure TLS and SASL authentication for Redpanda Console - Verify and scale a Redpanda Console deployment ## [](#prerequisites)Prerequisites - You must have a running Redpanda or Kafka cluster available to connect to. Redpanda Console requires a cluster to function. For instructions on deploying a Redpanda cluster, see [Deploy on Kubernetes](https://docs.redpanda.com/streaming/current/deploy/redpanda/kubernetes/). - Review the [system requirements for Redpanda Console on Kubernetes](https://docs.redpanda.com/streaming/current/deploy/console/kubernetes/k-requirements/). ## [](#install-redpanda-console)Install Redpanda Console Choose your deployment method. #### Operator The Redpanda Operator provides a `Console` custom resource (CR) that lets you deploy and manage Redpanda Console declaratively. The operator handles the lifecycle of the Console deployment, including creating the underlying Deployment, Service, and ConfigMap resources. 1. Create a Console custom resource: `console.yaml` ```yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Console metadata: name: redpanda-console namespace: redpanda spec: cluster: clusterRef: (1) name: redpanda replicaCount: 2 (2) resources: (3) requests: cpu: 100m memory: 512Mi limits: cpu: 4000m memory: 2Gi service: (4) type: LoadBalancer port: 8080 ingress: (5) enabled: true annotations: cert-manager.io/cluster-issuer: letsencrypt-prod className: nginx hosts: - host: console.example.com paths: - path: / pathType: Prefix tls: - secretName: console-tls hosts: - console.example.com ``` | 1 | Reference to your Redpanda cluster CR. The operator automatically configures broker addresses, TLS, and authentication based on the referenced cluster. If your Redpanda cluster is not managed by the operator, use staticConfiguration instead of clusterRef. See the TLS section for staticConfiguration examples. | | --- | --- | | 2 | For production, run at least two replicas for high availability and rolling upgrades. | | 3 | Adjust resource requests and limits based on your expected workload and available node resources. | | 4 | Use LoadBalancer for cloud environments or when you want Redpanda Console to be accessible from outside the cluster. Use ClusterIP for internal-only access. | | 5 | Enable and configure Ingress if you want to expose Redpanda Console using a domain name and use TLS/HTTPS. Make sure your cluster has an Ingress controller installed. To use the Kubernetes Gateway API instead of Ingress, see Expose Redpanda Console with the Gateway API. | 2. Apply the Console CR: ```bash kubectl apply -f console.yaml --namespace redpanda ``` The operator reconciles the Console CR and creates the necessary Deployment, Service, and ConfigMap resources. #### Helm 1. Create a values file: The values file is where you configure how Redpanda Console connects to your Redpanda or Kafka cluster. You must specify the broker addresses in the `config.kafka.brokers` section. `console-values.yaml` ```yaml config: kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9092 (1) - redpanda-1.redpanda.redpanda.svc.cluster.local:9092 - redpanda-2.redpanda.redpanda.svc.cluster.local:9092 # Resource configuration resources: (2) requests: cpu: 100m memory: 512Mi limits: cpu: 4000m memory: 2Gi # High availability configuration replicaCount: 2 (3) # Pod anti-affinity for node separation affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/name: console topologyKey: kubernetes.io/hostname # Service configuration service: (4) type: LoadBalancer port: 8080 # Ingress configuration (optional) ingress: (5) enabled: true annotations: cert-manager.io/cluster-issuer: letsencrypt-prod ingressClassName: nginx hosts: - host: console.example.com paths: - path: / pathType: Prefix tls: - secretName: console-tls hosts: - console.example.com ``` | 1 | Replace these addresses with the internal DNS names or external addresses of your Redpanda brokers. If you deployed Redpanda using the Redpanda Helm chart or Redpanda Operator, you can find the broker service names by running:kubectl get svc -n Look for services named like redpanda-0, redpanda-1, etc. The port is typically 9092 for Kafka traffic. If your brokers are outside the cluster, use their reachable addresses instead. | | --- | --- | | 2 | Adjust resource requests and limits based on your expected workload and available node resources. | | 3 | For production, run at least two replicas for high availability and rolling upgrades. | | 4 | Use LoadBalancer for cloud environments or when you want Redpanda Console to be accessible from outside the cluster. Use ClusterIP for internal-only access. | | 5 | Enable and configure Ingress if you want to expose Redpanda Console using a domain name and use TLS/HTTPS. Make sure your cluster has an Ingress controller installed. To use the Kubernetes Gateway API instead of Ingress, see Expose Redpanda Console with the Gateway API. | 2. Install the chart: ```bash helm install redpanda-console redpanda/console \ --namespace redpanda \ --create-namespace \ --values console-values.yaml ``` ### [](#connect-to-redpanda-clusters-with-tls)Connect to Redpanda clusters with TLS If your Redpanda cluster uses TLS encryption (the default for Helm deployments), you must configure Redpanda Console to connect securely. #### Operator When you use `clusterRef` to reference a Redpanda cluster managed by the operator, TLS is configured automatically. No additional steps are required. If you use `staticConfiguration` to connect to an external cluster with TLS: 1. Extract the CA certificate: ```bash kubectl get secret redpanda-default-root-certificate -n redpanda -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt ``` 2. Create a secret with the CA certificate: ```bash kubectl create secret generic redpanda-console-tls --from-file=ca.crt=ca.crt -n redpanda ``` 3. Configure the Console CR: ```yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Console metadata: name: redpanda-console namespace: redpanda spec: cluster: staticConfiguration: kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9093 tls: caCertSecretRef: name: redpanda-console-tls key: ca.crt secretMounts: - name: redpanda-console-tls secretName: redpanda-console-tls path: /etc/console/secrets ``` 4. Apply the updated Console CR: ```bash kubectl apply -f console.yaml --namespace redpanda ``` #### Helm 1. Run the following command to extract the CA certificate from the Redpanda Helm deployment: ```bash kubectl get secret redpanda-default-root-certificate -n redpanda -o jsonpath='{.data.ca\.crt}' | base64 -d > ca.crt ``` 2. Create a secret named `redpanda-console` in the `redpanda` namespace with the CA certificate: ```bash kubectl create secret generic redpanda-console --from-file=ca.crt=ca.crt -n redpanda ``` 3. In your `console-values.yaml`: ```yaml config: kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9093 tls: enabled: true caFilepath: /etc/console/secrets/ca.crt insecureSkipTlsVerify: true # For local/testing only secretMounts: - name: redpanda-console secretName: redpanda-console path: /etc/console/secrets ``` 4. Upgrade or install Redpanda Console: ```bash helm upgrade --install redpanda-console redpanda/console \ --namespace redpanda \ --values console-values.yaml ``` Redpanda Console now connects securely to your Redpanda cluster using TLS. For production, set `insecureSkipTlsVerify: false` and use a trusted CA. ## [](#expose-console-gateway-api)Expose Redpanda Console with the Gateway API As an alternative to Ingress, you can expose Redpanda Console through a Kubernetes [Gateway API](https://gateway-api.sigs.k8s.io/) HTTPRoute. This feature is in beta and requires Redpanda Operator 26.2 or later, or Redpanda Helm chart 26.2.0 or later. Beta features are not recommended for production environments. The Gateway API separates infrastructure from application routing: your platform team manages a shared Gateway, which is the entry point that terminates TLS, and Redpanda Console attaches to that Gateway with an HTTPRoute that the Redpanda Operator or Helm chart renders and manages for you. Choose the Gateway API over Ingress when your cluster already routes traffic through a Gateway controller, such as Envoy Gateway, Istio, Cilium, or NGINX Gateway Fabric, or when you want typed, role-based routing configuration instead of controller-specific Ingress annotations. Ingress and the Gateway API are mutually exclusive for Redpanda Console: enabling both fails validation with `ingress and gateway cannot both be enabled; use one or the other`. > 📝 **NOTE** > > With an HTTPRoute, TLS terminates at the Gateway’s listener, so you configure the certificate on the Gateway resource instead of in the Redpanda Console configuration. ### [](#prerequisites-2)Prerequisites Redpanda Console and the Redpanda Operator don’t bundle Gateway API resources: 1. Install the Gateway API CRDs and a compatible controller, such as [Envoy Gateway](https://gateway.envoyproxy.io/), [Istio](https://istio.io/latest/docs/tasks/traffic-management/ingress/gateway-api/), [Cilium](https://docs.cilium.io/en/stable/network/servicemesh/gateway-api/gateway-api/), or [NGINX Gateway Fabric](https://github.com/nginx/nginx-gateway-fabric). For versions and installation steps, see the prerequisites in [Configure External Access through Gateway API](https://docs.redpanda.com/streaming/current/manage/kubernetes/networking/external/k-gateway-api/#prerequisites). HTTPRoute ships in the standard channel, so either release channel works for this feature. 2. Create a Gateway for the HTTPRoute to attach to, or identify an existing one: `gateway.yaml` ```yaml apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: my-gateway namespace: gateway-system spec: gatewayClassName: eg (1) listeners: - name: https protocol: HTTPS port: 443 tls: mode: Terminate certificateRefs: - name: console-tls (2) allowedRoutes: namespaces: from: All (3) ``` | 1 | The GatewayClass name depends on your controller. For example, Envoy Gateway installs eg. | | --- | --- | | 2 | A Secret in the Gateway’s namespace that contains the TLS certificate for your Redpanda Console hostname. | | 3 | The listener must allow routes from the namespace where Redpanda Console runs. from: All accepts routes from any namespace. Use from: Selector to restrict which namespaces can attach. | 3. Apply the manifest and verify that the controller accepts the listener: ```bash kubectl apply -f gateway.yaml kubectl get gateway my-gateway --namespace gateway-system \ -o jsonpath='{range .status.listeners[*]}{.name}: {range .conditions[*]}{.type}={.status} {end}{"\n"}{end}' ``` The listener reports `Accepted=True` and `Programmed=True`. ### [](#enable-the-httproute)Enable the HTTPRoute Configure the `gateway` block instead of the `ingress` block: #### Operator 1. Add a `gateway` block to the Console resource: `console.yaml` ```yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Console metadata: name: redpanda-console namespace: redpanda spec: cluster: clusterRef: name: redpanda gateway: enabled: true parentRefs: (1) - name: my-gateway namespace: gateway-system sectionName: https hostnames: (2) - console.example.com path: / (3) pathType: PathPrefix ``` | 1 | References the Gateway that the HTTPRoute attaches to. sectionName optionally pins the route to one listener on that Gateway. Without parentRefs, Redpanda creates the HTTPRoute but it doesn’t attach to any Gateway. | | --- | --- | | 2 | The hostnames that the route matches. Point DNS for these hostnames at the Gateway’s address. | | 3 | The path to match. pathType is one of PathPrefix, Exact, or RegularExpression. | 2. Apply the resource: ```bash kubectl apply -f console.yaml --namespace redpanda ``` The operator creates the HTTPRoute and keeps it in sync with the Console resource. #### Helm 1. Add a `gateway` block to your values file: `console-values.yaml` ```yaml gateway: (1) enabled: true parentRefs: - name: my-gateway namespace: gateway-system sectionName: https hostnames: - console.example.com path: / pathType: PathPrefix ``` | 1 | The fields have the same meaning as in the Console resource: parentRefs selects the Gateway (and optionally one listener through sectionName), hostnames lists the hostnames to match, and pathType is one of PathPrefix, Exact, or RegularExpression. | | --- | --- | 2. Upgrade the release: ```bash helm upgrade --install redpanda-console redpanda/console \ --namespace redpanda \ --values console-values.yaml ``` ### [](#verify-the-route)Verify the route 1. Check that the HTTPRoute exists and that the Gateway accepted it: ```bash kubectl get httproute --namespace redpanda kubectl describe httproute redpanda-console --namespace redpanda ``` In the route’s status, the `Accepted` and `ResolvedRefs` conditions are both `True` for the referenced Gateway. If `Accepted` is `False` with reason `NotAllowedByListeners`, update the Gateway listener’s `allowedRoutes` to include the Redpanda Console namespace. 2. Get the Gateway’s external address and point DNS for your Redpanda Console hostname at it: ```bash kubectl get gateway my-gateway --namespace gateway-system ``` 3. Confirm that Redpanda Console responds through the Gateway. Until DNS is in place, resolve the hostname to the Gateway address explicitly: ```bash curl --resolve console.example.com:443: https://console.example.com -I # Replace with the address from the previous step. ``` ### [](#switch-between-ingress-and-the-gateway-api)Switch between Ingress and the Gateway API To move an existing Redpanda Console deployment from Ingress to the Gateway API, remove or disable the `ingress` block and add the `gateway` block in the same update. The operator or chart deletes the Ingress and creates the HTTPRoute. Switching back works the same way in reverse: remove the `gateway` block, add the `ingress` block, and the operator or chart removes the HTTPRoute and creates an Ingress. > 💡 **TIP** > > To expose the Redpanda cluster itself through the Gateway API, see [Configure External Access through Gateway API](https://docs.redpanda.com/streaming/current/manage/kubernetes/networking/external/k-gateway-api/). ## [](#deploy-redpanda-console-as-standalone-service-with-yaml-manifests)Deploy Redpanda Console as standalone service with YAML manifests If you prefer to deploy using YAML manifests, you can create the following resources: console-deployment.yaml ```yaml apiVersion: apps/v1 kind: Deployment metadata: name: redpanda-console namespace: redpanda labels: app.kubernetes.io/name: console app.kubernetes.io/component: console spec: replicas: 2 selector: matchLabels: app.kubernetes.io/name: console template: metadata: labels: app.kubernetes.io/name: console spec: affinity: podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: app.kubernetes.io/name: console topologyKey: kubernetes.io/hostname containers: - name: console image: docker.redpanda.com/redpandadata/console:v3.9.0 ports: - containerPort: 8080 name: http resources: requests: cpu: 200m memory: 512Mi limits: cpu: 1000m memory: 2Gi env: - name: KAFKA_BROKERS value: "redpanda-0.redpanda.redpanda.svc.cluster.local:9092,redpanda-1.redpanda.redpanda.svc.cluster.local:9092,redpanda-2.redpanda.redpanda.svc.cluster.local:9092" livenessProbe: httpGet: path: /health port: http initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: httpGet: path: /health port: http initialDelaySeconds: 5 periodSeconds: 5 ``` console-service.yaml ```yaml apiVersion: v1 kind: Service metadata: name: redpanda-console namespace: redpanda labels: app.kubernetes.io/name: console spec: type: LoadBalancer ports: - port: 8080 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: console ``` For more complex configurations, create a ConfigMap: console-config.yaml ```yaml apiVersion: v1 kind: ConfigMap metadata: name: redpanda-console-config namespace: redpanda data: config.yaml: | kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9092 - redpanda-1.redpanda.redpanda.svc.cluster.local:9092 - redpanda-2.redpanda.redpanda.svc.cluster.local:9092 server: listenPort: 8080 console: enabled: true ``` Apply the manifests: ```bash kubectl apply -f console-config.yaml kubectl apply -f console-deployment.yaml kubectl apply -f console-service.yaml ``` ## [](#configuration)Configuration Make sure to configure the following settings in your Console CR, values file, or ConfigMap: ### [](#connect-to-redpanda)Connect to Redpanda Configure the connection to your Redpanda cluster by setting the broker addresses in your Console CR or values file. See [Configure Redpanda Console to Connect to a Redpanda Cluster](https://docs.redpanda.com/streaming/current/console/config/connect-to-redpanda/). ### [](#authentication-and-security)Authentication and security For production deployments, configure: - **TLS encryption**: Enable TLS for secure communication - **SASL authentication**: Configure SASL if Redpanda uses authentication - **RBAC**: Set up role-based access control Configure authentication based on your deployment method. #### Operator When you use `clusterRef`, the operator automatically inherits SASL and TLS settings from the referenced Redpanda cluster. No additional Console configuration is needed. To configure SASL manually with `staticConfiguration`: ```yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Console metadata: name: redpanda-console namespace: redpanda spec: cluster: staticConfiguration: kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9092 sasl: enabled: true mechanism: SCRAM-SHA-256 secret: kafka: saslPassword: ``` You can also reference an existing Kubernetes Secret for credentials: ```yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Console metadata: name: redpanda-console namespace: redpanda spec: cluster: staticConfiguration: kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9092 sasl: enabled: true mechanism: SCRAM-SHA-256 username: console-user passwordFilepath: /etc/console/secrets/password secretMounts: - name: kafka-credentials secretName: console-kafka-credentials path: /etc/console/secrets ``` #### Helm Example with SASL authentication: ```yaml config: kafka: brokers: - redpanda-0.redpanda.redpanda.svc.cluster.local:9092 sasl: enabled: true mechanism: SCRAM-SHA-256 username: console-user password: console-password ``` See [Redpanda Console Security](https://docs.redpanda.com/streaming/current/console/config/security/). ## [](#verify-deployment)Verify deployment Use the following steps to confirm that Redpanda Console is running and accessible. ### Operator 1. Check the Console CR status: ```bash kubectl get console -n redpanda ``` The output shows the replica status of your Console deployment: ```bash NAME REPLICAS UPDATED READY AVAILABLE redpanda-console 2 2 2 2 ``` 2. Check pod status: ```bash kubectl get pods -n redpanda -l app.kubernetes.io/name=console ``` 3. Check service status: ```bash kubectl get svc -n redpanda redpanda-console ``` 4. Access the Redpanda Console: 1. If using LoadBalancer: ```bash kubectl get svc -n redpanda redpanda-console -o jsonpath='{.status.loadBalancer.ingress[0].ip}' ``` 2. If using port-forward for testing: ```bash kubectl port-forward -n redpanda svc/redpanda-console 8080:8080 ``` Open [http://localhost:8080](http://localhost:8080) in your browser. ### Helm 1. Check pod status: ```bash kubectl get pods -n redpanda -l app.kubernetes.io/name=console ``` 2. Check service status: ```bash kubectl get svc -n redpanda redpanda-console ``` 3. Access the Redpanda Console: 1. If using LoadBalancer: ```bash kubectl get svc -n redpanda redpanda-console -o jsonpath='{.status.loadBalancer.ingress[0].ip}' ``` 2. If using port-forward for testing: ```bash kubectl port-forward -n redpanda svc/redpanda-console 8080:8080 ``` Open [http://localhost:8080](http://localhost:8080) in your browser. ## [](#scaling)Scaling For production deployments, consider the following scaling strategies: ### [](#horizontal-scaling)Horizontal scaling Scale the deployment: ```bash kubectl scale deployment redpanda-console -n redpanda --replicas=3 ``` ### [](#auto-scaling)Auto-scaling Create an HPA for automatic scaling: console-hpa.yaml ```yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: redpanda-console-hpa namespace: redpanda spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: redpanda-console minReplicas: 2 maxReplicas: 10 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 ``` ## [](#monitoring)Monitoring Configure metrics exposure and Prometheus scraping for Redpanda Console. Enable monitoring for Redpanda Console: ```yaml config: server: metrics: enabled: true port: 9090 ``` ### [](#prometheus-servicemonitor)Prometheus ServiceMonitor If you use the [Prometheus Operator](https://github.com/prometheus-operator/prometheus-operator), deploy a `ServiceMonitor` resource alongside Redpanda Console. Prometheus then discovers and scrapes Console metrics from the `/admin/metrics` endpoint. #### Operator To enable the ServiceMonitor in the Console custom resource, set `monitoring.enabled` to `true`: ```yaml apiVersion: cluster.redpanda.com/v1alpha2 kind: Console metadata: name: redpanda-console namespace: redpanda spec: monitoring: enabled: true (1) scrapeInterval: "30s" (2) labels: (3) release: kube-prometheus-stack cluster: clusterRef: name: redpanda ``` | 1 | Set to true to create a ServiceMonitor resource. Default: false. | | --- | --- | | 2 | How often Prometheus scrapes the metrics endpoint. Default: 1m. | | 3 | Additional labels to apply to the ServiceMonitor. Match your Prometheus Operator’s serviceMonitorSelector by applying the same labels here. | Apply the Console CR: ```bash kubectl apply -f console.yaml --namespace redpanda ``` #### Helm To enable the ServiceMonitor in the Console Helm chart, add the following to your `console-values.yaml`: ```yaml monitoring: enabled: true (1) scrapeInterval: "30s" (2) labels: {} (3) ``` | 1 | Set to true to create a ServiceMonitor resource. Default: false. | | --- | --- | | 2 | How often Prometheus scrapes the metrics endpoint. Default: 1m. | | 3 | Additional labels to apply to the ServiceMonitor. Match your Prometheus Operator’s serviceMonitorSelector by applying the same labels here. For example:monitoring: enabled: true labels: release: kube-prometheus-stack | If you deploy Redpanda Console as a subchart of the Redpanda Helm chart, configure monitoring under the `console` key. All `monitoring` options are available under this key. ```yaml console: monitoring: enabled: true ``` When the Console server is configured with TLS (`config.server.tls.enabled: true`), the ServiceMonitor uses HTTPS and configures CA validation for scraping. ## [](#troubleshooting)Troubleshooting - **Connection refused**: Verify Redpanda broker addresses and network policies - **Authentication failed**: Check SASL credentials and configuration - **Resource limits**: Monitor CPU and memory usage, adjust limits as needed ### [](#logs)Logs Check Redpanda Console logs: ```bash kubectl logs -n redpanda -l app.kubernetes.io/name=console -f ``` ## [](#next-steps)Next steps - [Configure Redpanda Console](https://docs.redpanda.com/streaming/current/console/config/configure-console/) - [Authentication in Redpanda Console](https://docs.redpanda.com/streaming/current/console/config/security/authentication/) - [Authorization in Redpanda Console](https://docs.redpanda.com/streaming/current/console/config/security/authorization/)