Hosted by

avatar

Viktor Farcic

Viktor Farcic is an Open-Source Program Manager & Developer Advocate at Shipa, a member of the Google Developer Experts and Docker Captains groups, and a published author.

Using Helm As A Package Manager For Kubernetes

A Workshop on using Helm As A Package Manager For Kubernetes

July 22nd, 10am - 11.30am PST

Online

Price $49

Event information

Every operating system has at least one packaging mechanism. Some Linux distributions use RPM or APT. Windows uses Chocolatey, and macOS uses Brew. Those are all package mechanisms for operating systems. But why does that matter in the context of Kubernetes?

You might say that Kubernetes is a scheduler, while Windows, Linux, and macOS are operating systems. You would be right in thinking so, but that would be only partly true. We can think of Kubernetes as an operating system for clusters, while Linux, Windows, and macOS are operating systems of individual machines. The scheduler is only one of the many features of Kubernetes and saying that it is an operating system for a cluster would be a more precise way to define it. It serves a similar purpose as, let's say, Linux, except that it operates over a group of servers. As such, it needs a packaging mechanism designed to leverage its *modus operandi*.

While there are quite a few tools we can use to package, install, and manage applications in Kubernetes, none is as widely used as Helm. It is the de facto standard in the Kubernetes ecosystem.

Helm uses "charts" to help us define, install, upgrade, and manage apps and all the surrounding resources. It simplifies versioning, publishing, and sharing of applications. It was donated to the [Cloud Native Computing Foundation (CNCF)]( https://www.cncf.io/), thus landing in the same place as most other projects that matter in the Kubernetes ecosystem.

Helm is mighty, yet simple to use. If we'd need to explain Helm in a single sentence, we could say that it is a templating and packaging mechanism for Kubernetes resources. But it is much more than that, even though those are the primary objectives of the project.


Key objectives

  • Defining A Scenario
  • Preparing For The Exercises
  • Creating Helm Charts
  • Adding Application Dependencies
  • Deploying Applications To Production
  • Deploying Applications To Development And Preview Environments
  • Deploying Applications To Permanent Non-Production Environments
  • Packaging And Deploying Releases
  • Rolling Back Releases
  • Destroying The Resources
  • QA

Join the Growing Network of Experts & Mentors
Sign up