---
title: "서비스, 로드밸런싱, 네트워킹"
weight: 60
description: >
  쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다.
---

## 쿠버네티스 네트워크 모델

모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 
이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며 
또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 
이로 인해 포트 할당, 네이밍, 서비스 디스커버리, 
[로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing), 
애플리케이션 구성, 마이그레이션 관점에서 `파드`를 
VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다.

쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다 
(이로 인해 모든 의도적인 네트워크 분할 정책이 방지된다)

   * [노드](/ko/docs/concepts/architecture/nodes/) 상의 파드가 NAT 없이 모든 노드의 모든 파드와 통신할 수 있다
   * 노드 상의 에이전트(예: 시스템 데몬, kubelet)가 해당 노드의 모든 
     파드와 통신할 수 있다

참고: `파드`를 호스트 네트워크에서 구동하는 것도 지원하는 플랫폼(예: 리눅스)에 대해서는 
다음의 요구사항도 존재한다.

   * 한 노드의 호스트 네트워크에 있는 파드는 
     NAT 없이 모든 노드의 모든 파드와 통신할 수 있다

이 모델은 전반적으로 덜 복잡할 뿐만 아니라, 
무엇보다도 VM에 있던 앱을 컨테이너로 손쉽게 포팅하려는 쿠버네티스 요구사항을 만족시킬 수 있다. 
작업을 기존에는 VM에서 실행했었다면, VM은 IP주소를 가지며 프로젝트 내의 다른 VM과 통신할 수 있었을 것이다. 
이는 동일한 기본 모델이다.

쿠버네티스 IP 주소는 `파드` 범주에 존재하며, 
`파드` 내의 컨테이너들은 IP 주소, MAC 주소를 포함하는 네트워크 네임스페이스를 공유한다. 
이는 곧 `파드` 내의 컨테이너들이 각자의 포트에 `localhost`로 접근할 수 있음을 의미한다. 
또한 `파드` 내의 컨테이너들이 포트 사용에 있어 서로 협조해야 하는데, 
이는 VM 내 프로세스 간에도 마찬가지이다. 
이러한 모델은 "파드 별 IP" 모델로 불린다.

이것이 어떻게 구현되는지는 사용하는 컨테이너 런타임의 상세사항이다.

`노드` 자체의 포트를 `파드`로 포워드하도록 요청하는 것도 가능하지만(호스트 포트라고 불림), 
이는 매우 비주류적인(niche) 동작이다. 
포워딩이 어떻게 구현되는지도 컨테이너 런타임의 상세사항이다. 
`파드` 자체는 호스트 포트 존재 유무를 인지할 수 없다.

쿠버네티스 네트워킹은 다음의 네 가지 문제를 해결한다.
- 파드 내의 컨테이너는 루프백(loopback)을 통한 [네트워킹을 사용하여 통신](/ko/docs/concepts/services-networking/dns-pod-service/)한다.
- 클러스터 네트워킹은 서로 다른 파드 간의 통신을 제공한다.
- [서비스 리소스](/ko/docs/concepts/services-networking/service/)를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/concepts/services-networking/connect-applications-service/)할 수 있다.
- 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다.