Requisitos para desplegar el controlador de entrada nativo de OCI como programa independiente

Descubra lo que tiene que hacer antes de desplegar el controlador de entrada nativo de OCI como un programa independiente para equilibrar la carga y enrutar el tráfico entrante a los 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 un programa independiente:

Cree un nuevo cluster o identifique un cluster existente que tenga redes de pod 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 la versión 1.26 o posterior de Kubernetes. 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, principal de usuario o principal de identidad de carga de trabajo para activar el acceso a los servicios y recursos de OCI.
Otorgue permisos al principal de instancia, principal de usuario o 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 a OCI Native Ingress Controller as a Standalone Program.
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.
Instale la CLI de Helm para poder instalar el controlador de entrada nativo de OCI de una de estas dos formas. Consulte Instalación de la CLI de Helm para instalar OCI Native Ingress Controller as a Standalone Program.
Clone el repositorio del controlador de entrada nativo de OCI de GitHub a un repositorio local, para permitirle desplegar el controlador de entrada nativo de OCI y especificar valores de parámetros para el despliegue. Consulte Clonación del repositorio de controlador de entrada nativo de OCI y definición de parámetros en values.yaml.

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 de 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 la identidad de un usuario de OCI. Consulte Uso de principales de usuario para activar el acceso a los servicios y recursos de OCI.
Principal 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 los 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 seleccione Identidad y seguridad. En Identidad, seleccione Dominios. En Dominio de identidad, seleccione 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 a través del grupo dinámico. Consulte Otorgamiento de permisos a OCI Native Ingress Controller as a Standalone Program.
Indique que desea utilizar principales de instancia con el controlador de entrada nativo de OCI especificando lo siguiente en el archivo values.yaml:
```
authType: instance
```
Consulte Clonación del repositorio del controlador de entrada nativo de OCI y definición de parámetros en values.yaml.

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 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, deberá:

Otorgue permisos al usuario a través del grupo al que pertenece el usuario. Consulte Otorgamiento de permisos al controlador de entrada nativo de OCI como programa independiente.
Indique que desea utilizar principales de usuario con el controlador de entrada nativo de OCI especificando lo siguiente en el archivo values.yaml:
```
authType: user
authSecretName: <secret-name>
```
donde <secret-name> es el nombre del secreto de Kubernetes que ha creado anteriormente. Por ejemplo:
```
authType: user
authSecretName: oci-config
```
Consulte Clonación del repositorio del controlador de entrada nativo de OCI y definición de parámetros en values.yaml.

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 a OCI Native Ingress Controller as a Standalone Program.
- Indique si desea utilizar principales de identidad de carga de trabajo con el controlador de entrada nativo de OCI especificando lo siguiente en el archivo values.yaml:
```
authType: workloadIdentity
```
  Consulte Clonación del repositorio del controlador de entrada nativo de OCI y definición de parámetros en values.yaml.
- Defina las variables de entorno OCI_RESOURCE_PRINCIPAL_VERSION y OCI_RESOURCE_PRINCIPAL_REGION en el archivo deployment.yaml.
  
  Consulte Clonación del repositorio del controlador de entrada nativo de OCI y definición de parámetros en values.yaml.

Otorgamiento de permisos al controlador de entrada nativo de OCI como programa independiente

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. Y 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 a través de 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 permitir 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 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 principales de usuario), para el grupo dinámico (en el caso de principales de instancia) o para la carga de trabajo (en el caso de 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 seleccione Identidad y seguridad. En Identidad, seleccione 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, anteponga el nombre de grupo o grupo dinámico al 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 leaf-certificate-versions
- 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
- use tag-namespaces (solo es necesario si desea que el controlador de entrada nativo de OCI aplique etiquetas definidas a los equilibradores de carga, consulte Aplicación de etiquetas definidas al equilibrador de carga)
<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 especificado 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 leaf-certificate-versions 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>
Allow <group|dynamic-group> <subject-name> to use tag-namespaces 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 leaf-certificate-versions 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
Allow dynamic-group acme-oke-nat-ing-cont-dyn-grp to use tag-namespaces 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 leaf-certificate-versions
- 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
- use tag-namespaces (solo es necesario si desea que el controlador de entrada nativo de OCI aplique etiquetas definidas a los equilibradores de carga, consulte Aplicación de etiquetas definidas al equilibrador de carga)
<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 especificado 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 leaf-certificate-versions 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>'}
Allow any-user to use tag-namespaces 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 webhook 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 cert-manager 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.

Instalación de la CLI de Helm para instalar el controlador de entrada nativo de OCI como programa independiente

Helm es un gestor de paquetes para Kubernetes. Helm se suele utilizar para crear, empaquetar, configurar y desplegar aplicaciones de Kubernetes mediante la combinación de archivos de configuración en un único paquete reutilizable denominado gráfico de Helm. Los gráficos se empaquetan y distribuyen en un formato de archivo conocido como archivo de gráficos. Un gráfico contiene la información necesaria para instalar un juego de recursos de Kubernetes en un cluster de Kubernetes. Un gráfico incluye:

un archivo chart.yaml, que describe la aplicación,
un archivo values.yaml, que proporciona valores por defecto para los parámetros de aplicación
plantillas de archivos utilizadas por la aplicación
otras dependencias

Helm también tiene un cliente de línea de comandos, la CLI de Helm (a veces denominada timón, todo en minúsculas)

Para instalar el controlador de entrada nativo de OCI como un programa independiente, el controlador de entrada nativo de OCI está disponible como un gráfico de Helm. Antes de instalar el gráfico del controlador de entrada nativo de OCI, primero debe instalar la CLI de Helm.

Para instalar la CLI de Helm, siga las instrucciones de la documentación de instalación de Helm para descargar y extraer el archivo de almacenamiento zip o tar.gz adecuado.

Clonación del repositorio del controlador de entrada nativo de OCI y definición de parámetros en values.yaml

Para clonar el controlador de entrada nativo de OCI y definir parámetros en values.yaml en preparación para instalar el controlador de entrada nativo de OCI como un programa independiente:

Clone el repositorio del controlador de entrada nativo de OCI de GitHub introduciendo:
```
git clone https://github.com/oracle/oci-native-ingress-controller
```
En el repositorio de Git local, vaya al directorio oci-native-ingress-controller y abra el archivo values.yaml en un editor de texto.
En el archivo values.yaml, defina el parámetro compartment_id en el OCID del compartimento en el que el controlador de entrada nativo de OCI va a crear el equilibrador de carga y el certificado de OCI. Por ejemplo:
```
compartment_id: "ocid1.compartment.oc1..aaaaaaaa______ddq" 
```
En el archivo values.yaml, defina el parámetro subnet_id en el OCID de la subred del equilibrador de carga. Por ejemplo:
```
subnet_id: "ocid1.subnet.oc1.iad.aaaaaaaa______dba" 
```
En el archivo values.yaml, defina el parámetro cluster_id en el OCID del cluster. Por ejemplo:
```
cluster_id: "ocid1.cluster.oc1.iad.aaaaaaaa______ska" 
```
En el archivo values.yaml, especifique cómo debe acceder el controlador de entrada nativo de OCI a los servicios y recursos de OCI de la siguiente manera:
- Para especificar que desea que el controlador de entrada nativo de OCI acceda a los servicios y recursos de OCI mediante un principal de instancia, defina el parámetro authType de la siguiente forma:
```
authType: instance
```
  Consulte Uso de principales de instancia para activar el acceso a los servicios y recursos de OCI.
- Para especificar que desea que el controlador de entrada nativo de OCI acceda a los servicios y recursos de OCI mediante un principal de usuario, defina los parámetros authType y authSecretName de la siguiente manera:
```
authType: user
authSecretName: <secret-name>
```
  donde <secret-name> es el nombre del secreto de Kubernetes que ha creado anteriormente. Por ejemplo:
```
authType: user
authSecretName: oci-config
```
  Consulte Uso de principales de usuario para activar el acceso a los servicios y recursos de OCI.
- Para especificar que desea que el controlador de entrada nativo de OCI acceda a los servicios y recursos de OCI mediante un principal de identidad de carga de trabajo, defina los parámetros authType de la siguiente manera:
```
authType: workloadIdentity
```
  Consulte Uso de principales de identidad de carga de trabajo para permitir el acceso a los servicios y recursos de OCI.
(Opcional) Si desea ejecutar varias instancias del controlador de entrada nativo de OCI por motivos de disponibilidad, cambie el valor de replicaCount en el archivo values.yaml. Por ejemplo:
```
replicaCount: 3
```
Por defecto, replicaCount se define en 1, lo que significa que una instancia del controlador de entrada nativo de OCI se ejecuta como un solo pod. Para garantizar la disponibilidad, puede que desee aumentar replicaCount (normalmente a 2 o 3) para ejecutar varias instancias de controlador de entrada nativo de OCI como pods diferentes. Un pod está nominado como líder y actúa como controlador de entrada nativo de OCI, mientras que los pods restantes esperan en estado pasivo. Si el líder deja de estar disponible posteriormente, uno de los otros pods será nominado como líder y actuará como controlador de entrada nativo de OCI.
Guarde los cambios realizados en el archivo values.yaml y cierre el archivo.
Si desea que el controlador de entrada nativo de OCI acceda a los servicios y recursos de OCI mediante un principal de identidad de carga de trabajo, debe definir variables de entorno adicionales de la siguiente forma:
1. En el repositorio de Git local, vaya al directorio oci-native-ingress-controller/templates y abra el archivo deployment.yaml en un editor de texto.
2. En el archivo deployment.yaml, defina las siguientes variables de entorno como se muestra a continuación:
```
  env:
    - name: OCI_RESOURCE_PRINCIPAL_VERSION
      value: "2.2"
    - name: OCI_RESOURCE_PRINCIPAL_REGION
      value: "us-ashburn-1"
```
3. Guarde los cambios realizados en el archivo deployment.yaml y cierre el archivo.

Documentación de Oracle Cloud Infrastructure