一、Helm 介绍
1.1 Helm 三个基本概念介绍
1） Chart：Helm 应用包（Package），其中包括了运行一个应用所需要的资源定义、依赖以及相关镜像的引用，还有模板文件、Values 文件等。类似于 yum 的 rpm 文件。
2） 仓库（Repository）：用于发布、存储和共享 Chart 的仓库，Chart 的程序包都存放在这里。
3） 发布（Release）：在 K8s 集群上运行 Chart 的一个实例。在同一个集群上，一个 Chart 可以被安装很多次，而每次安装都会创建一个新的 Release。
1.2 Helm 架构
Helm 是一个可执行文件，执行时分成两个不同的组件:
1）Helm 客户端：是终端用户的命令行客户端，主要负责本地 Chart 的开发、管理仓库、与 Tiller 服务端交互（发送 Chart 用于安装、查询关于发布的信息，以及请求、升级或卸载已经存在的发布）。
2）Tiller 服务端：是一个集群内的服务器，与 Helm 客户端交互并与 Kubernetes API 服务器对接。主要负责监听来自 Helm 客户端的传入请求、结合 Chart 和配置来构建一个发布、安装 Chart 至 Kubernetes，并跟踪后续的发布，以及与 Kubernetes 交互，升级或卸载 Chart。
Helm 的 Chart Install 过程：
1）Helm 从指定的目录或者 tgz 文件中解析出 Chart 结构信息；
2）Helm 将指定的 Chart 结构和 Values 信息经 gRPC 传递给 Tiller；
3）Tiller 根据 Chart 和 Values 生成一个 Release；
二、集约化容器部署 Hadoop 组件
Hadoop 组件容器化部署过程中，每种组件需要部署多个进程，如 kerberos 需要部署 kdc、kadmin；hdfs 需要部署 datanode、namenode；yarn 需要部署 resource management、node manager，hbase 需要部署 master、regionServer 等，每个进程需要部署多种类型的 K8s 资源，如 statefulset、headless service、client service、secret、configMap、ingress、pvc 等。每种组件的每个进程所需 K8s 资源一一部署，部署过程异常复杂，且管理难度大。使用 Helm 可以实现组件的一键部署，部署过程大大简化，方便管理。
2.1 集约化部署 kerberos 组件
集约化部署 Kerberos 组件需要部署 kdc 以及 kadmin 两个进程，每个进程所需要的 K8s 资源如下图所示，根据所需资源设计 Helm Chart。
容器化部署 kerberos 后，需要将生成的 keytab 挂载为 secret，供其他组件使用，为此，开发出一套容器 Kubernets 大数据集群身份验证系统，用户只需要创建 Principal 资源，便可自动生成 keytab 并挂载为 secret。具体逻辑如下图所示：
服务控制器：主要负责接收自定义资源创建消息及其状态监控，当接收到特定的创建消息时，发送请求给另外两个服务；
Kerberos 服务创建服务：它负责请求容器接口服务器，并根据配置创建 Kerberos 服务；
秘钥文件管理服务：它负责通知容器接口服务器创建秘钥，通过 Kerberos 服务创建秘钥文件并挂载为容器 Secret。
2.2 集约化容器部署 Hadoop
集约化容器部署 Hadoop 需要部署 HDFS 组件和 Yarn 组件，集约化容器部署 Hdfs 和 Yarn 组件所需 K8S 资源如下图所示。
根据上图设计 Hadoop Helm Chart 时，将 HDFS 和 Yarn 组件作为 Hadoop Chart 的子 Chart，提供全局参数来帮助用户控制 HDFS 组件、Yarn 组件是否部署以及是否开启 kerberos 认证功能。由于 HDFS 开启 kerberos 认证，则 Yarn 也需要开启 kerberos 认证功能，则设置一个全局变量同时控制 HDFS 和 Yarn 是否开启 kerberos 认证功能。若开启集约化容器部署 Hadoop 组件的 kerberos 认证功能，需要在部署服务的过程中，将 2.1 节部署 kerberos 的配置文件/etc/krb5.conf 以及 2.1 节保存 keytab 的 secret 挂载到 Hadoop 上。HDFS 开启 kerberos 认证功能时，Datanode 进程需要使用 jsvc 启动，则在编写 Hadoop 组件的镜像时，需要安装 jsvc，并设置 jsvc 的环境变量。
2.3 集约化容器部署 HBase
分布式部署 HBase 依赖 zookeeper 与 HDFS，集约化容器部署 HBase 之前需要提前部署 Zookeeper 与 HDFS，按照 2.2 部署 HDFS，集约化容器部署 HBase 与 Zookeeper 所需 K8S 资源如下图所示。
根据上图所示设计 HBase 与 Zookeeper Helm chart。若 HDFS 开启 kerberos 认证功能，则 HBase 与 Zookeeper 同样需要开启 kerberos 认证功能。使用上图 K8S 资源集约化容器部署的 HBase 开启 kerberos 认证功能，HBase 的 RegionServers 进程启动之后，需要告知 Master 进程，在这一过程中，RegionServer 与 Master 进程通信需要进行 Kerberos 认证。具体流程如下：
1）RegionServer 从 Zookeeper 的 Znode 获取 Master 进程的 hostname+port+启动时间戳；
2）RegionServer 根据 hostname 解析出 Master 进程所在机器的 ip；
3）RegionServer 通过 ip 反解析出 Master 的 hostname 形成 principal，并与 keytab 文件配合使用进行 kerberos 认证；
4）认证通过后，RegionServer 进行通信。
在上述第 3 步中存在将 ip 反解析 hostname 不唯一，且存在 hostname 中包含 ip 样式的字符串，HBase 的 RegionServer 和 Master 的 pod 每次重启，pod 的 ip 都会发生改变，导致 RegionServer 访问 Master 出现 kerberos 认证不通过问题，同理，Master 访问 RegionServer 也会出现 kerberos 认证不通过的问题。
本文档使用 CoreDNS 进行域名发现，CoreDNS 不使用 loadbalance 插件，使 ip 每次反解析出的 hostname 相同，将带有 ip 字符串的域名后注册到 CoreDNS 服务，则 ip 反解析出的 hostname 固定，固定的 hostname 生成的 principal 与 keytab 配合使用解决进程之间通信出现的 kerberos 认证失败问题。
三、总结与思考
使用 Helm 集约化容器部署 Hadoop 组件，可以实现 Hadoop 组件一键化部署，管理方便，效率高的优势。由于时间限制，目前尚未实现 HDFS、Yarn 和 HBase 高可用部署，且使用 Helm 集约化部署 Hadoop 生态圈的组件种类少，后续将进一步完善 Helm 集约化容器部署 Hadoop 组件。
参考链接：
•https://helm.sh/zh/docs/
