mirror of
https://github.com/bjw-s-labs/helm-charts.git
synced 2025-07-03 08:37:03 +02:00
feat(common): Release common 4.0.0 (#398)
Co-authored-by: lab-assistant[bot] <180935599+lab-assistant[bot]@users.noreply.github.com>
This commit is contained in:
Bernd Schorgers
parent
1e210f43e3
commit
a01a89cb13
327 changed files with 11181 additions and 7330 deletions
84
docs/common-library/howto/default-pod-options.md
Normal file
84
docs/common-library/howto/default-pod-options.md
Normal file
|
|
@ -0,0 +1,84 @@
|
|||
---
|
||||
hide:
|
||||
- toc
|
||||
---
|
||||
|
||||
# Setting default Pod options
|
||||
|
||||
It is possible to configure default Pod options under the `defaultPodOptions` key. These options will be applied to all Pods specified in the chart values.
|
||||
|
||||
To see which fields can be configured, please take a look at the Chart values schema specific to your Common library version. The latest version can be found here: https://github.com/bjw-s-labs/helm-charts/blob/main/charts/library/common/schemas/pod.json
|
||||
|
||||
## Default value strategies
|
||||
|
||||
### Overwrite
|
||||
|
||||
The default strategy for configuring default Pod options is `overwrite`. This means that if a controller has an entry for a default Pod option it will be overwritten entirely by the Pod-specific configuration.
|
||||
|
||||
This behavior can be set explicitly by setting `defaultPodOptionsStrategy` to `overwrite`.
|
||||
|
||||
An (abbreviated) example of the `overwrite` strategy:
|
||||
|
||||
```yaml
|
||||
defaultPodOptions:
|
||||
resources:
|
||||
requests:
|
||||
memory: 1Gi
|
||||
cpu: 150m
|
||||
|
||||
controllers:
|
||||
main:
|
||||
pod:
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
|
||||
containers:
|
||||
main:
|
||||
...
|
||||
```
|
||||
|
||||
The expected `resources` field on the `main` Deployment is expected to look like this:
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
```
|
||||
|
||||
### Merge
|
||||
|
||||
An alternative strategy for configuring default Pod options is `merge`. This means that if a Pod has an entry for a default Pod option it will be merged with the Pod-specific configuration.
|
||||
|
||||
This behavior can be set explicitly by setting `defaultPodOptionsStrategy` to `merge`.
|
||||
|
||||
An (abbreviated) example of the `merge` strategy:
|
||||
|
||||
```yaml
|
||||
defaultPodOptionsStrategy: merge
|
||||
defaultPodOptions:
|
||||
resources:
|
||||
requests:
|
||||
memory: 1Gi
|
||||
cpu: 150m
|
||||
|
||||
controllers:
|
||||
main:
|
||||
pod:
|
||||
resources:
|
||||
requests:
|
||||
cpu: 100m
|
||||
|
||||
containers:
|
||||
main:
|
||||
...
|
||||
```
|
||||
|
||||
The expected `resources` field on the `main` Deployment is expected to look like this:
|
||||
|
||||
```yaml
|
||||
resources:
|
||||
requests:
|
||||
memory: 1Gi
|
||||
cpu: 100m
|
||||
```
|
||||
42
docs/common-library/resources/names.md
Normal file
42
docs/common-library/resources/names.md
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# Names
|
||||
|
||||
### Configuration
|
||||
|
||||
Each resource that can be created by the Common library supports the following fields to control the generated resource name, along with the resource identifier.
|
||||
|
||||
All of these fields support the use of Helm templates for advanced naming requirements.
|
||||
|
||||
#### forceRename
|
||||
|
||||
Override the default resource name entirely.
|
||||
|
||||
!!! info
|
||||
The `forceRename` field is mutually exclusive with the `prefix` and `suffix` fields.
|
||||
|
||||
#### prefix
|
||||
|
||||
Prefix to prepend to the resource name.
|
||||
|
||||
#### suffix
|
||||
|
||||
Suffix to append to the resource name. Defaults to the resource identifier if there are multiple enabled items, otherwise it defaults to an empty value.
|
||||
|
||||
### Behavior
|
||||
|
||||
Assuming a Helm Release with the name `base_name`, the following table gives an overview of how the resource name is generated:
|
||||
|
||||
| item key | enabled items | `prefix` | `suffix` | `forceRename` | Generated name |
|
||||
|----------|---------------|----------|----------|----------------------------|------------------------|
|
||||
| `id` | 1 | | | `random_name` | `random_name` |
|
||||
| `id` | 1 | | | `{{ .Release.Namespace }}` | `default` |
|
||||
| `id` | 1 | | | | `base_name` |
|
||||
| `id` | 1 | `pfx` | | | `pfx-base_name` |
|
||||
| `id` | 1 | | `sfx` | | `base_name-sfx` |
|
||||
| `id` | 2 | | | | `base_name-id` |
|
||||
| `id` | 1 | `pfx` | `sfx` | | `pfx-base_name-sfx` |
|
||||
| `id` | 2 | `pfx` | | | `pfx-base_name-id` |
|
||||
| `id` | 2 | | `sfx` | | `base_name-id-sfx` |
|
||||
| `id` | 2 | `pfx` | `sfx` | | `pfx-base_name-id-sfx` |
|
||||
| `id` | 1 | | `sfx` | | `base_name-sfx` |
|
||||
| `id` | 1 | `pfx` | | | `pfx-base_name` |
|
||||
| `id` | 1 | `pfx` | `sfx` | | `pfx-base_name-sfx` |
|
||||
|
|
@ -45,6 +45,10 @@ Specify if the volume should be mounted read-only
|
|||
|
||||
Specifies a sub-path inside the referenced volume instead of its root.
|
||||
|
||||
### subPathExpr
|
||||
|
||||
Use the `subPathExpr` field to construct `subPath` directory names from downward API environment variables. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath-expanded-environment) for more information.
|
||||
|
||||
## advancedMounts
|
||||
|
||||
Explicitly configure mounts for specific controllers and containers.
|
||||
|
|
@ -86,3 +90,7 @@ Specify if the volume should be mounted read-only
|
|||
### subPath
|
||||
|
||||
Specifies a sub-path inside the referenced volume instead of its root.
|
||||
|
||||
### subPathExpr
|
||||
|
||||
Use the `subPathExpr` field to construct `subPath` directory names from downward API environment variables. See the [Kubernetes documentation](https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath-expanded-environment) for more information.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue