|Index|SUSE Telco Cloud Documentación|Configuración del clúster de gestión|Consideraciones y configuración de doble pila
Applies to SUSE Telco Cloud 3.6

33 Consideraciones y configuración de doble pila

Los ejemplos mostrados en las secciones anteriores proporcionan orientación y ejemplos sobre cómo configurar un clúster de gestión IPv4 de pila única. Dicho clúster de gestión es independiente del estado operativo de los clústeres descendentes, que pueden configurarse individualmente para operar en una configuración de pila única IPv4/IPv6 o de doble pila, una vez desplegados. Sin embargo, la forma en que se configura el clúster de gestión tiene un impacto directo en los protocolos de comunicación que pueden utilizarse durante la fase de aprovisionamiento, donde tanto las comunicaciones en banda como fuera de banda deben producirse de acuerdo con los protocolos admitidos por el clúster de gestión y el host descendente. En caso de que se espere que algunos o todos los BMCs y/o nodos de clúster descendentes utilicen IPv6, se requiere entonces una configuración de doble pila para el clúster de gestión.

Note
Note

Los clústeres de gestión IPv6 de pila única aún no son compatibles.

Para lograr la funcionalidad de doble pila, se debe proporcionar a Kubernetes CIDR tanto IPv4 como IPv6 para POD y Servicios. Sin embargo, otros componentes también requieren un ajuste específico antes de crear la imagen del clúster de gestión con EIB. Los servicios de aprovisionamiento Metal3 (Ironic) pueden configurarse de diferentes maneras, dependiendo de su infraestructura o requisitos:

  • Los servicios Ironic pueden configurarse para escuchar en todas las interfaces del sistema en lugar de en una única dirección IP, por lo que, siempre que el host o los hosts del clúster de gestión tengan direcciones IPv4 e IPv6 asignadas a la interfaz pertinente, cualquiera de ellas puede utilizarse potencialmente durante el aprovisionamiento. Tenga en cuenta que, en este momento, solo se puede seleccionar una de estas direcciones para la generación de la URL (para su consumo por otros servicios, p. ej., el Baremetal Operator, BMCs, etc.); como consecuencia, para habilitar las comunicaciones IPv6 con los BMCs, se puede indicar al Baremetal Operator que exponga y transmita una URL IPv6 al tratar con definiciones de BMH que incluyan una dirección IPv6. En otras palabras, cuando un BMC se identifica como compatible con IPv6, el aprovisionamiento se realizará solo a través de IPv6, y a través de IPv4 en todos los demás casos.

  • Se puede utilizar un único nombre de host, que resuelva tanto a IPv4 como a IPv6, mediante Metal3 para permitir que Ironic utilice esas direcciones para la vinculación y la creación de la URL. Este enfoque permite una configuración sencilla y un comportamiento flexible (tanto IPv4 como IPv6 siguen siendo viables en cada paso del aprovisionamiento), pero requiere una infraestructura con servidores DNS, asignaciones de IP y registros preexistentes ya implementados.

En ambos casos, Kubernetes necesitará saber qué CIDR utilizar tanto para IPv4 como para IPv6, por lo que puede añadir las siguientes líneas a su kubernetes/config/server.yaml en el directorio EIB, asegurándose de listar IPv4 primero:

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

Algunos contenedores aprovechan la red del host, así que modifique la configuración de red para el/los host(s), bajo el directorio network, para habilitar la conectividad 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

Sustituya los marcadores de posición por las direcciones IP del gateway, el servidor DNS adicional (si es necesario), la dirección MAC de la interfaz de red y las direcciones IP del clúster de gestión. Si se prefiere la autoconfiguración de direcciones, consulte el siguiente extracto y, simplemente, configure la variable ${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

A continuación, defina los archivos restantes para una configuración de un solo nodo, comenzando por la primera opción, creando 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}

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

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

donde ${MGMT_CLUSTER_IP_V4} y ${MGMT_CLUSTER_IP_V6} son las direcciones IP asignadas previamente al host.

Alternativamente, para usar el nombre de host en lugar de las direcciones IP, modifique kubernetes/helm/values/metal3.yaml a:

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

Y modifique kubernetes/helm/values/rancher.yaml a:

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

Donde ${MGMT_CLUSTER_HOSTNAME} debe ser un nombre de dominio completo que resuelva a las direcciones IP de su host.

Para obtener más información, visite SUSE Telco Cloud el repositorio de GitHub bajo la carpeta "dual-stack", donde se puede encontrar una estructura de directorio de ejemplo.