啊啊

test11

test11

test10

test10

用df -h查看磁盘的使用空间，发现根目录还剩下80%，删除了一些后，发现可以正常启动了。

[root@node-name ~]# df -h /
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme0n1p1   20G   15G  5.9G  71% /

原因可能是根目录的磁盘空间不足，删除部分空间即可。

kafka的消息是无状态的，不管你消费和不消费的，到时间了就会清理的。

1kb是不是太少了啊，一个分区块也不止啊，至少也得640M。

不行的

虽然 HugePages 的申请方式与默认的内存相差不多，但是它实际上是操作系统单独管理的特殊资源，Linux 会在 /proc/meminfo 中单独展示 HugePages 的相关数据，而 Kubernetes 也会认为大页是不同于内存的独立资源。

另外，在设计方案中，大页资源请求是固定的，不支持过量使用（overcommit），也不是为可能有多种尺寸的场景设计的。

我们认为，应用程序试图使用多个巨大页面尺寸的情况很少。

所以：
你可能不得不根据你的节点设置不同pod规格，例如通过污点将有助于识别特定资源。

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

一、首先在网卡设置中修改NM_CONTROLLED的值：

修改文件/etc/sysconfig/network-scripts/ifcfg-eth0的内容：

NM_CONTROLLED="no"  //是否允许Network Manager管理，设置为no

默认允许Network Manager管理DNS，所以首先设置为no，然后操作DNS设置

二、设置DNS内容：

修改DNS可以有如下两种方案：

1.修改网卡设置：

在/etc/sysconfig/network-scripts/ifcfg-eth0中修改内容：

PEERDNS="yes"
DNS1="xxx.xxx.xxx.xxx"
DNS2="xxx.xxx.xxx.xxx"

这种设置方案是以网卡中设置的DNS为主，resolv.conf中按照网卡设置的DNS内容自动生成，以后想修改DNS，必须修改网卡中的设置才不会在服务器重启之后出现DNS设置失效的问题。

2、直接修改/etc/resolv.conf的值：

需要注意的是，若要使直接修改的DNS内容不会在服务器重启之后丢失，需要设置网卡中PEERDNS的值为no：

nameserver xxx.xxx.xxx.xxx
nameserver xxx.xxx.xxx.xxx

最后，重启网卡：

service network restart

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）