维克的博客

从零开始：生产级 GitLab CI 流水线搭建

Fri, 30 Oct 2026 15:59:39 +0800

本文以 Go 语言为案例，从「只做编译和测试」的最小流水线起步，逐步加上构建镜像、镜像漏洞扫描、推送 Harbor，最终形成五阶段完整生产级 GitLab CI 流水线。

下面是本文的实践路线：

最小流水线，只做 build 和 test 阶段，让流水线先简单跑通。
增加 build-image 阶段，用 Kaniko 按 Dockerfile 构建镜像。
增加 scan-image 阶段，用 Trivy 扫描镜像，有高危漏洞直接退出。
增加 push 阶段，扫描通过后把镜像推送并打上标签。
汇总：给出完整五阶段配置与生产最佳实践。

为什么从头开始一点点增加步骤?

直接给出五十行的完整配置的话，出了问题根本不知道是编译、测试、构建、扫描还是推送哪一个阶段的问题。先跑通最小闭环，每次增加一个阶段，有问题能立即验证，排查范围小，人也更有把握。

日常编写构建生产级别的流水线也建议这样一步步验证。

1. 最小流水线验证

先只配置两个 job：

build 阶段：负责编译校验，确认代码能否正常打包、是否存在语法错误。
test 阶段：运行单元测试。

这两个 job 是整个 CI 的基础，也是触发最频繁、最需要优先跑稳的部分。

1.1 为什么先只做这两步

反馈最快：编译和单元测试在同一个代码环境中运行，几秒内就能拿到结果，不依赖镜像仓库或外部服务。
成本最低：不构建镜像、不推送，也不做扫描，任何分支的提交都可以安全触发，不会产生多余产物。
优先保障代码质量：如果编译或测试失败，就不应继续执行后续的构建、扫描和推送步骤。

1.3 写配置文件

在项目根目录新建 .gitlab-ci.yml，写入下面内容：

stages:
 - build
 - test

variables:
 GO_VERSION: "1.26"

 # 国内须覆盖 GOPROXY，否则 go mod download 走 proxy.golang.org 会超时
 GOPROXY: "https://goproxy.cn,direct"
 GOSUMDB: "sum.golang.google.cn"

 # 镜像仓库地址
 HARBOR_REGISTRY: example.harbor.com
 IMAGE_NAME: ${HARBOR_REGISTRY}/devops/web-demo

 # 缓存目录
 GOMODCACHE: $CI_PROJECT_DIR/.cache/go-mod
 GOCACHE: $CI_PROJECT_DIR/.cache/go-build


# ============================================================================
# Stage 1: 服务构建
# ============================================================================
build:
 stage: build
 image: ${HARBOR_REGISTRY}/devops/golang:1.26-trixie
 variables:
 GOFLAGS: "-mod=mod"
 cache:
 key:
 files:
 - go.sum
 paths:
 - .cache/go-mod/
 - .cache/go-build/
 untracked: true
 before_script:
 - mkdir -p ${GOMODCACHE} ${GOCACHE}
 script:
 - go mod download
 - go build -o /dev/null ./...  # 只验证能否编译，不产出二进制
 - go vet ./...

# ============================================================================
# Stage 2: 单元测试
# ============================================================================
test:
 stage: test
 image: ${HARBOR_REGISTRY}/devops/golang:1.26-trixie
 cache:
 key:
 files:
 - go.sum
 paths:
 - .cache/go-mod/
 - .cache/go-build/
 untracked: true
 before_script:
 - mkdir -p ${GOMODCACHE} ${GOCACHE}
 script:
 - go mod download
 - go test -v -race -coverprofile=coverage.out ./...
 artifacts:
 when: always
 expire_in: 1 week
 reports:
 coverage_report:
 coverage_format: cobertura
 path: coverage.out
 paths:
 - coverage.out

配置说明：

Trivy 使用笔记：从安装到生产实践

Mon, 26 Oct 2026 10:41:08 +0800

1. Trivy 是什么

官方网站： https://trivy.dev/
开源仓库： https://github.com/aquasecurity/trivy

Trivy（读作 “tri-vee”）是由 Aqua Security 主导开发并开源的统一安全扫描工具，名称取自 “Trigger”，寓意快速触发安全检查。它面向整个软件供应链，可用于扫描：

容器镜像与文件系统
Git 仓库与依赖项
IaC 配置，如 Dockerfile、Terraform 和 Kubernetes 清单
SBOM
Kubernetes 集群及资源

借助统一的命令行入口，Trivy 能够发现：

操作系统及应用依赖中的已知漏洞（CVE）
容器、Kubernetes 和 IaC 配置错误
硬编码密码、令牌等泄露密钥
依赖项的许可证合规风险

Trivy 的优势在于将多种安全检查整合到一套工具中，并可轻松接入 CI/CD、DevSecOps 和 Kubernetes 等工作流，以结构化报告输出扫描结果。这样无需为不同类型的安全风险维护多套独立工具，就能在代码构建、制品发布和部署运行等阶段持续开展安全检查。

trivy <扫描目标> ─► 镜像 / 文件系统 / Git / IaC / SBOM / K8s
 ─► 漏洞 + 配置错误 + 密钥 + 许可证风险报告

2. 为什么我们需要它

2.1 供应链安全是真实风险

服务的容器镜像不是凭空造的，它由一层层基础镜像 + 一堆依赖库叠加而成。任何一个基础镜像里的老漏洞（比如某个 glibc 漏洞）、任何一个 npm install 下来的依赖带 CVE，都会原封不动带进生产环境。

Kaniko 从入门到实践

Sat, 24 Oct 2026 11:28:31 +0800

1. Kaniko 是什么

Kaniko 是一个由 Google 开源的，在容器或 Kubernetes 集群内部，直接根据 Dockerfile 构建容器镜像的工具。

它最核心的特点只有一个：不依赖 Docker daemon（守护进程），所有构建动作都在用户态（userspace）完成。这意味着你不需要在集群里跑一个 Docker 服务，也不需要挂载 /var/run/docker.sock，就可以构建出标准镜像。

2. Kaniko 解决了什么问题

在 Kaniko 出现之前，CI 里构建镜像的主流做法是 Docker-in-Docker（DinD）。即在 CI Job 里再起一个 Docker 守护进程，用它去 build。这套方案在 Kubernetes 集群里有两个致命痛点：

需要 privileged 特权模式：dind 服务容器要操控内核特性，必须给 Pod 开 privileged: true。这是很严重的安全隐患——容器可能逃逸到宿主机，很多安全策略严格的集群直接禁止。
性能差：每个 Job 都额外拉起一个完整 Docker daemon，启动慢、占用高，多任务并发时更是灾难。

Kaniko 就是为了解决这个问题而生的：不用特权、不用 daemon，在标准 K8s 集群里就能安全构建镜像。

问题	DinD（旧方案）	Kaniko
需要 privileged 特权	✅ 必须	❌ 不需要
依赖 Docker daemon	✅ 必须	❌ 完全不需要
挂载 docker.sock	✅ 需要	❌ 不需要
安全性	有容器逃逸风险	纯用户态，安全
性能开销	每个 Job 起 daemon，慢	轻量，快

Kaniko 的核心价值用一句话来说就是：在不安全、不方便跑 Docker daemon 的环境（尤其是 K8s 集群）里，仍然能安全、快速地构建镜像。

GitLab CICD 入门指南

Thu, 22 Oct 2026 10:02:12 +0800

1. 简介

1.1 GitLab CI/CD 是什么？

GitLab CI/CD 可以理解为：GitLab 内置的持续集成 / 持续交付引擎。代码提交、合并请求、打标签或定时触发后，GitLab 会根据项目里的 .gitlab-ci.yml 生成流水线，再交给 GitLab Runner 去执行构建、测试、扫描、打包、部署等任务。

它的整体架构可以分成三层：

层级	组件	作用
控制层	GitLab Server	解析 `.gitlab-ci.yml`，生成 Pipeline，分发 Job，展示结果
执行层	GitLab Runner	从 GitLab 拉取任务，执行脚本，回传日志和产物
环境层	Executor	决定 Job 跑在哪里，比如 Docker、Kubernetes、Shell、SSH 等

一个典型的 Gitlab CICD 执行链路如下所示：

开发者 push 代码或创建 MR，触发流水线
 ↓
GitLab 读取仓库里的 .gitlab-ci.yml，生成 Pipeline 流水线作业
 ↓
Runner 轮询到待执行的任务，领取 Job
 ↓
Job 的 Tag 会和 Executor 的 Tag 进行匹配，匹配成功后，Executor 去执行 Job
 ↓
执行完成后，日志、制品、状态回传到 GitLab，在页面上可以查看结果

1.2 如何定义流水线？

一个流水线本质上由两个核心概念构成：

JavaScript 基础知识

Tue, 20 Oct 2026 17:13:23 +0800

1. JavaScript 是什么

JavaScript（简称 JS）是一门动态类型、多范式的编程语言。它最初为浏览器而生，如今已覆盖浏览器、服务器（Node.js）、桌面应用、移动端等环境。

几个关键特征：

解释执行：不需要编译，引擎直接逐行运行。
动态类型：变量类型在运行时确定，无需声明。
一等函数：函数可以像值一样传递、赋值、作为参数。
基于原型：对象继承通过原型链实现，而非传统类继承（ES6 提供了 class 语法糖）。

注意：JavaScript 与 Java 是两门完全不同的语言，仅名字有历史渊源关系。

2. 运行环境

写 JS 代码前，需要一个运行环境。

2.1 浏览器环境

打开任意浏览器（Chrome / Edge / Firefox），按 F12 打开开发者工具，切换到 Console（控制台）标签，即可直接输入并运行 JS 代码：

a="zhangsan";
console.log("Hello ",a);

也可以在 HTML 文件中通过 <script> 标签引入：

<!DOCTYPE html>
<html>
<body>
 <script>
 console.log("页面加载时执行");
 </script>
</body>
</html>

2.2 Node.js 环境

Node.js 是一个免费、开源、跨平台的 JavaScript 运行时环境，它让开发人员能够创建服务器、 Web 应用、命令行工具和脚本。

安装后，在终端执行：

node -v # 查看版本
node hello.js # 运行文件

// hello.js
console.log("Hello from Node.js");

注意：浏览器和 Node.js 共享 ECMAScript 核心语法，但宿主 API 不同。浏览器有 window、document；Node.js 有 fs、path、process。

Gitlab 备份恢复和版本升级

Mon, 12 Oct 2026 19:32:50 +0800

1. gitlab 数据备份

1.1 数据备份

GitLab 提供一条命令 gitlab-backup create，运行命令后会产出一个压缩 tar 归档，包含数据库、Git 仓库与 LFS、CI/CD artifacts、Wiki、附件上传、Pages、注册表等。但它不包含配置文件、密钥、Redis 队列和对象存储，这些要另行处理。

官方提示至少必须单独备份 /etc/gitlab/gitlab-secrets.json（内含数据库加密密钥，丢失后无法解密两步验证和 CI 安全变量）与 /etc/gitlab/gitlab.rb。建议连同 /etc/gitlab/trusted-certs一起备份，避免整机恢复时出现中间人警告。

1.2 执行备份

Omnibus 包安装的环境下，可以直接调用官方封装命令：

gitlab-backup create

归档默认生成在 /var/opt/gitlab/backups/，文件名一般是这个样子： 1730000000_2026_10_12_17.5_gitlab_backup.tar。

可以在 /etc/gitlab/gitlab.rb 中调整文件保存路径和时间:

# 备份保留7天
gitlab_rails['backup_keep_time'] = 604800

# 备份目录配置
gitlab_rails['backup_path'] = "/var/opt/gitlab/backups"

修改后执行 gitlab-ctl reconfigure。

需要排除某类数据时用 SKIP，例如跳过 CI 输出日志：

gitlab-backup create SKIP=builds,artifacts

1.3 生产备份策略

策略	做法	为什么
定时执行	用 cron 每天/每周触发 `gitlab-backup create`	备份频率决定最多可丢失多少数据（RPO）
异地/对象存储	把 tar 归档拷贝到另一台机器或对象存储（支持 S3 等 remote 配置）	单机磁盘故障时本地归档同样会丢
配置密钥单独备	定期打包 `/etc/gitlab` 到加密存储	密钥丢失=数据库无法解密，归档也无意义
定期恢复演练	在测试机用备份实际恢复一次	没验证能恢复的备份等于没有备份

提示：

Gitlab 入门和生产部署实践

Mon, 12 Oct 2026 14:51:37 +0800

1. 什么是 GitLab

GitLab 是一款开源的 Git 代码托管平台，支持私有化部署，被众多企业用于搭建内部代码仓库。与 GitHub 主打开源协作不同，GitLab 更聚焦于代码托管和研发流程自动化，原生提供 CI/CD、代码评审、权限管控、镜像仓库、日志审计等能力。

GitLab 主要分为两个版本：

CE 社区版：免费开源，基本能满足 95% 中小企业的生产需求（本文案例）；
EE 企业版：付费使用，提供高可用架构、高级安全扫描、集群权限管控以及官方技术支持，比较适合大厂落地。

总之，对企业来说，GitLab 的核心价值主要体现在四个方面：代码内网私有化存储、研发流程标准化、流水线自动化、操作可审计追溯。

2. 三种部署方式（选型）

Omnibus 包部署（生产首选）：官方推荐的标准生产部署方案，以一键安装包形式提供，支持主流 Linux 发行版。内置 PostgreSQL、Redis、Gitaly、Web、Sidekiq 等核心组件，部署路径清晰、运维成本较低、稳定性较高，是生产环境中最稳妥的选择。
K8s 混合部署（不推荐新人尝试）：面向大规模高并发场景时，官方推荐采用混合架构，将 Web、Sidekiq 等无状态组件部署在 Kubernetes 中，便于弹性扩缩；Gitaly、数据库、缓存等有状态服务则保留在虚拟机或独立节点上部署，以保证存储和数据的稳定性。不建议新手直接使用 Kubernetes 全组件部署 GitLab。有状态组件在容器环境中的存储管理、备份恢复和升级复杂度较高，生产风险较大。
Docker 单容器部署（仅测试用）：Docker 单容器部署启动快、上手简单，但在数据持久化、备份恢复、版本升级和高可用方面能力有限，仅适合本地测试、功能验证或演示环境，不建议用于生产。

3. 安装 GitLab

官方安装文档

3.1 前置硬件&系统要求

仅支持 linux，最低配置：4核8G（10人以内小团队），生产推荐 8 核 16G 及以上；
关闭 SELinux 或 AppArmor，否则可能影响服务正常运行；
存储优先用 SSD；不建议用 NFS、EFS、Azure Files 这类网络文件系统放仓库数据；
开放端口：80(http)、443(https)、22(ssh)。

3.2 添加 apt 源安装

# 更新系统依赖
sudo apt update && sudo apt upgrade -y

# 安装必备依赖
sudo apt install -y curl openssh-server ca-certificates tzdata

# 添加 GitLab 官方 APT 源
sudo curl --location "https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh" | sudo bash

# 安装 GitLab 社区版（默认启动初始化）
sudo apt install gitlab-ce -y

3.3 离线包（无网络环境使用）

官方离线包下载地址

ArgoCD 入门和生产实践指南

Sat, 10 Oct 2026 09:33:28 +0800

1. 什么是 ArgoCD

ArgoCD 是 CNCF 毕业级项目，面向 Kubernetes 的声明式 GitOps 持续交付工具。

GitOps 核心思想：Git 仓库作为应用配置的唯一可信源。ArgoCD 持续监听 Git 仓库内定义的应用目标状态，对比集群内资源的实际运行状态，自动完成应用部署、版本更新与故障回滚。

ArgoCD 原生支持多种配置编排方式：Helm Chart、Kustomize、Jsonnet、Ksonnet，以及原生 YAML/JSON Kubernetes 资源清单。

2. 架构原理

ArgoCD 以 Kubernetes 控制器形态运行，持续对应用做状态巡检：

拉取 Git 仓库中声明的期望状态（Target State）
采集集群内资源实际运行状态（Live State）
对比两者差异，不一致时标记为 OutOfSync（不同步）
可视化展示资源差异，支持手动同步 / 自动同步，将集群状态收敛到 Git 定义的目标状态

Git 仓库中修改清单后，ArgoCD 会感知变更并同步至目标集群，实现“改 Git 即发布”。

具体工作流程参见下面的图片：

核心组件:

组件	核心作用
`argocd-server`	ArgoCD API 服务，提供 REST API、Web UI，处理认证鉴权
`argocd-repo-server`	Git 仓库管理服务，缓存仓库代码、渲染 Helm/Kustomize 生成K8s清单
`argocd-application-controller`	应用控制器，持续做状态比对，执行同步、健康检查
`argocd-applicationset-controller`	ApplicationSet控制器，批量、模板化管理多环境/多集群 Application
`argocd-redis`	缓存组件，存储仓库缓存、应用状态信息
`argocd-dex-server`	可选，Dex 身份代理，对接OIDC、LDAP等外部身份源
`argocd-notifications-controller`	可选，通知控制器，同步状态变更推送至邮件、Slack、Webhook等

3. 部署

部署前建议查阅官方版本兼容矩阵，选择与K8s集群匹配的ArgoCD版本。

Kubespray 部署和维护 K8s 集群指南

Fri, 09 Oct 2026 11:34:13 +0800

1. 简介

Kubespray 是 Kubernetes SIGs 官方维护的部署项目，本质是一套经过大量生产环境验证的 Ansible Playbook、Inventory 模板和角色集合。它不发明新的集群模型，而是把 kubeadm 引导、etcd 集群组建、CNI 安装、证书轮换、节点扩缩容与升级这些容易出错的步骤固化为可重复执行的代码。

1.1 Kubespray 解决了什么问题

手动搭一个生产集群的工作量并不仅仅只是简单把 K8s 集群跑起来，而在于：

etcd 节点集群的证书、成员管理、快照备份；
多控制平面节点下 apiserver 的负载均衡与前端证书 SAN；
kubelet 配置（cgroup 驱动、预留资源、镜像垃圾回收、最大 Pod 数）；
CNI 插件与内核网络参数、iptables/nftables 后端的匹配；
证书到期轮换、跨小版本顺序升级、节点下线清理。

这些工作做一次可以靠文档，做十次就得靠自动化。Kubespray 的价值就在于它把这些工程细节沉淀成了一套符合生产环境最佳实践的可重复执行代码，你只需要在默认值的基础上少量改动，而不是自己编写和维护大量的脚本。

1.2 和其他工具对比

工具	Kubespray	kubeadm	Rancher	OpenShift(OKD)	kops	KubeKey(kk)	k3s
核心定位	Ansible驱动，生产级离线部署K8s集群	K8s官方最小化集群引导工具	企业级K8s全生命周期管理平台	红帽出品，基于K8s的企业容器平台	AWS专用K8s集群部署工具	KubeSphere社区开源部署工具，中文友好	Rancher出品轻量K8s发行版
底层引擎	Ansible	Go原生二进制	容器+WebUI	容器/Operator	Go，调用AWS API	Go二进制，封装kubeadm	裁剪K8s单二进制
适用环境	裸金属、VMware、私有云、离线环境	裸金属/虚拟机/云主机，在线为主	公有云、私有云、边缘，多集群统一管理	企业私有/混合云，偏向生产企业	仅限AWS公有云	裸机/虚拟机，私有化离线场景	低配服务器、边缘、开发/小生产
离线部署	✅ 完美支持，可打包离线介质	⚠️ 支持但麻烦，需要手动下载镜像/二进制	✅ 支持离线airgap安装	✅ 官方提供离线方案	❌ 依赖AWS云API，不适合离线	✅原生支持打包离线包	✅离线包
集群维护	Ansible playbook升级、扩容、替换节点；版本升级稳定	仅引导集群，不负责后续集群运维，升级操作繁琐	Web界面一键升级、扩缩容，多集群统一监控告警	Operator管理集群，自动化运维能力强	集群升级、节点替换由kops命令管理	一键HA、扩容升级，可配套KubeSphere控制台	一行命令运维，嵌入式etcd HA
高可用	✅ 内置etcd三副本、控制面HA方案	需要手动搭建HA（负载均衡+多master）	✅ 自动支持HA，内置负载均衡方案	✅ 默认HA架构	✅ AWS上自动搭建控制面HA	✅一键HA，内置负载均衡	✅内置HA（嵌入式etcd）
网络插件	内置Calico/Flannel/Cilium等多种CNI可选	仅提供基础CNI对接，需自行部署CNI	内置多种CNI，UI可视化配置	默认OVN-Kubernetes，也可Calico	默认Calico，可自定义CNI	Calico等CNI可选	Flannel默认，支持替换CNI
存储支持	对接本地卷、Ceph、Longhorn等，ansible角色集成	仅提供CSI标准，存储需要自己部署	内置存储管理，支持Longhorn等	内置CSI+本地存储方案	对接AWS EBS等云存储	对接Longhorn、Ceph、本地存储	支持本地存储、CSI
版本适配	紧跟K8s社区版本，滞后一小段时间	K8s官方同步发布	支持多K8s版本，统一纳管不同版本集群	OKD版本独立，和上游K8s有差异	紧跟AWS支持的K8s版本	跟随上游kubeadm	Rancher维护稳定版本
学习成本	中等，需要懂Ansible	低，上手简单，适合测试集群	低，WebUI友好，运维门槛低	高，体系庞大，有专属概念	中等，熟悉AWS即可快速上手	中等，中文文档友好	很低，上手极快
典型场景	裸金属机房、私有化项目、需要批量部署大量集群、等保离线环境	实验室、POC测试、小规模简单集群	多集群管理、混合云、需要统一权限/审计的企业	大型企业生产环境，需要完整容器安全、合规能力	AWS云上快速搭建销毁K8s集群	中小企业裸机/VM离线部署，可选KubeSphere控制台	资源有限、边缘、小生产集群
缺点	Ansible串行执行，大规模集群部署慢；无WebUI；故障排查需要Ansible基础	没有集群生命周期管理，生产HA搭建工作量大；缺少监控日志等附加组件	资源开销大；底层K8s被封装，深度定制复杂；商业版收费	闭源企业版昂贵；架构重，资源消耗高；学习曲线陡峭	只能跑在AWS，无法裸金属/其他云使用	依赖kubeadm；底层封装，深度排障需要kubeadm知识；KubeSphere额外耗资源	裁剪部分组件，重型大规模生产不推荐；和标准K8s有细微差异
国内中小企业热度	⭐⭐⭐ 更多集成商使用，中小企业自用偏少	⭐⭐⭐⭐⭐ 最高，几乎所有运维都学这个	⭐⭐⭐⭐ 多集群场景热门	⭐⭐ 大型企业为主，中小企业很少用	⭐ 国内几乎不用	⭐⭐⭐⭐ 私有化中小企业热门	⭐⭐⭐⭐ 小集群/边缘场景热门

2. 底层架构和设计

关键核心设计：

Harbor 私有镜像仓库安装部署和最佳实践

Sat, 03 Oct 2026 11:32:44 +0800

1. 简介

Harbor 是 CNCF 托管、VMware 开源的企业级容器镜像仓库，基于 Docker Registry 二次开发。除基础镜像存储能力外，还提供 Web UI、细粒度RBAC权限、镜像漏洞扫描、垃圾回收、镜像复制同步、审计日志等企业级能力，是 Kubernetes 集群离线部署、容器镜像统一管理的核心组件。

适用场景：企业内网私有镜像托管、Kubespray 离线集群镜像分发、CI/CD流水线镜像仓库。

官方参考文档：

Harbor 官方安装指南：https://goharbor.io/docs/2.8.0/install-config/
Harbor HTTPS 证书配置文档：https://goharbor.io/docs/main/install-config/configure-https/
Harbor 版本生命周期与版本策略：https://goharbor.io/docs/main/install-config/versioning/
Harbor 备份恢复官方文档：https://goharbor.io/docs/main/administration/backup-restore/
Harbor 生产环境最佳实践：https://www.cncf.io/blog/2026/02/24/making-harbor-production-ready-essential-considerations-for-deployment/
Harbor 官方 Trivy 文档：https://goharbor.io/docs/2.14.0/scan/
Trivy 官方文档：https://aquasecurity.github.io/trivy/

2. 前置环境准备

2.1 Harbor版本选型指南

当前最新版已经到 v2.15.x，很多人会直接选用最新版，但不建议生产直接上最新大版本。

Harbor版本命名规则：主版本.次版本.补丁号，例如 2.10.2、2.15.0

奇数小版本（2.11、2.13、2.15）：新特性版本，引入新功能、重构模块；bug相对多，适合测试体验，不推荐生产直接使用。
偶数小版本（2.10、2.12、2.14）：长期维护稳定分支，重点修复漏洞，新增功能保守，生产首选。

举例：

v2.15.x：新特性版，适合尝鲜、学习测试；
v2.14.x：当前最新稳定偶数版；
v2.10.x：久经大规模生产验证，bug少，社区问题资料极多，如果不需要新版本的一些新特性的话，推荐使用。

企业生产环境：优先选择偶数LTS稳定分支，发布至少3个月以上，积累足够补丁。不要选用刚发布的 .0 首版（例如 2.15.0），这类版本会存在较多未发现的bug。

2.2 基础依赖

Harbor 基于 Docker Compose V2 编排运行，提前准备依赖环境：

Docker Engine：20.10+
Docker Compose V2
系统架构：amd64 / arm64 均可支持（OrbStack、VMware虚拟机均可正常运行）
硬件资源：测试环境≥2核4G；生产环境≥4核8G，推荐SSD存储提升镜像读写性能

3. Harbor 离线安装流程

离线包稳定性高于在线安装，内网、离线集群优先选用。本文部署以v2.14.4版本为例。

Go 语言中的 Slice 类型

Wed, 30 Sep 2026 15:55:22 +0800

Slice（切片）是 Go 语言内置的可变长度序列，属于引用类型，基于底层数组封装实现，解决数组长度固定、数组传参完整拷贝开销大的问题，是 Go 开发最常用的数据结构之一。

1. Slice 的基础特性

可变长度：长度不固定，可通过 append 动态追加元素。
底层数组共享：切片本身不存储实际元素，元素存放在底层数组；多个切片可以指向同一个底层数组，修改会互相影响。
len 与 cap 分离：len代表切片当前可用元素个数；cap代表底层数组允许的最大容量。
零值特性：切片零值为 nil，nil slice len=0、cap=0；nil slice 和空切片 []int{} 不相等。
引用语义：切片变量存储的是结构体头信息，赋值、传参拷贝的是切片头，不是底层数组。
不可直接比较：切片不能使用 == 判断两个切片内容是否相等，仅允许和 nil 做相等判断。

友情提示

上述特性与 Slice 的底层实现紧密关联，建议结合第 4 节"Slice 底层实现原理"章节阅读，以获得更深入的理解。

2. Slice 的四种初始化方式

切片必须初始化，nil切片可以读取、append，但不能直接对索引位置赋值。

2.1 声明未初始化（nil slice）

仅定义变量，底层数组指针为 nil，len=0、cap=0。

// 声明nil切片，未分配底层数组
var a []string
fmt.Println(a == nil) // true
fmt.Println(len(a), cap(a)) // 0 0

// a[0] = "hello"
// 未初始化的切片直接赋值会引发 panic
// panic: index out of range

2.2 字面量初始化（空切片/带初始值）

直接初始化，分配底层数组，支持空切片和预设元素。

Go 语言中的 Map 类型

Mon, 28 Sep 2026 13:01:24 +0800

Map 是 Go 语言内置的键值对（key-value）哈希集合，属于引用类型，核心作用是通过唯一键快速索引对应值，查询、插入、删除的平均时间复杂度均为O(1)，是 Go 开发中最常用的数据结构之一。

1. Map 的基础特性

键唯一性：同一个 Map 中，key 唯一，重复插入会覆盖旧值。
键类型限制：key 必须是可比较类型（int、string、bool、结构体等），切片、map、函数不可作为 key。
无序性：Map 不存储键值对插入顺序，遍历顺序随机（Go 1.12+ 每次遍历顺序不一致）。
零值特性：Map 零值为 nil，nil map 无法写入数据，仅可读取。
引用类型：赋值、传参仅传递引用，多个变量指向同一个底层数据

2. Map 的四种初始化方式

Go 语言 Map 必须初始化后才能写入数据，未初始化的nil map直接写入会触发运行时 panic。以下是所有合法初始化方式。

2.1 声明未初始化（`nil map`）

仅定义变量，未分配内存，零值为nil，只能读、不能写。

package main

import "fmt"

func main() {
 // 声明nil map，未初始化
 var m map[string]int
 fmt.Println(m == nil) // 输出：true

 // m["a"] = 1
 // 报错：panic: assignment to entry in nil map
}

2.2 字面量初始化（空 Map/带初始值）

直接初始化并分配内存，支持空 Map 和预设键值对，最常用。

Go 语言中的字符串类型

Fri, 25 Sep 2026 10:01:44 +0800

Go 原生支持字符串类型，关键字string用于表示字符串数据类型。

1. 底层实现

Go 中的string实际上是一个struct类型，其本身并不真正存储字符串数据，仅是由一个指向底层数组的指针和字符串的长度字段组成，可以在标准库的reflect包中，找到下面代码：

// $GOROOT/src/reflect/value.go

// StringHeader是一个string的运行时表示
type StringHeader struct {
 Data uintptr
 Len int
}

由于string类型实际上只是一个对底层存储的引用，因此实际传参的开销非常小，另外在生成string变量时，会同时存储字节长度len，所以无论字符串长度怎么变化，获取长度的时间都是O(1)。

底层实现图解：

三个必须记住的特性：

特性	含义
不可变	任何“修改”操作都会产生新字符串，原串不变
UTF-8 编码	源码中的字符串字面量默认是 UTF-8
零值是 `""`	不是 nil，`var s string` 是空串

var s string = "Hello"
// s[0] = 'h' // 编译错误：cannot assign to s[0]
b := []byte(s) // 想修改就转成切片（会复制一份）

注意：len(s)返回的是字节数，不是字符数。中文、emoji 等多字节字符会让两者不相等。

2. 字面量与引号

Go 中初始化字符串变量，需要在双引号"中定义值，单引号'用于单个字符（以及 runes ）。

var Name string = "zhangsan"
age := "18"
var a char = 'a'

s1 := "hello\nworld" // 双引号：支持 \n \t \" \\ 等转义
// 输出：
// hello
// world

s2 := `hello\nworld` // 反引号（原生字符串）：原样保留
// 输出：
// hello\nworld

s3 := "" // 空串，len == 0

Go 中没有也不支持三引号的写法，使用反引号来表示原生字面量。由于所见即所得，原样保留，可跨行的特点，常用于SQL/JSON/正则表达式中

Go 语言中的循环控制

Wed, 23 Sep 2026 10:36:31 +0800

Go 语言只有一种循环构造方式，即 for 循环（没有 while 或 do-while），类似于 C、Java 和 C# 之类的编程语言中的 for 循环。使用分号;分隔。。它的基本语法如下：

for 初始化语句; 条件表达式; 后置语句 {
 循环体
}

执行顺序

初始化语句：在循环开始前执行，且只执行一次（如 i := 0）。
条件表达式：在每次迭代前求值。如果为true，进入循环体；如果为false，循环直接结束。
循环体：条件为真时执行。
后置语句：在每次循环体执行结束后执行（如 i++），然后回到第 2 步重新判断条件。

1. 基本语法

for循环的三个组件：

在第一次迭代之前执行的初始语句（可选）。
在每次迭代之前计算的条件表达式，该条件为false时，循环会停止退出。
在每次迭代结束时执行的后处理语句（可选）。

func main() {
 sum := 0
 for i := 1; i <= 100; i++ {
 sum += i
 }
 fmt.Println("sum of 1..100 is", sum)
}

2. 只使用表达式的 for 循环

某些编程语言中，可以使用 while 关键字编写循环，而 Go 没有 while 关键字。但是可以改用 for 循环实现相同的效果。

package main

import (
 "fmt"
 "math/rand"
 "time"
)

func main() {
 var num int64
 rand.Seed(time.Now().Unix())
 for num != 5 {
 num = rand.Int63n(15)
 fmt.Println(num)
 }
}

3. 无限循环和 break

更进一步，当 for 循环连表达式都不编写的情况就是无限循环，这时想要退出循环必须使用 break 关键字。

K8s MetaLB 详解

Wed, 16 Sep 2026 13:59:57 +0800

在 Kubernetes 集群中，Service 是核心资源之一，其中 LoadBalancer 类型服务是业务对外暴露的核心方式。但原生 K8s 仅为公有云集群（AWS、阿里云、腾讯云等）提供 LoadBalancer 实现，裸金属、本地机房、私有部署的 K8s 集群默认不支持 LoadBalancer 类型 Service，只能依赖 NodePort、Ingress 实现流量暴露，存在端口散乱、运维复杂、无统一入口、负载均衡能力薄弱等问题。

MetalLB 正是这样一款专为私有/裸金属K8s集群设计的开源负载均衡组件，完全开源免费、轻量无侵入，完美补齐了私有 K8s 集群无原生 LoadBalancer 的短板，是本地机房 K8s 生产集群的标配组件。

1. 项目介绍

1.1 项目定位与核心作用

MetalLB 是 Kubernetes官方认可的负载均衡解决方案，专为非云环境（裸金属服务器、虚拟机、本地私有集群）设计。其核心作用是：为集群内 LoadBalancer 类型的 Service 自动分配外部静态 IP，实现四层流量负载均衡，替代原生 NodePort 的低效暴露方式，让私有集群拥有与公有云一致的 Service 负载均衡能力。

核心价值：

统一业务暴露方式：与公有云 K8s 开发规范对齐，无需适配 NodePort 特殊逻辑。
稳定四层负载均衡：支持 TCP/UDP 协议，适配后端服务、数据库、中间件等各类业务。
简化运维：固定服务外部 IP，无需节点端口映射，流量入口统一可控。
轻量高性能：无复杂依赖，资源占用极低，不侵入 K8s 核心组件。

1.2 架构原理

MetalLB 采用控制器 + 转发节点的分布式架构，整体由两大核心组件组成，全部运行在集群内部，以 Pod 形式部署。

1.2.1 Controller（控制器组件）

全局唯一的调度组件，默认单副本部署，核心职责：

监听集群内所有 LoadBalancer 类型的 Service 资源变更。
维护 IP 地址池，为新的 LoadBalancer Service 自动分配可用外部 IP。
回收废弃 Service 的 IP 资源，避免 IP 泄露与占用。
校验 IP 分配合法性，保证全局唯一性。

1.2.2 Speaker（转发组件）

集群节点级组件，默认每个集群节点部署一个Pod（DaemonSet部署），核心职责：

Pod 网络故障排查

Sat, 12 Sep 2026 15:51:54 +0800

Kubernetes 的网络是一个多层虚拟网络体系，流量从客户端到后端 Pod 的路径涉及多个组件。排查网络问题时，如果"东戳一下西戳一下"没有章法，可能需要耗费大量时间。如何最快的定位网络问题的根源？记住常见的具体现象和应对办法，遵循从内到外的原则（先确认"自己没问题"，再确认"中间没问题"，最后确认"外面没问题"）或许能够帮你节约大量的时间，。

下面按照从具体访问现象出发的思路，由浅入深展开。

1. 第一层：Pod 自身状态确认

现象：Pod 完全无法访问，任何请求都无响应 这是最基础的一层。在排查任何网络问题之前，先确认 Pod 本身是否健康运行。

1.1 检查 Pod 状态

kubectl get pods -o wide

关注以下状态：

状态	含义	可能原因
`Running`	正常运行	正常
`Pending`	等待调度	资源不足、节点亲和性不匹配
`CrashLoopBackOff`	反复崩溃重启	应用启动失败、配置错误
`OOMKilled`	内存超限被杀	`resources.limits.memory` 设置过低
`ImagePullBackOff`	镜像拉取失败	镜像名错误、仓库认证失败
`ContainerCreating`	容器创建中	CNI 插件分配 IP 失败、存储卷挂载失败

如果 Pod 不在 Running 状态，网络问题只是表象，根因在 Pod 本身：

# 查看 Pod 详细事件
kubectl describe pod <pod-name> -n <namespace>

# 查看容器日志（如果容器曾启动过）
kubectl logs <pod-name> -n <namespace>

# 查看前一个崩溃容器的日志
kubectl logs <pod-name> -n <namespace> --previous

1.2 确认 Pod 有 IP 地址

kubectl get pods -o wide

如果 Pod 状态是 Running 但 IP 为空，说明 CNI 插件没有成功分配 IP。此时需要检查：

K8s 集群升级

Wed, 09 Sep 2026 14:26:14 +0800

Kubernetes 集群的大版本（跨次要版本）升级是一项复杂且高风险的运维操作。为了确保业务连续性，必须遵循严格的规范。以下是升级的核心原则、标准流程以及可能遇到的关键问题。

1. 大版本升级的核心原则

逐级递进，严禁跨版本：Kubernetes 不支持跨多个次要版本直接升级（例如不能从 1.24 直接升级到 1.26），必须按照1.24 → 1.25 → 1.26的顺序逐版本进行。每一跳都需要完成控制面和节点的升级与验证。
组件版本兼容策略：
- 控制面：kube-apiserver 版本最高且需最先升级，controller-manager 和 scheduler 版本应小于或等于 apiserver。
- kubelet：节点上的 kubelet 版本必须小于或等于 apiserver，且不能低于 apiserver 的前一个次要版本（例如 apiserver 为 v1.28 时，kubelet 可以是 v1.28 或 v1.27）。
先升级控制面，再升级节点：必须先完成 Master 节点（控制平面）的升级，确认稳定后再分批升级 Worker 节点。
第三方组件兼容性检查：升级前必须确认 CNI 插件（如 Calico/Cilium）、CoreDNS、kube-proxy 以及 Ingress 控制器等是否支持目标版本。通常建议先升级 CNI，CoreDNS 则与 K8s 版本强绑定，需查阅官方对应表。

2. 标准升级流程

升级前准备：
- 检查集群健康状态，确保所有节点为 Ready，无 CrashLoopBackOff 的 Pod。
- 备份关键数据：必须备份 etcd 数据、证书文件及核心配置文件，以防升级失败导致数据丢失。
- 检查并处理废弃 API（Deprecated APIs），高版本可能会移除旧版 API，导致 HPA 或 Ingress 等资源失效。
升级控制面：升级 kubeadm，执行 kubeadm upgrade apply，依次更新 kube-apiserver、kube-controller-manager 和 kube-scheduler。
升级工作节点：
- 腾空节点（Cordon & Drain），将 Pod 驱逐到其他节点。
- 升级节点的 kubeadm、kubelet 和 kubectl。
- 解除节点保护（Uncordon），使其重新加入调度。
- 建议在生产环境中逐个节点离线升级后再上线，避免全部同时升级。

3. 升级过程中可能遇到的问题

废弃 API 导致业务失效：高版本 K8s 会废弃旧版 API。例如升级到 1.22+ 时，networking.k8s.io/v1beta1 的 Ingress 将不再可用；升级到 1.18+ 后，HPA 的 apiVersion 必须切换为 apps/v1，否则功能会失效。
容器运行时变更：从 Kubernetes 1.24 开始，不再支持将 Docker 作为内置容器运行时。若从 1.22/1.23 升级，必须提前将节点运行时从 Docker 迁移到 containerd，否则升级会失败。
节点排水（Drain）失败与 PDB 冲突：在驱逐 Pod 时，如果配置了 Pod Disruption Budget (PDB) 且当前可用副本数达到下限，Pod 将无法被驱逐，导致节点升级超时或失败。
网络连通性中断：如果 Pod 通过 LoadBalancer 类型的 Service 访问同节点上的另一个 Pod，且 Service 的 externalTrafficPolicy 设置为 Local，在节点轮转升级后，两个 Pod 可能不再位于同一节点，导致网络不通。
自定义配置被覆盖：如果曾通过非产品化方式（如直接登录节点修改 kubelet 配置、打开 SWAP 分区等）更改过节点配置，升级过程中这些自定义配置可能会被重置或覆盖，甚至导致升级失败。
磁盘空间不足：升级过程需要下载软件包并可能产生临时文件。如果节点磁盘水位过高（建议预留至少 20% 空间），可能导致 Pod 被驱逐或升级失败。
Cgroup v1 兼容性问题：在较新的版本（如 1.36）中，kubelet 默认仅支持 Cgroup v2。如果节点操作系统仍在使用 Cgroup v1，可能会导致 kubelet 启动失败或节点 NotReady。

Kubeadm 部署高可用 K8s 集群

Wed, 09 Sep 2026 10:54:51 +0800

kubeadm 安装官方文档

0. 引言

Kubernetes 高可用架构的核心在于保障 API Server 的访问连续性与 etcd 的数据可靠性。通常通过部署多 Master 节点并前置负载均衡来实现，本方案采用 kube-vip 承担此角色。为节省资源，本文将负载均衡与 etcd 集群复用部署于 Master 节点；生产环境请务必将其独立部署，以确保集群稳定性。

本文基于 Ubuntu 24.04 环境编写。若使用其他 Linux 发行版，请根据实际情况自行调整相关命令。

1. 环境架构

1.1 角色划分

主机名	IP	角色
master01	192.168.69.11	master01、Etcd-node01、kube-vip 节点
master02	192.168.69.12	master02、Etcd-node02、kube-vip 节点
master03	192.168.69.13	master03、Etcd-node03、kube-vip 节点
worker01	192.168.69.21	worker01
worker02	192.168.69.22	worker02
worker03	192.168.69.23	worker03
虚拟IP	10.0.0.100	kube-vip 提供

1.2 拓扑图

2. 操作系统初始化

2.1 Linux 基础配置

# 关闭防火墙
ufw disable

# 关闭 swap
swapoff -a && sysctl -w vm.swappiness=0
sed -ri 's/.*swap.*/#&/' /etc/fstab

# 配置主机名和 hosts
hostnamectl set-hostname <hostname>
cat >> /etc/hosts << EOF
192.168.69.11 master01.wuvikr.top master01
192.168.69.12 master02.wuvikr.top master02
192.168.69.13 master03.wuvikr.top master03
192.168.69.21 worker01.wuvikr.top worker01
192.168.69.22 worker02.wuvikr.top worker02
192.168.69.23 worker03.wuvikr.top worker03
192.168.69.100 kubeapi.wuvikr.top kubeapi
EOF


# 配置 limit
ulimit -SHn 65535

# 持久化 limit 配置（重新登录后生效）
cat >> /etc/security/limits.conf << EOF
* soft nofile 65536
* hard nofile 131072
* soft nproc 65535
* hard nproc 655350
* soft memlock unlimited
* hard memlock unlimited
* soft core unlimited
* hard core unlimited
EOF

2.2 时间同步

# 同步硬件时钟到系统时间（虚拟机环境中可选）
hwclock -s

# 设置时区（推荐方式，一步完成）
timedatectl set-timezone Asia/Shanghai

# 确保时间同步服务已启用（Ubuntu 24.04 默认已启用）
systemctl enable --now systemd-timesyncd

# 查看时间同步状态
timedatectl status

Ubuntu 24.04 内置的 systemd-timesyncd 提供轻量级 NTP 客户端功能，支持自动同步、漂移补偿和状态查询。如需更高精度的时间同步（如金融、日志审计场景），建议改用 chrony 替代 systemd-timesyncd。

Terraform 状态文件管理

Fri, 04 Sep 2026 16:08:53 +0800

1. 为什么要把 State 搬到「云上」

State 文件是 Terraform 的「账本」：它记录云上到底有哪些资源、各自的属性。本地存放 State 有三个硬伤：

绑定机器：State 在 A 电脑上，B 电脑 apply 就会"失忆"，容易把资源重建一遍。
无法协作：两个人同时改同一个环境，互相覆盖，状态文件乱套。
安全隐患：本地文件易丢，而且里面可能含有明文密码等敏感信息，因此也不建议上传到 gitlab 等代码托管平台。

解决办法就是 Terraform 的 Backend 机制：用阿里云 OSS 存 State（集中、加密、可回滚），用 Tablestore 提供加锁（防止多人并发操作冲突）。

2. 工作原理

每次执行 Terraform 命令，OSS Backend 都会走「加锁 → 干活 → 放锁」三步：

flowchart LR
A[terraform apply] --> B{从 Tablestore 拿 LockID}
B -- 已存在 --> C[报错：有人在操作]
B -- 不存在 --> D[生成并存入 LockID]
D --> E[读写 OSS 里的 State 文件]
E --> F[释放 LockID]

有锁 → 说明有人正在操作，或上次操作异常退出，直接报错
无锁 → 自动生成 LockID 存入 Tablestore，操作完成后更新 OSS 中的 State，再释放锁

3. 第一步：创建「存储 + 锁」资源

在正式使用前，要先准备一个 OSS Bucket 和一个 Tablestore 实例/表。它们本身也是云资源，所以也可以用 Terraform 自己建。

Terraform 云上存量资源导入

Thu, 03 Sep 2026 16:24:03 +0800

1. 为什么要"导入"云上资源？

很多团队都有这样的经历：最开始用控制台点几下、或者用 CLI 脚本把资源建好了，等资源越攒越多、想标准化管理时，发现这些资源"游离"在 Terraform 之外。

Terraform 的管理逻辑很简单：它只认自己 state 文件里记录的资源。你在控制台创建的资源，Terraform 根本"看不见"，也不会去动它们。所以要把存量资源管起来，第一步就是"导入"（import）——把云上已有的资源登记进 Terraform 的 state，再补上对应的配置代码。

导入成功后，这些资源和 Terraform 新建的资源享受完全一样的待遇：能 plan、能 apply、能 diff、能进 CI/CD。

2. 先搞清楚两个概念：config 和 state

这是最容易绕晕的地方，务必先分清：

概念	是什么	谁来写
`.tf` 配置（config）	声明"想要什么"，是给人看的声明式代码	手写，或工具自动生成
`terraform.tfstate`（state）	记录"现在实际是什么"，含真实属性（可能有敏感信息）	由 apply / import 自动生成

关键点：

导入只会写 state，不会自动写 config（除非你用 -generate-config-out 或 Terraformer）。
所以完整流程 = 导入进 state + 补齐 config + plan 核对一致，三步缺一不可。
state 含敏感信息，永远不要提交到 git（后面最佳实践会讲远程存储）。

整体流程可以先看这张图：

flowchart TD
A[盘点存量资源: 类型 / ID / 地域] --> B[环境准备: Terraform + provider + RAM 凭证]
B --> C{资源量多少?}
C -->|少| D[import block / terraform import]
C -->|多| E[aliterraformer 批量导入]
D --> F[生成 config + state]
E --> F
F --> G[terraform plan 核对无漂移]
G --> H[清理只读属性 + 纳入 git + OSS 远程 state]

3. 三种导入方式怎么选

阿里云官方文档提供了三种方式，直接放对比表：

Terraform 内置函数

Thu, 03 Sep 2026 16:06:29 +0800

写 Terraform 配置的时候，你肯定遇到过这些场景：

想把几个字符串拼起来
想从一个列表里取第一个元素
想根据条件选不同的值
想读取一个 JSON 配置文件

Terraform 内置了 100+ 个函数，覆盖了字符串处理、集合操作、类型转换、编码解码等各种需求。掌握它们，你的 HCL 代码会从"能跑"变成"优雅"。

本文挑出最常用的 20 个函数，每个都配上可直接运行的 demo，最后附上最佳实践。

1. 字符串函数

1.1. `format()` — 格式化字符串

类似其他语言的 sprintf，用占位符拼接字符串。

locals {
 env = "prod"
 region = "cn-hangzhou"
 # 输出: "prod-cn-hangzhou-01"
 name = format("%s-%s-01", local.env, local.region)
}

1.2. `join()` — 用分隔符拼接列表

locals {
 tags = ["web", "nginx", "frontend"]
 # 输出: "web,nginx,frontend"
 csv = join(",", local.tags)
}

1.3. `split()` — 按分隔符拆分字符串

locals {
 str = "10.0.0.1,10.0.0.2,10.0.0.3"
 # 输出: ["10.0.0.1", "10.0.0.2", "10.0.0.3"]
 ips = split(",", local.str)
}

1.4. `replace()` — 替换子串

locals {
 name = "my-project-dev"
 # 输出: "my-project-prod"
 new = replace(local.name, "dev", "prod")
}

1.5. `trimprefix()` / `trimsuffix()` — 去掉前缀/后缀

locals {
 domain = "www.example.com"
 # 输出: "example.com"
 base = trimprefix(local.domain, "www.")
}

1.6. `upper()` / `lower()` / `title()` — 大小写转换

locals {
 env = "production"
 # 输出: "PRODUCTION"
 tag = upper(local.env)
}

2. 集合函数（列表 / 映射 / 集合）

2.1. `length()` — 获取长度

locals {
 zones = ["cn-hangzhou-a", "cn-hangzhou-b", "cn-hangzhou-c"]
 count = length(local.zones) # 输出: 3
}

2.2. `element()` — 按索引取值（会循环）

locals {
 zones = ["a", "b"]
 # 索引 2 超出长度，自动取模 → 回到索引 0
 # 输出: "a"
 zone = element(local.zones, 2)
}

💡 和直接 local.zones[2] 不同，element() 不会报错，适合循环创建资源时分配可用区。

Terrafrom 基础知识

Thu, 03 Sep 2026 12:37:52 +0800

1. 简介

Terraform 是一款开源的“基础设施即代码（Infrastructure as Code，IaC）”工具，由 HashiCorp 公司开发（创始人为 Mitchell Hashimoto）。它的核心作用是用人类可读的配置文件来安全、高效地构建、变更和版本化管理云上和本地的各类基础设施。

它的主要特点包括：

基础设施即代码：用高阶配置语法描述基础设施，便于版本控制、复用和共享。
声明式语言：用户只需描述期望的基础设施最终状态，工具自动处理依赖关系和部署顺序；配置语言使用 HCL（也支持 JSON）。
执行计划：在真正执行前会生成操作计划，避免意外变更。
资源图：构建资源依赖图并并行处理相互独立的资源。
多云支持：可与 AWS、Azure、Google Cloud、阿里云等主流云平台集成。

典型的工作流程包括初始化（terraform init）、生成计划（terraform plan）和应用（terraform apply）三个阶段。Terraform 侧重于定义和管理基础设施结构，常与 Ansible 等侧重于配置管理的工具搭配使用。

2. 核心概念

2.1. 基础架构即代码 (IaC)

Terraform 允许使用配置文件（而非手动操作或脚本）来定义和管理基础设施。这使基础设施可以像应用程序代码一样进行版本控制、测试和协作。

2.2 HCL

HCL 全称 HashiCorp Configuration Language，是 Terraform 使用的一种特定于域的专用语言，专为基础设施管理设计：

语法简单易学，比 JSON 和 ARM 模板更直观
支持变量、条件表达式和函数
提供类型安全和 IntelliSense 支持（在 VS Code 等编辑器中）

2.3. Providers

Provider 是云厂商提供并维护的一个能与云厂商 API 进行交互的插件，其中包含相关资源和数据源对象。Terraform 可以通过 Provider 来管理基础设施。常用的 Providers 有：

AzureRM：管理 Azure 资源
AWS：管理 AWS 服务
Kind：使用 Kind 管理 kubernetes 集群
Docker：管理容器资源
其他支持的云平台和 SaaS 服务

2.4. 状态文件 (State File)

Terraform 会跟踪基础设施的当前状态，包括，组件配置，资源之间的依赖关系等，通过比对配置文件与状态文件，确定需要实施哪些变更。

维克的博客

从零开始：生产级 GitLab CI 流水线搭建

1. 最小流水线验证

1.1 为什么先只做这两步

1.3 写配置文件

Trivy 使用笔记：从安装到生产实践

1. Trivy 是什么

2. 为什么我们需要它

2.1 供应链安全是真实风险

Kaniko 从入门到实践

1. Kaniko 是什么

2. Kaniko 解决了什么问题

GitLab CICD 入门指南

1. 简介

1.1 GitLab CI/CD 是什么？

1.2 如何定义流水线？

JavaScript 基础知识

1. JavaScript 是什么

2. 运行环境

2.1 浏览器环境

2.2 Node.js 环境

Gitlab 备份恢复和版本升级

1. gitlab 数据备份

1.1 数据备份

1.2 执行备份

1.3 生产备份策略

Gitlab 入门和生产部署实践

1. 什么是 GitLab

2. 三种部署方式（选型）

3. 安装 GitLab

3.1 前置硬件&系统要求

3.2 添加 apt 源安装

3.3 离线包（无网络环境使用）

ArgoCD 入门和生产实践指南

1. 什么是 ArgoCD

2. 架构原理

3. 部署

Kubespray 部署和维护 K8s 集群指南

1. 简介

1.1 Kubespray 解决了什么问题

1.2 和其他工具对比

2. 底层架构和设计

Harbor 私有镜像仓库安装部署和最佳实践

1. 简介

2. 前置环境准备

2.1 Harbor版本选型指南

2.2 基础依赖

3. Harbor 离线安装流程

Go 语言中的 Slice 类型

1. Slice 的基础特性

2. Slice 的四种初始化方式

2.1 声明未初始化（nil slice）

2.2 字面量初始化（空切片/带初始值）

Go 语言中的 Map 类型

1. Map 的基础特性

2. Map 的四种初始化方式

2.1 声明未初始化（nil map）

2.2 字面量初始化（空 Map/带初始值）

Go 语言中的字符串类型

1. 底层实现

2. 字面量与引号

Go 语言中的循环控制

1. 基本语法

2. 只使用表达式的 for 循环

3. 无限循环和 break

K8s MetaLB 详解

1. 项目介绍

1.1 项目定位与核心作用

1.2 架构原理

1.2.1 Controller（控制器组件）

1.2.2 Speaker（转发组件）

Pod 网络故障排查

1. 第一层：Pod 自身状态确认

1.1 检查 Pod 状态

1.2 确认 Pod 有 IP 地址

K8s 集群升级

1. 大版本升级的核心原则

2. 标准升级流程

3. 升级过程中可能遇到的问题

Kubeadm 部署高可用 K8s 集群

2.1 声明未初始化（`nil map`）

1.1. `format()` — 格式化字符串

1.2. `join()` — 用分隔符拼接列表

1.3. `split()` — 按分隔符拆分字符串

1.4. `replace()` — 替换子串

1.5. `trimprefix()` / `trimsuffix()` — 去掉前缀/后缀

1.6. `upper()` / `lower()` / `title()` — 大小写转换

2.1. `length()` — 获取长度

2.2. `element()` — 按索引取值（会循环）