Aplica-se a SUSE Telco Cloud 3.6

33 Considerações e configuração de pilha dupla #

Os exemplos mostrados nas seções anteriores fornecem orientação e exemplos sobre como configurar um cluster de gerenciamento IPv4 de pilha única. Tal cluster de gerenciamento é independente do status operacional dos clusters downstream, que podem ser configurados individualmente para operar em configuração de pilha única IPv4/IPv6 ou pilha dupla, uma vez implantados. No entanto, a maneira como o cluster de gerenciamento é configurado tem um impacto direto nos protocolos de comunicação que podem ser usados durante a fase de provisionamento, onde as comunicações in-band e out-of-band devem ocorrer de acordo com os protocolos suportados pelo cluster de gerenciamento e pelo host downstream. Caso se espere que alguns ou todos os BMCs e/ou nós do cluster downstream usem IPv6, uma configuração de pilha dupla para o cluster de gerenciamento é necessária.

Nota

Clusters de gerenciamento IPv6 de pilha única ainda não são suportados.

Para obter a funcionalidade de pilha dupla, o Kubernetes deve receber CIDRs IPv4 e IPv6 para PODs e Serviços. No entanto, outros componentes também exigem ajustes específicos antes de criar a imagem do cluster de gerenciamento com o EIB. Os serviços de provisionamento Metal³ (Ironic) podem ser configurados de diferentes maneiras, dependendo da sua infraestrutura ou requisitos:

Os serviços Ironic podem ser configurados para escutar em todas as interfaces do sistema em vez de um único endereço IP, portanto, desde que o(s) host(s) do cluster de gerenciamento tenha(m) endereços IPv4 e IPv6 atribuídos à interface relevante, qualquer um deles pode potencialmente ser usado durante o provisionamento. Observe que, neste momento, apenas um desses endereços pode ser selecionado para a geração da URL (para consumo por outros serviços, por exemplo, o Baremetal Operator, BMCs, etc.); como consequência, para habilitar comunicações IPv6 com os BMCs, o Baremetal Operator pode ser instruído a expor e transmitir uma URL IPv6 ao lidar com definições BMH que incluam um endereço IPv6. Em outras palavras, quando um BMC é identificado como compatível com IPv6, o provisionamento será realizado apenas via IPv6, e via IPv4 em todos os outros casos.
Um único nome de host, resolvendo para IPv4 e IPv6, pode ser usado pelo Metal³ para permitir que o Ironic use esses endereços para vinculação e criação de URL. Essa abordagem permite uma configuração fácil e comportamento flexível (tanto IPv4 quanto IPv6 permanecem viáveis em cada etapa de provisionamento), mas requer uma infraestrutura com servidores DNS, alocações de IP e registros preexistentes já em vigor.

Em ambos os casos, o Kubernetes precisará saber quais CIDRs usar para IPv4 e IPv6, portanto, você pode adicionar as seguintes linhas ao seu kubernetes/config/server.yaml no diretório EIB, certificando-se de listar o IPv4 primeiro:

service-cidr: 10.96.0.0/12,fd12:4567:789c::/112
cluster-cidr: 193.168.0.0/18,fd12:4567:789b::/48

Alguns contêineres aproveitam a rede do host, portanto, modifique a configuração de rede para o(s) host(s), no diretório network, para habilitar a conectividade IPv6:

routes:
  config:
  - destination: 0.0.0.0/0
    next-hop-address: ${MGMT_GATEWAY_V4}
    next-hop-interface: eth0
  - destination: ::/0
    next-hop-address: ${MGMT_GATEWAY_V6}
    next-hop-interface: eth0
dns-resolver:
  config:
    server:
    - ${MGMT_DNS}
    - 8.8.8.8
    - 2001:4860:4860::8888
interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: ${MGMT_MAC}
  ipv4:
    address:
    - ip: ${MGMT_CLUSTER_IP_V4}
      prefix-length: 24
    dhcp: false
    enabled: true
  ipv6:
    address:
    - ip: ${MGMT_CLUSTER_IP_V6}
      prefix-length: 128
    dhcp: false
    autoconf: false
    enabled: true

Substitua os espaços reservados pelos endereços IP do gateway, servidor DNS adicional (se necessário), o endereço MAC da interface de rede e o endereço IP do cluster de gerenciamento. Se a autoconfiguração de endereço for preferida, consulte o trecho a seguir e apenas defina a variável ${MGMT_MAC}:

interfaces:
- name: eth0
  type: ethernet
  state: up
  mac-address: ${MGMT_MAC}
  ipv4:
    enabled: true
    dhcp: true
  ipv6:
    enabled: false
    dhcp: true
    autoconf: true

Agora podemos definir os arquivos restantes para uma configuração de nó único, começando pela primeira opção, criando kubernetes/helm/values/metal3.yaml como:

global:
  ironicIP: ${MGMT_CLUSTER_IP_V4}
  enable_vmedia_tls: false
  # trustedCAs: tls-ca-bundle  # Optional: Uncomment and set to ConfigMap name for trusted CA bundle
metal3-ironic:
  global:
    predictableNicNames: true
  listenOnAll: true
  persistence:
    ironic:
      size: "5Gi"
  service:
    type: NodePort
metal3-baremetal-operator:
  baremetaloperator:
    externalHttpIPv6: ${MGMT_CLUSTER_IP_V6}

e kubernetes/helm/values/rancher.yaml como:

hostname: rancher-${MGMT_CLUSTER_IP_V4}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"

onde ${MGMT_CLUSTER_IP_V4} e ${MGMT_CLUSTER_IP_V6} são os endereços IP atribuídos anteriormente ao host.

Alternativamente, para usar o nome do host em vez dos endereços IP, modifique kubernetes/helm/values/metal3.yaml para:

global:
  provisioningHostname: `${MGMT_CLUSTER_HOSTNAME}`
  enable_vmedia_tls: false
  # trustedCAs: tls-ca-bundle  # Optional: Uncomment and set to ConfigMap name for trusted CA bundle
metal3-ironic:
  global:
    predictableNicNames: true
  persistence:
    ironic:
      size: "5Gi"
  service:
    type: NodePort

e kubernetes/helm/values/rancher.yaml para:

hostname: rancher-${MGMT_CLUSTER_HOSTNAME}.sslip.io
bootstrapPassword: "foobar"
replicas: 1
global:
  cattle:
    systemDefaultRegistry: "registry.rancher.com"

onde ${MGMT_CLUSTER_HOSTNAME} deve ser um Nome de Domínio Completo e Qualificado que resolva para os endereços IP do seu host.

Para mais informações, visite SUSE Telco Cloud o repositório do GitHub na pasta \"dual-stack\", onde uma estrutura de diretório de exemplo pode ser encontrada.