search

kubernetes / sample-controller

Repository for sample controller. Complements sample-apiserver
Apache License 2.0
3.14k stars 1.08k forks source link

What's the recommended way to deploy controllers to prod environments? #71

Closed marcosnils closed 3 years ago

marcosnils commented 4 years ago

Hi,

Thx for putting up this project, it really helped on understand how controller works and as a start point to implement my custom controller.

I have two questions that could really help me finish my project implementation.

  1. As the title of this issue says, what's the recommended way to deploy the controller to a production cluster once it's ready to be shipped? Put it in a docker image and create a deployment? Is there something else to take into consideration before putting the controller intro production?

  2. What's the reason for queuing the object key instead of the actual object in the worker queue here (https://github.com/kubernetes/sample-controller/blob/bf5c061a2037b0c8a0da885e3cca780c92f23503/controller.go#L339-L345). I have a use-case where I need to detect an object deletion and fetch some annotations from the object that's being deleted to perform some actions. I've tried to hook that logic here (https://github.com/kubernetes/sample-controller/blob/bf5c061a2037b0c8a0da885e3cca780c92f23503/controller.go#L253-L259) but since I'm getting the key of the deleted object and not the actual object being deleted I'm not able to do so. What I did instead is queuing the whole object instead of the key as I didn't see any other way to do this. Is this correct?

Thanks

caoruidong commented 4 years ago

2) Because workqueue is for any type. It's better to use the name than a specific type.

gianarb commented 4 years ago

Hello, @caoruidong is it a valid answer but it does not cover the use case @marcosnils expressed.

The queue is a general-purpose so it does not require a type, but if you know that only one type will ever get managed by your queue because it is required by your business logic the queue will stay general purpose, or you can have a solid logic that casts what you dequeue until you find what's needed otherwise it triggers an error or it skips.

What I learned is that when you can is great to store just a key because it forces you to fetch a fresh object for a particular resource, in case of multi updates for example.

For complex objects, somebody else will change its state along the way, as soon as it gets created.

The problem you are facing with the delete action is legit and I think it is safe to inject the entire resource if you can accept that at the point the worker will get the resource it won't be in its real state. Because you are likely enqueuing an object that is in termination state but when you dequeue it, it is terminated, but you still get it in termination.

Eventual consistency is hard but if you deeply know your use case and that's fine for you I think there is nothing bad about enqueueing the concrete object, but I am happy to be wrong here.

fejta-bot commented 4 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle stale

fejta-bot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /lifecycle rotten

fejta-bot commented 3 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta. /close

k8s-ci-robot commented 3 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes/sample-controller/issues/71#issuecomment-716410749): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-testing, kubernetes/test-infra and/or [fejta](https://github.com/fejta). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.