网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载导读本文基于 Calico 仓库内置的 kind-cluster 开发技能.claude/skills/kind-cluster/SKILL.md系统讲解如何用make kind-*系列目标在本地一键拉起一个运行着从本仓库源码现构建镜像的 kind 集群覆盖集群创建、镜像构建、Helm 部署、增量重载与集群销毁的完整闭环。读完本文你将掌握 Calico 开发者改代码 → 编译组件 → 热重载到 kind 集群的高效迭代循环以及双栈网络、本地镜像仓库、BPF 数据平面等关键细节的配置原理。一、工作流全景六条核心命令kind 相关目标定义在仓库根目录的 lib.Makefile约 1639 行起中由根目录 Makefile 编排入口脚本与基础设施则位于 hack/test/kind/。所有命令都必须在仓库根目录执行。make kind-up # 构建全部镜像 创建集群 部署 Calico完整拉起 make kind-cluster-create # 仅创建 kind 集群不构建镜像、不装 Calico make kind-build-images # 构建 kind 集群所需的全部容器镜像 make kind-deploy # 加载镜像 通过 Helm 安装 Calico 等待就绪 make kind-reload # 只把发生变更的镜像重载到已有集群增量 make kind-cluster-destroy # 销毁 kind 集群 make kind-down # kind-cluster-destroy 的别名kind-up是端到端入口其实现Makefile依次串联了三个阶段kind-up: $(MAKE) -j$(NUM_BUILD_JOBS) kind-build-images $(MAKE) kind-cluster-create CALICO_API_GROUP$(KIND_CALICO_API_GROUP) $(MAKE) kind-deploy即先构建镜像 → 再创建集群 → 最后部署 Calico。-j$(NUM_BUILD_JOBS)指定了镜像构建阶段的并行度外层并行数定义见 lib.Makefile。二、kind-cluster-create创建带 Calico CRD 的集群kind-cluster-createlib.Makefile不仅是kind create cluster还完成了本地镜像仓库接入与 CRD 预装清理旧集群先执行kind-cluster-destroy确保环境干净创建集群使用--config $(KIND_CONFIG)、--name $(KIND_NAME)节点镜像固定为kindest/node:$(KINDEST_NODE_VERSION)——该版本定义在 metadata.mk为v1.35.5kind 二进制版本v0.32.0且有意比仓库目标 Kubernetes 版本v1.37.0低一个小版本以满足 KubeVirt 等测试对节点镜像的约束接入本地镜像仓库kind 网络创建后调用registry.sh up与registry.sh configure-nodes等待 apiserver 就绪轮询get serviceaccount default随后依次创建 operator CRD、Calico CRD来自libcalico-go/config/crd/以及clusternetworkpoliciesCRD安装变更准入策略当CALICO_API_GROUPprojectcalico.org/v3时应用 api/admission/ 下的 mutating admission policyMutatingAdmissionPolicyfeature gate 需开启见下文集群配置。集群配置文件多套场景预置集群创建使用的KIND_CONFIG默认是 hack/test/kind/kind.config仓库还预置了多种场景配置配置文件用途差异点kind.config默认多节点集群1 控制面 3 worker双栈ipFamily: dualpodSubnet192.168.0.0/16,fd00:10:244::/64kube-proxy 为ipvskind-single.config仅控制面节点用于只依赖 apiserver 的 libcalico-go 等测试额外映射宿主机 8080 端口kind-bpf.configeBPF 数据平面 e2e与 kind.config 几乎一致唯一区别是 kube-proxy 改为iptables模式kind-manifests.config从生成清单安装3 worker 以满足 datapath 测试的可调度节点数所有配置都包含两个关键项详见 kind.configfeatureGates: MutatingAdmissionPolicy: true runtimeConfig: admissionregistration.k8s.io/v1beta1: truedisableDefaultCNI: true必须禁用 kind 自带 CNI把网络数据平面完全交给 CalicoMutatingAdmissionPolicy feature gate 开启因为 Calico 使用 Kubernetes 1.32 的 CEL 变更准入策略api/admission/ 下的 YAML对 IPPool 等资源做默认值注入旧式 webhook 方式已被替代仓库MIN_K8S_VERSION为 v1.32.0lib.Makefilekube-proxy 的conntrack.maxPerCore: 0用于规避 conntrack 相关测试干扰。另外每个配置都注释说明了 containerd 的镜像仓库配置方式kind 节点通过/etc/containerd/certs.d/读取镜像仓库映射因此registry.sh configure-nodes会在每个节点写入hosts.toml把localhost:5000重定向到网络内的http://kind-registry:5000——旧式containerdConfigPatches的mirrors语法在设置config_path后会被拒绝这正是脚本采用新机制的原因。三、本地镜像仓库kind-registry 的运作原理所有本地构建镜像都通过一个名为kind-registry的容器分发。其管理脚本 hack/test/kind/registry.sh 提供up | configure-nodes | down三个子命令且幂等可重复调用up若容器不存在则docker run -d --restartalways -p 127.0.0.1:5000:5000 registry:2启动若已停止则docker start随后把容器接入kinddocker 网络该网络在首次kind create cluster时才创建所以脚本会在集群创建后被 Makefile 再次调用以完成真正的网络接入configure-nodes遍历该集群的节点容器在/etc/containerd/certs.d/localhost:5000/hosts.toml写入[host.http://kind-registry:5000]重定向——containerd 按需读取该目录无需重启节点downdocker rm -f kind-registry删除容器。注意 lib.Makefile 中的kind-registry-destroy目标在删除 registry 后还会清理.dev-stamps/*pushed-id否则下次构建会因 push 时间戳未失效而跳过重新推送。这个 registry 容器跨集群创建/销毁而持久存在其镜像分层缓存得以在反复重建集群时复用registry.sh 注释明确说明。四、kind-build-images构建并推送全部测试镜像kind-build-imageslib.Makefile直接复用发布流程的make push管线只是注入了 kind 专用的镜像参数kind-build-images: kind-registry-up $(MAKE) -C $(REPO_ROOT) push $(KIND_DEV_IMAGE_ARGS)其中lib.MakefileKIND_IMAGE_REGISTRY localhost:5000 KIND_IMAGE_PATH calico KIND_TEST_BUILD_TAG test-build KIND_DEV_IMAGE_ARGS \ DEV_IMAGE_REGISTRY$(KIND_IMAGE_REGISTRY) \ DEV_IMAGE_PATH$(KIND_IMAGE_PATH) \ DEV_IMAGE_TAG$(KIND_TEST_BUILD_TAG)即所有组件镜像最终以localhost:5000/calico/name:test-build的形态落在本地 registry 中。需要构建的组件清单KIND_CALICO_IMAGESlib.Makefile包括calico/nodecalico-node 守护进程镜像calico/calico合并镜像calico subcommand作为容器命令承载了 apiserver、kube-controllers、typha、confd 等大多数组件calico/whisker唯一仍独立打包的 TypeScript/nginx 组件非 Go 二进制calico/envoy-gateway、calico/envoy-proxy、calico/envoy-ratelimitGateway API 相关组件calico/third-party-cni-plugins第三方 CNI 插件。此外kind-operator-imagelib.Makefile可单独构建 operator 镜像CI 的 Build: operator image 阶段会构建并缓存它供各 kind 测试作业直接复用避免每个作业重复编译 operator。五、kind-deploy通过 Helm 安装并等待就绪kind-deploylib.Makefile不做镜像加载——镜像由 kubelet 按需从本地 registry 拉取。它的核心动作是生成 Helm chart$(MAKE) -C $(REPO_ROOT) chart CALICO_API_GROUP$(KIND_CALICO_API_GROUP)调用 hack/test/kind/deploy_resources.sh 完成安装。部署脚本的关键流程deploy_resources.sh校验工作目录必须从REPO_ROOT运行脚本内的相对路径基于当前目录解析给节点配置 IPv6 地址按节点名后缀分配2001:20::suffix/64控制面::8、第一个 worker::1、后续 worker::2/::3/...该分配与 node/tests/k8st/utils/utils.go 中 k8st BGP 测试的ipv6Map保持严格一致因此不能按遍历顺序计数否则会破坏 BGP 对等测试安装 Calicohelm install calico chart -f values.yaml [-f 覆盖值文件] -n tigera-operator --create-namespace基础 values 文件为 hack/test/kind/infra/values.yamlEXTRA_VALUES_FILES中后续文件会覆盖前面的值Helm 深度合并等待 calico-node Ready在部署任何附加组件前必须先等数据平面就绪否则节点保持 NotReady、CNI ADD 失败后续 Pod 无法获得 sandbox安装 calicoctl Pod应用 infra/calicoctl.yaml便于在集群内执行calicoctl命令安装 MetalLBL2 模式为 Gateway API 一致性测试提供 ARP 可达的负载均衡 IP应用 infra/metallb.yaml等待所有 TigeraStatus 变为 Available默认上限 1200 秒可用TIGERASTATUS_WAIT_TIMEOUT覆盖每 60 秒会通过annotate installation default triggerReconciletimestamp触发 operator 重新协调避免其陷入 backoff设置KIND_SKIP_TIGERASTATUS_WAITtrue可跳过该等待应用 Calico 原生 LB 地址池应用 infra/calico-lb-pools.yaml80.15.0.0/24fdff::/64并把 kube-controllers 的 loadbalancer 控制器切换为RequestedServicesOnly模式——只有显式声明loadBalancerClasscalico或 projectcalico.org/* 注解的 Service 才由其分配 IP避免与 MetalLB 争抢未分类的 LB Service这与 e2e/pkg/tests 中 BGP 通告测试的设置保持一致失败诊断脚本通过 trap 捕获非零退出码并调用collect_diags输出 TigeraStatus YAML、operator 日志、所有 Pod 状态以及非 Running/未 Ready Pod 的 describe 与日志含 previous 日志大幅降低 CI 排障成本。基础 values.yaml 要点infra/values.yaml 是 kind 集群安装 Calico 的基准配置其中值得注意的项installation.imagePullPolicy: Always总是重新拉取确保make kind-reload时集群能拾取test-build稳定标签下的新 digestcontrolPlaneReplicas: 1关闭 HA 控制面kubeletVolumePluginPath: None、flexVolumePath: None测试不用 CSI/flexVolume直接关闭cni.installMode: CalicoOnlykind 节点镜像已自带上游 CNI 插件于/opt/cni/bin跳过 cni-plugins init 容器calicoNetwork.linuxPolicySetupTimeoutSeconds: 5加大策略下发超时窗口提升测试稳定性calicoNetwork.nodeAddressAutodetectionV6.cidrs: [2001:20::/64]固定 IPv6 节点地址自动检测范围——kind 的 docker 网络会自动分配 IPv6 ULAfc00:f853:...若用默认firstFound会不确定地选到 ULA 而非部署脚本配置的2001:20::地址导致 k8st BGP 测试对等失败ipPools192.168.0.0/16与fd00:10:244::/64与 kubeadm 集群的 CIDR 对齐apiserver / webhooks / goldmane / whisker 均固定到kind-control-plane节点nodeSelector: kubernetes.io/hostname: kind-control-plane避免测试中禁用/重启网络时影响与 k8s apiserver 的连通性并为各组件设置了精简的资源请求/限制总占用被压到较低水平适配 CI 资源tigeraOperator.image: localhost:5000/calico/operator:test-buildoperator 镜像同样来自本地 registrymanageCRDs: falseCRD 由kind-cluster-create阶段预先创建operator 不再管理zapDevel: true开启 zap 开发级日志让测试失败时能暴露 operator 的 debug 日志与告警堆栈。场景化的 values 覆盖层infra/values-bpf.yamlBPF e2e 作业通过第二个-f叠加。要点包括linuxDataplane: BPF、bpfNetworkBootstrap: Enabledkube-proxy 被禁用、数据平面尚未编程 Service NAT 时靠 bootstrap 引导 apiserver 访问、kubeProxyManagement: Enabled由 operator 关闭 kube-proxy DaemonSetBPF 数据平面取代之、v4 池固定encapsulation: VXLANBPF 不管理 IPIP 的 tunl0 设备且Always模式保证流量真实穿过vxlan.calico以让 host-endpoint 测试生效以及把 calico-node 内存上限从 512Mi 提升到1Gi——内核 5.11 会把 BPF map 内存计入容器 cgroup512Mi 上限下 BPF 数据平面的 NAT/conntrack map 集会导致 OOMKilledinfra/values-felix-routing.yaml仅一行clusterRoutingMode: Felix用于 Felix-routing CI 作业切换集群路由模式infra/values-bird-routing.yaml对应的 BIRD 路由模式覆盖层。六、kind-reload增量热重载真正的开发循环这是日常开发最常用的目标lib.Makefilekind-reload: $(MAKE) -j$(NUM_BUILD_JOBS) kind-build-images $(MAKE) -C $(REPO_ROOT) chart CALICO_API_GROUP$(KIND_CALICO_API_GROUP) KUBECONFIG$(KIND_KUBECONFIG) $(REPO_ROOT)/bin/helm upgrade calico \ $(REPO_ROOT)/bin/tigera-operator-$(GIT_VERSION).tgz \ --reuse-values -n tigera-operator KUBECONFIG$(KIND_KUBECONFIG) $(KUBECTL) delete pods -n calico-system --all KUBECONFIG$(KIND_KUBECONFIG) $(KUBECTL) apply -f $(KIND_INFRA_DIR)/calicoctl.yaml镜像加载是增量的kind-reload与kind-deploy都会比较本地 Docker 镜像 ID 与集群上已有的镜像只传输发生变更的部分。因此标准的编辑/测试循环是make -C component build # 只编译改动的组件 make kind-reload # 增量重载而不是完整 kind-up重载的语义链为重新构建变更的镜像并推送 → 重新生成 chart →helm upgrade --reuse-values保留既有 values→删除 calico-system 下所有 Pod让 kubelet 在imagePullPolicy: Always下按test-build稳定标签重新拉取新 digest → 重新应用 calicoctl。整套动作在数分钟内完成一次改代码→上真集群验证的迭代。七、多集群与销毁KIND_NAME与kind-down集群名默认由KIND_CONFIG文件名推导KIND_NAME $(basename $(notdir $(KIND_CONFIG)))lib.Makefile。因此使用kind-bpf.config时集群名自动变为kind-bpf使用kind-manifests.config时变为kind-manifests。需要同时维护多个集群时直接覆盖make kind-up KIND_NAMEmycluster KIND_CONFIGhack/test/kind/kind-single.configkubeconfig 也按集群名命名KIND_KUBECONFIG $(KIND_DIR)/$(KIND_NAME)-kubeconfig.yamllib.Makefile。销毁集群统一使用make kind-cluster-destroy # 或别名 make kind-down其实现lib.Makefile会先拆除 e2e 外部节点若有幂等、无外部节点时为 no-op然后kind delete cluster——销毁前会优雅排空集群避免内核 netdev unregister 错误这要求先对带 Pod 网络的 Pod 执行 CNI del最后清理 kubeconfig 与.created时间戳文件该文件是kind-cluster-create的依赖标记删除后下次创建会重新走完整流程。八、由 kind 集群串联的测试链路kind 集群基础设施服务于多种测试根 Makefile 中可见一斑kind-migration-testMakefile以KIND_CALICO_API_GROUPcrd.projectcalico.org/v1拉起集群后运行 hack/test/kind/migration/run_test.sh执行 v1→v3 CRD 迁移测试kind-manifest-install-testMakefile用kind-manifests.config建集群经 deploy_manifests.sh从生成清单安装而非 operator再运行 datapath/policy 一致性测试——这是唯一不走 operator 的安装路径e2e-test/e2e-test-bpfMakefile前者kind-up后跑通用一致性测试后者用kind-bpf.configvalues-bpf.yaml建 BPF 集群并额外拉起外部节点external-node.sh up、加载 rapidclient 镜像后跑含 ExternalNode 场景的 BPF e2ekind-load-rapidclientMakefile从 PR 源码构建 rapidclient 辅助镜像并kind load docker-image到节点使包大小测试的服务端 Pod 使用 PR 构建而非公开镜像。九、实战完整开发循环速查# 1. 从仓库根目录完整拉起构建镜像 建集群 部署 Calico make kind-up # 2. 日常改代码后的增量迭代不重建集群 make -C felix build # 以 felix 为例编译改动的组件 make kind-reload # 增量推送变更镜像并滚动重启相关 Pod # 3. 多集群并存时指定名称 make kind-up KIND_NAMEmydev # 4. 验证集群状态 KUBECONFIGhack/test/kind/kind-kubeconfig.yaml hack/test/kind/kubectl get tigerastatus KUBECONFIGhack/test/kind/kind-kubeconfig.yaml hack/test/kind/kubectl get po -A # 5. 收尾销毁 make kind-down十、关键前提与限制执行位置所有 make 目标必须从仓库根目录运行部署脚本也会强校验当前目录为REPO_ROOTdeploy_resources.sh环境依赖需要可用的 Dockerkind 节点与本地 registry 均为容器、curl下载 kubectl与 Go 工具链在容器内go install sigs.k8s.io/kind$(KIND_VERSION)安装 kind版本耦合kind 二进制版本v0.32.0、节点镜像kindest/node:v1.35.5、kubectl 版本$(K8S_VERSION)v1.37.0均在 metadata.mk 定义变更需同步考虑测试兼容性BPF 集群的特殊性kube-proxy 必须为 iptables 模式kind-bpf.config 的注释说明了 eBPF 数据平面与 ipvs 遗留kube-ipvs0设备不兼容且需叠加values-bpf.yaml并提升 calico-node 内存上限。结语Calico 的 kind 开发设施把构建镜像 → 创建集群 → 安装部署 → 增量重载 → 销毁封装成了六个语义清晰的 make 目标配合本地镜像仓库、幂等脚本与完善的失败诊断构成了一个可重复、可并行的本地测试闭环。理解kind-reload的增量机制与imagePullPolicy: Always 稳定test-build标签的配合是高效使用这套工作流的关键——日常迭代用它完整验证再回到kind-up即可在分钟级内完成从源码改动到真实集群验证的全过程。赞分享网络云原生网络安全【免费下载链接】calicoCloud native networking and network security项目地址https://gitcode.com/gh_mirrors/cal/calico点击查看免费下载相关推荐KubeVela 本地 k3d 开发工作流从构建控制器镜像到集群内运行与迭代KubeVela 本地 k3d 开发工作流从构建控制器镜像到集群内运行与迭代 导读 本文介绍 KubeVela 官方仓库提供的一套本地 k3d 开发工作流见云原生DevOps运维微服务GreptimeDB 开发用 Docker 镜像构建完全指南从本地 nightly 二进制到可调试的本地集群测试镜像GreptimeDB 开发用 Docker 镜像构建完全指南从本地 nightly 二进制到可调试的本地集群测试镜像 本指南基于 GreptimeDB 仓库中时序数据库数据库可观测性AIBrix 源码开发指南从构建、代码生成、测试到 Kind 本地部署的完整工作流AIBrix 源码开发指南从构建、代码生成、测试到 Kind 本地部署的完整工作流 AIBrix 是一套面向 GenAI 推理的低成本、可插拔基础设施组件云原生大模型模型推理服务API网关LLM 网关弹性伸缩可观测性后端上一篇claude-seo Schema 结构化数据审计指南Schema.org JSON-LD 检测、校验与生成全流程下一篇Audacity音频编辑从零开始的免费音频处理完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考