-
Notifications
You must be signed in to change notification settings - Fork 16.8k
update Review Guidelines for workloads #3334
update Review Guidelines for workloads #3334
Conversation
Initial update with Best Practises.
cc : @kubernetes/charts-maintainers |
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.
Thanks for putting this together!
A little feedback (mostly nits)...
REVIEW_GUIDELINES.md
Outdated
|
||
## Kubernetes Native Workloads. | ||
|
||
While reviewing Charts that contains workloads such as [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Statefulset](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [Daemonset](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) below points should be considered. These are to seen as best practises rather than strict enforcement. |
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.
Some nits...
While reviewing Charts that contains workloads
should be contain
and...
below points should be considered.
should be:
the below points should be considered.
I also noticed practises is misspelled. It should be practices.
REVIEW_GUIDELINES.md
Outdated
|
||
While reviewing Charts that contains workloads such as [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Statefulset](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [Daemonset](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) below points should be considered. These are to seen as best practises rather than strict enforcement. | ||
|
||
1. Any workload that are stateless and long running (servers) in nature are to be created as deployments. Deployments in turn creates replica sets. |
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.
workload should be plural as workloads
REVIEW_GUIDELINES.md
Outdated
While reviewing Charts that contains workloads such as [Deployment](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/), [Statefulset](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/), [Daemonset](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) and [Jobs](https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/) below points should be considered. These are to seen as best practises rather than strict enforcement. | ||
|
||
1. Any workload that are stateless and long running (servers) in nature are to be created as deployments. Deployments in turn creates replica sets. | ||
2. Unless there is a compelling reason replica sets or replica controllers are are to be avoided as workload types. |
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.
replica controllers should be replication controllers
REVIEW_GUIDELINES.md
Outdated
|
||
1. Any workload that are stateless and long running (servers) in nature are to be created as deployments. Deployments in turn creates replica sets. | ||
2. Unless there is a compelling reason replica sets or replica controllers are are to be avoided as workload types. | ||
3. Workloads that are stateful in nature such as Databases, Key Value Store, Messages Queues , In-memory caches are to be created as statefulsets |
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.
There's an extra space between Messages Queues and the comma after it.
Might also be useful to call it StatefulSet everywhere to keep the case consistent in the doc.
REVIEW_GUIDELINES.md
Outdated
1. Any workload that are stateless and long running (servers) in nature are to be created as deployments. Deployments in turn creates replica sets. | ||
2. Unless there is a compelling reason replica sets or replica controllers are are to be avoided as workload types. | ||
3. Workloads that are stateful in nature such as Databases, Key Value Store, Messages Queues , In-memory caches are to be created as statefulsets | ||
4. It is recommended that Deployments and Statefulsets configure their workloads with [Pod Disruption Budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) for high availability. |
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.
It might read better if after "their workloads with" there was an a.
REVIEW_GUIDELINES.md
Outdated
3. Workloads that are stateful in nature such as Databases, Key Value Store, Messages Queues , In-memory caches are to be created as statefulsets | ||
4. It is recommended that Deployments and Statefulsets configure their workloads with [Pod Disruption Budget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/) for high availability. | ||
5. For workloads such as databases, KV store, etc., that replicates data it is recommended to configure interpod anti-affinity. | ||
6. It is recommended to have default workload update strategy configured that is suitable for this chart |
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.
Might read better to update
to have default workload update
to
to have a default workload update
REVIEW_GUIDELINES.md
Outdated
5. For workloads such as databases, KV store, etc., that replicates data it is recommended to configure interpod anti-affinity. | ||
6. It is recommended to have default workload update strategy configured that is suitable for this chart | ||
7. Batch workloads are to be created using Jobs. | ||
8. It is best to always create workload with latest supported [api version]( https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#statefulset-v1-apps) as older version are either depcicated or soon to be depreciated. |
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 latest is only supported in 1.9. apps/v1
isn't supporting in 1.8. Because of these we should use the last api version. Many providers don't even provide 1.9 yet (like GKE).
Thanks for putting this together. Do we really need it this explicit? For my taste it is a little bit too much. |
Apply review comments
@mattfarina Thanks for the review PTAL @unguiculus Sure, its targetted for new reviewers to Chart community who may not be expert with workload apis in K8s, Also do you have any good examples for 'deployment', 'job' and 'DaemonSet' that we can be a good starting point for new contributors/reviewers? |
REVIEW_GUIDELINES.md
Outdated
|
||
More [configuration](https://kubernetes.io/docs/concepts/configuration/overview/) best practises. | ||
|
||
Example Charts that follow above best practices: [Statefulset](https://github.com/kubernetes/charts/tree/master/incubator/zookeeper), [Deployment](), [DaemonSet]() and [Jobs](). |
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.
Zookeeper is not the best example. It doesn't fully follow best practices and is in incubator.
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.
Might I suggest we handling the example in 2 steps.
- Remove them from here, as we don't have a complete best practice set, so we can get this committed.
- Add discussing the examples to the next charts chart meeting so we can figure out which are good to include and then handle that in a second PR.
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.
Agreed
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.
@dhilipkumars if you remove that line it LGTM. Don't see a reason to not merge it then. Thanks for putting this together.
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.
@mattfarina Done
examples to be handled separately.
/lgtm We can iterate on it from here if we like, I think. |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhilipkumars, mattfarina The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
Initial update with Best Practises. PTAL
Ref: #3011
Thank you for contributing to kubernetes/charts. Before you submit this PR we'd like to
make sure you are aware of our technical requirements and best practices:
For a quick overview across what we will look at reviewing your PR, please read
our review guidelines:
Following our best practices right from the start will accelerate the review process and
help get your PR merged quicker.
When updates to your PR are requested, please add new commits and do not squash the
history. This will make it easier to identify new changes. The PR will be squashed
anyways when it is merged. Thanks.