云原生教程【免费下载链接】kubernetes-handbookKubernetes Handbook Kubernetes指南 https://kubernetes.feisky.xyz项目地址https://gitcode.com/gh_mirrors/kub/kubernetes-handbook点击查看免费下载Calico 是 Kubernetes 生态中极具代表性的纯三层容器网络方案它不需要 Overlay 隧道而是在每个计算节点上通过 Linux 内核实现 vRouter借助 BGP 协议在节点间分发路由并用 iptables 提供丰富的网络策略能力。本文以 extension/network/calico.md 为主体结合本仓库中 kubeadm 安装文档、CNI 与 Network Policy 相关章节以及 examples/calico/ 下的真实示例完整讲解 Calico 的核心架构、IP-in-IP 模式、CNI/CNM 接入方式、在 Kubernetes 中的部署步骤、进程与配置文件细节以及它的适用边界与已知不足帮助你掌握一套可直接落地、可排障、可二次定制的 Calico 实战知识体系。Calico 是什么纯三层、无 Overlay 的容器网络方案Calico 是一个纯三层L3的数据中心网络方案核心设计目标是不依赖 Overlay。它与 OpenStack、Kubernetes、AWS、GCE 等 IaaS 与容器平台都有良好的集成在 extension/network/README.md 的网络插件清单中与 Flannel、Weave Net、OVN 并列是官方网络插件之外最主要的第三方选择之一。其工作原理可概括为三个关键点节点内高效转发Calico 在每一个计算节点利用 Linux Kernel 实现了一个高效的 vRouter 来负责数据转发vRouter 直接做三层路由转发不经过隧道封装节点间 BGP 路由分发每个 vRouter 通过 BGP 协议把自己上运行的 workload 的路由信息向整个 Calico 网络内传播——小规模部署可以直接互联full mesh大规模下可通过指定的 BGP Route Reflector 来完成集中式路由分发。这样保证最终所有 workload 之间的数据流量都是通过 IP 路由的方式完成互联的基于 iptables 的策略控制Calico 基于 iptables 提供了丰富而灵活的网络 Policy通过各个节点上的 ACLs 来提供 workload 的多租户隔离、安全组以及其他可达性限制等功能。与 Flannel 这类基于 UDP/VXLAN 封装的 Overlay 方案不同Calico 节点组网可以直接利用数据中心的网络结构无论是 L2 或者 L3不需要额外的 NAT、隧道或者 Overlay Network这正是它在数据中心场景中被广泛选用的核心原因。注意本仓库中 extension/network/README.md 使用的安装命令是 v2.1 的 hosted 部署方式kubectl apply -f http://docs.projectcalico.org/v2.1/getting-started/kubernetes/installation/hosted/kubeadm/1.6/calico.yaml而 extension/network/calico.md 与 setup/cluster/kubeadm.md 使用的是 v3.x 的 rbac-kdd calico.yaml 组合。实际使用时请以你安装的 Calico 版本对应的官方安装清单为准两者在网络模型与组件构成上是同一套架构。Calico 架构四大核心组件与 IPAM 插件Calico 主要由Felix、etcd、BGP ClientBIRD以及 BGP Route ReflectorBIRD组成各组件分工如下组件角色定位核心职责FelixCalico Agent跑在每台需要运行 workload 的节点上负责配置路由及 ACLs 等信息确保 Endpoint 的连通状态etcd分布式键值存储负责网络元数据一致性确保 Calico 网络状态的准确性BGP ClientBIRD每节点上的 BGP 路由客户端负责把 Felix 写入 Kernel 的路由信息分发到当前 Calico 网络确保 workload 间的通信有效BGP Route ReflectorBIRD大规模部署时的集中式路由分发点摒弃所有节点互联的 mesh 模式通过一个或多个 Route Reflector 完成集中式的路由分发calico/calico-ipamKubernetes 的 CNI 插件作为 CNI 插件与 IPAM 插件为 Pod 配置网络并分配 IP整体架构如下图所示Calico 整体架构示意图展示 Felix、etcd、BIRD 与 Route Reflector 的协作关系从控制平面与数据平面两个角度看这套架构控制平面etcd 保存全网网络状态如 IP Pool、Profile、Endpoint 等元数据Felix 将状态落成内核路由与 iptables 规则BIRD 将这些路由通过 BGP 广播给对等节点或 Route Reflector数据平面workload 发出的报文在节点内核中直接按路由表转发由 vRouter内核路由 iptables完成逐跳路由不存在二次封装开销。正是这种控制面集中、数据面分布式直转的设计让 Calico 在性能与可扩展性上具备天然优势也让 BGP Route Reflector 成为大规模集群数百上千节点部署时的必选项——避免 full mesh 模式下 BGP 会话数量随节点数平方级增长。IP-in-IP面向 L3 Fabric 物理网络的封装选项Calico 控制平面的设计要求物理网络得是L2 Fabric这样 vRouter 之间都是直接可达的路由不需要把物理设备当做下一跳。但现实中有大量数据中心采用 L3 Fabric三层路由网络此时节点间的直连假设不成立。为此Calico 推出了IP-in-IPIPinIP选项它把 workload 的 IP 报文再包一层 IP 头通过隧道在 L3 物理网络上传输从而在不引入完整 Overlay 方案的前提下让 Calico 也能运行在 L3 Fabric 之上。这与完全基于 Overlay如 VXLAN、UDP 封装的方案不同——IP-in-IP 只增加一层 IP 封装封装与解封装都发生在内核中开销远低于用户态隧道。从 extension/network/calico.md 的表述可以推断IP-in-IP 是控制面为 L2 Fabric 设计这一默认假设下的兼容选项适用于无法改造为 L2 直连的既有网络环境。Calico CNI 与 CNM两大容器网络接入方式Calico 同时支持 Kubernetes 生态的CNI接口和 Docker 生态的CNMContainer Network Model接口。CNI 插件calico / calico-ipam在 Kubernetes 中Calico 以 CNI 插件形式接入核心组件为calico网络配置插件与calico-ipamIP 分配插件。CNI 的工作模型是容器运行时先创建好 network namespace再调用 CNI 插件为这个 netns 配置网络其后才启动容器内进程——Kubernetes Pod 中所有容器共享 pause 容器的网络命名空间具体机制参见 extension/network/cni.md。在 Pod 创建过程中kubelet 先创建 pause 容器生成 network namespace调用网络 CNI driverCNI driver 根据配置调用具体的 CNI 插件此处即 calicocalico 插件为 pause 容器配置网络接口并分配 IPPod 中其他容器随后复用该网络。Calico 的 CNI 插件实现细节见 extension/network/cni.md 中对 CNI 规范ADD/DEL 接口、IPAM 插件的介绍。CNM 集成Pool 与 Profile对于 Docker CNM 网络Calico 通过Pool和Profile两个概念实现Pool定义可用于 Docker Network 的 IP 资源范围比如10.0.0.0/8或者192.168.0.0/16Profile定义 Docker Network Policy 的集合由 tags 和 rules 组成。每个 Profile 默认拥有一个和 Profile 名字相同的 Tag每个 Profile 可以有多个 Tag以 List 形式保存。这套设计把IP 资源池与访问控制策略解耦使同一套 Calico 数据平面既能服务 KubernetesCNI NetworkPolicy也能服务传统 Docker 网络CNM Profile。在 Kuberneteskubeadm中部署 Calico完整实操对于使用 kubeadm 创建的 Kubernetes 集群安装 Calico 需要先保证 kubeadm 的 CIDR 参数与 Calico 配置一致--pod-network-cidr192.168.0.0/16--service-cidr10.96.0.0/12不能与 Calico 网络重叠然后依次应用两个清单v3.1 部署方式与 setup/cluster/kubeadm.md 中的 calico 章节一致kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml第一条命令部署 Kubernetes datastore driverKDD模式所需的 RBAC 资源第二条命令部署完整的 Calico 网络组件。本仓库 concepts/objects/network-policy.md 中的 calico 示例还提示了另一处关键前提kubelet 需要以 CNI 方式启动kubelet --network-plugincni --cni-conf-dir/etc/cni/net.d --cni-bin-dir/opt/cni/bin ...且 CNI 的 pod-network-cidr 需与 kubeadm 初始化参数保持一致。部署后集群内出现的组件执行上述安装后会在 Pod 中启动Calico-etcd并在所有 Node 上启动bird6、felix 以及 confd同时把 CNI 网络配置为 calico 插件。部署完成后各节点上的进程分布如下图所示Calico 在 Kubernetes 集群中的组件部署示意图展示 calico-etcd、felix、bird、bird6、confd 的分布节点上的 Calico 相关进程部署完成后可以在节点上用ps -ef | grep calico | grep -v grep看到如下进程实际输出来自 extension/network/calico.md# Calico 相关进程 $ ps -ef | grep calico | grep -v grep root 9012 8995 0 14:51 ? 00:00:00 /bin/sh -c /usr/local/bin/etcd --namecalico --data-dir/var/etcd/calico-data --advertise-client-urlshttp://$CALICO_ETCD_IP:6666 --listen-client-urlshttp://0.0.0.0:6666 --listen-peer-urlshttp://0.0.0.0:6667 root 9038 9012 0 14:51 ? 00:00:01 /usr/local/bin/etcd --namecalico --data-dir/var/etcd/calico-data --advertise-client-urlshttp://10.146.0.2:6666 --listen-client-urlshttp://0.0.0.0:6666 --listen-peer-urlshttp://0.0.0.0:6667 root 9326 9325 0 14:51 ? 00:00:00 bird6 -R -s /var/run/calico/bird6.ctl -d -c /etc/calico/confd/config/bird6.cfg root 9327 9322 0 14:51 ? 00:00:00 confd -confdir/etc/calico/confd -interval5 -watch --log-leveldebug -nodehttp://10.96.232.136:6666 -client-key -client-cert -client-ca-keys root 9328 9324 0 14:51 ? 00:00:00 bird -R -s /var/run/calico/bird.ctl -d -c /etc/calico/confd/config/bird.cfg root 9329 9323 1 14:51 ? 00:00:04 calico-felix这些进程印证了上文架构分析的落地形态etcd监听 6666/6667 端口Calico 的分布式元数据存储--data-dir/var/etcd/calico-data保存网络状态calico-felixCalico Agent负责将网络状态写入内核路由与 iptablesbird/bird6IPv4 / IPv6 的 BGP 路由客户端通过/var/run/calico/bird.ctlbird6 为bird6.ctl与 Felix 交互配置来自/etc/calico/confd/config/bird.cfgconfd以 5 秒间隔-interval5 -watch监听 etcd-nodehttp://10.96.232.136:6666动态生成 bird 与 felix 的配置。从进程关系可以看到 Calico 的配置链路etcd状态源→ confd配置生成→ felix / bird路由与策略执行。CNI 网络插件配置文件kubelet 会从/etc/cni/net.d/目录读取 CNI 配置。Calico 安装后生成10-calico.conf# CNI 网络插件配置 $ cat /etc/cni/net.d/10-calico.conf { name: k8s-pod-network, cniVersion: 0.1.0, type: calico, etcd_endpoints: http://10.96.232.136:6666, log_level: info, ipam: { type: calico-ipam }, policy: { type: k8s, k8s_api_root: https://10.96.0.1:443, k8s_auth_token: token }, kubernetes: { kubeconfig: /etc/cni/net.d/calico-kubeconfig } }各字段含义与调优要点name网络名称k8s-pod-network即集群 Pod 网络typeCNI 插件类型calico对应/opt/cni/bin/下的 calico 二进制etcd_endpointsCalico 数据存储地址即上文进程中的10.96.232.136:6666log_level插件日志级别可调为debug便于排障ipam.typecalico-ipam表示由 calico-ipam 插件负责 Pod IP 分配policy.typek8s表示策略数据来自 Kubernetes APIk8s_api_root指向 apiserver 的 443 端口k8s_auth_token为访问凭据kubernetes.kubeconfig指向 CNI 插件访问 Kubernetes 集群的 kubeconfig 文件。配套的calico-kubeconfig文件内容如下extension/network/calico.md 中的原始配置$ cat /etc/cni/net.d/calico-kubeconfig # Kubeconfig file for Calico CNI plugin. apiVersion: v1 kind: Config clusters: - name: local cluster: insecure-skip-tls-verify: true users: - name: calico contexts: - name: calico-context context: cluster: local user: calico current-context: calico-context注意其中的insecure-skip-tls-verify: true——CNI 插件通过该 kubeconfig 访问 apiserver 时跳过 TLS 证书校验在安全要求较高的生产环境中应替换为正式的 CA 证书与客户端证书并将该 kubeconfig 的访问权限严格限制在 root 用户。Calico 网络策略实战从 iptables 到 Kubernetes NetworkPolicyCalico 的策略能力建立在 iptables 之上Felix 将网络策略翻译成各节点上的 ACL 规则从而实现多租户隔离、安全组与可达性限制。因此 Calico 是少数原生支持 Kubernetes NetworkPolicy 的网络插件之一——在 extension/network-policy.md 列出的支持插件中Calico 排在首位与 Cilium、Romana、Weave Net 并列。从 NetworkPolicy 到 iptables 的实现链路一个支持 Network Policy 的网络扩展需要包含两个组件CNI 网络插件负责给 Pod 配置网络接口和 Policy controller监听 Network Policy 的变化并将 Policy 应用到相应网络接口。Calico 中这两个职责分别由 calico CNI 插件和 felix 承担felix 作为 Policy controller 监听 Kubernetes API 中的 NetworkPolicy 资源动态下发 iptables 规则。一个完整的策略示例concepts/objects/network-policy.md 以 calico 为例演示了完整流程。首先部署一个 nginx 服务$ kubectl run nginx --imagenginx --replicas2 deployment nginx created $ kubectl expose deployment nginx --port80 service nginx exposed此时其他 Pod 可以正常访问 nginx无策略限制。随后创建 NetworkPolicy隔离 default namespace 中带有roledb标签的 Pod允许rolefrontend标签的 Pod 访问其 6379 端口、允许projectmyprojects标签的 namespace 内 Pod 访问其 6379 端口、允许其访问10.0.0.0/24网段的 TCP 5987 端口。策略一经下发Calico 的 felix 立即在相关节点上生成对应的 iptables 规则未匹配的流量将被默认拒绝。查看 GlobalNetworkPolicy 的 Log 动作日志由于 Calico 的策略基于 iptablescalico-node容器的日志只会显示它自身容器的输出而不会显示 GlobalNetworkPolicy 中Log动作产生的数据包日志。本仓库的 examples/calico/calico-packet-logs.yaml 提供了一个专门抓取这些日志的示例其思路值得借鉴定义一个GlobalNetworkPolicy对 TCP/UDP 的 Ingress 与 Egress 流量先执行action: Log再执行action: Allow即记录但不拦截apiVersion: crd.projectcalico.org/v1 kind: GlobalNetworkPolicy metadata: name: calico-log spec: egress: - action: Log destination: {} protocol: TCP source: {} - action: Log destination: {} protocol: UDP source: {} - action: Allow ingress: - action: Log destination: {} protocol: TCP source: {} - action: Log destination: {} protocol: UDP source: {} - action: Allow types: - Ingress - Egress部署一个 DaemonSet以 hostPath 方式挂载宿主机的/var/log用tail -f /var/log/syslog | grep calico-packet:过滤 iptables LOG 动作写入的系统日志apiVersion: apps/v1 kind: DaemonSet metadata: name: calico-packet-logs namespace: default spec: selector: matchLabels: app: calico-packet-logs template: metadata: labels: app: calico-packet-logs spec: containers: - name: calico-packet-logs image: alpine command: - sh - -c - tail -f /var/log/syslog | grep calico-packet: volumeMounts: - name: iptables-logs mountPath: /var/log readOnly: true volumes: - name: iptables-logs hostPath: path: /var/log nodeSelector: beta.kubernetes.io/os: linux部署后用kubectl logs calico-packet-logs-xxxx查看策略日志输出。这套方案把策略执行与日志观测分离对排查策略误拒、验证安全规则是否按预期生效非常实用完整的部署与查询步骤见 examples/calico/README.md。Calico 数据转发流程Calico 网络中 workload 间的通信完全依赖 IP 路由完成。数据包从源 Pod 出发后经源节点内核路由转发到目标节点再由目标节点送达目标 Pod全程无隧道封装路由信息由 BIRD 通过 BGP 在对等节点间传播具体转发链路如下图所示Calico 数据包转发流程示意图展示 vRouter 与 BGP 路由分发下的跨节点通信路径从网络模型看该流程完全符合 extension/network/README.md 中描述的 Kubernetes 网络模型集群内所有 Pod 处于一个直接连通的扁平网络中容器之间、Node 与容器之间无需 NAT 即可直接互访容器看到的 IP 与其他容器看到的一致。Calico 的不足与适用边界尽管 Calico 在性能与策略能力上优势明显extension/network/calico.md 也明确指出它的三个主要限制不支持 VRFCalico 是三层实现不提供基于 VRF 的虚拟路由转发能力不支持多租户网络的隔离功能在多租户场景下存在网络安全问题。虽然 Calico 有基于 iptables 的策略隔离但它并不提供传统 SDN 意义上按租户隔离的虚拟网络VPC抽象多租户共享同一张 L3 网络时的安全边界需要靠策略严格约束控制平面要求物理网络为 L2 Fabric默认设计假设 vRouter 间直接可达路由不需要把物理设备当做下一跳在 L3 Fabric 环境中需启用 IP-in-IP 选项来适配。因此选型时应结合场景判断若追求原生三层性能、无需 Overlay、强 NetworkPolicy 能力Calico 是首选若需要多租户虚拟网络隔离如每个租户独立的 L2 网络、VLAN/VXLAN 抽象则 extension/network/contiv.md 中介绍的 Contiv 等方案在直接提供多租户网络方面更有优势若希望以最小的配置成本获得 Overlay 网络extension/network/flannel.md 中的 Flannel 则更轻量。三者在本仓库 extension/network/README.md 中有并列介绍可对照取舍。小结Calico 以内核 vRouter BGP 路由分发 iptables 策略三件套提供了一条不同于 Overlay 的纯三层容器网络路线控制面由 etcd、Felix、BIRD 与 Route Reflector 构成数据面完全走 IP 路由在 Kubernetes 中通过 calico/calico-ipam 这对 CNI 插件接入配合 kubeadm 的 CIDR 约束即可快速部署其策略能力既能满足 Kubernetes NetworkPolicy也能通过 GlobalNetworkPolicy 与 iptables LOG 实现深度可观测。理解它的架构组件、配置文件与转发路径是在生产集群中排障、调优与二次开发的基础——结合本仓库的 extension/network/calico.md、setup/cluster/kubeadm.md、concepts/objects/network-policy.md 与 examples/calico/ 示例即可形成从原理到实操的完整闭环。赞分享云原生教程【免费下载链接】kubernetes-handbookKubernetes Handbook Kubernetes指南 https://kubernetes.feisky.xyz项目地址https://gitcode.com/gh_mirrors/kub/kubernetes-handbook点击查看免费下载相关推荐Kubernetes 网络插件 Romana 实战解析以纯三层路由聚合替代 OverlayKubernetes 网络插件 Romana 实战解析以纯三层路由聚合替代 Overlay 本文围绕本仓库 Romana 网络插件文档 https://lin云原生教程Kniteditor核心功能解析让你的针织设计效率提升10倍Kniteditor核心功能解析让你的针织设计效率提升10倍 Kniteditor是一款专为针织设计打造的高效编辑器旨在帮助设计师和手工爱好者轻松创建、编辑桌面应用Kubernetes 网络模型与 CNI 插件深度解析从 flannel、Calico 到 CiliumKubernetes 网络模型与 CNI 插件深度解析从 flannel、Calico 到 Cilium Kubernetes 网络是构建集群时绕不开的核心话教程云原生容器编排上一篇Workflow Core 1.8.0 版本解析Elasticsearch 搜索索引插件与 Action 式 Input/Output 映射下一篇深入理解 dnd-kit/abstractdnd-kit 拖拽框架的抽象核心层创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考