La sonda de actividad HTTP de Kubernetes falla con “conexión rechazada” a pesar de que la URL funciona sin ella

Preguntas WordPress
⏰ 6 minutos de lectura

AMBIENTE:

Kubernetes version: v1.16.3  
OS: CentOS 7  
Kernel: Linux k8s02-master01 3.10.0-1062.4.3.el7.x86_64 #1 SMP Wed Nov 13 23:58:53 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

QUÉ PASÓ:

Tengo una implementación de WordPress que ejecuta un contenedor creado a partir de una imagen personalizada de Apache/Wordpress. La imagen expone el puerto 8080 en lugar de 80 (Archivo acoplable a continuación). El Pod está expuesto al mundo a través del proxy inverso Traefik. Todo funciona bien sin controles de disponibilidad o vitalidad. Pod se prepara y se puede acceder a WordPress desde https://www.ejemplo.com/.

Intenté agregar sondas de actividad y preparación y ambas fallan repetidamente con “conexión rechazada”. Cuando elimino ambas sondas y vuelvo a aplicar la implementación, vuelve a funcionar. Funciona hasta que la sonda alcanza el umbral de falla, momento en el que el contenedor entra en un ciclo de reinicio sin fin y se vuelve inaccesible.

EVENTOS DE POD:

Events:
  Type     Reason     Age                   From                        Message
  ----     ------     ----                  ----                        -------
  Normal   Scheduled  <unknown>             default-scheduler           Successfully assigned development/blog-wordpress-5dbcd9c7c7-kdgpc to gg-k8s02-worker02
  Normal   Killing    16m (x2 over 17m)     kubelet, gg-k8s02-worker02  Container blog-wordpress failed liveness probe, will be restarted
  Normal   Created    16m (x3 over 18m)     kubelet, gg-k8s02-worker02  Created container blog-wordpress
  Normal   Started    16m (x3 over 18m)     kubelet, gg-k8s02-worker02  Started container blog-wordpress
  Normal   Pulled     13m (x5 over 18m)     kubelet, gg-k8s02-worker02  Container image "wordpress-test:test12" already present on machine
  Warning  Unhealthy  8m17s (x35 over 18m)  kubelet, gg-k8s02-worker02  Liveness probe failed: Get http://10.244.3.83/: dial tcp 10.244.3.83:80: connect: connection refused
  Warning  BackOff    3m27s (x27 over 11m)  kubelet, gg-k8s02-worker02  Back-off restarting failed container

REGISTROS DE POD:

WordPress not found in /var/www/html - copying now...
WARNING: /var/www/html is not empty! (copying anyhow)
Complete! WordPress has been successfully copied to /var/www/html
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.3.83. Set the 'ServerName' directive globally to suppress this message
AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 10.244.3.83. Set the 'ServerName' directive globally to suppress this message
[Wed Dec 11 06:39:07.502247 2019] [mpm_prefork:notice] [pid 1] AH00163: Apache/2.4.38 (Debian) PHP/7.3.11 configured -- resuming normal operations
[Wed Dec 11 06:39:07.502323 2019] [core:notice] [pid 1] AH00094: Command line: 'apache2 -D FOREGROUND'
10.244.3.1 - - [11/Dec/2019:06:39:18 +0000] "GET /index.php HTTP/1.1" 301 264 "-" "kube-probe/1.16"
10.244.3.1 - - [11/Dec/2019:06:39:33 +0000] "GET /index.php HTTP/1.1" 301 264 "-" "kube-probe/1.16"
10.244.3.1 - - [11/Dec/2019:06:39:48 +0000] "GET /index.php HTTP/1.1" 301 264 "-" "kube-probe/1.16"
10.244.3.1 - - [11/Dec/2019:06:40:03 +0000] "GET /index.php HTTP/1.1" 301 264 "-" "kube-probe/1.16"
10.244.3.1 - - [11/Dec/2019:06:40:18 +0000] "GET /index.php HTTP/1.1" 301 264 "-" "kube-probe/1.16"

DOCKERFILE (“wordpress-prueba: prueba12”):

FROM wordpress:5.2.4-apache

RUN sed -i 's/Listen 80/Listen 8080/g' /etc/apache2/ports.conf;
RUN sed -i 's/:80/:8080/g' /etc/apache2/sites-enabled/000-default.conf;
# RUN sed -i 's/#ServerName www.example.com/ServerName localhost/g' /etc/apache2/sites-enabled/000-default.conf;

EXPOSE 8080

CMD ["apache2-foreground"]

DESPLIEGUE:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: blog-wordpress
  namespace: development
  labels:
    app: blog

spec:
  selector:
    matchLabels:
      app: blog
      tier: wordpress
  replicas: 4
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  template:
    metadata:
      labels:
        app: blog
        tier: wordpress
    spec:
      volumes:
        - name: blog-wordpress
          persistentVolumeClaim:
            claimName: blog-wordpress
      containers:
        - name: blog-wordpress
          # image: wordpress:5.2.4-apache
          image: wordpress-test:test12
          securityContext:
            runAsUser: 65534
            allowPrivilegeEscalation: false
            capabilities:
              add:
                - "NET_ADMIN"
                - "NET_BIND_SERVICE"
                - "SYS_TIME"
          resources:
            requests:
              cpu: "250m"
              memory: "64Mi"
            limits:
              cpu: "500m"
              memory: "128Mi"
          ports:
            - name: liveness-port
              containerPort: 8080
          readinessProbe:
            initialDelaySeconds: 15
            httpGet:
              path: /index.php
              port: 8080
            timeoutSeconds: 15
            periodSeconds: 15
            failureThreshold: 5
          livenessProbe:
            initialDelaySeconds: 10
            httpGet:
              path: /index.php
              port: 8080
            timeoutSeconds: 10
            periodSeconds: 15
            failureThreshold: 5
          env:
            # Database
            - name: WORDPRESS_DB_HOST
              value: blog-mysql
            - name: WORDPRESS_DB_NAME
              value: wordpress
            - name: WORDPRESS_DB_USER
              valueFrom:
                secretKeyRef:
                  name: blog-mysql
                  key: username
            - name: WORDPRESS_DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: blog-mysql
                  key: password
            - name: WORDPRESS_TABLE_PREFIX
              value: wp_
            - name: WORDPRESS_AUTH_KEY
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: auth-key
            - name: WORDPRESS_SECURE_AUTH_KEY
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: secure-auth-key
            - name: WORDPRESS_LOGGED_IN_KEY
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: logged-in-key
            - name: WORDPRESS_NONCE_KEY
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: nonce-key
            - name: WORDPRESS_AUTH_SALT
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: auth-salt
            - name: WORDPRESS_SECURE_AUTH_SALT
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: secure-auth-salt
            - name: WORDPRESS_LOGGED_IN_SALT
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: logged-in-salt
            - name: WORDPRESS_NONCE_SALT
              valueFrom:
                secretKeyRef:
                  name: blog-wordpress
                  key: nonce-salt
            - name: WORDPRESS_CONFIG_EXTRA
              value: |
                define('WPLANG', 'fr_FR');
                define('WP_CACHE', false);
                define('WP_MEMORY_LIMIT', '64M');
          volumeMounts:
            - name: blog-wordpress
              mountPath: "/var/www/html/wp-content"

SERVICIO DE DESPLIEGUE:

apiVersion: v1
kind: Service
metadata:
  name: blog-wordpress
  namespace: development
  labels:
    app: blog

spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  selector:
    app: blog
    tier: wordpress
  type: ClusterIP

RUTA DE INGRESO DE TRAEFIK:

##
# HTTP
##

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: blog
  namespace: development
spec:
  entryPoints:
    - http
  routes:
  - match: Host(`example.com`)
    kind: Rule
    services:
    - name: blog-wordpress
      port: 80
    middlewares:
      - name: redirect-to-https
        namespace: kube-system

---

##
# HTTPS
##

apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
  name: blog-https
  namespace: development
spec:
  entryPoints:
    - https
  routes:
  - match: Host(`example.com`) && PathPrefix(`/`)
    kind: Rule
    services:
    - name: blog-wordpress
      port: 80

  tls:
    certResolver: letsencrypt

¡Gracias!

  • De tu Pod caso de que pueda ver que la sonda se está comprobando en el puerto 80 (dial tcp 10.244.3.83:80: connect: connection refused) mientras está en implementación, muestra 8080. ¿Puedes verificar eso?

    – acid_fuji

    11 de diciembre de 2019 a las 14:25

Para cualquier persona interesada, he logrado resolver este problema.

Recibí una respuesta de redireccionamiento 301 de WordPress debido a que WordPress forzó mi nombre de dominio ejemplo.com. Se resolvió este problema al deshabilitar la función de redirección canónica de WordPress para la solicitud específica http://POD_IP:8080/index.php.

Así es cómo:

Se agregó la dirección IP del pod como una variable de entorno:

- name: K8S_POD_IP
  valueFrom:
    fieldRef:
      fieldPath: status.podIP

Creó un complemento de WordPress con un personalizado redirigir_canonical filtro que evita que WordPress redirija http://POD_IP:8080/index.php:

<?php
/**
 * Plugin Name: Kubernetes Liveness Probe Exception
 */

add_filter('redirect_canonical', function($redirect_url, $requested_url) {
    $K8S_POD_IP = getenv('K8S_POD_IP');
    $LIVENESS_URL = "http://" . $K8S_POD_IP . ":8080/index.php";

    if ($requested_url == $LIVENESS_URL) {
        return $requested_url;
    }

    return $redirect_url;
}, 10, 2);

Avatar de usuario de Luke
Lucas

Solo para dar otra forma: wordpress intentará redirigir porque le faltan los encabezados http X-Forwarded que debería tener si se conecta a wordpress a través de un proxy.

Algo como esto funciona sin necesidad de php personalizado:

    livenessProbe:
      initialDelaySeconds: 10
      httpGet:
        path: /
        port: 8080
        httpHeaders:
        - name: X-Forwarded-Proto
          value: https
        - name: X-Forwarded-Host
          value: www.your-wordpress-domain-here.com
        - name: Host
          value: www.your-wordpress-domain-here.com
        timeoutSeconds: 10
        periodSeconds: 15
        failureThreshold: 5

  • ¡Trabajado como un encanto! Esta debería ser realmente la respuesta aceptada en mi opinión.

    – Michael Mayo

    12 de enero de 2022 a las 20:10 

10.244.3.1 - - [11/Dec/2019:06:39:18 +0000] "GET /index.php HTTP/1.1" 301 264 "-" "kube-probe/1.16"

Está recibiendo una respuesta de redireccionamiento 301 de Apache. Necesita obtener un 2xx para ser considerado un éxito.

Para comprobar qué ruta te está redirigiendo para probar curl --location --verbose http://url/index.php

Si no puede encontrar una forma de evitar la redirección de Apache o WordPress, podría considerar una sonda tcpSocket en lugar de httpGet

  • ¡Gracias! Curl devolvió el siguiente encabezado: X-Redirect-By: WordPress. WordPress redirige la solicitud de sondeo.

    – iamcryptoki

    11 de diciembre de 2019 a las 10:18

  • ¿La sonda tcpSocket es relevante para una implementación de WordPress? @hipyhop

    – iamcryptoki

    11 dic 2019 a las 11:30

Creo que WP te redirige a una URL “limpia” de /. Eliminar la parte index.php

¿Ha sido útil esta solución?