46 lines
2.8 KiB
Markdown
46 lines
2.8 KiB
Markdown
---
|
|
# reviewers:
|
|
# - thockin
|
|
title: 클러스터 네트워킹
|
|
content_type: concept
|
|
weight: 50
|
|
---
|
|
|
|
<!-- overview -->
|
|
네트워킹은 쿠버네티스의 중심적인 부분이지만, 어떻게 작동하는지 정확하게
|
|
이해하기가 어려울 수 있다. 쿠버네티스에는 4가지 대응해야 할 네트워킹
|
|
문제가 있다.
|
|
|
|
1. 고도로 결합된 컨테이너 간의 통신: 이 문제는
|
|
{{< glossary_tooltip text="파드" term_id="pod" >}}와 `localhost` 통신으로 해결된다.
|
|
2. 파드 간 통신: 이 문제가 이 문서의 주요 초점이다.
|
|
3. 파드와 서비스 간 통신: 이 문제는 [서비스](/ko/docs/concepts/services-networking/service/)에서 다룬다.
|
|
4. 외부와 서비스 간 통신: 이 문제도 서비스에서 다룬다.
|
|
|
|
<!-- body -->
|
|
|
|
쿠버네티스는 애플리케이션 간에 머신을 공유하는 것이다. 일반적으로,
|
|
머신을 공유하려면 두 애플리케이션이 동일한 포트를 사용하지 않도록
|
|
해야 한다. 여러 개발자 간에 포트를 조정하는 것은 대규모로 실시하기가 매우 어렵고,
|
|
사용자가 통제할 수 없는 클러스터 수준의 문제에 노출된다.
|
|
|
|
동적 포트 할당은 시스템에 많은 복잡성을 야기한다. 모든
|
|
애플리케이션은 포트를 플래그로 가져와야 하며, API 서버는 동적 포트 번호를
|
|
구성 블록에 삽입하는 방법을 알아야 하고, 서비스는 서로를
|
|
찾는 방법 등을 알아야 한다. 쿠버네티스는 이런 것들을 다루는 대신
|
|
다른 접근법을 취한다.
|
|
|
|
쿠버네티스 네트워킹 모델에 대한 상세 정보는 [여기](/ko/docs/concepts/services-networking/)를 참고한다.
|
|
|
|
## 쿠버네티스 네트워크 모델의 구현 방법
|
|
|
|
네트워크 모델은 각 노드의 컨테이너 런타임에 의해 구현된다. 가장 일반적인 컨테이너 런타임은 [컨테이너 네트워크 인터페이스](https://github.com/containernetworking/cni)(CNI) 플러그인을 사용하여 네트워크 및 보안 기능을 관리한다. 여러 공급 업체의 다양한 CNI 플러그인이 존재하며, 이들 중 일부는 네트워크 인터페이스를 추가 및 제거하는 기본 기능만 제공하는 반면, 다른 일부는 다른 컨테이너 오케스트레이션 시스템과의 통합, 여러 CNI 플러그인 실행, 고급 IPAM 기능 등과 같은 보다 정교한 솔루션을 제공한다.
|
|
|
|
쿠버네티스에서 지원하는 네트워킹 애드온의 일부 목록은 [이 페이지](/ko/docs/concepts/cluster-administration/addons/#network-and-networking-policy)를 참조한다.
|
|
|
|
## {{% heading "whatsnext" %}}
|
|
|
|
네트워크 모델의 초기 설계와 그 근거 및 미래의 계획은
|
|
[네트워킹 디자인 문서](https://git.k8s.io/design-proposals-archive/network/networking.md)에
|
|
자세히 설명되어 있다.
|