- 博客(1845)
- 收藏
- 关注
RSS订阅原创 Kubernetes 在生产环境的调优笔记，建议收藏！
本文基于生产实践，详细剖析了Kubernetes集群从1000节点扩展到5000节点的系统化优化方案。核心内容包括：控制平面扩容与参数调优、etcd集群深度优化、网络架构升级、调度策略精细化等关键场景。通过某互联网公司真实案例，展示了分阶段实施的具体步骤和效果对比，最终实现APIServer响应时间降低85%、Pod调度时间缩短80%、节点资源利用率提升132%等显著优化。文章总结了大规模集群运维的关键经验，并展望了虚拟集群、边缘计算、AI调度等未来发展方向。为面临集群扩展挑战的架构师和运维工程师提供了可落
2025-10-21 09:14:19
1426
原创 RocketMQ 集群核心概念-幂等消息-幂等问题的出现
消费者在拿到消息以后，它已经将消息存在DB里面了，它已经完成它的业务了，正常要返回ack，只剩下最后一步提交offset，但是在提交offset的时候，不巧消费者挂掉了，那么意味着这个offset没有办法被提交。现在由于网络的抖动导致生产者这条消息发送之后没有办法收到broker的ack，那么生产者根据之前的机制的设定还会再次去发送，那么这条消息按照正常的链路来走的话就是被消费者消费两次。或者在消费完一条消息的时候，在提交offset的时候，消费者1挂掉了，然后消费者2继续将这条消息存放到数据库里面。
2025-10-14 20:05:03
1277
原创 Kubernetes 证书监控--x509-certificate-exporter
本文介绍了在Kubernetes集群中部署x509-certificate-exporter监控工具的配置方法。该工具通过监控集群节点上指定的证书文件和kubeconfig文件来获取证书信息。文章详细列出了需要监控的证书文件路径，并提供了从GitHub下载和修改配置文件的步骤，包括调整Chart版本号、镜像仓库地址等关键配置项。同时说明了如何通过Helm命令安装该工具，以及部署后如何检查Pod运行状态。最后还提供了异常处理建议，包括检查日志和解决证书文件权限问题的方法。
2025-09-23 17:53:45
1042
原创 RocketMQ 集群核心概念-消息重试-触发重试的条件
消息消费过程中，消费者会从broker获取消息但不会立即删除。消费者通过提交offset到consumerquenue文件来标记消息消费进度。若消费失败未提交offset，broker会保留消息并触发重试机制。当消费者宕机时，系统会通过rebalance机制将队列重新分配给其他消费者，新消费者会从最后一个已提交的offset位置继续消费。这种机制确保了消息不会因消费异常而丢失，同时支持负载均衡和故障转移。
2025-09-15 10:33:37
1116
原创 RocketMQ 集群核心概念-消息主从复制
生产者producer发送了一个消息过来，然后在master上面这个数据进来了，如果是同步方式的话，那么要等这个消息同步到slave节点上之后，那么这个broker集群才会返回ack给我们的producer。异步也可以得到broker返回的消息，但是发送完消息不需要一直等broker给我返回，这里只需要放一个回调函数，当broker返回确认消息，这个方法就会被调用，在发送完消息就可以做其他事情了。同步的方式：当生产者发送消息，消息同步到了从节点，这个时候才会返回确认消息给producer。
2025-09-10 20:48:11
1093
原创 RocketMQ 消息存储机制-索引文件及页缓存
摘要：RocketMQ采用混合存储结构，将生产者消息写入CommitLog文件，同时构建ConsumeQueue逻辑队列和IndexFile索引文件。IndexFile支持通过key或时间区间查询消息，底层采用hash索引结构。通过页缓存、顺序读写和零拷贝技术优化读写性能。Broker启动时通过abort文件判断上次关闭状态，配置信息存储在json文件中。这种设计保证了消息持久化存储和高效检索，同时支持长轮询消费模式。
2025-09-02 16:28:30
1816
原创 Velero 实现k8s跨集群迁移
K8s集群数据迁移指南 摘要：本文介绍了使用Velero工具实现Kubernetes集群间数据迁移的方法。首先需要在目标端部署干净的K8s集群，然后安装Velero服务端和客户端，配置与原集群相同的MinIO存储地址以获取备份文件。迁移过程包括：1）在目标集群部署Velero并连接源MinIO；2）查看并确认备份数据可用；3）执行还原命令；4）验证资源恢复情况。注意目标集群配置（如节点数、版本）可与源集群不同，但核心数据将保持一致。整个迁移过程实质是备份还原操作的跨集群实现，最终确保数据完整移植到新环境。
2025-09-02 11:20:46
935
原创 velero 数据备份与恢复时的资源过滤（指定ns/资源/label）
本文介绍了Velero工具中资源过滤的使用方法，包括包含和排除标志的应用。通过include/exclude选项可以按命名空间、资源类型或标签选择性地备份和恢复Kubernetes对象。主要内容涵盖：1）包含功能（--include-）可指定特定资源；2）排除功能（--exclude-）可过滤不需要的资源；3）集群范围资源（--include-cluster-resources）的三种处理方式；4）标签选择器（--selector）实现更细粒度控制；5）特殊标签velero.io/exclude-from-
2025-08-27 15:46:34
1384
原创 RocketMQ 消息存储机制-消息刷盘
消息刷盘分为同步和异步两种方式。同步刷盘确保消息写入磁盘后才返回确认，可靠性高但吞吐量低；异步刷盘先将消息存入内存页缓存后立即返回确认，由后台线程异步写入磁盘，提高了吞吐量但存在数据丢失风险。两种方式在可靠性和性能之间各有侧重。
2025-08-26 20:08:08
882
原创 RocketMQ 消息存储机制 CommitLog和ConsumerQu
摘要：RocketMQ通过CommitLog文件存储所有消息，采用顺序写入提升性能。为优化消费效率，引入ConsumeQueue作为索引，按Topic/QueueId组织，记录消息在CommitLog中的物理偏移量。CommitLog默认1G大小，写满后创建新文件；ConsumeQueue采用定长设计（20字节/条目），实现快速检索。这种物理存储+逻辑索引的架构既保证了消息持久化，又提升了消费性能，同时支持消费者偏移量管理以实现故障恢复。
2025-08-13 20:11:43
1520
原创 velero 资源备份恢复测试 定期备份
摘要：本文介绍了使用Velero工具进行Kubernetes集群备份和恢复的操作流程。主要内容包括：1）通过velerobackup create命令创建带时间戳的命名空间备份；2）使用velerobackup describe查看备份状态；3）演示删除命名空间后，通过velero restore create从指定备份恢复应用和数据；4）验证恢复后Pod和数据完整性。整个过程展示了Velero在K8s环境中的备份恢复能力，包括元数据备份、持久化数据恢复等功能。
2025-08-13 16:20:40
1072
原创 containerd 配置镜像加速
本文介绍如何配置containerd镜像加速器。首先修改config.toml文件，添加registry插件配置，指定证书目录。然后创建对应的certs.d目录结构，为docker.io、registry.k8s.io等镜像仓库配置hosts.toml文件，添加阿里云、DaoCloud、163等国内镜像源。配置完成后需重启containerd服务。注意ctr命令与crictl命令的差异，以及不同镜像仓库的配置方法。文中提供了docker.io、registry.k8s.io和k8s.gcr.io三种常见镜像
2025-08-13 14:06:46
1666
1
原创 Velero 简介和部署
摘要：Kubernetes集群备份工具Velero支持资源备份和PV数据迁移，与etcd备份形成互补。Velero通过API server进行细粒度备份（如按命名空间、标签等），支持周期性备份，而etcd直接备份整个数据库。部署Velero需安装客户端和服务端（控制器），配合对象存储（如Minio）使用，需配置访问凭证。Velero备份流程包括创建Backup对象、资源收集和存储上传，恢复时通过Restore控制器完成。相比etcd，Velero提供了更灵活的备份策略和迁移能力，适合生产环境集群数据的管理和
2025-08-05 16:47:43
2007
2
原创 如何使用 Nginx Ingress 实现金丝雀发布
本文详细介绍了如何使用Nginx Ingress实现金丝雀发布，包括两种主要场景：1）基于Header/Cookie的定向灰度发布，可将新版本面向特定用户群体；2）基于权重的流量比例切分（0-100%）。文章提供了完整的YAML配置示例，涵盖v1/v2版本部署、常规Ingress创建以及三种Canary策略实现（Header匹配、Cookie识别和权重分配）。同时指出了Nginx Ingress在Canary发布中的局限性，如仅支持两个版本共存、必须配置域名等。该方案适合使用Nginx Ingress且发布
2025-08-01 13:58:26
2146
原创 如何根据不同业务场景调节 HPA 扩缩容灵敏度
Kubernetes HPA自动扩缩容灵敏度控制指南 Kubernetes 1.18对HorizontalPodAutoscaler(HPA)进行了重要更新，新增了behavior字段用于控制扩缩容灵敏度。该功能允许用户根据业务需求定制化扩缩容策略：关键业务可配置快速扩容（立即新增9倍副本）和缓慢缩容（每10分钟缩1个Pod）；非关键业务可设置缓慢扩容（每次新增1个Pod）；还可禁止自动缩容或延长扩缩容时间窗口（最长10分钟）以避免误操作。这些特性通过scaleUp/scaleDown策略实现，使HPA能更
2025-07-23 15:16:04
2060
原创 Kubernetes 探针原理、效果以及配置建议
Kubernetes容器探针主要包括启动探针(StartupProbe)、存活探针(LivenessProbe)和就绪探针(ReadinessProbe)。启动探针用于检测容器初始化完成，存活探针判断容器是否正常运行，就绪探针确认容器是否准备好接收流量。探针支持HTTP请求、TCP连接和执行命令三种检测方式，并可通过参数调整探测行为。配置建议包括：慢启动应用应优先配置启动探针，调整合适的探测时间间隔，存活探针失败阈值应大于就绪探针等。探针失败时，存活探针会导致容器重启，就绪探针则从服务中移除实例。
2025-07-21 14:56:44
2364
原创 K8s 集群CoreDNS监控告警最佳实践
CoreDNS作为Kubernetes集群的核心DNS服务，其性能监控至关重要。关键监控指标包括：请求速率（按协议、记录类型分组）、响应速率（按状态码）、UDP/TCP请求/响应数据包大小（P50/P90/P99）、响应时延（P99阈值建议设为1s）以及缓存指标（记录数、命中/丢失率）。这些指标通过Prometheus采集，使用PromQL进行查询和告警配置。重点需关注P99响应时延、请求速率和缓存命中率，其中响应时延初始告警阈值可设为1秒（基于DNS解析超时时间2s），后续根据实际数据优化。
2025-07-21 11:18:50
1972
原创 Kubernetes NodeLocal DNSCache 简介
DNSConfig动态注入控制器，基于Admission Webhook机制拦截Pod创建的请求，自动注入使用DNS缓存的Pod DNSConfig配置；DNS缓存代理，在每个集群节点上创建一个虚拟网络接口（默认监听IP 169.254.20.10），配合Pod的DNSConfig和节点上的网络配置，Pod内产生的DNS请求会被该服务所代理。工作原理图如下图所示：1、已注入DNS本地缓存的Pod，默认会通过NodeLocal DNSCache的服务地址（169.254.20.10）解析域名;
2025-06-27 10:59:01
2699
转载 记一次 k8s dns解析异常故障分析
事情是这样的，有天有个客户找到我，说他在k8s集群里面部署了一套KubeFlow，pod状态都是正常的，但是登录的时候界面报了一个500错误，并给我发了下面这张截图，我当时也不知道KubeFlow是啥，但是我注意到了截图上面显示的url地址，“oauth2/callback”看名称是一个认证回调相关的地址，初步怀疑是调用这个oauth2接口异常了所以报错。只能去提供这个接口的pod里找日志了，以下是客户部署的KubeFlow的pod，注意到最底下的2个pod，就是提供认证接口的pod。
2025-06-25 15:48:41
2165
原创 CoreDNS 配置优化实践
如果在云容器引擎集群中部署的应用容器使用了Alpine作为基础镜像，可能会因为下述musl libc特性导致无法正常解析域名，此时建议尝试更换基础镜像，如Debian、CentOS等。当集群的kube-proxy负载均衡模式为IPVS时，缩容或重启CoreDNS可能会遇到DNS概率性解析超时的问题。该问题由社区Linux内核缺陷导致，具体信息请查看社区。。。CoreDNS启动时会默认获取实例所在节点中的DNS配置而且在CoreDNS重启之前不会再重新加载该节点上的resolve.conf配置。
2025-06-24 11:02:30
3139
原创 Kubernetes CoreDNS策略配置和域名解析说明
本文介绍了在Kubernetes集群中配置Pod DNS策略的方法，主要包含四种场景：1) 使用ClusterFirst策略默认采用集群CoreDNS解析域名；2) 通过None策略自定义Pod的DNS配置；3) 使用Default策略继承节点ECS的DNS配置；4) 在HostNetwork模式下采用ClusterFirstWithHostNet策略访问集群服务。文章详细说明了每种策略的适用场景、示例配置和关键参数，并提供了集群DNS服务的基本查询方法，帮助用户根据实际需求选择合适的DNS解析方案。
2025-06-09 09:56:31
2893
原创 Kubernetes CoreDNS 概述
Kubernetes集群中的DNS解析机制主要依靠CoreDNS和NodeLocalDNSCache组件实现。CoreDNS负责解析集群内服务域名（格式为<servicename>.<namespace>.svc.<ClusterDomain>）和外部域名，作为集群默认DNS服务器运行。NodeLocalDNSCache则在每个节点部署DNS缓存，减轻CoreDNS负载并提升解析效率。集群DNS配置包含三个层面：全局的ClusterDomain设置（默认cluster.l
2025-06-06 10:40:59
2399
原创 etcd 性能 FIO测试
etcd作为一个分布式键值存储系统，其性能主要由延迟和吞吐量两个因素决定。延迟指完成操作所需时间，而吞吐量则是在特定时间内完成的操作数量。在并发客户端请求下，etcd的平均延迟会随吞吐量增加而增加。在标准云环境中，三成员etcd集群在轻负载下可实现低于1毫秒的请求完成时间，重负载下每秒可处理超过30000个请求。etcd使用Raft算法确保数据一致性和复制，其性能受网络和磁盘IO延迟限制。为提高吞吐量，etcd采用批量处理策略。此外，etcd的性能还受到MVCC存储引擎、快照、压缩和gRPC系统的影响。通过
2025-05-23 09:50:47
2479
原创 云原生|kubernetes|kubernetes的etcd集群备份策略
总结：etcd恢复还是比较快的，脚本做了一些工作，比如，停服务，因此，恢复完要先启动etcd，然后在其它节点启动etcd，最后启动kube-apiserver服务，顺序不要搞错了哦。可将备份脚本放入计划任务，实现自动备份哈，这里我就不演示啦，然后恢复的时候根据需要恢复任意天的etcd。再次强调，集群恢复是所有节点都恢复，不能只恢复一个节点，那样会劈叉的，根据每个节点的etcd配置文件修改脚本。
2025-05-13 15:04:03
3817
原创 ETCD 集群的常见问题处理(2)
本文介绍了ETCD集群在日常运维中常见问题的处理方法。ETCD是一个高可用的分布式Key/Value存储系统，使用Raft算法保持集群一致性。文章详细描述了三种常见问题的解决步骤：1）单个节点宕机的恢复，包括查看状态、摘除异常节点、重新部署和加入集群；2）超过半数节点宕机的恢复，涉及备份数据恢复、启动服务和检查状态；3）数据库空间超限的恢复，包括备份数据、获取reversion、compact、defrag和删除报警。文章还建议定时备份和压缩数据，并增加集群监控以确保服务稳定运行。
2025-05-12 10:34:09
3375
原创 Etcd 数据存储文件 配置建议和管理
etcd集群在正常服务时，成员分为Leader和Follower两种状态，确保数据强一致性。所有数据从Leader流向Follower，Follower数据必须与Leader一致，否则会被覆盖。Leader处理所有写操作，并需等待超过半数的成员确认写操作成功，而Follower可直接响应读操作。etcd采用预写式日志（WAL）记录所有数据库事务，确保数据持久化。此外，etcd定期生成数据库快照（snapshot），记录某一时间点的数据状态，以减少日志体积并辅助数据恢复。快照与WAL日志结合，可快速同步故障实
2025-05-09 17:20:32
2802
原创 Vue 生命周期详解
vue的生命周期，是vue中比较重要的知识点，在面试中也经常会被问到，所以就打算写一篇关于vue生命周期的文章。世间万物都有自己生命周期⏱，vue也有这一特点，vue的生命周期可以简单分为四个阶段：创建阶段，挂载阶段，运行阶段，销毁阶段。每个 Vue 实例在被创建时都要经过一系列的初始化过程——例如，需要设置数据监听、编译模板、将实例挂载到 DOM 并在数据变化时更新 DOM 等。❝在这个过程中会运行一些叫做生命周期钩子的函数，这给了用户在不同阶段添加自己的代码的机会❞每个阶段都有两个。
2025-05-09 11:19:58
3429
原创 Kubernetes etcd 故障恢复(1)
本文介绍了处理ETCD集群故障的步骤，包括查看集群状态、剔除故障节点、重新添加故障节点以及备份恢复集群的方法。首先，通过etcdctl命令查看集群状态，识别主节点和故障节点。接着，使用member remove命令剔除故障节点，并通过member list验证剔除是否成功。随后，详细说明了重新添加故障节点的步骤，包括清空旧数据、修改配置文件、拷贝证书以及执行member add命令。最后，文章还提供了备份恢复集群的流程，强调停止相关服务、恢复数据后重启服务的操作顺序。通过这些步骤，可以有效维护ETCD集群的
2025-05-09 11:04:05
3539
原创 Etcd 压缩整理
内存中的存储除了顺序化的记录下所有用户对节点数据变更的记录外，还会对用户数据进行索引、建堆等方便查询的操作。历史版本越多，存储空间越大，性能越差，直到etcd到达空间配额限制的时候，etcd的写入将会被禁止变为只读，影响线上服务，因此这些历史版本需要进行压缩。由于ETCD数据存储多版本数据，随着写入的主键增加历史版本需要定时清理，默认的历史数据是不会清理的，数据达到2G就不能写入，只是对给定版本之前的历史版本进行清理，清理后数据的历史版本将不能访问，但不会影响现有最新数据的访问。
2025-04-17 11:10:44
4289
原创 etcdctl工具 管理操作etcd集群 存储调整
etcd就是个分布式非关系型数据库，3 个节点组成的集群，可以容忍 1 个节点故障。生产环境中，不推荐使用单个节点的 etcd 集群。etcd 支持存储多个版本的数据，允许查询指定 key 历史版本的数据。etcd 为了控制数据总空间，会周期性的清理数据的历史版本。etcd 不支持修改旧版本的数据。etcd 中，数据以二进制的方式存储在磁盘中。#/bin/bash。
2025-04-16 10:34:12
4114
原创 Vue 局部布局 K8s项目 header部分 下拉选择框 [el-select]
整体布局写完了，那么就可以写main这部分的局部布局了，一般在做后台系统的时候，大部分时候，在做一些数据展示的时候基本上都会使用table的方式去做应该数据的展示，以及各种操作。按钮也可以放在table里面去，头部会给一些搜索的逻辑，基于什么样的条件去做一个搜索。在开发之前，先开发header，最后开发table。（也就是main里面的header）搜索之后数据就会慢慢展示出来了，然后对每条数据进行什么样的操作。
2025-04-14 09:16:46
3212
原创 Vue Kubernetes项目 局部布局面包屑 el-breadcrumb
这种一项一项手写面包屑的方法带来了很多重复性工作，比如每个页面中都需要写一遍“首页”的面包屑，所有“活动管理”下的所有页面，也都需要写一遍“活动管理”。这时如果路由需要调整，那么所有页面的面包屑都要进行修改，非常繁琐。因此如果可以自动生成面包屑，就能够减轻很多重复性工作，也方便代码维护。
2025-03-29 14:17:07
4215
转载 Kubernetes Pod OOM 和 CPU 限制
中看到的，当我们想要限制进程的资源消耗时，设置限制或请求非常重要。不过，请注意不要将总请求设置为大于实际 CPU 大小，因为这意味着每个容器都应该有一定数量的 CPU。实际上，如果所有容器使用的内存多于请求的内存，则可能会耗尽节点中的内存。通过设置不切实际的限制或过度使用，您可能不会意识到您的进程受到限制，并且性能受到影响。限制是设置节点中资源最大上限的一种方法，但需要谨慎处理，因为最终可能会导致进程被限制或终止。云应用程序中的 CPU 和内存要求变得越来越重要，因为它们与您的云成本直接相关。
2024-12-10 10:55:32
6891
原创 如何导出和导入Grafana仪表盘
您可以使用导出导入Grafana仪表盘功能对Grafana仪表盘进行备份，或将仪表盘从一个Grafana实例迁移到另一个实例中。本文介绍如何导出和导入Grafana仪表盘。
2024-12-04 15:48:39
10093
原创 CoreDNS Plugins ---＞ hosts 添加hosts解析记录
虽然格式"172.30.200.21 172.30.200.22 172.30.200.23 kubenode1"可以正常下发configmap资源，但只有第一个ip生效。通过coredns的hosts插件配置kubernetes集群的dns服务，使集群内部可通过hostname/域名访问外部服务。kubernetes集群外部有少量服务，kubernetes集群内部pod需要通过服务所在的主机的hostname访问服务。# 省略了”FILE“，"ZONES"等字段。# ping外部hostname。
2024-10-08 16:40:33
8027
原创 Alertmanager 路由匹配
2、第二种方式则基于正则表达式，通过设置match_re验证当前告警标签的值是否满足正则表达式的内容。当前告警中是否存在标签labelname并且其值等于labelvalue。1、一种方式基于字符串验证，通过设置。告警的匹配有两种方式可以选择。
2024-09-26 17:48:24
5221
原创 你真的理解 Kubernetes 中的 requests 和 limits 吗？
为了实现 Kubernetes 集群中资源的有效调度和充分利用， Kubernetes 采用requests和limits两种限制类型来对资源进行容器粒度的分配。每一个容器都可以独立地设定相应的requests和limits。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。一般来说，在调度的时候requests比较重要，在运行时limits比较重要。
2024-09-09 18:03:30
4859
原创 kubernetes Pod failed to create fsnotify watcher: too many open files
fs.nr_open: 控制单个进程可以打开的文件描述符的最大数量。单个进程的文件描述符限制可以通过 ulimit 命令来设置。单个进程能够打开的文件描述符总数的限制。当前系统可打开的最大数量指定用户可以打开的最大数量。
2024-09-06 10:20:17
5595
1
原创 prometheus cadvisor 容器相关指标
3、 container_cpu_user_seconds_total与container_cpu_system_seconds_total的总和，代表容器占用CPU的总和。6、 查询容器相关的 数据：查询所有POD的1min内CPU使用情况，用到的数据指标是k8s通过request（下限）和limit（上限）限制容器的CPU和内存的使用范围，在容器运行的过程中需要实时监控容器对cpu的使用情况。1、 容器用户态占用CPU的时间总和。
2024-09-04 10:17:25
6678
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人