serviço kubernetes ip externo pendente


142

Estou tentando implantar o nginx no kubernetes, a versão do kubernetes é v1.5.2, implantei o nginx com 3 réplicas, o arquivo YAML está abaixo,

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 agora quero expor sua porta 80 na porta 30062 do nó, para isso criei um serviço abaixo,

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

este serviço está funcionando bem como deveria, mas está sendo exibido como pendente não apenas no painel do kubernetes, mas também no terminal. Saída terminalStatus do painel de instrumentos

então, por favor me ajude a resolver esse problema. Obrigado ...

Respostas:


177

Parece que você está usando um costume Kubernetes Cluster (usando minikube, kubeadmou semelhantes). Nesse caso, não há LoadBalancer integrado (ao contrário da AWS ou do Google Cloud). Com esta configuração padrão, você pode usar apenas NodePortum Controlador de ingresso.

Com o Ingress Controller, você pode configurar um nome de domínio que mapeie para o seu pod; você não precisa dar ao seu serviço o LoadBalancertipo se você usa um controlador de ingresso.


Muito obrigado @ javier, isso é realmente útil. Resolvi meu problema acima, doc.
Pankaj Jackson

9
Isso realmente não responde à pergunta? O usuário está usando LoadBalancercomo um tipo de serviço que é um tipo de serviço válido. NodePorte ingressexistem outras maneiras de fazer isso, mas realmente não resolvendo o problema, certo?
Raptor

2
É um tipo de serviço válido, mas está sendo usado em uma plataforma não compatível (pelo menos por padrão). Para usar o LoadBalancer, você deve ter uma plataforma que possa fornecer IPs externos aos pods, algo que o Google Cloud ou a AWS fazem.
Javier Salmeron 27/03

2
Estou usando o kubeadm na AWS. Ainda posso LoadBalancer?
jiashenC

3
Se você estiver usando o minikube, execute o "túnel do minikube". Agora verifique seus serviços, você receberá o IP público. Aqui está o documento para obter mais informações minikube.sigs.k8s.io/docs/tasks/loadbalancer
Ravi

73

Se você estiver usando o Minikube, há um comando mágico!

$ minikube tunnel

Espero que alguém possa economizar alguns minutos com isso.

Link de referência https://minikube.sigs.k8s.io/docs/handbook/accessing/#using-minikube-tunnel


Eu tentei minikube tunnele ele realmente resolve o pendingproblema, mas, em seguida, o novo IP externo não funciona: eu recebo um erro de tempo limite ...
a.barbieri

@ a.barbieri verifique se você está usando o ip do túnel em vez do ip do minikube. "corrigindo o ingress-nginx com IP 10.106.102.98"
Peter Zhou

2
sim obrigado Peter. Vai tentar. De qualquer maneira, alternando para o Docker Desktop, eu pude superar esse problema com a configuração pronta para uso que funciona diretamente no host local.
a.barbieri

3
Excelente dica de economia de tempo para demonstração!
Jgitter #

49

Se você não estiver usando GCE ou EKS (você usou kubeadm), poderá adicionar uma externalIPsespecificação ao seu serviço YAML. Você pode usar o IP associado à interface principal do seu nó, como eth0. Você pode acessar o serviço externamente, usando o IP externo do nó.

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

2
Deve haver uma informação que falta: "IPs externos não são gerenciados pelo Kubernetes e são de responsabilidade do administrador do cluster". ( kubernetes.io/docs/concepts/services-networking/service ). Existe algum tipo de "controlador" que tenho que instalar?
Daniel Alder

Eu estou seguindo o tutorial Kubernetes ( kubernetes.io/docs/tutorials/stateless-application/guestbook ) e funcionou muito bem com kubeadm
Eduardo

Obrigado - brilhante, funcionou como esperado. Eu expus o Serviço aos nós e à rede IP, que agora está acessível fora do cluster
Vlad Gulin


21

Criei um cluster k8s de nó único usando o kubeadm. Quando tentei o PortForward e o proxy kubectl , ele mostrou o IP externo como pendente.

$ 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

No meu caso, corrigi o serviço assim:

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

Depois disso, ele passou a servir pelo IP público

$ 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
Talvez você deva mencionar de onde "172.31.71.218" vem?
EuRBamarth 26/09/19

Finalmente, uma resposta que mostra como corrigir. Obrigado por compartilhar.
Srikant 10/06

5

Se estiver executando no minikube , não esqueça de mencionar o namespace se você não estiver usando o padrão.

serviço minikube << service_name >> --url --namespace = << namespace_name >>


4

Se você estiver usando o minikube, execute os comandos abaixo no terminal,

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

2

o mesmo problema:

os> kubectl obtém svc right-sabertooth-wordpress

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

os> lista de serviços do minikube

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

| NAMESPACE NOME URL

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

| padrão | kubernetes | Nenhuma porta de nó |

| padrão | marertob-sabertooth-direito | Nenhuma porta de nó |

| padrão | direito-sabertooth-wordpress | http://192.168.99.100:30454 |

| | | http://192.168.99.100:30427 |

| sistema kube | kube-dns | Nenhuma porta de nó |

| sistema kube | implantação do leme | Nenhuma porta de nó |

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

É, no entanto, acessível através desse http://192.168.99.100:30454 .


2

Seguindo a resposta de @ Javier. Eu decidi ir com "corrigindo o IP externo" para o meu balanceador de carga.

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

Isso substituirá o 'pendente' por um novo endereço IP corrigido que você pode usar para o seu cluster.

Para mais sobre isso. Consulte a publicação de karthik no suporte ao LoadBalancer com o Minikube for Kubernetes

Não é a maneira mais limpa de fazer isso. Eu precisava de uma solução temporária. Espero que isso ajude alguém.


1

Use o NodePort:

kubectl executar login do usuário --replicas = 2 - etiquetas = "executar = login do usuário" --image = kingslayerr / teamproject: version2 --port = 5000

kubectl expõe a implantação user-login --type = NodePort --name = user-login-service

O kubectl descreve os serviços user-login-service (Observe a porta)

informações do cluster kubect (IP-> Obter o IP onde o mestre está sendo executado)

Seu serviço está acessível em (IP) :( porta)


1

Ao usar o Minikube, você pode obter o IP e a porta através da qual pode acessar o serviço executando o serviço minikube kubia-http.



1

O LoadBalancer ServiceType funcionará apenas se a infraestrutura subjacente suportar a criação automática de balanceadores de carga e tiver o respectivo suporte no Kubernetes, como é o caso do Google Cloud Platform e da AWS. Se nenhum desses recursos estiver configurado, o campo Endereço IP do LoadBalancer não será preenchido e ainda estará no status pendente, e o Serviço funcionará da mesma maneira que um Serviço do tipo NodePort


1

Você pode corrigir o IP do nó em que os pods estão hospedados (IP privado do nó), essa é a solução fácil.

Tomando referência às postagens acima, a seguir funcionou para mim:

serviço de patch kubectl my-loadbalancer-service-name \ -n lb-service-namespace \ -p '{"spec": {"type": "LoadBalancer", "externalIPs": ["xxx.xxx.xxx.xxx particular IP do servidor físico - Nó - onde a implantação é feita "]}} '


0

excluir o serviço existente e criar um mesmo novo serviço resolveu meus problemas. Meu problema é que o balanceamento de carga que Ip I define é usado para que o endpoint externo esteja pendente. Quando alterei um novo IP de balanceamento de carga, ele ainda não funcionava. Por fim, exclua o serviço existente e crie um novo resolvido meu problema.


0

Verifique os logs do controlador kube. Consegui resolver esse problema definindo as tags clusterID na instância ec2 na qual implantei o cluster.


0

Se for o seu cluster privado do k8s, o MetalLB seria mais adequado. Abaixo estão os passos.

Etapa 1: instalar o MetalLB no seu 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)"

Etapa 2: Configure usando um 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 

Etapa 3: crie seu serviço para obter um IP externo (seria um IP privado).

ARJ:

Antes da instalação do MetalLB: insira a descrição da imagem aqui

Após a instalação do MetalLB: insira a descrição da imagem aqui

insira a descrição da imagem aqui


0

Adicionando uma solução para aqueles que encontraram esse erro enquanto executavam no .

Antes de tudo, execute:

kubectl describe svc <service-name>

E revise o eventscampo no exemplo de saída abaixo:

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 a mensagem de erro:

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

No meu caso, o motivo pelo qual não foram fornecidas sub-redes adequadas para a criação do ELB foi:

1: O cluster EKS foi implantado no grupo de sub-redes errado - sub-redes internas em vez de voltadas para o público.
(*) Por padrão, serviços do tipo LoadBalancercriam balanceadores de carga voltados para o público se nenhuma service.beta.kubernetes.io/aws-load-balancer-internal: "true"anotação foi fornecida).

2: As sub-redes não foram marcadas de acordo com os requisitos mencionados aqui .

Marcando a VPC com:

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

Marcando sub-redes públicas com:

Key: kubernetes.io/role/elb
Value: 1
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.