This chart was originally forked from incubator/common
, which is designed to make it easier for you to build and maintain Helm charts.
It provides utilities that reflect best practices of Kubernetes chart development, making it faster for you to write charts.
The following command allows you to download and install all the charts from our repository:
$ helm repo add hahow https://hahow-helm-charts.storage.googleapis.com/
To use the library chart, common
should be listed in dependencies
field in your Chart.yaml
:
dependencies:
- name: common
version: 0.4.1
repository: https://hahow-helm-charts.storage.googleapis.com/
Once you have defined dependencies, you should run the following command to download this chart into your charts/
directory:
$ helm dep build
The best way to get started is to use the create
script to generate a new chart.
You can fetch that script, and then execute it locally:
$ curl -fsSL -o create.sh https://raw.githubusercontent.com/hahow/common-chart/master/create.sh
$ chmod 700 create.sh
$ ./create.sh mychart
or simply
$ curl https://raw.githubusercontent.com/hahow/common-chart/master/create.sh | bash -s -- mychart
Now, there is a chart in ./mychart
. You can edit it and create your own templates.
Kubernetes defines a variety of resource kinds, from Secret
to StatefulSet
. We define some of the most common kinds in a way that lets you easily work with them.
The resource kind templates are designed to make it much faster for you to define basic versions of these resources. They allow you to extend and modify just what you need, without having to copy around lots of boilerplate.
To make use of these templates you must define a template that will extend the base template (though it can be empty). The name of this template is then passed to the base template, for example:
{{- include "common.service" (list . .Values.service "mychart.service") }}
{{- define "mychart.service" -}}
## Define overrides for your Service resource here, e.g.
# metadata:
# labels:
# custom: label
# spec:
# ports:
# - port: 8080
# targetPort: http
# protocol: TCP
# name: http
{{- end }}
Note that the common.service
template defines three parameters:
- The root context (usually
.
) - A dictionary of values which are used in the template
- A optional template name containing the service definition overrides
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.
Each implemented base resource is described in greater detail below.
The common.configMap
template accepts a list of two values:
$top
, the top context- [optional] the template name of the overrides
It creates an empty ConfigMap
resource that you can override with your configuration.
Example use:
{{- include "common.configMap" (list . "mychart.configMap") }}
{{- define "mychart.configMap" -}}
data:
zeus: cat
athena: cat
julius: cat
one: |-
{{ .Files.Get "file1.txt" }}
{{- end }}
Output:
apiVersion: v1
data:
athena: cat
julius: cat
one: This is a file.
zeus: cat
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
The common.cronJob
template accepts a list of five values:
$top
, the top context$cronJob
, a dictionary of values used in the cronjob template$pod
, a dictionary of values used in the pod template$serviceAccount
, a dictionary of values used in the service account template- [optional] the template name of the overrides
It defines a basic CronJob
with the following defaults:
- Labels of
JobTemplate
are defined withcommon.selectorLabels
as this is also used as the selector. - Restart policy of pod is set to
OnFailure
In addition, it uses the following configuration from the $cronJob
:
Value | Description |
---|---|
$cronJob.schedule |
Schedule for the cronjob |
$cronJob.concurrencyPolicy |
[optional] Allow|Forbid|Replace concurrent jobs |
$cronJob.failedJobsHistoryLimit |
[optional] Specify the number of failed jobs to keep |
$cronJob.successfulJobsHistoryLimit |
[optional] Specify the number of completed jobs to keep |
$cronJob.suspend |
[optional] Specify cronjob is suspend, default false |
$cronJob.activeDeadlineSeconds |
[optional] Specify cronjob activeDeadlineSeconds |
Underneath the hood, it invokes common.pod.template
template with $pod
to populate the PodTemplate
.
Example use:
{
{
- include "common.cronJob" (list . .Values.cronJob .Values .Values.serviceAccount),
},
}
## The following is the same as above:
# {{- include "common.cronJob" (list . .Values.cronJob .Values .Values.serviceAccount "mychart.cronJob") }}
# {{- define "mychart.cronJob" -}}
# {{- end }}
The common.deployment
template accepts a list of five values:
$top
, the top context$deployment
, a dictionary of values used in the deployment template$autoscaling
, a dictionary of values used in the hpa template$serviceAccount
, a dictionary of values used in the service account template- [optional] the template name of the overrides
It defines a basic Deployment
with the following settings:
Value | Description |
---|---|
$deployment.replicaCount |
Number of replica. If autoscaling enabled, this field will be ignored |
$deployment.imagePullSecrets |
[optional] Name of Secret resource containing private registry credentials |
$deployment.podSecurityContext |
[optional] Security options for pod |
$deployment.nodeSelector |
[optional] Node labels for pod assignment |
$deployment.affinity |
[optional] Expressions for affinity |
$deployment.tolerations |
[optional] Toleration labels for pod assignment |
$autoscaling.enabled |
[optional] Set this to true to enable autoscaling |
Underneath the hood, it invokes common.pod.template
template with $deployment
to populate the PodTemplate
.
Example use:
{
{
- include "common.deployment" (list . .Values .Values.autoscaling .Values.serviceAccount),
},
}
## The following is the same as above:
# {{- include "common.deployment" (list . .Values .Values.autoscaling .Values.serviceAccount "mychart.deployment") }}
# {{- define "mychart.deployment" -}}
# {{- end }}
The common.hpa
template accepts a list of three values:
$top
, the top context$autoscaling
, a dictionary of values used in the hpa template- [optional] the template name of the overrides
It creates a basic HorizontalPodAutoscaler
resource with the following defaults:
- The name of scaled target is set with
common.fullname
An example values file that can be used to configure the HorizontalPodAutoscaler
resource is:
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 5
cpuUtilizationPercentage: 50
memoryUtilizationPercentage: 90
Example use:
{ { - include "common.hpa" (list . .Values.autoscaling) } }
## The following is the same as above:
# {{- include "common.hpa" (list . .Values.autoscaling "mychart.hpa") }}
# {{- define "mychart.hpa" -}}
# {{- end }}
Output:
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
spec:
maxReplicas: 5
metrics:
- resource:
name: cpu
target:
averageUtilization: 50
type: Utilization
type: Resource
- resource:
name: memory
target:
averageUtilization: 90
type: Utilization
type: Resource
minReplicas: 3
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: release-name-mychart
The common.ingress
template accepts a list of four values:
$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
It is designed to give you a well-defined Ingress
resource, that can be configured using $ingress
. An example values file that can be used to configure the Ingress
resource is:
ingress:
enabled: true
annotations:
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"
hosts:
- host: chart-example.local
paths:
- path: /path/to/somewhere
pathType: ImplementationSpecific
tls:
- secretName: chart-example-tls
hosts:
- chart-example.local
service:
type: ClusterIP
port: 80
Example use:
{ { - include "common.ingress" (list . .Values.ingress .Values.service) } }
## The following is the same as above:
# {{- include "common.ingress" (list . .Values.ingress .Values.service "mychart.ingress") }}
# {{- define "mychart.ingress" -}}
# {{- end }}
Output:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
annotations:
kubernetes.io/ingress.class: nginx
kubernetes.io/tls-acme: "true"
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
spec:
rules:
- host: "chart-example.local"
http:
paths:
- backend:
service:
name: release-name-mychart
port:
number: 80
path: /path/to/somewhere
pathType: ImplementationSpecific
tls:
- hosts:
- "chart-example.local"
secretName: chart-example-tls
The common.pdb
template accepts a list of five values:
$top
, the top context$pdb
, a dictionary of values used in the hpa template$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
It creates a basic PodDisruptionBudget
resource with the following defaults:
- Selector is set with
common.selectorLabels
to match the default used in thePod
resource
An example values file that can be used to configure the PodDisruptionBudget
resource is:
podDisruptionBudget:
## You can specify only one of maxUnavailable and minAvailable in a single PodDisruptionBudget
minAvailable: 2
# maxUnavailable: 1
Example use:
{
{
- include "common.pdb" (list . .Values.podDisruptionBudget .Values .Values.autoscaling),
},
}
## The following is the same as above:
# {{- include "common.pdb" (list . .Values.podDisruptionBudget .Values .Values.autoscaling "mychart.pdb") }}
# {{- define "mychart.pdb" -}}
# {{- end }}
Output:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
spec:
minAvailable: 2
selector:
matchLabels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
The common.secret
template accepts a list of two values:
$top
, the top context- [optional] the template name of the overrides
It creates an empty Secret
resource that you can override with your secrets.
Example use:
{{- include "common.secret" (list . "mychart.secret") }}
{{- define "mychart.secret" -}}
data:
zeus: {{ print "cat" | b64enc }}
athena: {{ print "cat" | b64enc }}
julius: {{ print "cat" | b64enc }}
one: |-
{{ .Files.Get "file1.txt" | b64enc }}
{{- end }}
Output:
apiVersion: v1
data:
athena: Y2F0
julius: Y2F0
one: VGhpcyBpcyBhIGZpbGUuCg==
zeus: Y2F0
kind: Secret
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
type: Opaque
The common.service
template accepts a list of three values:
$top
, the top context$service
, a dictionary of values used in the service template- [optional] the template name of the overrides
It creates a basic Service
resource with the following defaults:
- Service type (ClusterIP, NodePort, LoadBalancer) made configurable by
$service.type
- Named port
http
configured on port$service.port
- Selector set with
common.selectorLabels
to match the default used in theDeployment
resource
Example template:
{{- include "common.service" (list . .Values.service "mychart.mail.service") }}
{{- 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
protocol: mail
spec:
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
protocol: mail
{{- end }}
---
{{ include "common.service" (list . .Values.service "mychart.web.service") }}
{{- 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
protocol: www
spec:
ports: # composes the `ports` section of the service definition.
- name: www
port: 80
targetPort: 8080
{{- end }}
The above template defines two services: a web service and a mail service.
The most important part of a service definition is the ports
object, which defines the ports that this service will listen on. Most of the time, selector
is computed for you. But you can replace it or add to it.
The output of the example above is:
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
protocol: www
name: release-name-mychart-www
spec:
ports:
- name: www
port: 80
targetPort: 8080
selector:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
type: ClusterIP
---
apiVersion: v1
kind: Service
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
protocol: mail
name: release-name-mychart-mail
spec:
ports:
- name: smtp
port: 25
targetPort: 25
- name: imaps
port: 993
targetPort: 993
selector:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
protocol: mail
type: ClusterIP
The common.serviceAccount
template accepts a list of three values:
$top
, the top context$serviceAccount
, a dictionary of values used in the service account template- [optional] the template name of the overrides
It creates a basic ServiceAccount
resource with the following defaults:
- The name is set with
common.serviceAccountName
- Lays out the annotations using
$serviceAccount.annotations
An example values file that can be used to configure the ServiceAccount
resource is:
serviceAccount:
create: true
annotations: {}
name:
Example use:
{ { - include "common.serviceAccount" (list . .Values.serviceAccount) } }
## The following is the same as above:
# {{- include "common.serviceAccount" (list . .Values.serviceAccount "mychart.serviceAccount") }}
# {{- define "mychart.serviceAccount" -}}
# {{- end }}
Output:
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
The common.serviceMonitor
template accepts a list of three values:
$top
, the top context$serviceMonitor
, a dictionary of values used in the service account template- [optional] the template name of the overrides
It creates a basic ServiceMonitor
resource with the following defaults:
- Namespace selector is set to the release namespace
- Selector is set with
common.selectorLabels
to match the default used in theService
resource
An example values file that can be used to configure the ServiceMonitor
resource is:
serviceMonitor:
enabled: true
namespace: monitoring
port: 80
path: /path/to/metrics
interval: 30s
scrapeTimeout: 30s
basicAuth:
enabled: true
username: administrator
password: password
Example use:
{ { - include "common.serviceMonitor" (list . .Values.serviceMonitor) } }
## The following is the same as above:
# {{- include "common.serviceMonitor" (list . .Values.serviceMonitor "mychart.serviceMonitor") }}
# {{- define "mychart.serviceMonitor" -}}
# {{- end }}
Output:
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
namespace: monitoring
spec:
endpoints:
- basicAuth:
password:
key: password
name: release-name-mychart
username:
key: username
name: release-name-mychart
interval: 30s
path: /path/to/metrics
port: 80
scrapeTimeout: 30s
namespaceSelector:
matchNames:
- default
selector:
matchLabels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
The common.serviceMonitor.secret
template accepts a list of three values:
$top
, the top context$serviceMonitor
, a dictionary of values used in the service account template- [optional] the template name of the overrides
It creates a Secret
resource contains the BasicAuth information for the ServiceMonitor
.
An example values.yaml
for your ServiceMonitor
could look like:
serviceMonitor:
basicAuth:
enabled: true
username: administrator
password: password
Example use:
{ { - include "common.serviceMonitor.secret" (list . .Values.serviceMonitor) } }
## The following is the same as above:
# {{- include "common.serviceMonitor.secret" (list . .Values.serviceMonitor "mychart.serviceMonitor.secret") }}
# {{- define "mychart.serviceMonitor.secret" -}}
# {{- end }}
Output:
apiVersion: v1
data:
password: cGFzc3dvcmQ=
username: YWRtaW5pc3RyYXRvcg==
kind: Secret
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
namespace: monitoring
type: Opaque
When writing Kubernetes resources, you may find the following helpers useful to construct parts of the spec.
The common.chart
helper prints the chart name and version, escaped to be legal in a Kubernetes label field.
Example template:
helm.sh/chart: { { include "common.chart" . } }
For the chart foo
with version 1.2.3-beta.55+1234
, this will render:
helm.sh/chart: foo-1.2.3-beta.55_1234
(Note that +
is an illegal character in label values)
The common.container
template accepts a list of three values:
$top
, the top context$container
, a dictionary of values used in the container template- [optional] the template name of the overrides
It creates a basic Container
spec to be used within a Deployment
or CronJob
. It holds the following defaults:
- The name is set to the chart name
- Uses
$container.image
to describe the image to run, with the following spec:image: repository: nginx tag: stable pullPolicy: IfNotPresent
- Lays out the security options using
$container.securityContext
- Lays out the compute resources using
$container.resources
Example use:
{{- include "common.deployment" (list . .Values .Values.autoscaling "mychart.deployment") }}
{{- define "mychart.deployment" -}}
## Define overrides for your Deployment resource here, e.g.
{{- $top := first . }}
{{- $deployment := index . 1 }}
spec:
template:
spec:
containers:
- {{- include "common.container" (list $top $deployment "mychart.deployment.container") | nindent 8 }}
{{- end }}
{{- define "mychart.deployment.container" -}}
## Define overrides for your Container here, e.g.
ports:
- name: http
containerPort: 80
protocol: TCP
livenessProbe:
httpGet:
path: /
port: http
readinessProbe:
httpGet:
path: /
port: http
{{- 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 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:
replicaCount: 1
image:
repository: nginx
tag: stable
pullPolicy: IfNotPresent
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
resources:
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 100m
memory: 128Mi
The output of running the above values through the earlier template is:
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
template:
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
spec:
containers:
- image: nginx:stable
imagePullPolicy: IfNotPresent
livenessProbe:
httpGet:
path: /
port: http
name: mychart
ports:
- containerPort: 80
name: http
protocol: TCP
readinessProbe:
httpGet:
path: /
port: http
resources:
limits:
cpu: 100m
memory: 128Mi
requests:
cpu: 100m
memory: 128Mi
securityContext:
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
serviceAccountName: release-name-mychart
The common.fullname
template generates a name suitable for the name:
field in Kubernetes metadata. It is used like this:
name: { { include "common.fullname" . } }
This prints the value of {{ .Release.Name }}-{{ .Chart.Name }}
by default, but can be overridden with .Values. fullnameOverride
:
fullnameOverride: some-name
Example output:
---
# with the values above
name: some-name
---
# the default, for release "release-name" and chart "mychart"
name: release-name-mychart
Output of this function is truncated at 63 characters, which is the maximum length of name.
common.selectorLabels
prints the standard set of labels.
Example usage:
{{ include "common.labels" . }}
Example output:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
The common.metadata
helper generates value for the metadata:
section of a Kubernetes resource.
This takes a list of two values:
$top
, the top context- [optional] the template name of the overrides
It generates standard labels and a name field.
Example template:
metadata: { { - include "common.metadata" (list .) | nindent 2 } }
## The following is the same as above:
# metadata:
# {{- include "common.metadata" (list . "mychart.metadata") | nindent 2 }}
# {{- define "mychart.metadata" -}}
# {{- end }}
Example output:
metadata:
labels:
app.kubernetes.io/instance: release-name
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: mychart
app.kubernetes.io/version: 1.16.0
helm.sh/chart: mychart-0.1.0
name: release-name-mychart
Most of the common templates that define a resource type (e.g. common.configMap
or common.cronJob
) use this to generate the metadata, which means they inherit the same labels
and name
fields.
The common.name
template generates a name suitable for the app.kubernetes.io/name
label. It is used like this:
app.kubernetes.io/name: { { include "common.name" . } }
This prints the value of {{ .Chart.Name }}
by default, but can be overridden with .Values.nameOverride
:
nameOverride: some-name
Example output:
---
# with the values above
app.kubernetes.io/name: some-name
---
# the default, for chart "mychart"
app.kubernetes.io/name: mychart
Output of this function is truncated at 63 characters, which is the maximum length of name.
The common.pod.template
template accepts a list of four values:
$top
, the top context$pod
, a dictionary of values used in the container template$serviceAccount
, a dictionary of values used in the service account 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:
- Labels are defined with
common.selectorLabels
as this is also used as the selector. - Service account name is set with
common.serviceAccountName
It also uses the following configuration from the $pod
:
Value | Description |
---|---|
$pod.imagePullSecrets |
Names of secrets containing private registry credentials |
$pod.podAnnotations |
Pod annotations |
$pod.podSecurityContext |
Security options |
$pod.nodeSelector |
Node labels for pod assignment |
$pod.affinity |
Expressions for affinity |
$pod.tolerations |
Toleration labels for pod assignment |
$pod.podLabels |
Pod extra labels |
$pod.priorityClassName |
Pod priorityClassName |
Underneath the hood, it invokes common.container
template with $pod
to populate the PodSpec
's container list.
common.selectorLabels
prints the standard set of selector labels.
Example usage:
{{ include "common.selectorLabels" . }}
Example output:
app.kubernetes.io/instance: release-name
app.kubernetes.io/name: mychart
The common.serviceAccountName
template accepts a list of two values:
$top
, the top context$serviceAccount
, a dictionary of values used in the service account template
It generates a name suitable for the serviceAccountName
field of a Pod
resource.
Example usage:
serviceAccountName: {{ include "common.serviceAccountName" . .Values.serviceAccount }}
The following values can influence the output:
serviceAccount:
create: true
# The name of the service account to use.
# If not set and create is true, a name is generated using the fullname template
name: some-name
Example output:
---
# with the values above
serviceAccountName: some-name
---
# if serviceAccount.name is not set, the value will be the same as "common.fullname"
serviceAccountName: release-name-mychart
---
# if serviceAccount.create is false, the value will be "default"
serviceAccountName: default