servizio kubernetes IP esterno in sospeso

Sto provando a distribuire nginx su kubernetes, la versione di kubernetes è v1.5.2, ho distribuito nginx con 3 repliche, il file YAML è sotto,

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

e ora voglio esporre la sua porta 80 sulla porta 30062 del nodo, per questo ho creato un servizio di seguito,

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

questo servizio funziona bene come dovrebbe essere, ma si sta dimostrando in sospeso non solo sul cruscotto di kubernetes anche sul terminale.

quindi per favore aiutatemi a risolvere questo problema. Grazie ...

Sembra che si sta utilizzando un custom kubernetes cluster (utilizzando minikube, kubeadmo simili). In questo caso, LoadBalancer non è integrato (diversamente da AWS o Google Cloud). Con questa impostazione predefinita, è possibile utilizzare solo NodePorto un controller di ingresso.

Con Ingress Controller puoi impostare un nome di dominio che si associa al tuo pod; non è necessario fornire il LoadBalancertipo di servizio se si utilizza un controller Ingress.

Se stai usando Minikube, c'è un comando magico!

$ minikube tunnel

Spero che qualcuno possa risparmiare qualche minuto con questo.

Link di riferimento https://minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel

Se non si utilizza GCE o EKS (utilizzato kubeadm), è possibile aggiungere una externalIPsspecifica al servizio YAML. Puoi usare l'IP associato all'interfaccia primaria del tuo nodo come eth0. È quindi possibile accedere al servizio esternamente, utilizzando l'IP esterno del nodo.

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

Per accedere a un servizio minikube, è necessario eseguire il comando seguente:

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

Maggiori informazioni qui: Minikube GitHub

Ho creato un cluster k8s a nodo singolo usando kubeadm. Quando ho provato PortForward e il proxy kubectl , ha mostrato che l'IP esterno era in sospeso.

$ 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

Nel mio caso ho patchato il servizio in questo modo:

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

Successivamente, ha iniziato a essere pubblicato tramite l'IP pubblico

$ 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

Se in esecuzione su minikube , non dimenticare di menzionare lo spazio dei nomi se non si utilizza l'impostazione predefinita.

servizio minikube << nome_servizio >> --url --namespace = << namespace_name >>

Se stai usando minikube, esegui i comandi di seguito dal terminale,

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

stesso problema:

os> kubectl get svc right-sabertooth-wordpress

NOME TIPO CLUSTER-IP EXTERNAL-IP PORT (S)
right-sabertooth-wordpress LoadBalancer 10.97.130.7 "pending" 80: 30454 / TCP, 443: 30427 / TCP

os> elenco dei servizi minikube

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

| NAMESPACE | NOME | URL |

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

| impostazione predefinita | kubernetes | Nessuna porta nodo |

| impostazione predefinita | right-sabertooth-mariadb | Nessuna porta nodo |

| impostazione predefinita | right-sabertooth-wordpress | http://192.168.99.100:30454 |

| | | http://192.168.99.100:30427 |

| sistema kube | kube-dns | Nessuna porta nodo |

| sistema kube | distribuzione timone | Nessuna porta nodo |

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

È, tuttavia, accessibile tramite tale http://192.168.99.100:30454 .

Seguendo la risposta di @ Javier. Ho deciso di scegliere "rattoppare l'IP esterno" per il mio bilanciamento del carico.

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

Ciò sostituirà tale "in sospeso" con un nuovo indirizzo IP con patch che è possibile utilizzare per il cluster.

Per di più su questo. Si prega di consultare il post di karthik sul supporto LoadBalancer con Minikube per Kubernetes

Non è il modo più pulito per farlo. Avevo bisogno di una soluzione temporanea. Spero che questo aiuti qualcuno.

Usa NodePort:

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

kubectl esporre la distribuzione user-login --type = NodePort --name = user-login-service

kubectl descrive i servizi user-login-service (annota la porta)

kubect cluster-info (IP-> Ottieni l'IP su cui è in esecuzione il master)

Il servizio è accessibile all'indirizzo (IP) :( porta)

Quando si utilizza Minikube, è possibile ottenere l'IP e la porta attraverso cui è possibile accedere al servizio eseguendo il servizio minikube kubia-http.

Se non sei su un cloud supportato (aws, azzurro, gcloud ecc.) Non puoi usare LoadBalancer senza MetalLB https://metallb.universe.tf/ ma è ancora in beta ..

LoadBalancer ServiceType funzionerà solo se l'infrastruttura sottostante supporta la creazione automatica di Load Balancer e dispone del rispettivo supporto in Kubernetes, come nel caso della Google Cloud Platform e di AWS. Se tale funzionalità non è configurata, il campo Indirizzo IP LoadBalancer non viene popolato e rimane ancora in sospeso e il Servizio funzionerà allo stesso modo di un servizio di tipo NodePort

È possibile correggere l'IP del nodo in cui sono ospitati i pod (IP privato del nodo), questa è la soluzione semplice.

Facendo riferimento ai post precedenti, Seguito ha funzionato per me:

servizio patch kubectl my-loadbalancer-service-name \ -n lb-service-namespace \ -p '{"spec": {"type": "LoadBalancer", "externalIPs": ["xxx.xxx.xxx.xxx privato IP del server fisico - Nodo - dove viene eseguita la distribuzione "]}} '

elimina il servizio esistente e crea un nuovo servizio risolto i miei problemi. I miei problemi sono che il bilanciamento del carico definito da Ip I viene utilizzato in modo che l'endpoint esterno sia in sospeso. Quando ho cambiato un nuovo IP di bilanciamento del carico, non funzionava ancora. Infine, elimina il servizio esistente e creane uno nuovo risolto il mio problema.

Controlla i registri del controller del cubo. Sono stato in grado di risolvere questo problema impostando i tag clusterID sull'istanza ec2 su cui ho distribuito il cluster.

Se è il tuo cluster privato di k8, MetalLB si adatterebbe meglio. Di seguito sono riportati i passaggi.

Passaggio 1: installare MetalLB nel 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)"

Passaggio 2: configurarlo utilizzando una 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 

Passaggio 3: crea il tuo servizio per ottenere un IP esterno (sarebbe comunque un IP privato).

FYR:

Prima dell'installazione di MetalLB:

Dopo l'installazione di MetalLB:

Aggiunta di una soluzione per coloro che hanno riscontrato questo errore durante l'esecuzione amazon-eks.

Prima di tutto corri:

kubectl describe svc <service-name>

E quindi rivedere il eventscampo nell'output di esempio seguente:

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

Rivedi il messaggio di errore:

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

Nel mio caso, la ragione per cui non sono state fornite sottoreti adatte per la creazione dell'ELB erano:

1: il cluster EKS è stato distribuito nel gruppo di sottoreti errato: sottoreti interne anziché pubbliche.
(*) Per impostazione predefinita, i servizi di tipo LoadBalancercreano bilanciamento del carico pubblico se non è service.beta.kubernetes.io/aws-load-balancer-internal: "true"stata fornita alcuna annotazione).

2: Le sottoreti non sono state taggate in base ai requisiti menzionati qui .

Taggare VPC con:

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

Contrassegnare le subnet pubbliche con:

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