mirror of
https://github.com/bitnami/charts.git
synced 2026-03-15 14:57:16 +08:00
[bitnami/*] Reorder Chart sections (#24455)
* [bitnami/*] Reorder Chart sections Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> --------- Signed-off-by: Jota Martos <jotamartos@vmware.com>
This commit is contained in:
Juan José Martos
@@ -39,15 +39,209 @@ The command deploys apisix on the Kubernetes cluster in the default configuratio
|
||||
|
||||
> **Tip**: List all releases using `helm list`
|
||||
|
||||
## Uninstalling the Chart
|
||||
## Configuration and installation details
|
||||
|
||||
To uninstall/delete the `my-release` deployment:
|
||||
### Resource requests and limits
|
||||
|
||||
```console
|
||||
helm delete my-release
|
||||
Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the `resources` value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.
|
||||
|
||||
To make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcePreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers)
|
||||
|
||||
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Deployment modes
|
||||
|
||||
Apache APISIX supports [multiple deployment modes](https://apisix.apache.org/docs/apisix/deployment-modes/). The Bitnami APISIX chart deploys the `decoupled` mode by default, but it is possible to deploy in `traditional` or `standalone` modes as well.
|
||||
|
||||
#### Traditional mode
|
||||
|
||||
The following values configure the traditional mode:
|
||||
|
||||
``` yaml
|
||||
dataPlane:
|
||||
enabled: false
|
||||
controlPlane:
|
||||
extraConfig:
|
||||
deployment:
|
||||
role: traditional
|
||||
role_traditional:
|
||||
config_provider: etcd
|
||||
service:
|
||||
extraPorts:
|
||||
- name: http
|
||||
port: 80
|
||||
targetPort: 9080
|
||||
- name: https
|
||||
port: 443
|
||||
targetPort: 9443
|
||||
```
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
#### Standalone mode
|
||||
|
||||
The following values configure the standalone mode:
|
||||
|
||||
``` yaml
|
||||
controlPlane:
|
||||
enabled: false
|
||||
ingressController:
|
||||
enabled: false
|
||||
etcd:
|
||||
enabled: false
|
||||
dataPlane:
|
||||
extraConfig:
|
||||
deployment:
|
||||
role_data_plane:
|
||||
config_provider: yaml
|
||||
extraVolumes:
|
||||
- name: routes
|
||||
configMap:
|
||||
name: apisix-routes
|
||||
extraVolumeMounts:
|
||||
- name: routes
|
||||
mountPath: /opt/bitnami/apisix/conf/apisix.yaml
|
||||
subPath: apisix.yaml
|
||||
extraDeploy:
|
||||
- apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: apisix-routes
|
||||
data:
|
||||
apisix.yaml: |-
|
||||
routes:
|
||||
-
|
||||
uri: /hello
|
||||
upstream:
|
||||
nodes:
|
||||
"127.0.0.1:1980": 1
|
||||
type: roundrobin
|
||||
```
|
||||
|
||||
### Ingress
|
||||
|
||||
This chart provides support for Ingress resources. If you have an ingress controller installed on your cluster, such as [nginx-ingress-controller](https://github.com/bitnami/charts/tree/main/bitnami/nginx-ingress-controller) or [contour](https://github.com/bitnami/charts/tree/main/bitnami/contour) you can utilize the ingress controller to serve your application.To enable Ingress integration, set `ingress.enabled` to `true`.
|
||||
|
||||
The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `ingress.tls` parameter can be used to add the TLS configuration for this host.
|
||||
|
||||
However, it is also possible to have more than one host. To facilitate this, the `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts.
|
||||
|
||||
> NOTE: For each host specified in the `ingress.extraHosts` parameter, it is necessary to set a name, path, and any annotations that the Ingress controller should know about. Not all annotations are supported by all Ingress controllers, but [this annotation reference document](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md) lists the annotations supported by many popular Ingress controllers.
|
||||
|
||||
Adding the TLS parameter (where available) will cause the chart to generate HTTPS URLs, and the application will be available on port 443. The actual TLS secrets do not have to be generated by this chart. However, if TLS is enabled, the Ingress record will not work until the TLS secret exists.
|
||||
|
||||
[Learn more about Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
|
||||
|
||||
### TLS secrets
|
||||
|
||||
This chart facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). There are several common use cases:
|
||||
|
||||
- Generate certificate secrets based on chart parameters.
|
||||
- Enable externally generated certificates.
|
||||
- Manage application certificates via an external service (like [cert-manager](https://github.com/jetstack/cert-manager/)).
|
||||
- Create self-signed certificates within the chart (if supported).
|
||||
|
||||
In the first two cases, a certificate and a key are needed. Files are expected in `.pem` format.
|
||||
|
||||
Here is an example of a certificate file:
|
||||
|
||||
> NOTE: There may be more than one certificate if there is a certificate chain.
|
||||
|
||||
```text
|
||||
-----BEGIN CERTIFICATE-----
|
||||
MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
|
||||
...
|
||||
jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
Here is an example of a certificate key:
|
||||
|
||||
```text
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
|
||||
...
|
||||
wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc=
|
||||
-----END RSA PRIVATE KEY-----
|
||||
```
|
||||
|
||||
- If using Helm to manage the certificates based on the parameters, copy these values into the `certificate` and `key` values for a given `*.ingress.secrets` entry.
|
||||
- If managing TLS secrets separately, it is necessary to create a TLS secret with name `INGRESS_HOSTNAME-tls` (where INGRESS_HOSTNAME is a placeholder to be replaced with the hostname you set using the `*.ingress.hostname` parameter).
|
||||
- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, add to `*.ingress.annotations` the [corresponding ones](https://cert-manager.io/docs/usage/ingress/#supported-annotations) for cert-manager.
|
||||
- If using self-signed certificates created by Helm, set both `*.ingress.tls` and `*.ingress.selfSigned` to `true`.
|
||||
|
||||
### External etcd support
|
||||
|
||||
You may want to have Mastodon connect to an external etcd rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalEtcd` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example:
|
||||
|
||||
```yaml
|
||||
etcd:
|
||||
enabled: false
|
||||
externalEtcd:
|
||||
hosts:
|
||||
- externalhost
|
||||
```
|
||||
|
||||
### Additional environment variables
|
||||
|
||||
In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
```yaml
|
||||
dataPlane:
|
||||
extraEnvVars:
|
||||
- name: LOG_LEVEL
|
||||
value: error
|
||||
```
|
||||
|
||||
Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
### Sidecars
|
||||
|
||||
If additional containers are needed in the same pod as APISIX (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
```yaml
|
||||
sidecars:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter (where available), as shown in the example below:
|
||||
|
||||
```yaml
|
||||
service:
|
||||
extraPorts:
|
||||
- name: extraPort
|
||||
port: 11311
|
||||
targetPort: 11311
|
||||
```
|
||||
|
||||
> NOTE: This Helm chart already includes sidecar containers for the Prometheus exporters (where applicable). These can be activated by adding the `--enable-metrics=true` parameter at deployment time. The `sidecars` parameter should therefore only be used for any extra sidecar containers.
|
||||
|
||||
If additional init containers are needed in the same pod, they can be defined using the `initContainers` parameter. Here is an example:
|
||||
|
||||
```yaml
|
||||
initContainers:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
Learn more about [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/) and [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
|
||||
|
||||
### Pod affinity
|
||||
|
||||
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
As an alternative, use one of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
## Parameters
|
||||
|
||||
@@ -854,210 +1048,6 @@ helm install my-release -f values.yaml my-repo/apisix
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/apisix/values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### Resource requests and limits
|
||||
|
||||
Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the `resources` value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.
|
||||
|
||||
To make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcePreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers)
|
||||
|
||||
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Deployment modes
|
||||
|
||||
Apache APISIX supports [multiple deployment modes](https://apisix.apache.org/docs/apisix/deployment-modes/). The Bitnami APISIX chart deploys the `decoupled` mode by default, but it is possible to deploy in `traditional` or `standalone` modes as well.
|
||||
|
||||
#### Traditional mode
|
||||
|
||||
The following values configure the traditional mode:
|
||||
|
||||
``` yaml
|
||||
dataPlane:
|
||||
enabled: false
|
||||
controlPlane:
|
||||
extraConfig:
|
||||
deployment:
|
||||
role: traditional
|
||||
role_traditional:
|
||||
config_provider: etcd
|
||||
service:
|
||||
extraPorts:
|
||||
- name: http
|
||||
port: 80
|
||||
targetPort: 9080
|
||||
- name: https
|
||||
port: 443
|
||||
targetPort: 9443
|
||||
```
|
||||
|
||||
#### Standalone mode
|
||||
|
||||
The following values configure the standalone mode:
|
||||
|
||||
``` yaml
|
||||
controlPlane:
|
||||
enabled: false
|
||||
ingressController:
|
||||
enabled: false
|
||||
etcd:
|
||||
enabled: false
|
||||
dataPlane:
|
||||
extraConfig:
|
||||
deployment:
|
||||
role_data_plane:
|
||||
config_provider: yaml
|
||||
extraVolumes:
|
||||
- name: routes
|
||||
configMap:
|
||||
name: apisix-routes
|
||||
extraVolumeMounts:
|
||||
- name: routes
|
||||
mountPath: /opt/bitnami/apisix/conf/apisix.yaml
|
||||
subPath: apisix.yaml
|
||||
extraDeploy:
|
||||
- apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: apisix-routes
|
||||
data:
|
||||
apisix.yaml: |-
|
||||
routes:
|
||||
-
|
||||
uri: /hello
|
||||
upstream:
|
||||
nodes:
|
||||
"127.0.0.1:1980": 1
|
||||
type: roundrobin
|
||||
```
|
||||
|
||||
### Ingress
|
||||
|
||||
This chart provides support for Ingress resources. If you have an ingress controller installed on your cluster, such as [nginx-ingress-controller](https://github.com/bitnami/charts/tree/main/bitnami/nginx-ingress-controller) or [contour](https://github.com/bitnami/charts/tree/main/bitnami/contour) you can utilize the ingress controller to serve your application.To enable Ingress integration, set `ingress.enabled` to `true`.
|
||||
|
||||
The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `ingress.tls` parameter can be used to add the TLS configuration for this host.
|
||||
|
||||
However, it is also possible to have more than one host. To facilitate this, the `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts.
|
||||
|
||||
> NOTE: For each host specified in the `ingress.extraHosts` parameter, it is necessary to set a name, path, and any annotations that the Ingress controller should know about. Not all annotations are supported by all Ingress controllers, but [this annotation reference document](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md) lists the annotations supported by many popular Ingress controllers.
|
||||
|
||||
Adding the TLS parameter (where available) will cause the chart to generate HTTPS URLs, and the application will be available on port 443. The actual TLS secrets do not have to be generated by this chart. However, if TLS is enabled, the Ingress record will not work until the TLS secret exists.
|
||||
|
||||
[Learn more about Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
|
||||
|
||||
### TLS secrets
|
||||
|
||||
This chart facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). There are several common use cases:
|
||||
|
||||
- Generate certificate secrets based on chart parameters.
|
||||
- Enable externally generated certificates.
|
||||
- Manage application certificates via an external service (like [cert-manager](https://github.com/jetstack/cert-manager/)).
|
||||
- Create self-signed certificates within the chart (if supported).
|
||||
|
||||
In the first two cases, a certificate and a key are needed. Files are expected in `.pem` format.
|
||||
|
||||
Here is an example of a certificate file:
|
||||
|
||||
> NOTE: There may be more than one certificate if there is a certificate chain.
|
||||
|
||||
```text
|
||||
-----BEGIN CERTIFICATE-----
|
||||
MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
|
||||
...
|
||||
jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
Here is an example of a certificate key:
|
||||
|
||||
```text
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
|
||||
...
|
||||
wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc=
|
||||
-----END RSA PRIVATE KEY-----
|
||||
```
|
||||
|
||||
- If using Helm to manage the certificates based on the parameters, copy these values into the `certificate` and `key` values for a given `*.ingress.secrets` entry.
|
||||
- If managing TLS secrets separately, it is necessary to create a TLS secret with name `INGRESS_HOSTNAME-tls` (where INGRESS_HOSTNAME is a placeholder to be replaced with the hostname you set using the `*.ingress.hostname` parameter).
|
||||
- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, add to `*.ingress.annotations` the [corresponding ones](https://cert-manager.io/docs/usage/ingress/#supported-annotations) for cert-manager.
|
||||
- If using self-signed certificates created by Helm, set both `*.ingress.tls` and `*.ingress.selfSigned` to `true`.
|
||||
|
||||
### External etcd support
|
||||
|
||||
You may want to have Mastodon connect to an external etcd rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalEtcd` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example:
|
||||
|
||||
```yaml
|
||||
etcd:
|
||||
enabled: false
|
||||
externalEtcd:
|
||||
hosts:
|
||||
- externalhost
|
||||
```
|
||||
|
||||
### Additional environment variables
|
||||
|
||||
In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
```yaml
|
||||
dataPlane:
|
||||
extraEnvVars:
|
||||
- name: LOG_LEVEL
|
||||
value: error
|
||||
```
|
||||
|
||||
Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
### Sidecars
|
||||
|
||||
If additional containers are needed in the same pod as APISIX (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
```yaml
|
||||
sidecars:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter (where available), as shown in the example below:
|
||||
|
||||
```yaml
|
||||
service:
|
||||
extraPorts:
|
||||
- name: extraPort
|
||||
port: 11311
|
||||
targetPort: 11311
|
||||
```
|
||||
|
||||
> NOTE: This Helm chart already includes sidecar containers for the Prometheus exporters (where applicable). These can be activated by adding the `--enable-metrics=true` parameter at deployment time. The `sidecars` parameter should therefore only be used for any extra sidecar containers.
|
||||
|
||||
If additional init containers are needed in the same pod, they can be defined using the `initContainers` parameter. Here is an example:
|
||||
|
||||
```yaml
|
||||
initContainers:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
Learn more about [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/) and [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
|
||||
|
||||
### Pod affinity
|
||||
|
||||
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
As an alternative, use one of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Find more information about how to deal with common errors related to Bitnami's Helm charts in [this troubleshooting guide](https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues).
|
||||
|
||||
Reference in New Issue
Block a user