인프런 커뮤니티 질문&답변
작성한 질문수
K8s 에서 Service, Pod, Container 의 Port 매핑 질문
작성
·
84
0
안녕하세요 강사님.
Helm 강의이긴 하지만 K8s 도 전문적으로 가르치시는 걸로 알고 있어서, K8s 질문을 조금 하게 되었습니다 (정말 주변에 물어볼 사람이 없어서..). Helm 질문이 아니라서 답변해주시기 어려우시다면 이해하겠습니다 ㅠ
기본기적인 질문인데, Service 가 Pod 내 Container 에게 어떻게 통신을 하는지 갑자기 이해가 조금 안됩니다. 다음과 같은 시나리오 두가지가 있다고 해보겠습니다.
1. Pod 내 단일 컨테이너,
Service -> spec.ports.targetPort 에 1000 포트로 통신을 전달하도록 설정되어 있음
"Service 는 selector 로 어떤 Pod 에게 보내야할지는 이미 알고 있고, Pod 내 targetPort 로 요청을 전달한다" 라고 이해하고 있습니다.
Pod -> spec.containers.ports.containerPort 에 2000번 포트를 점유하도록 설정되어 있음
>> 이런 시나리오인 경우에도, K8s 는 통신을 정상적으로 앱에 전달하는 것으로 이해하고 있습니다. containerPort 는 사실 큰 역할을 하지 않고, 실제 container 내부 Application 이 1000 포트에 런닝 중이면 된다고 생각했습니다. ( Spring 경우 application.properties 내의 server.port=1000)
>> 결론부터 말씀드리면 이게 "왜 가능한지?" 가 궁금합니다.
2. Pod 내 멀티 컨테이너,
Service -> 위와 동일
Pod -> spec.containers 내부에 1000번 포트, 2000번 포트에 점유하는 두개의 컨테이너를 정의함 (각각 다른 앱)
(물론 권장하는 상황은 아님)
>> 이런 시나리오인 경우, 해당 Service 에 요청하면 containerPort:2000 인 컨테이너에게 요청을 전달하고, 해당 컨테이너에 점유중인 앱이 통신을 수신하는 것으로 이해했습니다.
>> 그럼 지금 1번 시나리오랑 다른 점인데, 멀티 컨테이너와 단일 컨테이너를 사용하는 Pod 간에는 어떤 차이가 존재하는건지 알 수 있을까요?
>> 그리고 이런 경우에는 1번 시나리오에서 제가 이해한 컨테이너 내부 App Port 는 어떻게 아는지? 가 궁금합니다
만약 service 내부 containerPort 가 Pod 내 컨테이너가 점유중인 port 가 아닌, container 내부의 App Port 라면, Service 는 "Selector 를 통해 어떤 Pod 로 보내야 하는지 알 뿐 아니라 어떤 Container 로 보내야 하는지도 알고있다" 가 되는데, 이건 아닌 것 같았습니다.
혹시 어렵지 않으시다면, 제가 기본기가 좀 모자라서, 도움 한번만 주시면 정말 감사할 것 같습니다.
답변 2
0
Pod의 containerPort 속성은 정보성 입니다. 그래서 이걸 설정했다고해서 컨테이너에 Port가 바인딩 되는 건 아니에요. 실제 컨테이너 내부 App에서 바인딩한 Port가 실제 수신 받을 수 있는 포트라서 Service에서 targetPort만 잘 지정해도 정상적으로 통신이 됩니다.
일단 Pod내에 두 개의 컨테이너를 띄우는 건 비권장 사항은 아닙니다. 다만 두 컨테이너가 메인 역할을 하면 안되고, 한 컨테이너가 메인이고, 다른 컨테이너는 메인 컨테이너를 보조하는 역할을 해야 되요. 그리고 그랬을 때 각각의 컨테이너가 포트를 가지고 있을 수 있습니다.
Service 자체 Port는 1000이고, targetPort도 1000으로 해놨을 때, http://service_name:1000 으로 트래픽을 날리면, Pod에도 1000으로 트래픽이 날라갈 텐데, 2000으로 전달이 된다는 말씀인가요? 그건 불가능 합니다. 아마 설정이 잘못되 있을 거예요.
그리고 컨테이너 내부에서 띄운 Port는 외부 입장에서는 알 수가 없습니다. 실제 컨테이너 안으로 들어가서 바인딩된 Port를 조회해보던가 해야되고. Pod를 만들 때 containerPort를 잘 적어놔야 되요.
일단 답변드린 내용을 토대로 한번 고민해보시고, 다시 질문주시면 답변드릴께요.
1번과 2번 시나리오에서 이해 안되는 부분이 있는데
[Service 에서 tgPort 를 1000 이라고 했고, Pod 에서 1000, 2000 컨테이너 두개가 점유중인 상황인 경우였습니다.] 와 [다만 멀티 컨테이너일 경우, containerPort 1000 인 컨테이너 1번과 containerPort 2000 인 2번 컨테이너가 Pod 에 점유중이라고 하겠습니다.]
이 다른 상태인가요?
그리고 어떤 경우라도 Pod에 ContainerPort로 인해 실제 컨테이너에 포트가 바인딩 되지는 않습니다.
Pod 안에는 여러 컨테이너는 하나의 IP를 공유합니다. 그렇기 때문에 한 컴퓨터에서 두개의 Port를 띄우면 충돌이 생기듯, 컨테이너끼리 같은 포트를 할당시키면 기동이 되면서 에러가 나요. yaml 파일 작성상으로 ContainerPort가 중복되면 정보성이라 에러가 안나지만, 실제 기능적으로 Pod 내부에 동일한 Port가 열려있으면 에러가 나서 Pod 기동이 안되거든요.
제가 1번 시나리오를 잘못달았네요. 1번 시나리오 는 Pod 에 2000 컨테이너만 점유중인 단일 컨테이너 상황입니다. (tgPort 랑 containerPort 랑 다른 상황)
Pod 안에 여러 컨테이너는 IP 를 공유하는건 알고 있었는데, 컨테이너 내부에 App Port 는 컨테이너 별로 독립적이라 두 컨테이너가 같을 수 있지 않나요? 저는 그 App Port (Spring 을 예로들면 application.properties 내의 server.port 값) 와 Service 의 targetPort 가 같으면 되는건가라는 생각이 들었습니다.
(containerPort 가 아무 의미 없는 정보성인걸 알고 헷갈리기 시작해서 문의드렸습니다)
0
안녕하세요, 인프런 AI 인턴입니다. 강우석님께서 주신 질문은 Kubernetes의 Service, Pod, 그리고 Container 간의 포트 매핑에 대한 이해를 돕기 위한 내용으로 보입니다. 비슷한 사례들을 소개하며 답변을 드리겠습니다.
- Pod 내 단일 컨테이너 포트 매핑 이해:
Kubernetes에서 Service는 클러스터 내에서 Pod를 선택하고 트래픽을 라우팅하는 역할을 합니다. Service의targetPort는 실제 어플리케이션이 수신하는 포트를 의미하며, Pod 내부의 각 컨테이너는containerPort를 통해 어떤 포트를 사용할 것인지를 결정합니다.containerPort는 주로 정보 제공 목적으로 사용됩니다. 즉, 실제로는 어플리케이션이 올바른 포트를 수신하고 있다면,containerPort지정 유무에 크게 영향을 받지 않습니다. 이는 주로 설정된 포트에서 어플리케이션이 제대로 실행되는지 체크하는 용도로 활용됩니다.
관련 답변:
- “안녕하세요 포트 관련해서 여쭤볼게 있어서 다시 질문드립니다…”
- Pod 내 멀티 컨테이너 포트 매핑:
멀티 컨테이너가 포함된 Pod의 경우, Service는 Pod 단위로 트래픽을 라우팅하며 각 컨테이너는 서로 다른 포트를 통해 통신할 수 있습니다. 여기서 각 컨테이너에 대해 별도의 포트가 지정되기 때문에, Service는 지정된 포트 기준으로 특정 컨테이너로 트래픽을 전달하게 됩니다. 다만, Service는 특정 컨테이너까지 구체적으로 지정할 수 없으며, Pod 내 모든 컨테이너들이 동일한 네트워크 네임스페이스를 공유하기 때문에 Pod의 IP와 포트로만 접근이 가능합니다.
이러한 구조에서 Service는 Pod 레벨에서 동작하며, 따라서 Pod 내부의 다중 컨테이너 간의 디렉트 포워딩은 Service 구성의 포트 설정 특성에 따라 달라질 수 있습니다.
추가로 이해를 돕기 위한 유사한 상황에 대한 설명은 다음 링크에서 확인하실 수 있습니다:
- “서비스 (NodePort) 질문 드려요.”
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다. 현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏 추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
답변주셔서 감사합니다. 1번에서 containerPort 는 단순 정보성이라는 점은 확실히 염두해두고 고민하겠습니다. 2번 같은 경우 둘다 메인 역할하는 경우를 생각하며 비권장이란 표현을 썼습니다. 그 부분은 사실 질문에 큰 목적이 있는건 아니였고, 질문 시나리오를 다시 설명하겠습니다.
1번 시나리오 -
Service 에서 tgPort 를 1000 이라고 했고, Pod 에서 1000, 2000 컨테이너 두개가 점유중인 상황인 경우였습니다.
어떻게든 트래픽은 나렸고 서비스는 수신을 이미 했고, 서비스는 자신이 담당하는 Pod 에게 tgPort 인 1000으로 보낼겁니다. 이 때 단일 컨테이너인 경우 말씀하신대로 containerPort: 2000 으로 했어도 이 정보는 단순히 정보성이니, app port 만 잘 지정했으면 트래픽이 잘 수신될겁니다.
2번 시나리오 -
다만 멀티 컨테이너일 경우, containerPort 1000 인 컨테이너 1번과 containerPort 2000 인 2번 컨테이너가 Pod 에 점유중이라고 하겠습니다.
1번이랑 똑같이 서비스가 tgPort 1000으로 트래픽을 전달하는 경우, 이 상황에서도 containerPort 대로 매핑을 해서 1번 컨테이너로 전달한다고 생각했습니다. 이런 경우면 더이상 containerPort 는 정보성이 아니게 되는걸까요?
만약 containerPort 는 이런 경우에도 아예 무시하고 App Port 대로 매핑을 해주는거라면.. 컨테이너는 내부적으로 포트가 독립적이라서 두 컨테이너에 있는 앱이 둘다 1000번 포트에 있을 수 있는거 아닌가요? 그러면 어떤 App 으로 전달할지 모를 것 같다는 의문이 생겨서 질문을 드렸습니다.