Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Helm Chart Full Deployment Process: Kubernetes Environment Requirements, Namespace Planning, and Persistent Storage Configuration

Helm deployment is the formal environment path that partners most need to master.

This is directly supported by Enterprise official documentation. The official Helm documentation, Kubernetes prerequisites documentation, and Resources Checklist explicitly position Helm on the formal environment deployment path, specifying requirements for Kubernetes version, Helm version, persistence, domain names, Ingress, and resource specifications. Therefore, this content can serve as an official training baseline for partners.

1. Helm Training Focus Confirmed by Public Sources

1. Helm Is One of the Primary Paths for Formal Environment Deployment

The Enterprise documentation already presents helm repo add, helm repo update, and helm upgrade -i dify -f values.yaml dify/dify as the standard installation method. This means partners must master Helm, not just know how to navigate the console UI.

2. Kubernetes and Resource Requirements Have Official Minimums

The public documentation explicitly specifies requirements such as Kubernetes 1.24+ and Helm 3.14+, and lists preparation items for external resources including databases, Redis, vector databases, and object storage. These prerequisites should be covered as mandatory training content.

3. Namespace Planning Affects License and Operations

The official License documentation explicitly states that the License is bound to a namespace. Therefore, namespace planning is not merely an organizational habit but a critical boundary for subsequent activation, renewal, and migration.

2. Environment Requirements

Baseline requirements confirmed by public sources include Kubernetes 1.24+ and Helm 3.14+, with corresponding resources required for the database, Redis, object storage, and vector database.

3. Namespace Planning

At minimum, distinguish between:

  • dev
  • staging
  • prod

For Enterprise, namespaces also relate to License activation, so they should not be changed casually.

4. Persistent Storage

Three categories of persistent objects should be clearly defined:

  • Database
  • File storage / Object storage
  • Vector database

5. Training Focus

Trainees should master:

  • helm repo add / helm show values
  • How to maintain values.yaml
  • How to perform upgrades and rollbacks
  • How to check deployment / pod / ingress / pvc status

Public Source References

note.com

  • Running Dify on Azure Kubernetes Service (AKS) | https://note.com/k_7tsumi/n/n347b0db42499

zenn.dev / Official Documentation / Other Public Pages

  • Dify Helm Chart - Dify Enterprise Docs | https://enterprise-docs.dify.ai/en-us/deployment/advanced-configuration/dify-helm-chart
  • Kubernetes - Dify Enterprise Docs | https://enterprise-docs.dify.ai/en-us/deployment/prerequisites/kubernetes
  • Resources Checklist - Dify Enterprise Docs | https://enterprise-docs.dify.ai/versions/3-7-x/en-us/deployment/resources-checklist
  • Deploying Dify on minikube using Helm | https://zenn.dev/data_and_ai/articles/703ac71eea4b01

Confirmed Information from Public Sources

  • Helm is one of the publicly documented standard approaches for Enterprise formal deployment
  • Kubernetes version, resource specifications, and persistence requirements have official minimums
  • Namespace planning affects License activation and subsequent operations