Skip to main content

Troubleshooting de Red

Plugins de CNI​

Varios plugins pueden ser utilizados para crear la red entre los nodos. En el examen la URL será dada en caso necesario. Para más documentación https://kubernetes.io/docs/concepts/cluster-administration/addons/#networking-and-network-policy

  1. Weave Net: kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s.yaml

  2. Flannel : kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/2140ac876ef134e0ed5af15c65e414cf26827915/Documentation/kube-flannel.yml 2.1. No soporta network policies.

  3. Calico : curl https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml -O; kubectl apply -f calico.yaml

Si existen varios archivos de configuración de CNI, el kubelet usará el primero en orden alfabético.

DNS in Kubernetes​

Como servidor DNS Kubernetes utiliza CoreDNS que es muy flexible y extensible.

Memory and Pods

El uso de memoria usado por CoreDNS es afectado por el número de pods y services en el cluster, pero solo visible en clusters de gran escala. El tamaño del cache y la tasa de consultas influyen en la utilización de la memoria también.

Los recursos del CoreDNS son:

Kubernetes resources for coreDNS are:

  • service account: coredns
  • cluster-roles: coredns e kube-dns
  • clusterrolebindings coredns e kube-dns
  • deployment: coredns
  • configmap: coredns
  • service: kube-dns

Analizando el deployment del coreDNS, un configmap es utilizado para las configuraciones.

    spec:
      volumes:
        - name: config-volume
          configMap:
            name: coredns #<<<<
            items:
              - key: Corefile
                path: Corefile
            defaultMode: 420

Aquí el contenido del configmap.

kubectl describe cm -n kube-system coredns
Name:         coredns
Namespace:    kube-system
Labels:       <none>
Annotations:  <none>

Data
====
Corefile:
----
### Puerto 53 es usado para la resolución de DNS.
.:53 {
    errors
    health {
       lameduck 5s
    }
    ready
    # Este es el back-end del k8s para cluster.local y dominios reversos.
    kubernetes cluster.local in-addr.arpa ip6.arpa {
       pods insecure
       fallthrough in-addr.arpa ip6.arpa
       ttl 30
    }
    prometheus :9153
    # Reenviar dominios de cluster directamente al servidor DNS autoritativo correcto.
    forward . /etc/resolv.conf {
       max_concurrent 1000
    }
    cache 30
    loop
    reload
    loadbalance
}


BinaryData
====

Events:  <none>

https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/

Solución de problemas relacionados con coreDNS.

  1. Si CoreDNS está en estado pending, verifique si algún plugin CNI está instalado.

  2. Si los pods de CoreDNS están en estado CrashLoopBackOff o Error. Si está utilizando nodos que están ejecutando SELinux con una versión antigua de Docker puede ser que CoreDNS no inicie. Para resolver ese problema puede intentar seguir los pasos abajo.

    2.1. Actualizar la versión del container runtime.

    2.2. Desactivar SELinux en el sistema operativo.

    2.3. Modificar el deployment de CoreDNS y configurar allowPrivilegeEscalation como true.

    kubectl -n kube-system get deployment coredns -o yaml | sed 's/allowPrivilegeEscalation: false/allowPrivilegeEscalation: true/g' | kubectl apply -f -

    2.4. Otra causa para que CoreDNS tenga CrashLoopBackOff es cuando un Pod CoreDNS desplegado en Kubernetes detecta un loop. Hay muchas maneras de solucionar ese problema, algunas están listadas aquí:

    • Agregue lo siguiente al yaml de configuración del kubelet: resolvConf: <path-to-your-real-resolv-conf-file> Este flag dice al kubelet que pase un resolv.conf alternativo a los pods. Para sistemas que usan systemd-resolved, /run/systemd/resolve/resolv.conf es normalmente la ubicación del resolv.conf "real", aunque puede ser diferente dependiendo de su distribución.
    • Desactive el cache DNS local en los nodos del host y restaure /etc/resolv.conf al original.
    • Una solución rápida es editar su Corefile, reemplazando forward . /etc/resolv.conf por la dirección IP de su DNS upstream, por ejemplo forward . 8.8.8.8. Pero esto solo corrige el problema de CoreDNS, el kubelet continuará reenviando el resolv.conf inválido a todos los pods dnsPolicy por defecto, dejándolos incapaces de resolver el DNS.

  3. Si los pods CoreDNS y el servicio kube-dns están funcionando bien, verifique si el servicio kube-dns tiene endpoints válidos. kubectl -n kube-system get ep kube-dns Si no hay endpoints para el service, inspecciónelo y asegúrese de que utiliza los selectores y puertos correctos.

Kube-Proxy​

kube-proxy es un proxy de red ejecutado en cada nodo del cluster. kube-proxy mantiene reglas de red en nodos. Estas reglas de red permiten la comunicación de red con los pods a partir de sesiones de red dentro o fuera del cluster.

Si el cluster fue configurado con kubeadm, kube-proxy estará ejecutándose como un daemonset.

kube-proxy es responsable de monitorear los services y endpoints asociados a cada service. Cuando el cliente va a conectarse al service usando la IP virtual, kube-proxy es responsable de enviar el tráfico a los pods reales.

Si ejecuta un kubectl description ds -n kube-system kube-proxy podrá ver que el binario kube-proxy es ejecutado con el siguiente comando dentro del contenedor kube-proxy.

kubectl describe ds -n kube-system kube-proxy
Name:           kube-proxy
Selector:       k8s-app=kube-proxy
Node-Selector:  kubernetes.io/os=linux
Labels:         k8s-app=kube-proxy
Annotations:    deprecated.daemonset.template.generation: 1
Desired Number of Nodes Scheduled: 4
Current Number of Nodes Scheduled: 4
Number of Nodes Scheduled with Up-to-date Pods: 4
Number of Nodes Scheduled with Available Pods: 4
Number of Nodes Misscheduled: 0
Pods Status:  4 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:
  Labels:           k8s-app=kube-proxy
  Service Account:  kube-proxy
  Containers:
   kube-proxy:
    Image:      registry.k8s.io/kube-proxy:v1.29.1
    Port:       <none>
    Host Port:  <none>
####################
    Command:
      /usr/local/bin/kube-proxy
      --config=/var/lib/kube-proxy/config.conf
      --hostname-override=$(NODE_NAME)
####################
    Environment:
      NODE_NAME:   (v1:spec.nodeName)
    Mounts:
      /lib/modules from lib-modules (ro)
      /run/xtables.lock from xtables-lock (rw)
      /var/lib/kube-proxy from kube-proxy (rw)
  Volumes:
   kube-proxy:
    Type:      ConfigMap (a volume populated by a ConfigMap)
    Name:      kube-proxy
    Optional:  false
   xtables-lock:
    Type:          HostPath (bare host directory volume)
    Path:          /run/xtables.lock
    HostPathType:  FileOrCreate
   lib-modules:
    Type:               HostPath (bare host directory volume)
    Path:               /lib/modules
    HostPathType:
  Priority Class Name:  system-node-critical
Events:                 <none>

Por lo tanto, busca la configuración de un archivo /var/lib/kube-proxy/config.conf y podemos sobrescribir el nombre del host por el nombre del nodo en el cual el pod está siendo ejecutado.

En el archivo de configuración definimos clusterCIDR, modo kubeproxy, ipvs, iptables, bindaddress, kube-config etc.

Como resolver problemas relacionados con kube-proxy:

  1. Verifique si el pod kube-proxy en el namespace kube-system está en ejecución.

  2. Verifique los logs del proxy kube.

  3. Verifique si el configmap está definido correctamente y si el archivo de configuración para ejecutar el binario kube-proxy está correcto.

  4. kube-config está definido en el configmap.

  5. verifique si kube-proxy está siendo ejecutado dentro del contenedor.

# netstat -plan | grep kube-proxy
tcp        0      0 0.0.0.0:30081           0.0.0.0:*               LISTEN      1/kube-proxy
tcp        0      0 127.0.0.1:10249         0.0.0.0:*               LISTEN      1/kube-proxy
tcp        0      0 172.17.0.12:33706       172.17.0.12:6443        ESTABLISHED 1/kube-proxy
tcp6       0      0 :::10256                :::*                    LISTEN      1/kube-proxy