Consideraciones Requisitos previos Configurar políticas de red Demostración de política Stars Solución de problemas Políticas de red de Kubernetes

Configure su clúster para las políticas de red de Kubernetes

De forma predeterminada, no hay restricciones en Kubernetes para las direcciones IP, puertos o conexiones entre cualquier Pods de su clúster o entre sus Pods y recursos en cualquier otra red. Puede usar la política de red de Kubernetes para restringir el tráfico de red que entra y sale de su Pods. Para obtener más información, consulte Políticas de red en la documentación de Kubernetes.

Si tiene una versión 1.13 o anterior del Amazon VPC CNI plugin for Kubernetes en su clúster, tiene que implementar una solución de terceros para aplicar políticas de red de Kubernetes a su clúster. La versión 1.14 o posterior del complemento puede implementar políticas de red, de modo que no es necesario utilizar una solución de terceros. En este tema, aprenderá a configurar el clúster para que utilice la política de red de Kubernetes en su clúster sin utilizar un complemento de terceros.

Las políticas de red del Amazon VPC CNI plugin for Kubernetes se admiten en las siguientes configuraciones.

Clústeres de Amazon EKS de la versión 1.25 y posterior.
Versión 1.14 o posterior del Amazon VPC CNI plugin for Kubernetes en su clúster.
Clúster configurado para las direcciones IPv4 o IPv6.
Puede utilizar las políticas de red con los grupos de seguridad para Pods. Con las políticas de red, puede controlar todas las comunicaciones dentro del clúster. Con los grupos de seguridad para Pods, puede controlar el acceso a Servicios de AWS desde aplicaciones dentro de un Pod.
Puede utilizar las políticas de red con las redes personalizadas y la delegación de prefijos.

Consideraciones

Al aplicar las políticas de red del Amazon VPC CNI plugin for Kubernetes a su clúster con el Amazon VPC CNI plugin for Kubernetes, puede aplicar las políticas únicamente a los nodos de Linux de Amazon EC2. No puede aplicar las políticas a los nodos de Fargate o Windows.
Si su clúster utiliza actualmente una solución de terceros para la administración de políticas de red de Kubernetes, puede usar esas mismas políticas con el Amazon VPC CNI plugin for Kubernetes. Sin embargo, debe eliminar la solución existente para que no administre las mismas políticas.
Puede aplicar varias políticas de red al mismo Pod. Cuando se han configurado dos o más políticas que seleccionan el mismo Pod, todas las políticas se aplican al Pod.
El número máximo de combinaciones únicas de puertos para cada protocolo en cada selector de ingress: o egress: en una política de red es 24.
Para cualquiera de sus servicios de Kubernetes, el puerto de servicio debe ser el mismo que el puerto del contenedor. Si utiliza puertos con nombre, utilice también el mismo nombre en la especificación del servicio.
Aplicación de políticas al inicio del Pod

El Amazon VPC CNI plugin for Kubernetes configura las políticas de red para los pods en paralelo con el aprovisionamiento de los pods. A menos que se hayan configurado todas las políticas para el nuevo pod, los contenedores del nuevo pod se iniciarán con una política de permisos predeterminada. Esto se denomina modo estándar. Una política de permisos predeterminada significa que se permite todo el tráfico de entrada y salida desde y hacia los nuevos pods.

Para cambiar esta política de red predeterminada, debe configurar la variable de entorno NETWORK_POLICY_ENFORCING_MODE en strict en el contenedor aws-node del DaemonSet de la CNI de la VPC.
```
env:
  - name: NETWORK_POLICY_ENFORCING_MODE
    value: "strict"
```
Con la variable NETWORK_POLICY_ENFORCING_MODE configurada en strict, los pods que utilizan la CNI de la VPC se inician con una política de denegación predeterminada y, a continuación, se configuran las políticas. Esto se denomina modo estricto. En el modo estricto, debe tener una política de red para cada punto de conexión del clúster al que los pods necesiten acceder. Tenga en cuenta que este requisito se aplica a los pods CoreDNS. La política de denegación predeterminada no está configurada para los pods con redes de Host.
La característica de política de red crea y requiere una definición de recurso personalizada (CRD) de PolicyEndpoint llamada policyendpoints.networking.k8s.aws. Amazon EKS administra los objetos PolicyEndpoint del recurso personalizado. No debe modificar ni eliminar estos recursos.
Si ejecuta pods que utilizan las credenciales de IAM del rol de instancia o se conectan al IMDS de EC2, compruebe si hay políticas de red que puedan bloquear el acceso al IMDS de EC2. Puede que tenga que añadir una política de red para permitir el acceso al IMDS de EC2. Para obtener más información, consulte el tema Metadatos de instancia y datos de usuario en la guía del usuario de instancias de Linux de Amazon EC2.

Los pods que utilizan los roles de IAM para cuentas de servicio no accedan al IMDS de EC2.
El Amazon VPC CNI plugin for Kubernetes no aplica políticas de red a las interfaces de red adicionales de cada pod, solo a la interfaz principal de cada pod (eth0). Esta característica afecta a las siguientes arquitecturas:
- Pods IPv6 con la variable ENABLE_V4_EGRESS establecida en true. Esta variable habilita la característica de salida IPv4 para conectar los pods IPv6 a puntos de conexión IPv4, como aquellos fuera del clúster. La característica de salida IPv4 funciona mediante la creación de una interfaz de red adicional con una dirección IPv4 de bucle invertido local.
- Cuando se utilizan complementos de red encadenados, como Multus. Debido a que estos complementos añaden interfaces de red a cada pod, las políticas de red no se aplican a los complementos de red encadenados.
La característica de la política de red utiliza el puerto 8162 del nodo para las métricas de manera predeterminada. Además, la característica utilizaba el puerto 8163 para las sondas de estado. Si ejecuta otra aplicación en los nodos o dentro de pods que necesite utilizar estos puertos, la aplicación no se puede ejecutar. En la versión de CNI de VPC v1.14.1 o posterior, puede cambiar estos puertos en los siguientes lugares:
AWS Management Console
Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.

En el panel de navegación izquierdo, seleccione Clústeres y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.

Elija la pestaña Complementos.

Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija Edit (Editar).

En la página Configurar el nombre del complemento:

Seleccione la versión v1.14.0-eksbuild.3 o posterior en la lista desplegable Versión.

Seleccione Ajustes de configuración opcionales.

Introduzca la clave JSON "enableNetworkPolicy": y el valor "true" en Valores de configuración. El texto resultante debe ser un objeto JSON válido. Si esta clave y este valor son los únicos datos del cuadro de texto, rodee la clave y el valor entre corchetes {}.

El siguiente ejemplo tiene habilitada la característica de política de red y los registros de política de red habilitados. Estos se envían a Registros de Amazon CloudWatch, y las métricas y sondas de estado se configuran con los números de puertos predeterminados:

{ "enableNetworkPolicy": "true", "nodeAgent": { "enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true", "healthProbeBindAddr": "8163", "metricsBindAddr": "8162" } }
Helm
Si ha instalado el Amazon VPC CNI plugin for Kubernetes mediante helm, puede actualizar la configuración para cambiar los puertos.

Ejecute el siguiente comando para cambiar los puertos. Establezca el número de puerto en el valor para la clave nodeAgent.metricsBindAddr o nodeAgent.healthProbeBindAddr, respectivamente.

helm upgrade --set nodeAgent.metricsBindAddr=8162 --set nodeAgent.healthProbeBindAddr=8163 aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
kubectl
Abra el DaemonSet de aws-node en el editor.

kubectl edit daemonset -n kube-system aws-node

Reemplace los números de puertos en los siguientes argumentos de comando de args: del contenedor aws-network-policy-agent del manifiesto del daemonset de aws-node de CNI de VPC.

- args: - --metrics-bind-addr=:8162 - --health-probe-bind-addr=:8163

Requisitos previos

Versión mínima del clúster

Un clúster existente de Amazon EKS. Para implementar uno, consulte Introducción a Amazon EKS. El clúster debe ser la versión 1.25 de Kubernetes o posterior. El clúster debe estar ejecutando una de las versiones de Kubernetes y versiones de la plataforma que se enumeran en la siguiente tabla. Tenga en cuenta que también se admite cualquier versión de Kubernetes y de la plataforma posterior a las enumeradas. Puede comprobar la versión actual de Kubernetes reemplazando my-cluster en el siguiente comando por el nombre del clúster y luego ejecutando el comando modificado:


aws eks describe-cluster
              --name my-cluster --query cluster.version --output
              text

Versión de Kubernetes	Versión de la plataforma
`1.27.4`	`eks.5`
`1.26.7`	`eks.6`
`1.25.12`	`eks.7`

Versión mínima de CNI de VPC

Versión 1.14 o posterior del Amazon VPC CNI plugin for Kubernetes en su clúster. Puede comprobar qué versión utiliza actualmente con el siguiente comando.
```
kubectl describe daemonset aws-node --namespace kube-system | grep amazon-k8s-cni: | cut -d : -f 3
```
Si su versión es anterior a la 1.14, actualice Actualizar el complemento de Amazon EKS a la versión 1.14 o posterior.
Versión mínima del kernel de Linux

Sus nodos deben tener la versión del núcleo de Linux 5.10 o posterior. Puede comprobar la versión del núcleo con uname -r. Si utiliza las versiones más recientes de las AMI optimizadas para Amazon EKS de Amazon Linux, las AMI optimizadas para Amazon EKS de Amazon Linux acelerado y las AMI de Bottlerocket, estas ya tienen la versión de núcleo necesaria.

La versión v20231116 de la AMI de Amazon Linux acelerada y optimizada de Amazon EKS o posterior tiene una versión 5.10 de núcleo.

Para configurar su clúster para que use las políticas de red de Kubernetes

Montar el sistema de archivos BPF

nota
Si su clúster es la versión 1.27 o posterior, puede omitir este paso, ya que todas las AMI de Amazon Linux y Bottlerocket optimizadas para Amazon EKS para la versión 1.27 o posterior ya disponen de esta característica.
Para todas las demás versiones de clústeres, si actualiza Amazon Linux optimizado para Amazon EKS a la versión v20230703 o posterior, o actualiza la AMI de Bottlerocket a la versión v1.0.2 o posterior, puede omitir este paso.
1. Monte el sistema de archivos Berkeley Packet Filter (BPF) en cada uno de sus nodos.
```
sudo mount -t bpf bpffs /sys/fs/bpf
```
2. A continuación, añada el mismo comando a los datos de usuario en la plantilla de lanzamiento de sus grupos de Amazon EC2 Auto Scaling.
Habilitar la política de red en el CNI de VPC
1. Consulte qué tipo del complemento está instalado en el clúster. Según la herramienta con la que haya creado el clúster, es posible que actualmente no tenga instalado el tipo de complemento Amazon EKS en el clúster. Reemplace my-cluster por el nombre de su clúster.
```
aws eks describe-addon --cluster-name my-cluster --addon-name vpc-cni --query addon.addonVersion --output text
```
  Si se devuelve el número de versión, tiene el tipo de complemento de Amazon EKS instalado en el clúster y no es necesario que complete los pasos restantes del procedimiento. Si se devuelve un error, no tiene el tipo de complemento de Amazon EKS instalado en el clúster.
2. - Complemento de Amazon EKS
    AWS Management Console
    
    Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.
    
    En el panel de navegación izquierdo, seleccione Clústeres y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
    
    Elija la pestaña Complementos.
    
    Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija Edit (Editar).
    
    En la página Configurar el nombre del complemento:
    
    Seleccione la versión v1.14.0-eksbuild.3 o posterior en la lista desplegable Versión.
    
    Seleccione Ajustes de configuración opcionales.
    
    Introduzca la clave JSON "enableNetworkPolicy": y el valor "true" en Valores de configuración. El texto resultante debe ser un objeto JSON válido. Si esta clave y este valor son los únicos datos del cuadro de texto, rodee la clave y el valor entre corchetes {}. En el siguiente ejemplo se muestra que la política de red está habilitada:
    
    { "enableNetworkPolicy": "true" }
    
    En la siguiente captura de pantalla se muestra un ejemplo de este escenario.
    
    AWS CLI
    
    Ejecute el siguiente comando de la AWS CLI. Reemplace my-cluster por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.
    
    aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \ --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \ --resolve-conflicts PRESERVE --configuration-values '{"enableNetworkPolicy": "true"}'
  - Complemento autoadministrado
    Helm
    
    Si ha instalado el Amazon VPC CNI plugin for Kubernetes mediante helm, puede actualizar la configuración para habilitar la política de red.
    
    Ejecute el siguiente comando para habilitar la política de red.
    
    helm upgrade --set enableNetworkPolicy=true aws-vpc-cni --namespace kube-system eks/aws-vpc-cni
    
    kubectl
    
    Abra el ConfigMap de amazon-vpc-cni en el editor.
    
    kubectl edit configmap -n kube-system amazon-vpc-cni -o yaml
    
    Añada la línea siguiente al data de ConfigMap.
    
    enable-network-policy-controller: "true"
    
    Una vez que haya añadido la línea, el ConfigMap debería tener un aspecto similar al siguiente ejemplo.
    
    apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true"
    
    Abra el DaemonSet de aws-node en el editor.
    
    kubectl edit daemonset -n kube-system aws-node
    
    Sustituya el false por true en el argumento del comando --enable-network-policy=false en el args: del contenedor aws-network-policy-agent en el manifiesto del daemonset de aws-node del CNI de VPC.
    
    - args: - --enable-network-policy=true
Confirme que los pods de aws-node se estén ejecutando en su clúster.
```
kubectl get pods -n kube-system | grep 'aws-node\|amazon'
```
Un ejemplo de salida sería el siguiente.
```
aws-node-gmqp7                                          2/2     Running   1 (24h ago)   24h
aws-node-prnsh                                          2/2     Running   1 (24h ago)   24h
```
Si la política de red está habilitada, hay 2 contenedores en los pods de aws-node. En versiones anteriores, y si la política de red está deshabilitada, solo hay un contenedor en los pods de aws-node.

Ahora puede implementar políticas de red de Kubernetes en su clúster. Para obtener más información, consulte Políticas de red de Kubernetes.

Demostración Stars de la política de red

Esta demostración crea un frontend, un backend y un servicio cliente en el clúster de Amazon EKS. La demostración también crea una interfaz gráfica de usuario de administración que muestra las rutas de entrada y salida disponibles entre los servicios. Le recomendamos que complete la demostración en un clúster en el que no ejecute cargas de trabajo de producción.

Cuando aún no se ha creado ninguna política de red, todos los servicios pueden comunicarse en ambas direcciones. Después de aplicar las políticas de red, puede ver que el cliente solo puede comunicarse con el servicio frontend y el backend solo puede aceptar tráfico del frontend.

Para ejecutar la demostración de política Stars

Aplique los servicios de frontend, backend, cliente e interfaz de usuario de administración:


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml

Visualice todos los Pods en el clúster.


kubectl get pods -A

Un ejemplo de salida sería el siguiente.

En la salida, debería ver pods en los espacios de nombres que se muestran en la siguiente salida. Los valores de NAMES y el número de pods de la columna READY son diferentes de los de la siguiente salida. No continúe hasta que vea pods con nombres similares y todos tengan Running en la columna STATUS.


NAMESPACE         NAME                                       READY   STATUS    RESTARTS   AGE
[...]
client            client-xlffc                               1/1     Running   0          5m19s
[...]
management-ui     management-ui-qrb2g                        1/1     Running   0          5m24s
stars             backend-sz87q                              1/1     Running   0          5m23s
stars             frontend-cscnf                             1/1     Running   0          5m21s
[...]

Para conectarse a la interfaz de usuario de administración, conéctese a la EXTERNAL-IP del servicio que se ejecuta en el clúster:
```
kubectl get service/management-ui -n management-ui
```
Abra el navegador en la ubicación del paso anterior. Debería ver la interfaz de usuario de administración. El nodo C es el servicio cliente, el nodo F es el servicio frontend y el nodo B es el servicio backend. Cada nodo tiene acceso de comunicación completo a todos los demás nodos, como indican las líneas gruesas de colores.

Aplique la siguiente política de red en los espacios de nombres de stars y client para aislar los servicios entre sí:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels: {}

Puede usar los siguientes comandos para aplicar la política a ambos espacios de nombres:


kubectl apply -n stars -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml
kubectl apply -n client -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/default-deny.yaml

Actualice su navegador. Verá que la interfaz de usuario de administración ya no tiene acceso a los nodos, que dejan de aparecer en la interfaz de usuario.

Aplique las siguientes políticas de red distintas para permitir el acceso de la interfaz de usuario de administración a los servicios. Aplique esta política para permitir la interfaz de usuario:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

Aplique esta política para permitir el cliente:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: client 
  name: allow-ui 
spec:
  podSelector:
    matchLabels: {}
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: management-ui

Puede usar los siguientes comandos para aplicar ambas políticas:


kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui.yaml
kubectl apply -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/apply_network_policies.files/allow-ui-client.yaml

Actualice su navegador. Verá que la interfaz de usuario de administración tiene de nuevo acceso a los nodos, pero los nodos no pueden comunicarse entre sí.

Aplique la siguiente política de red para permitir el tráfico desde el servicio frontend hacia el servicio backend:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      role: backend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              role: frontend
      ports:
        - protocol: TCP
          port: 6379

Actualice su navegador. Puede ver que el frontend puede comunicarse con el backend.

Aplique la siguiente política de red para permitir el tráfico desde el cliente hacia el servicio frontend:


kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  namespace: stars
  name: frontend-policy
spec:
  podSelector:
    matchLabels:
      role: frontend 
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              role: client
      ports:
        - protocol: TCP
          port: 80

Actualice su navegador. Verá que el cliente puede comunicarse con el servicio frontend. El servicio frontend puede seguir comunicándose con el servicio backend.

(Opcional) Cuando haya terminado con la demostración, puede eliminar sus recursos.


kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/client.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/frontend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/backend.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/management-ui.yaml
kubectl delete -f https://eksworkshop.com/beginner/120_network-policies/calico/stars_policy_demo/create_resources.files/namespace.yaml

Incluso después de eliminar los recursos, todavía puede haber puntos de conexión de las políticas de red en los nodos que podrían interferir de manera inesperada con las redes en el clúster. La única forma segura de eliminar estas reglas es reiniciar los nodos o terminar todos los nodos y reciclarlos. Para terminar todos los nodos, establezca el recuento deseado del grupo de Auto Scaling en 0 y, a continuación, realice una copia de seguridad en el número deseado o simplemente termine los nodos.

Solución de problemas de las políticas de red

Puede solucionar problemas e investigar las conexiones de red que utilizan políticas de red leyendo los Registros de políticas de red y ejecutando las herramientas del eBPF SDK.

Registros de políticas de red

Se registra si una política de red permite o deniega las conexiones en los registros de flujo. Los registros de políticas de red de cada nodo incluyen los registros de flujo de cada pod que tiene una política de red. Los registros de políticas de red se almacenan en /var/log/aws-routed-eni/network-policy-agent.log. A continuación se muestra un ejemplo de un archivo network-policy-agent.log:

{"level":"info","timestamp":"2023-05-30T16:05:32.573Z","logger":"ebpf-client","msg":"Flow Info: ","Src
IP":"192.168.87.155","Src Port":38971,"Dest IP":"64.6.160","Dest
Port":53,"Proto":"UDP","Verdict":"ACCEPT"}

Los registros de políticas de red está deshabilitados de manera predeterminada. Para habilitar los registros de políticas de red, siga estos pasos:

nota

Los registros de políticas de red requieren 1 vCPU adicional para el contenedor aws-network-policy-agent del manifiesto del daemonset de aws-node del CNI de la VPC.

Complemento de Amazon EKS

AWS Management Console

Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.
En el panel de navegación izquierdo, seleccione Clústeres y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
Elija la pestaña Complementos.
Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija Edit (Editar).
En la página Configurar el nombre del complemento:
1. Seleccione la versión v1.14.0-eksbuild.3 o posterior en la lista desplegable Versión.
2. Seleccione Ajustes de configuración opcionales.
3. Introduzca la clave de JSON de nivel superior "nodeAgent": y el valor en un objeto con una clave "enablePolicyEventLogs": y un valor de "true" en Valores de configuración. El texto resultante debe ser un objeto JSON válido. En el siguiente ejemplo se muestra que la política de red y los registros de políticas de red están habilitados, y que estos últimos se envían a los Registros de CloudWatch:
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true"
    }
}
```

En la siguiente captura de pantalla se muestra un ejemplo de este escenario.

AWS Management Console mostrando el complemento CNI de VPC con la política de red y los Registros de CloudWatch en la configuración opcional.

AWS CLI

Ejecute el siguiente comando de la AWS CLI. Reemplace my-cluster por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true"}}'

Complemento autoadministrado

Enviar los registros de políticas de red a los Registros de Amazon CloudWatch

Puede supervisar los registros de políticas de red mediante servicios como los Registros de Amazon CloudWatch. Puede usar los siguientes métodos para enviar los registros de políticas de red a los Registros de CloudWatch.

En el caso de los clústeres de EKS, los registros de políticas se ubicarán en /aws/eks/cluster-name/cluster/ y, en el caso de los clústeres K8S autoadministrados, los registros se colocarán en/aws/k8s-cluster/cluster/.

Enviar los registros de políticas de red con el Amazon VPC CNI plugin for Kubernetes

Si habilita la política de red, se añade un segundo contenedor a los pods de aws-node para un agente de nodos. Este agente de nodos puede enviar los registros de políticas de red a los Registros de CloudWatch.

nota

El agente de nodos solo envía los registros de políticas de red. No se incluyen otros registros creados por el CNI de VPC.

Requisitos previos

Añada los siguientes permisos como una política individual o independiente al rol de IAM que está utilizando para el CNI de VPC.


{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "logs:DescribeLogGroups",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:PutLogEvents"
            ],
            "Resource": "*"
        }
    ]
}

Complemento de Amazon EKS

AWS Management Console

Abra la consola de Amazon EKS en https://console.aws.amazon.com/eks/home#/clusters.
En el panel de navegación izquierdo, seleccione Clústeres y, a continuación, seleccione el nombre del clúster para el que desea configurar el complemento CNI de Amazon VPC.
Elija la pestaña Complementos.
Seleccione la casilla situada en la parte superior derecha del cuadro y, a continuación, elija Edit (Editar).
En la página Configurar el nombre del complemento:
1. Seleccione la versión v1.14.0-eksbuild.3 o posterior en la lista desplegable Versión.
2. Seleccione Ajustes de configuración opcionales.
3. Introduzca la clave de JSON de nivel superior "nodeAgent": y el valor en un objeto con una clave "enableCloudWatchLogs": y un valor de "true" en Valores de configuración. El texto resultante debe ser un objeto JSON válido. En el siguiente ejemplo se muestra que la política de red y los registros de políticas de red están habilitados, y que estos últimos se envían a los Registros de CloudWatch:
```
{
    "enableNetworkPolicy": "true",
    "nodeAgent": {
        "enablePolicyEventLogs": "true",
        "enableCloudWatchLogs": "true",
    }
}
```

En la siguiente captura de pantalla se muestra un ejemplo de este escenario.

AWS CLI

Ejecute el siguiente comando de la AWS CLI. Reemplace my-cluster por el nombre del clúster y el ARN del rol de IAM por el rol que va a usar.


aws eks update-addon --cluster-name my-cluster --addon-name vpc-cni --addon-version v1.14.0-eksbuild.3 \
    --service-account-role-arn arn:aws:iam::123456789012:role/AmazonEKSVPCCNIRole \
    --resolve-conflicts PRESERVE --configuration-values '{"nodeAgent": {"enablePolicyEventLogs": "true", "enableCloudWatchLogs": "true"}}'

Complemento autoadministrado

Enviar los registros de políticas de red con el daemonset de Fluent Bit

Si utiliza Fluent Bit en un daemonset para enviar registros desde sus nodos, puede agregar una configuración para incluir los registros de políticas de red de las políticas de red. Puede utilizar la siguiente configuración de ejemplo:


    [INPUT]
        Name              tail
        Tag               eksnp.*
        Path              /var/log/aws-routed-eni/network-policy-agent*.log
        Parser            json
        DB                /var/log/aws-routed-eni/flb_npagent.db
        Mem_Buf_Limit     5MB
        Skip_Long_Lines   On
        Refresh_Interval  10

SDK de eBPF incluido

El Amazon VPC CNI plugin for Kubernetes instala la colección de herramientas del SDK de eBPF en los nodos. Puede utilizar las herramientas del SDK de eBPF para identificar problemas con las políticas de red. Por ejemplo, el siguiente comando muestra los programas que se ejecutan en el nodo.


sudo /opt/cni/bin/aws-eks-na-cli ebpf progs

Para ejecutar este comando, puede utilizar cualquier método para conectarse al nodo.

Políticas de red de Kubernetes

Para implementar políticas de red de Kubernetes, cree objetos NetworkPolicy de Kubernetes e impleméntelos en su clúster. Los objetos NetworkPolicy están limitados a un espacio de nombres. Implemente políticas para permitir o denegar el tráfico entre Pods en función de los selectores de etiquetas, los espacios de nombres y los rangos de direcciones IP. Para obtener más información sobre cómo crear objetos NetworkPolicy, consulte Políticas de red en la documentación de Kubernetes.

La aplicación de los objetos NetworkPolicy de Kubernetes se implementa mediante el Extended Berkeley Packet Filter (eBPF). En relación con las implementaciones basadas en iptables, ofrece características de rendimiento y latencia más bajas, que incluyen una menor utilización de la CPU y evitan las búsquedas secuenciales. Además, las sondas de eBPF proporcionan acceso a datos en contexto que ayudan a depurar problemas complejos a nivel del núcleo y a mejorar la observabilidad. Amazon EKS es compatible con un exportador basado en eBPF que aprovecha las sondas para registrar los resultados de las políticas en cada nodo y exportar los datos a recopiladores de registros externos para facilitar la depuración. Para obtener más información, consulte la Documentación de eBPF.

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

SNAT

Redes personalizadas

Configure su clúster para las políticas de red de Kubernetes

Consideraciones

Aplicación de políticas al inicio del Pod

Requisitos previos

Versión mínima del clúster

Versión mínima de CNI de VPC

Versión mínima del kernel de Linux

Para configurar su clúster para que use las políticas de red de Kubernetes

Montar el sistema de archivos BPF

nota

Habilitar la política de red en el CNI de VPC

Demostración Stars de la política de red

Para ejecutar la demostración de política Stars

Solución de problemas de las políticas de red

Registros de políticas de red

nota

Complemento de Amazon EKS

Complemento autoadministrado

Enviar los registros de políticas de red a los Registros de Amazon CloudWatch

Enviar los registros de políticas de red con el Amazon VPC CNI plugin for Kubernetes

nota

Requisitos previos

Complemento de Amazon EKS

Complemento autoadministrado

Enviar los registros de políticas de red con el daemonset de Fluent Bit

SDK de eBPF incluido

Políticas de red de Kubernetes