k8s实例线程、内存、存储异常与标准化

本文介绍了如何解决K8s中线程爆满问题,通过标准化线程限制、内存监控与OOM处理,以及调整实例存储和文件描述符配置。还探讨了如何配置docker以优化Pod性能和资源使用。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、实例的线程标准化

关于线程爆的问题: 由于k8s用户在使用的时候,通常没有关注到Pod的/proc/pid/cpuinfo,meminfo的实例规格信息默认和宿主机的是一致的,故程序默认使用容器的这个/proc/pid/cpuinfo设置默线程maxP(最大线程值),导致爆线程。平台可以给Pod做类似LXCFS之类的文件系统优化,让容器里面看到真实的cpu数据。当然另一种情况是,用户的程序并发控制确实存在问题(比如java线程池,python并发)

1、登录宿主机后,观察pod状态为running,但是kubectl exec 和docker exec 均无法进入该容器,报错如下
在这里插入图片描述
2、找出线程高于10000的容器

cd /sys/fs/cgroup/pids/kubepods && find -name pids.current |grep pod |xargs -I file sh -c 'echo -e file" \c" && cat file'|awk '$2 > 10000'     找出线程数高于N数值的容器

3、通过docker找到对应的id进入对应容器的pid相关目录,特殊情况的话可以临时放大Limit

4、通过kubelet限制每个Pod的线程上限5000,–feature-gates=SupportPodPidsLimit=true

[root@node01 ~]# ps -ef |grep kubelet
root     18735     1 14 11:19 ?        00:53:28 ./kubelet --v=1 --address=0.0.0.0 --feature-gates=SupportPodPidsLimit=true --pod-max-pids=5000 --allow-privileged=true --root-dir=/home/kubelet --node-status-update-frequency=5s --kubeconfig=/home/xbox/kubelet/conf/kubelet-kubeconfig --fail-swap-on=false --max-pods=254 --runtime-cgroups=/systemd/system.slice/frigga.service --kubelet-cgroups=/systemd/system.slice/frigga.service --make-iptables-util-chains=false

二、Pod内存OOM优化

1、查看申请内存失败次数高的实例,/sys/fs/cgroup/memory/kubepods目录下的文件有k8s对应的dockerid为名的限制文件,如果申请内存失败的次数一直在涨,其一是内存泄漏,其二是内存满了,这种可能导致用户实例异常

cd /sys/fs/cgroup/memory/kubepods && find -name "memory.failcnt"|xargs -I file sh -c 'echo -e file" \c" && cat file'|awk '$2 > "0"'

2、到/sys/fs/cgroup/memory/kubepods目录里面找到对应容器的下面两个文件
memory.limit_in_bytes
memory.uss
特殊情况的话可以临时放大Limit

3、Pod遇到OOM的时候,有的时候Pod的会关闭,有的时候不会,具体要看两点,先查/var/log/kern里面OOMkill的日志,要看pid/oom_score_adj的值,这个值越大越优先被Kill,如果没有Kill到主服务进程,Pod仍然会运行不退出,那主服务进程的优先级应该怎么设置呢?是由k8s调度的Qos定,(k8s源码指定当limit等于request的时候,容器进程为优先保障,pod的qos是最高级别, Guaranteed ,进程优先-998)容器的进程就受到保障,甚至在kubelet被系统级内存不足触发的OOMkill的时候Pod还在使用
在这里插入图片描述

三、实例底层存储(docker默认存储配置)

在用docker做Pod运行时通常是用户首选,因为体量大通用性强,不过在使用docker的时候,也是需要使用宿主机本身host存储,
通常我们标准化可以给每个运行时限制使用的存储,具体配置到 /etc/docker/daemon.json

...
  "storage-driver": "overlay2",
  "storage-opts": [
    "overlay2.override_kernel_check=true",
    "overlay2.size=50G"
  ],
...

四、实例的文件描述符

同样配置到/etc/daemom.json

...
  "data-root": "/var/lib/docker",
  "default-ulimits": {
    "nofile": {
      "Name": "nofile",
      "Hard": 2000000,
      "Soft": 2000000
    },
...  
<think>好的,用户现在让我扮演一个优秀的系统架构设计师。之前他询问过学习系统架构需要哪些知识,现在他希望我以这个角色来回答问题。我需要先回顾之前的对话,看看他之前的需求是什么。 在之前的对话中,用户问的是系统架构设计开发需要学习的其他知识,我给出了详细的扩展知识体系,包括底层基础、分布式系统、可观测性、性能优化、安全合规、新兴技术和软技能等。现在用户可能希望我以架构师的身份,提供更具体的设计思路或解决实际问题的方法。 用户当前的问题可能有两个层面:一是验证我是否能够胜任架构师的角色,二是希望得到更贴近实际应用的指导。因此,我的回应需要展示出架构师的思维过程和实际经验,同时保持专业性。 我需要考虑用户可能的深层需求。他可能正在学习系统架构设计,需要实例或方法论来指导实践。作为架构师,我应该强调核心原则、设计流程和常见问题的解决方案,同时提供案例来增强说服力。 接下来,我需要组织回答的结构。通常,系统架构设计会包括核心原则、设计流程、关键技术、案例分析等部分。结合之前的扩展知识,可以分步骤详细说明每个阶段需要考虑的因素,并举例说明如何处理典型问题。 同时,要避免使用过于技术化的术语,保持解释的清晰易懂,但又不失专业性。需要展示出对复杂系统的把控能力,以及在实际项目中权衡不同方案的经验。 可能还需要加入一些软技能的内容,比如沟通协调、风险管理,因为这些也是架构师的重要职责。此外,强调持续学习和适应新技术的能力,以体现架构师的成长性。 最后,确保回答符合用户的要求,使用中文,结构清晰,内容详实,并且以自然的口语化方式表达,避免使用Markdown格式,保持段落简洁。</think>好的,我现在作为系统架构设计师的角色,以实际工作视角为你解析架构设计的核心逻辑和实战方法。以下是系统架构设计的核心要点: --- ### **一、架构师的核心思维模式** 1. **全局权衡能力** - **典型场景**: - 选择Redis Cluster(CP)还是Cassandra(AP)时,需评估业务对数据一致性的容忍度(如秒杀库存能否接受短暂误差) - 决定是否引入Service Mesh:当微服务超过50个且跨语言(Java+Go)时,Istio的流量管理收益>性能损耗 2. **抽象建模能力** - **案例实操**: - 设计电商优惠券系统时,用有限状态机(`CouponStatus`)描述「锁定-核销-过期」状态变迁 - 对IM消息系统建模时,区分「必达消息」(RocketMQ事务消息)「轻量通知」(UDP+重试补偿) 3. **故障推演能力** - **经典Checklist**: - 当ETCD集群节点宕机超过半数,如何设计自动逃生方案(如降级到本地缓存模式) - 网络抖动导致Kafka ISR列表频繁收缩时,调整`replica.lag.time.max.ms`参数的副作用评估 --- ### **二、架构设计标准流程(含具体工具链)** 1. **需求分析阶段** - **核心动作**: - 使用**C4模型**绘制上下文图(明确系统外部支付/物流等系统的边界) - 通过**SLO/SLI定义工具**(如Google的SLOTH模板)量化系统可用性目标(如99.95% = 年故障时间≤4.38小时) 2. **方案设计阶段** - **关键技术选型框架**: ```python def tech_selection(requirements): if 需要强一致性 and 低延迟: return "Redis + Raft协议" elif 海量数据写入 and 高吞吐: return "Kafka + LevelDB存储引擎" else: return "基准测试(如wrk压测API网关)" ``` - 使用**Terraform**快速搭建多region灾备环境 3. **落地实施阶段** - **关键动作**: - 通过**OpenAPI Generator**自动生成SDK,确保各团队接口规范统一 - 在CI/CD流水线中集成**OWASP ZAP**,每次发布自动扫描API漏洞 --- ### **三、典型问题解决范式(附真实案例)** #### **案例1:高并发支付系统设计** - **问题**: 峰值QPS 10万+,要求99.99%事务成功率 - **解决方案**: 1. **分层削峰**: - 接入层:Nginx + Lua脚本实现令牌桶限流 - 队列缓冲:RocketMQ集群承载突发流量(设置优先级队列保障支付指令优先处理) 2. **热点账户优化**: - 采用**账户分桶**策略(user_id % 100分散锁竞争) - 使用**Redisson分布式锁** + 锁超时自动降级(Fallback到本地队列) 3. **对账兜底**: - 开发**离线对账系统**,每小时跑批修复最终一致性偏差 #### **案例2:物联网设备百万级连接** - **挑战**: 50万台设备同时在线,需维持平均心跳延迟≤1s - **架构方案**: - **传输层优化**: - 采用MQTT协议(对比HTTP节省70%流量) - 使用**QUIC协议**改善弱网环境下的连接保持 - **连接管理**: - 基于Netty实现**自适应线程模型**(BossGroup=2线程,WorkerGroup=CPU核心数×2) - 设备状态存储:Redis Cluster(Hash结构存储设备元数据) + 时间序列数据库(InfluxDB存储心跳数据) - **弹性扩展**: - 在K8s中配置HPA,根据TCP连接数自动扩容MQTT Broker Pod --- ### **四、架构师生存指南** 1. **技术雷达维护** - 每季度更新技术选型矩阵(如评估**ClickHouse**是否替代原有Hive+Impala方案) - 建立**技术负债看板**,量化技术升级优先级(如Spring Boot 2.x升3.x的ROI分析) 2. **跨团队协同技巧** - 用**决策日志**(ADR文档)对齐各方认知差异 - 设计**架构适应度函数**(如“API响应时间不得增加15%”)约束需求变更范围 3. **个人能力护城河** - 深度掌握至少一个云平台(如AWS的**Serverless架构设计**认证) - 定期研究顶级公司架构(如学习Twitter的**Timeline Service**重构论文) --- ### **五、避坑指南(血泪经验)** 1. **分布式事务陷阱** - 错误做法:为所有操作添加Saga补偿事务 → 系统复杂度爆炸 - 正确做法:区分**关键事务**(用DTX框架)**普通操作**(异步消息+人工对账) 2. **过度设计预警信号** - 在日均订单1000时引入Kafka → 运维成本远超收益 - 解决方案:建立**技术引入评审卡**(必须证明现有MySQL无法支撑) 3. **性能优化反模式** - 盲目使用缓存导致数据不一致 → 应先通过**Jepsen测试**验证缓存策略 - 过早优化(如为未来3年后的流量设计分库分表)→ 违反YAGNI原则 --- 如果需要解决具体场景的架构问题,可以直接提供业务需求(例如:“设计一个支持千万用户的活动抽奖系统”),我将给出完整技术方案和选型依据。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值