Aplica-se a SUSE Telco Cloud 3.7

52 Provisionamento de cluster downstream com provisionamento de rede direcionado (nó único) #

Esta seção descreve o fluxo de trabalho usado para automatizar o provisionamento de um cluster downstream de nó único usando provisionamento de rede direcionado. Esta é a maneira mais simples de automatizar o provisionamento de um cluster downstream.

Requisitos

A imagem gerada usando EIB, conforme descrito na seção anterior (Capítulo 50, Preparar a imagem do cluster downstream para cenários conectados), com a configuração mínima para configurar o cluster downstream deve estar localizada no cluster de gerenciamento exatamente no caminho que você configurou nesta seção (Nota).
O servidor de gerenciamento foi criado e está disponível para ser usado nas seções a seguir. Para obter mais informações, consulte a seção de Cluster de Gerenciamento Parte V, “Configurando o cluster de gerenciamento”.

Fluxo de trabalho

O diagrama a seguir mostra o fluxo de trabalho usado para automatizar o provisionamento de um cluster downstream de nó único usando provisionamento de rede direcionado:

Existem duas etapas diferentes para automatizar o provisionamento de um cluster downstream de nó único usando provisionamento de rede direcionado:

Registre o host bare-metal para torná-lo disponível para o processo de provisionamento.
Provisione o host bare-metal para instalar e configurar o sistema operacional e o cluster Kubernetes.

Registre o host bare-metal

A primeira etapa é registrar o novo host bare-metal no cluster de gerenciamento para torná-lo disponível para ser provisionado. Para fazer isso, o arquivo a seguir (bmh-example.yaml) deve ser criado no cluster de gerenciamento, para especificar as credenciais BMC a serem usadas e o objeto BaremetalHost a ser inscrito:

apiVersion: v1
kind: Secret
metadata:
  name: example-demo-credentials
type: Opaque
data:
  username: ${BMC_USERNAME}
  password: ${BMC_PASSWORD}
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: example-demo
  labels:
    cluster-role: control-plane
spec:
  architecture: x86_64
  online: true
  bootMACAddress: ${BMC_MAC}
  rootDeviceHints:
    deviceName: /dev/nvme0n1
  bmc:
    address: ${BMC_ADDRESS}
    disableCertificateVerification: true
    credentialsName: example-demo-credentials

em que:

${BMC_USERNAME} — O nome de usuário para o BMC do novo host bare-metal.
${BMC_PASSWORD} — A senha para o BMC do novo host bare-metal.
${BMC_MAC} — O endereço MAC do novo host bare-metal a ser usado.
${BMC_ADDRESS} — O URL para o host bare-metal BMC (por exemplo, redfish-virtualmedia://192.168.200.75/redfish/v1/Systems/1/). Para saber mais sobre as diferentes opções disponíveis dependendo do seu provedor de hardware, verifique o seguinte link.

Nota

A arquitetura deve ser x86_64 ou aarch64, dependendo da arquitetura do host bare-metal a ser inscrito.
Se nenhuma configuração de rede para o host tiver sido especificada, seja no momento da criação da imagem ou por meio da definição BareMetalHost, um mecanismo de autoconfiguração (DHCP, DHCPv6, SLAAC) será usado. Para mais detalhes ou configurações complexas, verifique o Capítulo 54, Configuração de rede avançada.

Assim que o arquivo for criado, o comando a seguir deve ser executado no cluster de gerenciamento para iniciar a inscrição do novo host bare-metal no cluster de gerenciamento:

$ kubectl apply -f bmh-example.yaml

O novo objeto de host bare-metal será inscrito, alterando seu estado de registering para inspecting e available. As alterações podem ser verificadas usando o seguinte comando:

$ kubectl get bmh

Nota

O objeto BaremetalHost fica no estado registering até que as credenciais BMC sejam validadas. Assim que as credenciais forem validadas, o objeto BaremetalHost altera seu estado para inspecting, e esta etapa pode levar algum tempo dependendo do hardware (até 20 minutos). Durante a fase de inspeção, as informações de hardware são recuperadas e o objeto Kubernetes é atualizado. Verifique as informações usando o seguinte comando: kubectl get bmh -o yaml.

Etapa de provisionamento

Uma vez que o host bare-metal esteja inscrito e disponível, a próxima etapa é provisionar o host bare-metal para instalar e configurar o sistema operacional e o cluster Kubernetes. Para fazer isso, o seguinte arquivo (capi-provisioning-example.yaml) deve ser criado no cluster de gerenciamento com as seguintes informações (o capi-provisioning-example.yaml pode ser gerado unindo os seguintes blocos).

Nota

Apenas valores entre $\{…\} devem ser substituídos pelos valores reais.

O bloco a seguir é a definição do cluster, onde a rede pode ser configurada usando os blocos pods e services. Além disso, ele contém as referências aos objetos do plano de controle e da infraestrutura (usando o provedor Metal³) a serem usados.

apiVersion: cluster.x-k8s.io/v1beta2
kind: Cluster
metadata:
  name: single-node-cluster
  namespace: default
  labels:
    cluster-api.cattle.io/rancher-auto-import: "true"
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 192.168.0.0/18
        - fd00:bad:cafe::/48
    services:
      cidrBlocks:
        - 10.96.0.0/12
        - fd00:bad:bad:cafe::/112
  controlPlaneRef:
    apiGroup: controlplane.cluster.x-k8s.io
    kind: RKE2ControlPlane
    name: single-node-cluster
  infrastructureRef:
    apiGroup: infrastructure.cluster.x-k8s.io
    kind: Metal3Cluster
    name: single-node-cluster

Nota

Implantações de pilha única e pilha dupla são possíveis; remova os CIDRs IPv6 da definição acima para um cluster apenas IPv4.
Implantações de pilha única IPv6 estão em status de prévia técnica e ainda não são oficialmente suportadas.
Adicionar o rótulo cluster-api.cattle.io/rancher-auto-import: "true" aos objetos cluster.x-k8s.io importará o cluster para o Rancher (criando um objeto clusters.management.cattle.io correspondente). Consulte a documentação do Cluster API para obter mais informações.

O objeto Metal3Cluster especifica o endpoint do plano de controle (substituindo o ${DOWNSTREAM_CONTROL_PLANE_IPV4}) a ser configurado e o sinalizador cloudProviderEnabled definido como false porque um nó bare-metal é usado.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: Metal3Cluster
metadata:
  name: single-node-cluster
  namespace: default
spec:
  controlPlaneEndpoint:
    host: ${DOWNSTREAM_CONTROL_PLANE_IPV4}
    port: 6443
  cloudProviderEnabled: false

O objeto RKE2ControlPlane especifica a configuração do plano de controle a ser usada e o objeto Metal3MachineTemplate especifica a imagem do plano de controle a ser usada. Além disso, ele contém as informações sobre o número de réplicas necessárias (neste caso, uma) e o plug-in CNI a ser usado (neste caso, Cilium). O bloco agentConfig contém o formato Ignition a ser usado e o additionalUserData a ser usado para configurar o nó RKE2 com informações como um serviço de unidade systemd chamado rke2-preinstall.service para substituir automaticamente o PROVIDERID e node-name durante o processo de provisionamento usando as informações do Ironic. A configuração necessária para o controlador de entrada RKE2 (baseado em Traefik) também está incluída, juntamente com os manifestos de instância de recursos personalizados MetalLB (IPAddressPool e L2Advertisement) necessários para expor externamente o serviço Ingress através dos IPs Virtuais ${INGRESS_IPV4} e ${INGRESS_IPV6}. O último bloco de informações contém a versão do Kubernetes a ser usada. ${RKE2_VERSION} é a versão do RKE2 a ser usada substituindo este valor (por exemplo, v1.36.3+rke2r1).

apiVersion: controlplane.cluster.x-k8s.io/v1beta2
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
  annotations: {
    rke2.controlplane.cluster.x-k8s.io/load-balancer-exclusion: "true"
  }
spec:
  machineTemplate:
  infrastructureRef:
    apiGroup: infrastructure.cluster.x-k8s.io
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  replicas: 1
  version: ${RKE2_VERSION}
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  serverConfig:
    cni: cilium
  agentConfig:
    format: ignition
    additionalUserData:
      config: |
        variant: fcos
        version: 1.4.0
        systemd:
          units:
          - name: rke2-preinstall.service
            enabled: true
            contents: |
              [Unit]
              Description=rke2-preinstall
              Wants=network-online.target
              Before=rke2-install.service
              ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
              [Service]
              Type=oneshot
              User=root
              ExecStartPre=/bin/sh -c "mount -L config-2 /mnt"
              # Note we use _ as a delimiter for sed here because the providerid includes / characters
              ExecStart=/bin/sh -c "sed -i \"s_PROVIDERID_$(jq -r .providerid /mnt/openstack/latest/meta_data.json)_\" /etc/rancher/rke2/config.yaml"
              ExecStart=/bin/sh -c "echo \"node-name: $(jq -r .name /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
              ExecStart=/bin/sh -c "echo \"node-label:\" >> /etc/rancher/rke2/config.yaml"
              ExecStart=/bin/sh -c "echo \"  - metal3.io/uuid=$(jq -r .uuid /mnt/openstack/latest/meta_data.json)\" >> /etc/rancher/rke2/config.yaml"
              ExecStartPost=/bin/sh -c "umount /mnt"
              [Install]
              WantedBy=multi-user.target
        storage:
          directories:
          - path: /var/lib/rancher/rke2/server/manifests
            overwrite: true
          files:
          - path: /var/lib/rancher/rke2/server/manifests/rke2-traefik-config.yaml
            overwrite: true
            contents:
              inline: |
                apiVersion: helm.cattle.io/v1
                kind: HelmChartConfig
                metadata:
                  name: rke2-traefik
                  namespace: kube-system
                spec:
                  valuesContent: |-
                    ingressClass:
                      isDefaultClass: true
                    ports:
                      web:
                        hostPort: null    # disallow hostPort
                        exposedPort: 80
                      websecure:
                        hostPort: null    # disallow hostPort
                        exposedPort: 443
                    service:
                      enabled: true
                      spec:
                        type: LoadBalancer
                        externalTrafficPolicy: Local
                        allocateLoadBalancerNodePorts: false
            mode: 0644
            user:
              name: root
            group:
              name: root
          - path: /var/lib/rancher/rke2/server/manifests/metallb-traefik-cr.yaml
            overwrite: true
            contents:
              inline: |
                apiVersion: metallb.io/v1beta1
                kind: IPAddressPool
                metadata:
                  name: ingress-ippool
                  namespace: metallb-system
                spec:
                  addresses:
                    - ${INGRESS_IPV4}/32
                    - ${INGRESS_IPV6}/128
                  serviceAllocation:
                    priority: 100
                    serviceSelectors:
                    - matchExpressions:
                      - {key: app.kubernetes.io/name, operator: In, values: [rke2-traefik]} # assign to rke2-traefik LB svc
                ---
                apiVersion: metallb.io/v1beta1
                kind: L2Advertisement
                metadata:
                  name: ingress-l2-adv
                  namespace: metallb-system
                spec:
                  ipAddressPools:
                    - ingress-ippool
            mode: 0644
            user:
              name: root
            group:
              name: root
    kubelet:
      extraArgs:
      - provider-id=metal3://PROVIDERID
    nodeName: "localhost.localdomain"

O objeto Metal3MachineTemplate especifica as seguintes informações:

O dataTemplate a ser usado como referência para o modelo.
O hostSelector a ser usado correspondendo ao rótulo criado durante o processo de inscrição.
O image a ser usado como referência para a imagem gerada usando EIB na seção (Capítulo 50, Preparar a imagem do cluster downstream para cenários conectados) anterior, e o checksum e checksumType a serem usados para validar a imagem.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: Metal3MachineTemplate
metadata:
  name: single-node-cluster-controlplane
  namespace: default
spec:
  template:
    spec:
      dataTemplate:
        name: single-node-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/eibimage-output-telco.raw.sha256
        checksumType: sha256
        diskFormat: raw
        url: http://imagecache.local:8080/eibimage-output-telco.raw

O objeto Metal3DataTemplate especifica o metaData para o cluster downstream.

apiVersion: infrastructure.cluster.x-k8s.io/v1beta2
kind: Metal3DataTemplate
metadata:
  name: single-node-cluster-controlplane-template
  namespace: default
spec:
  clusterName: single-node-cluster
  metaData:
    objectNames:
    - key: name
      object: machine
    - key: local-hostname
      object: machine
    - key: local_hostname
      object: machine

Uma vez que o arquivo seja criado juntando os blocos anteriores, o seguinte comando deve ser executado no cluster de gerenciamento para iniciar o provisionamento do novo host bare-metal:

$ kubectl apply -f capi-provisioning-example.yaml