记录一下：K8s部署SkyWalking链路追踪
本文详细介绍了在Kubernetes集群中部署SkyWalking链路追踪系统的完整流程。环境采用1个Master节点（4核6G）和2个Worker节点（4核8G），部署了SkyWalking OAP、UI、ElasticSearch等核心组件。通过Helm Chart进行部署配置，包含资源限制、存储配置等参数。后端应用集成SkyWalking agent，配置环境变量实现数据采集；前端应用通过Nginx提供服务。系统提供拓扑图、链路追踪等功能，帮助实现故障快速定位、性能瓶颈识别、服务依赖分析和容量规划，为微服务架构提供重要可观测性支持。
记录一下：Kubernetes Pod 资源配额与自动扩缩容实践
Kubernetes通过requests/limits实现资源隔离与弹性伸缩。requests为资源下界，影响Pod调度；limits为上界，CPU超限被限流，内存超限触发OOMKilled。推荐CPU requests:limits=1:2或1:1.5，内存=1:1.5或1:2。HPA基于CPU/内存利用率自动扩缩容，需配置min/max副本数、利用率阈值（如CPU 70%）、稳定化窗口防抖动，并定义扩缩策略。工作流程为Metrics Server采集指标→HPA Controller计算目标副本数→检查范围→应用策略→更新Deployment。常见问题包括HPA不生效（检查Metrics Server、等待数据）、Pod频繁扩缩（调整稳定化窗口）、新增Pod超载（优化容量与应用）。监控需通过kubectl describe hpa、top pod等命令排查。
记录一下：Redis Sentinel 哨兵机制详解与故障转移实践
Redis Sentinel通过监控、通知、自动故障转移三大核心机制解决单实例单点故障问题，实现高可用（HA）。其定期PING检测实例存活状态，通过Pub/Sub机制向客户端通知故障；主库故障时自动选举从库提升为新主，并同步其他从库。典型部署为三节点Sentinel集群加一主二从Redis架构，需合理配置监控超时、故障转移超时等参数。故障转移流程包括主观下线检测、客观下线确认、Raft算法选举Leader、选从提升、同步及事件通知。客户端需支持Sentinel模式实现读写分离。生产环境至少部署3个Sentinel节点，以保障秒级故障转移能力，是Redis高可用标准方案。
记录一下：从零搭建Kubernetes集群踩坑记录
本文记录了作者从传统运维转向Kubernetes（K8s）后，首次搭建测试集群的实践过程。环境采用1 Master+2 Node架构，配置均为4C8G CentOS7.9，选用K8s 1.24.6、Docker 20.10.21及Calico 3.24.0。核心步骤包括：关闭防火墙/SELinux/swap等基础配置；加载br_netfilter模块（避免后续报错）；安装Docker并配置；通过yum安装kubelet/kubeadm/kubectl；Master节点提前拉取镜像（注意CoreDNS镜像名称需手动修正）；执行初始化并配置kubectl；安装Calico时修改Pod网段；Node节点通过join命令入群；最终通过部署Nginx验证跨节点通信。过程中踩坑包括模块加载、镜像名称等，后续计划学习Helm、Ingress等进阶内容。
记录一下：MySQL 主从复制与 GTID 模式详解
MySQL主从复制中，GTID模式通过全局唯一事务ID解决了传统文件位置模式的数据一致性问题。传统模式在故障转移时难以确定同步位置、易产生数据分歧且需手动计算偏移量，而GTID凭借server-uuid:transaction-id的全局标识，自动跟踪已执行事务，实现故障转移时无需手动指定断点，并支持多源复制与自动转移。其核心在于GTID集合记录事务范围，配置需开启gtid-mode与enforce-gtid-consistency。生产环境建议优先采用GTID模式，配合Sentinel实现高可用，同时需关注从库延迟、复制中断等问题，通过并行复制、错误排查等手段保障稳定运行。