Skip to content
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

Open
wants to merge 47 commits into
base: main
Choose a base branch
from

Conversation

nightkr
Copy link
Member

@nightkr nightkr commented Aug 4, 2022

Description

Fixes #714.

Blockers:

Followup issues/regressions:

Review Checklist

  • Code contains useful comments
  • CRD change approved (or not applicable)
  • (Integration-)Test cases added (or not applicable)
  • Documentation added (or not applicable)
  • Changelog updated (or not applicable)
  • Cargo.toml only contains references to git tags (not specific commits or branches)
  • Helm chart can be installed and deployed operator works (or not applicable)

Once the review is done, comment bors r+ (or bors merge) to merge. Further information

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.
@nightkr
Copy link
Member Author

nightkr commented Aug 24, 2022

Blocked on stackabletech/listener-operator#1

@maltesander
Copy link
Member

Tested and works!

@lfrancke
Copy link
Member

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?

@siegfriedweber
Copy link
Member

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.

@nightkr
Copy link
Member Author

nightkr commented Sep 12, 2023

Tests currently fail due to stackabletech/listener-operator#110.

@nightkr nightkr marked this pull request as ready for review September 20, 2023 00:42
@nightkr
Copy link
Member Author

nightkr commented Sep 20, 2023

The tests now pass!

@sbernauer
Copy link
Member

sbernauer commented Sep 20, 2023

@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?
It'd be awesome if we get it right in the first run :)

@nightkr
Copy link
Member Author

nightkr commented Sep 20, 2023

Preferably not, since we're still working out a few API kinks there (truststore passwords), and I'd rather keep this PR focused. ^^

@sbernauer sbernauer self-requested a review September 18, 2024 07:08
Copy link
Member

@sbernauer sbernauer left a 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 :)

docs/modules/kafka/examples/getting_started/kafka.yaml Outdated Show resolved Hide resolved
CHANGELOG.md Show resolved Hide resolved
rust/crd/src/security.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/discovery.rs Show resolved Hide resolved
rust/operator-binary/src/kafka_controller.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/kafka_controller.rs Outdated Show resolved Hide resolved
@nightkr nightkr requested a review from sbernauer October 1, 2024 16:01
Copy link
Member

@sbernauer sbernauer left a 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

rust/operator-binary/src/kafka_controller.rs Outdated Show resolved Hide resolved
rust/operator-binary/src/kafka_controller.rs Outdated Show resolved Hide resolved
@nightkr
Copy link
Member Author

nightkr commented Oct 2, 2024

Clients should only configure the bootstrap address(es), the Kafka client is then responsible for resolving that to the relevant replicas.

@sbernauer
Copy link
Member

Agreed. I'm a bit torn between "we should label everything" and "I don't want everything to show in stacklet list".
I'm happy to merge as-is, but than please add a comment above Labels::new() why we choose to not label the broker Listener objects.

@sbernauer
Copy link
Member

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

@sbernauer
Copy link
Member

Somewhat related: Is it intentional that the simple-kafka-broker-default-bootstrap Listener contains the ingressAddress three times in the status?
Do we want to de-duplicate that list in listener-op?

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

@nightkr
Copy link
Member Author

nightkr commented Oct 2, 2024

Somewhat related: Is it intentional that the simple-kafka-broker-default-bootstrap Listener contains the ingressAddress three times in the status?

That smells like a minor bug that I would suggest filing against list-op.

Copy link
Member

@sbernauer sbernauer left a 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(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
&Labels::new(),
&Labels::role_selector(kafka, APP_NAME, &rolegroup_ref.role)
.context(LabelBuildSnafu)?,

Copy link
Member Author

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

7dae34d for the PVC

Copy link
Member Author

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(),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
&Labels::new(),
&Labels::role_group_selector(
kafka,
APP_NAME,
&rolegroup_ref.role,
&rolegroup_ref.role_group,
)
.context(LabelBuildSnafu)?,

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sbernauer
Copy link
Member

That smells like a minor bug that I would suggest filing against list-op.

I was not sure if this was a bug. Created stackabletech/listener-operator#229

@nightkr nightkr requested a review from sbernauer October 2, 2024 14:34
@nightkr
Copy link
Member Author

nightkr commented Oct 4, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Service exposition with ListenerClasses
5 participants