用df -h
查看磁盘的使用空间,发现根目录还剩下80%,删除了一些后,发现可以正常启动了。
[root@node-name ~]# df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/nvme0n1p1 20G 15G 5.9G 71% /
原因可能是根目录的磁盘空间不足,删除部分空间即可。
不行的
虽然 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可以有如下两种方案:
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
从容器的角度出发,限制容器使用的CPU和内存,是通过cgroup来实现的,目前kubernetes的QoS只能管理CPU和内存,所以kubernetes现在也是通过对cgroup的配置来实现QoS管理的。
在kubernetes中,每个Pod都有个QoS标记,QoS的英文全称为 Quality of Service
,中文名为服务质量
,它取决于用户对服务质量的预期,也就是期望的服务质量。对于Pod来说,服务质量体现在两个指标上,一个指标是CPU,另一个指标是内存。在实际运行过程中,当NODE节点
上内存资源紧张的时候,kubernetes根据Pod具有的不同QoS标记,采取不同调度和驱逐策略。
Kubernetes 创建 Pod 时就给它指定了下列一种 QoS 类:
如果满足下面条件,将会指定 Pod 的 QoS 类为 Burstable:
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)