Kubernetes Service externe IP ausstehend

Ich versuche, nginx auf kubernetes bereitzustellen, kubernetes Version ist v1.5.2, ich habe nginx mit 3 Replikaten bereitgestellt, YAML-Datei ist unten,

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

und jetzt möchte ich seinen Port 80 auf Port 30062 des Knotens verfügbar machen, dafür habe ich unten einen Dienst erstellt,

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

Dieser Dienst funktioniert einwandfrei, wird jedoch nicht nur im kubernetes-Dashboard, sondern auch im Terminal als ausstehend angezeigt.

Bitte helfen Sie mir, dieses Problem zu beheben. Vielen Dank ...

Es sieht aus wie Sie eine benutzerdefinierte Kubernetes Cluster (mit Verwendung minikube, kubeadmoder dergleichen). In diesem Fall ist kein LoadBalancer integriert (im Gegensatz zu AWS oder Google Cloud). Mit dieser Standardeinstellung können Sie nur NodePorteinen Ingress Controller verwenden.

Mit dem Ingress Controller können Sie einen Domainnamen einrichten, der Ihrem Pod zugeordnet ist. Sie müssen Ihrem Service nicht den LoadBalancerTyp geben, wenn Sie einen Ingress Controller verwenden.

Wenn Sie Minikube verwenden, gibt es einen magischen Befehl!

$ minikube tunnel

Hoffentlich kann jemand damit ein paar Minuten sparen.

Referenzlink https://minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel

Wenn Sie GCE oder EKS (Sie haben es nicht verwendet kubeadm) nicht verwenden , können Sie externalIPsIhrer Service-YAML eine Spezifikation hinzufügen . Sie können die IP-Adresse verwenden, die der primären Schnittstelle Ihres Knotens zugeordnet ist, z eth0. Sie können dann über die externe IP des Knotens extern auf den Dienst zugreifen.

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

Um auf einen Dienst zuzugreifen minikube, müssen Sie den folgenden Befehl ausführen:

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

Weitere Informationen hier: Minikube GitHub

Ich habe mit kubeadm einen einzelnen Knoten-k8s-Cluster erstellt. Als ich PortForward und Kubectl Proxy ausprobierte , zeigte es externe IP als ausstehend an.

$ 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

In meinem Fall habe ich den Dienst wie folgt gepatcht:

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

Danach wurde es über die öffentliche IP-Adresse bereitgestellt

$ 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

Wenn Sie mit minikube arbeiten , vergessen Sie nicht, den Namespace anzugeben , wenn Sie nicht die Standardeinstellung verwenden.

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

Wenn Sie minikube verwenden, führen Sie die folgenden Befehle vom Terminal aus.

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

gleicher Fehler:

os> kubectl get svc right-sabertooth-wordpress

NAME TYP CLUSTER-IP EXTERN-IP PORT (S)
Rechts-Sabertooth-WordPress LoadBalancer 10.97.130.7 "ausstehend" 80: 30454 / TCP, 443: 30427 / TCP

os> minikube service liste

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

| NAMENRAUM | NAME | URL |

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

| Standard | kubernetes | Kein Knotenport |

| Standard | rechts-sabertooth-mariadb | Kein Knotenport |

| Standard | rechts-sabertooth-wordpress | http://192.168.99.100:30454 |

| | | http://192.168.99.100:30427 |

| kube-system | kube-dns | Kein Knotenport |

| kube-system | Pinne-Einsatz | Kein Knotenport |

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

Es ist jedoch über die http://192.168.99.100:30454 zugänglich .

Nach der Antwort von @ Javier. Ich habe mich für das "Patchen der externen IP" für meinen Load Balancer entschieden.

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

Dadurch wird diese ausstehende IP-Adresse durch eine neue gepatchte IP-Adresse ersetzt, die Sie für Ihren Cluster verwenden können.

Mehr dazu. Weitere Informationen finden Sie in Karthiks Beitrag zur LoadBalancer-Unterstützung mit Minikube für Kubernetes

Nicht der sauberste Weg, es zu tun. Ich brauchte eine vorübergehende Lösung. Hoffe das hilft jemandem.

Verwenden Sie NodePort:

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

kubectl enthüllt die Bereitstellung Benutzeranmeldung --type = NodePort --name = Benutzeranmeldedienst

kubectl beschreibt Dienste Benutzer-Anmeldedienst (Notieren Sie den Port)

kubect cluster-info (IP-> Get Die IP, auf der der Master ausgeführt wird)

Ihr Dienst ist erreichbar unter (IP) :( Port)

Wenn Sie Minikube verwenden, können Sie die IP und den Port abrufen, über die Sie auf den Dienst zugreifen können, indem Sie den Minikube-Dienst kubia-http ausführen.

Wenn Sie sich nicht in einer unterstützten Cloud befinden (aws, azure, gcloud usw.), können Sie LoadBalancer nicht ohne MetalLB https://metallb.universe.tf/ verwenden, aber es befindet sich noch in der Beta.

Der LoadBalancer ServiceType funktioniert nur, wenn die zugrunde liegende Infrastruktur die automatische Erstellung von Load Balancern unterstützt und die entsprechende Unterstützung in Kubernetes bietet, wie dies bei Google Cloud Platform und AWS der Fall ist. Wenn keine solche Funktion konfiguriert ist, wird das LoadBalancer-IP-Adressfeld nicht ausgefüllt und befindet sich noch im Status "Ausstehend". Der Dienst funktioniert genauso wie ein Dienst vom Typ NodePort

Sie können die IP des Knotens patchen, auf dem Pods gehostet werden (Private IP des Knotens). Dies ist die einfache Problemumgehung.

Unter Bezugnahme auf die obigen Beiträge hat Folgendes für mich funktioniert:

kubectl patch service my-loadbalancer-service-name \ -n lb-service-namespace \ -p '{"spec": {"type": "LoadBalancer", "externalIPs": ["xxx.xxx.xxx.xxx Private IP des physischen Servers - Knoten - wo die Bereitstellung erfolgt "]}} '

Bestehenden Dienst löschen und denselben neuen Dienst erstellen löste meine Probleme. Meine Probleme sind, dass die von mir definierte IP-Lastausgleichs-IP verwendet wird, sodass der externe Endpunkt aussteht. Wenn ich eine neue IP für den Lastausgleich geändert habe, funktioniert sie immer noch nicht. Löschen Sie schließlich den vorhandenen Dienst und erstellen Sie einen neuen, um mein Problem zu lösen.

Überprüfen Sie die Kube-Controller-Protokolle. Ich konnte dieses Problem lösen, indem ich die clusterID-Tags auf die ec2-Instanz setzte, auf der ich den Cluster bereitgestellt habe.

Wenn es sich um Ihren privaten k8s-Cluster handelt, ist MetalLB besser geeignet. Unten sind die Schritte.

Schritt 1: Installieren Sie MetalLB in Ihrem 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)"

Schritt 2: Konfigurieren Sie es mithilfe einer Konfigurationskarte

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 

Schritt 3: Erstellen Sie Ihren Dienst, um eine externe IP zu erhalten (wäre jedoch eine private IP).

EJR:

Vor der Installation von MetalLB:

Nach der Installation von MetalLB:

Hinzufügen einer Lösung für diejenigen, bei denen dieser Fehler beim Ausführen aufgetreten ist amazon-eks.

Zunächst einmal ausführen:

kubectl describe svc <service-name>

Überprüfen Sie anschließend das eventsFeld in der folgenden Beispielausgabe:

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

Überprüfen Sie die Fehlermeldung:

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

In meinem Fall war der Grund dafür, dass keine geeigneten Subnetze zum Erstellen der ELB bereitgestellt wurden:

1: Der EKS-Cluster wurde in der falschen Subnetzgruppe bereitgestellt - interne Subnetze statt öffentlich zugänglich.
(*) Standardmäßig LoadBalancererstellen Dienste des Typs öffentlich zugängliche Load Balancer, wenn keine service.beta.kubernetes.io/aws-load-balancer-internal: "true"Anmerkung angegeben wurde.)

2: Die Subnetze wurden nicht gemäß den hier genannten Anforderungen markiert .

Tagging VPC mit:

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

Öffentliche Subnetze markieren mit:

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