Documentation sur Oracle Cloud Infrastructure

Exemple : Installation de Calico et configuration de politiques de réseau

Découvrez comment installer Calico et configurer des politiques de réseau sur une grappe que vous avez créée à l'aide de Kubernetes Engine (OKE).

Le modèle de réseau Kubernetes suppose que les conteneurs (pods) possèdent des adresses IP uniques et routables dans une grappe. Dans le modèle de réseau Kubernetes, les conteneurs communiquent entre eux à l'aide de ces adresses IP, qu'ils soient déployés sur le même noeud d'une grappe ou sur un autre noeud. Kubernetes a adopté la spécification CNI (Container Network Interface) pour la gestion des ressources réseau. Le CNI se compose d'une spécification et de bibliothèques pour l'écriture de plugins pour configurer des interfaces réseau dans des conteneurs Linux, ainsi que d'un certain nombre de plugins pris en charge.

Par défaut, les pods acceptent le trafic provenant de n'importe quelle source. Pour améliorer la sécurité des grappes, il est possible d'isoler les pods en les sélectionnant dans une politique de réseau (ressource NetworkPolicy de Kubernetes). Une politique de réseau est une spécification de la manière dont les groupes de pods sont autorisés à communiquer les uns avec les autres et avec les autres points d'extrémité du réseau. Les ressources NetworkPolicy utilisent des étiquettes pour sélectionner les pods et pour définir des règles qui déterminent le trafic autorisé vers les pods sélectionnés. Si une ressource NetworkPolicy d'un espace de noms d'une grappe sélectionne un pod, celui-ci rejette toutes les connexions non autorisées par une ressource NetworkPolicy. Les autres pods de l'espace de noms qui ne sont pas sélectionnés par la ressource NetworkPolicy continuent d'accepter tout le trafic. Pour plus d'informations sur les politiques de réseau, voir la documentation sur Kubernetes.

Les politiques de réseau sont mises en oeuvre par le fournisseur de réseau CNI. En l'absence de fournisseur de réseau CNI, la création de la ressource NetworkPolicy n'a aucun effet. Notez que tous les fournisseurs de réseau CNI ne mettent pas en oeuvre la ressource NetworkPolicy.

Lorsque vous créez des grappes avec Kubernetes Engine, vous sélectionnez un type de réseau. Le type de réseau que vous sélectionnez détermine le fournisseur de réseau CNI et le plugiciel CNI associé utilisés pour le réseau de pods, comme suit :

  • Réseau de pods natif du VCN : Utilise le plugiciel CNI de réseau de pods natif du VCN OCI pour connecter les noeuds de travail aux sous-réseaux de pods d'un VCN Oracle Cloud Infrastructure. Par conséquent, les adresses IP de pod dans un VCN sont directement routables à partir d'autres réseaux en nuage virtuels connectés (appairés) à ce VCN et à partir de réseaux sur place. Voir Utilisation du plugiciel CNI de réseau de pods natif du VCN pour OCI pour le service de réseau de pods.
  • Surcouche de canal : Utilise le plugiciel CNI de canal pour encapsuler la communication entre les pods du réseau de surcouche de canal, un réseau virtuel de simple surcouche privée qui attache des adresses IP aux conteneurs. Les pods du réseau superposé privé ne sont accessibles qu'à partir d'autres pods de la même grappe. Voir Utilisation du plugiciel CNI flannel pour la gestion de réseau de pods.

Le plugiciel CNI de réseau de pods natifs du VCN OCI et le plugiciel CNI flannel prennent entièrement en charge les exigences de réseau de pods dans Kubernetes. Toutefois, si vous voulez améliorer la sécurité des grappes en appliquant les politiques de réseau Kubernetes, vous devez déployer une solution supplémentaire. L'une de ces solutions est le moteur de politique de réseau Calico (pour d'autres solutions, reportez-vous à la documentation sur Kubernetes). Kubernetes Engine prend en charge l'application des politiques de réseau grâce à l'intégration avec Calico. En activant Calico dans une grappe, vous pouvez définir et appliquer des politiques de réseau Kubernetes ainsi que le plugiciel CNI de réseau de pods natifs du VCN OCI ou Flannel.

Calico est une solution de réseau et de sécurité de réseau à code source libre pour les conteneurs, les machines virtuelles et les charges de travail natives basées sur un hôte. Pour plus d'informations sur Calico, voir la documentation sur Calico.

Note

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

  • Seule l'utilisation de Calico à code source libre est prise en charge. Calico Enterprise n'est pas pris en charge.

  • Si vous avez créé une grappe et sélectionné Surcouche de canal comme type de réseau, vous pouvez installer Calico à la place du plugiciel CNI de canal (voir Installation de Calico à la place du plugiciel CNI de canal). Cependant, notez que la modification du plugiciel 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 grappes qui ont déjà des noeuds de travail existants.

Compatibilité Calico

Le tableau répertorie les versions du plugiciel de réseau Calico qu'Oracle a testées avec succès sur les grappes créées à l'aide de Kubernetes Engine. Oracle prend uniquement en charge les versions de Calico qui ont été testées avec succès. Pour chaque version de Calico, le tableau présente la version de Kubernetes qui s'exécutait sur des grappes lors de tests réussis.

Notez que seule l'utilisation de Calico à code source libre est prise en charge. Calico Enterprise n'est pas pris en charge.

Pour plus d'informations, voir Exemple : Installation de Calico et configuration de politiques de réseau.

Version de Calico Testé (et pris en charge) sur les grappes exécutant Kubernetes 1.30? Testé (et pris en charge) sur les grappes exécutant Kubernetes 1.31? Testé (et pris en charge) sur des grappes exécutant Kubernetes 1.32? Testé (et pris en charge) sur des grappes 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

Après avoir créé une grappe améliorée à 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 la grappe pour prendre en charge les politiques de 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 plugiciel CNI de flannel à Calico ne s'applique qu'aux nouveaux noeuds qui sont ensuite créés dans la grappe. Par conséquent, nous vous recommandons de ne pas remplacer flannel par Calico sur les grappes qui ont déjà des noeuds de travail existants.

Pour plus de facilité, les instructions d'installation de Calico sont fournies ci-dessous. Notez que les instructions d'installation varient entre les versions de Calico. Pour plus d'informations sur l'installation des différentes versions de Calico, consultez toujours la documentation sur l'installation de Calico.

  1. Désactivez le module complémentaire de grappe pour le plugiciel CNI flannel. Voir Désactivation (et suppression) d'un module complémentaire de grappe.

  2. Si vous ne l'avez pas encore fait, suivez les étapes pour configurer le fichier de configuration kubeconfig de la grappe et (s'il y a lieu) définissez la variable d'environnement KUBECONFIG pour qu'elle pointe vers le fichier. Notez que vous devez configurer votre propre fichier kubeconfig. Vous ne pouvez pas accéder à une grappe à l'aide d'un fichier kubeconfig configuré par un autre utilisateur. Voir Configuration de l'accès aux grappes.
  3. Supprimez le jeu de démonset flannel de l'espace de noms kube-system en entrant :
    kubectl delete -n kube-system daemonset kube-flannel-ds

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

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

    Notez que l'URL diffère selon la version de Calico que vous voulez installer.

  5. Si vous avez sélectionné une image Oracle Linux 8 pour les noeuds de travail de la grappe, définissez une variable d'environnement supplémentaire dans le fichier calico.yaml comme suit :
    1. Ouvrez le fichier calico.yaml dans un é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 entrant la commande suivante :

    kubectl apply -f calico.yaml

Installation de Calico à côté du plugiciel CNI de réseau de pods natif du VCN pour OCI

Après avoir créé une grappe à l'aide du moteur Kubernetes (à l'aide de la console ou de l'API) et sélectionné Réseau de pod natif du VCN comme type de réseau, vous pouvez ensuite installer Calico sur la grappe à côté du plugiciel CNI de réseau de pods natifs du VCN OCI pour prendre en charge les politiques de réseau.

Pour plus de facilité, les instructions d'installation de Calico sont fournies ci-dessous. Notez que les instructions d'installation varient entre les versions de Calico. Pour plus d'informations sur l'installation des différentes versions de Calico, consultez toujours la documentation sur l'installation de Calico.

  1. Si vous ne l'avez pas encore fait, suivez les étapes pour configurer le fichier de configuration kubeconfig de la grappe et (s'il y a lieu) définissez la variable d'environnement KUBECONFIG pour qu'elle pointe vers le fichier. Notez que vous devez configurer votre propre fichier kubeconfig. Vous ne pouvez pas accéder à une grappe à l'aide d'un fichier kubeconfig configuré par un autre utilisateur. Voir Configuration de l'accès aux grappes.

  2. Dans une fenêtre de terminal, téléchargez le manifeste policy-only de Calico pour le magasin de données d'API Kubernetes en entrant la commande suivante :

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

    Notez que l'URL diffère selon la version de Calico que vous voulez installer.

  3. Le fichier calico-policy-only.yaml comprend des composants Calico qui ne sont pas requis lors de l'utilisation de Calico avec le plugiciel CNI de réseau de pods natifs du VCN OCI. Vous devez donc supprimer ces composants. Vous devez également définir des variables d'environnement supplémentaires.
    1. Ouvrez le fichier calico-policy-only.yaml dans un éditeur de texte de votre choix.
    2. Supprimez la section initContainers du manifeste de calico-node DaemonSet.
    3. Supprimez ce qui suit de la section env pour le conteneur calico-node du manifeste du fichier 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 du fichier 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 de 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
          ...

      Après avoir effectué la modification, vérifiez que 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 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
              ...

      Après avoir effectué la modification, vérifiez que la section volumeMounts ressemble à ceci :

                ...
          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 du fichier calico-node DaemonSet :
      • FELIX_INTERFACEPREFIX="oci"
      • NO_DEFAULT_POOLS="true"
      • FELIX_CHAININSERTMODE="Append"
      • FELIX_IPTABLESMANGLEALLOWACTION="Return"
      • FELIX_IPTABLESBACKEND="NFT" Note : Ajoutez cette variable d'environnement uniquement si vous avez sélectionné une image Oracle Linux 8 pour les noeuds de travail de la grappe.

      Avant d'effectuer la modification, la section des variables d'environnement du 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"         
            ...

      Après avoir effectué la modification, vérifiez que la section des variables d'environnement du 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 entrant la commande suivante :

    kubectl apply -f calico-policy-only.yaml

Configuration de politiques de réseau

Après avoir installé Calico sur une grappe que vous avez créée avec Kubernetes Engine, vous pouvez créer des ressources Kubernetes NetworkPolicy pour isoler les pods, si nécessaire.

Pour obtenir des exemples de ressources NetworkPolicy et pour savoir comment les utiliser, voir la documentation sur Calico, notamment :

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