Concepts

Edit This Page

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:

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

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:

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:

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:

  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:

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.

Feedback