Ejemplo: instalación de Calico y configuración de políticas de red

Descubra cómo instalar Calico y configurar políticas de red en un cluster que haya creado con Kubernetes Engine (OKE).

El modelo de red de Kubernetes asume que los contenedores (pods) tienen direcciones IP únicas y enrutables dentro de un cluster. En el modelo de red de Kubernetes, los contenedores se comunican entre sí utilizando esas direcciones IP, independientemente de si los contenedores se despliegan en el mismo nodo de un cluster o en un nodo diferente. Kubernetes ha adoptado la especificación de la interfaz de red de contenedor (CNI) para la gestión de recursos de red. El CNI consta de una especificación y bibliotecas para escribir plugins para configurar interfaces de red en contenedores Linux, junto con una serie de plugins admitidos.

Por defecto, los pods aceptan tráfico de cualquier origen. Para mejorar la seguridad del cluster, los pods se pueden "aislar" seleccionándolos en una política de red (el recurso NetworkPolicy de Kubernetes). Una política de red es una especificación de cómo se permite a los grupos de pods comunicarse entre sí y con otros puntos finales de red. Los recursos NetworkPolicy utilizan etiquetas para seleccionar pods y definir reglas que especifiquen el tráfico permitido para los pods seleccionados. Si un NetworkPolicy en un espacio de nombre de cluster selecciona un pod concreto, ese pod rechazará las conexiones que no estén permitidas por ningún NetworkPolicy. Otros pods del espacio de nombre que no estén seleccionados en NetworkPolicy seguirán aceptando todo el tráfico. Para obtener más información sobre las políticas de red, consulte la documentación de Kubernetes.

Las políticas de red se implementan mediante el proveedor de red CNI. Simplemente crear el recurso NetworkPolicy sin un proveedor de red CNI para implementarlo no tendrá ningún efecto. Tenga en cuenta que no todos los proveedores de red CNI implementan el recurso NetworkPolicy.

Al crear clusters con Kubernetes Engine, seleccione un tipo de red. El tipo de red que seleccione determina el proveedor de red CNI y el complemento CNI asociado que se utiliza para la red de pod, de la siguiente manera:

  • Red de pods nativa de VCN: utiliza el plugin CNI de red de pod nativo de VCN de OCI para conectar los nodos de trabajador a las subredes de pod en una VCN de Oracle Cloud Infrastructure. Como resultado, las direcciones IP de pod dentro de una VCN son direccionables directamente desde otras redes virtuales en la nube conectadas (con intercambio de tráfico) a esa VCN y desde redes locales. Consulte Using the OCI VCN-Native Pod Networking CNI plugin para redes de pod.
  • Superposición de franela: utiliza el plugin flannel CNI para encapsular la comunicación entre pods en la red de superposición de franela, una sencilla red virtual de superposición privada que asocia direcciones IP a contenedores. Solo se puede acceder a los pods de la red privada de superposición desde otros pods del mismo cluster. Consulte Uso del plugin flannel CNI para redes de pod.

Tanto el plugin CNI de red de pod nativo de VCN de OCI como el plugin flannel CNI admiten completamente los requisitos de red de pod en Kubernetes. Sin embargo, si desea mejorar la seguridad del cluster mediante la aplicación de políticas de red de Kubernetes, debe desplegar una solución adicional. Una de estas soluciones es el motor de políticas de red de Calico (consulte la documentación de Kubernetes para obtener otras soluciones). Kubernetes Engine soporta la aplicación de políticas de red a través de la integración con Calico. Al activar Calico en un cluster, puede definir y aplicar políticas de red de Kubernetes junto con el plugin de CNI de Flannel o la red de pod nativo de VCN de OCI.

Calico es una solución de seguridad de red y red de código abierto para contenedores, máquinas virtuales y cargas de trabajo nativas basadas en host. Para obtener más información sobre Calico, consulte la documentación de California.

Nota

  • Puede utilizar Calico con pools de nodos gestionados, pero no con pools de nodos virtuales.
  • Solo está soportado el uso de Calico de código abierto. El uso de Calico Enterprise no está soportado.

  • Si ha creado un cluster y ha seleccionado superposición de franela como tipo de red, puede instalar Calico en lugar del complemento flannel CNI (consulte Installing Calico in place of the flannel CNI plugin). Sin embargo, tenga en cuenta que cambiar el plugin CNI de flannel a Calico solo se aplica a los nuevos nodos que se crean posteriormente en el cluster. Por lo tanto, recomendamos que no sustituya flannel por Calico en clusters que ya tengan nodos de trabajador existentes.

Compatibilidad con Calico

En la tabla se muestran las versiones del plugin de red de Calico que Oracle ha probado correctamente en los clusters creados mediante Kubernetes Engine. Oracle solo admite versiones de Calico que se hayan probado correctamente. Para cada versión de Calico, la tabla muestra la versión de Kubernetes que se estaba ejecutando en clusters en pruebas correctas.

Tenga en cuenta que solo está soportado el uso de Calico de código abierto. El uso de Calico Enterprise no está soportado.

Para obtener más información, consulte Ejemplo: instalación de Calico y configuración de políticas de red.

Versión de Calico ¿Está probado (y soportado) en clusters que ejecutan Kubernetes 1.30? ¿Está probado (y soportado) en clusters que ejecutan Kubernetes 1.31? ¿Está probado (y soportado) en clusters que ejecutan Kubernetes 1.32? ¿Se ha probado (y soportado) en clusters que ejecutan Kubernetes 1.33?
3.25.1 (no se ha probado) (no se ha probado) (no se ha probado) (no se ha probado)
3.26.1 (no se ha probado) (no se ha probado) (no se ha probado) (no se ha probado)
3.26.4 (no se ha probado) (no se ha probado) (no se ha probado) (no se ha probado)
3.27.2 (no se ha probado) (no se ha probado) (no se ha probado) (no se ha probado)
3.28.0 (no se ha probado) (no se ha probado) (no se ha probado)
3.28.2 (no se ha probado) (no se ha probado) (no se ha probado)
3.29.2 (no se ha probado) (no se ha probado) (no probado)
3.30.0 (no probado) (no probado) (no probado)

Instalación de Calico en lugar del plugin CNI de franela

Después de crear un cluster mejorado con Kubernetes Engine (mediante la consola o la API) y seleccionar superposición de franela como tipo de red, puede instalar posteriormente Calico en el cluster para admitir políticas de red.

Antes de instalar Calico en lugar del plugin CNI de franela, primero debe desactivar el plugin CNI de franela. Tenga en cuenta que cambiar el plugin CNI de flannel a Calico solo se aplica a los nuevos nodos que se creen posteriormente en el cluster. Por lo tanto, se recomienda no sustituir flannel por Calico en clusters que ya tengan nodos de trabajador existentes.

Para su comodidad, las instrucciones de instalación de Calico se incluyen a continuación. Tenga en cuenta que las instrucciones de instalación de Calico varían según la versión de Calico. Para obtener información sobre la instalación de diferentes versiones de Calico, consulte siempre la documentación de instalación de Calico.

  1. Desactive el complemento de cluster de plugin CNI de canal. Consulte Disabling (and Removing) a Cluster Add-on.

  2. Si todavía no lo ha hecho, siga los pasos para configurar el archivo de configuración kubeconfig del cluster y (si es necesario) defina la variable de entorno KUBECONFIG para que apunte al archivo. Tenga en cuenta que debe configurar su propio archivo kubeconfig. No puede acceder a un cluster utilizando un archivo kubeconfig que haya configurado un usuario diferente. Consulte Configuración del acceso a los clusters.
  3. Elimine el daemonset de canal del espacio de nombres kube-system introduciendo:
    kubectl delete -n kube-system daemonset kube-flannel-ds
  4. En una ventana de terminal, descargue el manifiesto de Calico para el almacén de datos de API de Kubernetes introduciendo:

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

    Tenga en cuenta que la URL difiere según la versión de Calico que desee instalar.

  5. Si ha seleccionado una imagen de Oracle Linux 8 para los nodos de trabajador en el cluster, defina una variable de entorno adicional en el archivo calico.yaml de la siguiente manera:
    1. Abra el archivo calico.yaml en el editor de texto que desee.
    2. Agregue la siguiente variable de entorno a la sección env para el contenedor calico-node en el manifiesto del manifiesto calico-node DaemonSet:

                  - name: FELIX_IPTABLESBACKEND
                    value: "NFT"
    3. Guarde y cierre el archivo calico.yaml modificado.
  6. Instale y configure Calico introduciendo el siguiente comando:

    kubectl apply -f calico.yaml

Instalación de Calico junto con el plugin de CNI de red de pod nativos de VCN de OCI

Después de crear un cluster con Kubernetes Engine (mediante la consola o la API) y seleccionar red de pods nativa de VCN como tipo de red, puede instalar posteriormente Calico en el cluster junto con el plugin CNI de red de pod nativo de VCN de OCI para admitir políticas de red.

Para su comodidad, las instrucciones de instalación de Calico se incluyen a continuación. Tenga en cuenta que las instrucciones de instalación de Calico varían según la versión de Calico. Para obtener información sobre la instalación de diferentes versiones de Calico, consulte siempre la documentación de instalación de Calico.

  1. Si todavía no lo ha hecho, siga los pasos para configurar el archivo de configuración kubeconfig del cluster y (si es necesario) defina la variable de entorno KUBECONFIG para que apunte al archivo. Tenga en cuenta que debe configurar su propio archivo kubeconfig. No puede acceder a un cluster utilizando un archivo kubeconfig que haya configurado un usuario diferente. Consulte Configuración del acceso a los clusters.
  2. En una ventana de terminal, descargue el manifiesto solo de políticas de Calico para el almacén de datos de API de Kubernetes introduciendo:

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

    Tenga en cuenta que la URL difiere según la versión de Calico que desee instalar.

  3. El archivo calico-policy-only.yaml incluye componentes de Calico que no son necesarios al utilizar Calico junto con el plugin CNI de red de pod nativo de VCN de OCI, por lo que debe eliminar estos componentes. También debe definir algunas variables de entorno adicionales.
    1. Abra el archivo calico-policy-only.yaml en el editor de texto que desee.
    2. Elimine la sección initContainers del manifiesto de calico-node DaemonSet.
    3. Elimine lo siguiente de la sección env para el contenedor calico-node del manifiesto de calico-node DaemonSet:
                # Typha support: controlled by the ConfigMap.
                - name: FELIX_TYPHAK8SSERVICENAME
                    valueFrom:
                        configMapKeyRef:
                            name: calico-config
                            key: typha_service_name
    4. Elimine la siguiente sección envFrom para el contenedor calico-node del manifiesto 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. Elimine los siguientes volúmenes de la sección volumes del manifiesto de calico-node DaemonSet:
      • cni-bin-dir
      • cni-net-dir
      • cni-log-dir

      Antes de realizar el cambio, la sección volumes del manifiesto calico-node DaemonSet tiene el siguiente aspecto:

            ...
            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
                ...

      Después de realizar el cambio, compruebe que la sección volumes del manifiesto calico-node DaemonSet tenga el siguiente aspecto:

            ...
            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. Elimine los siguientes montajes de volumen de la sección volumeMounts para el contenedor calico-node en el manifiesto de calico-node DaemonSet:
      • cni-net-dir, incluido el comentario asociado # For maintaining CNI plugin API credentials.
      • cni-log-dir

      Antes de realizar el cambio, la sección volumeMounts tiene el siguiente aspecto:

                ...
                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
                    ...

      Después de realizar el cambio, compruebe que la sección volumeMounts tiene el siguiente aspecto:

                ...
                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. Agregue las siguientes variables de entorno para el contenedor calico-node en el manifiesto de calico-node DaemonSet:
      • FELIX_INTERFACEPREFIX="oci"
      • NO_DEFAULT_POOLS="true"
      • FELIX_CHAININSERTMODE="Append"
      • FELIX_IPTABLESMANGLEALLOWACTION="Return"
      • FELIX_IPTABLESBACKEND="NFT" Nota: solo agregue esta variable de entorno si ha seleccionado una imagen de Oracle Linux 8 para nodos de trabajador en el cluster.

      Antes de realizar el cambio, la sección de variables de entorno de contenedor calico-node (env:) del manifiesto calico-node DaemonSet tiene el siguiente aspecto:

            ...
            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"         
                  ...

      Después de realizar el cambio, compruebe que la sección de variables de entorno de contenedor calico-node (env:) del manifiesto calico-node DaemonSet tenga el siguiente aspecto:

            ...
            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. Guarde y cierre el archivo calico-policy-only.yaml modificado.
  4. Instale y configure Calico introduciendo el siguiente comando:

    kubectl apply -f calico-policy-only.yaml

Configuración de políticas de red

Una vez haya instalado Calico en un cluster creado con Kubernetes Engine, puede crear recursos NetworkPolicy de Kubernetes para aislar pods según sea necesario.

Para ver ejemplos de NetworkPolicy y cómo usarlos, consulte la documentación de Calico y concretamente:

Tenga en cuenta que los ejemplos varían según la versión de Calico que haya instalado.