Wednesday, November 13, 2019

Helm 3 Arrives to Boost the Way to Deploy Applications on Kubernetes

Three years have passed since the first release of Helm and it has undoubtedly become the de-facto way of deploying applications in Kubernetes. Maybe this is because of its simplicity and ease of use, or maybe because of the ability to manage upgrades and rollbacks with ease. No matter the reason, the Helm community has been steadily gaining momentum, and it has become the preferred way development teams deploy applications to Kubernetes.

Helm 3 is good evidence the community is continuing to advance and mature. Its new features and improvements make Helm charts even easier to manage, and offers the most secure way to move applications to production. Keep reading to discover more about the improvements this new version brings with it.

Say goodbye to Tiller

Helm is comprised of two parts: Helm (the client) and Tiller (the server). In previous versions, when you initialized Helm running “helm init”, Tiller was installed automatically. 

Tiller had an important role in clusters that were shared across different teams since it allowed the possibility of having multiple operators interacting with the same set of releases at the same time.

When role-based access controls (RBAC rules) came into action with the release of Kubernetes v.1.6, the use of Tiller in a production scenario became more difficult due to the multiple security policies that you can set for your cluster. Take a look at the numerous pre-configurations you should do in order to install and configure Helm and Tiller to realize how RBAC rules complicated the management in a multi-tenant cluster.

After seeing how users were using Helm in certain scenarios the Helm team decided to remove Tiller in the latest release. They found that fetching the information from the Kubernetes API server, rendering the charts client-side, and storing the record of the installation in Kubernetes was the best way to collect Helm release information (instead of using Tiller as a central hub). 

Now that Tiller has been removed, Helm’s security relies on your kubeconfig file where cluster administrators define user’s roles and permissions.

Open Container Initiative: Removing Chart Repository Limitations for Production Environments 

Helm 3 also provides new ways of managing chart repositories. For a long time, Docker Registry has been the de-facto toolset to store and deliver Docker images. Many cloud vendors also offered different versions of the Docker Registry that implemented security features to try and mitigate some of the more common chart repository limitations:

Chart repositories usually take a long time to abstract the security implementations needed for a production environment.

Not every chart repository includes tools for signing and verifying the origin and integrity of a chart.

Using a unique index file for metadata information makes searching and fetching charts hard, and makes it more difficult to manage security in multi-tenant scenarios.

Although it is still experimental, the Open Container Initiative may solve these limitations by adding login support and other features that will be essential for managing charts with Helm 3.

Try Bitnami charts with Helm 3

The Bitnami catalog has already been tested and validated to work with Helm 2 and Helm 3 across the major Kubernetes platforms.

Bitnami runs daily tests on its entire application catalog to make sure that all solutions can be deployed successfully without issues in any platform.

As one of the largest maintainers of Helm charts (currently 60), we have focused our efforts on delivering maintained, secure, and production-ready charts.

Why don’t give it a try? Install Helm 3 in your cluster now and select any of Bitnami charts from our GitHub repository to test its new features!

For more information about Helm 3 new features and changes, read the official announcement or refer to Helm FAQ. 

Friday, October 25, 2019

Kubeapps v1.6.0 is out!

Authored by Andrés Martínez, Member of Technical Staff

Over the past few months, the Bitnami team has been working on adding features to Kubeapps such as the ability to rollback releases and to customize private Helm registriesThis new release adds to these improvements with support for two major new featuresForms to deploy and upgrade applications and OIDC support with OAuth2_proxy.  

Keep reading to discover these new features and how to start using them. 

Simple Forms to Deploy and Upgrade Applications 

Iis now possible to change the default chart configuration for new deployments easily. This feature is already active for the stable versions of WordPress, PostgreSQL, and Apache, and there are more to come! 

By clicking the Deploy button for those charts, a new form is displayed. This form allows you to change common parameters, such as the username or password, without the hassle of knowing how the values.yaml file of the chart is structured. 

With this new feature, iteven easier to adopt Kubernetes applications that are ready for production. Watch the following video to learn how to deploy WordPress after modifying the default values:

How can you add this form to your chart? 

With Helm v3you can include a JSON Schema along with your chart. This file is named values.schema.json and it allows you to describe the content of the values.yaml file. The goal of this new file is to verify that the chart values satisfy the expected structure, but Kubeapps also uses it to render the form mentioned in the section above. With some special annotations, you can specify which parameters should be presentso Kubeapps can render it. To learn more about this feature, check the Kubeapps developer documentation. 

OIDC Support with OAuth2_proxy 

Some time ago, we started to support OpenID Connect (OIDC) as an alternative to the default login experience in Kubeapps. If you enable it, you can login in to Kubeapps with an email account using the identity provider of your choice, such as Google or GitHub:  

By installing Kubeapps v1.6.0you can now configure OIDC to work with more managed platforms for Kubernetes, like GKE, thanks to oauth2_proxy But remember, iyou were using OIDC in previous versions of Kubeappsyou will need to change some of the chart parameters to enable this featureCheck out these instructions to learn how! 

We would like to hear about your experience with the new version of Kubeapps. You can reach out to the Kubeapps team both through our GitHub page and through the #kubeapps channel in Slack. 

Happy Helming!