kubernetes源码分析：大页内存数据来源与更新机制
背景 node资源总量信息 大页内存数据来源 nodeStatus更新 频率配置 kubelet日志等级 回到原点 结论 参考 背景 大页内存通常可以通过/etc/default/grub配置 在配置了大页内存的node上，k8s会自动检测到并将其添加到node capacity中 在开启了NUMA的node上，通过/etc/default/grub配置的大页内存默认会平均分配到所
k8s-pvc延迟绑定模式(waitforfirstconsumer)的一个小坑
背景 排查 解决 参考 背景 某集群部署了rancher的local-path-provisioner供有持久化需求的业务pod使用 今天接到同事的求助：发现在部署几个statefulset的时候，有些pod正常，而有些pod会由于pvc unbound status卡住，同事未能检查出原因。 排查 首先进行常规排查： 对出问题的应用yaml进行垂直、链式检查：statefulset->
开源贡献：为metallb实现layer2模式下状态展示功能
背景 贡献前须知 概要设计 CRD设计 问题分析 controller or speaker node状态 interface状态 功能实现 Go type marker 生成deepcopy代码 CRD client 核心思路 实现功能 本地调试 invoke工具的使用需知 code review round1 round2 e2e测试 ginkgo技巧 round2修改 单元测试 C
基于traefik的TCP-SNI路由和自动SSL证书
背景 部署traefik 准备集群LB 尝试external IP 修改fprs部署方式 traefik基于SNI的TCP流量分发 新增服务使用IngressRoute暴露 参考 背景 有一台公有云vm，部署了k3s，之前主要用于内网穿透，集群中部署了frps，并且直接用hostNetwork接管了节点的443端口。 同时pod里还部署了一个nginx容器，接管节点的80端口，并直接把所有请
kubelet在多NUMA下的性能问题排查
问题发现 初步排查 定位及分析 复现 解决 todo 参考 问题发现 k8s 1.21， node使用了某国产化服务器，其CPU也是国产的，numa node数量多达8个 kubelet cpumanager 启用了best-effort policy 某kubevirt vm挂载sriov网卡数量大于5后，vm无法正常创建，具体表现为vm对应的pod持续卡在pending状态 初步排查
又一次metallb lb ip不通问题排查
问题 排查 分析 解决 参考 问题 某k8s集群基于metallb layer2模式实现了kubernetes得lb service，目前建立了几个lb service，发现有个别的不通 排查 首先在客户端查看arp表（arp -a），发现表里的mac地址和预期中的mac地址不符 安装arping（apt install arping），使用该工具看看arp response的情况（