website/content/it/docs/concepts/cluster-administration/cloud-providers.md

---
title: Cloud Providers
content_template: templates/concept
weight: 30
---

{{% capture overview %}}
Questa pagina spiega come gestire Kubernetes in esecuzione su uno specifico
fornitore di servizi cloud.
{{% /capture %}}


{{% capture body %}}

### kubeadm
[kubeadm](/docs/reference/setup-tools/kubeadm/kubeadm/) è un'opzione popolare per la creazione di cluster di kuberneti.
kubeadm ha opzioni di configurazione per specificare le informazioni di configurazione per i provider cloud. Ad esempio
un tipico il provider cloud in-tree può essere configurato utilizzando kubeadm come mostrato di seguito:

```yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: InitConfiguration
nodeRegistration:
  kubeletExtraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"
---
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: v1.13.0
apiServer:
  extraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"
  extraVolumes:
  - name: cloud
    hostPath: "/etc/kubernetes/cloud.conf"
    mountPath: "/etc/kubernetes/cloud.conf"
controllerManager:
  extraArgs:
    cloud-provider: "openstack"
    cloud-config: "/etc/kubernetes/cloud.conf"
  extraVolumes:
  - name: cloud
    hostPath: "/etc/kubernetes/cloud.conf"
    mountPath: "/etc/kubernetes/cloud.conf"
```

I provider cloud in-tree in genere richiedono sia `--cloud-provider` e` --cloud-config` specificati nelle righe di
comando per [kube-apiserver](/docs/admin/kube-apiserver/), [kube-controller-manager](/docs/admin/kube-controller-manager/)
e il [Kubelet](/docs/admin/kubelet/). Anche il contenuto del file specificato in `--cloud-config` per ciascun provider
è documentato di seguito.

Per tutti i fornitori di servizi cloud esterni, seguire le istruzioni sui singoli repository.

## AWS
Questa sezione descrive tutte le possibili configurazioni che possono essere utilizzato durante l'esecuzione di
Kubernetes su Amazon Web Services.

### Node Name
Il provider cloud AWS utilizza il nome DNS privato dell'istanza AWS come nome dell'oggetto Nodo Kubernetes.

### Load Balancers
È possibile impostare [bilanciamento del carico esterno](/docs/tasks/access-application-cluster/create-external-load-balancer/)
per utilizzare funzionalità specifiche in AWS configurando le annotazioni come mostrato di seguito.

```yaml
apiVersion: v1
kind: Service
metadata:
  name: example
  namespace: kube-system
  labels:
    run: example
  annotations:
     service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm:xx-xxxx-x:xxxxxxxxx:xxxxxxx/xxxxx-xxxx-xxxx-xxxx-xxxxxxxxx #replace this value
     service.beta.kubernetes.io/aws-load-balancer-backend-protocol: http
spec:
  type: LoadBalancer
  ports:
  - port: 443
    targetPort: 5556
    protocol: TCP
  selector:
    app: example
```
È possibile applicare impostazioni diverse a un servizio di bilanciamento del carico in AWS utilizzando _annotations_. Quanto segue descrive le annotazioni supportate su ELB AWS:

* `service.beta.kubernetes.io / aws-load-balancer-access-log-emit-interval`: utilizzato per specificare l'intervallo di emissione del registro di accesso.
* `service.beta.kubernetes.io / aws-load-balancer-access-log-enabled`: utilizzato sul servizio per abilitare o disabilitare i log di accesso.
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-name`: usato per specificare il nome del bucket di log degli accessi s3.
* `service.beta.kubernetes.io / aws-load-balancer-access-log-s3-bucket-prefix`: utilizzato per specificare il prefisso del bucket del registro di accesso s3.
* `service.beta.kubernetes.io / aws-load-balancer-additional-resource-tags`: utilizzato sul servizio per specificare un elenco separato da virgole di coppie chiave-valore che verranno registrate come tag aggiuntivi nel ELB. Ad esempio: "Key1 = Val1, Key2 = Val2, KeyNoVal1 =, KeyNoVal2" `.
* `service.beta.kubernetes.io / aws-load-balancer-backend-protocol`: utilizzato sul servizio per specificare il protocollo parlato dal backend (pod) dietro un listener. Se `http` (predefinito) o` https`, viene creato un listener HTTPS che termina la connessione e analizza le intestazioni. Se impostato su `ssl` o` tcp`, viene utilizzato un listener SSL "raw". Se impostato su `http` e` aws-load-balancer-ssl-cert` non viene utilizzato, viene utilizzato un listener HTTP.
* `service.beta.kubernetes.io / aws-load-balancer-ssl-cert`: utilizzato nel servizio per richiedere un listener sicuro. Il valore è un certificato ARN valido. Per ulteriori informazioni, vedere [ELB Listener Config](http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-listener-config.html) CertARN è un ARN certificato IAM o CM, ad es. `ARN: AWS: ACM: US-est-1: 123456789012: certificato / 12345678-1234-1234-1234-123456789012`.
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-enabled`: utilizzato sul servizio per abilitare o disabilitare il drenaggio della connessione.
* `service.beta.kubernetes.io / aws-load-balancer-connection-draining-timeout`: utilizzato sul servizio per specificare un timeout di drenaggio della connessione.
* `service.beta.kubernetes.io / aws-load-balancer-connection-idle-timeout`: utilizzato sul servizio per specificare il timeout della connessione inattiva.
* `service.beta.kubernetes.io / aws-load-balancer-cross-zone-load-bilanciamento-abilitato`: utilizzato sul servizio per abilitare o disabilitare il bilanciamento del carico tra zone.
* `service.beta.kubernetes.io / aws-load-balancer-extra-security-groups`: utilizzato sul servizio per specificare gruppi di sicurezza aggiuntivi da aggiungere a ELB creato
* `service.beta.kubernetes.io / aws-load-balancer-internal`: usato nel servizio per indicare che vogliamo un ELB interno.
* `service.beta.kubernetes.io / aws-load-balancer-proxy-protocol`: utilizzato sul servizio per abilitare il protocollo proxy su un ELB. Al momento accettiamo solo il valore `*` che significa abilitare il protocollo proxy su tutti i backend ELB. In futuro potremmo regolarlo per consentire l'impostazione del protocollo proxy solo su determinati backend.
* `service.beta.kubernetes.io / aws-load-balancer-ssl-ports`: utilizzato sul servizio per specificare un elenco di porte separate da virgole che utilizzeranno listener SSL / HTTPS. Il valore predefinito è `*` (tutto)

Le informazioni per le annotazioni per AWS sono tratte dai commenti su [aws.go](https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/aws/aws.go)

## Azure

### Node Name
Il provider cloud di Azure utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
corrispondere al nome VM di Azure.

## CloudStack

### Node Name
Il provider cloud CloudStack utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
corrispondere al nome VM di CloudStack.

## GCE

### Node Name
Il provider cloud GCE utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il primo segmento del nome del nodo
Kubernetes deve corrispondere al nome dell'istanza GCE (ad esempio, un nodo denominato `kubernetes-node-2.c.my-proj.internal`
deve corrispondere a un'istanza denominata` kubernetes-node-2`) .

## OpenStack
Questa sezione descrive tutte le possibili configurazioni che possono
essere utilizzato quando si utilizza OpenStack con Kubernetes.

### Node Name
Il provider cloud OpenStack utilizza il nome dell'istanza (come determinato dai metadati OpenStack) come nome dell'oggetto Nodo Kubernetes.
Si noti che il nome dell'istanza deve essere un nome nodo Kubernetes valido affinché kubelet registri correttamente il suo oggetto Node.

### Services
Il provider cloud OpenStack implementazione per Kubernetes supporta l'uso di questi servizi OpenStack da la nuvola
sottostante, ove disponibile:

| Servizio | Versioni API | Richiesto |
| -------------------------- | ---------------- | ----- ----- |
| Block Storage (Cinder) | V1 †, V2, V3 | No |
| Calcola (Nova) | V2 | No |
| Identity (Keystone) | V2 ‡, V3 | Sì |
| Load Balancing (Neutron) | V1§, V2 | No |
| Load Balancing (Octavia) | V2 | No |

† Il supporto dell'API di storage block V1 è obsoleto, il supporto dell'API di Storage Block V3 era
aggiunto in Kubernetes 1.9.

‡ Il supporto dell'API di Identity V2 è obsoleto e verrà rimosso dal provider in
una versione futura. A partire dalla versione "Queens", OpenStack non esporrà più il file
Identity V2 API.


§ Il supporto per il bilanciamento del carico V1 API è stato rimosso in Kubernetes 1.9.

La scoperta del servizio si ottiene elencando il catalogo dei servizi gestito da
OpenStack Identity (Keystone) usando `auth-url` fornito nel provider
configurazione. Il fornitore si degraderà garbatamente in funzionalità quando
I servizi OpenStack diversi da Keystone non sono disponibili e semplicemente disconoscono
supporto per le caratteristiche interessate. Alcune funzionalità sono anche abilitate o disabilitate
in base all'elenco delle estensioni pubblicate da Neutron nel cloud sottostante.

### cloud.conf
Kubernetes sa come interagire con OpenStack tramite il file cloud.conf. È
il file che fornirà a Kubernetes le credenziali e il percorso per l'endpoint auth di OpenStack.
È possibile creare un file cloud.conf specificando i seguenti dettagli in esso

#### Typical configuration
Questo è un esempio di una configurazione tipica che tocca i valori più
spesso devono essere impostati. Punta il fornitore al Keystone del cloud di OpenStack
endpoint, fornisce dettagli su come autenticarsi con esso e configura il
bilanciamento del carico:

```yaml
[Global]
username=user
password=pass
auth-url=https://<keystone_ip>/identity/v3
tenant-id=c869168a828847f39f7f06edd7305637
domain-id=2a73b8f597c04551a0fdc8e95544be8a

[LoadBalancer]
subnet-id=6937f8fa-858d-4bc9-a3a5-18d2c957166a
```

##### Global
Queste opzioni di configurazione per il provider OpenStack riguardano la sua globalità
configurazione e dovrebbe apparire nella sezione `[Globale]` di `cloud.conf`
file:

* `auth-url` (obbligatorio): l'URL dell'API keystone utilizzata per l'autenticazione. Sopra
  Pannelli di controllo OpenStack, questo può essere trovato in Access and Security> API
  Accesso> Credenziali.
* `username` (obbligatorio): si riferisce al nome utente di un set utente valido in keystone.
* `password` (obbligatorio): fa riferimento alla password di un set utente valido in keystone.
* `tenant-id` (obbligatorio): usato per specificare l'id del progetto dove si desidera
  per creare le tue risorse.
* `tenant-name` (Opzionale): utilizzato per specificare il nome del progetto in cui si trova
  vuoi creare le tue risorse.
* `trust-id` (Opzionale): utilizzato per specificare l'identificativo del trust da utilizzare
  autorizzazione. Un trust rappresenta l'autorizzazione di un utente (il fidato) a
  delegare i ruoli a un altro utente (il trustee) e facoltativamente consentire al trustee
  per impersonare il fiduciario. I trust disponibili si trovano sotto
  `/v3/OS-TRUST/trust` endpoint dell'API Keystone.
* `domain-id` (Opzionale): usato per specificare l'id del dominio a cui appartiene l'utente
  a.
* `domain-name` (Opzionale): utilizzato per specificare il nome del dominio dell'utente
  appartiene a.
* `region` (Opzionale): utilizzato per specificare l'identificatore della regione da utilizzare quando
  in esecuzione su un cloud OpenStack multiregionale. Una regione è una divisione generale di
  una distribuzione OpenStack. Anche se una regione non ha una geografia rigorosa
  connotazione, una distribuzione può utilizzare un nome geografico per un identificatore di regione
  come `us-east`. Le regioni disponibili si trovano sotto `/v3/region`
  endpoint dell'API Keystone.
* `ca-file` (Opzionale): utilizzato per specificare il percorso del file CA personalizzato.


Quando si usa Keystone V3 - che cambia il titolare del progetto - il valore `tenant-id`
viene automaticamente associato al costrutto del progetto nell'API.

#####  Load Balancer
Queste opzioni di configurazione per il provider OpenStack riguardano il carico
bilanciamento e dovrebbe apparire nella sezione `[LoadBalancer]` di `cloud.conf`
file:

* `lb-version` (Opzionale): usato per sovrascrivere il rilevamento automatico della versione. Valido
  i valori sono `v1` o` v2`. Dove non viene fornito alcun valore, lo sarà il rilevamento automatico
  seleziona la versione supportata più alta esposta dal sottostante OpenStack
  nube.
* `use-octavia` (Opzionale): utilizzato per determinare se cercare e utilizzare un
  Octavia LBaaS V2 endpoint del catalogo di servizi. I valori validi sono `true` o` false`.
  Dove `true` è specificato e non è possibile trovare una voce V2 Octaiva LBaaS, il
  il provider si ritirerà e tenterà di trovare un endpoint Neutron LBaaS V2
  anziché. Il valore predefinito è `false`.
* `subnet-id` (Opzionale): usato per specificare l'id della sottorete che si desidera
  crea il tuo loadbalancer su Può essere trovato su Rete> Reti. Clicca sul
  rispettiva rete per ottenere le sue sottoreti.
* `floating-network-id` (Opzionale): se specificato, creerà un IP mobile per
  il bilanciamento del carico.
* `lb-method` (Opzionale): utilizzato per specificare l'algoritmo in base al quale verrà caricato il carico
  distribuito tra i membri del pool di bilanciamento del carico. Il valore può essere
  `ROUND_ROBIN`,` LEAST_CONNECTIONS` o `SOURCE_IP`. Il comportamento predefinito se
  nessuno è specificato è `ROUND_ROBIN`.
* `lb-provider` (Opzionale): utilizzato per specificare il provider del servizio di bilanciamento del carico.
  Se non specificato, sarà il servizio provider predefinito configurato in neutron
  Usato.
* `create-monitor` (Opzionale): indica se creare o meno una salute
  monitorare il bilanciamento del carico Neutron. I valori validi sono `true` e` false`.
  L'impostazione predefinita è `false`. Quando è specificato `true` quindi` monitor-delay`,
  `monitor-timeout`, e` monitor-max-retries` deve essere impostato.
* `monitor-delay` (Opzionale): il tempo tra l'invio delle sonde a
  membri del servizio di bilanciamento del carico. Assicurati di specificare un'unità di tempo valida. Le unità di tempo
  valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h"
* `monitor-timeout` (Opzionale): tempo massimo di attesa per un monitor
  per una risposta ping prima che scada. Il valore deve essere inferiore al ritardo
  valore. Assicurati di specificare un'unità di tempo valida. Le unità di tempo valide sono "ns", "us" (o "μs"), "ms", "s", "m", "h"
* `monitor-max-retries` (Opzionale): numero di errori ping consentiti prima
  cambiare lo stato del membro del bilanciamento del carico in INATTIVO. Deve essere un numero
  tra 1 e 10.
* `manage-security-groups` (Opzionale): Determina se il carico è o meno
  il sistema di bilanciamento dovrebbe gestire automaticamente le regole del gruppo di sicurezza. Valori validi
  sono `true` e` false`. L'impostazione predefinita è `false`. Quando è specificato `true`
  `node-security-group` deve anche essere fornito.
* `node-security-group` (Opzionale): ID del gruppo di sicurezza da gestire.

##### Block Storage
Queste opzioni di configurazione per il provider OpenStack riguardano lo storage a blocchi
e dovrebbe apparire nella sezione `[BlockStorage]` del file `cloud.conf`:

* `bs-version` (Opzionale): usato per sovrascrivere il rilevamento automatico delle versioni. Valido
  i valori sono `v1`,` v2`, `v3` e` auto`. Quando `auto` è specificato automatico
  il rilevamento selezionerà la versione supportata più alta esposta dal sottostante
  Cloud OpenStack. Il valore predefinito se nessuno è fornito è `auto`.
* `trust-device-path` (Opzionale): Nella maggior parte degli scenari i nomi dei dispositivi a blocchi
  fornito da Cinder (ad esempio `/dev/vda`) non può essere considerato attendibile. Questo commutatore booleano
  questo comportamento Impostandolo su `true` risulta fidarsi dei nomi dei dispositivi a blocchi
  fornito da Cinder. Il valore predefinito di `false` risulta nella scoperta di
  il percorso del dispositivo in base al suo numero di serie e mappatura `/dev/disk/by-id` ed è
  l'approccio raccomandato
* `ignore-volume-az` (Opzionale): usato per influenzare l'uso della zona di disponibilità quando
  allegando i volumi di Cinder. Quando Nova e Cinder hanno una diversa disponibilità
  zone, questo dovrebbe essere impostato su `true`. Questo è più comunemente il caso in cui
  ci sono molte zone di disponibilità Nova ma solo una zona di disponibilità Cinder.
  Il valore predefinito è `false` per preservare il comportamento utilizzato in precedenza
  rilasci, ma potrebbero cambiare in futuro.

Se si distribuiscono le versioni di Kubernetes <= 1.8 su una distribuzione OpenStack che utilizza
percorsi piuttosto che porte per distinguere tra endpoint potrebbe essere necessario
per impostare in modo esplicito il parametro `bs-version`. Un endpoint basato sul percorso è del
forma `http://foo.bar/ volume` mentre un endpoint basato sulla porta è del modulo
`Http://foo.bar: xxx`.

In ambienti che utilizzano endpoint basati sul percorso e Kubernetes utilizza il precedente
logica di auto-rilevamento un errore dell'autodeterminazione della versione API BS non riuscito. Errore
restituito al tentativo di distacco del volume. Per risolvere questo problema lo è
possibile forzare l'uso dell'API di Cinder versione 2 aggiungendo questo al cloud
configurazione del provider:

```yaml
[BlockStorage]
bs-version=v2
```

##### Metadata
Queste opzioni di configurazione per il provider OpenStack riguardano i metadati e
dovrebbe apparire nella sezione `[Metadata]` del file `cloud.conf`:

* `ricerca-ordine` (facoltativo): questo tasto di configurazione influenza il modo in cui il
  il provider recupera i metadati relativi alle istanze in cui viene eseguito. Il
  il valore predefinito di `configDrive, metadataService` risulta nel provider
  recuperare i metadati relativi all'istanza dall'unità di configurazione prima se
  disponibile e quindi il servizio di metadati. I valori alternativi sono:
  * `configDrive` - recupera solo i metadati dell'istanza dalla configurazione
    guidare.
  * `metadataService`: recupera solo i metadati dell'istanza dai metadati
    servizio.
  * `metadataService, configDrive` - Recupera i metadati dell'istanza dai metadati
    prima assistenza se disponibile, quindi l'unità di configurazione.

  Influenzare questo comportamento può essere desiderabile come i metadati sul
  l'unità di configurazione può diventare obsoleta nel tempo, mentre il servizio di metadati
  fornisce sempre la vista più aggiornata. Non tutti i cloud di OpenStack forniscono
  sia l'unità di configurazione che il servizio di metadati e solo l'uno o l'altro
  potrebbe essere disponibile, motivo per cui l'impostazione predefinita è controllare entrambi.

##### Router

Queste opzioni di configurazione per il provider OpenStack riguardano [kubenet]
Il plugin di rete di Kubernetes dovrebbe apparire nella sezione `[Router]` di
File `cloud.conf`:

* `router-id` (opzionale): se supporta la distribuzione Neutron del cloud sottostante
   l'estensione `extraroutes` quindi usa` router-id` per specificare un router da aggiungere
   percorsi per. Il router scelto deve estendersi alle reti private che contengono il tuo
   nodi del cluster (in genere esiste solo una rete di nodi e questo valore dovrebbe essere
   il router predefinito per la rete di nodi). Questo valore è necessario per utilizzare [kubenet]
   su OpenStack.

[kubenet]: https://kubernetes.io/docs/concepts/cluster-administration/network-plugins/#kubenet

{{% /capture %}}

## OVirt

### Node Name
Il provider di cloud OVirt utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
corrispondere al FQDN del VM (riportato da OVirt in `<vm> <guest_info> <fqdn> ... </fqdn> </guest_info> </vm>`)

## Photon

### Node Name
Il provider cloud Photon utilizza il nome host del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
corrispondere al nome VM Photon (o se "overrideIP` è impostato su true in` --cloud-config`, il nome del nodo Kubernetes
deve corrispondere all'indirizzo IP della macchina virtuale Photon).

## VSphere

### Node Name
Il provider cloud VSphere utilizza il nome host rilevato del nodo (come determinato dal kubelet) come nome dell'oggetto
Nodo Kubernetes.

Il parametro `--hostname-override` viene ignorato dal fornitore di cloud VSphere.

## IBM Cloud Kubernetes Service

### Compute nodes
Utilizzando il provider di servizi IBM Cloud Kubernetes, è possibile creare cluster con una combinazione di nodi
virtuali e fisici (bare metal) in una singola zona o su più zone in una regione. Per ulteriori informazioni,
consultare [Pianificazione dell'installazione di cluster e nodo di lavoro](https://cloud.ibm.com/docs/containers?topic=containers-plan_clusters#plan_clusters).

Il nome dell'oggetto Nodo Kubernetes è l'indirizzo IP privato dell'istanza del nodo di lavoro IBM Cloud Kubernetes Service.

### Networking
Il fornitore di servizi IBM Cloud Kubernetes fornisce VLAN per le prestazioni di rete di qualità e l'isolamento della
rete per i nodi. È possibile configurare firewall personalizzati e criteri di rete Calico per aggiungere un ulteriore
livello di sicurezza per il cluster o per connettere il cluster al data center on-prem tramite VPN. Per ulteriori
informazioni, vedere [Pianificazione in-cluster e rete privata](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_cluster#cs_network_cluster).

Per esporre le app al pubblico o all'interno del cluster, è possibile sfruttare i servizi NodePort, LoadBalancer o
Ingress. È anche possibile personalizzare il bilanciamento del carico dell'applicazione Ingress con le annotazioni.
Per ulteriori informazioni, vedere [Pianificazione per esporre le app con reti esterne](https://cloud.ibm.com/docs/containers?topic=containers-cs_network_planning#cs_network_planning).

### Storage
Il fornitore di servizi IBM Cloud Kubernetes sfrutta i volumi persistenti nativi di Kubernetes per consentire agli
utenti di montare archiviazione di file, blocchi e oggetti cloud nelle loro app. È inoltre possibile utilizzare il
componente aggiuntivo database-as-a-service e di terze parti per la memorizzazione permanente dei dati. Per ulteriori
informazioni, vedere [Pianificazione dell'archiviazione persistente altamente disponibile](https://cloud.ibm.com/docs/containers?topic=containers-storage_planning#storage_planning).

## Baidu Cloud Container Engine

### Node Name
Il provider di cloud Baidu utilizza l'indirizzo IP privato del nodo (come determinato dal kubelet o sovrascritto
con `--hostname-override`) come nome dell'oggetto Nodo Kubernetes. Si noti che il nome del nodo Kubernetes deve
corrispondere all'IP privato VM di Baidu.