Migrate Calico to an operator-managed installation

Big picture

Switch your Calico installation from manifest-based resources to an installation managed by the Calico operator.

Value

The Calico operator provides a number of advantages over traditional manifest-based installation of Calico resources, including but not limited to:

  • Automatic platform and configuration detection.
  • A simplified upgrade procedure.
  • Well-defined split between end-user configuration and product code.
  • Resource reconciliation and lifecycle management.

Concepts

Operator vs manifest based installations

Most Calico installations in the past have been manifest-based, meaning that Calico is installed directly as a set of Kubernetes resources in a .yaml file.

The Calico operator is a Kubernetes application that installs and manages the lifecycle of a Calico installation by creating and updating Kubernetes resources such as Deployments, DaemonSets, Secrets, without the need for direct user intervention.

There are a few key differences to be aware of, if you are familiar with manifest-based installs and are looking to use the operator:

  • Calico resources will be migrated from the kube-system namespace used by the Calico manifests to a new calico-system namespace.
  • Calico resources will no longer be hand-editable, as the Calico operator will reconcile undesired changes to maintain an expected state.
  • Calico resources can instead be configured via the operator.tigera.io APIs.

Operator migration

For new clusters, you can simply follow the steps in the quickstart guide to get started with the operator.

For existing clusters using the calico.yaml manifest to install Calico, upon installing the operator, it will detect the existing Calico resources on the cluster and calculate how to take ownership of them. The operator will maintain existing customizations, if supported, and warn about any unsupported configurations that it detects.

Before you begin

  • Ensure that your Calico installation is configured to use the Kubernetes datastore. If your cluster uses etcdv3 directly, you must follow the datastore migration procedure before following this document.
  • Migration to Calico v3.27 operator-managed installation is supported only from Calico v3.27 manifest-based installation

How To

Migrate a cluster to the operator

Migrate Calico to an operator-managed installation - 图1note

Do not edit or delete any resources in the kube-system Namespace during the following procedure as it may interfere with the upgrade.

  1. Install the Tigera Calico operator and custom resource definitions.

    1. kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/projectcalico/calico/v3.27.4/manifests/tigera-operator.yaml

    Migrate Calico to an operator-managed installation - 图2note

    Due to the large size of the CRD bundle, kubectl apply might exceed request limits. Instead, use kubectl create or kubectl replace.

  2. Trigger the operator to start a migration by creating an Installation resource. The operator will auto-detect your existing Calico settings and fill out the spec section.

    1. kubectl create -f - <<EOF
    2. apiVersion: operator.tigera.io/v1
    3. kind: Installation
    4. metadata:
    5.   name: default
    6. spec: {}
    7. EOF

  3. Monitor the migration status with the following command:

    1. kubectl describe tigerastatus calico

  4. Now that the migration is complete, you will see Calico resources have moved to the calico-system namespace.

    1. kubectl get pods -n calico-system

    You should see output like this:

    1. NAME                                       READY   STATUS    RESTARTS   AGE
    2. calico-kube-controllers-7688765788-9rqht   1/1     Running   0          17m
    3. calico-node-4ljs6                          1/1     Running   0          14m
    4. calico-node-bd8mc                          1/1     Running   0          14m
    5. calico-node-cpbd8                          1/1     Running   0          14m
    6. calico-node-jl97q                          1/1     Running   0          14m
    7. calico-node-xw2nj                          1/1     Running   0          14m
    8. calico-typha-57bf79f96f-6sk8x              1/1     Running   0          14m
    9. calico-typha-57bf79f96f-g99s9              1/1     Running   0          14m
    10. calico-typha-57bf79f96f-qtchs              1/1     Running   0          14m

    At this point, the operator will have automatically cleaned up any Calico resources in the kube-system namespace. No manual cleanup is required.