Applies to SUSE Telco Cloud 3.6

51 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 (Chapter 49, 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 na seção (Note).
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 Part 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.

Note

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 Chapter 53, 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

Note

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).

Note

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

Note

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 da API de Cluster 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 noCloudProvider porque um nó bare-metal é usado.

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

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 a serem usadas (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 systemd chamado rke2-preinstall.service para substituir automaticamente o BAREMETALHOST_UUID e node-name durante o processo de provisionamento usando as informações do Ironic. Para habilitar o multus com cilium, um arquivo é criado no diretório de manifestos do servidor rke2 chamado rke2-cilium-config.yaml com a configuração a ser usada. 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.35.4+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"
              ExecStart=/bin/sh -c "sed -i \"s/BAREMETALHOST_UUID/$(jq -r .uuid /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
          # rke2-traefik-deployment.service unit to be removed once "traefik" being the default ingress controller (starting with RKE2 v1.36)
          - name: rke2-traefik-deployment.service
            enabled: true
            contents: |
              [Unit]
              Description=rke2-traefik-deployment
              Wants=rke2-preinstall.service
              Before=rke2-install.service
              ConditionPathExists=!/run/cluster-api/bootstrap-success.complete
              [Service]
              Type=oneshot
              User=root
              ExecStart=/bin/sh -c "echo \"ingress-controller: traefik\" >> /etc/rancher/rke2/config.yaml"
              [Install]
              WantedBy=multi-user.target
        storage:
          directories:
          - path: /var/lib/rancher/rke2/server/manifests
            overwrite: true
          files:
          # https://docs.rke2.io/networking/multus_sriov#using-multus-with-cilium
          - path: /var/lib/rancher/rke2/server/manifests/rke2-cilium-config.yaml
            overwrite: true
            contents:
              inline: |
                apiVersion: helm.cattle.io/v1
                kind: HelmChartConfig
                metadata:
                  name: rke2-cilium
                  namespace: kube-system
                spec:
                  valuesContent: |-
                    cni:
                      exclusive: false
            mode: 0644
            user:
              name: root
            group:
              name: root
          - 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
                      type: LoadBalancer
                      spec:
                        externalTrafficPolicy: Local
                        allocateLoadBalancerNodePorts: false  # k8s GA from 1.24; supported by MetalLB
            mode: 0644
            user:
              name: root
            group:
              name: root
    kubelet:
      extraArgs:
      - provider-id=metal3://BAREMETALHOST_UUID
    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 (Chapter 49, 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/v1beta1
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
        format: 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/v1beta1
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