bitflicker64 commented on code in PR #494:
URL: https://github.com/apache/hugegraph-doc/pull/494#discussion_r4174084097


##########
content/en/docs/quickstart/hugegraph/hugegraph-helm.md:
##########
@@ -0,0 +1,263 @@
+---
+title: "Deploy on Kubernetes with Helm"
+linkTitle: "Deploy on Kubernetes (Helm)"
+weight: 4
+search_keywords:
+  - helm
+  - kubernetes
+  - k8s
+---
+
+### 1 Overview
+
+The Helm chart deploys a distributed HugeGraph cluster on Kubernetes: PD, 
Store, and Server, plus the optional
+Hubble UI. It lives in the main repository under
+[`helm/hugegraph`](https://github.com/apache/hugegraph/tree/master/helm/hugegraph).
+
+| Component | Workload | Default replicas | Purpose |
+|-----------|----------|------------------|---------|
+| PD | StatefulSet + PVC | 3 | Placement driver: a Raft group tracking Stores 
and partitions |
+| Store | StatefulSet + PVC | 3 | Graph data storage (HStore) |
+| Server | Deployment | 3 | Gremlin and REST query layer |
+| Hubble | Deployment | 0 (off) | Web UI, enabled with `hubble.enabled=true` |
+
+A distributed HugeGraph cluster has a startup contract (no `init-store` on 
Server, every Server using PD for graph
+metadata, Store waiting for a PD quorum, one PD REST secret shared by three 
readers). The chart encodes that
+contract so operators do not have to; the details are in the
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#chart-details).
+
+```mermaid
+flowchart LR
+    subgraph Kubernetes cluster
+        PD[PD StatefulSet<br>Raft group of 3, PVC]
+        Store[Store StatefulSet<br>3 replicas, PVC] -->|register, heartbeat| PD
+        Server[Server Deployment<br>3 replicas] -->|metadata, discovery| PD
+        Server -->|gRPC read/write| Store
+        Hubble[Hubble Deployment<br>optional UI] -->|discovers Servers via PD| 
PD
+    end
+    Client[Client / hugegraph-client] -->|REST / Gremlin| Server
+```
+
+Startup order is enforced by the chart, not by the operator: PD pods elect a 
leader first, each Store pod waits in
+an init container until a majority of PD peers report ready, and Servers keep 
restarting their storage wait until
+Stores have registered. A fresh install converges without manual steps.
+
+### 2 Prerequisites
+
+- Kubernetes 1.23 or later (the chart renders `autoscaling/v2` and `policy/v1`)
+- Helm 3; the `--reset-then-reuse-values` flag mentioned under Upgrade needs 
Helm 3.14 or later
+- Dynamic volume provisioning: a default StorageClass, or an explicit 
`storageClassName` for PD and Store
+- Memory for nine JVMs in the default topology; see the resource note under 
Install
+
+The chart requires component images that carry the PD readiness endpoint and 
PD REST authentication (both merged
+for the release after 1.7.0). The default image tags already point at builds 
that include them; 1.7.0 images are
+not supported.
+
+### 3 Install
+
+#### 3.1 Get the chart
+
+The chart is not published to a chart repository yet, so install it from the 
source tree:
+
+```bash
+git clone https://github.com/apache/hugegraph.git
+cd hugegraph
+```
+
+#### 3.2 Install with default values
+
+First confirm `kubectl` points at the intended cluster and that it can 
provision volumes. PVCs stuck in `Pending`
+for want of a StorageClass are the most common first-run failure:
+
+```bash
+kubectl config current-context
+kubectl get storageclass
+```
+
+Then install:
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace --wait --timeout 15m
+```
+
+`--wait` makes Helm block until every workload is ready, which for a 
distributed cluster is the signal that PD
+elected a leader, Stores registered, and Servers came up; without it `helm 
install` returns as soon as the objects
+are created. A fresh cluster normally converges in a few minutes; the 15 
minute timeout leaves room for slow image
+pulls.
+
+Two defaults to know before going further:
+
+- **No resources are set.** Every pod is BestEffort and each JVM sizes its 
heap against total node memory. That is
+  fine on a single node; on a multi-node cluster the heaps oversubscribe the 
nodes and pods abort. Use
+  `values-cluster.yaml` or set `resources` per component for anything beyond a 
laptop.
+- **Image tags track `latest`** until the next HugeGraph release is published, 
with `pullPolicy: Always`. Pin tags
+  or digests for production.
+
+#### 3.3 Topology presets
+
+The chart ships three values files:
+
+| File | Topology | Intended use |
+|------|----------|--------------|
+| `values.yaml` | 3 PD + 3 Store + 3 Server | Default; preferred 
anti-affinity, auth on, Hubble off |
+| `values-single.yaml` | 1 + 1 + 1 | Single-node development and CI; smaller 
PVCs |
+| `values-cluster.yaml` | 3 + 3 + 3 | Production starting point: JVM heap and 
resource settings, PD/Store PodDisruptionBudgets, `required` anti-affinity |
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace \
+    -f helm/hugegraph/values-single.yaml --wait --timeout 15m
+```
+
+`values-cluster.yaml` is a starting point, not a capacity guarantee: 
recalculate resources for your graph size and
+traffic. The full parameter reference (every component, probe, scheduling, and 
Secret knob) is kept in the
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#configuration).
+
+#### 3.4 Verify the install
+
+```bash
+helm test hugegraph --namespace hugegraph
+```
+
+Read the generated admin password and call the API:
+
+```bash
+PASSWORD="$(kubectl get secret -n hugegraph hugegraph-admin -o 
jsonpath='{.data.password}' | base64 --decode)"
+kubectl port-forward -n hugegraph svc/hugegraph-server 8080:8080
+curl --user "admin:${PASSWORD}" http://127.0.0.1:8080/versions
+```
+
+The commands above assume the release is named `hugegraph`; with another name, 
substitute the release-prefixed
+resource names (`kubectl get svc,secret -n <namespace>` lists them). The 
post-install notes printed by
+`helm install` repeat these commands with the right names filled in.
+
+### 4 Authentication and Secrets
+
+Authentication is on by default and the chart manages three Secrets. Each 
credential resolves in the same order:
+an `existingSecret` you created wins, then an inline value, then a random 
value generated at install time.
+
+| Secret | Key | Used for | Bring your own with |
+|--------|-----|----------|---------------------|
+| `<release>-admin` | `password` | Server admin account, Hubble login | 
`server.auth.admin.existingSecret` |
+| `<release>-auth-token` | `token_secret` | JWT signing key shared by all 
Server replicas | `server.auth.token.existingSecret` |
+| `<release>-pd-auth` | `secret-key` | PD REST authentication, read by PD, 
Server, and Hubble | `pd.auth.existingSecret` |
+
+To manage a credential yourself, create the Secret before installing and point 
the matching `existingSecret` value
+at it; the chart never modifies a Secret it did not create. Value constraints: 
the admin password must not contain
+newlines, carriage returns, or backslashes; the JWT key must be at least 32 
bytes; the PD secret must be printable

Review Comment:
   Follow-up in a5fadccb0: chart 2a6e2c404 (apache/hugegraph#3218) narrowed the 
admin password to printable ASCII with no spaces, colons or backslashes, which 
also covers the old leading and trailing whitespace rule. The schema checks an 
inline value at render time and the Server wrapper checks an `existingSecret` 
at Pod start. Section 4 now says this in EN and CN. The PD secret rule has not 
changed.



##########
content/cn/docs/quickstart/hugegraph/hugegraph-helm.md:
##########
@@ -0,0 +1,251 @@
+---
+title: "使用 Helm 在 Kubernetes 上部署"
+linkTitle: "Kubernetes 部署 (Helm)"
+weight: 4
+search_keywords:
+  - helm
+  - kubernetes
+  - k8s
+---
+
+### 1 概述
+
+Helm chart 在 Kubernetes 上部署一套分布式 HugeGraph 集群:PD、Store、Server,以及可选的 Hubble 
UI。chart 位于主仓库的
+[`helm/hugegraph`](https://github.com/apache/hugegraph/tree/master/helm/hugegraph)
 目录。
+
+| 组件 | 工作负载 | 默认副本数 | 作用 |
+|------|----------|------------|------|
+| PD | StatefulSet + PVC | 3 | 元数据管理:以 Raft 组跟踪 Store 与分区 |
+| Store | StatefulSet + PVC | 3 | 图数据存储 (HStore) |
+| Server | Deployment | 3 | Gremlin 与 REST 查询层 |
+| Hubble | Deployment | 0(默认关闭) | Web UI,通过 `hubble.enabled=true` 启用 |
+
+分布式 HugeGraph 集群有一套启动约定(Server 不执行 `init-store`、每个 Server 都通过 PD 读写图元数据、Store 
等待 PD
+形成多数派、一个 PD REST 密钥由三个组件共用)。chart 把这套约定固化下来,运维人员无需手工处理;细节见
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#chart-details)。日常运维(NetworkPolicy
+细节、灾难恢复、伸缩、安全滚动 Store、在集群外运行 Hubble)见
+[运维页](/cn/docs/quickstart/hugegraph/hugegraph-helm-operations/)。
+
+```mermaid
+flowchart LR
+    subgraph Kubernetes 集群
+        PD[PD StatefulSet<br>3 节点 Raft 组,PVC]
+        Store[Store StatefulSet<br>3 副本,PVC] -->|注册、心跳| PD
+        Server[Server Deployment<br>3 副本] -->|元数据、服务发现| PD
+        Server -->|gRPC 读写| Store
+        Hubble[Hubble Deployment<br>可选 UI] -->|通过 PD 发现 Server| PD
+    end
+    Client[客户端 / hugegraph-client] -->|REST / Gremlin| Server
+```
+
+启动顺序由 chart 保证,而不是由运维人员保证:PD 先选出 leader,每个 Store Pod 的 init 容器等到多数 PD 汇报就绪后才启动,
+Server 则反复等待存储层,直到 Store 完成注册。全新安装无需手工干预即可收敛。
+
+### 2 前置条件
+
+- Kubernetes 1.23 及以上(chart 渲染 `autoscaling/v2` 和 `policy/v1`)
+- Helm 3;升级一节提到的 `--reset-then-reuse-values` 需要 Helm 3.14 及以上
+- 动态卷供给:有默认 StorageClass,或为 PD 和 Store 显式指定 `storageClassName`
+- 默认拓扑要运行九个 JVM 进程,内存需留足;见安装一节的资源说明
+
+chart 要求组件镜像包含 PD 就绪探测端点和 PD REST 认证(两者都已合入 1.7.0 之后的版本)。默认镜像 tag 指向的构建已包含
+这些改动;1.7.0 镜像不受支持。
+
+### 3 安装
+
+#### 3.1 获取 chart
+
+chart 尚未发布到 chart 仓库,从源码树安装:
+
+```bash
+git clone https://github.com/apache/hugegraph.git
+cd hugegraph
+```
+
+#### 3.2 使用默认值安装
+
+先确认 `kubectl` 指向目标集群,且集群能供给存储卷。因缺少 StorageClass 而卡在 `Pending` 的 PVC 是最常见的首次安装
+故障:
+
+```bash
+kubectl config current-context
+kubectl get storageclass
+```
+
+然后安装:
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace --wait --timeout 15m
+```
+
+`--wait` 让 Helm 阻塞到所有工作负载就绪。对分布式集群来说,这个信号意味着 PD 已选出 leader、Store 已注册、Server 已
+启动;不加它,`helm install` 在对象创建完成后就返回。全新集群一般几分钟内收敛,15 分钟超时是给缓慢的镜像拉取留的余量。
+
+继续之前需要了解两个默认值:
+
+- **默认不设置 resources。** 每个 Pod 都是 BestEffort,JVM 按节点总内存计算堆大小。单节点没有问题;多节点集群上各个堆
+  会超订节点内存导致进程中止。超出笔记本范围的部署请使用 `values-cluster.yaml`,或按组件设置 `resources`。
+- **镜像 tag 跟踪 `latest`**,且 `pullPolicy: Always`,直到下一个 HugeGraph 版本发布。生产环境请固定 
tag 或 digest。
+
+#### 3.3 拓扑预设
+
+chart 附带三个 values 文件:
+
+| 文件 | 拓扑 | 适用场景 |
+|------|------|----------|
+| `values.yaml` | 3 PD + 3 Store + 3 Server | 默认;preferred 反亲和,认证开启,Hubble 关闭 |
+| `values-single.yaml` | 1 + 1 + 1 | 单节点开发与 CI;PVC 更小 |
+| `values-cluster.yaml` | 3 + 3 + 3 | 生产起点:JVM 堆与资源设置、PD/Store 
PodDisruptionBudget、`required` 反亲和、NetworkPolicy 开启 |
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace \
+    -f helm/hugegraph/values-single.yaml --wait --timeout 15m
+```
+
+`values-cluster.yaml` 是起点而非容量保证:请按图规模和流量重新核算资源。其中一个数字值得说明:它给每个 Store 申请
+5Gi、限制 8Gi 内存,远高于 1Gi 的堆,因为 Store 的 RocksDB 缓存在 JVM 堆之外(4Gi 的限制在约 1 GB 数据后就把
+Store OOM 杀掉了)。两个数字要随数据量一起放大。完整参数参考(每个组件的探针、调度、Secret 配置项)见
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#configuration)。
+
+#### 3.4 验证安装
+
+```bash
+helm test hugegraph --namespace hugegraph
+```
+
+读取自动生成的 admin 密码并调用 API:
+
+```bash
+PASSWORD="$(kubectl get secret -n hugegraph hugegraph-admin -o 
jsonpath='{.data.password}' | base64 --decode)"
+kubectl port-forward -n hugegraph svc/hugegraph-server 8080:8080
+curl --user "admin:${PASSWORD}" http://127.0.0.1:8080/versions
+```
+
+以上命令假定 release 名为 `hugegraph`;用其他名字时,请替换成带 release 前缀的资源名(`kubectl get 
svc,secret -n
+<namespace>` 可以列出)。`helm install` 结束时打印的说明里包含填好名字的同样命令。
+
+### 4 认证与 Secret
+
+认证默认开启,chart 管理三个 Secret。每个凭据按同一顺序取值:你预先创建的 `existingSecret` 优先,其次是内联值,最后
+是安装时随机生成。
+
+| Secret | 键 | 用途 | 自带凭据的配置项 |
+|--------|-----|------|------------------|
+| `<release>-admin` | `password` | Server admin 账号、Hubble 登录 | 
`server.auth.admin.existingSecret` |
+| `<release>-auth-token` | `token_secret` | 所有 Server 副本共用的 JWT 签名密钥 | 
`server.auth.token.existingSecret` |
+| `<release>-pd-auth` | `secret-key` | PD REST 认证,由 PD、Server、Hubble 读取 | 
`pd.auth.existingSecret` |
+
+要自行管理凭据,请在安装前创建 Secret 并把对应的 `existingSecret` 指向它;chart 不会改动任何不是它创建的 Secret。取值
+约束:admin 密码不能包含换行、回车或反斜杠;JWT 密钥至少 32 字节;PD 密钥必须是可打印 ASCII。非法值会在渲染时或启动

Review Comment:
   Follow-up in a5fadccb0: chart 2a6e2c404 (apache/hugegraph#3218) narrowed the 
admin password to printable ASCII with no spaces, colons or backslashes, which 
also covers the old leading and trailing whitespace rule. The schema checks an 
inline value at render time and the Server wrapper checks an `existingSecret` 
at Pod start. Section 4 now says this in EN and CN. The PD secret rule has not 
changed.



##########
content/en/docs/quickstart/hugegraph/hugegraph-helm.md:
##########
@@ -0,0 +1,282 @@
+---
+title: "Deploy on Kubernetes with Helm"
+linkTitle: "Deploy on Kubernetes (Helm)"
+weight: 4
+search_keywords:
+  - helm
+  - kubernetes
+  - k8s
+---
+
+### 1 Overview
+
+The Helm chart deploys a distributed HugeGraph cluster on Kubernetes: PD, 
Store, and Server, plus the optional
+Hubble UI. It lives in the main repository under
+[`helm/hugegraph`](https://github.com/apache/hugegraph/tree/master/helm/hugegraph).
+
+| Component | Workload | Default replicas | Purpose |
+|-----------|----------|------------------|---------|
+| PD | StatefulSet + PVC | 3 | Placement driver: a Raft group tracking Stores 
and partitions |
+| Store | StatefulSet + PVC | 3 | Graph data storage (HStore) |
+| Server | Deployment | 3 | Gremlin and REST query layer |
+| Hubble | Deployment | 0 (off) | Web UI, enabled with `hubble.enabled=true` |
+
+A distributed HugeGraph cluster has a startup contract (no `init-store` on 
Server, every Server using PD for graph
+metadata, Store waiting for a PD quorum, one PD REST secret shared by three 
readers). The chart encodes that
+contract so operators do not have to; the details are in the
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#chart-details).
+Day-2 work (NetworkPolicy details, disaster recovery, scaling, safe Store
+rolls, running Hubble outside the cluster) is on the
+[operations page](/docs/quickstart/hugegraph/hugegraph-helm-operations/).
+
+```mermaid
+flowchart LR
+    subgraph Kubernetes cluster
+        PD[PD StatefulSet<br>Raft group of 3, PVC]
+        Store[Store StatefulSet<br>3 replicas, PVC] -->|register, heartbeat| PD
+        Server[Server Deployment<br>3 replicas] -->|metadata, discovery| PD
+        Server -->|gRPC read/write| Store
+        Hubble[Hubble Deployment<br>optional UI] -->|discovers Servers via PD| 
PD
+    end
+    Client[Client / hugegraph-client] -->|REST / Gremlin| Server
+```
+
+Startup order is enforced by the chart, not by the operator: PD pods elect a 
leader first, each Store pod waits in
+an init container until a majority of PD peers report ready, and Servers keep 
restarting their storage wait until
+Stores have registered. A fresh install converges without manual steps.
+
+### 2 Prerequisites
+
+- Kubernetes 1.23 or later (the chart renders `autoscaling/v2` and `policy/v1`)
+- Helm 3; the `--reset-then-reuse-values` flag mentioned under Upgrade needs 
Helm 3.14 or later
+- Dynamic volume provisioning: a default StorageClass, or an explicit 
`storageClassName` for PD and Store
+- Memory for nine JVMs in the default topology; see the resource note under 
Install
+
+The chart requires component images that carry the PD readiness endpoint and 
PD REST authentication (both merged
+for the release after 1.7.0). The default image tags already point at builds 
that include them; 1.7.0 images are
+not supported.
+
+### 3 Install
+
+#### 3.1 Get the chart
+
+The chart is not published to a chart repository yet, so install it from the 
source tree:
+
+```bash
+git clone https://github.com/apache/hugegraph.git
+cd hugegraph
+```
+
+#### 3.2 Install with default values
+
+First confirm `kubectl` points at the intended cluster and that it can 
provision volumes. PVCs stuck in `Pending`
+for want of a StorageClass are the most common first-run failure:
+
+```bash
+kubectl config current-context
+kubectl get storageclass
+```
+
+Then install:
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace --wait --timeout 15m
+```
+
+`--wait` makes Helm block until every workload is ready, which for a 
distributed cluster is the signal that PD
+elected a leader, Stores registered, and Servers came up; without it `helm 
install` returns as soon as the objects
+are created. A fresh cluster normally converges in a few minutes; the 15 
minute timeout leaves room for slow image
+pulls.
+
+Two defaults to know before going further:
+
+- **No resources are set.** Every pod is BestEffort and each JVM sizes its 
heap against total node memory. That is
+  fine on a single node; on a multi-node cluster the heaps oversubscribe the 
nodes and pods abort. Use
+  `values-cluster.yaml` or set `resources` per component for anything beyond a 
laptop.
+- **Image tags track `latest`** until the next HugeGraph release is published, 
with `pullPolicy: Always`. Pin tags
+  or digests for production.
+
+#### 3.3 Topology presets
+
+The chart ships three values files:
+
+| File | Topology | Intended use |
+|------|----------|--------------|
+| `values.yaml` | 3 PD + 3 Store + 3 Server | Default; preferred 
anti-affinity, auth on, Hubble off |
+| `values-single.yaml` | 1 + 1 + 1 | Single-node development and CI; smaller 
PVCs |
+| `values-cluster.yaml` | 3 + 3 + 3 | Production starting point: JVM heap and 
resource settings, PD/Store PodDisruptionBudgets, `required` anti-affinity, 
NetworkPolicy on |
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace \
+    -f helm/hugegraph/values-single.yaml --wait --timeout 15m
+```
+
+`values-cluster.yaml` is a starting point, not a capacity guarantee: 
recalculate resources for your graph size and
+traffic. One of its numbers deserves a note: it requests 5Gi and limits at 8Gi 
of memory per Store, well above the
+1Gi heap, because the Store's RocksDB caches live outside the JVM heap (a 4Gi 
limit OOM-killed Stores after about
+1 GB of data). Scale both numbers with data size. The full parameter reference 
(every component, probe,
+scheduling, and Secret knob) is kept in the
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#configuration).
+
+#### 3.4 Verify the install
+
+```bash
+helm test hugegraph --namespace hugegraph
+```
+
+Read the generated admin password and call the API:
+
+```bash
+PASSWORD="$(kubectl get secret -n hugegraph hugegraph-admin -o 
jsonpath='{.data.password}' | base64 --decode)"
+kubectl port-forward -n hugegraph svc/hugegraph-server 8080:8080
+curl --user "admin:${PASSWORD}" http://127.0.0.1:8080/versions
+```
+
+The commands above assume the release is named `hugegraph`; with another name, 
substitute the release-prefixed
+resource names (`kubectl get svc,secret -n <namespace>` lists them). The 
post-install notes printed by
+`helm install` repeat these commands with the right names filled in.
+
+### 4 Authentication and Secrets
+
+Authentication is on by default and the chart manages three Secrets. Each 
credential resolves in the same order:
+an `existingSecret` you created wins, then an inline value, then a random 
value generated at install time.
+
+| Secret | Key | Used for | Bring your own with |
+|--------|-----|----------|---------------------|
+| `<release>-admin` | `password` | Server admin account, Hubble login | 
`server.auth.admin.existingSecret` |
+| `<release>-auth-token` | `token_secret` | JWT signing key shared by all 
Server replicas | `server.auth.token.existingSecret` |
+| `<release>-pd-auth` | `secret-key` | PD REST authentication, read by PD, 
Server, and Hubble | `pd.auth.existingSecret` |
+
+To manage a credential yourself, create the Secret before installing and point 
the matching `existingSecret` value
+at it; the chart never modifies a Secret it did not create. Value constraints: 
the admin password must not contain
+newlines, carriage returns, or backslashes; the JWT key must be at least 32 
bytes; the PD secret must be printable

Review Comment:
   Follow-up in a5fadccb0: chart 2a6e2c404 (apache/hugegraph#3218) narrowed the 
admin password to printable ASCII with no spaces, colons or backslashes, which 
also covers the old leading and trailing whitespace rule. The schema checks an 
inline value at render time and the Server wrapper checks an `existingSecret` 
at Pod start. Section 4 now says this in EN and CN. The PD secret rule has not 
changed.



##########
content/en/docs/quickstart/hugegraph/hugegraph-helm.md:
##########
@@ -0,0 +1,282 @@
+---
+title: "Deploy on Kubernetes with Helm"
+linkTitle: "Deploy on Kubernetes (Helm)"
+weight: 4
+search_keywords:
+  - helm
+  - kubernetes
+  - k8s
+---
+
+### 1 Overview
+
+The Helm chart deploys a distributed HugeGraph cluster on Kubernetes: PD, 
Store, and Server, plus the optional
+Hubble UI. It lives in the main repository under
+[`helm/hugegraph`](https://github.com/apache/hugegraph/tree/master/helm/hugegraph).
+
+| Component | Workload | Default replicas | Purpose |
+|-----------|----------|------------------|---------|
+| PD | StatefulSet + PVC | 3 | Placement driver: a Raft group tracking Stores 
and partitions |
+| Store | StatefulSet + PVC | 3 | Graph data storage (HStore) |
+| Server | Deployment | 3 | Gremlin and REST query layer |
+| Hubble | Deployment | 0 (off) | Web UI, enabled with `hubble.enabled=true` |
+
+A distributed HugeGraph cluster has a startup contract (no `init-store` on 
Server, every Server using PD for graph
+metadata, Store waiting for a PD quorum, one PD REST secret shared by three 
readers). The chart encodes that
+contract so operators do not have to; the details are in the
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#chart-details).
+Day-2 work (NetworkPolicy details, disaster recovery, scaling, safe Store
+rolls, running Hubble outside the cluster) is on the
+[operations page](/docs/quickstart/hugegraph/hugegraph-helm-operations/).
+
+```mermaid
+flowchart LR
+    subgraph Kubernetes cluster
+        PD[PD StatefulSet<br>Raft group of 3, PVC]
+        Store[Store StatefulSet<br>3 replicas, PVC] -->|register, heartbeat| PD
+        Server[Server Deployment<br>3 replicas] -->|metadata, discovery| PD
+        Server -->|gRPC read/write| Store
+        Hubble[Hubble Deployment<br>optional UI] -->|discovers Servers via PD| 
PD
+    end
+    Client[Client / hugegraph-client] -->|REST / Gremlin| Server
+```
+
+Startup order is enforced by the chart, not by the operator: PD pods elect a 
leader first, each Store pod waits in
+an init container until a majority of PD peers report ready, and Servers keep 
restarting their storage wait until
+Stores have registered. A fresh install converges without manual steps.
+
+### 2 Prerequisites
+
+- Kubernetes 1.23 or later (the chart renders `autoscaling/v2` and `policy/v1`)
+- Helm 3; the `--reset-then-reuse-values` flag mentioned under Upgrade needs 
Helm 3.14 or later
+- Dynamic volume provisioning: a default StorageClass, or an explicit 
`storageClassName` for PD and Store
+- Memory for nine JVMs in the default topology; see the resource note under 
Install
+
+The chart requires component images that carry the PD readiness endpoint and 
PD REST authentication (both merged
+for the release after 1.7.0). The default image tags already point at builds 
that include them; 1.7.0 images are
+not supported.
+
+### 3 Install
+
+#### 3.1 Get the chart
+
+The chart is not published to a chart repository yet, so install it from the 
source tree:
+
+```bash
+git clone https://github.com/apache/hugegraph.git
+cd hugegraph
+```
+
+#### 3.2 Install with default values
+
+First confirm `kubectl` points at the intended cluster and that it can 
provision volumes. PVCs stuck in `Pending`
+for want of a StorageClass are the most common first-run failure:
+
+```bash
+kubectl config current-context
+kubectl get storageclass
+```
+
+Then install:
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace --wait --timeout 15m
+```
+
+`--wait` makes Helm block until every workload is ready, which for a 
distributed cluster is the signal that PD
+elected a leader, Stores registered, and Servers came up; without it `helm 
install` returns as soon as the objects
+are created. A fresh cluster normally converges in a few minutes; the 15 
minute timeout leaves room for slow image
+pulls.
+
+Two defaults to know before going further:
+
+- **No resources are set.** Every pod is BestEffort and each JVM sizes its 
heap against total node memory. That is
+  fine on a single node; on a multi-node cluster the heaps oversubscribe the 
nodes and pods abort. Use
+  `values-cluster.yaml` or set `resources` per component for anything beyond a 
laptop.
+- **Image tags track `latest`** until the next HugeGraph release is published, 
with `pullPolicy: Always`. Pin tags
+  or digests for production.
+
+#### 3.3 Topology presets
+
+The chart ships three values files:
+
+| File | Topology | Intended use |
+|------|----------|--------------|
+| `values.yaml` | 3 PD + 3 Store + 3 Server | Default; preferred 
anti-affinity, auth on, Hubble off |
+| `values-single.yaml` | 1 + 1 + 1 | Single-node development and CI; smaller 
PVCs |
+| `values-cluster.yaml` | 3 + 3 + 3 | Production starting point: JVM heap and 
resource settings, PD/Store PodDisruptionBudgets, `required` anti-affinity, 
NetworkPolicy on |
+
+```bash
+helm install hugegraph ./helm/hugegraph --namespace hugegraph 
--create-namespace \
+    -f helm/hugegraph/values-single.yaml --wait --timeout 15m
+```
+
+`values-cluster.yaml` is a starting point, not a capacity guarantee: 
recalculate resources for your graph size and
+traffic. One of its numbers deserves a note: it requests 5Gi and limits at 8Gi 
of memory per Store, well above the
+1Gi heap, because the Store's RocksDB caches live outside the JVM heap (a 4Gi 
limit OOM-killed Stores after about
+1 GB of data). Scale both numbers with data size. The full parameter reference 
(every component, probe,
+scheduling, and Secret knob) is kept in the
+[chart 
README](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#configuration).
+
+#### 3.4 Verify the install
+
+```bash
+helm test hugegraph --namespace hugegraph
+```
+
+Read the generated admin password and call the API:
+
+```bash
+PASSWORD="$(kubectl get secret -n hugegraph hugegraph-admin -o 
jsonpath='{.data.password}' | base64 --decode)"
+kubectl port-forward -n hugegraph svc/hugegraph-server 8080:8080
+curl --user "admin:${PASSWORD}" http://127.0.0.1:8080/versions
+```
+
+The commands above assume the release is named `hugegraph`; with another name, 
substitute the release-prefixed
+resource names (`kubectl get svc,secret -n <namespace>` lists them). The 
post-install notes printed by
+`helm install` repeat these commands with the right names filled in.
+
+### 4 Authentication and Secrets
+
+Authentication is on by default and the chart manages three Secrets. Each 
credential resolves in the same order:
+an `existingSecret` you created wins, then an inline value, then a random 
value generated at install time.
+
+| Secret | Key | Used for | Bring your own with |
+|--------|-----|----------|---------------------|
+| `<release>-admin` | `password` | Server admin account, Hubble login | 
`server.auth.admin.existingSecret` |
+| `<release>-auth-token` | `token_secret` | JWT signing key shared by all 
Server replicas | `server.auth.token.existingSecret` |
+| `<release>-pd-auth` | `secret-key` | PD REST authentication, read by PD, 
Server, and Hubble | `pd.auth.existingSecret` |
+
+To manage a credential yourself, create the Secret before installing and point 
the matching `existingSecret` value
+at it; the chart never modifies a Secret it did not create. Value constraints: 
the admin password must not contain
+newlines, carriage returns, or backslashes; the JWT key must be at least 32 
bytes; the PD secret must be printable
+ASCII. Invalid values are rejected at render time or by the startup wrapper, 
not silently truncated.
+
+Chart-managed Secrets are kept on uninstall and reused by a later install 
under the same release name.
+
+<details>
+<summary>Rotation and caveats</summary>
+
+- The admin password is applied only when the auth metadata is first created, 
so changing the Secret later does not
+  rotate an existing cluster's password. Rotate it through the Server's auth 
API instead.
+- Rotating the PD REST Secret rolls PD, Server, and Hubble together on the 
next `helm upgrade`, which keeps their
+  copies in step. Template-only pipelines (`helm template`, GitOps renderers) 
cannot see live Secrets, so there the
+  rotation-detecting annotation is inert.
+- All three Secrets exist even if you only ever read one: the post-install 
notes print the exact `kubectl get
+  secret` commands for the admin password and the PD secret.
+</details>
+
+### 5 Health checks and startup order
+
+PD exposes two health endpoints, and the chart deliberately uses both:
+
+- `/v1/health` answers 200 as soon as the REST listener is up. It never 
consults Raft, so it cannot see a lost
+  quorum.
+- `/v1/ready` answers 503 until the PD Raft group has a leader, so it reports 
quorum, not just a live process.
+
+The chart puts PD **readiness** and the Store init-container wait on 
`/v1/ready`: a Store only starts once a
+majority of PD peers are quorum members, and a PD that lost its leader drops 
out of Service endpoints until a
+leader is back. PD **startup and liveness** derive from the replica count 
(`pd.livenessPath` overrides the
+choice). With more than one PD they stay on `/v1/health` on purpose: a PD that 
merely lost its leader is still a
+healthy Raft member, and restarting it would make the outage worse. A single 
PD is the exception and derives to
+`/v1/ready`: it has no election to lose, and one that steps down for good, as 
after a failed Raft snapshot on a
+full disk 
([apache/hugegraph#3222](https://github.com/apache/hugegraph/issues/3222)), 
would answer `/v1/health`
+forever while serving no writes; the kubelet restarts it instead.
+
+Server startup gets a matching budget: the image would normally kill a Server 
still starting after 120 seconds, so
+the chart derives `HG_SERVER_STARTUP_TIMEOUT_S` from the startup probe (450 
seconds by default) and raises a lower
+configured probe budget to that floor. Raise `server.probes.startup` if your 
storage takes longer to come up, and
+the image budget follows.
+
+### 6 Enable the Hubble UI
+
+Hubble is off by default so API-only clusters stay lean. Enable it on a 
running release:
+
+```bash
+helm upgrade hugegraph ./helm/hugegraph --namespace hugegraph --reuse-values 
--set hubble.enabled=true
+```
+
+```bash
+kubectl port-forward -n hugegraph svc/hugegraph-hubble 8088:8088
+```
+
+Open `http://127.0.0.1:8088` and log in as `admin` with the admin password 
from Section 3.4. Hubble discovers the
+Servers through PD, so the cluster operations view works without extra wiring. 
Hubble serves plain HTTP: reach it
+through a port-forward or an HTTPS-terminating Ingress, never directly from an 
untrusted network. Running Hubble
+outside the cluster is possible but takes more wiring; see
+[Reaching 
Hubble](https://github.com/apache/hugegraph/tree/master/helm/hugegraph#reaching-hubble-pick-one-path)
 in
+the chart README.
+
+### 7 Upgrade
+
+```bash
+helm upgrade hugegraph ./helm/hugegraph --namespace hugegraph --reuse-values
+```
+
+`--reuse-values` keeps the release's existing overrides; without it the 
upgrade rebuilds the release from chart
+defaults. Any upgrade that changes a Pod template rolls that workload once. 
Points worth planning around:
+
+- **The first upgrade after a fresh install rolls PD, Server, and Hubble 
once**, when the Secret-tracking

Review Comment:
   Follow-up in a5fadccb0: at chart 2a6e2c404 a no-change upgrade rolls 
nothing, so the first-upgrade bullet is gone. Section 7 now says the 
annotations hash the credential value, or the `resourceVersion` of an 
`existingSecret`, and keeps the `helm test` advice for any upgrade that does 
roll PD and Server together, such as a PD REST Secret rotation. EN and CN match.



##########
content/en/docs/quickstart/hugegraph/hugegraph-helm.md:
##########
@@ -0,0 +1,263 @@
+---
+title: "Deploy on Kubernetes with Helm"
+linkTitle: "Deploy on Kubernetes (Helm)"
+weight: 4
+search_keywords:
+  - helm
+  - kubernetes
+  - k8s
+---
+
+### 1 Overview
+
+The Helm chart deploys a distributed HugeGraph cluster on Kubernetes: PD, 
Store, and Server, plus the optional
+Hubble UI. It lives in the main repository under
+[`helm/hugegraph`](https://github.com/apache/hugegraph/tree/master/helm/hugegraph).

Review Comment:
   Still applies at a5fadccb0. Checked 2026-10-03: apache/hugegraph master 
(02628ed50) has no `helm/` directory, and apache/hugegraph#3218 is open at 
2a6e2c404. Leaving this thread open as the merge-order gate: merge #3218 first, 
then this PR.



-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to