Skip to main content
NetApp public and hybrid cloud solutions
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Distribuisci e configura la piattaforma Red Hat OpenShift Container su Azure

Collaboratori kevin-hoke

Questa sezione descrive un flusso di lavoro di alto livello su come configurare e gestire i cluster OpenShift in Azure e distribuire su di essi applicazioni con stato. Mostra l'utilizzo dello storage NetApp Cloud Volumes ONTAP con l'ausilio di Trident per fornire volumi persistenti. Vengono forniti dettagli sull'utilizzo di Trident Protect per eseguire attività di protezione e migrazione dei dati per le applicazioni con stato.

Ecco un diagramma che mostra i cluster distribuiti su Azure e connessi al data center tramite una VPN.

Figura che mostra il dialogo di input/output o che rappresenta il contenuto scritto

Nota Esistono diversi modi per distribuire i cluster della piattaforma Red Hat OpenShift Container in Azure. Questa descrizione di alto livello della configurazione fornisce link alla documentazione per il metodo specifico utilizzato. È possibile fare riferimento agli altri metodi nei link pertinenti forniti nel"sezione risorse" .

Il processo di configurazione può essere suddiviso nei seguenti passaggi:

Installare un cluster OCP su Azure dalla CLI.
  • Assicurati di aver soddisfatto tutti i prerequisiti indicati"Qui" .

  • Creare una VPN, subnet e gruppi di sicurezza di rete e una zona DNS privata. Crea un gateway VPN e una connessione VPN da sito a sito.

  • Per la connettività VPN tra locale e Azure, è stata creata e configurata una VM pfsense. Per le istruzioni, vedere"Qui" .

  • Ottenere il programma di installazione e il segreto pull e distribuire il cluster seguendo i passaggi forniti nella documentazione"Qui" .

  • L'installazione del cluster è completata e verranno forniti un file kubeconfig, nonché nome utente e password per accedere alla console del cluster.

Di seguito è riportato un esempio di file install-config.yaml.

apiVersion: v1
baseDomain: sddc.netapp.com
compute:
- architecture: amd64
  hyperthreading: Enabled
  name: worker
  platform:
    azure:
      encryptionAtHost: false
      osDisk:
        diskSizeGB: 512
        diskType: "StandardSSD_LRS"
      type: Standard_D2s_v3
      ultraSSDCapability: Disabled
      #zones:
      #- "1"
      #- "2"
      #- "3"
  replicas: 3
controlPlane:
  architecture: amd64
  hyperthreading: Enabled
  name: master
  platform:
    azure:
      encryptionAtHost: false
      osDisk:
        diskSizeGB: 1024
        diskType: Premium_LRS
      type: Standard_D8s_v3
      ultraSSDCapability: Disabled
  replicas: 3
metadata:
  creationTimestamp: null
  name: azure-cluster
networking:
  clusterNetwork:
  - cidr: 10.128.0.0/14
    hostPrefix: 23
  machineNetwork:
  - cidr: 10.0.0.0/16
  networkType: OVNKubernetes
  serviceNetwork:
  - 172.30.0.0/16
platform:
  azure:
    baseDomainResourceGroupName: ocp-base-domain-rg
    cloudName: AzurePublicCloud
    computeSubnet: ocp-subnet2
    controlPlaneSubnet: ocp-subnet1
    defaultMachinePlatform:
      osDisk:
        diskSizeGB: 1024
        diskType: "StandardSSD_LRS"
      ultraSSDCapability: Disabled
    networkResourceGroupName: ocp-nc-us-rg
    #outboundType: UserDefinedRouting
    region: northcentralus
    resourceGroupName: ocp-cluster-ncusrg
    virtualNetwork: ocp_vnet_ncus
publish: Internal
pullSecret:
Distribuisci Cloud Volumes ONTAP in Azure utilizzando BlueXP.
Utilizzo della funzionalità CSI Topology di Trident per architetture multizona

Oggi i provider cloud consentono agli amministratori di cluster Kubernetes/OpenShift di generare nodi di cluster basati su zone. I nodi possono essere ubicati in diverse zone di disponibilità all'interno di una regione o tra regioni diverse. Per facilitare il provisioning dei volumi per i carichi di lavoro in un'architettura multizona, Trident utilizza la topologia CSI. Utilizzando la funzionalità CSI Topology, l'accesso ai volumi può essere limitato a un sottoinsieme di nodi, in base alle regioni e alle zone di disponibilità. Fare riferimento"Qui" per ulteriori dettagli.

Nota Kubernetes supporta due modalità di associazione del volume: - Quando VolumeBindingMode è impostato su Immediate (predefinito), Trident crea il volume senza alcuna consapevolezza della topologia. I volumi persistenti vengono creati senza alcuna dipendenza dai requisiti di pianificazione del pod richiedente. - Quando VolumeBindingMode è impostato su WaitForFirstConsumer, la creazione e l'associazione di un volume persistente per un PVC vengono ritardate finché non viene pianificato e creato un pod che utilizza il PVC. In questo modo, i volumi vengono creati per soddisfare i vincoli di pianificazione imposti dai requisiti di topologia. I backend di archiviazione Trident possono essere progettati per fornire volumi in modo selettivo in base alle zone di disponibilità (backend con riconoscimento della topologia). Per le StorageClass che utilizzano tale backend, un volume verrà creato solo se richiesto da un'applicazione pianificata in una regione/zona supportata. (StorageClass con riconoscimento della topologia) Fare riferimento"Qui" per ulteriori dettagli.