Cloud Providers

Questa pagina spiega come gestire Kubernetes in esecuzione su uno specifico fornitore di servizi cloud.

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:

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, kube-controller-manager e il 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 per utilizzare funzionalità specifiche in AWS configurando le annotazioni come mostrato di seguito.

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

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:

[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:

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

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.

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.

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.

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.

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.