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，都会原封不动带进生产环境。 ...

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 集群）里，仍然能安全、快速地构建镜像。 ...

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 如何定义流水线？ 一个流水线本质上由两个核心概念构成： ...

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。 ...

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 到加密存储 密钥丢失=数据库无法解密，归档也无意义 定期恢复演练 在测试机用备份实际恢复一次 没验证能恢复的备份等于没有备份 提示： ...

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 离线包（无网络环境使用） 官方离线包下载地址 ...

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版本。 ...

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. 底层架构和设计 关键核心设计： ...

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版本为例。 ...