Strimzi exposes individual Kafka brokers outside Kubernetes
Strimzi 0.7 adds external listeners through OpenShift Routes, load balancers and node ports. Each mode exposes individual brokers as well as bootstrap, with TLS and authentication configured as separate concerns.
An external Kafka client needs more than a reachable bootstrap address. It also needs addresses for the individual brokers it will contact. Strimzi's September 19 release of 0.7 addresses that deployment problem through external listeners. The supported exposure methods are OpenShift Routes, load balancer services and node port services.
The tagged listener documentation explains that each mode creates a separate way to reach each broker alongside an additional bootstrap endpoint. That is the important mechanism. A successful connection to one generic service does not, by itself, show that the client's subsequent broker connections can reach their destinations.
I regard Kafka's partition-local ordering as an important constraint on application design. The deployment has to preserve the corresponding ability to reach the broker responsible for a partition. Exposing the service therefore requires more attention to advertised endpoints than a single front-end address might suggest.
Each exposure mode supplies a broker addressing arrangement
The Route mode creates a dedicated OpenShift Route for every broker pod and another for bootstrap. Clients use the routes on port 443 through the OpenShift HAProxy router. The documentation explicitly limits this mode to OpenShift. It is not a generic Kubernetes Ingress configuration.
The load balancer mode creates a LoadBalancer service for each broker plus an additional bootstrap service. These listen on 9094. A cluster with several brokers consequently needs several externally provisioned endpoints, rather than one load balancer that stands in for every advertised broker identity.
The load balancer access procedure tells the operator to discover the bootstrap service's hostname or IP address. It separately extracts the broker certificate authority's public certificate for client TLS configuration. Discovering an endpoint and establishing trust in the connection remain distinct steps.
This arrangement has a clear operational implication. The chosen platform must actually provide the load balancer services represented by the configuration. Declaring the mode describes the desired resources, while the allocated addresses describe what clients can use. An external client configuration needs the latter information.
Node ports use the node's address and a distinct port per broker
The node port mode exposes each broker through a separate port and creates an additional bootstrap service. Clients connect to Kubernetes or OpenShift nodes directly. The documentation calls out firewall and security-group access because those node ports must be reachable from the client's network.
For advertised broker addresses, Strimzi selects an address on the node running the broker pod. The documented priority starts with external DNS, followed by external IP and hostname, then internal DNS and internal IP. That priority is part of the implementation's attempt to produce an address useful outside the pod network.
An address being present in node status does not guarantee reachability from every external network. The selection rules explain which address Strimzi chooses, while routing and firewall configuration determine whether the client can use it. Those two parts need to describe the same path.
The node port procedure also describes finding the bootstrap port and selecting a node address. The listener documentation states that TLS hostname verification is not currently supported for this exposure mode. That is a specific limitation of the released arrangement and should remain visible when comparing it with the other modes.
TLS and client authentication are distinct settings
All three external listener types use TLS encryption in this release. The listener's authentication property is separate. The documentation says that omitting authentication means the listener does not authenticate clients. An encrypted connection therefore should not be described as automatically requiring a client identity.
The release also adds SCRAM-SHA-512 support to Kafka Connect and Connect with Source-to-Image. The Connect authentication procedure configures a username and a password reference through a Kubernetes Secret. This concerns Connect's authentication to Kafka, rather than a blanket change to every external client's configuration.
I find these distinctions useful because connectivity, encrypted transport and an authenticated principal answer different questions. A broker endpoint can be reachable without accepting the intended credentials. A TLS listener can encrypt traffic while its authentication property remains absent. The configuration model gives each of those decisions an identifiable place. Authentication must also be configured when the User Operator manages the corresponding Kafka users.
The same release adds network policies for ZooKeeper and Kafka replication ports and narrows RBAC bindings where possible. These changes concern internal communication and operator permissions alongside external reachability. The resulting deployment has explicit resources for outside clients while retaining separate controls over the communication paths and management permissions used inside the cluster.