Open sinamohsenifar opened 1 month ago
The issue may not be directly related to the Bitnami container image/Helm chart, but rather to how the application is being utilized, configured in your specific environment, or tied to a specific scenario that is not easy to reproduce on our side.
If you think that's not the case and are interested in contributing a solution, we welcome you to create a pull request. The Bitnami team is excited to review your submission and offer feedback. You can find the contributing guidelines here.
Your contribution will greatly benefit the community. Feel free to reach out if you have any questions or need assistance.
Suppose you have any questions about the application, customizing its content, or technology and infrastructure usage. In that case, we highly recommend that you refer to the forums and user guides provided by the project responsible for the application or technology.
With that said, we'll keep this ticket open until the stale bot automatically closes it, in case someone from the community contributes valuable insights.
Thank you for your response. I understand that the issue might be specific to our configuration. I am considering contributing a solution and will review the contributing guidelines. Meanwhile, could you provide any additional insights or recommendations on how to configure the listeners in a similar environment effectively? Your guidance will be greatly appreciated.
Hi,
I'm not sure if I understood correctly, but you mention that you want to have separate IPs, right? Would the external access option work for your use case?
## External Access to Kafka brokers configuration
##
externalAccess:
## @param externalAccess.enabled Enable Kubernetes external cluster access to Kafka brokers
##
enabled: false
my request is that let us to define list of additional listeners and advertised listeners, because some times our clienst cant see kafka or kubernetes ips directly.
Hi @sinamohsenifar,
I'm sorry for the late response. The bitnami/kafka
chart already has a feature that allows users to add additional listeners or even override the default ones as desired:
See the 'listeners' section of the values.yaml:
listeners:
## @param listeners.client.name Name for the Kafka client listener
## @param listeners.client.containerPort Port for the Kafka client listener
## @param listeners.client.protocol Security protocol for the Kafka client listener. Allowed values are 'PLAINTEXT', 'SASL_PLAINTEXT', 'SASL_SSL' and 'SSL'
## @param listeners.client.sslClientAuth Optional. If SASL_SSL is enabled, configure mTLS TLS authentication type. If SSL protocol is enabled, overrides tls.authType for this listener. Allowed values are 'none', 'requested' and 'required'
client:
containerPort: 9092
protocol: SASL_PLAINTEXT
name: CLIENT
sslClientAuth: ""
## @param listeners.controller.name Name for the Kafka controller listener
## @param listeners.controller.containerPort Port for the Kafka controller listener
## @param listeners.controller.protocol Security protocol for the Kafka controller listener. Allowed values are 'PLAINTEXT', 'SASL_PLAINTEXT', 'SASL_SSL' and 'SSL'
## @param listeners.controller.sslClientAuth Optional. If SASL_SSL is enabled, configure mTLS TLS authentication type. If SSL protocol is enabled, overrides tls.authType for this listener. Allowed values are 'none', 'requested' and 'required'
## Ref: https://cwiki.apache.org/confluence/display/KAFKA/KIP-684+-+Support+mutual+TLS+authentication+on+SASL_SSL+listeners
controller:
name: CONTROLLER
containerPort: 9093
protocol: SASL_PLAINTEXT
sslClientAuth: ""
## @param listeners.interbroker.name Name for the Kafka inter-broker listener
## @param listeners.interbroker.containerPort Port for the Kafka inter-broker listener
## @param listeners.interbroker.protocol Security protocol for the Kafka inter-broker listener. Allowed values are 'PLAINTEXT', 'SASL_PLAINTEXT', 'SASL_SSL' and 'SSL'
## @param listeners.interbroker.sslClientAuth Optional. If SASL_SSL is enabled, configure mTLS TLS authentication type. If SSL protocol is enabled, overrides tls.authType for this listener. Allowed values are 'none', 'requested' and 'required'
interbroker:
containerPort: 9094
protocol: SASL_PLAINTEXT
name: INTERNAL
sslClientAuth: ""
## @param listeners.external.containerPort Port for the Kafka external listener
## @param listeners.external.protocol Security protocol for the Kafka external listener. . Allowed values are 'PLAINTEXT', 'SASL_PLAINTEXT', 'SASL_SSL' and 'SSL'
## @param listeners.external.name Name for the Kafka external listener
## @param listeners.external.sslClientAuth Optional. If SASL_SSL is enabled, configure mTLS TLS authentication type. If SSL protocol is enabled, overrides tls.sslClientAuth for this listener. Allowed values are 'none', 'requested' and 'required'
external:
containerPort: 9095
protocol: SASL_PLAINTEXT
name: EXTERNAL
sslClientAuth: ""
## @param listeners.extraListeners Array of listener objects to be appended to already existing listeners
## E.g.
## extraListeners:
## - name: CUSTOM
## containerPort: 9097
## protocol: SASL_PLAINTEXT
## sslClientAuth: ""
##
extraListeners: []
## NOTE: If set, below values will override configuration set using the above values (extraListeners.*, controller.*, interbroker.*, client.* and external.*)
## @param listeners.overrideListeners Overrides the Kafka 'listeners' configuration setting.
## @param listeners.advertisedListeners Overrides the Kafka 'advertised.listener' configuration setting.
## @param listeners.securityProtocolMap Overrides the Kafka 'security.protocol.map' configuration setting.
overrideListeners: ""
advertisedListeners: ""
securityProtocolMap: ""
I think the value you may be looking for would be extraListeners
and/or advertisedListeners
/overrideListeners
.
Name and Version
bitnami/kafka
What is the problem this feature will solve?
in some projects, the clients can't see Kubernetes cluster workers. in situations like this, we route their traffic through a firewall virtual IP or from another secure server. we need to configure and modify listeners freely with Kubernetes setup with Nodeport configs.
What is the feature you are proposing to solve the problem?
access to kafka cluster from seperate ips modify listeners separately for broker and controller.
add advertised listeners from different ips.
What alternatives have you considered?
we created kafka cluster with manifests to handle this problem.
sample of broker manifest:
sample of services: