半兽人
只有比别人更早、更勤奋地努力，才能尝到成功的滋味。
只有比别人更早、更勤奋地努力，才能尝到成功的滋味。
只有比别人更早、更勤奋地努力，才能尝到成功的滋味。
只有比别人更早、更勤奋地努力，才能尝到成功的滋味。
嗯，k8s的版本，所以对参数有区别，可以参考：https://www.kubebiz.com/KubeBiz/kafka
里面有k8s的版本选择，会自动补全。
有个困惑 好像只有sts才能使用volumeClaimTemplates给每个副本创建pvc，deploy不能用，那么deploy是怎么给每个pod分配pvc的呢，问的gpt说是deploy是一组pod共享一个pvc。。但是网上又有说这种说法是错的。。每个pod都应该有自己独立的pvc。。。请教一下大佬
一般是基础镜像的问题：
先手动拉取：
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.45
然后手动指定基础镜像：
minikube start --force --base-image='registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.45'
enabled mechanisms are []
启用的机制是空，并没有生效，先看看kafka日志中是否有什么异常。
另外，我看你配置里有些其他的认证方式，建议你注掉，防止干扰。
可参考：https://www.orchome.com/1966
先保证命令行可以运行成功。
enabled mechanisms are []
启用的机制是空，并没有生效，先看看kafka日志中是否有什么异常。
另外，我看你配置里有些其他的认证方式，建议你注掉，防止干扰。
可参考：https://www.orchome.com/1966
先保证命令行可以运行成功。
LISTENERS=listeners=PLAINTEXT://phm-data02:9092,
这个换成
LISTENERS=listeners=SASL_PLAINTEXT://phm-data02:9092
LISTENERS=listeners=PLAINTEXT://phm-data02:9092,
这个换成
LISTENERS=listeners=SASL_PLAINTEXT://phm-data02:9092
一般是基础镜像的问题：
先手动拉取：
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.45
然后手动指定基础镜像：
minikube start --force --base-image='registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.45'
一般是基础镜像的问题：
先手动拉取：
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.45
然后手动指定基础镜像：
minikube start --force --base-image='registry.cn-hangzhou.aliyuncs.com/google_containers/kicbase:v0.0.45'
先看看有没有权限，上面只是说失败的加载。
另外可参考：https://www.orchome.com/500
无法删除是因为命名空间中仍然存在的资源引起的。
以下命令显示命名空间中剩余的资源：
kubectl api-resources --verbs=list --namespaced -o name \
| xargs -n 1 kubectl get --show-kind --ignore-not-found -n <namespace>
一旦你移除了这些资源之后，命名空间就能删掉了。
感谢大佬的指点，目前已经全部调通，包括kerberos环境！
非kerberos环境最后配置的格式就是上面贴的。
kerberos环境 大致还需要以下几点。
1、kafka-server端加了环境变量
export KAFKA_OPTS="-Djava.security.auth.login.config=/usr/hdp/current/kafka-broker/conf/kafka_jaas.conf"
2、/etc/krb5.conf文件可能需要加一行udp_preference_limit = 1 将udp改成tcp防止丢包（这个不一定需要）
3、客户端需要一个kafka_client_jaas.conf
KafkaClient {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true
renewTicket=true
serviceName="kafka";
};
Client {
com.sun.security.auth.module.Krb5LoginModule required
useTicketCache=true
renewTicket=true
serviceName="zookeeper";
};
4、然后一些sasl的配置，监听器的配置就不赘述了
总结：之前对“主动发现集群机制”了解不够，也不知道消费时要对每一个broker都开一个长连接* 加上报错一直都是权限验证失败让人感觉是kerberos的问题，绕了很久。后面排除无关的因素，就很明显了。另外提醒ambari安装的kafka不管界面上配置的advertised.listeners是多少，内部代码还是会强行将listeners的值赋给advertised.listeners。
还是很感谢大佬的及时回复 耐心指导。期待以后更多的交流
对应的是pod的.metadata.uid：
for d in /var/lib/kubelet/pods/*; do
p_u=$(basename "$d")
kubectl get po -A -o json | \
jq --arg pod_uuid "$p_u" -r '.items[]
| select(.metadata.uid == $pod_uuid)
| "uuid \($pod_uuid) is \(.metadata.name)"'
done
类似如下输出：
"Labels": {
"annotation.io.kubernetes.container.hash": "e44bee94",
"annotation.io.kubernetes.container.restartCount": "4",
"annotation.io.kubernetes.container.terminationMessagePath": "/dev/termination-log",
"annotation.io.kubernetes.container.terminationMessagePolicy": "File",
"annotation.io.kubernetes.pod.terminationGracePeriod": "30",
"io.kubernetes.container.logpath": "/var/log/pods/kube-system_storage-provisioner_b4aa3b1c-62c1-4661-a302-4c06b305b7c0/storage-provisioner/4.log",
"io.kubernetes.container.name": "storage-provisioner",
"io.kubernetes.docker.type": "container",
"io.kubernetes.pod.name": "storage-provisioner",
"io.kubernetes.pod.namespace": "kube-system",
"io.kubernetes.pod.uid": "b4aa3b1c-62c1-4661-a302-4c06b305b7c0",
"io.kubernetes.sandbox.id": "3950ec60121fd13116230cad388a4c6c4e417c660b7da475436f9ad5c9cf6738"
}
