DK Blog

0%

发表于： 分类于： 浏览：

Git LFS 完全指南：轻松管理 Git 仓库中的大文件

在日常开发中，你是否遇到过这样的问题：Git 仓库因为几张设计图、一个安装包而体积暴增，克隆代码需要几十分钟，git status 命令卡顿严重？如果你正在被大文件拖累 Git 仓库性能，那么 Git LFS 就是你的救星。

什么是 Git LFS？

Git LFS（Large File Storage，大文件存储）是 Git 的一个扩展工具，专门为解决 Git 对大文件支持不足的问题而设计。它的核心思路是：用轻量的「指针文件」替代实际大文件存储在 Git 仓库中，而真正的大文件则单独存储在 LFS 服务器，从而避免 Git 仓库体积膨胀，提升操作效率。

为什么需要 Git LFS？

Git 本身的设计更适合管理文本文件（如代码、配置文件），因为文本文件体积小，且 Git 能通过「差异对比」（只记录修改部分）高效存储版本历史。但面对图片、视频、安装包等大文件时，Git 会暴露明显缺陷：

  1. 仓库体积爆炸：Git 会完整保存大文件的每一个版本，几次修改后仓库可能从 MB 级膨胀到 GB 级，克隆/拉取速度极慢。
  2. 操作卡顿：git status、git commit 等命令需要扫描文件，大文件会显著拖慢这些操作。
  3. 存储浪费：重复存储大文件的多个版本，占用大量本地和远程存储空间。

而 Git LFS 正是为解决这些问题而生——它让 Git 既能管理大文件的版本，又不用承受大文件带来的性能负担。

发表于： 分类于： 浏览：

整改 Dashboard.json ConfigMap 过大导致 kubectl apply 失败问题

在实际部署 Grafana Dashboard 过程中，因 kubectl apply 会将完整配置写入 kubectl.kubernetes.io/last-applied-configuration 注释，导致 ConfigMap 的 metadata.annotations 长度超限制，出现部署报错。本文围绕「拆分 ConfigMap + 挂载到指定目录」的核心思路，提供 subPath 和 Projected 两种落地方案，同时结合 Kubernetes 官方源码解析限制本质。

一、问题核心回顾

1. 报错现象

执行 kubectl apply 创建 Grafana 相关 ConfigMap（如 grafana-dashboards-general）时，终端提示如下错误，配置创建失败：

1

ConfigMap "grafana-dashboards-general" is invalid: metadata.annotations: Too long: must have at most 262144 characters

2. 根源分析

  • kubectl apply** 的注释机制**：kubectl apply 作为 Kubernetes 声明式部署的核心命令，会自动在 ConfigMap 的 metadata.annotations 中添加 kubectl.kubernetes.io/last-applied-configuration 注释 —— 该注释会完整记录上一次 apply 时的配置内容，用于后续对比配置差异、实现增量更新。当 dashboard.json 包含大量可视化配置（如多指标面板、复杂筛选规则）时，注释携带的完整配置会让 metadata.annotations 总长度骤增。

发表于： 分类于： 浏览：

Golang 实现支持过期功能的 Map：从设计到实践

在日常的 Golang 开发中，我们经常会遇到需要缓存临时数据的场景，比如存储用户会话信息、接口请求结果等。这些数据通常不需要长期保留，若手动管理过期删除，不仅代码繁琐，还容易出现内存泄漏问题。此时，一个支持自动过期的 Map 就成了刚需。本文将带大家从零开始，设计并实现一个高性能、线程安全的过期 Map，并对核心逻辑进行深度解析。

一、需求分析：为什么需要过期 Map？

在正式编码前，我们先明确一个合格的过期 Map 应具备哪些核心能力，避免后续开发偏离需求：

  1. 自动过期：支持为键值对设置过期时间，过期后自动删除，无需手动干预；

  2. 线程安全：在高并发场景下（如多 Goroutine 读写），不会出现数据竞争问题；

  3. 高性能：读写操作耗时低，即使存储大量数据，也不会因锁竞争导致性能瓶颈；

  4. 可配置化：默认参数（如默认过期时间、清理间隔）可自定义，适应不同业务场景；

  5. 基础工具方法：提供获取活跃元素数量、手动删除键等功能，方便业务监控与调试。

二、设计思路：如何兼顾性能与安全性？

针对上述需求，我们采用以下设计方案，平衡性能、安全性与易用性：

设计要点实现方案优势
线程安全基于 sync.Map 实现sync.Map 是 Golang 标准库提供的线程安全 Map，内置原子操作，避免手动加锁的繁琐与风险
减少锁竞争分段存储（Sharding）将全局 Map 拆分为多个 sync.Map 分片，键通过哈希计算分配到指定分片，降低单个分片的竞争频率
过期清理定时清理 + 惰性删除- 定时清理：启动独立 Goroutine，按固定间隔扫描所有分片，删除过期键；- 惰性删除：获取键时先检查是否过期，若过期则立即删除，避免 “过期键残留” 问题
活跃计数原子操作（atomic.Int64）新增 / 删除键时通过原子操作更新计数，确保高并发下计数准确，且性能开销极低
可配置化选项模式（Option Pattern）通过自定义函数动态设置过期时间、清理间隔，不破坏默认参数的易用性

三、完整实现：代码与核心逻辑解析

1. 定义核心结构体与默认参数

首先定义存储过期值的结构体和过期 Map 的主体结构，同时设置默认参数（默认清理间隔 1 分钟，默认过期时间 5 分钟）：

发表于： 分类于： 浏览：

使用 Kubebuilder 开发 Helm 部署 Operator：从入门到实践

在 Kubernetes 生态中，Operator 模式已成为管理复杂应用生命周期的标准方式。本文将详细介绍如何使用 Kubebuilder 开发一个具有门禁检查功能的 Helm 部署 Operator，帮助你理解控制器调和逻辑、状态管理及事件处理等核心概念。

什么是 Operator？

Operator 是一种包装、部署和管理 Kubernetes 应用的方法，它通过自定义资源 (CR) 和控制器扩展 Kubernetes API，将领域知识编码到软件中，实现应用生命周期的自动化管理。

对于 Helm 应用来说，一个功能完善的 Operator 可以：

  • 自动处理 Helm Chart 的部署、升级和回滚

  • 实现自定义的部署门禁检查（如依赖检查、手动审批）

  • 维护应用状态并提供丰富的可观测性

  • 响应相关资源变化并自动调和状态

开发环境准备

必要工具安装 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 安装 Kubebuilder

curl -L -o kubebuilder https://github.com/kubernetes-sigs/kubebuilder/releases/download/v3.10.0/kubebuilder\_linux\_amd64

chmod +x kubebuilder && sudo mv kubebuilder /usr/local/bin/

# 安装 kustomize

go install sigs.k8s.io/kustomize/kustomize/v4@latest

# 确保已安装 Go (1.19+) 和 Docker

初始化项目 

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 创建项目目录

mkdir helm-app-operator && cd helm-app-operator

# 初始化项目

kubebuilder init --domain demo.example.com --repo demo.example.com/helm-app-operator

# 创建 API 组和版本

kubebuilder create api --group demo --version v1alpha1 --kind HelmApp

定义自定义资源 (CRD)

编辑 api/v1alpha1/helmapp_types.go 文件，定义我们的 HelmApp 资源：

发表于： 分类于： 浏览：

Kubernetes中通过ServiceAccount自动生成Kubeconfig文件

在Kubernetes集群管理中，我们经常需要为不同的用户或应用创建具有特定权限的访问凭证。本文将介绍如何通过ServiceAccount自动化创建具有只读权限的kubeconfig文件。

背景介绍

在Kubernetes中，ServiceAccount是为Pod中的进程提供身份标识的资源对象。通过RBAC授权机制，我们可以为ServiceAccount分配特定的权限。本文提供的脚本可以自动创建ServiceAccount、分配只读权限，并生成对应的kubeconfig文件。