Skip to content

bug: With stakater reloader restart option, one replica is getting restarted #1504

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

Open
btalakola opened this issue Mar 17, 2025 · 2 comments

Comments

@btalakola
Copy link
Contributor

btalakola commented Mar 17, 2025

Describe the issue

Hi @cw-Guo & Team, Deployed fluent-bit using fluent-operator with v3.3.0. I am using stakater reloader as below to restart the fluent-bit pods in case of any configurational changes:

Restart fluent-bit daemonset using stakater relaoder if there are any configurational changes.

fluent-bit
annotations:
secret.reloader.stakater.com/reload: "fluent-bit-config"

This is restarting only one replica of fluent-bit daemonset though the "kubectl rollout restart daemonsets fluent-bit -n namespace-dummy" restarting all the replicas. Is there anything that I need to work on using stakater reloader? Can you please please help me out here. Thanks in advance!

Similar issue ref : #1479

To Reproduce

Deployed fluent-bit using fluent-operator with v3.3.0. I am using stakater reloader to restart the fluent-bit pods in case of any configurational changes. This actually restarting only one replica of fluent-bit daemonset

Expected behavior

With stakater reload option, should actually restart all the replicas.

Your Environment

- Fluent Operator version:v3.3.0
- Container Runtime:
- Operating system:
- Kernel version:

How did you install fluent operator?

No response

Additional context

No response

@cw-Guo
Copy link
Collaborator

cw-Guo commented Mar 17, 2025

Hi @btalakola that's depends on how the tool stakater reloader implement the rollout.

Steps to resolve this issue:

  1. understand how stakater reloader implement the rollout, I would assume that they use an annotation to implement that.
  2. refer to this feat: support rollout restart for daemonset and statefulset #1375 to retain that annotation too.

@btalakola
Copy link
Contributor Author

btalakola commented Mar 24, 2025

@cw-Guo Thanks for the response.

  1. For the Point#1: Stakater reloader implmenets the rollout restart in the following manner : https://github.com/stakater/Reloader/blob/master/internal/pkg/callbacks/rolling_upgrade.go#L382-L387

// UpdateDaemonSet performs rolling upgrade on daemonSet func UpdateDaemonSet(clients kube.Clients, namespace string, resource runtime.Object) error { daemonSet := resource.(*appsv1.DaemonSet) _, err := clients.KubernetesClient.AppsV1().DaemonSets(namespace).Update(context.TODO(), daemonSet, meta_v1.UpdateOptions{FieldManager: "Reloader"}) return err }
2. For the Point#2 : With PR-1375, fluent operator "kubectl rollout restart daemonsets fluent-bit -n ns-dummy " issue is fixed but not the Reloader use case. We have Reloader uses for other deamonsets where the restart of the pods is working fine in case configmap/secret changes but it is not working fine for fluent operator. Can you provide any suggestions to make it to work as expected?

Thanks in advance!

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

No branches or pull requests

2 participants