企业官网建设流程全解析

本文围绕 Helm Charts 仓库中stable/mcrouter图表展开，系统讲解如何通过 Helm 在 Kubernetes 集群中部署 Mcrouter——一款用于横向扩展 Memcached 部署的 Memcached 协议路由器。文中将完整覆盖图表的全部可配置参数、两种 Pod 控制器（DaemonSet / StatefulSet）的选型逻辑、自动生成与自定义配置文件的机制，以及从安装到 telnet 实测的完整验证流程，并深入源码揭示其内部实现细节。

仓库归档提示：本仓库已于 2020 年 11 月 13 日起停止更新，stable/mcrouter图表本身也带有明确的废弃（DEPRECATED）标记，请结合这一前提评估其生产可用性。

Mcrouter 与图表定位

Mcrouter（Memcached Router）是 Facebook 开源的 Memcached 协议路由器，核心用途是在客户端与 Memcached 服务之间加入一层路由，从而支持 Memcached 集群的水平扩展、流量切分与故障转移。本仓库中的 stable/mcrouter 图表即用于把 Mcrouter 以容器化方式部署到 Kubernetes 中，并将 Memcached 作为可选依赖一并安装。

从 Chart.yaml 可以确认图表的元信息：

• name: mcrouter，version: 1.0.6，appVersion: 0.36.0
• description: DEPRECATED - Mcrouter is a memcached protocol router for scaling memcached deployments
• 图片来源为jphalip/mcrouter:0.36.0（第三方镜像），官方源码指向 facebook/mcrouter
• deprecated: true，模板引擎为engine: gotpl

也就是说，Mcrouter 本身是久经考验的开源组件，但这份 Kubernetes 图表已被标记为废弃，社区也不再维护更新。若要在生产环境使用，建议基于官方 Dockerfile 自行构建更新版本的镜像，并自行维护部署清单。

配置参数全览

图表的核心配置集中在 values.yaml，README.md 给出了完整的参数对照表，以下逐一展开说明：

values.yaml 中其余可调项

除 README 参数表外，values.yaml 还暴露了以下配置入口：

• imagePullPolicy：镜像拉取策略，模板中以default "" .Values.imagePullPolicy兜底，未设置时交由 kubelet 默认行为决定
• memcached.replicaCount：Memcached 副本数，默认3，该值直接参与自动配置文件的生成
• memcachedService：Memcached 服务相关信息，包含serviceName（注释状态）、replicaCount（注释状态）、port: 11211、namespace: "default"
• nameOverride（通过_helpers.tpl支持）：用于覆盖资源命名中的名称部分

控制器选型：DaemonSet 与 StatefulSet

图表的核心设计允许用户通过controller参数在两种控制器之间切换，二者在 templates/daemonset.yaml 与 templates/statefulset.yaml 中分别实现，并以{{- if eq .Values.controller "daemonset" }}/{{- if eq .Values.controller "statefulset" }}条件渲染，互斥生效。

DaemonSet 模式（默认）

默认使用 DaemonSet 控制器，即每个 Kubernetes 节点上运行一个 Mcrouter Pod。每个 Mcrouter Pod 通过hostPort（默认5000）绑定到所在节点的宿主机端口。

• 客户端应用 Pod 只需连接自身所在节点的5000端口即可访问 Mcrouter，无需感知具体 Pod IP
• 要获取节点名称，可通过应用 PodSpec 中的spec.nodeName以环境变量方式注入容器
• 该模式的天然优势是负载随节点分布，流量就近转发，适合"每节点一代理"的边缘路由场景

从 daemonset.yaml 的模板实现看，容器启动命令为：

command: ["mcrouter"] args: - -p {{ .Values.mcrouterCommandParams.port }} - --config-file=/etc/mcrouter/config.json

即 mcrouter 以-p 5000监听端口、--config-file指向挂载的 ConfigMap 配置文件启动。同时定义了：

• ports：containerPort取mcrouterCommandParams.port，hostPort取daemonset.hostPort
• livenessProbe：TCP 探活，initialDelaySeconds: 30、timeoutSeconds: 5
• readinessProbe：TCP 就绪探针，initialDelaySeconds: 5、timeoutSeconds: 1
• volumes：将同名的 ConfigMap 挂载到/etc/mcrouter

StatefulSet 模式

当controller: "statefulset"时，使用 StatefulSet 控制器，副本数由statefulset.replicas（默认1）控制。集群内部可通过如下 DNS 名称访问服务：

<release name>-mcrouter.<namespace>.svc.cluster.local

默认端口仍为5000。

StatefulSet 模式还引入了 Pod 反亲和（antiAffinity）策略：

• hard（默认）：使用requiredDuringSchedulingIgnoredDuringExecution，以topologyKey: "kubernetes.io/hostname"强制将副本调度到不同节点
• soft：使用preferredDuringSchedulingIgnoredDuringExecution，权重5，尽力分散副本

从 statefulset.yaml 可看到，反亲和 labelSelector 匹配app: <fullname>与release: <release name>标签，确保同一次 release 的副本之间彼此隔离。

两种控制器的模板还通过 _helpers.tpl 中定义的daemonset.apiVersion/statefulset.apiVersion辅助函数自动选择 API 版本：Kubernetes< 1.9时使用extensions/v1beta1，>= 1.9时使用apps/v1，兼顾了不同集群版本的兼容性。

配置文件的自动生成与自定义

mcrouter 依赖一份 JSON 格式的路由配置（pools、route 等）。图表提供了两条路径：

路径一：自动生成（默认）

若mcrouterCommandParams.configFile未设置，且memcached.enabled: true，templates/configmap.yaml 会根据 Memcached 副本数自动生成配置。生成的 ConfigMapdata.config.json内容形如：

{ "pools": { "A": { "servers": [ "<release>-memcached-0.<release>-memcached.<namespace>.svc.cluster.local:11211", "<release>-memcached-1.<release>-memcached.<namespace>.svc.cluster.local:11211", "<release>-memcached-2.<release>-memcached.<namespace>.svc.cluster.local:11211" ] } }, "route": "PoolRoute|A" }

模板中通过until (.Values.memcached.replicaCount | int)循环生成memcached.replicaCount个后端地址，每个地址的构成规则为：

<release>-memcached-<i>.<release>-memcached.<namespace>.svc.cluster.local:11211

这里隐含了命名约定：依赖的 Memcached StatefulSet 副本pod-0..N由 headless Service<release>-memcached提供稳定的 DNS 名，端口为 Memcached 默认的11211。PoolRoute|A表示将请求路由到名为A的服务器池。

路径二：自定义配置

若要精细控制路由策略（例如多池切分、故障转移、哈希策略等），可设置mcrouterCommandParams.configFile指向仓库内一个自定义 JSON 文件。模板会读取该文件内容并逐行写入 ConfigMap：

{{- if .Values.mcrouterCommandParams.configFile }}{{ range .Files.Lines .Values.mcrouterCommandParams.configFile }}

mcrouter 配置的完整语法与能力（PoolRoute、HashRoute、FailoverRoute 等）可参考 mcrouter 官方的 Config Files 文档（仓库 values.yaml 中注释给出了相关指引），此处不再展开。

无论走哪条路径，生成的 ConfigMap 都会作为卷挂载进 Pod 的/etc/mcrouter目录，并由--config-file=/etc/mcrouter/config.json参数引用；daemonset 与 statefulset 模板还通过checksum/config注解对 ConfigMap 内容取 SHA256 校验和，配置变更会触发 Pod 滚动更新。

依赖管理：Memcached 子图表

图表通过 requirements.yaml 声明了依赖：

dependencies: - name: memcached version: 3.1.0 repository: https://charts.helm.sh/stable condition: mcrouter.memcached.enabled

要点：

• 依赖版本锁定为memcached: 3.1.0，requirements.lock 记录了对应 digest
• condition: mcrouter.memcached.enabled实现条件安装：当memcached.enabled: false时，不会安装 Memcached，此时必须通过mcrouterCommandParams.configFile提供指向外部 Memcached 集群的自定义配置

若 Memcached 已由外部（或其他 release）提供，可设置memcached.enabled: false并利用memcachedService参数（port: 11211、namespace: "default"）配合自定义配置文件指向既有服务。

安装与端到端测试

安装图表

helm install stable/mcrouter --name=myproxy

该命令以 release 名myproxy部署 Mcrouter（默认 DaemonSet 模式），并连带安装 Memcached 依赖。安装完成后，Pod 标签为app=myproxy-mcrouter（fullname由_helpers.tpl定义为<release>-<chart>）。

连接 Pod 并启动 telnet 会话

获取首个 Mcrouter Pod 的 IP，并启动一个临时 alpine 容器进行 telnet 测试：

MCROUTER_POD_IP=$(kubectl get pods -l app=myproxy-mcrouter -o jsonpath="{.items[0].status.podIP}") kubectl run -it --rm alpine --image=alpine --restart=Never telnet $MCROUTER_POD_IP 5000

在 telnet 提示符中输入以下命令验证读写链路：

set mykey 0 0 5 hello get mykey quit

命令语义说明：

• set mykey 0 0 5：设置键mykey，后接标志位、过期时间（0 表示永不过期）、字节长度（5），随后输入hello（5 字节）作为值
• get mykey：读取刚写入的值，应返回VALUE mykey 0 5及hello
• quit：退出 telnet

这一流程验证了客户端 → Mcrouter → Memcached 全链路的写入与读取。由于默认自动生成的配置将请求路由到 Memcached 池A，成功get回刚才set的值即证明路由、转发与后端存储均工作正常。

服务暴露与集群内访问

templates/svc.yaml 定义了 headless Service（clusterIP: None）：

• 端口5000（mcrouterCommandParams.port），targetPort: mcrouter-port
• 通过app: <fullname>选择器关联 Mcrouter Pod

配合 StatefulSet 控制器，Mcrouter 实例可获得稳定 DNS 名<release>-mcrouter-0.<release>-mcrouter.<namespace>.svc.cluster.local及 Service 域名<release name>-mcrouter.<namespace>.svc.cluster.local，供集群内应用按名称访问。

模板实现速查

仓库内stable/mcrouter/templates/目录结构如下：

结语

stable/mcrouter图表完整呈现了一个"路由层 + 存储层"的 Kubernetes 编排范本：通过单一controller参数在 DaemonSet（按节点就近路由）与 StatefulSet（按副本 + 反亲和的高可用路由）之间切换，配合自动或自定义的 JSON 路由配置，把 Mcrouter 的横向扩展能力与 Kubernetes 的调度能力结合起来。需要再次强调的是，该图表已标记废弃（deprecated: true），仓库自 2020 年 11 月起不再更新，本文内容仅适用于存量环境参考或作为自建部署清单的设计蓝本；新部署建议基于 facebook/mcrouter 官方 Dockerfile 构建镜像并自行维护高可用方案。