Los clústeres de Anthos en Bare Metal ahora son Google Distributed Cloud (solo software) para Bare Metal. Para obtener más información, consulta la descripción general del producto.
Información sobre el recurso personalizado de ClusterCIDRConfig
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
Descripción general
ClusterCIDRConfig es un recurso de asignador de CIDR personalizado que te permite asignar más rangos de direcciones IP para los Pods de forma dinámica.
La administración de direcciones IP (IPAM) permite el uso eficiente de las subredes de IP y evita tener superposiciones en los rangos de direcciones, lo que impide los conflictos y las interrupciones de la red.
Kubernetes asigna CIDR de Pod por nodo, que se usan como direcciones IP para los pods que se ejecutan en ese nodo.
El NodeIPAM actual de Kubernetes tiene las siguientes limitaciones:
Todos los CIDR de pod se asignan desde un CIDR de clúster. Debes especificar todo el rango de direcciones IP que representa el clúster más grande en el momento de su creación. Esta limitación puede desperdiciar direcciones IP.
Si aumentas el tamaño del clúster, será difícil agregar más direcciones IP.
El CIDR del clúster es un rango grande. Puede ser difícil encontrar un bloque contiguo de direcciones IP que satisfaga las necesidades del clúster.
Cada nodo obtiene un rango de IP de tamaño fijo dentro de un clúster. Si los nodos tienen diferentes tamaños y capacidades, no puedes asignar un rango de pods más grande a un nodo determinado con mayor capacidad y un rango más pequeño a los nodos con menor capacidad. Esto desperdicia muchas direcciones IP. En un clúster grande con muchos nodos, este desperdicio se acumula en todos los nodos del clúster.
Con la funcionalidad de ClusterCIDRConfig, puedes evitar asignar un bloque CIDR grande a un clúster, asignar el tamaño del clúster a la escala de tus Pods y, por lo tanto, preservar las direcciones IP. Puedes guardar direcciones IP con ClusterCIDRConfigs
con diferentes combinaciones de CIDR y perNodeMaskSize. El recurso ClusterCIDRConfig admite lo siguiente:
Varios bloques CIDR de IP no contiguos para el CIDR del clúster en un nivel más detallado
Afinidad de nodos de bloques CIDR
Diferentes tamaños de bloques asignados a los nodos
Google Distributed Cloud usa la funcionalidad ClusterCIDRConfig en las siguientes funciones:
Cluster.spec.clusterNetwork.pods.cidrBlocks es un campo opcional y no se define de forma predeterminada. Debes definirlo si alguna de las funciones de la lista anterior
no la tiene definida. Por ejemplo, es obligatorio cuando los clústeres se crean en el modo isla de IPv4 y se debe especificar, ya que se usa como un CIDR de enrutamiento nativo.
En la siguiente tabla, se muestra el uso del comportamiento del campo Cluster.spec.clusterNetwork.pods.cidrBlocks de ClusterCIDRConfig para diferentes modos de red.
Cluster.spec.clusterNetwork.pods.cidrBlocks se ignoran por completo y se pueden omitir. Los usuarios deben definir explícitamente ClusterCIDRConfigs (por nodo, por grupo de nodos o por clúster).
Pila doble (isla IPv4, IPv4 plana)
Especifica el CIDR de IPv4.
No especifiques el CIDR de IPv6 en Cluster.spec.clusterNetwork.pods.cidrBlocks.
Especifica ClusterCIDRConfigs con CIDR de IPv4 e IPv6. El CIDR de IPv4 configurado en todos los ClusterCIDRConfigs debe ser el mismo que el CIDR de IPv4 de Cluster.spec.clusterNetwork.pods.cidrBlocks, incluido el valor de PerNodeMask para IPv4. Para obtener más información sobre ClusterCIDRConfig y ejemplos sobre su uso, consulta Ejemplos: pila doble (isla IPv4, IPv6 plano).
Pila doble (IPv4 plano, IPv6 plano)
Puedes omitir Cluster.spec.clusterNetwork.pods.cidrBlocks, ya que se ignoran por completo. Debes definir explícitamente ClusterCIDRConfigs (por nodo, por grupo de nodos o por clúster) con CIDR IPv4 e IPv6.
Cómo configurar el recurso de asignador de CIDR personalizado ClusterCIDRConfig
ClusterCIDRConfig
Cuando configures el recurso de asignador de CIDR personalizado ClusterCIDRConfig, ten en cuenta los siguientes puntos:
La asignación de CIDR de Pod de un ClusterCIDRConfig en particular a un nodo se basa en selectores de etiquetas. Esto es similar al mecanismo de nodeSelector que se usa para programar Pods en un nodo.
Debes configurar ClusterCIDRConfig durante el proceso de creación del clúster en el archivo YAML de configuración del clúster. Una vez que especifiques ClusterCIDRConfigs,
no podrás modificar los valores más adelante.
Puedes especificar varios ClusterCIDRConfigs con CIDR superpuestos.
Si no se encuentra una ClusterCIDRConfig coincidente para un nodo, este permanecerá en un estado NotReady hasta que se cree una ClusterCIDRConfig con etiquetas coincidentes.
Si la mejor coincidencia de ClusterCIDRConfig no tiene más CIDR disponibles para la asignación, se elige el siguiente CIDR mejor y se asignan los CIDR de Pod a partir de los CIDR disponibles.
En el caso del modelo de pila doble, si deseas asignar CIDR de Pod de pila doble a los nodos, haz lo siguiente:
Configura los CIDR IPv4 e IPv6 en ClusterCIDRConfig.
Asegúrate de que todos los ClusterCIDRConfig tengan CIDR de DualStack si se configuran varios.
Asegúrate de que los CIDR IPv4 e IPv6 configurados tengan la misma cantidad de direcciones IP asignables por nodo.
Por ejemplo, 32 - spec.IPv4.PerNodeMaskSize == 128 -
spec.IPv6.PerNodeMaskSize
spec.IPv4.PerNodeMaskSize = 24
spec.IPv6.PerNodeMaskSize = 120
Por lo tanto, 32 - 24 == 128 - 120, ya que la diferencia es 8.
Varios ClusterCIDRConfigs pueden hacer coincidir las etiquetas de nodeSelector con las etiquetas de nodos.
Reglas de asignación de ClusterCIDRConfig
Para determinar qué ClusterCIDRConfig se usa para asignar CIDR de pods al nodo actual, usa las siguientes reglas de desempate. Implementa estas reglas en el orden indicado. Implementa la siguiente regla solo si la regla anterior no rompe el empate.
Elige el ClusterCIDRConfig cuyo NodeSelector coincida con la mayor cantidad de etiquetas en el nodo. Por ejemplo, {'node.kubernetes.io/instance-type':'medium', 'rack':
'rack1'} (Match Count: 2) se elige antes que {'node.kubernetes.io/instance-type': 'medium'}. (Match Count: 1).
Elige el ClusterCIDRConfig con la menor cantidad de CIDR de Pod asignables. Por ejemplo, {CIDR: "10.0.0.0/16", PerNodeMaskSize: "16"} (1 possible Pod
CIDR) se elige antes que {CIDR: "192.168.0.0/20", PerNodeMaskSize: "22"} (4
possible Pod CIDRs).
Elige el ClusterCIDRConfig cuyo PerNodeMaskSize tenga la menor cantidad de direcciones IP.
Por ejemplo, 27 (2^(32-27)= 32 direcciones IP) se elige antes que 25 (2^(32-25)=128 direcciones IP).
Elige el ClusterCIDRConfig cuya etiqueta NodeSelector coincidente tenga un valor alfanumérico inferior. Por ejemplo, se elige {'kubernetes.io/hostname': 'node-1'} en lugar de {'node.kubernetes.io/instance-type':'medium'}.
Elige el ClusterCIDRConfig cuya IP CIDR tenga un valor más bajo. Independientemente de si la configuración es IPv4 o DualStack, solo se comparan los CIDR de IPv4. Por ejemplo, {CIDR: "10.0.0.0/16"} is picked over
{CIDR: "192.168.0.0/16"}.
Ejemplos de configuración
En esta sección, se enumeran ejemplos de configuración para Cluster y ClusterCIDRConfig para todos los modos de red.
Ejemplos: Modo de isla IPv4 (predeterminado)
Configuración del clúster (predeterminada)
apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
name: bm-cluster
namespace: cluster-default
spec:
...
clusterNetwork:
# Pods specify the IP ranges from which pod networks are allocated.
pods:
cidrBlocks:
- 192.168.0.0/16
services:
cidrBlocks:
- 10.96.0.0/12
... (other cluster config omitted)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-02-02 (UTC)"],[],[]]