企业官网建设流程全解析

本指南以当前仓库中 incubator/cassandra-reaper 的官方 README 为骨架，结合该 Chart 的源码模板与默认配置，系统讲解 Cassandra Reaper 在 Kubernetes 上的安装、卸载、参数配置、Ingress 暴露、Basic Auth 鉴权以及资源调度等完整实战方案。读完本文，你将掌握基于 Helm 一键部署 Reaper、通过环境变量驱动其运行配置、为 Web 控制台配置 TLS 与基础认证，以及按集群资源定制部署形态的具体操作方法。

一、Chart 背景与仓库定位

Cassandra Reaper 是一个集中式、有状态且高度可配置的 Apache Cassandra 修复（Repair）工具，支持对单数据中心或多数据中心集群执行修复任务。仓库中 Chart.yaml 对它的描述是：

"Reaper is a centralized, stateful, and highly configurable tool for running Apache Cassandra repairs against single or multi-site clusters."

该 Chart 的基本元信息如下（来自 Chart.yaml）：

需要特别说明的是，本仓库中的所有 Chart 已于 2020 年 11 月 13 日起停止更新维护，README 中明确标注了仓库归档通知与弃用声明（DEPRECATION NOTICE），因此本指南所描述的内容适用于 Helm 2 时代及当时的 Kubernetes API 版本（如 Deployment 使用apps/v1beta2、Ingress 使用extensions/v1beta1）。如果你的集群使用 Helm 3 或较新的 Kubernetes 版本，请将其作为配置思路参考，并结合新版 API 进行适配迁移。

二、快速安装与卸载

安装

在仓库根目录下，通过 Helm 将 Chart 安装到cassandra命名空间，release 名称为cassandra-reaper：

helm install --namespace cassandra -n cassandra-reaper incubator/cassandra-reaper

安装完成后可使用helm status cassandra-reaper查看发布状态。默认配置下，Chart 会创建一个名为cassandra-reaper的 Deployment（replicaCount为 1）、一个ClusterIP类型的 Service，以及对应的标签、探针等资源，但不创建 Ingress（ingress.enabled默认为false）。

卸载

helm delete --purge cassandra-reaper

--purge为 Helm 2 时代的参数，表示删除 release 时同时清除其历史记录；使用 Helm 3 时直接执行helm delete cassandra-reaper即可。

三、核心配置参数一览（完整参数表）

以下为 README 中给出的完整可配置参数表，这些参数均可通过values.yaml或helm install --set key=value覆盖：

上述参数在 values.yaml 中都有对应默认值声明，此外该文件还额外支持nameOverride与fullnameOverride，用于覆盖 Chart 默认的资源命名规则，相关机制详见后文"命名约定"一节。

四、通过环境变量驱动 Reaper 运行配置

Cassandra Reaper 的运行时配置主要由环境变量驱动。README 明确指出：要正确配置cassandra-reaper，请参考其官方"环境变量配置文档（docker vars）"。本 Chart 的做法是把values.yaml中的env字段以键值对形式原样注入容器环境。

从 deployment.yaml 的模板逻辑可以看到注入机制：

env: {{- range $key, $value := .Values.env }} - name: {{ $key }} value: {{ $value | quote }} {{- end }}

即env是一个普通字典，每个键成为容器环境变量名，每个值通过quote模板函数自动加引号后写入。例如在values.yaml中配置：

env: REAPER_STORAGE_TYPE: cassandra REAPER_CASS_CONTACT_POINTS: cassandra REAPER_CASS_KEYSPACE: reaper_db REAPER_ENABLE_CROSS_ORIGIN: "true" REAPER_AUTO_ENABLE_NEW_CLUSTERS: "false" JAVA_OPTS: "-Xms256m -Xmx512m"

上述写法会被渲染为容器的env列表，Reaper 启动时即可读取对应配置。需要注意两点：

1. env与探针、端口等硬编码配置不同，它是完全自由的字典，键名需要与 Reaper 镜像内部约定的环境变量名称一致，具体变量清单与取值请以所用镜像版本的官方配置文档为准；
2. 值统一会被quote包裹，因此布尔值、数字等类型在模板中以字符串形式注入，Reaper 侧会自行解析。

五、使用 Ingress 暴露 Web 控制台

Reaper 默认通过 Service 在集群内部暴露，若要对外提供 Web 控制台访问，需要启用 Ingress。Chart 在 ingress.yaml 中渲染 Ingress 资源，完整支持注解、自定义标签、多主机、TLS 与 Basic Auth。

基础启用示例

ingress: enabled: true annotations: kubernetes.io/ingress.class: nginx # kubernetes.io/tls-acme: "true" path: / hosts: - reaper.example.com

对应的 Ingress 模板渲染逻辑（摘自 ingress.yaml）：

rules: {{- range .Values.ingress.hosts }} - host: {{ . | quote }} http: paths: - path: {{ $ingressPath }} backend: serviceName: {{ $fullName }} servicePort: http {{- end }}

ingress.hosts支持多个主机，每个主机都指向名为{{ fullname }}的 Service 的http端口（即 8080，见 Service 定义）。ingress.path默认/，可根据需要改为/reaper等子路径。

配置 TLS

ingress.tls用于配置 HTTPS 证书，默认值为空。在 values.yaml 中给出了参考结构：

ingress: tls: - secretName: chart-example-tls hosts: - chart-example.local

模板会遍历ingress.tls列表，为每个条目渲染tls[].hosts与对应的secretName（即存放证书的 Kubernetes Secret 名称），配合kubernetes.io/tls-acme: "true"注解可实现 Let's Encrypt 自动签发。每个 tls 条目中secretName与hosts为必填字段，secretName在模板中直接引用（见 ingress.yaml 中的secretName: {{ .secretName }}）。

自定义标签与注解

ingress.annotations与ingress.labels通过toYaml模板函数整体渲染进 Ingress 的 metadata，可用于指定 Ingress Controller 类别（如kubernetes.io/ingress.class: nginx）、流量管理、日志采集等场景：

ingress: labels: app: reaper team: database

六、为控制台启用 Basic Auth 鉴权

由于 Cassandra Reaper 自身目前缺乏内置的认证机制，本 Chart 通过 Ingress 层的 Basic Auth 提供基础访问保护。README 特别说明：这种方式是否生效取决于你选择的 Ingress Controller 实现（如 Nginx Ingress 支持在 Secret 中挂载auth数据），不同 Controller 的配置方式略有差异，请查阅对应 Ingress Controller 的文档进行核对。启用 Basic Auth 时，需要提供 auth 文件的 base64 编码版本。

生成 auth 文件

README 给出的生成示例为：

htpassword -c ./auth myuser cat ./auth | base64

说明：示例中的htpassword应为 Apache 工具集提供的htpasswd（如apache2-utils包），正确命令为：

htpasswd -c ./auth myuser # 按提示输入密码 cat ./auth | base64 # 输出 base64 编码后的 auth 文件内容

启用并注入 Secret

将上一步输出的 base64 字符串填入values.yaml：

ingress: enabled: true basicAuth: enabled: true name: reaper-basic-auth # 自定义 Secret 名称 secret: "<上一步 base64 输出的内容>"

当ingress.enabled与ingress.basicAuth.enabled同时为 true 时，secret.yaml 会创建一个Opaque类型的 Secret，其渲染逻辑为：

type: Opaque data: auth: {{ required ".Values.ingress.basicAuth.secret is required when basicAuth is enabled" .Values.ingress.basicAuth.secret }}

这里有几个值得注意的细节：

• Secret 的数据键固定为auth，这正是 Nginx Ingress 等 Controller 读取 Basic Auth 凭据的约定键名；
• required模板函数保证：只要启用了 Basic Auth 而未提供secret字段，Helm 渲染阶段就会直接报错并给出提示信息，从源头避免"认证形同虚设"的配置失误；
• ingress.basicAuth.name不填时默认使用basic-auth（见 secret.yaml 中的default "basic-auth"），填了则使用自定义名称，并在部署时注意与 Ingress Controller 的认证注解引用保持一致。

七、Service 与健康检查机制

Service 定义

默认情况下 Chart 创建一个ClusterIP类型的 Service（见 service.yaml）：

spec: type: {{ .Values.service.type }} ports: - port: 8080 targetPort: http protocol: TCP name: http selector: app.kubernetes.io/name: {{ include "cassandra-reaper.name" . }} app.kubernetes.io/instance: {{ .Release.Name }}

Service 将集群内 8080 端口转发到 Pod 的http命名端口。若需要从集群外部直接访问（不通过 Ingress），可将service.type改为NodePort或LoadBalancer。

探针配置

Reaper 容器对外暴露两个端口（见 deployment.yaml）：

• http：8080（Web 控制台）
• api：8081（REST API）

Deployment 同时配置了完备的存活与就绪探针：

探针均以 HTTP GET 方式请求 API 端口根路径：就绪探针延迟较短（10 秒），用于尽快将可用实例加入 Service 端点；存活探针延迟较长（60 秒），给 Reaper 充分的时间完成 JVM 启动与 Cassandra 连接初始化，避免启动慢导致 Pod 被误杀。

八、资源限制与调度策略

资源请求与限制

通过resources字段为 Reaper 容器声明 CPU/内存请求与上限，模板使用toYaml直接渲染（见 deployment.yaml）：

resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1000m memory: 1Gi

Reaper 是有状态、运行 JVM 的修复任务调度器，建议根据集群规模与修复并发度合理设置内存上限，避免 OOM。

节点调度

Chart 支持三种 Kubernetes 原生调度约束，模板中的渲染位置见 deployment.yaml：

nodeSelector: disktype: ssd tolerations: - key: "dedicated" operator: "Equal" value: "reaper" effect: "NoSchedule" affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: topology.kubernetes.io/zone operator: In values: - us-central1-a

三者的默认值分别为{}、[]、{}（即不做任何调度约束），按需启用即可。

九、命名约定与 Helm 渲染细节

资源名称由 _helpers.tpl 中的三个模板函数统一生成，理解它们有助于预判部署后资源的确切名称：

• cassandra-reaper.name：取.Chart.Name（默认cassandra-reaper），若设置了nameOverride则优先使用，统一截断至 63 字符；
• cassandra-reaper.fullname：优先使用fullnameOverride；否则若 release 名称已包含 Chart 名，则直接复用 release 名，否则拼接为{release-name}-cassandra-reaper，同样截断至 63 字符（Kubernetes 部分资源名称受 DNS 命名规范限制）；
• cassandra-reaper.chart：渲染为{Chart.Name}-{Chart.Version}，并将+替换为_，用于资源的helm.sh/chart标签。

所有模板资源（Deployment、Service、Ingress、Secret）都统一携带以下标准标签：

• app.kubernetes.io/name
• helm.sh/chart
• app.kubernetes.io/instance（release 名称）
• app.kubernetes.io/managed-by（{{ .Release.Service }}）

这些标签保证了 Helm release 的资源选择与追踪一致性，Service 的 selector 正是通过app.kubernetes.io/name与app.kubernetes.io/instance精确匹配到 Deployment 管理的 Pod。

十、运维注意事项与弃用提示

1. 版本与 API 兼容性：该 Chart 使用apps/v1beta2Deployment 与extensions/v1beta1Ingress，仅适用于旧版 Kubernetes。在新集群中使用时，建议参考 deployment.yaml 与 ingress.yaml 的语义自行迁移为apps/v1与networking.k8s.io/v1（后者还需注意spec.rules[].http.paths[].pathType等新字段）。
2. 仓库已归档：本仓库 Chart 自 2020 年 11 月 13 日起不再更新，Cassandra Reaper 官方后续版本（1.4+、2.x）的配置变量与镜像入口可能有较大变化，生产环境请优先评估维护活跃的官方部署方案，并将本文作为理解 Reaper 部署形态与 Helm 模板编写思路的参考。
3. 认证方案取舍：Basic Auth 依赖 Ingress Controller 实现，若使用不支持auth数据键的 Controller，该方案不会生效；Reaper 自身没有内置认证，因此切勿在无任何访问控制的情况下将控制台直接暴露到公网。
4. 副本数说明：replicaCount默认为 1。Reaper 作为修复任务的调度者存在状态，多副本部署需要确保存储与任务调度的一致性，简单场景下保持单副本即可。

结语

围绕 incubator/cassandra-reaper 的 README，本文完整继承了其安装、卸载命令与全部 20 余项配置参数，并结合 values.yaml、deployment.yaml、ingress.yaml、secret.yaml、service.yaml 与 _helpers.tpl 的模板实现，深入讲解了环境变量注入、Ingress/TLS/Basic Auth、健康检查与调度约束的底层渲染机制。即使该 Chart 已归档，其"集中式配置、模板化交付"的设计思路与各参数的实际渲染路径，仍可作为你在 Kubernetes 上部署与管理 Cassandra Reaper 的可靠参考资料。