Solucionado (ver solução)
Solucionado
(ver solução)
4
respostas

[Dúvida] Não consigo acessar aplicação Spring boot pelo Postman

Boa noite,

Tenho uma aplicação feita em Spring boot e já está criado a imagem e subido no dockerHub.
Seguindo as aulas criei o arquivo para criar um container do tipo POD:

apiVersion: v1
kind: Pod
metadata:
  name: pod-alura-flix-api
  labels:
    app: alura-flix-api
spec:
  containers:
    - name: container-alura-flix-api
      image: laurocorreia/reactive-api
      ports:
        - containerPort: 8080

e outro para o nodePort:

apiVersion: v1
kind: Service
metadata:
  name: svc-alura-flix-api
  labels:
    app: alura-flix-api
spec:
  type: NodePort
  ports:
    - port: 8080
      nodePort: 30000
      targetPort: 8080
  selector:
    app: alura-flix-api

Porém quando tento executar pelo postman utilizando a porta 30000 e o INTERNAL-IP do comando kubectl get nodes -o wide nada funciona.
Por favor, poderia ajudar-me?

Obrigado

4 respostas

Olá Lauro.
Tudo bem?
Esse tipo de problema é bastante comum ao iniciar com Kubernetes, e pelo que você mostrou, seus arquivos YAML estão corretos do ponto de vista estrutural.
Normalmente, o problema não está no código, mas no ambiente onde o cluster está rodando.

  1. Verifique se o Pod está em execução

Execute:

kubectl get pods

O status do Pod deve estar como Running.

Caso não esteja, verifique os detalhes e os logs:

kubectl describe pod pod-alura-flix-api
kubectl logs pod pod-alura-flix-api

Se a aplicação Spring Boot não estiver subindo corretamente (por exemplo, erro de porta, configuração de perfil ou dependência externa), o Service não conseguirá expor a aplicação.

  1. Verifique se o Service foi criado corretamente

Execute:

kubectl get svc

Você deve ver algo semelhante a:

svc-alura-flix-api   NodePort   10.x.x.x   <none>   8080:30000/TCP

Depois, verifique os detalhes do Service:

kubectl describe svc svc-alura-flix-api

Confirme especialmente:

  • O NodePort configurado como 30000
  • O targetPort como 8080
  • O selector como app: alura-flix-api

O selector precisa corresponder exatamente ao label definido no Pod.

  1. Teste a aplicação a partir de dentro do cluster

Isso ajuda a identificar se o problema está na exposição externa ou na aplicação em si.

Execute:

kubectl exec -it pod-alura-flix-api -- curl http://localhost:8080

Se a chamada funcionar, a aplicação está respondendo corretamente dentro do container. Caso contrário, o problema está na aplicação Spring Boot.

  1. Verifique qual ambiente Kubernetes você está utilizando

Esse ponto é fundamental, pois o comportamento do NodePort muda conforme o ambiente.

Se estiver usando Minikube

O NodePort não funciona diretamente com o INTERNAL-IP do node.

Use um dos métodos abaixo:

minikube service svc-alura-flix-api

Ou:

minikube ip

E no Postman:

http://<IP_DO_MINIKUBE>:30000

Se estiver usando Docker Desktop com Kubernetes

Utilize diretamente:

http://localhost:30000

Nesse caso, o INTERNAL-IP retornado pelo Kubernetes geralmente não funciona para acesso externo.

Se estiver usando Kubernetes em uma VM ou na nuvem

Nesse cenário, o acesso via NodePort funciona com:

http://<INTERNAL-IP-DO-NODE>:30000

Mas é necessário garantir que:

  • A porta 30000 esteja liberada no firewall da VM
  • O Security Group (AWS, GCP, Azure) permita tráfego nessa porta
  1. Teste usando port-forward (para depuração)

Esse teste ajuda a isolar problemas de rede:

kubectl port-forward pod/pod-alura-flix-api 8080:8080

Depois, acesse no Postman:

http://localhost:8080

Se funcionar, o problema está exclusivamente na configuração de rede ou no uso do NodePort.

  1. Observação de boas práticas

Para estudos mais avançados ou ambientes reais, o ideal é:

  • Usar um Deployment em vez de Pod diretamente
  • Usar Service do tipo ClusterIP
  • Expor externamente via Ingress

Para fins de aprendizado, o uso de Pod + NodePort está correto.
Seus arquivos YAML estão corretos.
O problema provavelmente está relacionado ao ambiente Kubernetes ou à forma de acesso ao NodePort.
Avise qualquer duvida.
Bons estudos.

Bom dia Ronaldo,

Obrigado pela resposta, realmente os arquivos estavam estruturalmente corretos, o problema era a porta que estava utilizando.
Aproveito para perguntar, por que em ambiente real não se utiliza Pod + NodePort?
Sempre é necessário criar um serviço ClusterIp e outro NodePort?
Também gostaría de perguntar se você sabe si na Alura há curso que ensina como expor externamente via Ingress?

Orbigado pela ajuda!

solução!

Ola amigo..
obrigado pelo feedback!
Fecha esse tópico marcando como solucionado e abre outro com sua nova pergunta...te respondo por lá...
tem muita coisa pra explicar e para evitar confusão também...
aguardo...
bons estudos.

Olá amigo vou lhe passar uma explicação rapida por aqui mesmo...
Por que não se usa Pod + NodePort em ambiente real?
O Pod é efêmero e o NodePort é um recurso de baixo nível, pouco adequado para produção.
Em produção, normalmente não se cria Pods diretamente, pois:

  • Se o Pod morrer, ele não é recriado automaticamente
  • Não há controle de:
    • escala
    • atualização gradual (rolling update)
    • alta disponibilidade

Em vez disso, utiliza-se:

  • Deployment
  • StatefulSet
  • Job ou CronJob

Esses recursos gerenciam o ciclo de vida dos Pods.
O NodePort expõe a aplicação em todas as nodes do cluster, utilizando uma porta fixa (intervalo 30000–32767). Em produção isso gera vários problemas:

  • Exposição desnecessária da aplicação
  • Falta de TLS, autenticação e controle de acesso
  • Dificuldade de governança e segurança
  • Baixa flexibilidade para mudanças

Por isso, o NodePort é mais usado em ambientes de estudo ou testes locais.
Por que nas aulas funciona Pod + NodePort?
Porque é um modelo didático:

  • Facilita o entendimento dos conceitos básicos
  • Permite acesso rápido à aplicação
  • Reduz a complexidade inicial

É um padrão comum para aprendizado, mas não representa uma arquitetura real de produção.
Em produção, o fluxo mais comum é:
Usuário externo:

  • Ingress ou LoadBalancer
  • Service do tipo ClusterIP
  • Pods gerenciados por Deployment

Não é sempre necessário criar ClusterIP e NodePort.
O Service do tipo ClusterIP é quase sempre utilizado, pois:

  • É o padrão para comunicação interna
  • Serve como base para Ingress, Service Mesh e outros componentes

NodePort raramente é usado em produção e só faz sentido quando:

  • Não há Ingress disponível
  • Não há suporte a LoadBalancer
  • Há necessidade de exposição rápida e temporária

O que se usa no lugar do NodePort?
Ingress é a abordagem mais comum em produção:

  • Centraliza o acesso externo
  • Permite roteamento por domínio e path
  • Suporta TLS
  • Facilita controle de acesso e segurança

Service do tipo LoadBalancer é muito usado em ambientes cloud:

  • O provedor cria automaticamente um load balancer externo
  • Fornece IP público para a aplicação
  • Simplifica a exposição de serviços

NodePort é adequado para aprendizado e cenários temporários, mas não é a melhor escolha para produção.
Agora quanto as aulas sobre Ingress não sei informar e precisa dar uma pesquisada.
Qualquer duvida comente ai.
Bons estudos.