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 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.
Table of content
How to get Kubedeploy 1.1
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
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:
image: 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 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
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 image: repository: busybox tag: latest cronjobspec: 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 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
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 image: repository: nginx tag: latest envFrom: #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 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
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 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"
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:
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.
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.