servicio de kubernetes ip externa pendiente

Estoy tratando de implementar nginx en kubernetes, la versión de kubernetes es v1.5.2, he implementado nginx con 3 réplicas, el archivo YAML está debajo,

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: deployment-example
spec:
  replicas: 3
  revisionHistoryLimit: 2
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.10
        ports:
        - containerPort: 80

y ahora quiero exponer su puerto 80 en el puerto 30062 del nodo, para eso creé un servicio a continuación,

kind: Service
apiVersion: v1
metadata:
  name: nginx-ils-service
spec:
  ports:
    - name: http
      port: 80
      nodePort: 30062
  selector:
    app: nginx
  type: LoadBalancer

este servicio funciona bien como debería, pero se muestra como pendiente no solo en el panel de control de kubernetes sino también en la terminal.

así que ayúdame a resolver este problema. Gracias ...

Parece que está utilizando una costumbre Kubernetes clúster (utilizando minikube, kubeadmo similar). En este caso, no hay LoadBalancer integrado (a diferencia de AWS o Google Cloud). Con esta configuración predeterminada, solo puede usar NodePorto un controlador de entrada.

Con el controlador de ingreso puede configurar un nombre de dominio que se asigna a su pod; no es necesario que le dé el LoadBalancertipo a su servicio si usa un controlador de ingreso.

Si está utilizando Minikube, ¡hay un comando mágico!

$ minikube tunnel

Esperemos que alguien pueda ahorrar unos minutos con esto.

Enlace de referencia https://minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel

Si no está utilizando GCE o EKS (que utilizó kubeadm), puede agregar una externalIPsespecificación a su servicio YAML. Puede usar la IP asociada con la interfaz principal de su nodo, como eth0. Luego puede acceder al servicio externamente, utilizando la IP externa del nodo.

...
spec:
  type: LoadBalancer
  externalIPs:
  - 192.168.0.10

Para acceder a un servicio minikube, debe ejecutar el siguiente comando:

minikube service [-n NAMESPACE] [--url] NAME

Más información aquí: Minikube GitHub

Creé un clúster de nodo único k8s usando kubeadm. Cuando probé PortForward y el proxy kubectl , mostró IP externa como pendiente.

$ kubectl get svc -n argocd argocd-server
NAME            TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
argocd-server   LoadBalancer   10.107.37.153   <pending>     80:30047/TCP,443:31307/TCP   110s

En mi caso, parcheé el servicio así:

kubectl patch svc <svc-name> -n <namespace> -p '{"spec": {"type": "LoadBalancer", "externalIPs":["172.31.71.218"]}}'

Después de esto, comenzó a servir sobre la IP pública

$ kubectl get svc argo-ui -n argo
NAME      TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)        AGE
argo-ui   LoadBalancer   10.103.219.8   172.31.71.218   80:30981/TCP   7m50s

Si se ejecuta en minikube , no olvide mencionar el espacio de nombres si no está utilizando el predeterminado.

servicio minikube << service_name >> --url --namespace = << namespace_name >>

Si está utilizando minikube, ejecute los siguientes comandos desde la terminal,

$ minikube ip
$ 172.17.0.2 // then 
$ curl http://172.17.0.2:31245
or simply
$ curl http://$(minikube ip):31245

mismo problema:

os> kubectl get svc right-sabertooth-wordpress

NOMBRE TIPO CLUSTER-IP EXTERNAL-IP PUERTO (S)
right-sabertooth-wordpress LoadBalancer 10.97.130.7 "pendiente" 80: 30454 / TCP, 443: 30427 / TCP

os> lista de servicio de minikube

| ------------- | ---------------------------- | ------ -------------------------- |

El | NAMESPACE | NOMBRE | URL |

| ------------- | ---------------------------- | ------ -------------------------- |

El | por defecto | kubernetes | Sin puerto de nodo |

El | por defecto | right-sabertooth-mariadb | Sin puerto de nodo |

El | por defecto | right-sabertooth-wordpress | http://192.168.99.100:30454 |

El | El | El | http://192.168.99.100:30427 |

El | sistema kube | kube-dns | Sin puerto de nodo |

El | sistema kube | despliegue del timón | Sin puerto de nodo |

| ------------- | ---------------------------- | ------ -------------------------- |

Sin embargo, es accesible a través de esa http://192.168.99.100:30454 .

Siguiendo la respuesta de @ Javier. He decidido ir a "parchar la IP externa" para mi equilibrador de carga.

 $ kubectl patch service my-loadbalancer-service-name \
-n lb-service-namespace \
-p '{"spec": {"type": "LoadBalancer", "externalIPs":["192.168.39.25"]}}'

Esto reemplazará ese 'pendiente' con una nueva dirección IP parcheada que puede usar para su clúster.

Para más sobre esto. Consulte la publicación de karthik sobre el soporte de LoadBalancer con Minikube para Kubernetes

No es la forma más limpia de hacerlo. Necesitaba una solución temporal. Espero que esto ayude a alguien.

Use NodePort:

kubectl ejecutar inicio de sesión de usuario --replicas = 2 --labels = "ejecutar = inicio de sesión de usuario" --imagen = kingslayerr / teamproject: versión2 --port = 5000

kubectl expone la implementación de inicio de sesión de usuario --type = NodePort --name = user-login-service

kubectl describe los servicios user-login-service (anote el puerto)

kubect cluster-info (IP-> Obtener la IP donde se ejecuta el maestro)

Se puede acceder a su servicio en (IP) :( puerto)

Al usar Minikube, puede obtener la IP y el puerto a través del cual puede acceder al servicio ejecutando el servicio de minikube kubia-http.

Si no está en una nube compatible (aws, azure, gcloud, etc.), no puede usar LoadBalancer sin MetalLB https://metallb.universe.tf/ pero todavía está en beta.

LoadBalancer ServiceType solo funcionará si la infraestructura subyacente admite la creación automática de Load Balancers y tiene el soporte respectivo en Kubernetes, como es el caso de Google Cloud Platform y AWS. Si no se configura dicha función, el campo de dirección IP de LoadBalancer no se rellena y aún está en estado pendiente, y el Servicio funcionará de la misma manera que un Servicio de tipo NodePort

Puede parchear la IP del nodo donde se alojan los pods (IP privada del nodo), esta es la solución fácil.

Tomando referencia con las publicaciones anteriores, siguiente funcionó para mí:

servicio de parche kubectl my-loadbalancer-service-name \ -n lb-service-namespace \ -p '{"spec": {"type": "LoadBalancer", "externalIPs": ["xxx.xxx.xxx.xxx Private IP del servidor físico - Nodo - donde se realiza la implementación "]}} '

eliminar el servicio existente y crear un mismo servicio nuevo resolvió mis problemas. Mi problema es que el equilibrio de carga que define Ip I se usa para que el punto final externo esté pendiente. Cuando cambié una nueva IP de equilibrio de carga, todavía no funcionaba. Finalmente, eliminar el servicio existente y crear uno nuevo resolvió mi problema.

Verifique los registros del controlador Kube. Pude resolver este problema estableciendo las etiquetas de clusterID en la instancia ec2 en la que implementé el clúster.

Si es su clúster privado de k8s, MetalLB sería mejor. Debajo están los pasos.

Paso 1: Instale MetalLB en su clúster

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
# On first install only
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"

Paso 2: configúrelo utilizando un mapa de configuración

apiVersion: v1
kind: ConfigMap
metadata:
  namespace: metallb-system
  name: config
data:
  config: |
    address-pools:
    - name: default
      protocol: layer2
      addresses:
      - 172.42.42.100-172.42.42.105 #Update this with your Nodes IP range 

Paso 3: cree su servicio para obtener una IP externa (aunque sería una IP privada).

ARY:

Antes de la instalación de MetalLB:

Después de la instalación de MetalLB:

Agregar una solución para aquellos que encontraron este error mientras se ejecutaban amazon-eks.

Primero de todo correr:

kubectl describe svc <service-name>

Y luego revise el eventscampo en la salida de ejemplo a continuación:

Name:                     some-service
Namespace:                default
Labels:                   <none>
Annotations:              kubectl.kubernetes.io/last-applied-configuration:
                            {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"some-service","namespace":"default"},"spec":{"ports":[{"port":80,...
Selector:                 app=some
Type:                     LoadBalancer
IP:                       10.100.91.19
Port:                     <unset>  80/TCP
TargetPort:               5000/TCP
NodePort:                 <unset>  31022/TCP
Endpoints:                <none>
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type     Reason                  Age        From                Message
  ----     ------                  ----       ----                -------
  Normal   EnsuringLoadBalancer    68s  service-controller  Ensuring load balancer
  Warning  SyncLoadBalancerFailed  67s  service-controller  Error syncing load balancer: failed to ensure load balancer: could not find any suitable subnets for creating the ELB

Revise el mensaje de error:

Failed to ensure load balancer: could not find any suitable subnets for creating the ELB

En mi caso, la razón por la que no se proporcionaron subredes adecuadas para crear el ELB fueron:

1: El clúster EKS se implementó en el grupo de subredes incorrecto: subredes internas en lugar de cara al público.
(*) De manera predeterminada, los servicios de tipo LoadBalancercrean equilibradores de carga de cara al público si no service.beta.kubernetes.io/aws-load-balancer-internal: "true"se proporcionó ninguna anotación).

2: Las subredes no se etiquetaron de acuerdo con los requisitos mencionados aquí .

Etiquetar VPC con:

Key: kubernetes.io/cluster/yourEKSClusterName
Value: shared

Etiquetado de subredes públicas con:

Key: kubernetes.io/role/elb
Value: 1