🛡️
CTHFM: Kubernetes
  • Welcome
  • Kubernetes Fundamentals
    • Kubernetes Components
      • Kubernetes Master Node
      • Worker Nodes
      • Pods
      • Service
      • ConfigMaps and Secrets
      • Namespaces
      • Deployments
      • ReplicaSets
      • Jobs and CronJobs
      • Horizontal Pod Autoscaler (HPA)
      • Kubernetes Ports and Protocols
    • Kubectl
      • Installation and Setup
      • Basic Kubectl
      • Working With Pods
      • Deployments and ReplicaSets
      • Services and Networking
      • ConfigMaps and Secrets
      • YAML Manifest Management
      • Debugging and Troubleshooting
      • Kubectl Scripting: Security
      • Customizing Kubectl
      • Security Best Practices
      • Common Issues
      • Reading YAML Files
    • MiniKube
      • Intro
      • Prerequisites
      • Installation MiniKube
      • Starting MiniKube
      • Deploy a Sample Application
      • Managing Kubernetes Resources
      • Configuring MiniKube
      • Persistent Storage in Minikube
      • Using Minikube for Local Development
      • Common Pitfalls
      • Best Practices
  • Kubernetes Logging
    • Kubernetes Logging Overview
    • Audit Logs
    • Node Logs
    • Pod Logs
    • Application Logs
    • Importance of Logging
    • Types of Logs
    • Collecting and Aggregating Logs
    • Monitoring and Alerting
    • Log Parsing and Enrichment
    • Security Considerations in Logging
    • Best Practices
    • Kubernetes Logging Architecture
  • Threat Hunting
    • Threat Hunting Introduction
    • What Makes Kubernetes Threat Hunting Unique
    • Threat Hunting Process
      • Hypothesis Generation
      • Investigation
      • Identification
      • Resolution & Follow Up
    • Pyramid of Pain
    • Threat Frameworks
      • MITRE Containers Matrix
        • MITRE Att&ck Concepts
        • MITRE Att&ck Data Sources
        • MITRE ATT&CK Mitigations
        • MITRE Att&ck Containers Matrix
      • Microsoft Threat for Kubernetes
    • Kubernetes Behavioral Analysis and Anomaly Detection
    • Threat Hunting Ideas
    • Threat Hunting Labs
  • Security Tools
    • Falco
      • Falco Overview
      • Falco's Architecture
      • Runtime Security Explained
      • Installation and Setup
      • Falco Rules
      • Tuning Falco Rules
      • Integrating Falco with Kubernetes
      • Detecting Common Threats with Falco
      • Integrating Falco with Other Security Tools
      • Automating Incident Response with Falco
      • Managing Falco Performance and Scalability
      • Updating and Maintaining Falco
      • Real-World Case Studies and Lessons Learned
      • Labs
        • Deploying Falco on a Kubernetes Cluster
        • Writing and Testing Custom Falco Rules
        • Integrating Falco with a SIEM System
        • Automating Responses to Falco Alerts
    • Open Policy Agent (OPA)
      • Introduction to Open Policy Agent (OPA)
      • Getting Started with OPA
      • Rego
      • Advanced Rego Concepts
      • Integrating OPA with Kubernetes
      • OPA Gatekeeper
      • Policy Enforcement in Microservices
      • OPA API Gateways
      • Introduction to CI/CD Pipelines and Policy Enforcement
      • External Data in OPA
      • Introduction to Decision Logging
      • OPA Performance Monitoring
      • OPA Implementation Best Practices
      • OPA Case Studies
      • OPA Ecosystem
    • Kube-Bench
    • Kube-Hunter
    • Trivy
    • Security Best Practices and Documentation
      • RBAC Good Practices
      • Official CVE Feed
      • Kubernetes Security Checklist
      • Securing a Cluster
      • OWASP
  • Open Source Tools
    • Cloud Native Computing Foundation (CNCF)
      • Security Projects
  • Infrastructure as Code
    • Kubernetes and Terraform
      • Key Focus Areas for Threat Hunters
      • Infastructure As Code: Kubernetes
      • Infrastructure as Code (IaC) Basics
      • Infastructure As Code Essential Commands
      • Terraform for Container Orchestration
      • Network and Load Balancing
      • Secrets Management
      • State Management
      • CI/CD
      • Security Considerations
      • Monitoring and Logging
      • Scaling and High Availability
      • Backup and Disaster Recovery
    • Helm
      • What is Helm?
      • Helm Architecture
      • Write Helm Charts
      • Using Helm Charts
      • Customizing Helm Charts
      • Customizing Helm Charts
      • Building Your Own Helm Chart
      • Advanced Helm Chart Customization
      • Helm Repositories
      • Helm Best Practices
      • Helmfile and Continuous Integration
      • Managing Secrets with Helm and Helm Secrets
      • Troubleshooting and Debugging Helm
      • Production Deployments
      • Helm Case Studies
Powered by GitBook
On this page
  1. Infrastructure as Code
  2. Helm

Helm Architecture

In this lesson, we will explore the architecture of Helm, focusing on its core components and how they work together to manage Kubernetes applications. Understanding Helm's architecture is crucial for effectively using Helm to deploy, upgrade, and manage applications within Kubernetes clusters.

Key Components of Helm

Helm’s architecture revolves around a few key components that work together to simplify the management of Kubernetes applications:

  1. Helm CLI (Command-Line Interface)

  2. Helm Charts

  3. Helm Repositories

  4. Helm Releases

1.2.1.1 Helm CLI (Command-Line Interface)

The Helm CLI is the primary tool that users interact with when managing applications in Kubernetes. It is used to install, upgrade, delete, and manage Helm charts and releases. The CLI communicates with the Kubernetes API to apply the necessary changes to the cluster.

Key Functions of Helm CLI:

  • helm install: Deploys a chart as a new release.

  • helm upgrade: Upgrades an existing release to a new version of a chart.

  • helm rollback: Rolls back a release to a previous version.

  • helm list: Lists all the current releases in the Kubernetes cluster.

  • helm uninstall: Removes a release from the cluster.

1.2.1.2 Helm Charts

Helm charts are the heart of Helm's architecture. A chart is a package that contains all the resource definitions necessary to deploy an application or a set of related applications. It includes templates, configuration files, and dependencies.

Key Components of a Helm Chart:

  • Chart.yaml: Contains metadata about the chart, such as its name, version, and description.

  • values.yaml: Defines the default configuration values for the chart. These values can be overridden during installation.

  • Templates: A directory containing Go templates that define the Kubernetes resources. These templates are rendered with the values provided in values.yaml or by the user.

  • Charts: A directory that can contain dependencies or sub-charts.

1.2.1.3 Helm Repositories

Helm repositories are collections of Helm charts that are stored and shared publicly or privately. Repositories make it easy to distribute and version Helm charts.

Key Features of Helm Repositories:

  • Public Repositories: Helm has several public repositories, such as Artifact Hub, where users can find and download charts for various applications.

  • Private Repositories: Organizations can set up private Helm repositories to store and manage internal charts.

  • Repository Commands: Helm CLI provides commands like helm repo add, helm repo update, and helm repo list to manage repositories.

1.2.1.4 Helm Releases

A Helm release is an instance of a chart running in a Kubernetes cluster. Each time you deploy a chart using the helm install command, Helm creates a release.

Key Characteristics of Helm Releases:

  • Versioning: Releases are versioned, which allows for easy upgrades and rollbacks.

  • State Management: Helm maintains the state of each release, storing details like the chart version, Kubernetes resources created, and configuration values used.

  • Naming: Each release has a unique name, either provided by the user or generated by Helm, which is used to manage and track the release.

1.2.2 Helm v3 Architecture

Helm v3 is the current and recommended version of Helm. It introduced several architectural changes from Helm v2, the most significant being the removal of Tiller.

1.2.2.1 Removal of Tiller

In Helm v2, Tiller was a server-side component that managed releases within the Kubernetes cluster. However, Tiller introduced security concerns, as it required elevated permissions and exposed a potential attack surface within the cluster.

Changes in Helm v3:

  • Client-Side Operations: Helm v3 performs all operations client-side, directly interacting with the Kubernetes API. This simplifies the architecture and eliminates the need for Tiller.

  • Security: By removing Tiller, Helm v3 enhances security by reducing the need for elevated permissions. All operations are performed using the user's existing Kubernetes credentials.

  • Simplified Architecture: The removal of Tiller simplifies Helm’s architecture, making it easier to use and deploy, especially in production environments.

1.2.3 Interaction with Kubernetes API

Helm interacts with the Kubernetes API to manage the resources defined in Helm charts. When a user runs a Helm command (e.g., helm install), the Helm CLI processes the chart, renders the templates, and sends the corresponding API requests to Kubernetes.

Key Interactions:

  • Resource Creation: Helm creates Kubernetes resources (like Pods, Services, and ConfigMaps) based on the templates in the chart.

  • Resource Management: Helm can update or delete resources as part of an upgrade, rollback, or uninstall operation.

  • Status Monitoring: Helm tracks the status of the resources it manages, allowing users to monitor the health and status of their releases.

1.2.4 Hands-on Example: Deploying a Sample Chart

Let’s walk through a simple example to understand how Helm interacts with the Kubernetes cluster:

  1. Install Helm: Ensure Helm is installed and configured to work with your Kubernetes cluster.

  2. Add a Repository: Add a repository containing Helm charts.

    bashCopy codehelm repo add bitnami https://charts.bitnami.com/bitnami

  3. Install a Chart: Install a sample chart from the repository.

    bashCopy codehelm install my-release bitnami/nginx

  4. Observe the Release: Use Helm CLI to list the release and check its status.

    bashCopy codehelm list
helm status my-release

  5. Upgrade the Release: Upgrade the release with custom values.

    bashCopy codehelm upgrade my-release bitnami/nginx --set service.type=NodePort

  6. Rollback the Release: Rollback the release to a previous version if needed.

    bashCopy codehelm rollback my-release 1

1.2.5 Summary

Helm's architecture is designed to simplify Kubernetes application management by providing a robust, flexible, and secure toolset. With Helm CLI, charts, repositories, and releases, you can manage Kubernetes applications efficiently and effectively. The transition to Helm v3 has further enhanced security and usability by removing Tiller and streamlining operations.

PreviousWhat is Helm?NextWrite Helm Charts

Last updated 9 months ago