helm/common
1
0
Fork 0
Code Issues Pull Requests 2 Actions Releases Activity

docs: add description about common.pod.template

Browse Source
This commit is contained in:
Chi-En Wu
2020-04-23 11:33:24 +08:00
parent 5fcc2735e2
commit 2434554782
1 changed files with 49 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

75
README.md
View File

@ -43,7 +43,7 @@ To make use of these templates you must define a template that will extend the b
{{- end -}}
```
Note that the `common.service` template defines three parameters:
Note that the [`common.service`](#commonservice) template defines three parameters:
- The root context (usually `.`)
- A dictionary of values which are used in the template
@ -51,7 +51,7 @@ Note that the `common.service` template defines three parameters:
A limitation of the Go template library is that a template can only take a single argument. The `list` function is used to workaround this by constructing a list or array of arguments that is passed to the template.
The `common.service` template is responsible for rendering the templates with the root context and merging any overrides. As you can see, this makes it very easy to create a basic `Service` resource without having to copy around the standard metadata and labels.
The [`common.service`](#commonservice) template is responsible for rendering the templates with the root context and merging any overrides. As you can see, this makes it very easy to create a basic `Service` resource without having to copy around the standard metadata and labels.
Each implemented base resource is described in greater detail below.
@ -61,7 +61,7 @@ Each implemented base resource is described in greater detail below.
The `common.configMap` template accepts a list of two values:
- the top context
- `$top`, the top context
- [optional] the template name of the overrides
It creates an empty `ConfigMap` resource that you can override with your configuration.
@ -106,7 +106,7 @@ metadata:
The `common.deployment` template accepts a list of four values:
- the top context
- `$top`, the top context
- `$deployment`, a dictionary of values used in the deployment template
- `$autoscaling`, a dictionary of values used in the hpa template
- [optional] the template name of the overrides
@ -123,16 +123,7 @@ It defines a basic `Deployment` with the following settings:
| `$deployment.tolerations` | [optional] Toleration labels for pod assignment |
| `$autoscaling.enabled` | [optional] Set this to `true` to enable autoscaling |
Underneath the hood, it uses [`common.container`](#commoncontainer).
By default, the pod template within the deployment defines the labels
```yaml
app.kubernetes.io/name: {{ include "common.name" }}
app.kubernetes.io/instance: {{ .Release.Name }}
```
as this is also used as the selector. The standard set of labels are not used as some of these can change during upgrades, which causes the replica sets and pods to not correctly match.
Underneath the hood, it invokes [`common.pod.template`](#commonpodtemplate) template with `$deployment` to populate the `PodTemplate`.
Example use:
@ -151,7 +142,7 @@ Example use:
The `common.ingress` template accepts a list of four values:
- the top context
- `$top`, the top context
- `$ingress`, a dictionary of values used in the ingress template
- `$service`, a dictionary of values used in the service template
- [optional] the template name of the overrides
@ -225,7 +216,7 @@ spec:
The `common.secret` template accepts a list of two values:
- the top context
- `$top`, the top context
- [optional] the template name of the overrides
It creates an empty `Secret` resource that you can override with your secrets.
@ -271,7 +262,7 @@ type: Opaque
The `common.service` template accepts a list of three values:
- the top context
- `$top`, the top context
- `$service`, a dictionary of values used in the service template
- [optional] the template name of the overrides
@ -293,18 +284,18 @@ Example template:
{{- define "mychart.mail.service" -}}
{{- $top := first . -}}
metadata:
name: {{ include "common.fullname" $top }}-mail # overrides the default name to add a suffix
labels: # appended to the labels section
name: {{ include "common.fullname" $top }}-mail # overrides the default name to add a suffix
labels: # appended to the labels section
protocol: mail
spec:
ports: # composes the `ports` section of the service definition.
ports: # composes the `ports` section of the service definition.
- name: smtp
port: 25
targetPort: 25
- name: imaps
port: 993
targetPort: 993
selector: # this is appended to the default selector
selector: # this is appended to the default selector
protocol: mail
{{- end }}
---
@ -312,11 +303,11 @@ spec:
{{- define "mychart.web.service" -}}
{{- $top := first . -}}
metadata:
name: {{ include "common.fullname" $top }}-www # overrides the default name to add a suffix
labels: # appended to the labels section
name: {{ include "common.fullname" $top }}-www # overrides the default name to add a suffix
labels: # appended to the labels section
protocol: www
spec:
ports: # composes the `ports` section of the service definition.
ports: # composes the `ports` section of the service definition.
- name: www
port: 80
targetPort: 8080
@ -389,7 +380,7 @@ When writing Kubernetes resources, you may find the following helpers useful to
The `common.container` template accepts a list of three values:
- the top context
- `$top`, the top context
- `$container`, a dictionary of values used in the container template
- [optional] the template name of the overrides
@ -435,7 +426,7 @@ readinessProbe:
{{- end -}}
```
The above example creates a `Deployment` resource which makes use of the `common.container` template to populate the PodSpec's container list. The usage of this template is similar to the other resources, you must define and reference a template that contains overrides for the container object.
The above example creates a `Deployment` resource which makes use of the `common.container` template to populate the `PodSpec`'s container list. The usage of this template is similar to the other resources, you must define and reference a template that contains overrides for the container object.
The most important part of a container definition is the image you want to run. As mentioned above, this is derived from `$container.image` by default. It is a best practice to define the image, tag and pull policy in your charts' values as this makes it easy for an operator to change the image registry, or use a specific tag or version. Another example of configuration that should be exposed to chart operators is the container's required compute resources, as this is also very specific to an operators environment. An example `values.yaml` for your chart could look like:
@ -518,3 +509,35 @@ spec:
runAsUser: 1000
serviceAccountName: release-name-mychart
```
### `common.pod.template`
The `common.pod.template` template accepts a list of three values:
- `$top`, the top context
- `$pod`, a dictionary of values used in the container template
- [optional] the template name of the overrides
It creates a basic `PodTemplate` spec to be used within a `Deployment` or `CronJob`. It holds the following defaults:
- Defines the labels
```yaml
app.kubernetes.io/name: {{ include "common.name" }}
app.kubernetes.io/instance: {{ .Release.Name }}
```
as this is also used as the selector.
- Service account name is set with `{{ include "common.serviceAccountName" $top }}`
It also uses the following configuration from the `$pod`:
| Value | Description |
| ----- | ----------- |
| `$pod.imagePullSecrets` | Names of secrets containing private registry credentials |
| `$pod.podSecurityContext` | Security options |
| `$pod.nodeSelector ` | Node labels for pod assignment |
| `$pod.affinity ` | Expressions for affinity |
| `$pod.tolerations ` | Toleration labels for pod assignment |
Underneath the hood, it invokes [`common.container`](#commoncontainer) template with `$pod` to populate the `PodSpec`'s container list.