# 서비스, 로드밸런싱, 네트워킹 > 쿠버네티스의 네트워킹에 대한 개념과 리소스에 대해 설명한다. --- LLMS index: [llms.txt](/llms.txt) --- ## 쿠버네티스 네트워크 모델 클러스터의 모든 [`파드`](/ko/docs/concepts/workloads/pods/)는 고유한 IP 주소를 갖는다. 이는 즉 `파드`간 연결을 명시적으로 만들 필요가 없으며 또한 컨테이너 포트를 호스트 포트에 매핑할 필요가 거의 없음을 의미한다. 이로 인해 포트 할당, 네이밍, 서비스 디스커버리, [로드 밸런싱](/ko/docs/concepts/services-networking/ingress/#load-balancing), 애플리케이션 구성, 마이그레이션 관점에서 `파드`를 VM 또는 물리 호스트처럼 다룰 수 있는 깔끔하고 하위 호환성을 갖는 모델이 제시된다. 쿠버네티스는 모든 네트워킹 구현에 대해 다음과 같은 근본적인 요구사항을 만족할 것을 요구한다. (이를 통해, 의도적인 네트워크 분할 정책을 방지) * 파드는 NAT 없이 [노드](/ko/docs/concepts/architecture/nodes/) 상의 모든 파드와 통신할 수 있다. * 노드 상의 에이전트(예: 시스템 데몬, 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/) API를 사용하면 [파드에서 실행 중인 애플리케이션을 클러스터 외부에서 접근](/ko/docs/tutorials/services/connect-applications-service/) 할 수 있다. - [인그레스](/ko/docs/concepts/services-networking/ingress/)는 특히 HTTP 애플리케이션, 웹사이트 그리고 API를 노출하기 위한 추가 기능을 제공한다. - 또한 서비스를 사용하여 [서비스를 클러스터 내부에서만 사용할 수 있도록 게시](/ko/docs/concepts/services-networking/service-traffic-policy/)할 수 있다. - [서비스와 애플리케이션 연결하기](/ko/docs/tutorials/services/connect-applications-service/) 튜토리얼에서는 실습 예제를 통해 서비스와 쿠버네티스 네트워킹에 대해 배울 수 있다. [클러스터 네트워킹](/ko/docs/concepts/cluster-administration/networking/)은 클러스터에 네트워킹을 설정하는 방법과 관련된 기술에 대한 개요도 제공한다. --- Section pages: - [서비스](/ko/docs/concepts/services-networking/service/): 외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며, 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다. - [인그레스(Ingress)](/ko/docs/concepts/services-networking/ingress/): URI, 호스트네임, 경로 등과 같은 웹 개념을 이해하는 프로토콜-인지형(protocol-aware configuration) 설정 메커니즘을 이용하여 HTTP (혹은 HTTPS) 네트워크 서비스를 사용 가능하게 한다. 인그레스 개념은 쿠버네티스 API를 통해 정의한 규칙에 기반하여 트래픽을 다른 백엔드에 매핑할 수 있게 해준다. - [인그레스 컨트롤러](/ko/docs/concepts/services-networking/ingress-controllers/): 클러스터에서 [인그레스](/docs/concepts/services-networking/ingress/)가 동작하려면 인그레스 컨트롤러가 실행 중이어야 한다. 적어도 하나의 인그레스 컨트롤러를 선택하고 이를 클러스터 내에 설정해야 한다. 이 페이지는 배포할 수 있는 일반적인 인그레스 컨트롤러를 나열한다. - [게이트웨이 API](/ko/docs/concepts/services-networking/gateway/): 게이트웨이 API는 동적 인프라 프로비저닝과 고급 트래픽 라우팅을 제공하는 API 종류들의 모음이다. - [엔드포인트슬라이스](/ko/docs/concepts/services-networking/endpoint-slices/): 엔드포인트슬라이스 API는 서비스가 대규모 백엔드를 처리할 수 있도록 확장할 수 있게 해주고, 클러스터가 정상적인 백엔드의 리스트를 효율적으로 업데이트 할 수 있도록 쿠버네티스가 사용하는 메커니즘이다. - [네트워크 정책](/ko/docs/concepts/services-networking/network-policies/): IP 주소 또는 포트 수준(OSI 계층 3 또는 4)에서 트래픽 흐름을 제어하려는 경우, 네트워크 정책은 클러스터 내의 트래픽 흐름뿐만 아니라 파드와 외부 간의 규칙을 정의할 수 있도록 해준다. 클러스터는 반드시 네트워크 정책을 지원하는 네트워크 플러그인을 사용해야 한다. - [서비스 및 파드용 DNS](/ko/docs/concepts/services-networking/dns-pod-service/): 워크로드는 DNS를 사용하여 클러스터 내의 서비스들을 발견할 수 있다; 이 페이지는 이것이 어떻게 동작하는지를 설명한다. - [IPv4/IPv6 이중 스택](/ko/docs/concepts/services-networking/dual-stack/): 쿠버네티스는 단일 스택 IPv4 네트워킹, 단일 스택 IPv6 네트워킹 혹은 두 네트워크 패밀리를 활성화한 이중 스택 네트워킹 설정할 수 있도록 해준다. 이 페이지는 이 방법을 설명한다. - [토폴로지 인지 힌트](/ko/docs/concepts/services-networking/topology-aware-hints/): _토폴로지 인지 힌트_ 는 트래픽이 발생한 존 내에서 네트워크 트래픽을 유지하도록 처리하는 메커니즘을 제공한다. 클러스터의 파드간 동일한 존의 트래픽을 선호하는 것은 안전성, 성능(네트워크 지연 및 처리량) 혹은 비용 측면에 도움이 될 수 있다. - [윈도우에서의 네트워킹](/ko/docs/concepts/services-networking/windows-networking/) - [서비스 내부 트래픽 정책](/ko/docs/concepts/services-networking/service-traffic-policy/): 클러스터 내의 두 파드가 통신을 하려고 하고 두 파드가 동일한 노드에서 실행되는 경우, _서비스 내부 트래픽 정책_을 사용하여 네트워크 트래픽을 해당 노드 안에서 유지할 수 있다. 클러스터 네트워크를 통한 왕복 이동을 피하면 안전성, 성능 (네트워크 지연 및 처리량) 혹은 비용 측면에 도움이 될 수 있다. - [서비스 클러스터IP 할당](/ko/docs/concepts/services-networking/cluster-ip-allocation/) - [토폴로지 키를 사용하여 토폴로지-인지 트래픽 라우팅](/ko/docs/concepts/services-networking/service-topology/)