mirror of
https://github.com/bitnami/charts.git
synced 2026-03-14 14:57:22 +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
@@ -43,15 +43,73 @@ These commands deploy fluent-bit on the Kubernetes cluster in the default config
|
||||
|
||||
> **Tip**: List all releases using `helm list`
|
||||
|
||||
## Uninstalling the Chart
|
||||
## Configuration and installation details
|
||||
|
||||
To uninstall/delete the `my-release` statefulset:
|
||||
### 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.
|
||||
|
||||
### Persistence
|
||||
|
||||
The [Bitnami Fluent Bit](https://github.com/bitnami/containers/tree/main/bitnami/fluent-bit) doesn't implement storage persistence by default, but you could mount an extraVolume with Persistent Volume Claims to keep the buffer and/or the output if configured out-of-memory (see [Buffering & Storage](https://docs.fluentbit.io/manual/administration/buffering-and-storage))
|
||||
|
||||
### 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.
|
||||
|
||||
### Sidecars
|
||||
|
||||
If additional containers are needed in the same pod as fluent-bit (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the main section.
|
||||
|
||||
```yaml
|
||||
sidecars:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too.
|
||||
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 main section.
|
||||
|
||||
## Parameters
|
||||
|
||||
@@ -265,74 +323,6 @@ The command removes all the Kubernetes components associated with the chart and
|
||||
| `metrics.serviceMonitor.selector` | Prometheus instance selector labels | `{}` |
|
||||
| `extraDeploy` | Array of extra objects to deploy with the release | `[]` |
|
||||
|
||||
## 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.
|
||||
|
||||
### Persistence
|
||||
|
||||
The [Bitnami Fluent Bit](https://github.com/bitnami/containers/tree/main/bitnami/fluent-bit) doesn't implement storage persistence by default, but you could mount an extraVolume with Persistent Volume Claims to keep the buffer and/or the output if configured out-of-memory (see [Buffering & Storage](https://docs.fluentbit.io/manual/administration/buffering-and-storage))
|
||||
|
||||
### 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.
|
||||
|
||||
### Sidecars
|
||||
|
||||
If additional containers are needed in the same pod as fluent-bit (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the main section.
|
||||
|
||||
```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 main section.
|
||||
|
||||
## 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