En esta página, se explica cómo usar el registro de políticas de red para Google Kubernetes Engine (GKE). Las políticas de red de Kubernetes especifican el tráfico de red que los Pods pueden enviar y recibir. El registro de políticas de red te permite registrar cuando una política de red permite o rechaza una conexión. El registro de políticas de red puede ayudarte a solucionar problemas con las políticas de red.
Descripción general
Mediante el registro de políticas de red, puedes hacer lo siguiente:
- Verificar que las políticas de red funcionen según lo previsto
- Conocer qué Pods de tu clúster se comunican con Internet
- Comprender qué espacios de nombres se comunican entre sí
- Reconocer un ataque de denegación del servicio
Los registros de políticas de red se suben a Cloud Logging para el almacenamiento, la búsqueda, el análisis y las alertas si Cloud Logging está habilitado. En los clústeres nuevos, Cloud Logging está habilitado de forma predeterminada. Consulta Configura el registro y la supervisión para GKE a fin de obtener más información.
Requisitos
- El registro de políticas de red solo está disponible para clústeres que usan GKE Dataplane V2.
- El registro de políticas de red requiere Google Cloud CLI 303.0.0 de Google Cloud o una superior.
Precios
- La generación de registros no genera cargos para el registro de políticas de red.
- Si almacenas tus registros en Cloud Logging, se aplican los cargos estándar de Cloud Logging.
- Los registros se pueden enrutar luego a Pub/Sub, Cloud Storage o BigQuery. Es posible que se apliquen cargos de Pub/Sub, Cloud Storage o BigQuery. Para obtener más información, consulta Descripción general del enrutamiento y el almacenamiento.
Configura el registro de políticas de red
Para establecer la configuración del registro de las políticas de red, edita el objeto NetworkLogging en el clúster. De forma automática, GKE crea un objeto NetworkLogging llamado default en los clústeres nuevos de Dataplane V2. Solo puede haber un objeto NetworkLogging por clúster y no se puede cambiar de nombre.
Puedes configurar el registro de las conexiones permitidas y de las conexiones rechazadas por separado. También puedes habilitar el registro de forma selectiva para algunas políticas de red. A continuación, se muestra un ejemplo de la especificación de NetworkLogging, con la configuración especificada para registrar todas las conexiones permitidas y rechazadas:
kind: NetworkLogging
apiVersion: networking.gke.io/v1alpha1
metadata:
name: default
spec:
cluster:
allow:
log: true
delegate: false
deny:
log: true
delegate: false
Usa kubectl para editar la configuración:
kubectl edit networklogging default
Especificación de NetworkLogging
La especificación del objeto NetworkLogging está en formato YAML. Este formato se describe en la siguiente tabla:
| Campo | Tipo | Descripción | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
cluster.allow | struct |
Opciones de configuración para registrar conexiones permitidas.
|
|||||||||
cluster.deny |
struct |
Opciones de configuración para registrar conexiones rechazadas.
|
Accede a los registros de las políticas de red
Los registros de las políticas de red se suben de forma automática a Cloud Logging. Puedes acceder a los registros a través del Explorador de registros o con Google Cloud CLI. También puedes enrutar registros a un receptor.
Cloud Logging
Ve al Explorador de registros en la consola de Google Cloud.
Haz clic en Compilador de consultas.
Usa la siguiente consulta para encontrar todos los registros de las políticas de red:
resource.type="k8s_node" resource.labels.location="CLUSTER_LOCATION" resource.labels.cluster_name="CLUSTER_NAME" logName="projects/PROJECT_NAME/logs/policy-action"Reemplaza lo siguiente:
CLUSTER_LOCATION: La ubicación de Compute Engine del clúster.CLUSTER_NAME: Es el nombre del clúster.PROJECT_NAME: Es el nombre de tu proyecto de Google Cloud.
Consulta Usa el Explorador de registros para obtener información sobre cómo usar el Explorador de registros.
También puedes compilar una consulta con el Compilador de consultas. A fin de crear una consulta para los registros de políticas de red, selecciona policy-action en la lista desplegable Nombre del registro. Si no hay registros disponibles, policy-action no aparece en la lista desplegable.
gcloud
Busca todos los registros de las políticas de red:
gcloud logging read --project "PROJECT_NAME" 'resource.type="k8s_node"
resource.labels.location="CLUSTER_LOCATION"
resource.labels.cluster_name="CLUSTER_NAME"
logName="projects/PROJECT_NAME/logs/policy-action"'
Reemplaza lo siguiente:
PROJECT_NAME: Es el nombre de tu proyecto de Google Cloud.CLUSTER_LOCATION: La ubicación de Compute Engine del clúster.CLUSTER_NAME: Es el nombre del clúster.
Puedes agregar más condiciones para filtrar los resultados. Por ejemplo:
Mostrar registros en un período determinado:
timestamp>="2020-06-22T06:30:51.128Z" timestamp<="2020-06-23T06:30:51.128Z"Mostrar los registros de las conexiones rechazadas:
jsonPayload.disposition="deny"Mostrar los registros de una implementación llamada “redis”:
jsonPayload.dest.pod_name=~"redis" jsonPayload.dest.pod_namespace="default"Mostrar los registros de las conexiones externas del clúster:
jsonPayload.dest.instance != ""Mostrar los registros que coinciden con una política de red determinada, en este caso “allow-frontend-to-db”:
jsonPayload.policies.name="allow-frontend-to-db" jsonPayload.policies.namespace="default"
Si usas un clúster estándar, también puedes encontrar los registros de política de red generados en cada nodo del clúster de forma local en /var/log/network/policy_action.log*. Se crea un archivo de registro numerado nuevo cuando el archivo de registro actual alcanza los 10 MB. Se almacenan hasta cinco archivos de registro anteriores.
Formato de registro de políticas de red
Los registros de las políticas de red están en formato JSON. Este formato se describe en la siguiente tabla:
| Campo | Tipo | Descripción | |||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
connection | struct |
Información de la conexión:
|
|||||||||||||||||||||
src | struct |
Información del extremo del origen:
|
|||||||||||||||||||||
dest | struct |
Información del extremo del destino:
|
|||||||||||||||||||||
disposition | string | Disposición de la conexión, que puede ser allow o deny. | |||||||||||||||||||||
policies | list of structs |
Políticas coincidentes para las conexiones permitidas desde la vista del Pod aplicado. En la conexión de entrada, el Pod aplicado es el Pod de destino. En la conexión de salida, el Pod aplicado es el Pod de origen. Se registran varias políticas si una conexión coincide con todas ellas. Este campo se incluye solamente en los registros de las conexiones permitidas.
|
|||||||||||||||||||||
count | int | Se usa para la agregación de registros de las consultas rechazadas. El valor es siempre 1 para la conexión permitida. | |||||||||||||||||||||
node_name | string | El nodo que ejecuta el Pod que generó este mensaje de registro. | |||||||||||||||||||||
timestamp | string | Cuándo ocurrió el intento de conexión. |
Definición de conexión
En el caso de los protocolos orientados a la conexión, como TCP, se crea un registro por cada conexión permitida o rechazada. Para los protocolos como UDP y ICMP que no están orientados a la conexión, los paquetes se agrupan en conexiones basadas en ventanas de tiempo.
Registros de políticas para conexiones rechazadas
Los registros de conexión de las conexiones rechazadas no incluyen el campo policies, ya que la API de políticas de red de Kubernetes no tiene políticas de rechazo explícitas.
Se rechaza una conexión si un Pod está cubierto por una o más políticas de red, pero ninguna de las políticas permite la conexión. Esto significa que ninguna política es responsable de manera individual de una conexión bloqueada.
Agregación de registros para las conexiones rechazadas
Es común que un cliente vuelva a intentar una conexión que se rechazó. Para evitar el registro excesivo, las conexiones rechazadas repetidas en una ventana de cinco segundos se agregan en un solo mensaje de registro mediante el campo count.
Las conexiones rechazadas posteriores se agregan con un mensaje de registro anterior si los src_ip, dest_ip, dest_port, protocol, y la direction de la conexión coinciden con la primera conexión rechazada. Ten en cuenta que el src_port de las conexiones posteriores no tiene que coincidir, ya que las conexiones que se reintentaron pueden provenir de un puerto diferente.
El mensaje de registro agregado incluye el src_prt de la primera conexión rechazada al comienzo de la ventana de agregación.
Registros de ejemplo
La siguiente política de red de ejemplo llamada allow-green aplicada a test-service permite conexiones a test-service desde un Pod llamado client-green. De manera implícita, esta política rechaza todo el tráfico de entrada a test-service, incluido desde el client-red del Pod.
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-green
namespace: default
annotations:
policy.network.gke.io/enable-logging: "true"
spec:
podSelector:
matchLabels:
app: test-service
ingress:
- from:
- podSelector:
matchLabels:
app: client-green
policyTypes:
- Ingress
En este diagrama, se muestra el efecto de la política allow-green en dos conexiones a test-service. La política allow-green permite la conexión desde client-green. Debido a que ninguna política permite la conexión desde client-red, se rechaza la conexión.
El registro para la conexión permitida desde client-green se ve de la siguiente manera:
{
"connection":{
"src_ip":"10.84.0.252",
"dest_ip":"10.84.0.165",
"src_port":52648,
"dest_port":8080,
"protocol":"tcp",
"direction":"ingress"
},
"disposition":"allow",
"policies":[
{
"name":"allow-green",
"namespace":"default"
}
],
"src":{
"pod_name":"client-green-7b78d7c957-68mv4",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"client-green-7b78d7c957",
"workload_kind":"ReplicaSet"
},
"dest":{
"pod_name":"test-service-745c798fc9-sfd9h",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"test-service-745c798fc9",
"workload_kind":"ReplicaSet"
},
"count":1,
"node_name":"gke-demo-default-pool-5dad52ed-k0h1",
"timestamp":"2020-06-16T03:10:37.993712906Z"
}
El registro para la conexión rechazada desde client-red se ve de la siguiente manera:
{
"connection":{
"src_ip":"10.84.0.180",
"dest_ip":"10.84.0.165",
"src_port":39610,
"dest_port":8080,
"protocol":"tcp",
"direction":"ingress"
},
"disposition":"deny",
"src":{
"pod_name":"client-red-5689846f5b-b5ccx",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"client-red-5689846f5b",
"workload_kind":"ReplicaSet"
},
"dest":{
"pod_name":"test-service-745c798fc9-sfd9h",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"test-service-745c798fc9",
"workload_kind":"ReplicaSet"
},
"count":3,
"node_name":"gke-demo-default-pool-5dad52ed-k0h1",
"timestamp":"2020-06-15T22:38:32.189649531Z"
}
Ten en cuenta que no se incluye el campo policies en el registro de la conexión rechazada. Esto
se describe en la sección anterior,
Registros de políticas para conexiones rechazadas.
El registro de la conexión rechazada incluye un campo count para
agregar conexiones rechazadas.
Soluciona problemas de registros de políticas de red
Verifica los eventos de errores en el objeto
NetworkLogging:kubectl describe networklogging defaultSi la configuración de registros no es válida, no se aplicará y se informará un error en la sección de eventos:
Name: default Namespace: Labels: addonmanager.kubernetes.io/mode=EnsureExists Annotations: API Version: networking.gke.io/v1alpha1 Kind: NetworkLogging Metadata: Creation Timestamp: 2020-06-20T05:54:08Z Generation: 8 Resource Version: 187864 Self Link: /apis/networking.gke.io/v1alpha1/networkloggings/default UID: 0f1ddd6e-4193-4295-9172-baa6a52aa6e6 Spec: Cluster: Allow: Delegate: true Log: false Deny: Delegate: false Log: false Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning InvalidNetworkLogging 16s (x3 over 11h) network-logging-controller, gke-anthos-default-pool-cee49209-0t09 cluster allow log action is invalid: delegate cannot be true when log is false Warning InvalidNetworkLogging 16s (x3 over 11h) network-logging-controller, gke-anthos-default-pool-cee49209-80fx cluster allow log action is invalid: delegate cannot be true when log is falsePara limitar el uso de CPU empleado a la hora de registrar el nodo, un nodo puede registrar hasta 500 conexiones por segundo antes de comenzar a descartar registros. Las políticas de red en el nodo se siguen aplicando. Para ver si hay registros de políticas descartados, verifica si los contadores de errores aumentan:
kubectl exec ANETD_POD_NAME -n kube-system -- curl -s http://localhost:9990/metrics |grep policy_loggingReemplaza
ANETD_POD_NAMEpor el nombre de un Pod anetd. Verifica cada nodo. El anetd es el controlador de herramientas de redes para Dataplane V2.
Registros sin nombre aparecen para los pods con políticas de denegación predeterminadas
Los sondeos de capacidad de funcionamiento, preparación e inicio requieren que el Pod acepte las conexiones de Ingress realizadas por los sondeos de kubelet. Para garantizar que estos sondeos funcionen de forma correcta, GKE permite el tráfico del sondeo al Pod seleccionado de forma automática como está configurado para el Pod, sin importar las políticas de red aplicadas al Pod. No puedes cambiar este comportamiento.
Los registros de las conexiones de sondeo son similares a los siguientes:
{
"connection":{
"src_ip":"10.88.1.1",
"dest_ip":"10.88.1.4",
"src_port":35848,
"dest_port":15021,
"protocol":"tcp",
"direction":"ingress"
},
"disposition":"allow",
"src":{
"instance":"10.88.1.1"
},
"dest":{
"pod_name":"testpod-745c798fc9-sfd9h",
"pod_namespace":"default",
"namespace":"default",
"workload_name":"testpod-745c798fc9",
"workload_kind":"ReplicaSet"
},
"count":1,
"policies": [
{
"name":""
}
],
"node_name":"gke-demo-default-pool-5dad52ed-k0h1",
"timestamp":"2021-04-01T12:42:32.1898720941Z"
}
El registro tiene las siguientes características:
- El valor de
policies.nameestá vacío porque no hay ninguna política de red asociada para permitir la conexión. - El valor de
connection.src_ipno corresponde a ningún Pod ni nodo.
¿Qué sigue?
- Aprende a ver y analizar registros con Cloud Logging.
- Implementa enfoques comunes para restringir el tráfico mediante políticas de red.
- Obtén información sobre cómo ver la conectividad de la carga de trabajo con GKE Dataplane V2.