Genpack

Genpack Helm chart is designed to deploy containerized applications as easy as possible. Using the provided information, this chart automatically generates all needed kubernetes resources and keeps them in sync.

• Kubernetes 1.20+
• Helm 3+
• PV provisioner support in the underlying infrastructure (when using volumes)

Add helm repository first

helm repo add kubit-packs https://repo.sabz.dev/artifactory/kubit-packs

To install the chart with the release name my-release:

helm install -n my-namespace my-release kubit-packs/genpack -f my-values.yaml

The command deploys genpack on the Kubernetes cluster with given parameters. The Parameters section lists the parameters that can be configured during installation.

Tip: List all releases using helm list

To uninstall/delete the my-release deployment:

helm delete -n my-namespace my-release

The command removes all the Kubernetes components associated with the chart and deletes the release.

The following table lists the configurable parameters sections of the genpack chart. (Hint: the )

section: global.*

This object holds shared secrets and configs as well as shared certificate and repository related variables. for example:

global:
  commonImageRegistry: docker.sabz.dev
  commonImagePullSecrets:
    - name: docker-sabz-dev-registry
  sharedConfigs:
    POSTGRES_HOST: postgresql
    POSTGRES_PORT: 5432
    psk_conf: |
      TLSConnect=psk
      TLSAccept=psk
  sharedSecrets:
    POSTGRES_USER: user
    POSTGRES_PASSWORD: encrypted-password
  #...

The available parameters:

Section: gonbad.*

This is the main object. It contains values from which workloads and other manifests are created. It's most important sub-object is workloads. Workloads definition simplify creation and configuring most of used Kubernetes resources like Deployments, Services, ServiceMonitors and so on.

For example:

gonbad:
  workloads:
    server:
      kind: deployment
      replicaCount: 1
      service:
        type: NodePort
      containers:
        server:
          image:
            repository: zabbix/zabbix-server-pgsql
            tag: ubuntu-5.2.0
          ports:
            10051:
              name: server
              nodePort: 30051
            10052:
              enabled: false
              name: jmx

    web:
      kind: deployment
      replicaCount: 3
      containers:
        web:
          image:
            repository: zabbix/zabbix-web-nginx-pgsql
            tag: ubuntu-5.2.0
          ports:
            8080:
              name: http
            3040:
              name: metrics
              scrapePath: /metrics

      hostAliases:
        - ip: 1.2.3.4
          hostnames:
            - app1.local
            - app2.local

  ingresses:
    web:
      workloadName: web
      servicePort: http
      hosts:
        - host: zabbix.example.com
  #...

Section: gonbad.workloads.*

There are 5 types of workloads. a simple workload needs only an image and creates a simple single container deployment. On the other hand, a deployment workload, takes at least one container directive and can have as many as desired. A deployment workload, provides fine-tuning and high control over the specified workload. A statefulset, daemonset and cronjob workload are similar to deployment but with different kubernetes resources. To read more about them go to following sections

• Simple Workload
• Deployment Workload
• Statefulset Workload
• Daemonset Workload
• Cronjob Workload

To create simple workload, set gonbad.workload.<name>.kind to simple and so on. Each workload should have a name. A workload is an object which it's key is the workload's name.

gonbad:
  workloads:
    foo:
      kind: simple
      #...
    bar:
      kind: deployment
      #...
    rex:
      kind: statefulset
      #...
    jaz:
      kind: daemonset
      #...
    baz:
      kind: cronjob
      #...

A simple workload named foo looks like:

gonbad:
  workloads:
    foo:
      kind: simple
      #...

The following parameters are available for a simple workload.

A deployment workload name bar looks like:

gonbad:
  workloads:
    bar:
      kind: deployment
      #...

A deployment workload can have multiple containers.

The following parameters are available for a deployment workload.

A statefulset workload name bar looks like:

gonbad:
  workloads:
    rex:
      kind: statefulset
      #...
      volumeClaimTemplates:
        data-vol:
          size: 10Gi
        log-vol:
          size: 1Gi
    #...

A statefulset workload can have multiple containers.

The following parameters are available for a statefulset workload.

A daemonset workload name jaz looks like:

gonbad:
  workloads:
    jaz:
      kind: daemonset
      #...

A cronjob workload can have multiple containers.

The following parameters are available for a cronjob workload.

A cronjob workload name baz looks like:

gonbad:
  workloads:
    baz:
      kind: cronjob
      schedule: '0 */2 * * *'
      #...

A cronjob workload can have multiple containers.

The following parameters are available for a cronjob workload.

Section: gonbad.staticFiles

In order to mount single staticfiles (e.g., configuration files) inside containers, they need to be defined under gonbad.staticfiles. Then it's possible to reference the staticFiles from gonbad.workloads.containers.fileMounts.

Say one would want to define 2 static files named .zshrc and sshd.config. it would look like:

gonbad:
  #...
  staticFiles:
    .zshrc: |
      alias ll="ls -alh"
      alias g="git"
    sshd.config: |
      Port: 23412
  #...

This will create related configMaps and handles the integrity and naming uniformity.

section: gonbad.volumes

To create PVC and use them or mount Secrets/ConfigMaps into pods, they must first defined in the volumes section and then mount in containers using containers.volumeMounts. Different types of volumes are: persistentVolumeClaim, secret, configMap, emptyDir, ephemeral and existingPVC. The parameters of each will be described below.

The following parameters are available:

Section: gonbad.ingresses

In order to create ingress resources, one should define them under gonbad.ingresses. An ingress names ing looks like:

ingresses:
  web:
    workloadName: web
    servicePort: http
    hosts:
      - host: example.com
    annotations:
      annot: something
    tls:
      - secretName: example-com-tls
  media:
    #...
    hosts:
      paths:
        - /
            - /browse/
            - path: /serve/
            workloadName: media
            servicePort: http

Notes:

• workloadName only prepend the release name internally. It does not check if workload is exists/enabled and not useworkload.fullnameOverride
• In addition, global.ingress.annotations and global.ingress.tls can be configured. The two will be merged into all ingresses.

Section: gonbad.externalServices

To point to an external service, one should define them under gonbad.externalServices. The parameters are as follows. (take note that besides ports, one of externalIPs or `externalName are required)

Section: gonbad.prometheusRule

Section: gonbad.rawResources

Raw kubernetes resources to add beside other generated resources. This section is a list of raw resources with following parameters

The following objects, are not used directly. They are sub-types of the above objects.

section: deployment.strategy

Deployment strategy of a workload is used when the workload is reapplied or upgraded. A strategy is defined by:

section: workload.hpa

Create a HorizontalPodAutoscaler resource related to workload and configure it

sectionworkload.pdb

Create a PodDisruptionBudget resource related to workload and configure it

section: workload.securityContext

pod.securityContext holds pod-level security attributes and common container settings. Some fields are also present in container.securityContext. Field values of container.securityContext take precedence over field values of pod.securityContext.

Valid additional parameters: kubectl explain pod.spec.securityContext

section: container.image

section: workload.container.env

each env on workload.container can be a number, a string or an object described in below table to retrieve from other places like ConfigMap, note that only one of value, secretRef, configMapRef, resourceFieldRef and fieldRef can be set.

Envs are sorted as following groups, each group will sorted alphabetically:

1. all envs which have order by their order except order: -1
2. all unordered secretRef, configMapRef, resourceFieldRef and fieldRef envs
3. all simple or value envs which doesn't have $( in them
4. all simple or value envs which have $( in them
5. all order: -1 envs

Samples:

...:
  env:
    NUMBER: 123456
    SIMPLE: 'simple env value'

    SENTRY_DSN:
      configMapKeyRef:
        name: app-configmap
        key: sentry-dsn

    POSTGRESQL_PASSWORD:
      secretKeyRef:
        name: postgresql
        key: password

    POD_MEMORY_LIMIT:
      resourceFieldRef:
        resource: limits.memory

    POD_IP:
      fieldRef:
        fieldPath: status.podIP

    SIMPLE_ORDERED:
      value: foo
      order: 1

    POD_MEMORY_LIMIT_ORDERED:
      resourceFieldRef:
        resource: limits.memory
      order: 2

    COMPLEX:
      value: foo-$(SIMPLE_ORDERED)-$(POD_MEMORY_LIMIT_ORDERED)

    ANOTHER_COMPLEX:
      value: bar-$(POD_ID)
      order: -1 # -1 means last

section: container.envFrom

For each envFrom only one of secretRef and configMapRef can be set.

Samples:

...:
  envFrom:
    - secretRef:
        name: postgres-secret

    - configMapRef:
        name: deploy-configmap

    - configMapRef:
        name: django-configmap
      prefix: DJANGO_

section: container.startupProbe, container.livenessProbe, container.readinessProbe

Each container can have, liveness, readiness and startup probes. All these probes follow the same schema:

section: container.resources

A container can have requests and limits for CPU and Memory, if requests is set, the specified amount is reserved for the container. Having set the limits, if more CPU is used, the container will be throttled, while if the memory is overused, the container is killed, and the pod might get evicted.

section: container.ports

Mapping of ports and their configs for containers' ports as well as creating Service, ServiceMonitor, etc. resources as a single, centralized point of truth.

For each mapping, the key is the port number, optionally suffixed with tcp or udp, e.g. 8080, 1080/tcp, 16049/udp and the value can be null, string (port name) or an object with the following parameters:

section: container.lifecycle

Lifecycle describes actions that the management system should take in response to container lifecycle events. For the PostStart and PreStop lifecycle handlers, management of the container blocks until the action is complete, unless the container process fails, in which case the handler is aborted. For each lifecycle handlers only one of exec , httpGet or tcpSocket could be defined at once.

section: container.securityContext

SecurityContext holds security configuration that will be applied to a container. Some fields are present in both container.securityContext and pod.securityContext. When both are set, the values in container.securityContext take precedence.

Valid additional parameters: kubectl explain pod.spec.containers.securityContext

section: statefulset.volumeClaimTemplates

Creating a Persistent Volume Claim (PVC) per pod in SetatefulSets require configuring its volumeClaimTemplates. Each statefulset workload in gonbad could have volumeClaimTemplates. A mapping with volume names as its keys and object with following parameters as value.

Here some samples to demonstrate some aspects of this chart

#!/usr/bin/env -S helm template hello-world-sample genpack -f
gonbad:
  workloads:
    web:
      kind: deployment
      replicaCount: 1
      containers:
        web:
          image:
            registry: docker.io # optional, defaults to ''
            repository: tutum/hello-world
            tag: latest # optional, defaults to latest
          ports:
            80:
              name: http
              scrapePath: /metrics # optional, will create a ServiceMonitor object

  ingresses:
    web:
      workloadName: web
      servicePort: http
      hosts:
        - host: hello-world.example.dev

#!/usr/bin/env -S helm template volume-sample genpack -f
gonbad:
  workloads:
    web:
      kind: deployment
      replicaCount: 1
      containers:
        web:
          image:
            repository: nginx
          ports:
            80: http
          volumeMounts:
            - name: www-vol
              mountPath: /var/lib/nginx/sites/default/
            - name: existing-pvc-vol
              mountPath: /var/lib/nginx/sites/another/
            - name: config-vol
              mountPath: /etc/nginx/

  ingresses:
    web:
      workloadName: web
      servicePort: http
      hosts:
        - host: example.dev

  volumes:
    www-vol:
      type: persistentVolumeClaim
      size: 10Gi
      accessMode: ReadWriteOnce
      storageClass: zfs-hdd

    existing-pvc-vol:
      type: existingPVC
      name: pvc-fullname
      readOnly: false

    config-vol:
      type: configMap
      name: nginx-configs

#!/usr/bin/env -S helm template nodeport-sample genpack -f
gonbad:
  workloads:
    nginx:
      kind: deployment
      service:
        type: NodePort
      containers:
        nginx:
          image:
            repository: nginx
          ports:
            80:
              name: http
              nodePort: 30080
            443:
              name: https
              nodePort: 30443

    coredns:
      kind: deployment
      service:
        type: NodePort
      containers:
        coredns:
          image:
            repository: coredns
          ports:
            53/tcp:
              nodePort: 30053
            53/udp:
              nodePort: 30053

#!/usr/bin/env -S helm template external-service-sample genpack -f
gonbad:
  externalServices:
    kuma:
      externalIPs:
        - 1.2.3.4
      ports:
        443:
          enabled: true
          name: https
          scrapePath: /metrics

last update: 2023-02-14