-
Notifications
You must be signed in to change notification settings - Fork 14.5k
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
[WIP] Add controller reference pages #16885
[WIP] Add controller reference pages #16885
Conversation
Deploy preview for kubernetes-io-master-staging ready! Built with commit 1b006ad https://deploy-preview-16885--kubernetes-io-master-staging.netlify.com |
@kubernetes/sig-apps-pr-reviews |
Thinking about this one, I might change the storage pages to better reflect how the code really works. At the moment this make it sound like you can separate out the volume controllers, and according to pv_controller.go you can't easily do that: // ==================================================================
// PLEASE DO NOT ATTEMPT TO SIMPLIFY THIS CODE.
// KEEP THE SPACE SHUTTLE FLYING.
// ================================================================== |
/retitle [WIP] Add controller reference pages |
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.
Leaving some general feedback on DaemonSet controller page
|
||
{{% capture body %}} | ||
|
||
The DaemonSet controller is built in to the {{< glossary_tooltip term_id="kube-controller-manager" >}}. |
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.
The DaemonSet controller is built in to the {{< glossary_tooltip term_id="kube-controller-manager" >}}. | |
The DaemonSet controller is built-in to the {{< glossary_tooltip term_id="kube-controller-manager" >}}. |
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'll see if I can reword to avoid having to pick a side (dash vs. no dash).
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.
How's this?
If a DaemonSet's Pods fail the controller recreates them, applying a rate | ||
limit to avoid a hot loop of killing and then recreating broken Pods. | ||
|
||
## How DaemonSet Pods are scheduled |
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.
For this section maybe you'll want to take from #17476 restructuring to make sure the default behavior is clear. Or we can tag that issue and move it into here after this PR is merged, depends really how you see this restructure progressing
c21ae0b
to
089e449
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
089e449
to
02b6c65
Compare
02b6c65
to
1b006ad
Compare
Some good detail in https://github.com/kubernetes/enhancements/blob/299448d3d066d1e24054b6aa8fd8f494aad1c3c5/keps/sig-auth/20190607-certificates-api.md#signers I hope I can add a commit that includes these details. |
Hello @sftim , |
I'm wondering if this would work better as a series of PRs to a long-lived branch. That way, I can get each PR reviewed individually. Maybe that'd be a better idea? In which case, I should arrange for that new branch. |
Alternative: I could do lots of small PRs to add disabled pages, and then enable them once the set of changes are ready. |
@sftim, It may be helpful to create an issue outlining your proposed work items and then you can check off the items with individual pull requests (the issue can manage the state of the collective PRs). |
/close |
@sftim: Closed this PR. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Relevant to issue #4135. Rework of PR #15374. Preview.
Add a reference section that lists the built-in controllers and explains what each of them does.
This change fits in with an idea I have to restructure https://kubernetes.io/docs/concepts/workloads/
People developing things to deploy on Kubernetes need to understand that there is (eg) a Deployment resource; it doesn't matter as much how the Deployment resource gets translated into API actions like creating or removing ReplicaSet objects. Some resources happen to involve more than one controller (eg Job with the Job controller and the TTL-after-finished controller).
If you are interested in looking behind the scenes, I think it helps to have all kube-controller-manager controllers listed in one place, no matter what kind of resource they interact with (Endpoint? ReplicaSet? Namespace?)
/sig apps
Credit to @lavalamp for the excellent Kubecon talk that helped me a lot with drafting these documents.