Implante e configure a plataforma de contentor Red Hat OpenShift no Azure
Sugerir alterações
PDFs
Implante e configure a plataforma de contentor Red Hat OpenShift no Azure
Esta seção descreve um fluxo de trabalho de alto nível de como configurar e gerenciar clusters OpenShift no Azure e implantar aplicativos com estado neles. Isso mostra o uso do storage NetApp Cloud Volumes ONTAP com a ajuda do Trident/Astra Control Provisioner para fornecer volumes persistentes. Fornecemos detalhes sobre o uso do Astra Control Center para realizar atividades de proteção e migração de dados para as aplicações com estado monitorado.
Aqui está um diagrama que mostra os clusters implantados no Azure e conetados ao data center usando uma VPN.
|
Há várias maneiras de implantar clusters de plataforma de contentor do Red Hat OpenShift no Azure. Esta descrição de alto nível da configuração fornece links de documentação para o método específico que foi usado. Pode consultar os outros métodos nos links relevantes fornecidos no "seção recursos". |
O processo de configuração pode ser dividido nas seguintes etapas:
Instale um cluster OCP no Azure a partir da CLI.
-
Certifique-se de que cumpriu todos os pré-requisitos "aqui"indicados .
-
Crie uma VPN, sub-redes e grupos de segurança de rede e uma zona DNS privada. Crie um gateway VPN e uma conexão VPN site-a-site.
-
Para a conetividade VPN entre o local e o Azure, uma VM pfsense foi criada e configurada. Para obter instruções, "aqui"consulte .
-
Obtenha o programa de instalação e o segredo de recebimento e implante o cluster seguindo as etapas fornecidas na documentação "aqui".
-
A instalação do cluster é concluída e fornecerá um arquivo kubeconfig, nome de usuário e senha para fazer login no console do cluster.
Um exemplo de arquivo install-config.yaml é fornecido abaixo.
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:
Implante o Cloud Volumes ONTAP no Azure usando o BlueXP .
-
Instale um conetor no Azure. Consulte as instruções "aqui".
-
Implante uma instância do CVO no Azure usando o conetor. Consulte o link de instruções:https://docs.NetApp.com/US-en/BlueXP -cloud-volumes-ONTAP/task-getting-started-azure.html [aqui.]
Instale o Astra Control Provisioner no cluster OCP no Azure
-
Para este projeto, o Astra Control Provisioner (ACP) foi instalado em todos os clusters (cluster no local, cluster no local onde o Astra Control Center é implantado e o cluster no Azure). Saiba mais sobre o Astra Control Provisioner ."aqui"
-
Crie backend e classes de armazenamento. Consulte as instruções "aqui".
Adicione o cluster OCP no Azure ao Astra Control Center.
Os provedores de nuvem, hoje, permitem que os administradores de cluster do Kubernetes/OpenShift criem nós dos clusters baseados em zona. Os nós podem ser localizados em diferentes zonas de disponibilidade dentro de uma região ou em várias regiões. Para facilitar o provisionamento de volumes para workloads em uma arquitetura de várias zonas, o Trident usa a topologia de CSI. Usando o recurso de topologia de CSI, o acesso a volumes pode ser limitado a um subconjunto de nós, com base em regiões e zonas de disponibilidade. "aqui"Consulte para obter mais detalhes.
|
|
O Kubernetes suporta dois modos de vinculação de volume: - Quando VolumeBindingMode está definido como imediato (padrão), o Trident cria o volume sem qualquer reconhecimento de topologia. Os volumes persistentes são criados sem depender dos requisitos de agendamento do pod solicitante. - Quando VolumeBindingMode definido como WaitForFirstConsumer, a criação e vinculação de um volume persistente para um PVC é adiada até que um pod que usa o PVC seja programado e criado. Dessa forma, os volumes são criados para atender às restrições de agendamento impostas pelos requisitos de topologia. Os back-ends de storage do Trident podem ser projetados para provisionar volumes seletivamente com base em zonas de disponibilidade (back-end com reconhecimento de topologia). Para o StorageClasses que fazem uso de tal back-end, um volume só seria criado se solicitado por um aplicativo agendado em uma região/zona suportada. (StorageClass com reconhecimento de topologia) "aqui"consulte para obter detalhes adicionais. |
[Underline] no.Vídeo de demonstração no