Documentação do SUSE Edge|Documentação do SUSE Telco Cloud|Ações de ciclo de vida

44 Ações de ciclo de vida

 

Esta seção aborda as ações de gerenciamento de ciclo de vida para clusters implantados pelo SUSE Telco Cloud.

44.1 Exclusão de balanceador de carga

 

Há muitas ações de ciclo de vida que exigem drenagem dos nós. Durante o processo de drenagem, todos os pods são removidos para outros nós no cluster. Após o término do processo de drenagem, o nó não hospedará nenhum serviço e, portanto, nenhum tráfego deverá ser roteado para ele. É possível fazer com que os balanceadores de carga, como MetalLB, reconheçam isso aplicando um rótulo ao nó:

node.kubernetes.io/exclude-from-external-load-balancers: "true"

Para obter mais detalhes, consulte: Documentação do Kubernetes.

Para ver os rótulos em todos os nós em um cluster, execute:

kubectl get nodes -o json | jq -r '.items[].metadata | .name, .labels'

No caso de upgrades de clusters downstream, isso pode ser automatizado anotando o RKE2ControlPlane no cluster de gerenciamento:

rke2.controlplane.cluster.x-k8s.io/load-balancer-exclusion="true"

Essa ação cria imediatamente uma anotação em todos os objetos de máquina no cluster de gerenciamento para esse RKE2ControlPlane.

pre-drain.delete.hook.machine.cluster.x-k8s.io/rke2-lb-exclusion: ""

Com essa anotação nos objetos de máquina, qualquer nó no cluster downstream que esteja programado para drenagem receberá o rótulo do nó acima como anexo antes de iniciar o processo de drenagem. O rótulo será removido do nó assim que estiver disponível e pronto novamente.

44.2 Upgrades de cluster de gerenciamento

 

O upgrade do cluster de gerenciamento está descrito na documentação do cluster de gerenciamento do Dia 2 (Capítulo 36, Cluster de gerenciamento).

44.3 Upgrades de cluster downstream

 

O upgrade de clusters downstream envolve a atualização de vários componentes. As seções a seguir abordam o processo de upgrade de cada um deles.

Fazendo upgrade do sistema operacional

Para este processo, consulte a seguinte referência (Seção 43.2, “Preparar uma imagem de cluster downstream para cenários conectados”) para criar uma imagem com uma nova versão do sistema operacional. Com essa imagem gerada pelo EIB, a próxima fase de provisionamento usará a nova versão do sistema operacional fornecida. Na etapa seguinte, a nova imagem será usada para fazer upgrade dos nós.

Fazendo upgrade do cluster RKE2

As alterações necessárias para fazer upgrade do cluster RKE2 usando o fluxo de trabalho automatizado são as seguintes:

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: single-node-cluster
  namespace: default
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: Metal3MachineTemplate
    name: single-node-cluster-controlplane
  version: ${RKE2_NEW_VERSION}
  replicas: 1
  rolloutStrategy:
    type: "RollingUpdate"
    rollingUpdate:
      maxSurge: 0
  serverConfig:
    cni: cilium
  rolloutStrategy:
    rollingUpdate:
      maxSurge: 0
  registrationMethod: "control-plane-endpoint"
  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"
                ExecStartPost=/bin/sh -c "umount /mnt"
                [Install]
                WantedBy=multi-user.target
    kubelet:
      extraArgs:
        - provider-id=metal3://BAREMETALHOST_UUID
    nodeName: "localhost.localdomain"
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: Metal3MachineTemplate
metadata:
  name: single-node-cluster-controlplane
  namespace: default
spec:
  nodeReuse: True
  template:
    spec:
      automatedCleaningMode: metadata
      dataTemplate:
        name: single-node-cluster-controlplane-template
      hostSelector:
        matchLabels:
          cluster-role: control-plane
      image:
        checksum: http://imagecache.local:8080/${NEW_IMAGE_GENERATED}.sha256
        checksumType: sha256
        format: raw
        url: http://imagecache.local:8080/${NEW_IMAGE_GENERATED}.raw

Antes de aplicar o arquivo capi-provisioning-example.yaml, é sempre recomendável informar aos balanceadores de carga externos (ex. MetalLB) sobre os nós que estão sendo drenados, assim eles não roteiam tráfego para os nós nesse estado. Conforme mencionado na Seção 44.1, “Exclusão de balanceador de carga”, você pode automatizar esse processo anotando o RKE2ControlPlane no cluster de gerenciamento. Neste exemplo, um objeto no RKE2ControlPlane chamado multinode-cluster foi anotado:

kubectl annotate  RKE2ControlPlane/multinode-cluster  rke2.controlplane.cluster.x-k8s.io/load-balancer-exclusion="true"

Verifique se os objetos de máquina foram anotados:

pre-drain.delete.hook.machine.cluster.x-k8s.io/rke2-lb-exclusion: ""

Busque as anotações em todos os objetos de máquina:

kubectl get machines -o json | jq -r '.items[].metadata | .name, .annotations'
Nota
Nota

Sem essas anotações, os usuários poderão enfrentar tempos de resposta mais longos dos serviços já que os balanceadores de carga não foram informados sobre os nós drenados.

Depois de fazer essas alterações, o arquivo capi-provisioning-example.yaml poderá ser aplicado ao cluster usando o seguinte comando:

kubectl apply -f capi-provisioning-example.yaml