IP externe du service kubernetes en attente


142

J'essaye de déployer nginx sur kubernetes, la version de kubernetes est v1.5.2, j'ai déployé nginx avec 3 répliques, le fichier YAML est ci-dessous,

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

et maintenant je veux exposer son port 80 sur le port 30062 du nœud, pour cela j'ai créé un service ci-dessous,

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

ce service fonctionne bien comme il se doit, mais il apparaît comme en attente non seulement sur le tableau de bord de kubernetes également sur le terminal. Sortie de borneÉtat du tableau de bord

alors aidez-moi à résoudre ce problème. Merci ...

Réponses:


177

Il semble que vous utilisez un cluster personnalisée Kubernetes ( en utilisant minikube, kubeadmou similaire). Dans ce cas, il n'y a pas de LoadBalancer intégré (contrairement à AWS ou Google Cloud). Avec cette configuration par défaut, vous ne pouvez utiliser NodePortou qu'un contrôleur d'entrée.

Avec le contrôleur Ingress, vous pouvez configurer un nom de domaine qui correspond à votre pod; vous n'avez pas besoin de donner à votre service le LoadBalancertype si vous utilisez un contrôleur d'entrée.


Merci beaucoup @javier, c'est vraiment utile. J'ai résolu mon problème de doc ci-dessus.
Pankaj Jackson

9
Cela ne répond pas vraiment à la question? L'utilisateur utilise LoadBalancercomme type de service qui est un type de service valide. NodePortet ingressexiste-t-il d'autres façons de le faire mais pas vraiment de résoudre le problème, n'est-ce pas?
Raptor

2
Il s'agit d'un type de service valide mais il est utilisé sur une plateforme non compatible (au moins par défaut). Pour utiliser LoadBalancer, vous devez disposer d'une plate-forme capable de fournir des adresses IP externes aux pods, ce que font Google Cloud ou AWS.
Javier Salmeron

2
J'utilise kubeadm sur AWS. Puis-je encore LoadBalancer?
jiashenC

3
Si vous utilisez minikube, exécutez "minikube tunnel". Maintenant, vérifiez vos services, vous obtiendrez l'adresse IP publique. Voici la doc pour plus d'informations minikube.sigs.k8s.io/docs/tasks/loadbalancer
Ravi

73

Si vous utilisez Minikube, il existe une commande magique!

$ minikube tunnel

J'espère que quelqu'un pourra gagner quelques minutes avec ça.

Lien de référence https://minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel


J'ai essayé minikube tunnelet cela résout le pendingproblème, mais la nouvelle adresse IP externe ne fonctionne pas: j'obtiens une erreur de délai d'expiration ...
a.barbieri

@ a.barbieri assurez-vous que vous utilisez l'ip du tunnel au lieu de l'ip du minikube. "patcher ingress-nginx avec IP 10.106.102.98"
Peter Zhou

2
oui merci Peter. J'essaierai. Quoi qu'il en soit, en passant à Docker Desktop, j'ai pu résoudre ce problème avec le paramètre prêt à l'emploi qui fonctionne directement sur localhost.
a.barbieri

3
Excellente astuce pour gagner du temps pour la démonstration!
jgitter

49

Si vous n'utilisez pas GCE ou EKS (que vous avez utilisé kubeadm), vous pouvez ajouter une externalIPsspécification à votre service YAML. Vous pouvez utiliser l'adresse IP associée à l'interface principale de votre nœud, telle que eth0. Vous pouvez alors accéder au service en externe, en utilisant l'adresse IP externe du nœud.

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

2
Il doit y avoir une information manquante: «les externalIP ne sont pas gérés par Kubernetes et sont sous la responsabilité de l'administrateur du cluster». ( kubernetes.io/docs/concepts/services-networking/service ). Dois-je installer une sorte de "contrôleur"?
Daniel Alder

Je suis le tutoriel Kubernetes ( kubernetes.io/docs/tutorials/stateless-application/guestbook ) et cela a bien fonctionné avec kubeadm
Eduardo

Merci - brillant, a travaillé comme prévu. J'ai exposé le service aux nœuds IP du réseau eth qui est maintenant accessible en dehors du cluster
Vlad Gulin


21

J'ai créé un cluster k8s à nœud unique à l'aide de kubeadm. Quand j'ai essayé le proxy PortForward et kubectl , il a montré l'IP externe comme en attente.

$ 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

Dans mon cas, j'ai corrigé le service comme ceci:

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

Après cela, il a commencé à servir sur l'adresse IP publique

$ 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

11
Peut-être devriez-vous mentionner d'où vient "172.31.71.218"?
EuRBamarth

Enfin une réponse qui donne comment patcher. Merci d'avoir partagé.
Srikant

5

Si vous utilisez minikube , n'oubliez pas de mentionner l'espace de noms si vous n'utilisez pas default.

service minikube << nom_service >> --url --namespace = << nom_espace_noms >>


4

Si vous utilisez minikube, exécutez les commandes ci-dessous à partir du terminal,

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

2

même problème:

os> kubectl get svc right-sabertooth-wordpress

NOM TYPE CLUSTER-IP EXTERNAL-IP PORT (S)
right-sabertooth-wordpress LoadBalancer 10.97.130.7 "en attente" 80: 30454 / TCP, 443: 30427 / TCP

os> liste des services minikube

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

| NAMESPACE | NOM | URL |

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

| par défaut | kubernetes | Aucun port de nœud |

| par défaut | droit-sabertooth-mariadb | Aucun port de nœud |

| par défaut | wordpress à droite | http://192.168.99.100:30454 |

| | | http://192.168.99.100:30427 |

| kube-system | kube-dns | Aucun port de nœud |

| kube-system | tiller-deploy | Aucun port de nœud |

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

Il est cependant accessible via ce http://192.168.99.100:30454 .


2

Suite à la réponse de @ Javier. J'ai décidé de "patcher l'adresse IP externe" pour mon équilibreur de charge.

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

Cela remplacera cette adresse «en attente» par une nouvelle adresse IP corrigée que vous pouvez utiliser pour votre cluster.

Pour en savoir plus. Veuillez consulter l' article de karthik sur le support de LoadBalancer avec Minikube pour Kubernetes

Ce n'est pas la façon la plus propre de le faire. J'avais besoin d'une solution temporaire. J'espère que cela aide quelqu'un.


1

Utilisez NodePort:

kubectl run user-login --replicas = 2 --labels = "run = user-login" --image = kingslayerr / teamproject: version2 --port = 5000

kubectl expose le déploiement user-login --type = NodePort --name = user-login-service

kubectl décrire les services user-login-service (notez le port)

kubect cluster-info (IP-> Obtenir l'IP où le maître s'exécute)

Votre service est accessible sur (IP) :( port)


1

Lorsque vous utilisez Minikube, vous pouvez obtenir l'adresse IP et le port via lesquels vous pouvez accéder au service en exécutant le service minikube kubia-http.



1

Le LoadBalancer ServiceType ne fonctionnera que si l'infrastructure sous-jacente prend en charge la création automatique d'équilibreurs de charge et dispose du support correspondant dans Kubernetes, comme c'est le cas avec Google Cloud Platform et AWS. Si aucune fonctionnalité de ce type n'est configurée, le champ d'adresse IP LoadBalancer n'est pas rempli et toujours en attente, et le service fonctionnera de la même manière qu'un service de type NodePort


1

Vous pouvez patcher l'adresse IP du nœud où les pods sont hébergés (IP privée du nœud), c'est la solution de contournement simple.

Prenant référence aux articles ci-dessus, la suite a fonctionné pour moi:

kubectl patch service mon-loadbalancer-service-name \ -n lb-service-namespace \ -p '{"spec": {"type": "LoadBalancer", "externalIPs": ["xxx.xxx.xxx.xxx Privé IP du serveur physique - Nœud - où le déploiement est effectué "]}} '


0

supprimer le service existant et créer un même nouveau service a résolu mes problèmes. Mon problème est que l'équilibrage de charge Ip que je définit est utilisé de sorte que le point de terminaison externe soit en attente. Lorsque j'ai changé une nouvelle adresse IP d'équilibrage de charge, cela ne fonctionnait toujours pas. Enfin, supprimez le service existant et créez-en un nouveau a résolu mon problème.


0

Vérifiez les journaux du contrôleur kube. J'ai pu résoudre ce problème en définissant les balises clusterID sur l'instance ec2 sur laquelle j'ai déployé le cluster.


0

S'il s'agit de votre cluster k8 privé, MetalLB conviendrait mieux. Voici les étapes.

Étape 1: Installez MetalLB dans votre cluster

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)"

Étape 2: Configurez-le à l'aide d'un configmap

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 

Étape 3: Créez votre service pour obtenir une adresse IP externe (ce serait cependant une adresse IP privée).

FYR:

Avant l'installation de MetalLB: entrez la description de l'image ici

Après l'installation de MetalLB: entrez la description de l'image ici

entrez la description de l'image ici


0

Ajout d'une solution pour ceux qui ont rencontré cette erreur lors de l'exécution sur .

Tout d'abord, lancez:

kubectl describe svc <service-name>

Et puis examinez le eventschamp dans l'exemple de sortie ci-dessous:

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

Consultez le message d'erreur:

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

Dans mon cas, la raison pour laquelle aucun sous-réseau approprié n'a été fourni pour créer l'ELB était:

1: Le cluster EKS a été déployé sur le mauvais groupe de sous-réseaux - sous-réseaux internes au lieu de publics.
(*) Par défaut, les services de type LoadBalancercréent des équilibreurs de charge publics si aucune service.beta.kubernetes.io/aws-load-balancer-internal: "true"annotation n'a été fournie).

2: Les sous-réseaux n'ont pas été étiquetés conformément aux exigences mentionnées ici .

Marquage de VPC avec:

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

Balisage des sous-réseaux publics avec:

Key: kubernetes.io/role/elb
Value: 1
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.