-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate kafka-operator to use listener-operator for exposing brokers #443
base: main
Are you sure you want to change the base?
Conversation
This is far from final (for example, we'd need to expose a configurable LoadBalancerClass, for example), but I wanted to see whether lb-op would be a good fit for this operator first.
9c751ca
to
6c9c18f
Compare
Blocked on stackabletech/listener-operator#1 |
Tested and works! |
7e287d8
to
1f5a4e5
Compare
I've moved this back into "Ready for Development" because the Listener operator is now merged. AFAIU this should now be ready to be worked on again? |
This pull request is updated as requested by stackabletech/listener-operator#5. When stackabletech/operator-rs#496 is merged and operator-rs and the listener-operator are released then this pull request can be made ready for review. |
Tests currently fail due to stackabletech/listener-operator#110. |
The tests now pass! |
@nightkr do you plan to merge this or add the WIP functionality of secret-op beforehand, so that the kafka broker certificates will include the listener addresses? |
Preferably not, since we're still working out a few API kinks there (truststore passwords), and I'd rather keep this PR focused. ^^ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I started review but was sidetracked again. Submitting my comments early, as you are back :)
Co-authored-by: Sebastian Bernauer <sebastian.bernauer@stackable.de>
…erator into spike/lb-operator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to check: stackablectl stacklet list
currently returns:
│ kafka ┆ simple-kafka ┆ default ┆ broker-default-bootstrap-kafka 172.18.0.2:32639 ┆ Available, Reconciling, Running │
│ ┆ ┆ ┆ broker-default-bootstrap-metrics 172.18.0.2:30178 ┆ │
stackablectl uses the app.kubernetes.io/
labels to find all Listeners for a given stacklet. Only the bootstrap Listener has these labels set, is this intentional? I think this is due to the fact that pvcs inherit the labels of the Pod, but ephemeral volumes not
➜ kafka-operator git:(spike/lb-operator) ✗ k get listener kind-kind
NAME AGE
simple-kafka-broker-default-0-listener-broker 6m51s
simple-kafka-broker-default-1-listener-broker 6m49s
simple-kafka-broker-default-2-listener-broker 6m51s
simple-kafka-broker-default-bootstrap 10m
➜ kafka-operator git:(spike/lb-operator) ✗ k get listener -l app.kubernetes.io/name=kafka kind-kind
NAME AGE
simple-kafka-broker-default-bootstrap 10m
When I set the recommended labels on the ephermal volumes they get propagated to the Listener and all Listeners show up
│ kafka ┆ simple-kafka ┆ default ┆ broker-default-0-listener-broker-kafka 172.18.0.2:32579 ┆ Available, Reconciling, Running │
│ ┆ ┆ ┆ broker-default-0-listener-broker-metrics 172.18.0.2:30432 ┆ │
│ ┆ ┆ ┆ broker-default-1-listener-broker-kafka 172.18.0.2:31088 ┆ │
│ ┆ ┆ ┆ broker-default-1-listener-broker-metrics 172.18.0.2:30439 ┆ │
│ ┆ ┆ ┆ broker-default-2-listener-broker-kafka 172.18.0.2:31803 ┆ │
│ ┆ ┆ ┆ broker-default-2-listener-broker-metrics 172.18.0.2:31150 ┆ │
│ ┆ ┆ ┆ broker-default-bootstrap-kafka 172.18.0.2:32639 ┆ │
│ ┆ ┆ ┆ broker-default-bootstrap-metrics 172.18.0.2:30178 ┆ │
I think I would be in favor of adding the recommended labels to all listener volumes, WDYT?
This is the same thing as we did in hdfs-op in stackabletech/hdfs-operator#534, I would be in favor of copying the implementation from there
Clients should only configure the bootstrap address(es), the Kafka client is then responsible for resolving that to the relevant replicas. |
Agreed. I'm a bit torn between "we should label everything" and "I don't want everything to show in stacklet list". |
Just for the record: I think there is value in having the metrics endpoint for every individual broker, but as most customers will probably use Prometheus ServiceMonitor this is rather low prio |
Somewhat related: Is it intentional that the apiVersion: listeners.stackable.tech/v1alpha1
kind: Listener
metadata:
name: simple-kafka-broker-default-bootstrap
namespace: default
# ...
spec:
className: external-stable
extraPodSelectorLabels: {}
ports:
- name: metrics
port: 9606
protocol: TCP
- name: kafka
port: 9092
protocol: TCP
publishNotReadyAddresses: null
status:
ingressAddresses:
- address: 172.18.0.2
addressType: IP
ports:
kafka: 32639
metrics: 30178
- address: 172.18.0.2
addressType: IP
ports:
kafka: 32639
metrics: 30178
- address: 172.18.0.2
addressType: IP
ports:
kafka: 32639
metrics: 30178
nodePorts:
kafka: 32639
metrics: 30178
serviceName: simple-kafka-broker-default-bootstrap |
That smells like a minor bug that I would suggest filing against list-op. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This are the two changes needed to label the Listener objects correctly. I would prefer to label the Listeners correctly.
This causes them to show up in stacklet list
, if this is undesired we could filter them out there
pvcs.push( | ||
ListenerOperatorVolumeSourceBuilder::new( | ||
&ListenerReference::ListenerName(kafka.bootstrap_service_name(rolegroup_ref)), | ||
&Labels::new(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&Labels::new(), | |
&Labels::role_selector(kafka, APP_NAME, &rolegroup_ref.role) | |
.context(LabelBuildSnafu)?, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7aa5919 applies it to the Listener itself.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7dae34d for the PVC
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Had to revert it slightly to avoid upgrade issues: 2913081
.add_listener_volume_by_listener_class( | ||
LISTENER_BROKER_VOLUME_NAME, | ||
&merged_config.broker_listener_class, | ||
&Labels::new(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
&Labels::new(), | |
&Labels::role_group_selector( | |
kafka, | |
APP_NAME, | |
&rolegroup_ref.role, | |
&rolegroup_ref.role_group, | |
) | |
.context(LabelBuildSnafu)?, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was not sure if this was a bug. Created stackabletech/listener-operator#229 |
It broke upgrading
Description
Fixes #714.
Blockers:
ClusterResources::delete_orphaned_resources
also deletes objects that are not owned directly by it operator-rs#861Followup issues/regressions:
Review Checklist
Once the review is done, comment
bors r+
(orbors merge
) to merge. Further information