一、传闻规则
大数据CDH集群如果要开启Kerberos，主机名必须要求小写，否则CDH集成Kerberos会失败。
二、背景
生产环境由于经常扩容，且集群有很多应用节点，如果采用/etc/hosts方式做主机之间的解析，那么人力成本会比较高，因此采用DNS。于是引入了一个问题，公司生产环境DNS对主机名解析，会将原先的主机名解析为大写，且带有大写后缀。举例：原主机名为abc，DNS配置的解析映射为ABC.DEF.com，即主机名中出现了大写，与【传闻规则】冲突，然而回退到采用/etc/hosts不能接受，网络改造DNS映射规则不现实。
三、问题
主机名虽然是小写，然而通过DNS解析后变成了大写，即主机名大写了，还能否与kerberos正常集成？
四、尝试的方案
4.1 老朋友/etc/hosts
在集群所有节点/etc/hosts中添加ip与主机名（小写）的映射关系。该方案能够解决问题，但我们无法接受该方案带来的人力成本。因此该方案只是进一步验证了传闻规则而已。
4.2 Kerberos节点添加集群信息
从CDH集群Kerberos的报错日志来看，Kerberos会为每台主机生成principal，无论该服务器的主机名是大小还是小写，生成的principal都是小写，因此，如果服务器的主机名是大写，Kerberos侧的验证便会失败。Kerberos节点只要能解析出集群主机小写的主机名就行，出于该想法，我们只在kerberos节点/etc/hosts中添加集群其他节点的ip与主机名（小写）的映射关系，但结果显示，集群集成Kerberos服务异常，报错"Client not found in Kerberos database（6） - CLIENT_NOT_FOUND"，即Kerberos客户端找不到Server，说明还是主机名解析有问题。
4.3 所有节点添加Kerberos信息
回到Kerberos验证原理，Kerberos会在每台服务器上为其生产principal，包含了主机名信息，那么，每台服务器自己如果通过IP能解析出本机的小写主机名，Kerberos为其生成的principal中的主机名就会是小写，Kerberos验证就会通过。出于这个考虑，我们在集群所有节点/etc/hosts中只配置一条信息，即kerberos服务器的ip与主机名（小写）的映射关系，这样虽然在服务器上添加了/etc/hosts，但每台服务器只需添加一次，人力成本较低，我们可以接受。
结果让人振奋：集群CMS、Zookeeper服务能够正常启动，然而HDFS的NameNode与YARN的ResoureManager的HA无法正常进行选举，集群无Active的NameNode和ResourceManager。
4.4 管理节点添加本机信息
既然方案3已经解决CDH与Kerberos集成的问题，向前推进了一大步，那么，在此基础上继续分析。
无法选举的问题，自然与Zookeeper有关，分析Zookeeper日志，发现其中有对Namenode与ResourceManager来自DNS解析与通过Kerberos返回到的同一主机的大小写两个名字，即解析不一致。
基于最小化操作/etc/hosts规则，我们在三台管理节点Zookeeper上再添加一条关于本机的ip与主机名（小写）的映射，结果是服务启动成功！无报错，Yarn提交作业正常运行！
五、总结
如果CDH集群集成了Kerberos，且主机名中存在大写，不要慌，该问题有解，只需要：
1、每台服务器/etc/hosts中添加kerberos服务器IP与主机名（小写）的映射
2、管理节点/etc/hosts中添加本机的IP与主机名（小写）的映射
六、示例
管理节点hostname的/etc/hosts中添加
1.1.1.1 kerberos.dns.com
2.2.2.2 hostname.dns.com