Apache Kafka® client libraries must be able to connect to every Redpanda broker instance. If the client and broker are on different subnets, advertise the location of the broker in the Redpanda configuration file so other brokers in the cluster can be found. If not, clients connecting to brokers outside their local network experience connectivity issues.
Clients must connect to Redpanda with a TCP socket. A TCP socket is described by an IP address of an interface and a port on the machine that Redpanda runs on. For example:
redpanda: kafka_api: - address: 0.0.0.0 port: 9092
An address of
0.0.0.0 means that Redpanda listens on all interfaces.
By default, the advertised address is the address the listener is bound to, but this is not usually an externally-routable address. Set the advertised address to an address the client can use to connect to the instance of Redpanda.
If the client exists on another subnet, then it needs to know how to reach Redpanda. Do this by configuring the advertised address of the Kafka API in
redpanda.yaml. For example, if Redpanda is running on the subnet
192.168.4.0/24 with IP address
192.168.4.1, and the clients are running on the subnet
192.168.5.0/24, then the client machine needs a gateway configured to route requests to
redpanda: advertised_kafka_api: - address: 192.168.4.1 port: 9092
It’s also possible to advertise a host name, provided the client can resolve the DNS and has a route to the host.
Sometimes it’s useful to have multiple configurations for accessing Redpanda with multiple routes.
Do this by creating multiple listeners, and providing a name for the listener. The name is used to connect the listener and its advertised address. For example:
redpanda: kafka_api: - name: local address: 127.0.0.1 port: 9092 - name: subnet address: 192.168.4.1 port: 9093 advertised_kafka_api: - name: local address: 127.0.0.1 port: 9092 - name: subnet address: 192.168.4.1 port: 9093
You can also create additional listeners for different configurations of TLS or authentication.
Redpanda supports using both SASL and mTLS principal extraction authentication methods using multiple listeners. This supports a variety of Kafka clients using various authentication schemes all connecting to your cluster. For example:
redpanda: kafka_api: - address: 0.0.0.0 port: 9092 name: sasl_listener authentication_method: sasl kafka_api: - address: 0.0.0.0 port: 9092 name: mtls_listener authentication_method: mtls_identity kafka_api_tls: - name: mtls_listener key_file: mtls_server.key cert_file: mtls_server.crt truststore_file: mtls_ca.crt enabled: true require_client_auth: true
advertised_kafka_api: The address that Kafka clients connect to, for each listener.
advertised_rpc_api: The address that other Redpanda instances connect to.
advertised_pandaproxy_api: The address that HTTP clients connect to, for each listener.