Implante e configure a plataforma de contentor Red Hat OpenShift no Azure
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