Implantar nós de infraestrutura em um cluster do Azure Red Hat OpenShift (ARO)
O ARO permite que você use conjuntos de máquinas de infraestrutura para criar máquinas que hospedam apenas componentes de infraestrutura, como o roteador padrão, o registro de contêiner integrado e os componentes para métricas e monitoramento de cluster. Essas máquinas de infraestrutura não incorrem em custos OpenShift; eles incorrem apenas em custos de computação do Azure.
Em uma implantação de produção, é recomendável implantar três conjuntos de máquinas para armazenar componentes de infraestrutura. Cada um desses nós pode ser implantado em diferentes zonas de disponibilidade para aumentar a disponibilidade. Este tipo de configuração requer três conjuntos de máquinas diferentes; um para cada zona de disponibilidade. Para obter diretrizes de dimensionamento de nós de infraestrutura, consulte Práticas de infraestrutura recomendadas.
Cargas de trabalho qualificadas
As seguintes cargas de trabalho de infraestrutura não incorrem em assinaturas de trabalhador do Azure Red Hat OpenShift:
Serviços de plano de controle Kubernetes e Azure Red Hat OpenShift executados em masters
O roteador padrão
O registro de imagem de contêiner integrado
O controlador de ingresso baseado em HAProxy
A coleta de métricas de cluster ou serviço de monitoramento, incluindo componentes para monitorar projetos definidos pelo usuário
Log agregado por cluster
Importante
A execução de cargas de trabalho diferentes dos tipos designados nos nós de infraestrutura pode afetar o SLA (Service Level Agreement, contrato de nível de serviço) e a estabilidade do cluster.
Antes de começar
Para que as VMs do Azure adicionadas a um cluster ARO sejam reconhecidas como nós de infraestrutura (em oposição a mais nós de trabalho) e não sejam cobradas uma taxa OpenShift, os seguintes critérios devem ser atendidos:
Os nós devem ser apenas um dos seguintes tipos de instância:
- Standard_E4s_v5
- Standard_E8s_v5
- Standard_E16s_v5
- Standard_E4as_v5
- Standard_E8as_v5
- Standard_E16as_v5
Não pode haver mais do que três nós. Quaisquer nós adicionais são cobrados uma taxa OpenShift.
Os nós devem ter uma marca do Azure de node_role: infra
Somente cargas de trabalho designadas para nós de infraestrutura são permitidas. Todas as outras cargas de trabalho considerariam esses nós de trabalho e, portanto, sujeitos à taxa. Isso também pode invalidar o SLA e comprometer a estabilidade do cluster.
Criação de conjuntos de máquinas de infraestrutura
Use o modelo abaixo para criar a definição de manifesto para seu conjunto de máquinas de infraestrutura.
Substitua todos os campos entre "<>" pelos seus valores específicos.
Por exemplo, substitua
location: <REGION>porlocation: westus2Para obter ajuda no preenchimento dos valores necessários, consulte Comandos e valores.
Crie o conjunto de máquinas com o seguinte comando:
oc create -f <machine-set-filename.yaml>Para verificar a criação do conjunto de máquinas, execute o seguinte comando:
oc get machineset -n openshift-machine-apiA saída do comando de verificação deve ser semelhante à abaixo:
NAME DESIRED CURRENT READY AVAILABLE AGE ok0608-vkxvw-infra-westus21 1 1 1 1 165M ok0608-vkxvw-worker-westus21 1 1 1 1 4H24M ok0608-vkxvw-worker-westus22 1 1 1 1 4H24M ok0608-vkxvw-worker-westus23 1 1 1 1 4H24M
Modelo de definição de manifesto
Use o seguinte modelo no procedimento acima para criar a definição de manifesto para seu conjunto de máquinas de infraestrutura:
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
metadata:
labels:
machine.openshift.io/cluster-api-cluster: <INFRASTRUCTURE_ID>
machine.openshift.io/cluster-api-machine-role: infra
machine.openshift.io/cluster-api-machine-type: infra
name: <INFRASTRUCTURE_ID>-infra-<REGION><ZONE>
namespace: openshift-machine-api
spec:
replicas: 1
selector:
matchLabels:
machine.openshift.io/cluster-api-cluster: <INFRASTRUCTURE_ID>
machine.openshift.io/cluster-api-machineset: <INFRASTRUCTURE_ID>-infra-<REGION><ZONE>
template:
metadata:
creationTimestamp: null
labels:
machine.openshift.io/cluster-api-cluster: <INFRASTRUCTURE_ID>
machine.openshift.io/cluster-api-machine-role: infra
machine.openshift.io/cluster-api-machine-type: infra
machine.openshift.io/cluster-api-machineset: <INFRASTRUCTURE_ID>-infra-<REGION><ZONE>
spec:
metadata:
creationTimestamp: null
labels:
machine.openshift.io/cluster-api-machineset: <OPTIONAL: Specify the machine set name to enable the use of availability sets. This setting only applies to new compute machines.>
node-role.kubernetes.io/infra: ''
providerSpec:
value:
apiVersion: azureproviderconfig.openshift.io/v1beta1
credentialsSecret:
name: azure-cloud-credentials
namespace: openshift-machine-api
image:
offer: aro4
publisher: azureopenshift
sku: <SKU>
version: <VERSION>
kind: AzureMachineProviderSpec
location: <REGION>
metadata:
creationTimestamp: null
natRule: null
networkResourceGroup: <NETWORK_RESOURCE_GROUP>
osDisk:
diskSizeGB: 128
managedDisk:
storageAccountType: Premium_LRS
osType: Linux
publicIP: false
resourceGroup: <CLUSTER_RESOURCE_GROUP>
tags:
node_role: infra
subnet: <SUBNET_NAME>
userDataSecret:
name: worker-user-data
vmSize: <Standard_E4s_v5, Standard_E8s_v5, Standard_E16s_v5>
vnet: <VNET_NAME>
zone: <ZONE>
taints:
- key: node-role.kubernetes.io/infra
effect: NoSchedule
Comandos e valores
Abaixo estão alguns comandos/valores comuns usados ao criar e executar o modelo.
Listar todos os conjuntos de máquinas:
oc get machineset -n openshift-machine-api
Obtenha detalhes de um conjunto de máquinas específico:
oc get machineset <machineset_name> -n openshift-machine-api -o yaml
Grupo de recursos de cluster:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'
Grupo de recursos de rede:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.networkResourceGroupName}'
ID da infraestrutura:
oc get infrastructure cluster -o jsonpath='{.status.infrastructureName}'
Região:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.location}'
SKU:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.sku}'
Sub-rede:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.subnet}'
Versão:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.image.version}'
Vnet:
oc get machineset <machineset_name> -n openshift-machine-api -o jsonpath='{.spec.template.spec.providerSpec.value.vnet}'
Movendo cargas de trabalho para os novos nós de infraestrutura
Use as instruções abaixo para mover suas cargas de trabalho de infraestrutura para os nós de infraestrutura criados anteriormente.
Entrada
Use este procedimento para quaisquer controladores de entrada adicionais que você possa ter no cluster.
Nota
Se seu aplicativo tiver requisitos de recursos de entrada muito altos, talvez seja melhor distribuí-los entre nós de trabalho ou um conjunto de máquinas dedicadas.
Defina o
nodePlacementingresscontrollerno paranode-role.kubernetes.io/infrae aumente oreplicaspara corresponder ao número de nós de infraestrutura:oc patch -n openshift-ingress-operator ingresscontroller default --type=merge \ -p='{"spec":{"replicas":3,"nodePlacement":{"nodeSelector":{"matchLabels":{"node-role.kubernetes.io/infra":""}},"tolerations":[{"effect":"NoSchedule","key":"node-role.kubernetes.io/infra","operator":"Exists"}]}}}'Verifique se o Operador do Controlador de Ingresso está iniciando pods nos novos nós de infraestrutura:
oc -n openshift-ingress get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES router-default-69f58645b7-6xkvh 1/1 Running 0 66s 10.129.6.6 cz-cluster-hsmtw-infra-aro-machinesets-eastus-3-l6dqw <none> <none> router-default-69f58645b7-vttqz 1/1 Running 0 66s 10.131.4.6 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none> router-default-6cb5ccf9f5-xjgcp 1/1 Terminating 0 23h 10.131.0.11 cz-cluster-hsmtw-worker-eastus2-xj9qx <none> <none>
Registo
Defina o
nodePlacementno registro comonode-role.kubernetes.io/infra:oc patch configs.imageregistry.operator.openshift.io/cluster --type=merge \ -p='{"spec":{"affinity":{"podAntiAffinity":{"preferredDuringSchedulingIgnoredDuringExecution":[{"podAffinityTerm":{"namespaces":["openshift-image-registry"],"topologyKey":"kubernetes.io/hostname"},"weight":100}]}},"logLevel":"Normal","managementState":"Managed","nodeSelector":{"node-role.kubernetes.io/infra":""},"tolerations":[{"effect":"NoSchedule","key":"node-role.kubernetes.io/infra","operator":"Exists"}]}}'Verifique se o Operador de Registro está iniciando pods nos novos nós de infraestrutura:
oc -n openshift-image-registry get pods -l "docker-registry" -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES image-registry-84cbd76d5d-cfsw7 1/1 Running 0 3h46m 10.128.6.7 cz-cluster-hsmtw-infra-aro-machinesets-eastus-2-kljml <none> <none> image-registry-84cbd76d5d-p2jf9 1/1 Running 0 3h46m 10.129.6.7 cz-cluster-hsmtw-infra-aro-machinesets-eastus-3-l6dqw <none> <none>
Monitorização de cluster
Configure a pilha de monitoramento de cluster para usar os nós de infraestrutura.
Nota
Isso substituirá quaisquer outras personalizações para a pilha de monitoramento de cluster, portanto, convém mesclar as personalizações existentes antes de executar o comando.
cat << EOF | oc apply -f - apiVersion: v1 kind: ConfigMap metadata: name: cluster-monitoring-config namespace: openshift-monitoring data: config.yaml: |+ alertmanagerMain: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" prometheusK8s: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" prometheusOperator: {} grafana: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" k8sPrometheusAdapter: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" kubeStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" telemeterClient: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" openshiftStateMetrics: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" thanosQuerier: nodeSelector: node-role.kubernetes.io/infra: "" tolerations: - effect: "NoSchedule" key: "node-role.kubernetes.io/infra" operator: "Exists" EOFVerifique se o Operador de Monitoramento OpenShift está iniciando pods nos novos nós de infraestrutura. Observe que alguns nós (como
prometheus-operator) permanecerão nos nós mestres.oc -n openshift-monitoring get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES alertmanager-main-0 6/6 Running 0 2m14s 10.128.6.11 cz-cluster-hsmtw-infra-aro-machinesets-eastus-2-kljml <none> <none> alertmanager-main-1 6/6 Running 0 2m46s 10.131.4.11 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none> cluster-monitoring-operator-5bbfd998c6-m9w62 2/2 Running 0 28h 10.128.0.23 cz-cluster-hsmtw-master-1 <none> <none> grafana-599d4b948c-btlp2 3/3 Running 0 2m48s 10.131.4.10 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none> kube-state-metrics-574c5bfdd7-f7fjk 3/3 Running 0 2m49s 10.131.4.8 cz-cluster-hsmtw-infra-aro-machinesets-eastus-1-vr56r <none> <none>
DNS
Permita que os pods DNS sejam executados nos nós da infraestrutura.
oc edit dns.operator/defaultapiVersion: operator.openshift.io/v1 kind: DNS metadata: name: default spec: nodePlacement: tolerations: - operator: ExistsVerifique se os pods DNS estão agendados em todos os nós de infra.
oc get ds/dns-default -n openshift-dns
NAME DESIRED CURRENT READY UP-TO-DATE AVAILABLE NODE SELECTOR AGE
dns-default 7 7 7 7 7 kubernetes.io/os=linux 35d