Project Calico

Calico for Windows provides the necessary components to run Calico networking and security policies on Windows hosts. The package includes:

• Felix: Calico's per-host daemon responsible for applying Access Control List (ACL) policies.
• Startup scripts and installers: Tools used to install and manage Calico as a collection of Windows services.

The crd.projectcalico.org/v1 package contains the Kubernetes Custom Resource Definition (CRD) type definitions for Calico. These are kubebuilder-annotated Go structs that define the schemas for resources stored in the Kubernetes API server.

This API group includes:

• User-facing resources: NetworkPolicy, GlobalNetworkPolicy, BGPPeer, IPPool, Tier, FelixConfiguration, and others.
• Internal IPAM resources: IPAMBlock, IPAMHandle, IPAMConfig, and BlockAffinity (which embed specs from the internalapi package).

These definitions are used by the Kubernetes backend (libcalico-go/lib/backend/k8s) and its raw CRD client for performing direct operations on Calico resources via the Kubernetes API.

The confd package provides the Windows version of Calico's BGP configuration daemon. This component is responsible for managing BGP configurations on Windows nodes within a Calico network.

For specific installation steps, refer to the official Calico Windows Installation Guide.

Calico is an open-source container networking and security solution. Key capabilities include:

• Data Plane Versatility: Supports eBPF, standard Linux, Windows, and VPP.
• Interoperability: Compatible with multiple distributions, clouds, bare metal, and VMs.
• Advanced Security: Provides granular access controls and WireGuard encryption.
• Networking Protocols: Supports BGP, VXLAN, and service advertisement.
• Kubernetes Integration: Full support for Kubernetes networking policy standards.

The confd component in this repository is a Calico-specific version of the original confd tool. Unlike the original, it is specialized for a single backend type: the Calico datastore.

Its primary purpose is to:

1. Monitor Calico BGP configuration.
2. Autogenerate BIRD BGP templates based on that configuration.

Goldmane is a flow aggregation service that provides a central, aggregated view of network flows in a Kubernetes cluster. It functions by receiving per-node flow data from Felix via gRPC, aggregating those flows across nodes and time, and optionally emitting them to an upstream HTTP endpoint. It also serves flow queries for the Whisker UI.

Data Flow Architecture: Felix (per-node) --gRPC--> FlowCollector --> Goldmane main loop --> BucketRing

• The BucketRing then feeds into:
  • Flows/Statistics gRPC queries
  • Stream subscriptions
  • Emitter (on rollover) $\rightarrow$ upstream HTTP endpoint

networking-calico is a sub-project designed to provide Calico connectivity and security within an OpenStack/Neutron cloud environment. It integrates Calico into OpenStack by providing a Neutron server driver (or plugin) and a modified DHCP agent.

Unlike many Neutron backends that use bridging and tunneling to simulate Layer 2 (L2) connectivity, Calico uses IP routing to provide a flat IP network between workloads (VMs, containers, or bare metal) and uses iptables to enforce fine-grained security policies.

The libcalico-go/lib/apis/v1 package contains legacy type definitions for the original Calico northbound client API. It defines resource structs and configuration types used by the v1 validator, the etcd backend, calicoctl resource loaders, and test utilities.

Warning: This is not the current API. For all new development and standard interactions with Calico, use the public Calico API defined in api/pkg/apis/projectcalico/v3/.

This repository provides the code necessary to integrate Project Calico's networking capabilities into OpenStack/Neutron environments. Calico serves as an open-source solution for virtual networking in cloud data centers.

For comprehensive guides on getting started with a Calico/OpenStack installation and utilizing specific OpenStack/Neutron features, refer to the official documentation at http://docs.projectcalico.org/master.

The Calico eBPF dataplane organizes per-interface BPF programs using a structured layout designed for high performance and policy decoupling. The architecture consists of several key components:

• Attach Mechanisms: Uses clsact, TCX, or netkit to attach programs to interfaces.
• Per-interface Preamble: A standard entry point for every interface.
• Two-tier Jump Maps: Decouples per-endpoint security policies from generic packet-handling logic.
• skb->cb Convention: Uses skb->cb[0] and skb->cb[1] to store continuation addresses for allow/deny logic.
• Fast and Debug Paths: Specialized machinery to optimize packet processing while allowing for debugging.
• Interface State Management: Uses the cali_iface ifstate map to enable attach-gap protection, ensuring no packets are processed without active policy during attachment transitions.

Typha is a fan-out proxy designed to sit between Felix instances and the datastore (such as etcd or the Kubernetes API).

When to use it: It is an optional but recommended component for large clusters, typically those with more than 50 nodes.

Why use it:

• Scalability: It prevents each Felix instance from opening its own direct connection to the datastore.
• Reduced Load: It reduces the total number of upstream watchers and the overall load on the datastore.
• Latency Amortization: Datastore latency is amortized across all downstream Felix instances rather than being incurred per-Felix.

How it works: Typha connects once to the upstream datastore, caches the data, and then fans the stream out to many downstream Felix instances.