Calico Network Operator Overview (Tigera Operator)

Starting with StarlingX r13, the Calico networking stack is managed by the Tigera Operator (tigera-operator). This replaces the previous manifest-based installation and manages all Calico resources through Kubernetes Custom Resources (CRs).

The Tigera Operator is deployed during platform bootstrap and provides:

  • Automatic platform and configuration detection.

  • A simplified upgrade procedure.

  • A well-defined split between end-user configuration and product default configuration.

  • Resource reconciliation and lifecycle management.

Calico Operator Architecture and Namespaces

The operator organizes Calico components across the following namespaces:

Namespace

Contents

tigera-operator

The operator deployment.

calico-system

Calico networking pods (calico-node, calico-typha, calico-kube-controllers).

tigera-gateway

Envoy Gateway pods (present only when a GatewayAPI CR is created).

Component versions in StarlingX r13:

Component

Version

Tigera Operator

v1.40.12

Calico

v3.31.5

Kubernetes

v1.35.2+

The operator continuously reconciles the running state to match the desired state expressed in the Installation and other Calico CRs. Changes made directly to operator-managed resources (pods, deployments, daemonsets) are reverted. Always configure Calico through the CRs.

Upgrading Calico with the Tigera Operator

The Calico Operator integrates with the StarlingX Kubernetes upgrade framework. For systems upgrading from a manifest-based Calico deployment:

  • Migration to the operator model is performed automatically as part of the standard platform upgrade procedure, during the kube-upgrade-networking step.

  • No manual intervention is required.

  • Existing network configuration is preserved during migration.

No manual Calico commands are required. For the orchestrated upgrade procedure, see Kubernetes Upgrade using Cloud Orchestration.

Calico Operator Limitations

  • The additional Calico services exposed through the operator (APIServer, Goldmane, Whisker, and CSI Node Driver) are not validated or supported in StarlingX. Only the core Calico networking and the optional Calico Ingress Gateway are supported.

  • StarlingX does not currently provide a native LoadBalancer implementation. As a result, Gateway services show EXTERNAL-IP: <pending>. Traffic remains accessible through NodePort. If external IP assignment is required, a third-party LoadBalancer provider must be deployed separately by the user.