Prerequisiti per la distribuzione del controller di entrata nativo OCI come componente aggiuntivo cluster

Scopri cosa devi fare prima di poter distribuire il controller in entrata nativo OCI come componente aggiuntivo cluster per bilanciare il carico e instradare il traffico in entrata ai pod del servizio in esecuzione sui nodi di lavoro in un cluster Kubernetes.

Prima di distribuire il controller di entrata nativo OCI come componente aggiuntivo cluster:

Creare un nuovo cluster o identificare un cluster esistente con rete pod nativa VCN o overlay multicanale come tipo di rete. Il cluster può essere un cluster avanzato o di base. Il cluster deve eseguire Kubernetes versione 1.28 o successiva. Vedere Creazione di un cluster.
Configura le regole di sicurezza del load balancer per consentire il traffico in entrata e in uscita verso e dalla subnet del load balancer. Vedere Configurazione della subnet del load balancer.
Impostare un principal istanza, un principal utente o un principal identità del carico di lavoro per consentire al controller in entrata nativo OCI di accedere ad altri servizi e risorse Oracle Cloud Infrastructure. Vedere Impostazione di un principal dell'istanza, di un principal utente o di un principal dell'identità del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI.
Concedere le autorizzazioni al principal dell'istanza, al principal utente o al principal dell'identità del carico di lavoro per consentire al controller in entrata nativo OCI di accedere alle risorse. Vedere Concessione delle autorizzazioni al componente aggiuntivo cluster del controller di entrata nativo OCI.
Installare cert-manager per generare e gestire i certificati TLS richiesti dal server webhook che supporta la funzione di prontezza dei pod. Vedere Installazione di cert-manager.

Impostazione di un principal dell'istanza, di un principal utente o di un principal del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI

Per creare un load balancer e instradare il traffico in entrata, il controller di entrata nativo OCI, installato come programma standalone o come componente aggiuntivo cluster, esegue azioni su altre risorse del servizio Oracle Cloud Infrastructure (inclusi il servizio Load Balancer e il servizio Certificati). Per eseguire tali azioni sulle risorse del servizio OCI, il pod del controller di entrata nativo OCI utilizza le credenziali di un attore (o principal) autorizzato. Al momento, puoi impostare i seguenti tipi di principal per consentire al controller in entrata nativo OCI di eseguire azioni sulle risorse del servizio OCI:

Principal istanza: il controller in entrata nativo OCI utilizza l'identità dell'istanza in cui è in esecuzione. Vedere Utilizzo dei principal delle istanze per abilitare l'accesso ai servizi e alle risorse OCI.
User principal: il controller di entrata nativo OCI utilizza l'identità di un utente OCI. Vedere Utilizzo dei principal utente per abilitare l'accesso ai servizi e alle risorse OCI.
Principal di identità del carico di lavoro: il controller di entrata nativo OCI utilizza l'identità di una risorsa del carico di lavoro in esecuzione su un cluster Kubernetes. Vedere Utilizzo dei principal delle identità del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI.

Nota:

L'uso dei principal dell'istanza per consentire al controller in entrata nativo OCI di accedere ai servizi e alle risorse OCI non è supportato nei cluster con nodi virtuali.
L'uso delle identità dei carichi di lavoro per consentire al controller in entrata nativo OCI di accedere ai servizi e alle risorse OCI è supportato con cluster avanzati, ma non con cluster di base.

Utilizzo dei principal delle istanze per abilitare l'accesso ai servizi e alle risorse OCI

Puoi impostare un principal dell'istanza per consentire al controller in entrata nativo OCI di eseguire azioni sulle risorse del servizio OCI. Tenere presente che è possibile utilizzare solo principal delle istanze con nodi gestiti.

Per impostare un principal istanza:

Creare un nuovo gruppo dinamico per contenere le istanze di computazione che ospitano i nodi di lavoro del cluster:
1. Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Domini. In Dominio di Identity, selezionare Gruppi dinamici.
2. Selezionare il compartimento a cui appartengono le istanze di computazione.
3. Seguire le istruzioni in Per creare un gruppo dinamico e assegnare al gruppo dinamico un nome (ad esempio, acme-oke-native-ingress-controller-dyn-grp).
4. Immettere una regola che includa le istanze di computazione nel compartimento, nel formato seguente:
```
ALL {instance.compartment.id = '<compartment-ocid>'}
```
  dove <compartment-ocid> è l'OCID del compartimento in cui vengono creati i pool di nodi cluster.
  Ad esempio:
```
ALL {instance.compartment.id = 'ocid1.compartment.oc1..aaaaaaaa23______smwa'}
```
5. Fare clic su Crea gruppo dinamico.

Prima di distribuire il controller in entrata nativo OCI, dovrai:

Concedere le autorizzazioni all'istanza in cui il controller di entrata nativo OCI è in esecuzione tramite il gruppo dinamico. Vedere Concessione delle autorizzazioni al componente aggiuntivo cluster del controller di entrata nativo OCI.
Indicare se si desidera utilizzare i principal delle istanze con il componente aggiuntivo del controller in entrata nativo OCI impostando l'argomento di configurazione authType su instance. Ad esempio:
```
    {
      "key": "authType",
      "value": "instance"
    }
```
Vedere Distribuzione del componente aggiuntivo del controller di entrata nativo OCI

Utilizzo delle principal utente per abilitare l'accesso ai servizi e alle risorse OCI

È possibile impostare un principal utente per consentire al controller in entrata nativo OCI di eseguire azioni sulle risorse del servizio OCI.

Per impostare un principal utente:

Se non esiste già un utente appropriato, crearne uno in IAM (vedere Per creare un utente).
Se non esiste già un gruppo appropriato, crearne uno in IAM (vedere Per creare un gruppo).
Aggiungere l'utente al gruppo (vedere Per aggiungere un utente a un gruppo).
Recupera questi elementi:
- Coppia di chiavi RSA in formato PEM (minimo 2048 bit). Vedere How to Generate a API Signing Key.
- Impronta della chiave pubblica. Vedere How to Get the Key's Fingerprint.
- OCID della tenancy e OCID dell'utente. Vedere Where to Get the Tenancy's OCID and User's OCID.
Caricare la chiave pubblica dalla coppia di chiavi nella console. Vedere Come caricare la chiave pubblica.
Creare un file di configurazione come file .yaml contenente le informazioni sulle credenziali, nel seguente formato:
```
auth:
  region: <region-identifier>
  passphrase: <passphrase>
  user: <user-ocid>
  fingerprint: <fingerprint>
  tenancy: <tenancy-ocid>
```
Dove:
- region: <region-identifier> è l'area in cui risiede il cluster. Ad esempio, us-ashburn-1
- passphrase: <passphrase> specifica la password utilizzata per la chiave se è cifrata.
- user: <user-ocid> è l'OCID dell'utente che deve essere utilizzato dal controller in entrata nativo OCI.
- fingerprint: <fingerprint> è l'impronta della chiave pubblica.
- tenancy: <tenancy-ocid> è l'OCID della tenancy che contiene il cluster.
Ad esempio:
```
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
```
Creare una risorsa segreta Kubernetes nel cluster immettendo:
```
kubectl create secret generic <secret-name> \
--from-file=config=<config-file>.yaml \
--from-file=private-key=<private-key-file-path>.pem \
--namespace <namespace>
```
Dove:
- <secret-name> specifica il nome del segreto da creare. Ad esempio, oci-config
- --from-file=config=<config-file>.yaml specifica il nome e il percorso del file .yaml che contiene le informazioni sulle credenziali create in precedenza. Ad esempio, user-auth-config.yaml
- --from-file=private-key=./oci/oci_api_key.pem specifica il nome e il percorso del file di chiave privata scaricato. Ad esempio, ./oci/oci_api_key.pem
- --namespace <namespace> specifica lo spazio di nomi che contiene il controller di ingresso nativo OCI
Ad esempio:
```
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
```

Prima di distribuire il controller in entrata nativo OCI, dovrai:

Concedere le autorizzazioni all'utente tramite il gruppo a cui l'utente appartiene. Vedere Concessione delle autorizzazioni al componente aggiuntivo cluster del controller di entrata nativo OCI.
Indicare se si desidera utilizzare le identità utente con l'add-on del controller in entrata nativo OCI impostando i seguenti argomenti di configurazione:
- impostare authType su user
- impostare authSecretName sul nome del segreto Kubernetes creato in precedenza
Ad esempio:
```
    {
      "key": "authType",
      "value": "user"
    },
    {
      "key": "authSecretName",
      "value": "oci-config"
    }
```
Vedere Distribuzione del componente aggiuntivo del controller di entrata nativo OCI

Utilizzo delle identità del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI

Puoi impostare un principal di identità del carico di lavoro per consentire al controller in entrata nativo OCI di eseguire azioni sulle risorse del servizio OCI. Tenere presente che è possibile utilizzare solo le identità dei carichi di lavoro con cluster avanzati.

Per impostare un principal di identità del carico di lavoro, effettuare le operazioni riportate di seguito.

Ottenere l'OCID del cluster (ad esempio, utilizzando la scheda Dettagli cluster nella console).

Prima di distribuire il controller in entrata nativo OCI, dovrai:

Concedere le autorizzazioni all'identità del carico di lavoro del controller in entrata nativo OCI. Vedere Concessione delle autorizzazioni al componente aggiuntivo cluster del controller di entrata nativo OCI.
Indicare che si desidera utilizzare le identità del carico di lavoro con il componente aggiuntivo del controller in entrata nativo OCI impostando l'argomento di configurazione authType su workloadIdentity. Ad esempio:
```
    {
      "key": "authType",
      "value": "workloadIdentity"
    }
```
Vedere Distribuzione del componente aggiuntivo del controller di entrata nativo OCI

Concessione delle autorizzazioni al componente aggiuntivo cluster del controller di entrata nativo OCI

Il controller di entrata nativo OCI richiede le autorizzazioni per accedere alle risorse create da altri servizi Oracle Cloud Infrastructure (ad esempio, il servizio Load Balancer e il servizio Certificati). Le autorizzazioni concesse sono le stesse, indipendentemente dal fatto che si installi il controller di entrata nativo OCI come programma standalone o come componente aggiuntivo cluster. Inoltre, le autorizzazioni sono le stesse, indipendentemente dal fatto che tu abbia impostato un principal dell'istanza, un principal utente o un principal dell'identità del carico di lavoro per il controller in entrata nativo OCI. Tuttavia, il modo in cui si concedono tali autorizzazioni dipende dal tipo di principal impostato:

Quando si utilizzano i principal dell'istanza, il controller di entrata nativo OCI eredita le autorizzazioni concesse all'istanza su cui è in esecuzione tramite un gruppo dinamico a cui appartiene l'istanza. Per informazioni sulla creazione del gruppo dinamico per i principal delle istanze, vedere Utilizzo dei principal delle istanze per abilitare l'accesso ai servizi e alle risorse OCI.
Quando si utilizzano i principal utente, il controller di entrata nativo OCI eredita le autorizzazioni concesse a un utente tramite un gruppo a cui appartiene l'utente. Per informazioni sulla creazione dell'utente e del gruppo per i principal utente, vedere Utilizzo dei principal utente per abilitare l'accesso ai servizi e alle risorse OCI.
Quando si utilizzano le identità dei carichi di lavoro, il controller di entrata nativo OCI eredita le autorizzazioni concesse a un carico di lavoro in esecuzione su un cluster specificato, nell'account di servizio Kubernetes e nello spazio di nomi creati per il controller di entrata nativo OCI durante l'installazione. Per ulteriori informazioni, vedere Utilizzo delle identità del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI.

Per impostare le autorizzazioni per il controller in entrata nativo OCI, creare un criterio per il gruppo (nel caso di principal utente), per il gruppo dinamico (nel caso di principal istanza) o per il carico di lavoro (nel caso di principal identità del carico di lavoro), con istruzioni dei criteri per accedere ai servizi e alle risorse OCI:

Aprire il menu di navigazione e selezionare Identità e sicurezza. In Identità, selezionare Criteri.
Seguire le istruzioni in Per creare un criterio e assegnare un nome al criterio, ad esempio acme-oke-native-ingress-controller-policy.

Se si utilizzano principal dell'istanza o principal utente, immettere le istruzioni dei criteri per consentire l'accesso ai servizi e alle risorse OCI utilizzati dal controller di entrata nativo OCI, nel formato riportato di seguito.

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

Dove:

<group|dynamic-group> è group (nel caso dei principal utente) o dynamic-group (nel caso dei principal istanza)
<subject-name> è il nome del gruppo (nel caso dei principal utente) o il nome del gruppo dinamico (nel caso dei principal istanza). Ad esempio, acme-oke-nat-ing-cont-dyn-grp. Se un gruppo o un gruppo dinamico non si trova nel dominio di identità predefinito, inserire il nome del gruppo o del gruppo dinamico prima del nome del dominio di identità nel formato <group|dynamic-group> '<identity-domain-name>'/'<group-name|dynamic-group-name>'. È inoltre possibile specificare un gruppo o un gruppo dinamico utilizzando il relativo OCID, nel formato group id <group-ocid> o dynamic-group id <dynamic-group-ocid>.
<verb> <resource> è una delle seguenti opzioni (tutte queste sono obbligatorie, in istruzioni dei criteri separate):
- 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 (obbligatorio solo se si desidera che il controller di entrata nativo OCI applichi le tag definite ai load balancer; vedere Applicazione delle tag definite al load balancer)
<location> è uno dei seguenti:
- tenancy, se desideri che il controller di entrata nativo OCI abbia accesso alle risorse nell'intera tenancy.
- compartment <compartment-name> se si desidera che il controller di entrata nativo OCI abbia accesso alle risorse nel compartimento con il nome specificato come compartment <compartment-name>.

Ad esempio:

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

La sintassi per l'elenco completo delle istruzioni dei criteri è la seguente:

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>

Esempio della lista completa delle istruzioni dei criteri:

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

Se si utilizzano principal delle identità del carico di lavoro, immettere le istruzioni dei criteri per consentire l'accesso ai servizi e alle risorse OCI utilizzati dal controller di entrata nativo OCI, nel formato seguente:

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>'}

Dove:

<verb> <resource> è una delle seguenti opzioni (tutte queste sono obbligatorie, in istruzioni dei criteri separate):
- 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 (obbligatorio solo se si desidera che il controller di entrata nativo OCI applichi le tag definite ai load balancer; vedere Applicazione delle tag definite al load balancer)
<location> è uno dei seguenti:
- tenancy, se desideri che il controller di entrata nativo OCI abbia accesso alle risorse nell'intera tenancy.
- compartment <compartment-name> se si desidera che il controller di entrata nativo OCI abbia accesso alle risorse nel compartimento con il nome specificato come compartment <compartment-name>.
request.principal.namespace = 'native-ingress-controller-system' è il nome dello spazio di nomi creato per il controller di entrata nativo OCI durante l'installazione.
request.principal.service_account = 'oci-native-ingress-controller' è il nome dell'account di servizio creato per il controller di entrata nativo OCI durante l'installazione.
<cluster-ocid> è l'OCID del cluster ottenuto in precedenza.

Ad esempio:

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 sintassi per l'elenco completo delle istruzioni dei criteri è la seguente:

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>'}

Installazione di cert-manager

Il controller di ingresso nativo OCI, installato come programma standalone o come componente aggiuntivo cluster, utilizza i webhook per inserire i gate di idoneità dei pod nelle specifiche dei pod. Per garantire la sicurezza, il server webhook deve essere eseguito in modalità HTTPS, che richiede la coppia di certificati e chiavi. Il controller di ingresso nativo OCI utilizza Certificate Manager (noto anche come cert-manager) per generare e gestire i certificati e le chiavi per il server webhook, quindi è necessario installare cert-manager sul cluster per utilizzare i gate di idoneità dei pod.

Indipendentemente dal fatto che tu installi il controller di ingresso nativo OCI come programma standalone o come componente aggiuntivo cluster, puoi installare ed eseguire cert-manager in due modi:

È possibile installare ed eseguire cert-manager come prodotto open source, inserendo:

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

È possibile installare ed eseguire cert-manager come componente aggiuntivo cluster. Per ulteriori informazioni sull'installazione di cert-manager come componente aggiuntivo cluster, vedere Installazione di un componente aggiuntivo cluster.

Per ulteriori informazioni su cert-manager, consultare la documentazione di cert-manager.io.

Tenere presente che l'installazione del controller di ingresso nativo OCI come componente aggiuntivo cluster non riesce se cert-manager non è già stato installato come prodotto open source o come componente aggiuntivo cluster.

Documentazione di Oracle Cloud Infrastructure

Prerequisiti per la distribuzione del controller di entrata nativo OCI come componente aggiuntivo cluster

Impostazione di un principal dell'istanza, di un principal utente o di un principal del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI

Utilizzo dei principal delle istanze per abilitare l'accesso ai servizi e alle risorse OCI

Utilizzo delle principal utente per abilitare l'accesso ai servizi e alle risorse OCI

Utilizzo delle identità del carico di lavoro per abilitare l'accesso ai servizi e alle risorse OCI

Concessione delle autorizzazioni al componente aggiuntivo cluster del controller di entrata nativo OCI

Installazione di cert-manager