Wednesday, July 22, 2020

Helm Chart for Contour: A Chart Contributed by the Bitnami Community

Bitnami has recently released the Helm chart for Contour, an Ingress Controller for Kubernetes. Contour arrives to complete the list of Ingress Controllers available in the Bitnami Helm chart catalog: Nginx Ingress Controller, Kong, and now Contour. 

This chart is a great example of how Bitnami users are contributing to our catalog. Our users are not only sending us Pull Requests and reporting issues, but they are also creating new charts that help extend the Bitnami catalog. 

In this specific case, a user sent a Pull Request containing a proposal for the Contour Helm chart. The Bitnami content team checked it and gave him the support he needed to adapt the chart and make it ready for release. We are very proud of how our community is providing feedback and making our commitment of “creating awesome open source software available for everyone” possible. 

Built following the Bitnami best practices for Helm charts, the Contour Helm chart uses not-root containers and ships the latest versions of its components and dependencies. Continuously maintained by the Bitnami team, this chart is secure and ready to run in production environments.

Keep reading to learn more about the Bitnami Contour Helm chart’s special features and how easy it is to deploy it in your Kubernetes cluster. 

Why use Contour as an Ingress Controller for your Kubernetes cluster? 

As with any other Ingress Controller, Contour lets you control how external users access services in your Kubernetes cluster. It is ideal for organizations with multiple development teams that are using a single cluster concurrently since it helps secure traffic and protect environments when there are changes in Ingress resources. 

One of the most prominent advantages of using Contour is that it is based on Envoy, a powerful open source proxy designed specifically for cloud-native applications.  

Contour offers the following benefits for both cluster administrators and developers: 

Cluster admins can trust Contour as a safe way to connect applications from outside the cluster, helping them to manage TLS secrets and DNS.  

Contour operates Ingress Resources via Custom Resource Definitions (CRDs). This allows developers to interact with Contour by creating Kubernetes objects types that Contour can understand, skipping the need to interact directly with it. 

Apart from these advantages, Contour provides the following features: 

  • It is designed for deploying cloud-native applications using the flexible HTTPProxy API. 
  • It allows dynamic Envoy reconfiguration. When Ingress and underlying components change, the load balancer doesn’t need to be restarted.  
  • It supports TLS Certificate delegation. 
  • It supports Balancing algorithms such as mirroring, auto repetition, and limiting rate of requests.  
  • It enables detailed monitoring of traffic flow and failures. 

Deploy Contour in your Kubernetes cluster using Bitnami Helm charts 

Deploying Contour in your cluster is easy using the Bitnami Helm chart. You can deploy it on any platform without any other dependencies needed. If you are using Minikube, make sure that you do not have the Nginx Ingress Controller already running before installing. 

To deploy the chart, first add the Bitnami repository to your cluster. Then, simply execute the helm install command followed by a name for your release and the name of the Contour chart: 

$ helm repo add bitnami 

$ helm install my-release bitnami/contour 

These commands will bootstrap a Contour Ingress Controller deployment and an Envoy Proxy Daemonset on your Kubernetes cluster. 

To check the status of the services, execute the kubectl get svc command as shown below. You should see the two services that the chart deploys with their corresponding internal and external IP addresses. 

Now, you will be able to deploy an application in your cluster by enabling Ingress at deployment time. This example shows how to deploy WordPress using the Bitnami Helm chart, but you can choose any other solution from the Bitnami Helm charts catalog or through Kubeapps. 

$ helm install wp  bitnami/wordpress --set ingress.enabled=true 

This will deploy an Ingress rule, which you can check by running kubectl get ingress: 

Note that this deployment uses the same IP address as Contour. Now, you will be able to view your application using the domain name (in this example, the default wordpress.local) or the IP address: 

Do you want to learn more about the Bitnami Contour Helm chart? Check its README file for a complete list of deployment parameters and then give it a try by installing the chart directly in your cluster or through the Kubeapps catalog!  

Wednesday, May 13, 2020

Kubeapps Now Supports Private Helm and Docker Registries

The Kubeapps team has released a new version that provides support for private Helm repositories with private Docker images. This is the second release in a month, since last April, Kubeapps also extended its catalog with support for operators. 

From now on, Kubeapps users can include private Docker images in their customized Helm charts and deploy them directly from a private Helm repository.  This support is aligned with the Kubernetes RBAC authentication model with private credentials available only in the configured namespace. Users can only add private repositories in those namespaces in which they have the required permissions.  Similarly, only those users with access to that namespace have access to deploy the charts with private images.

Kubeapps officially supports the following private Helm repositories:

Chose the option that better suits your team and start deploying custom applications from your private repositories from the Kubeapps user interface.

Kubeapps simplifies the deployment from private registries within the Kubernetes security model 

To enable the full support for private repositories, Kubeapps introduced the option of associating Docker credentials to an application repository so that Kubeapps can ensure they are used to pull any matching private images within a chart.

This eliminates the manual configuration you would otherwise need to be able to deploy charts with private Docker images, without which Kubernetes is unable to find Docker images requiring credentials, resulting in a failed deployment.

Without this feature, the user has two options: either create manually an image pull secret in the Kubernetes namespace or ask the cluster operator to make the secret available, and then update the chart values to reference the created secret.

Both situations require that you or the people that will use the application know how to manually add the specific pull secret and reference it in the chart values at deployment time.

Here is where Kubeapps simplify things! How? By associating Docker image pull secrets to an application repository (only available for Helm 3).

From the Kubeapps user interface, create an application repository and after entering the normal URL of the private repository where the app is and basic authentication of the chart:

  • Create the credentials for the image pull secret so that Kubernetes can pull the images from the Docker registry.  
  • Then ensure the newly created image pull secret is selected for the application repository.  

This information tells Kubeapps that whenever deploying any chart from this application repository, if an image matching any associated pull secret is referenced in any pod, then Kubeapps will automatically add an image pull secret to that pod.

Watch the following video to learn step-by-step how to create an application repository to deploy a custom application from external private repositories:

Or check out the documentation for private application repositories to learn more.

Deploy the latest Kubeapps release now!

Wednesday, April 8, 2020

Kubeapps Extends its Catalog with Support for Operators

Over the last few weeks, the Bitnami team has worked on including a major change in the new Kubeapps version (available in alpha): support for Operators. With this, the Kubeapps catalog increases by more than 110 applications.

Operators extend Kubernetes capabilities, including those related to stateful applications. Operators may handle updates, failure recovery, application scale-out, etc., reducing the number of manual operations that are required for applications to run on a cluster. They contain the logic for deploying and operating an application on Kubernetes, handling almost all aspects of application management. Operators can also help with many so-called "day-2 operations", automating manual tasks like upgrades or backups.

Now, cluster administrators and developers will be able to deploy Operators directly from Kubeapps. Kubeapps users will be able to deploy instances directly from the UI to better manage applications and their components using custom resources.

Keep reading to learn how to use this new feature and to discover other enhancements in this new version of Kubeapps.

Why extend the Kubeapps catalog with Operators? 

Helm charts are a great way for deploying applications on Kubernetes. They package pre-configured Kubernetes resources and contain manifest files which describe how the application should be managed.

While Helm charts allow you to easily run an application on a cluster, once the application is deployed, you may still need to perform additional tasks to connect your application with external resources such a database or manual operations to scale a deployment.

Bitnami has added Operators to Kubeapps to give cluster administrators and developers the resources to automate the application lifecycle in their clusters. For example, when a security update is available for your application, you can now expect it to be automatically applied with no human intervention. This is especially useful for SRE teams that need to manage many clusters.

Now that the Kubeapps catalog includes both Helm charts and Operators (some applications are only available as Operators), administrators can mix and match Helm charts and Operators to create more complex / production-ready solutions.

Kubeapps is the first open source tool that allows you to manage charts, Operators, and instances through a single user-friendly interface.

Enable Operators Support and Start Deploying Operators on Your Cluster 

Support for Operators is being released as a feature in alpha state and it is not enabled by default. For that reason, users must manually enable it by adding the related flag at deployment time or when upgrading Kubeapps. 

When you finish the process, your Kubeapps “Catalog”  will add Operators to the catalog, and you can start using them from a web browser. Navigate to the “Configuration -> Operators” menu, and see the full list of Operators available and ready to be deployed on your cluster:

Click the Operator you wish to deploy, check the information displayed, click “Deploy” and follow the instructions to finish the installation. Check out the Kubeapps GitHub repository to learn how to get started with Operators.

Want to try Operators in Kubeapps?  Download the latest version and start using them!