IP externe du service kubernetes en attente

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.

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

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.

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

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

Pour accéder à un service sur minikube, vous devez exécuter la commande suivante:

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

Plus d'informations ici: Minikube GitHub

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

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

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

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 .

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.

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)

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.

Si vous n'êtes pas sur un cloud pris en charge (aws, azure, gcloud etc.) vous ne pouvez pas utiliser LoadBalancer sans MetalLB https://metallb.universe.tf/ mais il est encore en version bêta ..

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

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é "]}} '

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.

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.

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:

Après l'installation de MetalLB:

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

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