Announcing Kubedeploy 1.1

Kubedeploy release 1.1, together with 1.0, brings support for several new configuration options, bug fixes, and existing feature improvements, allowing you more flexible application deployment in Kubernetes clusters.

The chart now also features a dedicated chart documentation page available at https://kubedeploy.app/, offering a Quick start guide, detailed insight into every configuration parameter, and a number of example application deployments to inspire you on what is possible with Kubedeploy. The chart’s source and documentation are now publicly available at our GitHub repository SysbeeTech/kubedeploy.

From version 1.0, Kubedeploy guarantees no breaking changes in chart configuration between major versions while it also strives to simplify existing configuration values and deployment scenarios.

For new users:

helm repo add sysbee https://charts.sysbee.io/stable/sysbee
helm repo update

You are also encouraged to check out Kubedeploy Quickstart and Examples pages to get you started.

If you already have Sysbee Helm chart repository configured, simply update the repo and start using new version:

helm repo update sysbee

Under the hood, unit tests are added for each configuration option, which will help in further development and no-braking changes promise. On top of that, deployment tests are added for the latest Kubernetes version, with plans to expand them to all upstream-supported Kubernetes versions.

Chart values documentation is now available on the Values Reference page. For users just starting with Helm and Kubernetes and experienced users looking for more insights into chart internals, values documentation is also available on the Examples by Values page.

A new configuration value allows for easier Pod anti-affinity rules configuration. Previously, users would need to define raw affinity rules under chart values. It is now possible to use podAntiAffinity value that will create an automatic anti-affinity rule for your application:

image:
  repository: nginx
  tag: latest

replicaCount: 3

podAntiAffinity: "soft"

Previously, the chart supported only init containers users could use to prepare the application for runtime. From version 1.0, defining multiple running containers via additionalContainers value is now possible. This configuration value enables the deployment of applications that require frontend-backend relations or scenarios where the application needs sidecar containers for exposing metrics.

Each additional container can have its own exposed ports, health checks, and resource requirement definition:

nameOverride: my-app
image:
  repository: nginx
  tag: latest

ports:
  - containerPort: 80
    name: http
    protocol: TCP

additionalContainers:
  enabled: true
  resources:
    requests:
      cpu: 0.1
      memory: 128Mi
    limits:
      cpu: 0.2
      memory: 256Mi
  containers:
    - name: metrics-exporter
      repository: nginx/nginx-prometheus-exporter
      tag: latest
      args:
        - -nginx.scrape-uri=http://localhost:80/stub_status
      ports:
        - containerPort: 9113
          name: metrics
          protocol: TCP

Kubedeploy now allows for specifying Cronjob deploymentMode, which can be further fine-tuned by configuring cronjobspec values. These configuration values will enable users to run scheduled tasks from your application container easily:

nameOverride: my-cronjob
deploymentMode: Cronjob
image:
  repository: busybox
  tag: latest

cronjobspec:
  schedule: "*/10 * * * *"
  command: ["sh", "-c", "echo 'hello from cronjob'" ]

It is now possible to define extraSecrets value, which will deploy additional Secret objects alongside your application release. Similar to the configMaps value introduced in 0.8.0, extra secrets can be optionally automatically mounted as files in containers by defining the mount point in the extraSecrets value:

nameOverride: my-app
image:
  repository: nginx
  tag: latest

extraSecrets:
  - name: opaque-secret
    type: Opaque # (optional) - Default: Opaque if unspecified
    mount: True # (optional) - should this sercret be mounted as volume in containers
    mountPath: /mnt/secret-vol0 # (required if mount=True) - define mount path for this secret
    data:
      key: value # value will be automatically base64 encoded by chart template

If you needed to define environment variables from Secrets or ConfigMaps, in the previous Kubedeploy version, it was only possible by defining valueFrom for each variable under env values. From version 1.1, you can use simplified envFrom to expose all Secrets or ConfigMaps keys as container environment variables.

nameOverride: my-app
image:
  repository: nginx
  tag: latest

envFrom:
  #env from ConfigMap
  - configMapRef:
      name: special-config
  # env from Secret
  - secretRef:
      name: test-secret

As of version 1.0, it is no longer possible to define PVC via persistency value for deploymentMode other than Statefulset. However, the chart can now define extraVolumeMounts that can support previous versions’ behavior, among other things.

extraVolumeMounts will allow you to define existingClaims, hostPath, csi, secretName, and emptyDir volumes for containers running in a Pod:

nameOverride: my-app
image:
  repository: nginx
  tag: latest

extraVolumeMounts:
  - name: extra-volume-0
    mountPath: /mnt/volume0
    readOnly: true
    existingClaim: volume-claim

  - name: extra-volume-1
    mountPath: /mnt/volume1
    readOnly: true
    hostPath: /usr/shared/

  - name: external-secrets
    mountPath: /mnt/volume2
    csi: true
    data:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAttributes:
        secretProviderClass: "secret-provider-name"

  - name: empty-dir-vol
    mountPath: /mnt/volume3

  - name: secret-mount
    mountPath: /mnt/volume4
    secretName: my-secret
    optional: true  # If set to true, kubernetes will ignore this mount if secret is not available

If Kubedeploy does not have required object support, or if you want to take matters into your own hands, you can now define any raw Kubernetes object via extraObjects value configuration.

nameOverride: my-app
image:
  repository: nginx
  tag: 1.25.2

extraObjects:
  - apiVersion: secrets-store.csi.x-k8s.io/v1
    kind: SecretProviderClass
    metadata:
      name: aws-secrets-manager-secrets
    spec:
      provider: aws
      parameters:
        objects: |
          - objectName: "name-of-aws-secret"
            objectType: "secretsmanager"
            jmesPath:
                - path: db_username
                  objectAlias: db_username
                - path: db_password
                  objectAlias: db_password
                - path: db_hostname
                  objectAlias: db_hostname
                - path: database
                  objectAlias: database

extraVolumeMounts:
  - name: external-secrets
    readOnly: true
    mountPath: /etc/aws-secrets
    csi:
      driver: secrets-store.csi.k8s.io
      readOnly: true
      volumeAtributes:
        secretProviderClass: "aws-secretes-manager-secrets"

Except for the features mentioned above, some bugs were fixed in the past two versions, and some of the older features were reworked to make them simpler and more flexible.

For example, ingres value configuration is now simpler to get started. Minimal configuration requires only a few lines:

ingress:
  enabled: true
  hosts:
    - host: "my-domain.com"

At the same time, it also offers flexibility to define different backend ports for paths in scenarios where multiple containers are running in a Pod. Additionally, custom SSL certificates are supported by referencing existing secret names:

ingress:
  enabled: true
  hosts:
    - host: "my-domain.com"
      paths:
        - path: /
          svcPort: 9000 # set explicitly (first port is default anyway)
        - path: /api
          svcPort: 80 # target backend port for /api urls
  tls:
    - hosts:
        - my-domain.com
      # use secret provisioned with extraSecrets
      # remember: name is prefixed with fullname
      secretName: webap-my-app-my-domain-ssl

configMaps value now allows for automatic mounting as files in the pods, as well as defining configMapsHash for easier Pod rolling update on ConfigMaps content change.

A complete list of changes for past versions can be found in the Changelog.

Kubedeploy’s primary goal will always be making the deployment as simple as possible while retaining the flexibility that advanced users require.

A few new features are already planned for 1.2, with more to come. Check out the milestones page on GitHub, and feel free to propose any new feature you would like to see. If you like Kubedeploy, consider staring the project or becoming a contributor. Every little contribution helps. Contributing documentation updates, sharing your example application deployments, adding new features, or reporting bugs you encountered while using the chart.

Check out our other blog post about Kubernetes, or contact us if you need additional information about this topic.