Requisitos para desplegar el controlador de entrada nativo de OCI como complemento de cluster

Descubra lo que debe hacer antes de desplegar el controlador de entrada nativo de OCI como complemento de cluster para equilibrar la carga y enrutar el tráfico entrante a pods de servicio que se ejecutan en nodos de trabajador en un cluster de Kubernetes.

Antes de desplegar el controlador de entrada nativo de OCI como complemento de cluster:

Cree un nuevo cluster o identifique un cluster existente que tenga redes de pods nativas de VCN o superposición de franela como tipo de red. El cluster puede ser un cluster mejorado o un cluster básico. El cluster debe ejecutar Kubernetes versión 1.28 o posterior. Consulte Creación de un cluster.
Configure reglas de seguridad del equilibrador de carga para permitir el tráfico entrante y saliente hacia y desde la subred del equilibrador de carga. Consulte Load Balancer Subnet Configuration.
Configure un principal de instancia, un principal de usuario o un principal de identidad de carga de trabajo para permitir que el controlador de entrada nativo de OCI acceda a otros servicios y recursos de Oracle Cloud Infrastructure. Consulte Configuración de un principal de instancia, un principal de usuario o un principal de identidad de carga de trabajo para activar el acceso a los servicios y recursos de OCI.
Otorgue permisos al principal de instancia, al principal de usuario o al principal de identidad de carga de trabajo para permitir que el controlador de entrada nativo de OCI acceda a los recursos. Consulte Otorgamiento de permisos al complemento de cluster de controlador de entrada nativo de OCI.
Instale el gestor de certificados para generar y gestionar los certificados TLS requeridos por el servidor de webhook que admite la función de puertas de preparación de pod. Consulte Installing cert-manager.

Configuración de un principal de instancia, un principal de usuario o un principal de identidad de carga de trabajo para permitir el acceso a los servicios y recursos de OCI

Para crear un equilibrador de carga y enrutar el tráfico entrante, el controlador de entrada nativo de OCI, ya sea instalado como programa independiente o como complemento de cluster, realiza acciones en otros recursos del servicio de Oracle Cloud Infrastructure (incluidos el servicio Load Balancer y el servicio Certificates). Para realizar esas acciones en los recursos del servicio OCI, el pod del controlador de entrada nativo de OCI utiliza las credenciales de un actor (o principal) autorizado. Actualmente puede configurar los siguientes tipos de principal para permitir que el controlador de entrada nativo de OCI realice acciones en los recursos del servicio OCI:

Principal de instancia: el controlador de entrada nativo de OCI utiliza la identidad de la instancia en la que se está ejecutando. Consulte Uso de principales de instancia para activar el acceso a los servicios y recursos de OCI.
Principal de usuario: el controlador de entrada nativo de OCI utiliza una identidad de usuario de OCI. Consulte Uso de principales de usuario para activar el acceso a los servicios y recursos de OCI.
Director de identidad de carga de trabajo: el controlador de entrada nativo de OCI utiliza la identidad de un recurso de carga de trabajo que se ejecuta en un cluster de Kubernetes. Consulte Uso de principales de identidad de carga de trabajo para permitir el acceso a los servicios y recursos de OCI.

Nota:

El uso de principales de instancia para permitir que el controlador de entrada nativo de OCI acceda a servicios y recursos de OCI no está soportado en clusters con nodos virtuales.
El uso de principales de identidad de carga de trabajo para permitir que el controlador de entrada nativo de OCI acceda a los servicios y recursos de OCI está soportado con clusters mejorados, pero no con clusters básicos.

Uso de principales de instancia para permitir el acceso a los servicios y recursos de OCI

Puede configurar un principal de instancia para permitir que el controlador de entrada nativo de OCI realice acciones en los recursos del servicio OCI. Tenga en cuenta que solo puede utilizar principales de instancia con nodos gestionados.

Para configurar un principal de instancia:

Cree un nuevo grupo dinámico que contenga las instancias informáticas que alojan los nodos de trabajador del cluster:
1. Abra el menú de navegación y haga clic en Identidad y seguridad. En Identidad, haga clic en Dominios. En Dominio de identidad, haga clic en Grupos dinámicos.
2. Seleccione el compartimento al que pertenecen las instancias informáticas.
3. Siga las instrucciones en Para crear un grupo dinámico y asígnele un nombre al grupo dinámico (por ejemplo, acme-oke-native-ingress-controller-dyn-grp).
4. Introduzca una regla que incluya las instancias informáticas en el compartimento, con el formato:
```
ALL {instance.compartment.id = '<compartment-ocid>'}
```
  donde <compartment-ocid> es el OCID del compartimento en el que se crean los pools de nodos de cluster.
  Por ejemplo:
```
ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
```
5. Haga clic en Crear grupo dinámico.

Antes de desplegar el controlador de entrada nativo de OCI, deberá:

Otorgue permisos a la instancia en la que se ejecuta el controlador de entrada nativo de OCI mediante el grupo dinámico. Consulte Otorgamiento de permisos al complemento de cluster de controlador de entrada nativo de OCI.
Indique que desea utilizar principales de instancia con el complemento de controlador de entrada nativo de OCI definiendo el argumento de configuración authType en instance. Por ejemplo:
```
    {
      "key": "authType",
      "value": "instance"
    }
```
Consulte Despliegue del complemento de OCI Native Ingress Controller

Uso de principales de usuario para permitir el acceso a los servicios y recursos de OCI

Puede configurar un principal de usuario para permitir que el controlador de entrada nativo de OCI realice acciones en los recursos del servicio OCI.

Para configurar un principal de usuario:

Si aún no existe un usuario adecuado, cree un usuario en IAM (consulte Para crear un usuario).
Si aún no existe un grupo adecuado, cree un grupo en IAM (consulte Para crear un grupo).
Agregue el usuario al grupo (consulte Para agregar un usuario a un grupo).
Obtenga estos elementos:
- Par de claves de RSA en formato PEM (2048 bits como mínimo). Consulte Generación de una clave de firma de API.
- Huella de la clave pública. Consulte Cómo obtener la huella de la clave.
- OCID del arrendamiento y OCID del usuario. Consulte Dónde obtener el OCID del arrendamiento y el OCID del usuario.
Cargue la clave pública del par de claves en la consola. Consulte Cómo cargar la clave pública.
Cree un archivo de configuración como un archivo .yaml que contenga información de credenciales, con el siguiente formato:
```
auth:
  region: <region-identifier>
  passphrase: <passphrase>
  user: <user-ocid>
  fingerprint: <fingerprint>
  tenancy: <tenancy-ocid>
```
donde:
- region: <region-identifier> es la región en la que reside el cluster. Por ejemplo, us-ashburn-1
- passphrase: <passphrase> especifica la contraseña utilizada para la clave si está cifrada.
- user: <user-ocid> es el OCID del usuario que va a utilizar el controlador de entrada nativo de OCI.
- fingerprint: <fingerprint> es la huella de la clave pública.
- tenancy: <tenancy-ocid> es el OCID del arrendamiento que contiene el cluster.
Por ejemplo:
```
auth:
  region: us-ashburn-1
  passphrase: examplepass
  user: ocid1.user.oc1..aaaaaaaa_example
  fingerprint: 67:d9:74:4b:21:example
  tenancy: ocid1.tenancy.oc1..aaaaaaaa_example
```
Cree un recurso secreto de Kubernetes en el cluster introduciendo:
```
kubectl create secret generic <secret-name> \
--from-file=config=<config-file>.yaml \
--from-file=private-key=<private-key-file-path>.pem \
--namespace <namespace>
```
donde:
- <secret-name> especifica el nombre del secreto que se va a crear. Por ejemplo, oci-config
- --from-file=config=<config-file>.yaml especifica el nombre y la ruta del archivo .yaml que contiene la información de credenciales que ha creado anteriormente. Por ejemplo, user-auth-config.yaml
- --from-file=private-key=./oci/oci_api_key.pem especifica el nombre y la ruta de acceso del archivo de claves privadas descargado. Por ejemplo, ./oci/oci_api_key.pem
- --namespace <namespace> especifica el espacio de nombres que contiene el controlador de entrada nativo de OCI
Por ejemplo:
```
kubectl create secret generic oci-config \
--from-file=config=user-auth-config.yaml \
--from-file=private-key=./oci/oci_api_key.pem \
--namespace acme-namespace
```

Antes de desplegar el controlador de entrada nativo de OCI:

Otorgue permisos al usuario a través del grupo al que pertenece el usuario. Consulte Otorgamiento de permisos al complemento de cluster de controlador de entrada nativo de OCI.
Indique que desea utilizar principales de usuario con el complemento de controlador de entrada nativo de OCI definiendo los siguientes argumentos de configuración:
- defina authType en user
- defina authSecretName en el nombre del secreto de Kubernetes que ha creado anteriormente
Por ejemplo:
```
    {
      "key": "authType",
      "value": "user"
    },
    {
      "key": "authSecretName",
      "value": "oci-config"
    }
```
Consulte Despliegue del complemento de OCI Native Ingress Controller

Uso de entidades de identidad de carga de trabajo para permitir el acceso a los servicios y recursos de OCI

Puede configurar un principal de identidad de carga de trabajo para permitir que el controlador de entrada nativo de OCI realice acciones en los recursos del servicio OCI. Tenga en cuenta que solo puede utilizar principales de identidad de carga de trabajo con clusters mejorados.

Para configurar un principal de identidad de carga de trabajo:

Obtenga el OCID del cluster (por ejemplo, mediante el separador Detalles de cluster de la consola).

Antes de desplegar el controlador de entrada nativo de OCI, deberá:

Otorgue permisos a la identidad de carga de trabajo del controlador de entrada nativo de OCI. Consulte Otorgamiento de permisos al complemento de cluster de controlador de entrada nativo de OCI.
Indique que desea utilizar principales de identidad de carga de trabajo con el complemento de controlador de entrada nativo de OCI definiendo el argumento de configuración authType en workloadIdentity. Por ejemplo:
```
    {
      "key": "authType",
      "value": "workloadIdentity"
    }
```
Consulte Despliegue del complemento de OCI Native Ingress Controller

Asignación de permisos al complemento de cluster de controlador de entrada nativo de OCI

El controlador de entrada nativo de OCI necesita permisos para acceder a los recursos creados por otros servicios de Oracle Cloud Infrastructure (como el servicio Load Balancer y el servicio Certificates). Los permisos que otorga son los mismos, independientemente de si instala el controlador de entrada nativo de OCI como un programa independiente o como un complemento de cluster. Además, los permisos son los mismos, independientemente de si ha configurado un principal de instancia, un principal de usuario o un principal de identidad de carga de trabajo para el controlador de entrada nativo de OCI. Sin embargo, la forma en que otorga esos permisos depende del tipo de principal que haya configurado:

Al utilizar principales de instancia, el controlador de entrada nativo de OCI hereda los permisos otorgados a la instancia en la que se ejecuta mediante un grupo dinámico al que pertenece la instancia. Para obtener información sobre la creación del grupo dinámico para principales de instancia, consulte Uso de principales de instancia para activar el acceso a los servicios y recursos de OCI.
Al utilizar principales de usuario, el controlador de entrada nativo de OCI hereda los permisos otorgados a un usuario a través de un grupo al que pertenece el usuario. Para obtener información sobre la creación del usuario y el grupo para los principales de usuario, consulte Uso de principales de usuario para activar el acceso a los servicios y recursos de OCI.
Al utilizar principales de identidad de carga de trabajo, el controlador de entrada nativo de OCI hereda los permisos otorgados a una carga de trabajo que se ejecuta en un cluster especificado, en la cuenta de servicio de Kubernetes y el espacio de nombres creados para el controlador de entrada nativo de OCI durante la instalación. Para obtener más información, consulte Uso de principales de identidad de carga de trabajo para permitir el acceso a los servicios y recursos de OCI.

Para configurar permisos para el controlador de entrada nativo de OCI, cree una política para el grupo (en el caso de los principales de usuario), para el grupo dinámico (en el caso de los principales de instancia) o para la carga de trabajo (en el caso de los principales de identidad de carga de trabajo), con sentencias de política para acceder a los servicios y recursos de OCI:

Abra el menú de navegación y haga clic en Identidad y seguridad. En Identidad, haga clic en Políticas.
Siga las instrucciones de Para crear una política y asigne un nombre a la política (por ejemplo, acme-oke-native-ingress-controller-policy).

Si utiliza principales de instancia o principales de usuario, introduzca sentencias de política para permitir el acceso a los servicios y recursos de OCI utilizados por el controlador de entrada nativo de OCI, con el formato:

Allow <group|dynamic-group> <subject-name> to <verb> <resource> in <location>

donde:

<group|dynamic-group> es group (en el caso de los principales de usuario) o dynamic-group (en el caso de los principales de instancia)
<subject-name> es el nombre del grupo (en el caso de los principales de usuario) o el nombre del grupo dinámico (en el caso de los principales de instancia). Por ejemplo, acme-oke-nat-ing-cont-dyn-grp. Tenga en cuenta que si un grupo o grupo dinámico no está en el dominio de identidad por defecto, agregue un prefijo al nombre de grupo o grupo dinámico con el nombre de dominio de identidad, con el formato <group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>'. También puede especificar un grupo o grupo dinámico mediante su OCID, con el formato group id <group-ocid> o dynamic-group id <dynamic-group-ocid>.
<verb> <resource> es uno de los siguientes (todos estos son necesarios en sentencias de política independientes):
- manage load-balancers
- use virtual-network-family
- manage cabundles
- manage cabundle-associations
- manage leaf-certificates
- read leaf-certificate-bundles
- manage certificate-associations
- read certificate-authorities
- manage certificate-authority-associations
- read certificate-authority-bundles
- read public-ips
- manage floating-ips
- manage waf-family
- read cluster-family
<location> es uno de los siguientes:
- tenancy, si desea que el controlador de entrada nativo de OCI tenga acceso a los recursos de todo el arrendamiento.
- compartment <compartment-name> si solo desea que el controlador de entrada nativo de OCI tenga acceso a los recursos del compartimento con el nombre que especifique como compartment <compartment-name>.

Por ejemplo:

Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment

La sintaxis para la lista completa de sentencias de política es la siguiente:

Allow <group|dynamic-group> <subject-name> to manage load-balancers in <location>   
Allow <group|dynamic-group> <subject-name> to use virtual-network-family in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundles in <location>
Allow <group|dynamic-group> <subject-name> to manage cabundle-associations in <location>
Allow <group|dynamic-group> <subject-name> to manage leaf-certificates in <location>
Allow <group|dynamic-group> <subject-name> to read leaf-certificate-bundles in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authorities in <location>
Allow <group|dynamic-group> <subject-name> to manage certificate-authority-associations in <location>
Allow <group|dynamic-group> <subject-name> to read certificate-authority-bundles in <location>
Allow <group|dynamic-group> <subject-name> to read public-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage floating-ips in <location>
Allow <group|dynamic-group> <subject-name> to manage waf-family in <location>
Allow <group|dynamic-group> <subject-name> to read cluster-family in <location>

Ejemplo de la lista completa de sentencias de política:

Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage load-balancers in compartment acme-oke-cluster-compartment   
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use virtual-network-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage cabundle-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage leaf-certificates in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read leaf-certificate-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authorities in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage certificate-authority-associations in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read certificate-authority-bundles in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read public-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage floating-ips in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to manage waf-family in compartment acme-oke-cluster-compartment
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to read cluster-family in compartment acme-oke-cluster-compartment

Si utiliza principales de identidad de carga de trabajo, introduzca sentencias de política para permitir el acceso a los servicios y recursos de OCI utilizados por el controlador de entrada nativo de OCI, con el formato:

Allow any-user to <verb> <resource> in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

donde:

<verb> <resource> es uno de los siguientes (todos estos son necesarios en sentencias de política independientes):
- manage load-balancers
- use virtual-network-family
- manage cabundles
- manage cabundle-associations
- manage leaf-certificates
- read leaf-certificate-bundles
- manage certificate-associations
- read certificate-authorities
- manage certificate-authority-associations
- read certificate-authority-bundles
- read public-ips
- manage floating-ips
- manage waf-family
- read cluster-family
<location> es uno de los siguientes:
- tenancy, si desea que el controlador de entrada nativo de OCI tenga acceso a los recursos de todo el arrendamiento.
- compartment <compartment-name> si solo desea que el controlador de entrada nativo de OCI tenga acceso a los recursos del compartimento con el nombre que especifique como compartment <compartment-name>.
request.principal.namespace = 'native-ingress-controller-system' es el nombre del espacio de nombres creado para el controlador de entrada nativo de OCI durante la instalación.
request.principal.service_account = 'oci-native-ingress-controller' es el nombre de la cuenta de servicio creada para el controlador de entrada nativo de OCI durante la instalación.
<cluster-ocid> es el OCID del cluster que ha obtenido anteriormente.

Por ejemplo:

Allow any-user to manage load-balancers in tenancy where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = 'ocid1.cluster.oc1.iad.aaaaaaaa______ska'}

La sintaxis para la lista completa de sentencias de política es:

Allow any-user to manage load-balancers in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to use virtual-network-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage cabundle-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage leaf-certificates in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read leaf-certificate-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authorities in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage certificate-authority-associations in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read certificate-authority-bundles in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read public-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage floating-ips in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to manage waf-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}
Allow any-user to read cluster-family in <location> where all {request.principal.type = 'workload', request.principal.namespace = 'native-ingress-controller-system', request.principal.service_account = 'oci-native-ingress-controller', request.principal.cluster_id = '<cluster-ocid>'}

Instalación de cert-manager

El controlador de entrada nativo de OCI, ya sea instalado como un programa independiente o como un complemento de cluster, utiliza webhooks para inyectar puertas de preparación de pod en las especificaciones de pod. Para garantizar la seguridad, el servidor de webhooks debe ejecutarse en modo HTTPS, que requiere un par de certificados y claves. El controlador de entrada nativo de OCI utiliza Certificate Manager (también conocido como cert-manager) para generar y gestionar los certificados y las claves para el servidor de webhook, por lo que debe instalar cert-manager en el cluster para utilizar las puertas de preparación de pod.

Independientemente de si instala el controlador de entrada nativo de OCI como un programa independiente o como un complemento de cluster, puede instalar y ejecutar el gestor de cert de dos formas:

Puede instalar y ejecutar cert-manager como un producto de código abierto, introduciendo:

kubectl apply -f https://github.com/jetstack/cert-manager/releases/latest/download/cert-manager.yaml

Puede instalar y ejecutar cert-manager como un complemento de cluster. Para obtener más información sobre la instalación de cert-manager como complemento de cluster, consulte Installing a Cluster Add-on.

Para obtener más información sobre cert-manager, consulte la documentación de cert-manager.io.

Tenga en cuenta que la instalación del controlador de entrada nativo de OCI como complemento de cluster falla si aún no ha instalado cert-manager, ya sea como producto de código abierto o como complemento de cluster.