Announcing Kubedeploy 1.1

Kubedeploy 1.1 for more flexible application deployment in Kubernetes clusters.

Announcing Kubedeploy 1.1

Kubedeploy is the bridge that brings simplicity and flexibility together in the Kubernetes deployment journey. Whether you’re a beginner looking for an easy start or an advanced user seeking precision and control, Kubedeploy empowers you to navigate the complexities of Kubernetes deployment with ease.

Kubedeploy 1.1 is now generally available.

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, 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.

Table of content

How to get Kubedeploy 1.1

For new users:

helm repo add 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

What's new?

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.

Easy anti-affinity rules

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:

  repository: nginx
  tag: latest

replicaCount: 3

podAntiAffinity: "soft"

Additional containers in Pod

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
  repository: nginx
  tag: latest

  - containerPort: 80
    name: http
    protocol: TCP

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

Added support for CronJobs

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
  repository: busybox
  tag: latest

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

Added support for deploying extra Secrets objects

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
  repository: nginx
  tag: latest

  - 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
      key: value # value will be automatically base64 encoded by chart template

Environment variables from Secrets or ConfigMaps

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
  repository: nginx
  tag: latest

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

Extra volumes support

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 existingClaimshostPathcsisecretName, and emptyDir volumes for containers running in a Pod:

nameOverride: my-app
  repository: nginx
  tag: latest

  - 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
      readOnly: true
        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

Allow adding any Kubernetes object manifest

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
  repository: nginx
  tag: 1.25.2

  - apiVersion:
    kind: SecretProviderClass
      name: aws-secrets-manager-secrets
      provider: aws
        objects: |
          - objectName: "name-of-aws-secret"
            objectType: "secretsmanager"
                - path: db_username
                  objectAlias: db_username
                - path: db_password
                  objectAlias: db_password
                - path: db_hostname
                  objectAlias: db_hostname
                - path: database
                  objectAlias: database

  - name: external-secrets
    readOnly: true
    mountPath: /etc/aws-secrets
      readOnly: true
        secretProviderClass: "aws-secretes-manager-secrets"

Other honorable mentions

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:

  enabled: true
    - host: ""

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:

  enabled: true
    - host: ""
        - path: /
          svcPort: 9000 # set explicitly (first port is default anyway)
        - path: /api
          svcPort: 80 # target backend port for /api urls
    - hosts:
      # 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.

What lies ahead?

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.

Share this post