Unlock the Power of Helm Summit 2018 with Tamal Saha

Table of Contents

1. Introduction
2. Background
   • History of Using Home
   • Initial Challenges
   • Exploring Authentication and Authorization
3. Using Helm as a Package Consumer
   • Advantages of Helm for Trying Out Applications
   • Challenges of Using Helm for Internal Applications
   • Building Charts and Managing Workflows
   • Issues with Multiple Sources of Truth and Rollbacks
4. Publishing Charts with Helm
   • Challenges Faced by Chart Publishers
   • Versioning Issues and Chart Review Process
   • Dealing with the Stable Chart Repository
5. Simplifying Application Development with a New Approach
   • The Idea of Developing Applications with Ease
   • Leveraging Existing Tools like Glide and Dep
   • Introducing a Hypothetical Tool - Pack
   • Benefits of the Proposed Approach
6. Implementing Secure and Traceable Deployments
   • Simplified Deployment with Pack and Kubernetes
   • Leveraging Kubernetes Advanced Auditing
   • Ensuring Security and Accountability
7. Disaster Recovery and Git Integration
   • Creating a Cluster State Git Repository
   • Recreating the Cluster from the Git Repo
8. Conclusion
9. Additional Resources

Experience with Using Helm and its Challenges

Helm is a widely-used package manager for Kubernetes deployments that simplifies the installation and management of applications. In this article, I will share my experience using Helm and discuss the challenges I encountered. From the perspective of a package consumer, I will explore the advantages of using Helm for trying out applications and the challenges of using it for internal applications. Additionally, I will Delve into the issues faced by chart publishers and propose a simpler approach to application development. Finally, I will discuss the implementation of secure and traceable deployments, as well as the integration of Helm with Git for disaster recovery.

Introduction

Helm, a package manager for Kubernetes deployments, has gained popularity for its ability to simplify the installation and management of applications. As a user of Helm, I have experienced both the advantages it offers and the challenges it presents. In this article, I will share my insights and delve into the complexities of using Helm for both package consumers and chart publishers.

Background

History of Using Helm

I was first introduced to Helm when I was working on a Kubernetes cluster and needed a way to track deployments. After some research, I discovered Helm and its capabilities. However, I soon realized that it lacked essential features, such as RBAC and authentication. This led me to collaborate with the Helm community to address these limitations.

Initial Challenges

One of the initial challenges I faced was the absence of RBAC and authentication in Helm. To overcome this, we explored the possibility of introducing third-party objects or TPRs to add RBAC capabilities. However, after consulting with experts, we realized that this approach wouldn't fulfill our authorization requirements.

Exploring Authentication and Authorization

Upon discovering the limitations of the controller approach, we started investigating the integration of authentication and authorization directly into Helm. This involved extensive discussions and design considerations. Although progress was made, the issue regarding authentication and authorization in Helm remains unresolved.

Using Helm as a Package Consumer

Helm serves as an excellent tool for package consumers who want to try out applications. Its ease of use allows users to quickly install applications on a new cluster with a simple helm install command. However, when it comes to internal applications, using Helm presents a different set of challenges.

Advantages of Helm for Trying Out Applications

For package consumers, Helm provides a convenient way to evaluate and try out new applications. With a few simple steps, users can have a fully-functional application running on their cluster. This streamlined process saves time and effort, especially for testing and experimentation purposes.

Challenges of Using Helm for Internal Applications

While Helm is effective for trying out applications, using it for internal applications poses certain challenges. Additional steps need to be taken, such as creating values files and learning a new set of Helm-specific concepts. Furthermore, organizing a developer workflow around Helm, including chart building and version control, can be complex and time-consuming.

Building Charts and Managing Workflows

Developing complex applications with Helm requires mastering the creation of charts and managing workflows. While Helm offers the capability to package applications, ensuring the coherence and correctness of the charts requires Attention to Detail. Helm's chart repository adds another layer of complexity, making it necessary to integrate it with existing Git repositories to have a single source of truth.

Issues with Multiple Sources of Truth and Rollbacks

The presence of multiple sources of truth, such as Git repositories and Helm releases, introduces challenges in maintaining a clear and consistent view of the application's state. Knowing which version of a chart to use can be confusing, particularly when chart versions differ from the application's actual version. Additionally, the stable chart repository can be slow and unpredictable, resulting in delays and confusion during the review process.

Publishing Charts with Helm

As a chart publisher, I have encountered specific challenges when it comes to using Helm to distribute charts. The discrepancy between chart versions and the lengthy review process are just some of the issues I have faced.

Challenges Faced by Chart Publishers

One of the significant challenges faced by chart publishers is ensuring that the chart version aligns with the actual application version. In cases where the chart version and application version differ, confusion can arise for users trying to deploy the chart. This inconsistency undermines the Clarity and trustworthiness of the chart repository.

Versioning Issues and Chart Review Process

The chart review process can be slow and unpredictable, leading to frustration for chart publishers. It is not uncommon for publishers to push updates to the stable chart repository, only to wait for an indefinite period for the updated chart to be available. This lack of control over the review process can cause delays and impact the timeliness of deployments.

Dealing with the Stable Chart Repository

Chart publishers often struggle to adapt their charts to the frequently changing style guide of the stable chart repository. In particular, the constant alterations to the chunk addition length Create additional work and demand careful attention to detail. These ongoing changes can disrupt the publishing process and make it hard to maintain compatibility with the stable repository.