Implantar nós de infraestrutura em um cluster do ARO (Red Hat OpenShift no Azure)
O ARO permite que você use conjuntos de máquinas de infraestrutura para criar computadores que hospedam apenas componentes de infraestrutura, como o roteador padrão, o registro de contêiner integrado e os componentes para métricas de cluster e monitoramento. Esses computadores de infraestrutura não incorrem em custos do OpenShift. Eles só incorrem em custos de Computação do Azure.
Em uma implantação de produção, é recomendável que você implante três conjuntos de computadores para manter os componentes de infraestrutura. Cada um desses nós pode ser implantado em zonas de disponibilidade diferentes para aumentar a disponibilidade. Esse tipo de configuração exige três conjuntos de computadores diferentes, uma para cada zona de disponibilidade. Para obter diretrizes de dimensionamento de nó de infraestrutura, confira Melhores práticas de infraestrutura.
Cargas de trabalho qualificadas
As seguintes cargas de trabalho de infraestrutura não incorrem em assinaturas de trabalho do Red Hat OpenShift no Azure:
Serviços de painel de controle do Kubernetes e do Red Hat OpenShift no Azure executados em mestres
O roteador padrão
O registro de imagem de contêiner integrado
O controlador de entrada baseado em HAProxy
A coleção de métricas do cluster ou o serviço de monitoramento, inclusive componentes para monitorar os 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 (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 do ARO sejam reconhecidas como nós de infraestrutura (ao contrário de mais nós de trabalho) e para que não seja cobrado um valor do 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. Para todos os nós adicionais será cobrado um valor do OpenShift.
Os nós devem ter uma marca do Azure de node_role: infra
Somente as 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, estão sujeitas ao valor. Isso também pode invalidar o SLA e comprometer a estabilidade do cluster.
Criação de conjuntos de computadores de infraestrutura
Use o modelo abaixo para criar a definição de manifesto do conjunto de computadores de infraestrutura.
Substitua todos os campos entre "<>" pelos valores específicos.
Por exemplo, substitua
location: <REGION>porlocation: westus2Para obter ajuda para preencher os valores necessários, confira Comandos e valores.
Crie o conjunto de computadores com o seguinte comando:
oc create -f <machine-set-filename.yaml>Para verificar a criação do conjunto de computadores, execute o seguinte comando:
oc get machineset -n openshift-machine-apiA saída do comando de verificação deve ser semelhante à seguinte:
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 o conjunto de computadores 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: aro-vnet
zone: <ZONE>
taints:
- key: node-role.kubernetes.io/infra
effect: NoSchedule
Comandos e valores
Veja abaixo alguns comandos/valores comuns usados ao criar e executar o modelo.
Liste todos os conjuntos de computadores:
oc get machineset -n openshift-machine-api
Obtenha os detalhes de um conjunto de computadores específico:
oc get machineset <machineset_name> -n openshift-machine-api -o yaml
Grupo de recursos do cluster:
oc get infrastructure cluster -o jsonpath='{.status.platformStatus.azure.resourceGroupName}'
Grupo de recursos da 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}'
Como mover as cargas de trabalho para os novos nós de infraestrutura
Use as instruções abaixo para mover as cargas de trabalho de infraestrutura para os nós de infraestrutura criados anteriormente.
Entrada
Use este procedimento para os controladores de entrada adicionais que você possa ter no cluster.
Observação
Se o aplicativo tiver requisitos de recursos de entrada muito exigentes, talvez seja melhor distribui-los entre os nós de trabalho ou um conjunto de computadores dedicado.
Defina o
nodePlacementnoingresscontrollercomonode-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 Entrada está iniciando os 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>
Registro
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 do Registro está iniciando os 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>
Monitoramento do cluster
Configure a pilha de monitoramento do cluster para usar os nós de infraestrutura.
Observação
Isso substituirá as outras personalizações na pilha de monitoramento do cluster. Portanto, talvez você queira 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 do OpenShift está iniciando os 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 de 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