인프런 커뮤니티 질문&답변
작성한 질문수
node1 과 node2 사이에 통신이 잘 되지 않는지
해결된 질문
작성
·
664
2
안녕하세요.
ClusterIP 로 서비스를 만들고 로컬PC나 내부망에서 node 호출 시에 아래와 같은 현상이 있습니다.
> curl 192.168.56.31:30000/hostname
Hostname : pod-1
> curl 192.168.56.31:30000/hostname
===> 무응답
> curl 192.168.56.32:30000/hostname
Hostname : pod-2
> curl 192.168.56.31:30000/hostname
===> 무응답
node 1번으로 호출 시 pod-1 로 분기되었을때는 정상 동작합니다. 하지만 pod-2 로 분기되었을때는 (추측) 무응답으로 멈춰 있습니다.
node 2번으로 호출 시 pod-2로 분기되었을때만 정상 동작합니다.
> curl 서비스IP:9000/hostname
내부망에서 호출 시에는 정상적으로 분기되면서 동작합니다.
Virtual Box 를 NAT설정과 함께 되어 있어서 그런게 아닌지 싶은데 어떤 방향으로 찾아봐야 할지 조언을 구할 수 있을까요?
* Virtual Box NAT 설정 때문에 아래와 같이 초기화 시 IP 를 지정해주었었습니다.
kubeadm init --apiserver-advertise-address=192.168.56.30 --pod-network-cidr=20.96.0.0/12
답변 10
1
0
아닙니다. 해결 내용을 알려주셔서 제가 더 감사합니다^^
저도 다음주 쯤에 VirtualBox를 이용해서 설치를 해보고 자료 공유를 할려고 생각중입니다.
아무래도 그렇게 환경을 셋팅하셔야 하는 분들이 더 많은 것 같네요 ^^;
공부하시면서 문의사항 있으시면 언제든 질문 올려주세요~!
0
Virtual Box 에서 NAT + Host only adapter 구성을 NAT Network + Host only adapter 로 변경해서 해결했습니다.
NAT <-> NAT Network 의 차이가 하위 서버들 간에 서로 통신이 가능 여부라는데
원래도 완전히 통신 안된 것도 아니라 사실 이해가 잘 안되지만 어쨌든 해결 되었습니다...
바쁘실텐데 죄송합니다.
강의 정말 잘 듣고 있습니다. 수고하세요.
0
동일하게 virtual box 를 bridge adapter 방식으로 생성하니 정상적으로 동작했습니다.
기존에는 NAT + Host-only Adapter 방식인데 제가 뭔가 잘못 한게 아닌가 싶습니다.
kubectl init 했을때 NAT IP 로 생성되어서 아래 처럼 IP 지정해준 것도 찝찝했고..
> kubeadm init --apiserver-advertise-address=192.168.56.30 --pod-network-cidr=20.96.0.0/12
개인 공유기가 아니라 호스트 IP 가 계속 바뀌다보니
bridge adapter 방식에서 고정 IP 설정이 가능할지 모르겠습니다.
기존 방식이 왜 안 되는지 연구를 좀 해보다가
안되면 저도 태민님 처럼 집에 노트북을 서버로 사용해서 강의부터 계속 들어야 할 것 같습니다.
감사합니다.
0
네, 이제 질문에 대한 이해가 잘 되었네요^^;
제가 경험해 보지 못한 부분이라 제가 알고 있는 방향으로만 해석하려고 했던것 같습니다.
아래와 같이 Service가 알아서 Pod-1이 있는 Node1에만 호출해서 무조건 hostname이 찍혀야 되는데 현재 추측으로는 Service가 Node2를 호출을 하는 것인지 똑같은 주소로 curl을 날려도 무응답이 떨어질 때가 있다는 말씀이지요?
근데 그렇다면 ServiceIP로 호출할때도 마찬가지여야 되는데 이때는 또 잘 되는거고요?
이게 맞다면 이건 좀 쉽지 않은 문제네요^^;
혹시 Pod는 아래와 같이 만드셨나요? 아래 예제대로 컨테이너 하나만 만드신 건지요?
컨테이너를 두개 만드셨거나, 다른 image를 쓰시건 아닌지요?
apiVersion: v1 kind: Pod metadata: name: pod-1 labels: app: pod spec: nodeSelector: kubernetes.io/hostname: k8s-node1 containers: - name: container image: tmkube/app ports: - containerPort: 8080
0
그림과는 다르구요.
빨간선으로는 잘 가는 것 같은데 파란선이 본인 노드로 연결 되었을 때만 되는 것 같습니다.
파란선이 Node1, Node2 번갈아 가며 호출이 될텐데
31번 노드로 접근하면 31번으로 파란색이 갔을때는 응답이 되는 것 같고
31번 노드로 접근했지만 32번으로 파란색이 갔을때는 응답이 안되는 것 같습니다.
32번 노드로 접근하면 반대로 동일한 현상입니다.
(사실 내부나 로그를 보지는 못해 추측 한 것입니다.)
그래서
externalTrafficPolicy : local
이 옵션을 주면 본인 Node 로만 연결되니 정상 응답하고
내부망인 master 서버에서 service IP로 호출해보면 Node1, Node2 번갈아가면서 잘 되고
외부에서 호출 했을때만 그러네요.
0
일단 질문을 제가 정확히 이해하고 있는 건지 확인 부탁드릴께요.
아래와 같이 위에 externalTrafficPolicy : local이라는 속성 자체를 주지 않았을, 기본적인 NodePort를 만들었을 경우
apiVersion: v1
kind: Service
metadata:
name: svc-2
spec:
selector:
app: pod
ports:
- port: 9000
targetPort: 8080
nodePort: 30000
type: NodePort
아래 그림과 같이 Node1이건 Node2건 해당 호스트 IP(31,32)로 접근을 했을 경우, NodePort라면 어느 Node의 Port로 접근했건 간에 당연히 Service로 접근이 되고 Pod가 어느 노드위에 있건간에 Service에 연결되있기 때문에 파란선을 따라 접근이 되어야 하는데,
pod-1이 Node1위에 만들어 졌을 경우, Node1의 IP주소(192.168.0.31:30000)으로 접근을 하면 hostname이 호출이 되는데, Node2(192.168.0.56.32:30000)으로 접근을 하면 hostname이 호출이 안된다는 질문으로 이해가 되는데요,
혹시 제가 잘못 이해한 건지 확인 부탁드려요.
0
0
강의 예제 그대로 했습니다.
apiVersion: v1 kind: Service metadata: name: svc-2 spec: selector: app: pod ports: - port: 9000 targetPort: 8080 nodePort: 30000 type: NodePort
externalTrafficPolicy : local
이 옵션을 주면 해당 pod 만 찾으니 오히려 문제는 없었구요.
좀 더 원인을 찾아보도록 하겠습니다.
0
이장환님 안녕하세요.
서비스를 만들때 강의 예제를 보고 만드셨다면
externalTrafficPolicy : local
라는 옵션이 들어가 있는데요.
이 옵션을 빼고하시면 원하는대로 작동하실꺼예요^^
해당 옵션 내용에 대해서는 해당 강의내용에 설명이 되어있는데요... ㅠㅜ
혹시 강의예제로 만든 service가 아니고 그래도 잘 안되신다면. service를 만들때 사용하신 ymal 내용을 알려주시면 제가 원인 파악을 하는데 좀 더 도움이 될것 같고요.
일단은 NAT설정과는 무관해보입니다^^