开启了kerberos的环境，在zookeeper上有kafka的相关节点，无法删除。

进入zookeeper client，查看acl权限：
[zk: ] getAcl /brokers/topics/***
'world,'anyone
: r
'sasl,'kafka
: cdrwa

[zk: ] getAcl /brokers/topics//**
'world,'anyone
: cdrwa

kafka的配置：
KafkaServer {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/etc/kafka1/conf/kafka1.keytab"
storeKey=true
useTicketCache=false
principal=“kafka/**_@TDH";
};
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/etc/kafka1/conf/kafka1.keytab"
storeKey=true
useTicketCache=false
principal=“kafka/**TDH”;
};
// Zookeeper client authentication
Client {
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
storeKey=true
useTicketCache=false
keyTab="/etc/kafka1/conf/kafka1.keytab"
principal="kafka/_@TDH”;
};

检查发现kafka配置文件是没问题的，kinit无问题，klist可以得到kafka已经验证成功。

后来进入zookeeper client，想知道目前进来client的uid（或者说使用的principle到底是哪个），未找到直接查看的方法。

故新建节点，改节点权限为sasl:kafka,sasl:zookeeper,sasl:hbase，然后对该节点进行操作验证权限。发现无论在外部用哪个principle kinit，进入zookeeper client之后都会被换成zookeeper。

一定在进入zookeeper client的时候，自动使用了zookeeper的principle。查看zookeeper的配置文件，发现问题。
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=true
keyTab="/etc/zookeeper1/conf/zookeeper.keytab"
storeKey=true
useTicketCache=false
principal=“zookeeper/**@TDH”;

将client下的此处，换成
com.sun.security.auth.module.Krb5LoginModule required
useKeyTab=false
useTicketCache=true;

随后进行kinit,进入zookeeper client后，发现外部的kinit在client内成功生效，可以对相关节点进行操作。