bjw-s-labs Helm Charts

repository·main·Indexed 21 days ago

https://github.com/bjw-s-labs/helm-charts

A collection of Helm charts for running various applications in home Kubernetes cluster environments. It includes the `common` library chart for shared functions and templates, and the `app-template` chart for application deployments. Supports installation via standard Helm repositories, OCI (GitHub Container Registry), Flux HelmRelease, and Kustomize.

Tokens
71.8K
Snippets
163
Records
326
Agent score
76%

What's inside bjw-s-labs-helm-charts

  1. Overview of available Helm charts

    main

    The bjw-s-labs/helm-charts repository provides a collection of reusable Helm charts for deploying applications in Kubernetes. The primary charts available are:

    • App Template: A specialized application chart built on top of the Common Library. It allows you to deploy any application by defining your Kubernetes resource requirements directly within a values.yaml file.
    • Multus CNI: A chart used to deploy Multus CNI into a Kubernetes cluster, which enables pods to have multiple network interfaces.
    • Common Library: A library chart that provides reusable template functions for standard Kubernetes resources such as Deployments, Services, ConfigMaps, and Ingress.
  2. Understand User and Group settings in securityContext

    main

    You can specify the UID and GID for the container's entrypoint process using runAsUser and runAsGroup.

    • Precedence: These settings can also be defined in a PodSecurityContext. However, if a value is specified in the container-level securityContext, it takes precedence over the PodSecurityContext value.
    • runAsNonRoot: Setting runAsNonRoot: true forces the Kubelet to validate at runtime that the container is not running as UID 0 (root). If it is, the container will fail to start.
    • runAsUser Default: If runAsUser is not specified, it defaults to the user specified in the container image metadata.
  3. Manage Ingress resource naming

    main

    You can control the name of the generated Kubernetes Ingress resource using three mutually exclusive methods:

    1. forceRename: Provides a complete override of the default resource name.
    2. prefix: Prepends a specific string to the default resource name.
    3. suffix: Appends a specific string to the default resource name. If not provided, it defaults to the resource identifier if multiple items exist, or an empty string otherwise.
  4. Customize ServiceMonitor resource naming

    main

    You can control the name of the generated ServiceMonitor resource using one of three mutually exclusive methods:

    1. forceRename: Overrides the default resource name entirely.
    2. prefix: Prepends a string to the default resource name.
    3. suffix: Appends a string to the default resource name. Defaults to the resource identifier if multiple items exist, otherwise empty.

    Note: You cannot use forceRename in combination with prefix or suffix.

  5. Configure seLinuxOptions for containers

    main

    The seLinuxOptions object defines the SELinux context applied to containers. If this is not specified, the container runtime allocates a random SELinux context for each container.

    Precedence and Constraints:

    • If seLinuxOptions is set in both SecurityContext (container-level) and PodSecurityContext (pod-level), the value in SecurityContext takes precedence for that specific container.
    • This field cannot be used when spec.os.name is set to windows.
  6. Customize RBAC resource names using prefix, suffix, or forceRename

    main

    You can control the generated name of the RBAC resource using three mutually exclusive methods:

    1. prefix: Prepends a string to the resource name.
    2. suffix: Appends a string to the resource name. If multiple role instances exist, it defaults to the resource identifier; otherwise, it is empty.
    3. forceRename: Completely overrides the default resource name.

    Note: You cannot use forceRename in combination with prefix or suffix.

  7. Use postStart lifecycle hooks

    main

    A postStart hook is executed immediately after a container is created. It is used to perform initialization tasks within the container.

    Important Behaviors:

    • Failure Handling: If the hook handler fails, the container is terminated and restarted according to its defined restart policy.
    • Blocking: Other container management operations are blocked until the hook completes.

    For more detailed Kubernetes lifecycle specifications, refer to the official Kubernetes documentation.

  8. Manage service resource naming

    main

    You can customize the name of the generated Service resource using one of the following methods. Note that these options are mutually exclusive:

    1. forceRename: Use this to completely override the default resource name.
    2. prefix: Prepend a string to the default resource name.
    3. suffix: Append a string to the default resource name. If multiple services are defined, the suffix defaults to the service identifier; otherwise, it is empty.
  9. Customize ServiceAccount resource names

    main

    You can control the name of the generated serviceAccount using three mutually exclusive methods. You cannot use more than one of these at a time:

    1. forceRename: Provides a complete override of the default resource name.
    2. prefix: Prepends a specific string to the default resource name.
    3. suffix: Appends a specific string to the default resource name. If not provided, it defaults to the resource identifier (the key used in the serviceAccount map) if multiple items exist, otherwise it is empty.
  10. Customize Route resource names

    main

    You can modify the generated resource name of a Route using one of three mutually exclusive methods:

    1. forceRename: Provides a complete override of the default resource name.
    2. prefix: Prepends a string to the default resource name.
    3. suffix: Appends a string to the default resource name. If multiple route items exist, the default suffix is the resource identifier; otherwise, it is empty.
  11. Use the preStop lifecycle hook

    main

    The preStop hook is executed immediately before a container is terminated due to an API request or management events (e.g., liveness/startup probe failures, preemption, or resource contention).

    Key Behaviors:

    • Termination Grace Period: The Pod's termination grace period countdown begins before the preStop hook starts. The container will eventually terminate once the grace period expires, regardless of whether the hook succeeds or fails.
    • Blocking: Container management operations block until the hook completes or the grace period is reached.
    • Exclusions: The handler is not called if the container crashes or exits on its own.

    For more details on Kubernetes container lifecycle hooks, refer to the official Kubernetes documentation.