网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载本指南以 Calico 仓库根目录的 DEVELOPER_GUIDE.md 为主体结合仓库内根级 Makefile、共享构建库 lib.Makefile、版本元数据 metadata.mk 以及各组件子目录的 Makefile系统讲解如何搭建 Calico 开发环境、按需构建组件镜像、执行交叉编译并运行单元测试UT、功能验证测试FV与系统测试ST。读完本文你将能够从零开始编译出calico/node、felix、typha、calicoctl等镜像与二进制并掌握加速增量构建、替换基础镜像、同步 Helm Chart 与 manifests 的完整工作流。前置条件Linux 构建环境Calico 的构建体系完全围绕容器化构建设计所有 Go 编译都在 Docker 容器内完成因此宿主机只需要三样东西Docker构建容器镜像、执行容器内编译、运行 FV/ST 测试的基础设施git构建过程依赖 git 仓库状态推导版本号GIT_VERSION、GIT_COMMIT、BUILD_ID等见 lib.Makefilemake整个仓库的构建与测试入口统一由 Makefile 驱动。在开始之前建议先确认 Docker 守护进程可用如docker info能正常返回。首次构建时构建系统会自动拉取构建工具镜像calico/go-build版本形如$(GO_VERSION)-llvm$(LLVM_VERSION)-k8s$(K8S_VERSION)当前由 metadata.mk 中的GO_BUILD_VER决定例如 Go 1.27.1 LLVM 21.1.8 Kubernetes v1.37.0。注意文档假设的是 Linux 环境。虽然部分子目录支持 macOS 开发例如calicoctl提供darwin-amd64、darwin-arm64二进制但整体构建与测试仍以 Linux Docker 为基准。构建 Calico从全量镜像到按需编译全量构建make image在仓库根目录执行make image该命令会并行构建仓库内所有组件的容器镜像。根 Makefile 中image目标的实现为image: $(MAKE) -j$(NUM_BUILD_JOBS) $(KIND_IMAGE_MARKERS) CALICO_IMAGES$(KIND_CALICO_IMAGES) \ DEV_IMAGE_PREFIX$(DEV_IMAGE_PREFIX) \ DEV_IMAGE_TAG$(DEV_IMAGE_TAG) \ ARCH$(ARCH) \ STAMP_DIR$(DEV_STAMP_DIR) \ $(REPO_ROOT)/hack/dev-build.sh --tag可见全量构建分两步先以-j$(NUM_BUILD_JOBS)并行构建各组件镜像默认并行度为 4可用NUM_BUILD_JOBS8等调大见 lib.Makefile再调用 hack/dev-build.sh 将所有本地镜像统一打上开发仓库标签。全量构建产物众多、耗时较长因此文档明确建议只构建你正在修改的那个组件的镜像。干净构建make clean image构建系统利用 Go 包缓存与本地 vendor 缓存来加速重复构建增量构建会跳过未变更部分。若需要彻底重来先执行clean目标make clean image根 Makefile 的clean会递归清理api、apiserver、calicoctl、cni-plugin、confd、felix、cmd/calico、kube-controllers、libcalico-go、node、typha、release、whisker等全部子目录并删除.dev-stamps/、bin/、.stamp.*等中间产物确保后续构建从干净状态开始。构建单个组件镜像make -C dir imageCalico 采用每个子目录一个独立 Makefile 共享 lib.Makefile的架构各组件 Makefile 均include ../lib.Makefile因此可以在任意组件目录单独执行构建。例如构建calico/nodemake -C node image对应地也可以构建其他组件make -C felix image # 构建 calico/felix 测试环境镜像 make -C typha image # 构建 Typha 相关产物 make -C calicoctl build # 编译 calicoctl CLI 二进制以 node/Makefile 为例image目标依赖完整的构建链先编译 BPF 程序filesystem/usr/lib/calico/bpf来自 felix/bpf-gpl 与 felix/bpf-apache 的make build-bpf再以 CGO 方式构建组合型calicomonobinary../cmd/calico/bin/calico-cgo-$(ARCH)最后通过docker buildx build生成node:latest-$(ARCH)镜像。这也解释了为什么node镜像的源码依赖除了自身deps.txt外还通过local-deps-go-files宏把cmd模块的全部本地依赖felix、confd 等纳入增量重建判断。版本号与产物命名构建产物命名遵循统一约定详见 lib.Makefile 的LDFLAGS与各组件 Makefile二进制位于bin/或dist/形如felix-arm64、typha-amd64、calicoctl-linux-amd64、calicoctl-darwin-arm64、calicoctl-windows-amd64.exe多 OS 时按NAME-OS-ARCH命名见 calicoctl/Makefile镜像命名为NAME:latest-ARCH如calico/felix:latest-amd64、calico/typha:latest-s390x多 OS 时为NAME:latest-OS-ARCH编译进二进制的版本信息Version、BuildDate、GitRevision通过-X链接器标志注入pkg/buildinfo包版本号由git describe --tags --dirty --always --abbrev12推导发布构建RELEASEtrue时仅使用 tag。交叉编译为指定架构构建镜像默认情况下镜像面向构建机器的架构产出。Calico 支持四大架构amd64、arm64、ppc64le、s390x由 lib.Makefile 的ARCHES变量定义。要交叉编译通过ARCH环境变量指定目标架构make image ARCHarm64在 lib.Makefile 中可以看到完整的架构处理逻辑BUILDARCH为宿主机架构uname -m探测x86_64/aarch64会被规范化成amd64/arm64ARCH为目标架构默认等于BUILDARCH交叉编译时构建系统会先通过docker run --privileged calico/binfmt注册 QEMU binfmt 支持register目标再用docker buildx build --platformlinux/$(ARCH)产出目标架构镜像amd64 主机构建其他架构时Go 侧使用 clang 作为交叉编译器clang --targetaarch64-linux-gnu等配合/usr/$(CROSS_TRIPLE)/sys-root系统根目录避免 QEMU 慢速模拟 CGO 构建见CLANG_CROSS_TRIPLE_*与CROSS_SYSROOT定义Rust 侧CARGO_BUILD_TARGET同样通过环境变量注入交叉编译目标链路使用 lld 链接器。执行make build-all或make image-all会一次性构建全部受支持架构可用EXCLUDEARCH排除个别架构。替换基础镜像CALICO_BASE 变量许多 Calico 组件如 Typha、apiserver以calico/base作为基础镜像。该镜像可通过 Makefile 变量覆盖make image CALICO_BASEsome/image默认值由 lib.Makefile 决定CALICO_BASE ? calico/base:$(CALICO_BASE_VER)其中CALICO_BASE_VER当前为基于 Red Hat UBI 9 的镜像见 metadata.mk 中的CALICO_BASE_VERubi9-1789183536若设置USE_UBI_AS_CALICO_BASE则直接使用registry.access.redhat.com/ubi9/ubi-minimal:latest。DOCKER_BUILD宏会通过--build-arg CALICO_BASE$(CALICO_BASE)把该变量传入各组件 Dockerfile。使用自定义基础镜像需要满足两个前提文档原文明确警告所选基础镜像必须与默认镜像足够相似当前默认基于 Red Hat UBI否则构建可能失败自建镜像缺少 Calico 团队对官方镜像所做的回归测试官方支持将按尽力而为原则提供。同步 Helm Chart 与 ManifestsCalico 的 Helm Chart 位于仓库charts/目录含calico、tigera-operator、crd.projectcalico.org.v1、projectcalico.org.v3等多个 Chart而 manifests 目录下的 YAML如calico.yaml、calico-typha.yaml、calico-etcd.yaml大部分由 Helm Chart 自动生成。因此修改了 Chart 模板之后必须重新生成 manifestsmake gen-manifests根 Makefile 中该目标的实现为gen-manifests: bin/helm bin/yq cd ./manifests ./generate.sh即借助bin/helm与bin/yq渲染 Chart 并运行 manifests/generate.sh 批量产出。此外完整的代码/CRD 生成流程make generate会依次执行gen-semaphore-yaml、gen-deps-files、protobuf、各组件gen-files、gen-manifests、gen-test-set与fix-changed是新增 API 或修改 CRD 定义后的一站式生成入口。Makefile 标准目标参考以下是每个项目目录含根目录都会提供的标准 Makefile 目标目标作用说明make build为当前架构构建二进制产物位于bin/或dist/命名为NAME-ARCH如felix-arm64、typha-amd64多 OS 时为NAME-OS-ARCH如calicoctl-darwin-amd64make build ARCHARCH为指定架构构建二进制命名约定同上make build-all为所有受支持架构构建二进制产物遵循上述命名约定make image为当前架构创建 Docker 镜像命名为NAME:latest-ARCH如calico/felix:latest-amd64、calico/typha:latest-s390x多 OS 时为NAME:latest-OS-ARCH如calico/ctl:latest-linux-ppc64lemake image ARCHARCH为指定架构创建 Docker 镜像命名约定同上make image-all为所有受支持架构创建 Docker 镜像命名约定同上make test运行全部测试见下文运行自动化测试make ci运行构建与测试的全部 CI 步骤警告不建议本地执行其中部分操作可能具有破坏性make cd运行全部 CD 步骤通常为向镜像仓库推送警告不建议本地执行出于安全考虑只有在make cd CONFIRMtrue时才会真正执行推送且仅应由 CI 系统使用以 calicoctl/Makefile 为实例make build产出bin/calicoctl-$(BUILDOS)-$(ARCH)make build-all则产出 Linux 四种架构加 Windows/macOS 的全部二进制felix/Makefile 的build还额外包含build-bpf编译 GPL 与 Apache 两套 BPF 程序与 Windows 可执行文件。运行自动化测试单元测试UTmake test每个组件目录都维护着独立的测试套件测试随源码在仓库内无需部署完整 Kubernetes 集群即可运行。文档建议首选通过提交 PR 触发 CI 构建让 CI 系统代为运行测试本地运行时逐目录执行因为全仓库测试耗时非常长在具体目录中使用make test运行该目录的测试。make test在 lib.Makefile 中定义为test: ut fv st即依次运行单元测试ut、功能验证测试fv与系统测试st。各目录的测试入口各有特色felixut目标通过run-coverage脚本以 CGO 容器运行 Ginkgo 测试默认跳过fv,k8sfv,bpf/ut包ut-bpf需要 root 权限会挂载 bpffs 并运行真实 BPF 测试还提供ut-watchginkgo watch与cover-browser/cover-report覆盖率查看typhaut目标执行./utils/run-coverage另提供ut-no-cover、ut-watch、cover-report等辅助目标calicoctlut目标在容器内运行ginkgo -cover -r并输出 JUnit 报告。功能验证测试FV与系统测试ST在 lib.Makefile 中test由ut fv st组成但各目录对 FV/ST 的实现差异较大felix FVmake fv会先通过fv-prereqs构建fv/fv.test测试二进制、组合型calico镜像、test-workload、test-connection、calico-bpf、pktgen及全部 BPF 程序然后由run-batches脚本按批次执行。支持并行分片FV_NUM_BATCHESN设定总批次数FV_BATCHES_TO_RUNk指定运行第 k 批还有fv-bpfFELIX_FV_ENABLE_BPFtrue启用 eBPF 数据面、fv-nftnftables 数据面等变体typhafv等价于k8sfv-test即用calico/calico:latest-$(ARCH)镜像以component typha命令启动 Typha再运行 felix 侧的 k8s FV 测试USE_TYPHAtrue/false控制是否经过 Typhacalicoctlfv目标会启动 etcd、并在 6443/6444 两个端口各起一个 Kubernetes apiserver 与 controller-manager用于验证多 kubeconfig 支持应用 mock Node 与 CRD 后运行./tests/fvST系统测试calicoctl 的st通过pytest在特权测试容器内运行 tests/st 下的测试可用ST_TO_RUN指定单个用例如tests/st/calicoctl/test_crud.py:TestCalicoctlCommands.test_get_delete_multiple_namesfelix、typha 则声明No STs available。各目录更细粒度的测试选择如 Ginkgo focus、批次数、慢测试阈值请参考对应目录的文档与 Makefile。构建加速缓存与并行机制Calico 的构建体系从多个维度加速增量开发Go 包缓存与 vendor 缓存所有容器内构建统一挂载LOCAL_GO_PKG_CACHE默认$(REPO_ROOT)/.go-pkg-cache也可由GOCACHE或环境变量指定到容器/go-cache并挂载宿主机GOMOD_CACHE$GOPATH/pkg/mod或$HOME/go/pkg/mod实现模块复用见 lib.Makefile 的DOCKER_RUN_PRIV_NET定义源码依赖跟踪deps.txt每个组件的 deps.txt 记录外部模块依赖与仓库内本地依赖local:前缀SRC_FILES据此自动展开任何相关源码变更都会触发该组件的增量重建镜像指纹与 stamp 文件镜像构建通过.*.created-$(ARCH)等 stamp 文件标记完成状态make clean删除这些 stamp 以强制重建根目录image目标默认-j4并行构建各组件可用NUM_BUILD_JOBS调整并行度开发镜像标签与推送hack/dev-build.sh 负责把本地构建的calico/name:latest-$(ARCH)镜像重新打上$(DEV_IMAGE_PREFIX)/name:$(DEV_IMAGE_TAG)开发标签make image内部调用--tagmake push则按 docker image ID 变化增量推送--push重复运行会自动跳过未变更的镜像容器资源限制可在工作站上通过DOCKER_CPUS、DOCKER_CPUSET_CPUS、DOCKER_MEMORY、GOMAXPROCS、GO_BUILD_PARALLELISM等变量限制并行构建的内存/CPU 占用防止开发机被压垮。深入阅读更详细的开发者文档如 如何向 Calico 新增一个 API涵盖 v3 API 结构、make generate生成代码与 CRD、kubebuilder 校验注解、libcalico-go 客户端与 calicoctl CRUD 命令的编写流程位于 hack/docs 目录根级 Makefile 还包含protobuf重新生成 protobuf 绑定、static-checks/golangci-lint静态检查、chart打包 Helm Chart、kind-up/e2e-test本地 kind 集群端到端测试、release系列发布构建等更多目标可按需查阅各组件 Makefilenode/Makefile、felix/Makefile、typha/Makefile、calicoctl/Makefile 等是了解具体构建链与测试入口的第一手资料。常见问题与建议全量构建太慢优先make -C 组件目录 image只构建所修改的组件测试同理逐目录执行make test而非仓库级全量测试。需要干净构建使用make clean image或在make push前删除.dev-stamps目录强制全量重建见根 Makefile 顶部注释。要发布/推送镜像请勿在本地直接执行make cd正确做法是使用make push DEV_IMAGE_PATH你的账号 DEV_IMAGE_TAG标签推送到你自己的仓库或交由 CI 系统以CONFIRMtrue执行官方发布流程。架构与宿主不一致明确使用ARCHarm64等参数构建系统会自动注册 binfmt 并启用 clang 交叉编译无需手动干预。交叉编译的 CGO 差异amd64 默认CGO_ENABLED1BPF/libbpf 需要其余架构默认纯 Go 构建在 amd64 主机上交叉编译时通过 clang 系统根目录完成 CGO 编译相关细节均可在 lib.Makefile 中溯源。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐OceanBase 贡献者开发指南从环境搭建、源码构建到编码规范与调试测试的完整实践OceanBase 贡献者开发指南从环境搭建、源码构建到编码规范与调试测试的完整实践 导读 本文是 OceanBase 开源仓库中英文开发指南 docs/d数据库分布式数据库关系型数据库后端高可用Local Deep Research 开发者指南从环境搭建到测试、构建与排障的完整实战手册Local Deep Research 开发者指南从环境搭建到测试、构建与排障的完整实战手册 本指南以项目官方开发者文档 docs/developing.mdAI应用人工智能大模型RAGAI Agent深度研究本地部署后端前端winget-cli 开发者指南从环境搭建、源码构建到调试与本地化实践winget cli 开发者指南从环境搭建、源码构建到调试与本地化实践 本篇指南基于 winget cli 仓库的 doc/Developing.md htt包管理器CLI上一篇为什么选择OpenLLaMA 3B v2开源许可、硬件要求与应用场景全解析 下一篇Fork TS Checker Webpack Plugin完整配置指南从基础设置到高级优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Calico 开发者指南：从环境搭建到镜像构建与自动化测试的完整实践
网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载本指南以 Calico 仓库根目录的 DEVELOPER_GUIDE.md 为主体结合仓库内根级 Makefile、共享构建库 lib.Makefile、版本元数据 metadata.mk 以及各组件子目录的 Makefile系统讲解如何搭建 Calico 开发环境、按需构建组件镜像、执行交叉编译并运行单元测试UT、功能验证测试FV与系统测试ST。读完本文你将能够从零开始编译出calico/node、felix、typha、calicoctl等镜像与二进制并掌握加速增量构建、替换基础镜像、同步 Helm Chart 与 manifests 的完整工作流。前置条件Linux 构建环境Calico 的构建体系完全围绕容器化构建设计所有 Go 编译都在 Docker 容器内完成因此宿主机只需要三样东西Docker构建容器镜像、执行容器内编译、运行 FV/ST 测试的基础设施git构建过程依赖 git 仓库状态推导版本号GIT_VERSION、GIT_COMMIT、BUILD_ID等见 lib.Makefilemake整个仓库的构建与测试入口统一由 Makefile 驱动。在开始之前建议先确认 Docker 守护进程可用如docker info能正常返回。首次构建时构建系统会自动拉取构建工具镜像calico/go-build版本形如$(GO_VERSION)-llvm$(LLVM_VERSION)-k8s$(K8S_VERSION)当前由 metadata.mk 中的GO_BUILD_VER决定例如 Go 1.27.1 LLVM 21.1.8 Kubernetes v1.37.0。注意文档假设的是 Linux 环境。虽然部分子目录支持 macOS 开发例如calicoctl提供darwin-amd64、darwin-arm64二进制但整体构建与测试仍以 Linux Docker 为基准。构建 Calico从全量镜像到按需编译全量构建make image在仓库根目录执行make image该命令会并行构建仓库内所有组件的容器镜像。根 Makefile 中image目标的实现为image: $(MAKE) -j$(NUM_BUILD_JOBS) $(KIND_IMAGE_MARKERS) CALICO_IMAGES$(KIND_CALICO_IMAGES) \ DEV_IMAGE_PREFIX$(DEV_IMAGE_PREFIX) \ DEV_IMAGE_TAG$(DEV_IMAGE_TAG) \ ARCH$(ARCH) \ STAMP_DIR$(DEV_STAMP_DIR) \ $(REPO_ROOT)/hack/dev-build.sh --tag可见全量构建分两步先以-j$(NUM_BUILD_JOBS)并行构建各组件镜像默认并行度为 4可用NUM_BUILD_JOBS8等调大见 lib.Makefile再调用 hack/dev-build.sh 将所有本地镜像统一打上开发仓库标签。全量构建产物众多、耗时较长因此文档明确建议只构建你正在修改的那个组件的镜像。干净构建make clean image构建系统利用 Go 包缓存与本地 vendor 缓存来加速重复构建增量构建会跳过未变更部分。若需要彻底重来先执行clean目标make clean image根 Makefile 的clean会递归清理api、apiserver、calicoctl、cni-plugin、confd、felix、cmd/calico、kube-controllers、libcalico-go、node、typha、release、whisker等全部子目录并删除.dev-stamps/、bin/、.stamp.*等中间产物确保后续构建从干净状态开始。构建单个组件镜像make -C dir imageCalico 采用每个子目录一个独立 Makefile 共享 lib.Makefile的架构各组件 Makefile 均include ../lib.Makefile因此可以在任意组件目录单独执行构建。例如构建calico/nodemake -C node image对应地也可以构建其他组件make -C felix image # 构建 calico/felix 测试环境镜像 make -C typha image # 构建 Typha 相关产物 make -C calicoctl build # 编译 calicoctl CLI 二进制以 node/Makefile 为例image目标依赖完整的构建链先编译 BPF 程序filesystem/usr/lib/calico/bpf来自 felix/bpf-gpl 与 felix/bpf-apache 的make build-bpf再以 CGO 方式构建组合型calicomonobinary../cmd/calico/bin/calico-cgo-$(ARCH)最后通过docker buildx build生成node:latest-$(ARCH)镜像。这也解释了为什么node镜像的源码依赖除了自身deps.txt外还通过local-deps-go-files宏把cmd模块的全部本地依赖felix、confd 等纳入增量重建判断。版本号与产物命名构建产物命名遵循统一约定详见 lib.Makefile 的LDFLAGS与各组件 Makefile二进制位于bin/或dist/形如felix-arm64、typha-amd64、calicoctl-linux-amd64、calicoctl-darwin-arm64、calicoctl-windows-amd64.exe多 OS 时按NAME-OS-ARCH命名见 calicoctl/Makefile镜像命名为NAME:latest-ARCH如calico/felix:latest-amd64、calico/typha:latest-s390x多 OS 时为NAME:latest-OS-ARCH编译进二进制的版本信息Version、BuildDate、GitRevision通过-X链接器标志注入pkg/buildinfo包版本号由git describe --tags --dirty --always --abbrev12推导发布构建RELEASEtrue时仅使用 tag。交叉编译为指定架构构建镜像默认情况下镜像面向构建机器的架构产出。Calico 支持四大架构amd64、arm64、ppc64le、s390x由 lib.Makefile 的ARCHES变量定义。要交叉编译通过ARCH环境变量指定目标架构make image ARCHarm64在 lib.Makefile 中可以看到完整的架构处理逻辑BUILDARCH为宿主机架构uname -m探测x86_64/aarch64会被规范化成amd64/arm64ARCH为目标架构默认等于BUILDARCH交叉编译时构建系统会先通过docker run --privileged calico/binfmt注册 QEMU binfmt 支持register目标再用docker buildx build --platformlinux/$(ARCH)产出目标架构镜像amd64 主机构建其他架构时Go 侧使用 clang 作为交叉编译器clang --targetaarch64-linux-gnu等配合/usr/$(CROSS_TRIPLE)/sys-root系统根目录避免 QEMU 慢速模拟 CGO 构建见CLANG_CROSS_TRIPLE_*与CROSS_SYSROOT定义Rust 侧CARGO_BUILD_TARGET同样通过环境变量注入交叉编译目标链路使用 lld 链接器。执行make build-all或make image-all会一次性构建全部受支持架构可用EXCLUDEARCH排除个别架构。替换基础镜像CALICO_BASE 变量许多 Calico 组件如 Typha、apiserver以calico/base作为基础镜像。该镜像可通过 Makefile 变量覆盖make image CALICO_BASEsome/image默认值由 lib.Makefile 决定CALICO_BASE ? calico/base:$(CALICO_BASE_VER)其中CALICO_BASE_VER当前为基于 Red Hat UBI 9 的镜像见 metadata.mk 中的CALICO_BASE_VERubi9-1789183536若设置USE_UBI_AS_CALICO_BASE则直接使用registry.access.redhat.com/ubi9/ubi-minimal:latest。DOCKER_BUILD宏会通过--build-arg CALICO_BASE$(CALICO_BASE)把该变量传入各组件 Dockerfile。使用自定义基础镜像需要满足两个前提文档原文明确警告所选基础镜像必须与默认镜像足够相似当前默认基于 Red Hat UBI否则构建可能失败自建镜像缺少 Calico 团队对官方镜像所做的回归测试官方支持将按尽力而为原则提供。同步 Helm Chart 与 ManifestsCalico 的 Helm Chart 位于仓库charts/目录含calico、tigera-operator、crd.projectcalico.org.v1、projectcalico.org.v3等多个 Chart而 manifests 目录下的 YAML如calico.yaml、calico-typha.yaml、calico-etcd.yaml大部分由 Helm Chart 自动生成。因此修改了 Chart 模板之后必须重新生成 manifestsmake gen-manifests根 Makefile 中该目标的实现为gen-manifests: bin/helm bin/yq cd ./manifests ./generate.sh即借助bin/helm与bin/yq渲染 Chart 并运行 manifests/generate.sh 批量产出。此外完整的代码/CRD 生成流程make generate会依次执行gen-semaphore-yaml、gen-deps-files、protobuf、各组件gen-files、gen-manifests、gen-test-set与fix-changed是新增 API 或修改 CRD 定义后的一站式生成入口。Makefile 标准目标参考以下是每个项目目录含根目录都会提供的标准 Makefile 目标目标作用说明make build为当前架构构建二进制产物位于bin/或dist/命名为NAME-ARCH如felix-arm64、typha-amd64多 OS 时为NAME-OS-ARCH如calicoctl-darwin-amd64make build ARCHARCH为指定架构构建二进制命名约定同上make build-all为所有受支持架构构建二进制产物遵循上述命名约定make image为当前架构创建 Docker 镜像命名为NAME:latest-ARCH如calico/felix:latest-amd64、calico/typha:latest-s390x多 OS 时为NAME:latest-OS-ARCH如calico/ctl:latest-linux-ppc64lemake image ARCHARCH为指定架构创建 Docker 镜像命名约定同上make image-all为所有受支持架构创建 Docker 镜像命名约定同上make test运行全部测试见下文运行自动化测试make ci运行构建与测试的全部 CI 步骤警告不建议本地执行其中部分操作可能具有破坏性make cd运行全部 CD 步骤通常为向镜像仓库推送警告不建议本地执行出于安全考虑只有在make cd CONFIRMtrue时才会真正执行推送且仅应由 CI 系统使用以 calicoctl/Makefile 为实例make build产出bin/calicoctl-$(BUILDOS)-$(ARCH)make build-all则产出 Linux 四种架构加 Windows/macOS 的全部二进制felix/Makefile 的build还额外包含build-bpf编译 GPL 与 Apache 两套 BPF 程序与 Windows 可执行文件。运行自动化测试单元测试UTmake test每个组件目录都维护着独立的测试套件测试随源码在仓库内无需部署完整 Kubernetes 集群即可运行。文档建议首选通过提交 PR 触发 CI 构建让 CI 系统代为运行测试本地运行时逐目录执行因为全仓库测试耗时非常长在具体目录中使用make test运行该目录的测试。make test在 lib.Makefile 中定义为test: ut fv st即依次运行单元测试ut、功能验证测试fv与系统测试st。各目录的测试入口各有特色felixut目标通过run-coverage脚本以 CGO 容器运行 Ginkgo 测试默认跳过fv,k8sfv,bpf/ut包ut-bpf需要 root 权限会挂载 bpffs 并运行真实 BPF 测试还提供ut-watchginkgo watch与cover-browser/cover-report覆盖率查看typhaut目标执行./utils/run-coverage另提供ut-no-cover、ut-watch、cover-report等辅助目标calicoctlut目标在容器内运行ginkgo -cover -r并输出 JUnit 报告。功能验证测试FV与系统测试ST在 lib.Makefile 中test由ut fv st组成但各目录对 FV/ST 的实现差异较大felix FVmake fv会先通过fv-prereqs构建fv/fv.test测试二进制、组合型calico镜像、test-workload、test-connection、calico-bpf、pktgen及全部 BPF 程序然后由run-batches脚本按批次执行。支持并行分片FV_NUM_BATCHESN设定总批次数FV_BATCHES_TO_RUNk指定运行第 k 批还有fv-bpfFELIX_FV_ENABLE_BPFtrue启用 eBPF 数据面、fv-nftnftables 数据面等变体typhafv等价于k8sfv-test即用calico/calico:latest-$(ARCH)镜像以component typha命令启动 Typha再运行 felix 侧的 k8s FV 测试USE_TYPHAtrue/false控制是否经过 Typhacalicoctlfv目标会启动 etcd、并在 6443/6444 两个端口各起一个 Kubernetes apiserver 与 controller-manager用于验证多 kubeconfig 支持应用 mock Node 与 CRD 后运行./tests/fvST系统测试calicoctl 的st通过pytest在特权测试容器内运行 tests/st 下的测试可用ST_TO_RUN指定单个用例如tests/st/calicoctl/test_crud.py:TestCalicoctlCommands.test_get_delete_multiple_namesfelix、typha 则声明No STs available。各目录更细粒度的测试选择如 Ginkgo focus、批次数、慢测试阈值请参考对应目录的文档与 Makefile。构建加速缓存与并行机制Calico 的构建体系从多个维度加速增量开发Go 包缓存与 vendor 缓存所有容器内构建统一挂载LOCAL_GO_PKG_CACHE默认$(REPO_ROOT)/.go-pkg-cache也可由GOCACHE或环境变量指定到容器/go-cache并挂载宿主机GOMOD_CACHE$GOPATH/pkg/mod或$HOME/go/pkg/mod实现模块复用见 lib.Makefile 的DOCKER_RUN_PRIV_NET定义源码依赖跟踪deps.txt每个组件的 deps.txt 记录外部模块依赖与仓库内本地依赖local:前缀SRC_FILES据此自动展开任何相关源码变更都会触发该组件的增量重建镜像指纹与 stamp 文件镜像构建通过.*.created-$(ARCH)等 stamp 文件标记完成状态make clean删除这些 stamp 以强制重建根目录image目标默认-j4并行构建各组件可用NUM_BUILD_JOBS调整并行度开发镜像标签与推送hack/dev-build.sh 负责把本地构建的calico/name:latest-$(ARCH)镜像重新打上$(DEV_IMAGE_PREFIX)/name:$(DEV_IMAGE_TAG)开发标签make image内部调用--tagmake push则按 docker image ID 变化增量推送--push重复运行会自动跳过未变更的镜像容器资源限制可在工作站上通过DOCKER_CPUS、DOCKER_CPUSET_CPUS、DOCKER_MEMORY、GOMAXPROCS、GO_BUILD_PARALLELISM等变量限制并行构建的内存/CPU 占用防止开发机被压垮。深入阅读更详细的开发者文档如 如何向 Calico 新增一个 API涵盖 v3 API 结构、make generate生成代码与 CRD、kubebuilder 校验注解、libcalico-go 客户端与 calicoctl CRUD 命令的编写流程位于 hack/docs 目录根级 Makefile 还包含protobuf重新生成 protobuf 绑定、static-checks/golangci-lint静态检查、chart打包 Helm Chart、kind-up/e2e-test本地 kind 集群端到端测试、release系列发布构建等更多目标可按需查阅各组件 Makefilenode/Makefile、felix/Makefile、typha/Makefile、calicoctl/Makefile 等是了解具体构建链与测试入口的第一手资料。常见问题与建议全量构建太慢优先make -C 组件目录 image只构建所修改的组件测试同理逐目录执行make test而非仓库级全量测试。需要干净构建使用make clean image或在make push前删除.dev-stamps目录强制全量重建见根 Makefile 顶部注释。要发布/推送镜像请勿在本地直接执行make cd正确做法是使用make push DEV_IMAGE_PATH你的账号 DEV_IMAGE_TAG标签推送到你自己的仓库或交由 CI 系统以CONFIRMtrue执行官方发布流程。架构与宿主不一致明确使用ARCHarm64等参数构建系统会自动注册 binfmt 并启用 clang 交叉编译无需手动干预。交叉编译的 CGO 差异amd64 默认CGO_ENABLED1BPF/libbpf 需要其余架构默认纯 Go 构建在 amd64 主机上交叉编译时通过 clang 系统根目录完成 CGO 编译相关细节均可在 lib.Makefile 中溯源。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐OceanBase 贡献者开发指南从环境搭建、源码构建到编码规范与调试测试的完整实践OceanBase 贡献者开发指南从环境搭建、源码构建到编码规范与调试测试的完整实践 导读 本文是 OceanBase 开源仓库中英文开发指南 docs/d数据库分布式数据库关系型数据库后端高可用Local Deep Research 开发者指南从环境搭建到测试、构建与排障的完整实战手册Local Deep Research 开发者指南从环境搭建到测试、构建与排障的完整实战手册 本指南以项目官方开发者文档 docs/developing.mdAI应用人工智能大模型RAGAI Agent深度研究本地部署后端前端winget-cli 开发者指南从环境搭建、源码构建到调试与本地化实践winget cli 开发者指南从环境搭建、源码构建到调试与本地化实践 本篇指南基于 winget cli 仓库的 doc/Developing.md htt包管理器CLI上一篇为什么选择OpenLLaMA 3B v2开源许可、硬件要求与应用场景全解析 下一篇Fork TS Checker Webpack Plugin完整配置指南从基础设置到高级优化创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
