啊啊

# 详细链接
SHOW FULL PROCESSLIST;

# 汇总查看
SELECT USER, COUNT(*) FROM information_schema.processlist GROUP BY USER;

然后生成查杀kill

SELECT CONCAT('KILL ', ID, ';') AS kill_command
FROM information_schema.processlist
WHERE USER = 'agent' AND COMMAND = 'Sleep';

你是少了user_admin='123456'吧，例如：

KafkaServer {
    org.apache.kafka.common.security.scram.ScramLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin";

    org.apache.kafka.common.security.plain.PlainLoginModule required
    username="admin"
    password="admin-secret"
    user_admin="admin-secret"
    user_alice="alice-secret";
};

没看到你的配置，你看是是否缺少：

sasl.enabled.mechanisms=PLAIN
security.inter.broker.protocol=SASL_PLAINTEXT

这2个参数。

这也是导致这个错误的原因之一。

Error creating broker listeners from 'PLAINTEXT://172.23.15.130:9092': No security protocol defined for listener

这是你对外暴露的策略：

advertised.listeners=PLAINTEXT://172.23.198.184:9092

你有效的是，SASL_PLAINTEXT和CONTROLLER：

listeners=SASL_PLAINTEXT://:9092,CONTROLLER://:9093

所以，你把PLAINTEXT换成有效的SASL_PLAINTEXT或CONTROLLER 就可以了，如：

advertised.listeners=SASL_PLAINTEXT://172.23.198.184: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'

test11

test11

test10

test10

问题解决了。但是原因具体原因不能确定。如果有相同情况，可以按照这个思路排查看看。
我们服务器是arm架构，但是jdk没有使用arm架构的，替换了jdk版本后文件正常删除了。

QoS是怎么实现的

从容器的角度出发，限制容器使用的CPU和内存，是通过cgroup来实现的，目前kubernetes的QoS只能管理CPU和内存，所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。

QoS是什么

在kubernetes中，每个Pod都有个QoS标记，QoS的英文全称为 Quality of Service，中文名为服务质量，它取决于用户对服务质量的预期，也就是期望的服务质量。对于Pod来说，服务质量体现在两个指标上，一个指标是CPU，另一个指标是内存。在实际运行过程中，当NODE节点上内存资源紧张的时候，kubernetes根据Pod具有的不同QoS标记，采取不同调度和驱逐策略。

QoS 类

Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类：

• Guaranteed
• Burstable
• BestEffort

QoS 类为 Guaranteed 的 Pod

• Pod 中的每个容器必须指定内存请求和内存限制，并且两者要相等。
• Pod 中的每个容器必须指定 CPU 请求和 CPU 限制，并且两者要相等。

QoS 类为 Burstable 的 Pod

如果满足下面条件，将会指定 Pod 的 QoS 类为 Burstable：

• Pod 不符合 Guaranteed QoS 类的标准。
• Pod 中至少一个容器具有内存或 CPU 请求。

QoS 类为 BestEffort 的 Pod

• 对于 QoS 类为 BestEffort 的 Pod，Pod 中的容器必须没有设置内存和 CPU 限制或请求。

QoS级别决定了kubernetes处理这些Pod的方式，我们以内存资源为例：

1、当 NODE节点上内存资源不够的时候，QoS级别是BestEffort的Pod会最先被kill掉；当NODE节点上内存资源充足的时候，QoS级别是BestEffort的POD可以使用NODE节点上剩余的所有内存资源。

2、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort的Pod已经都被kill掉了，那么会查找QoS级别是Burstable的POD，并且这些POD使用的内存已经超出了requests设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。

3、当NODE节点上内存资源不够的时候，如果QoS级别是BestEffort和Burstable的Ppod都已经被kill掉了，那么会查找QoS级别是Guaranteed的POD，并且这些POD使用的内存已经超出了limits设置的内存值，这些被找到的POD会被kill掉；当NODE节点上内存资源充足的时候，QoS级别是Burstable的POD会按照requests和limits的设置来使用。

详细参考：配置Pod的服务质量（QoS）