Estou tentando colocar dois trabalhadores do Kubernetes em instâncias do EC2 e me deparo com um problema em que o serviço parece não "ver" todos os pods que deveria ser capaz de ver.
Meu ambiente exato é um par de AWS Snowballs, vermelho e azul, e meu cluster se parece com control, worker-rede worker-blue[1]. Estou implantando um servidor python fictício que aguarda um GET na porta 8080 e responde com o nome do host local. Eu configurei-o com réplicas suficientes para ambos worker-rede worker-bluetenho pelo menos um pod cada. Finalmente, criei um serviço cuja especificação se parece com
spec:
type: NodePort
selector:
app: hello-server
ports:
- port: 8080
targetPort: 8080
nodePort: 30080
Agora posso verificar se meus pods estão funcionando
kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
hello-world-deployment-587468bdb7-hf4dq 1/1 Running 0 27m 192.168.1.116 worker.red <none> <none>
hello-world-deployment-587468bdb7-mclhm 1/1 Running 0 27m 192.168.1.126 worker.blue <none> <none>
Agora posso tentar enrolá-los
curl worker-red:30080
greetings from hello-world-deployment-587468bdb7-hf4dq
curl worker-blue:30080
greetings from hello-world-deployment-587468bdb7-mclhm
Isso é o que acontece na metade das vezes. Na outra metade das vezes, o curl falha com um erro de tempo limite. Especificamente - curling trabalhador-vermelho SOMENTE produzirá uma resposta de hf4dq, e curling trabalhador-azul SOMENTE produzirá uma resposta de mclhm. Se eu isolar e drenar o trabalhador-azul para que ambos os meus pods funcionem no trabalhador-vermelho, nunca haverá um tempo limite e ambos os pods responderão.
Parece que o serviço NodePort não está alcançando pods que não estão no host que estou enrolando. Pelo que entendi, não é assim que os serviços devem funcionar. o que estou perdendo?
[1] Se eu configurar de forma que tenha dois trabalhadores no Red, o mesmo problema que estou descrevendo acontecerá, mas este é meu caso de uso principal, então é nele que vou me concentrar.
Responder1
É difícil simplesmente dizer o que pode estar errado aqui, mas existem algumas etapas que você pode seguir para solucionar seu problema:
- Pods de depuração, verifique especialmente se há algo suspeito nos logs:
kubectl logs ${POD_NAME} ${CONTAINER_NAME}kubectl logs --previous ${POD_NAME} ${CONTAINER_NAME}
- Serviços de depuração, por exemplo, verificando:
O Serviço existe?
O serviço funciona por nome DNS?
O Serviço funciona por IP?
O serviço está definido corretamente?
O serviço possui algum endpoint?
O proxy kube está funcionando?
Seguir essas etapas ajudará você a encontrar a causa do seu problema e também a entender melhor a mecânica por trás dos serviços.
Responder2
Você está usando NodePorto tipo service e, nesse caso, o que você está observando é muito esperado.
Seu serviço corresponde a dois pods em execução em dois nós diferentes. Como o serviço é do tipo NodePort, há uma associação inerente de um pod do seu serviço e do nó em que ele está sendo executado. Se você enrolar o worker-redponto final, você iráAPENASobtenha a resposta do worker-redpod, isso ocorre porque o outro pod está vinculado a outro endpoint worker-blue:<node-port>e não pode ser acessado a partir do worker-redendpoint. Sim, é o mesmo serviço, mas é apoiado por 2 endpoints, cada um com nomes de host diferentes.
É basicamente assim que NodePortos serviços funcionam.
Quando você agrupa ambos no mesmo nó, ambos os pods ficam acessíveis a partir do mesmo nome de host do nó, portanto, curlá-los funcionará. Desde agora, ambos os endpoints são mapeados para portas diferentes, mas omesmo nome de host.
Como forma de aprofundar sua compreensão sobre isso. Você pode tentar alterar seu tipo de serviço para LoadBalancer. E você notará que poderá acessar os dois pods usando o mesmo nome de host, independentemente de onde eles estiverem sendo agendados. E este nome de host/endereço IP será o endereço que LoadBalancertodos os pods do serviço terão em comum.
Espero que isso esclareça sua confusão!