@@ -60,17 +60,17 @@ Note: We use the same [workflow](https://github.com/kubernetes/community/blob/ma
## Owning and Maintaining A Chart
Individual charts can be maintained by one or more members of the Kubernetes community. When someone maintains a chart they have the access to merge changes to that chart. To have merge access to a chart someone needs to:
Individual charts can be maintained by one or more users of GitHub. When someone maintains a chart they have the access to merge changes to that chart. To have merge access to a chart someone needs to:
1. Be listed on the chart, in the `Chart.yaml` file, as a maintainer. If you need sponsors and have contributed to the chart, please reach out to the existing maintainers, or if you are having trouble connecting with them, please reach out to one of the [OWNERS](OWNERS) of the charts repository.
1. Be invited (and accept your invite) as a read-only collaborator on [this repo](https://github.com/helm/charts). This is required for @k8s-ci-robot [PR comment interaction](https://github.com/kubernetes/community/blob/master/contributors/guide/pull-requests.md).
1. An OWNERS file needs to be added to a chart. That OWNERS file should list the maintainers' GitHub login names for both the reviewers and approvers sections. For an example see the [Drupal chart](stable/drupal/OWNERS). The `OWNERS` file should also be appended to the `.helmignore` file.
Once these two steps are done a chart approver can merge pull requests following the directions in the [REVIEW_GUIDELINES.md](REVIEW_GUIDELINES.md) file.
Once these three steps are done a chart approver can merge pull requests following the directions in the [REVIEW_GUIDELINES.md](REVIEW_GUIDELINES.md) file.
## Trusted Collaborator
The `pull-charts-e2e` test run, that installs a chart to test it, is required before a pull request can be merged. These tests run automatically for members of the Helm Org and for chart OWNERS, listed in OWNERS files. For regular contributors who are trusted, in a manner similar to Kubernetes community members, we have trusted collaborators. These individuals can have their tests run automatically as well as mark other pull requests as ok to test by adding a comment of `/ok-to-test` on pull requests.
The `pull-charts-e2e` test run, that installs a chart to test it, is required before a pull request can be merged. These tests run automatically for members of the Helm Org and for chart [repository collaborators](https://help.github.com/articles/adding-outside-collaborators-to-repositories-in-your-organization/). For regular contributors who are trusted, in a manner similar to Kubernetes community members, we have trusted collaborators. These individuals can have their tests run automatically as well as mark other pull requests as ok to test by adding a comment of `/ok-to-test` on pull requests.
There are two paths to becoming a trusted collaborator. One only needs follow one of them.
@@ -16,6 +16,17 @@ Note, if a reviewer who is not an approver in an OWNERS file leaves a comment of
Chart releases must be immutable. Any change to a chart warrants a chart version bump even if it is only changes to the documentation.
## Versioning
The chart `version` should follow [semver](https://semver.org/).
Stable charts should start at `1.0.0` (for maintainability don't create new PRs for stable charts only to meet this criteria, but when reviewing PRs take the opportunity to ensure that this is met).
Any breaking (backwards incompatible) changes to a chart should:
1. Bump the MAJOR version
2. In the README, under a section called "Upgrading", describe the manual steps necessary to upgrade to the new (specified) MAJOR version
## Chart Metadata
The `Chart.yaml` should be as complete as possible. The following fields are mandatory:
...
...
@@ -37,17 +48,17 @@ Stable charts should not depend on charts in incubator.
Resources and labels should follow some conventions. The standard resource metadata (`metadata.labels` and `spec.template.metadata.labels`) should be this:
```yaml
name:{{template "myapp.fullname" .}}
name:{{include "myapp.fullname" .}}
labels:
app:{{template "myapp.name" .}}
chart:{{template "myapp.chart" .}}
release:{{.Release.Name}}
heritage:{{.Release.Service}}
app.kubernetes.io/name:{{include "myapp.name" .}}
app.kubernetes.io/instance:{{.Release.Name}}
app.kubernetes.io/managed-by:{{.Release.Service}}
helm.sh/chart:{{include "myapp.chart" .}}
```
If a chart has multiple components, a `component` label should be added (e. g. `component: server`). The resource name should get the component as suffix (e. g. `name: {{ template "myapp.fullname" . }}-server`).
If a chart has multiple components, a `app.kubernetes.io/component` label should be added (e. g. `app.kubernetes.io/component: server`). The resource name should get the component as suffix (e. g. `name: {{ include "myapp.fullname" . }}-server`).
Note that templates have to be namespaced. With Helm 2.7+, `helm create` does this out-of-the-box. The `app` label should use the `name` template, not `fullname` as is still the case with older charts.
Note that templates have to be namespaced. With Helm 2.7+, `helm create` does this out-of-the-box. The `app.kubernetes.io/name` label should use the `name` template, not `fullname` as is still the case with older charts.
@@ -56,13 +67,13 @@ Note that templates have to be namespaced. With Helm 2.7+, `helm create` does th
```yaml
selector:
matchLabels:
app:{{template "myapp.name" .}}
release:{{.Release.Name}}
app.kubernetes.io/name:{{include "myapp.name" .}}
app.kubernetes.io/instance:{{.Release.Name}}
```
If a chart has multiple components, a `component` label should be added to the selector (see above).
`spec.selector.matchLabels` defined in `Deployments`/`StatefulSets`/`DaemonSets``>=v1/beta2`**must not** contain `chart` label or any label containing a version of the chart, because the selector is immutable.
`spec.selector.matchLabels` defined in `Deployments`/`StatefulSets`/`DaemonSets``>=v1/beta2`**must not** contain `helm.sh/chart` label or any label containing a version of the chart, because the selector is immutable.
The chart label string contains the version, so if it is specified, whenever the the Chart.yaml version changes, Helm's attempt to change this immutable field would cause the upgrade to fail.
#### Fixing Selectors
...
...
@@ -70,39 +81,39 @@ The chart label string contains the version, so if it is specified, whenever the
##### For Deployments, StatefulSets, DaemonSets apps/v1beta1 or extensions/v1beta1
- If it does not specify `spec.selector.matchLabels`, set it
- Remove `chart` label in `spec.selector.matchLabels` if it exists
- Remove `helm.sh/chart` label in `spec.selector.matchLabels` if it exists
- Bump patch version of the Chart
##### For Deployments, StatefulSets, DaemonSets >=apps/v1beta2
- Remove `chart` label in `spec.selector.matchLabels` if it exists
- Remove `helm.sh/chart` label in `spec.selector.matchLabels` if it exists
- Bump major version of the Chart as it is a breaking change
### Service Selectors
Label selectors for services must have both `app` and `release` labels.
Label selectors for services must have both `app.kubernetes.io/name` and `app.kubernetes.io/instance` labels.
```yaml
selector:
app:{{template "myapp.name" .}}
release:{{.Release.Name}}
app.kubernetes.io/name:{{include "myapp.name" .}}
app.kubernetes.io/instance:{{.Release.Name}}
```
If a chart has multiple components, a `component` label should be added to the selector (see above).
If a chart has multiple components, a `app.kubernetes.io/component` label should be added to the selector (see above).
### Persistence Labels
### StatefulSet
In case of a `Statefulset`, `spec.volumeClaimTemplates.metadata.labels` must have both `app` and `release` labels, and **must not** contain `chart` label or any label containing a version of the chart, because `spec.volumeClaimTemplates` is immutable.
In case of a `Statefulset`, `spec.volumeClaimTemplates.metadata.labels` must have both `app.kubernetes.io/name` and `app.kubernetes.io/instance` labels, and **must not** contain `helm.sh/chart` label or any label containing a version of the chart, because `spec.volumeClaimTemplates` is immutable.
```yaml
labels:
app:{{template "myapp.name" .}}
release:{{.Release.Name}}
app.kubernetes.io/name:{{include "myapp.name" .}}
app.kubernetes.io/instance:{{.Release.Name}}
```
If a chart has multiple components, a `component` label should be added to the selector (see above).
If a chart has multiple components, a `app.kubernetes.io/component` label should be added to the selector (see above).
@@ -338,3 +349,13 @@ While reviewing Charts that contain workloads such as [Deployments](https://kube
10. As much as possible complex pre-app setups are configured using [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
More [configuration](https://kubernetes.io/docs/concepts/configuration/overview/) best practices.
## Tests
This repository follows a [test procedure](https://github.com/helm/charts/blob/master/test/README.md). This allows the charts of this repository to be tested according to several rules (linting, semver checking, deployment testing, etc) for every Pull Request.
The `ci` directory of a given Chart allows testing different use cases, by allowing you to define different sets of values overriding `values.yaml`, one file per set. See the [documentation](https://github.com/helm/charts/blob/master/test/README.md#providing-custom-test-values) for more information.
This directory MUST exist with at least one test file in it.
This chart bootstraps an alb-ingress-controller deployment on a [Kubernetes](http://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.
The command deploys alb-ingress-controller on the Kubernetes cluster in the default configuration. The [configuration](#configuration) section lists the parameters that can be configured during installation.
> **Tip**: List all releases using `helm list`
## Uninstalling the Chart
To uninstall/delete the `my-release` deployment:
```console
$helm delete my-release
```
The command removes all the Kubernetes components associated with the chart and deletes the release.
## Configuration
The following tables lists the configurable parameters of the alb-ingress-controller chart and their default values.
