kubernetes

Fluentd配置文件最佳实践

2022-7-31
technology
kubernetes, fluentd

Fluentd负责Kubernetes中容器日志的收集工作, 以Daemonset形式运行在每一个节点上. 下面这个配置是在多个生产集群使用的配置, 经过多次调优的. 有一些关键的配置增加了配置解释说明. 目前使用问题不大. 持续更新配置中…

Kubernetes 服务器配置和规划建设要求

2022-7-16
technology
kubernetes

新建集群的第一步就是要规划服务器、网络、操作系统等等, 下面就结合我平时的工作经验总结下相关的要求, 内容根据日常工作持续补充完善: 服务器配置 # kubernetes 集群分为控制节点和数据节点, 它们对于配置的要求有所不同: 控制面 # 节点规模 Master规格 1~5个节点 4核 8Gi(不建议2核 4Gi) 6~20个节点 4核 16Gi 21~100个节点 8核 32Gi 100~200个节点 16核 64Gi 系统盘40+Gi,用于储存 etcd 信息及相关配置文件等 数据面 # 规格:CPU >= 4核, 内存 >= 8Gi 确定整个集群的日常使用的总核数以及可用度的容忍度 例如:集群总的核数有160核, 可以容忍10%的错误. 那么最小选择10台16核VM, 并且高峰运行的负荷不要超过 160*90%=144核. 如果容忍度是20%, 那么最小选择5台32核VM, 并且高峰运行的负荷不要超过160*80%=128核. 这样就算有一台VM出现故障, 剩余VM仍可以支持现有业务正常运行. 确定 CPU:Memory 比例. ...

Linux 控制组(cgroups)和进程隔离

2022-5-15
technology
cgroups, kubernetes

控制组(cgroups)是内核的一个特性,它能限制/统计/隔离一个或者多个进程使用CPU、内存、磁盘I/O和网络。cgroups技术最开始是Google开发,最终在2.6.24版本的内核中出现。3.15和3.16版本内核将合并进重新设计的cgroups,它添加来kernfs(拆分一些sysfs逻辑)。cgroups的主要设计目标是提供一个统一的接口,它可以管理进程或者整个操作系统级别的虚拟化,包含Linux容器,或者LXC。

分析告警 kubernetes 节点 load 过高问题

2022-4-27
technology
kubernetes

负载过高分析 # 通过 linux 提供的几个命令可以从不同的纬度分析系统负载。 vmstat # 这命令能从一个系统的角度反应出服务器情况,报告虚拟内存统计信息,报告有关进程、内存、分页、块的信息 IO、陷阱、磁盘和 CPU 活动。看个例子: $ vmstat --wide --unit M 5 procs ----------------memory---------------- ---swap--- -----io---- ---system--- ---------cpu-------- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 1 0 127691 1535 73572 0 0 0 3 0 0 2 1 97 0 0 93 0 0 127674 1535 73573 0 0 0 80 49267 67634 5 1 94 1 0 0 2 0 127679 1535 73573 0 0 0 66 38537 56283 3 1 95 1 0 2 2 0 127738 1535 73574 0 0 6 86 41769 61823 5 1 93 2 0 2 0 0 127729 1535 73574 0 0 18 18 41002 59214 4 1 95 0 0 命令以及输出解释: ...

在 kubernetes 中找出使用 jdk9 及以上版本的应用

2022-3-30
technology
golang, kubernetes

近日, Spring Cloud (SPEL) 中发现 RCE 0-day 漏洞, 为了排查 kubernetes 中所有存在安全威胁的应用. 特地开发了一个小工具来寻找。该工具基于 golang&client-go 开发, 程序会找出当前集群中所有 Running 的 pods, 然后逐个进入容器,执行 java -version 命令,将命令输出打印到文件中,使用编辑器进行查找检索即可。

在 kubernetes 中找出过度使用资源的 namespaces

2022-3-28
technology
golang, kubernetes

我们知道, 在 kubernetes 中, namespace 的资源限制在 ResourceQuota 中定义, 比如我们控制 default 名称空间使用 1核1G 的资源. 通常来讲, 由于 kubernetes 的资源控制机制, .status.used 中资源的值会小于 .status.hard 中相应资源的值. 但是也有特例. 当我们开始定义了一个较大的资源限制, 待应用部署完毕, 资源占用了很多之后, 这时调低资源限制. 此时就会出现 .status.used 中的值超过 .status.hard 中相应值的情况, 尤其是内存的限制.