mirror of https://github.com/helm/helm
				
				
				
			
			You can not select more than 25 topics
			Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
		
		
		
		
		
			
		
			
				
					
					
						
							65 lines
						
					
					
						
							2.3 KiB
						
					
					
				
			
		
		
	
	
							65 lines
						
					
					
						
							2.3 KiB
						
					
					
				| # The Kubernetes Helm Architecture
 | |
| 
 | |
| This document describes the Helm architecture at a high level.
 | |
| 
 | |
| ## The Purpose of Helm
 | |
| 
 | |
| Helm is a tool for managing Kubernetes packages called _charts_. Helm
 | |
| can do the following:
 | |
| 
 | |
| - Create new charts from scratch
 | |
| - Package charts into chart archive (tgz) files
 | |
| - Interact with chart repositories where charts are stored
 | |
| - Install and uninstall charts into an existing Kubernetes cluster
 | |
| - Manage the release cycle of charts that have been installed with Helm
 | |
| 
 | |
| For Helm, there are three important concepts:
 | |
| 
 | |
| 1. The _chart_ is a bundle of information necessary to create an
 | |
|    instance of a Kubernetes application.
 | |
| 2. The _config_ contains configuration information that can be merged
 | |
|    into a packaged chart to create a releasable object.
 | |
| 3. A _release_ is a running instance of a _chart_, combined with a
 | |
|    specific _config_.
 | |
| 
 | |
| ## Components
 | |
| 
 | |
| Helm has two major components:
 | |
| 
 | |
| **The Helm Client** is a command-line client for end users. The client
 | |
| is responsible for the following domains:
 | |
| 
 | |
| - Local chart development
 | |
| - Managing repositories
 | |
| - Interacting with the Tiller server
 | |
|   - Sending charts to be installed
 | |
|   - Asking for information about releases
 | |
|   - Requesting upgrading or uninstalling of existing releases
 | |
| 
 | |
| **The Tiller Server** is an in-cluster server that interacts with the
 | |
| Helm client, and interfaces with the Kubernetes API server. The server
 | |
| is responsible for the following:
 | |
| 
 | |
| - Listening for incoming requests from the Helm client
 | |
| - Combining a chart and configuration to build a release
 | |
| - Installing charts into Kubernetes, and then tracking the subsequent
 | |
|   release
 | |
| - Upgrading and uninstalling charts by interacting with Kubernetes
 | |
| 
 | |
| In a nutshell, the client is responsible for managing charts, and the
 | |
| server is responsible for managing releases.
 | |
| 
 | |
| ## Implementation
 | |
| 
 | |
| The Helm client is written in the Go programming language, and uses the
 | |
| gRPC protocol suite to interact with the Tiller server.
 | |
| 
 | |
| The Tiller server is also written in Go. It provides a gRPC server to
 | |
| connect with the client, and it uses the Kubernetes client library to
 | |
| communicate with Kubernetes. Currently, that library uses REST+JSON.
 | |
| 
 | |
| The Tiller server stores information in ConfigMaps located inside of
 | |
| Kubernetes. It does not need its own database.
 | |
| 
 | |
| Configuration files are, when possible, written in YAML.
 |