Documentation Oracle Cloud Infrastructure

Exemple : installation de Calico et configuration de stratégies réseau

Découvrez comment installer Calico et configurer des stratégies réseau sur un cluster que vous avez créé à l'aide de Kubernetes Engine (OKE).

Le modèle de fonctions de réseau Kubernetes suppose que les conteneurs (pods) possèdent des adresses IP uniques et routables au sein d'un cluster. Dans le modèle de fonctions de réseau Kubernetes, les conteneurs communiquent entre eux à l'aide de ces adresses IP, que les conteneurs soient déployés sur le même noeud du cluster ou sur un noeud différent. Kubernetes a adopté la spécification de l'interface réseau de conteneurs (CNI) pour la gestion des ressources réseau. Le CNI se compose d'une spécification et de bibliothèques pour écrire des plug-ins afin de configurer des interfaces réseau dans des conteneurs Linux, ainsi que d'un certain nombre de plug-ins pris en charge.

Par défaut, les pods acceptent le trafic à partir de n'importe quelle source. Pour améliorer la sécurité du cluster, vous pouvez "isoler" les pods en les sélectionnant dans une stratégie réseau (la ressource NetworkPolicy de Kubernetes). Une stratégie réseau est une spécification du mode de communication des pods entre eux et avec d'autres adresses de réseau. Les ressources NetworkPolicy utilisent des libellés pour sélectionner des pods et définir des règles qui spécifient le trafic autorisé sur les pods sélectionnés. Si un pod donné de l'espace de noms d'un cluster est sélectionné par une stratégie réseau, il rejettera toute connexion non autorisée par une stratégie réseau. Les autres pods de l'espace de noms qui ne sont pas sélectionnés par une stratégie réseau continueront à accepter tout le trafic. Pour plus d'informations sur les stratégies réseau, reportez-vous à la documentation Kubernetes.

Les stratégies réseau sont implémentées par le fournisseur réseau Container Networking Interface. Si vous créez simplement la ressource NetworkPolicy sans qu'elle ne soit implémentée par un fournisseur réseau Container Networking Interface, votre opération n'aura aucun effet. La ressource NetworkPolicy n'est pas implémentée par tous les fournisseurs réseau Container Networking Interface.

Lorsque vous créez des clusters avec Kubernetes Engine, vous sélectionnez un type de réseau. Le type de réseau que vous sélectionnez détermine le fournisseur réseau CNI et le module d'extension CNI associé qui sont utilisés pour la mise en réseau de pod, comme suit :

  • Mise en réseau de pod natif VCN : utilise le module d'extension CNI de mise en réseau de pod natif OCI VCN pour connecter des noeuds de processus actif à des sous-réseaux de pod dans un VCN Oracle Cloud Infrastructure. Par conséquent, les adresses IP de pod au sein d'un VCN sont directement routables à partir d'autres réseaux cloud virtuels connectés (appairés) à ce VCN et à partir de réseaux sur site. Reportez-vous à Utilisation du module d'extension CNI de mise en réseau de pod natif OCI VCN pour la mise en réseau de pod.
  • Superposition de canal : utilise le module d'extension CNI de canal pour encapsuler la communication entre les pods du réseau superposé de canal, un réseau virtuel de superposition privé simple qui attache des adresses IP aux conteneurs. Les pods du réseau superposé privé sont accessibles uniquement à partir d'autres pods du même cluster. Reportez-vous à la section Using the flannel CNI plugin for pod networking.

Le module d'extension CNI de mise en réseau de pod natif OCI VCN et le module d'extension CNI flannel prennent tous deux en charge les exigences de mise en réseau de pod dans Kubernetes. Toutefois, si vous souhaitez améliorer la sécurité des clusters en appliquant des stratégies réseau Kubernetes, vous devez déployer une solution supplémentaire. L'une de ces solutions est le moteur de stratégie réseau Calico (pour d'autres solutions, reportez-vous à la documentation Kubernetes). Kubernetes Engine prend en charge l'application des stratégies réseau via l'intégration à Calico. En activant Calico dans un cluster, vous pouvez définir et appliquer des stratégies de réseau Kubernetes avec le module d'extension de réseau de pod natif OCI VCN ou Flannel CNI.

Calico est une solution de fonctions de réseau open source et de sécurité réseau pour les conteneurs, les machines virtuelles et les charges globales natives basées sur des hôtes. Pour plus d'informations sur Calico, reportez-vous à la documentation Calico.

Remarque

  • Vous pouvez utiliser Calico avec des pools de noeuds gérés, mais pas avec des pools de noeuds virtuels.

  • Seule l'utilisation de Calico open source est prise en charge. L'utilisation de Calico Enterprise n'est pas prise en charge.

  • Si vous avez créé un cluster et sélectionné Superposition de canal comme type de réseau, vous pouvez installer Calico à la place du module d'extension CNI flannel (reportez-vous à Installation de Calico à la place du module d'extension CNI flannel). Cependant, notez que la modification du plug-in CNI de flannel à Calico ne s'applique qu'aux nouveaux noeuds qui sont ensuite créés dans le cluster. Par conséquent, nous vous recommandons de ne pas remplacer flannel par Calico sur les clusters qui ont déjà des noeuds de processus actif existants.

Compatibilité Calico

Le tableau répertorie les versions du module d'extension réseau Calico qu'Oracle a testées avec succès sur les clusters créés à l'aide de Kubernetes Engine. Oracle ne prend en charge que les versions de Calico qui ont été testées avec succès. Pour chaque version de Calico, le tableau indique la version de Kubernetes exécutée sur les clusters lors des tests réussis.

Notez que seule l'utilisation de Calico open source est prise en charge. L'utilisation de Calico Enterprise n'est pas prise en charge.

Pour plus d'informations, reportez-vous à Exemple : installation de Calico et configuration de stratégies réseau.

Version de Calico Testé (et pris en charge) sur des clusters exécutant Kubernetes 1.30 ? Testé (et pris en charge) sur les clusters exécutant Kubernetes 1.31 ? Testé (et pris en charge) sur les clusters exécutant Kubernetes 1.32 ? Testé (et pris en charge) sur les clusters exécutant Kubernetes 1.33 ?
3.25.1 (non testé) (non testé) (non testé) (non testé)
3.26.1 (non testé) (non testé) (non testé) (non testé)
3.26.4 (non testé) (non testé) (non testé) (non testé)
3.27.2 (non testé) (non testé) (non testé) (non testé)
3.28.0 Oui (non testé) (non testé) (non testé)
3.28.2 (non testé) Oui (non testé) (non testé)
3.29.2 (non testé) (non testé) Oui (Non testé)
3.30.0 (Non testé) (Non testé) (Non testé) Oui

Installation de Calico à la place du plugin flannel CNI

Une fois que vous avez créé un cluster amélioré à l'aide de Kubernetes Engine (à l'aide de la console ou de l'API) et sélectionné Surcouche de canal comme type de réseau, vous pouvez ensuite installer Calico sur le cluster pour prendre en charge les stratégies réseau.

Avant d'installer Calico à la place du plugin flannel CNI, vous devez d'abord désactiver le plugin flannel CNI. Notez que la modification du module d'extension CNI de flannel en Calico s'applique uniquement aux nouveaux noeuds créés ultérieurement dans le cluster. Par conséquent, nous vous recommandons de ne pas remplacer Flannel par Calico sur les clusters qui ont déjà des noeuds de processus actif existants.

Pour plus de commodité, les instructions d'installation de Calico sont incluses ci-dessous. Les instructions d'installation de Calico dépendent de la version de Calico. Pour plus d'informations sur l'installation d'autres versions de Calico, reportez-vous toujours à la Documentation d'installation de Calico.

  1. Désactivez l'extension de cluster de plug-ins CNI flannel. Reportez-vous à la section Disabling (and Removing) a Cluster Add-on.

  2. Si vous ne l'avez pas encore fait, suivez les étapes permettant de configurer le fichier de configuration Kubeconfig du cluster et (si nécessaire) de définir la variable d'environnement KUBECONFIG de sorte qu'elle pointe vers le fichier. Vous devez configurer votre propre fichier Kubeconfig. Vous ne pouvez pas accéder à un cluster à l'aide d'un fichier Kubeconfig configuré par un autre utilisateur. Reportez-vous à Configuration de l'accès à un cluster.
  3. Supprimez le jeu de démons flannel de l'espace de noms kube-system en saisissant ce qui suit :
    kubectl delete -n kube-system daemonset kube-flannel-ds

  4. Dans une fenêtre de terminal, téléchargez le manifeste Calico pour la banque de données de l'API Kubernetes en saisissant la commande suivante :

    curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico.yaml -o calico.yaml

    L'URL diffère selon la version de Calico à installer.

  5. Si vous avez sélectionné une image Oracle Linux 8 pour les noeuds de processus actif dans le cluster, définissez une variable d'environnement supplémentaire dans le fichier calico.yaml comme suit :
    1. Ouvrez le fichier calico.yaml dans l'éditeur de texte de votre choix.

    2. Ajoutez la variable d'environnement suivante à la section env pour le conteneur calico-node dans le manifeste du manifeste calico-node DaemonSet :

                  - name: FELIX_IPTABLESBACKEND
              value: "NFT"
    3. Enregistrez et fermez le fichier calico.yaml modifié.

  6. Installez et configurez Calico en saisissant la commande suivante :

    kubectl apply -f calico.yaml

Installation de Calico en parallèle du module d'extension CNI OCI VCN-Native Pod Networking

Une fois que vous avez créé un cluster à l'aide de Kubernetes Engine (à l'aide de la console ou de l'API) et sélectionné Mise en réseau de pod natif VCN comme type de réseau, vous pouvez ensuite installer Calico sur le cluster en même temps que le module d'extension CNI de mise en réseau de pod natif OCI VCN pour prendre en charge les stratégies réseau.

Pour plus de commodité, les instructions d'installation de Calico sont incluses ci-dessous. Les instructions d'installation de Calico dépendent de la version de Calico. Pour plus d'informations sur l'installation d'autres versions de Calico, reportez-vous toujours à la Documentation d'installation de Calico.

  1. Si vous ne l'avez pas encore fait, suivez les étapes permettant de configurer le fichier de configuration Kubeconfig du cluster et (si nécessaire) de définir la variable d'environnement KUBECONFIG de sorte qu'elle pointe vers le fichier. Vous devez configurer votre propre fichier Kubeconfig. Vous ne pouvez pas accéder à un cluster à l'aide d'un fichier Kubeconfig configuré par un autre utilisateur. Reportez-vous à Configuration de l'accès à un cluster.

  2. Dans une fenêtre de terminal, téléchargez le fichier manifeste de Calico réservé aux stratégies pour la banque de données de l'API Kubernetes en saisissant la commande suivante :

    curl https://raw.githubusercontent.com/projectcalico/calico/v3.28.0/manifests/calico-policy-only.yaml -o calico-policy-only.yaml

    L'URL diffère selon la version de Calico à installer.

  3. Le fichier calico-policy-only.yaml inclut des composants Calico qui ne sont pas requis lors de l'utilisation de Calico avec le module d'extension CNI de mise en réseau de pod natif OCI VCN. Vous devez donc enlever ces composants. Vous devez également définir des variables d'environnement supplémentaires.
    1. Ouvrez le fichier calico-policy-only.yaml dans l'éditeur de texte de votre choix.
    2. Supprimez la section initContainers du manifeste de calico-node DaemonSet.
    3. Supprimez les éléments suivants de la section env du conteneur calico-node du manifeste de calico-node DaemonSet :
                # Typha support: controlled by the ConfigMap.
          - name: FELIX_TYPHAK8SSERVICENAME
              valueFrom:
                  configMapKeyRef:
                      name: calico-config
                      key: typha_service_name
    4. Supprimez la section envFrom suivante pour le conteneur calico-node du manifeste de calico-node DaemonSet :
                envFrom:
          - configMapRef:
              # Allow KUBERNETES_SERVICE_HOST and KUBERNETES_SERVICE_PORT to be overridden for eBPF mode.
              name: kubernetes-services-endpoint
              optional: true
    5. Supprimez les volumes suivants de la section volumes du manifeste du fichier calico-node DaemonSet :
      • cni-bin-dir
      • cni-net-dir
      • cni-log-dir

      Avant d'effectuer la modification, la section volumes du manifeste calico-node DaemonSet se présente comme suit :

            ...
      volumes:
        # Used by calico-node.
        - name: lib-modules
          hostPath:
            path: /lib/modules
        - name: var-run-calico
          hostPath:
            path: /var/run/calico
        - name: var-lib-calico
          hostPath:
            path: /var/lib/calico
        - name: xtables-lock
          hostPath:
            path: /run/xtables.lock
            type: FileOrCreate
        - name: sys-fs
          hostPath:
            path: /sys/fs/
            type: DirectoryOrCreate
        - name: bpffs
          hostPath:
            path: /sys/fs/bpf
            type: Directory
        # mount /proc at /nodeproc to be used by mount-bpffs initContainer to mount root cgroup2 fs.
        - name: nodeproc
          hostPath:
            path: /proc
        # Used to install CNI.
        - name: cni-bin-dir
          hostPath:
            path: /opt/cni/bin
        - name: cni-net-dir
          hostPath:
            path: /etc/cni/net.d
        # Used to access CNI logs.
        - name: cni-log-dir
          hostPath:
            path: /var/log/calico/cni
        # Used to create per-pod Unix Domain Sockets
        - name: policysync
          hostPath:
            type: DirectoryOrCreate
            path: /var/run/nodeagent
          ...

      Une fois la modification effectuée, vérifiez que la section volumes du manifeste calico-node DaemonSet ressemble à ce qui suit :

            ...
      volumes:
        # Used by calico-node.
        - name: lib-modules
          hostPath:
            path: /lib/modules
        - name: var-run-calico
          hostPath:
            path: /var/run/calico
        - name: var-lib-calico
          hostPath:
            path: /var/lib/calico
        - name: xtables-lock
          hostPath:
            path: /run/xtables.lock
            type: FileOrCreate
        - name: sys-fs
          hostPath:
            path: /sys/fs/
            type: DirectoryOrCreate
        - name: bpffs
          hostPath:
            path: /sys/fs/bpf
            type: Directory
        # mount /proc at /nodeproc to be used by mount-bpffs initContainer to mount root cgroup2 fs.
        - name: nodeproc
          hostPath:
            path: /proc
        # Used to create per-pod Unix Domain Sockets
        - name: policysync
          hostPath:
            type: DirectoryOrCreate
            path: /var/run/nodeagent
          ...
    6. Supprimez les montages de volume suivants de la section volumeMounts pour le conteneur calico-node dans le manifeste du fichier calico-node DaemonSet :
      • cni-net-dir, y compris le commentaire associé # For maintaining CNI plugin API credentials.
      • cni-log-dir

      Avant d'effectuer la modification, la section volumeMounts se présente comme suit :

                ...
          volumeMounts:
            # For maintaining CNI plugin API credentials.
            - mountPath: /host/etc/cni/net.d
              name: cni-net-dir
              readOnly: false
            - mountPath: /lib/modules
              name: lib-modules
              readOnly: true
            - mountPath: /run/xtables.lock
              name: xtables-lock
              readOnly: false
            - mountPath: /var/run/calico
              name: var-run-calico
              readOnly: false
            - mountPath: /var/lib/calico
              name: var-lib-calico
              readOnly: false
            - name: policysync
              mountPath: /var/run/nodeagent
            # For eBPF mode, we need to be able to mount the BPF filesystem at /sys/fs/bpf so we mount in the
            # parent directory.
            - name: bpffs
              mountPath: /sys/fs/bpf
            - name: cni-log-dir
              mountPath: /var/log/calico/cni
              readOnly: true
              ...

      Une fois la modification effectuée, vérifiez que la section volumeMounts se présente comme suit :

                ...
          volumeMounts:
            - mountPath: /lib/modules
              name: lib-modules
              readOnly: true
            - mountPath: /run/xtables.lock
              name: xtables-lock
              readOnly: false
            - mountPath: /var/run/calico
              name: var-run-calico
              readOnly: false
            - mountPath: /var/lib/calico
              name: var-lib-calico
              readOnly: false
            - name: policysync
              mountPath: /var/run/nodeagent
            # For eBPF mode, we need to be able to mount the BPF filesystem at /sys/fs/bpf so we mount in the
            # parent directory.
            - name: bpffs
              mountPath: /sys/fs/bpf
              ...
    7. Ajoutez les variables d'environnement suivantes pour le conteneur calico-node dans le manifeste de calico-node DaemonSet :
      • FELIX_INTERFACEPREFIX="oci"
      • NO_DEFAULT_POOLS="true"
      • FELIX_CHAININSERTMODE="Append"
      • FELIX_IPTABLESMANGLEALLOWACTION="Return"
      • FELIX_IPTABLESBACKEND="NFT" Remarque : ajoutez cette variable d'environnement uniquement si vous avez sélectionné une image Oracle Linux 8 pour les noeuds de processus actif du cluster.

      Avant d'effectuer la modification, la section des variables d'environnement de conteneur calico-node (env:) du manifeste calico-node DaemonSet se présente comme suit :

            ...
      containers:
        # Runs calico-node container on each Kubernetes node. This
        # container programs network policy and routes on each
        # host.
        - name: calico-node
          image: docker.io/calico/node:v3.28.0
          imagePullPolicy: IfNotPresent
          env:
            # Use Kubernetes API as the backing datastore.
            - name: DATASTORE_TYPE
              value: "kubernetes"
            # Configure route aggregation based on pod CIDR.
            - name: USE_POD_CIDR
              value: "true"
            # Wait for the datastore.
            - name: WAIT_FOR_DATASTORE
              value: "true"
            # Set based on the k8s node name.
            - name: NODENAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            # Don't enable BGP.
            - name: CALICO_NETWORKING_BACKEND
              value: "none"
            # Cluster type to identify the deployment type
            - name: CLUSTER_TYPE
              value: "k8s"
            # Non-calico CNI, disable credential management.
            - name: CALICO_MANAGE_CNI
              value: "false"
            # The default IPv4 pool to create on startup if none exists. Pod IPs will be
            # chosen from this range. Changing this value after installation will have
            # no effect. This should fall within `--cluster-cidr`.
            # - name: CALICO_IPV4POOL_CIDR
            #   value: "192.168.0.0/16"
            # Disable file logging so `kubectl logs` works.
            - name: CALICO_DISABLE_FILE_LOGGING
              value: "true"
            # Set Felix endpoint to host default action to ACCEPT.
            - name: FELIX_DEFAULTENDPOINTTOHOSTACTION
              value: "ACCEPT"
            # Disable IPv6 on Kubernetes.
            - name: FELIX_IPV6SUPPORT
              value: "false"
            - name: FELIX_HEALTHENABLED
              value: "true"         
            ...

      Une fois la modification effectuée, vérifiez que la section des variables d'environnement de conteneur calico-node (env:) du manifeste calico-node DaemonSet se présente comme suit :

            ...
      containers:
        # Runs calico-node container on each Kubernetes node. This
        # container programs network policy and routes on each
        # host.
        - name: calico-node
          image: docker.io/calico/node:v3.28.0
          imagePullPolicy: IfNotPresent
          env:
            # Use Kubernetes API as the backing datastore.
            - name: DATASTORE_TYPE
              value: "kubernetes"
            # Configure route aggregation based on pod CIDR.
            - name: USE_POD_CIDR
              value: "true"
            # Wait for the datastore.
            - name: WAIT_FOR_DATASTORE
              value: "true"
            # Set based on the k8s node name.
            - name: NODENAME
              valueFrom:
                fieldRef:
                  fieldPath: spec.nodeName
            # Don't enable BGP.
            - name: CALICO_NETWORKING_BACKEND
              value: "none"
            # Cluster type to identify the deployment type
            - name: CLUSTER_TYPE
              value: "k8s"
            # Non-calico CNI, disable credential management.
            - name: CALICO_MANAGE_CNI
              value: "false"
            # The default IPv4 pool to create on startup if none exists. Pod IPs will be
            # chosen from this range. Changing this value after installation will have
            # no effect. This should fall within `--cluster-cidr`.
            # - name: CALICO_IPV4POOL_CIDR
            #   value: "192.168.0.0/16"
            # Disable file logging so `kubectl logs` works.
            - name: CALICO_DISABLE_FILE_LOGGING
              value: "true"
            # Set Felix endpoint to host default action to ACCEPT.
            - name: FELIX_DEFAULTENDPOINTTOHOSTACTION
              value: "ACCEPT"
            # Disable IPv6 on Kubernetes.
            - name: FELIX_IPV6SUPPORT
              value: "false"
            - name: FELIX_HEALTHENABLED
              value: "true"
            - name: FELIX_INTERFACEPREFIX
              value: "oci"
            - name: NO_DEFAULT_POOLS
              value: "true"
            - name: FELIX_CHAININSERTMODE
              value: "Append"
            - name: FELIX_IPTABLESMANGLEALLOWACTION
              value: "Return"   
            - name: FELIX_IPTABLESBACKEND
              value: "NFT"         
            ...
    8. Enregistrez et fermez le fichier calico-policy-only.yaml modifié.

  4. Installez et configurez Calico en saisissant la commande suivante :

    kubectl apply -f calico-policy-only.yaml

Configuration de stratégies réseau

Après avoir installé Calico sur un cluster créé à l'aide de Kubernetes Engine, vous pouvez créer des ressources NetworkPolicy Kubernetes pour isoler les pods si nécessaire.

Pour obtenir des exemples de stratégies réseau et découvrir comment les utiliser, reportez-vous à la documentation Calico et plus spécifiquement aux rubriques suivantes :

Les exemples varient selon la version de Calico que vous avez installée.