Consideraciones para clústeres en modo mixto Configurar clústeres en modo mixto

Configuración de webhooks para nodos híbridos

Esta página presenta consideraciones importantes para la ejecución de webhooks con nodos híbridos. Los webhooks se utilizan en aplicaciones de Kubernetes y en proyectos de código abierto, como Controlador del equilibrador de carga de AWS y el agente de observabilidad de CloudWatch, para realizar funciones de mutación y validación en tiempo de ejecución.

Redes de pods enrutables

Si puede configurar el CIDR del pod en las instalaciones para que sea enrutable en la red en las instalaciones, puede ejecutar webhooks en los nodos híbridos. Existen varias técnicas que puede utilizar para hacer que el CIDR de los pods en las instalaciones sea enrutable en la red en las instalaciones, como el protocolo de puerta de enlace fronteriza (BGP), rutas estáticas u otras soluciones de enrutamiento personalizadas. BGP es la solución recomendada, ya que es más escalable y fácil de administrar que las soluciones alternativas que requieren configuración manual o personalizada de rutas. AWS admite las capacidades de BGP de Cilium y Calico para anunciar los CIDR de los pods. Consulte Cómo configurar una CNI para nodos híbridos y CIDR de pod remoto enrutable para obtener más información.

Redes de pods no enrutables

Si no puede hacer que el CIDR del pod en las instalaciones sea enrutable en la red en las instalaciones y necesita ejecutar webhooks, le recomendamos que ejecute todos los webhooks en los nodos de la nube en el mismo clúster EKS que los nodos híbridos.

Consideraciones para clústeres en modo mixto

Los clústeres en modo mixto se definen como clústeres de EKS que tienen tanto nodos híbridos como nodos que se ejecutan en la nube de AWS. Al ejecutar un clúster en modo mixto, tenga en cuenta las siguientes recomendaciones:

Ejecute la CNI de la VPC en los nodos en la nube de AWS y Cilium o Calico en nodos híbridos. Cilium y Calico no son compatibles con AWS cuando se ejecutan en nodos en la nube de AWS.
Configure los webhooks para que se ejecuten en los nodos en la nube de AWS. Consulte Configuración de webhooks para complementos para saber cómo configurar los webhooks para AWS y los complementos de la comunidad.
Si las aplicaciones requieren que los pods que se ejecutan en nodos en la nube de AWS se comuniquen directamente con los pods en nodos híbridos (“comunicación este-oeste”), y utiliza la CNI de la VPC en los nodos en la nube de AWS, junto con Cilium o Calico en los nodos híbridos, entonces el CIDR de los pods en las instalaciones debe ser enrutable en la red en las instalaciones.
Ejecute al menos una réplica de CoreDNS en los nodos de la nube de AWS y al menos una réplica de CoreDNS en los nodos híbridos.
Configure la distribución de tráfico del servicio para mantener el tráfico del servicio local en la zona de la que se origina. Para obtener más información sobre la distribución de tráfico del servicio, consulte Configurar la distribución de tráfico del servicio.
Si utiliza equilibradores de carga de aplicaciones (ALB) o equilibradores de carga de red (NLB) de AWS para el tráfico de las cargas de trabajo que se ejecutan en nodos híbridos, las direcciones IP de destino utilizadas con el ALB o NLB deben ser enrutable desde AWS.
El complemento Metrics Server requiere conectividad desde el plano de control de EKS hasta la dirección IP del pod de Metrics Server. Si ejecuta el complemento Metrics Server en nodos híbridos, el CIDR de pods en las instalaciones debe ser enrutable dentro de la red en las instalaciones.
Para recopilar métricas de nodos híbridos con los recolectores administrados por Amazon Managed Service para Prometheus (AMP), el CIDR de pods en las instalaciones debe ser enrutable en la red en las instalaciones. De otro modo, puede utilizar el recopilador administrado de AMP para las métricas del plano de control de EKS y de los recursos que se ejecutan en la nube de AWS, y el complemento AWS Distro para OpenTelemetry (ADOT) para recopilar métricas de los nodos híbridos.

Configurar clústeres en modo mixto

Para ver los webhooks de mutación y validación que se ejecutan en el clúster, puede consultar el tipo de recurso Extensiones en el panel de Recursos de la consola de EKS, o usar los siguientes comandos. EKS también reporta métricas de webhooks en el panel de observabilidad del clúster. Consulte Supervisión del clúster con el panel de observabilidad para obtener más información.


kubectl get mutatingwebhookconfigurations


kubectl get validatingwebhookconfigurations

Configurar la distribución de tráfico del servicio

Cuando ejecute clústeres de modo mixto, le recomendamos que utilice la distribución de tráfico del servicio para mantener el tráfico del servicio local en la zona de la que se origina. La distribución de tráfico del servicio (disponible para versiones de Kubernetes 1.31 y posteriores en EKS) es la solución recomendada en lugar del enrutamiento consciente de la topología, ya que ofrece un comportamiento más predecible. Con la distribución de tráfico del servicio, los puntos de conexión en buen estado dentro de una zona recibirán todo el tráfico correspondiente a esa zona. Con el enrutamiento consciente de la topología, cada servicio debe cumplir varias condiciones en esa zona para que se aplique el enrutamiento personalizado; de lo contrario, el tráfico se distribuye de manera equitativa entre todos los puntos de conexión.

Si utiliza Cilium como CNI, debe ejecutar la CNI con la opción enable-service-topology establecida en true para habilitar la distribución del tráfico de servicios. Puede transmitir esta configuración con el indicador de instalación de Helm --set loadBalancer.serviceTopology=true o puede actualizar una instalación existente con el comando de la CLI de Cilium cilium config set enable-service-topology true. El agente de Cilium que se ejecuta en cada nodo se debe reiniciar después de actualizar la configuración de una instalación existente.

En la siguiente sección se muestra un ejemplo de cómo configurar la distribución de tráfico del servicio para el servicio CoreDNS, y le recomendamos que habilite la misma para todos los servicios del clúster a fin de evitar el tráfico no deseado entre entornos.

Configuración de réplicas de CoreDNS

Cuando ejecuta clústeres en modo mixto, le recomendamos contar con al menos una réplica de CoreDNS en los nodos híbridos y otra en los nodos ubicados en la nube de AWS.

Agregue una etiqueta de zona de topología para cada uno de los nodos híbridos, por ejemplo topology.kubernetes.io/zone: onprem. O bien, puede establecer la etiqueta en la fase nodeadm init. Para ello, especifíquela en la configuración nodeadm (consulte Configuración de nodos para personalizar kubelet (opcional)). Nota: Los nodos que se ejecutan en la nube de AWS reciben automáticamente una etiqueta de zona de topología que corresponde a la zona de disponibilidad (AZ) del nodo.
```
kubectl label node hybrid-node-name topology.kubernetes.io/zone=zone
               
```

Agregue podAntiAffinity a la implementación de CoreDNS con la clave de zona de topología. De otro modo, puede configurar la implementación de CoreDNS durante la instalación con complementos de EKS.


kubectl edit deployment coredns -n kube-system


spec:
  template:
    spec:
      affinity:
       ...
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: k8s-app
                  operator: In
                  values:
                  - kube-dns
              topologyKey: kubernetes.io/hostname
            weight: 100
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: k8s-app
                  operator: In
                  values:
                  - kube-dns
              topologyKey: topology.kubernetes.io/zone
            weight: 50
      ...

Añada el ajuste trafficDistribution: PreferClose a la configuración del servicio de kube-dns para habilitar la distribución de tráfico del servicio.
```
kubectl patch svc kube-dns -n kube-system --type=merge -p '{
  "spec": {
    "trafficDistribution": "PreferClose"
  }
}'
```
Para confirmar que la distribución del tráfico del servicio está habilitada, puede consultar los segmentos de puntos de conexión del servicio kube-dns. Los segmentos de puntos de conexión deben mostrar las hints de las etiquetas de zona topológica, lo que confirma que la distribución del tráfico del servicio está habilitada. Si no ve la hints para cada dirección de punto de conexión, significa que la distribución del tráfico del servicio no está habilitada.
```
kubectl get endpointslice -A | grep "kube-dns"
```
```
kubectl get endpointslice [.replaceable]`kube-dns-<id>`  -n kube-system -o yaml
```
```
addressType: IPv4
apiVersion: discovery.k8s.io/v1
endpoints:
- addresses:
  - <your-hybrid-node-pod-ip>
  hints:
    forZones:
    - name: onprem
  nodeName: <your-hybrid-node-name>
  zone: onprem
- addresses:
  - <your-cloud-node-pod-ip>
  hints:
    forZones:
    - name: us-west-2a
  nodeName: <your-cloud-node-name>
  zone: us-west-2a
```

Configuración de webhooks para complementos

Los siguientes complementos utilizan webhooks y son compatibles para su uso con nodos híbridos.

Controlador del equilibrador de carga de AWS
Agente de observabilidad de Amazon CloudWatch
AWS Distro para OpenTelemetry (ADOT)
cert-manager

Consulte las secciones que aparecen a continuación para configurar los webhooks que estos complementos utilizan para que se ejecuten en nodos en la nube de AWS.

Controlador del equilibrador de carga de AWS

Para utilizar el controlador del equilibrador de carga de AWS en una configuración de clúster de modo mixto, debe ejecutar el controlador en nodos en la nube de AWS. Para ello, agregue lo siguiente a la configuración de valores de Helm o especifique los valores mediante la configuración del complemento de EKS.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid

Agente de observabilidad de Amazon CloudWatch

El complemento del agente de observabilidad de CloudWatch tiene un operador de Kubernetes que utiliza webhooks. Para ejecutar el operador en nodos en la nube de AWS dentro de una configuración de clúster en modo mixto, edite la configuración del operador del agente de observabilidad de CloudWatch. No es posible configurar la afinidad del operador durante la instalación con Helm y los complementos de EKS (consulte incidencia n.º 2431 containers-roadmap).


kubectl edit -n amazon-cloudwatch deployment amazon-cloudwatch-observability-controller-manager


spec:
  ...
  template:
    ...
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: eks.amazonaws.com/compute-type
                operator: NotIn
                values:
                - hybrid

AWS Distro para OpenTelemetry (ADOT)

El complemento de AWS Distro para OpenTelemetry (ADOT) tiene un operador de Kubernetes que utiliza webhooks. Para ejecutar el operador en nodos en la nube de AWS dentro de una configuración de clúster en modo mixto, agregue lo siguiente a la configuración de valores de Helm o especifique los valores mediante la configuración del complemento de EKS.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid

Si el CIDR de pods no es enrutable en la red en las instalaciones, el recopilador de ADOT se debe ejecutar en los nodos híbridos para obtener las métricas de los nodos híbridos y de las cargas de trabajo que se ejecutan en estos. Para ello, edite la definición de recurso personalizado (CRD).


kubectl -n opentelemetry-operator-system edit opentelemetrycollectors.opentelemetry.io adot-col-prom-metrics


spec:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: In
            values:
            - hybrid

Puede configurar el recopilador de ADOT para que obtenga únicamente métricas de los nodos híbridos y de los recursos que se ejecutan en estos. Para ello, agregeue las siguientes relabel_configs a cada scrape_configs en la configuración de CRD del recopilador de ADOT.


relabel_configs:
  - action: keep
    regex: hybrid
    source_labels:
    - __meta_kubernetes_node_label_eks_amazonaws_com_compute_type

El complemento ADOT tiene como requisito previo instalar cert-manager para los certificados TLS utilizados por el webhook del operador de ADOT. cert-manager también ejecuta webhooks y se puede configurar de manera que se ejecute en nodos en la nube de AWS con la siguiente configuración de valores de Helm.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
webhook:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
cainjector:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
startupapicheck:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid

`cert-manager`

El complemento cert-manager ejecuta webhooks y se puede configurar de manera que se ejecute en nodos en la nube de AWS con la siguiente configuración de valores de Helm.


affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: eks.amazonaws.com/compute-type
          operator: NotIn
          values:
          - hybrid
webhook:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
cainjector:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid
startupapicheck:
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: eks.amazonaws.com/compute-type
            operator: NotIn
            values:
            - hybrid

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Configuración de complementos

Configuración del proxy