通过shell脚本扫描从Kubernetes节点往外的tcp请求
2023-4-4
由于Kubernetes中部署的服务队外发起的tcp请求很难监控, 最近数据库运维在排查来自集群的大量数据库请求, 网络层只能看到来自哪个Kubernetes节点主机. 所以写了下面这个脚本来定时扫描.
由于Kubernetes中部署的服务队外发起的tcp请求很难监控, 最近数据库运维在排查来自集群的大量数据库请求, 网络层只能看到来自哪个Kubernetes节点主机. 所以写了下面这个脚本来定时扫描.
Fluentd负责Kubernetes中容器日志的收集工作, 以Daemonset形式运行在每一个节点上. 下面这个配置是在多个生产集群使用的配置, 经过多次调优的. 有一些关键的配置增加了配置解释说明. 目前使用问题不大. 持续更新配置中…
新建集群的第一步就是要规划服务器、网络、操作系统等等, 下面就结合我平时的工作经验总结下相关的要求, 内容根据日常工作持续补充完善: 服务器配置 # 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 比例. ...
控制组(cgroups)是内核的一个特性,它能限制/统计/隔离一个或者多个进程使用CPU、内存、磁盘I/O和网络。cgroups技术最开始是Google开发,最终在2.6.24版本的内核中出现。3.15和3.16版本内核将合并进重新设计的cgroups,它添加来kernfs(拆分一些sysfs逻辑)。cgroups的主要设计目标是提供一个统一的接口,它可以管理进程或者整个操作系统级别的虚拟化,包含Linux容器,或者LXC。
负载过高分析 # 通过 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 命令以及输出解释: ...
apisix-ingress-controller 要求 kubernetes 版本 1.16+. 因为使用了 CustomResourceDefinition v1 stable 版本的 API. 从 1.0.0 版本开始,APISIX-ingress-controller 要求 Apache APISIX 版本 2.7+.
近日, Spring Cloud (SPEL) 中发现 RCE 0-day 漏洞, 为了排查 kubernetes 中所有存在安全威胁的应用. 特地开发了一个小工具来寻找。该工具基于 golang&client-go 开发, 程序会找出当前集群中所有 Running 的 pods, 然后逐个进入容器,执行 java -version
命令,将命令输出打印到文件中,使用编辑器进行查找检索即可。
我们知道, 在 kubernetes 中, namespace 的资源限制在 ResourceQuota 中定义, 比如我们控制 default 名称空间使用 1核1G 的资源. 通常来讲, 由于 kubernetes 的资源控制机制, .status.used
中资源的值会小于 .status.hard
中相应资源的值. 但是也有特例. 当我们开始定义了一个较大的资源限制, 待应用部署完毕, 资源占用了很多之后, 这时调低资源限制. 此时就会出现 .status.used
中的值超过 .status.hard
中相应值的情况, 尤其是内存的限制.
以下冷门命令能实现某种具体的功能, 都是在实际工作中摸索总结的经验, 获取到相关的资源名称之后, 就可以配合常用的 kubectl 命令获取其他详细信息.
pod is in the cache, so can’t be assumed, 这是调度器 scheduler 缓存失效导致的异常事件, 大致原因是 pod 已经调度, 并绑定到指定节点, 由于该节点异常导致启动失败, 重新启动 prometheus statefulset, 让集群重新调度, 其实就是将现有到 prometheus pod 副本数将至 0, 再恢复正常即可.