본 문서는 쿠버네티스의 공식문서(https://kubernetes.io/docs/concepts/cluster-administration/networking/)의 일부를 번역하고 링크를 정리하여 붙이는 것에서 시작한 문서입니다.
일부 링크는 정상적이지 않거나 통합되지 않아, 원 문서에서 삭제하였습니다.
일부 추가된 부분은 이해를 돕기위한 링크입니다.
* Cluster Network
네트워킹은 쿠버네티스의 중요한 부분이다 하지만 정확한 이해를 위해서는 이해하기 위한 노력이 필요하다.
여기 4개의 주소에 대한 독립적인 문제가 있다.
1. 높은 결합도의 컨테이너간 통신 : 이 문제는 pods와 localhost의 통신으로 해결된다.
2. Pod 간의 통신 : 이것이 이 문서의 주제다.
3. Pod와 서비스 간의 통신 : 이 영역은 서비스를 통해 해결한다.
4. 외부와 서비스간의 통신 : 이 영역도 서비스를 통해 해결한다.
+ 쿠버네티스 네트워크 모델
+ 구버네티스 네트워크 모델을 구현하는 법
쿠버네티스는 기계의 모든것을 응용프로그램 간에 공유한다. 일반적으로 한대의 머신을 두개의 응용플그램이 공유하려면 해당 응용프로그램이 같은 포트를 사용하지 않도록 해야한다. 여러명의 개발자가 사용하는 포트를 적절하게 조절하는 것은 매우 어렵다. 이 문제는 사용자의 영역을 벗어난 클러스터 레벨의 문제이다.
동적포트 할당은 시스템에 많은 문제를 불러온다 - 모든 응용프로그램은 사용하는 포트들을 플래그로 가져가야 하고, API 서버는 동적포트번호를 설정블럭에 집어넣는 방법을 알아야 한다. 서비스는 이들을 어떻게 찾는지 알아야 한다. 쿠버네티스는 다른 방법을 취합니다.
* 쿠버네티스 네트워크 모델
모든 Pod는 각각의 IP를 갖는다. Pod 간의 통신을 위해서 링크를 만들 필요가 없다는 것과 대부분의 경우 컨테이너와 호트스에 대한 연결을 위한 고려를 할 필요가 없다는 것을 의미한다.이렇게하면 포트 할당, 이름 지정, 서비스 검색,로드 밸런싱, 애플리케이션 구성 및 마이그레이션 측면에서 Pod를 VM 또는 물리적 호스트처럼 취급 할 수있는 명시적인 모델이 생성된다.
쿠버네티스는 모든 네트워크 구현에 다음과 같은 기본요구 사항을 적용한다.(의도적 네트워크 세분화 정책 제외)
- 노드에 있는 Pod 들은 모든 노드들과 NAT 없이 통신이 가능하다.
- 노드에 설치되어 있는 Agent()들은 해당 노드에 있는 모든 Pod들과 통신이 가능하다.
주의 : 호스트 노트에서 Pod의 실행을 지원하는 경우(ex :Linux or Mac?)
- 노드의 호스트 네트워크에있는 포드는 NAT없이 모든 노드에 있는 모든 포드와 통신 할 수 있다.
이 모델은 전체적으로 덜 복잡 할뿐만 아니라 Kubernetes가 VM에서 컨테이너로 응용 프로그램을 이행하려고 할때 유효하다. 작업이 이전에 VM에서 실행 된 경우 VM에 IP가 있고 프로젝트의 다른 VM과 통신 할 수 있다. 이것은 동일한 기본 모델이다.
Kubernetes의 IP주소는 Pod영역에 존재한다. - 컨테이너들은 Pod와 Network namespace와 IP address를 공유한다. 이는 동일 Pod에 존재하는 컨테이너들이 localhost를 통해 연결될 수 있음을 의미한다. 이는 컨테이너의 사용 Port에 대해서 Pod가 조율해야 함을 의미한다. 이것은 프로세스에 VM에서 프로세스를 관리하는 것과 다르지 않다. 이 모델을 "IP per pod"라고 부른다.
이에 대한 구현은 사용중인 컨테이너의 내부 동작의 일부이다.
노드 자체에서 포트로 전달되는 포트 (호스트 포트라고 함)를 요청할 수 있지만 이는 적당한(niche) 작업이다. 전달이 구현되는 방법은 컨테이너 런타임에처 처리한다. 포드 자체는 호스트 포트의 존재 여부를 감춘다.
* 쿠버네티스 네트워크 모델의 구현
이 네트워크 모델을 구현할 수있는 여러 가지 방법이 있다. 이 문서는 다양한 방법에 대한 철저한 연구는 아니지만 다양한 기술에 대한 소개가 되기를 희망한다.
다음 네트워킹 옵션은 알파벳순으로 정렬되어 있다. 순서는 우선 순위를 의미하지 않는다.
[ACI]
컨테이너, 가상 머신 및 베어 메탈 서버를 지원하는 통합 오버레이 및 언더 레이 SDN 솔루션을 제공한다. ACI는 ACI를위한 컨테이너 네트워킹 통합을 제공한다.
이에 대한 개요는 여기(https://www.cisco.com/c/dam/en/us/solutions/collateral/data-center-virtualization/application-centric-infrastructure/solution-overview-c22-739493.pdf)에서 제공된다.
[Apstra의 AOS]
AOS는 단순한 통합 플랫폼에서 복잡한 데이터 센터 환경을 생성하고 관리하는 인 텐트 기반 네트워킹 (Intent-Based Networking)시스템이다. AOS는 확장 성이 뛰어난 분산 설계를 활용하여 네트워크 중단을 제거하면서 비용을 최소화한다.
IBS에 대한 참조자료.
AOS Reference Design은 현재 레거시 Layer-2 스위칭 문제를 제거하는 Layer-3 연결 호스트를 지원한다. 이 Layer-3 호스트는 Linux 서버 (Debian, Ubuntu, CentOS) 일 수 있으며 맨 위 랙 스위치 (TOR)와 직접 BGP(Border Gateway Protocol) 인접 관계를 만든다. AOS는 라우팅 인접성을 자동화 한 다음 Kubernetes 배포에서 일반적으로 사용되는 RHI (Route Health Injection)에 대한 세밀한 제어를 제공한다.
BGP 관련 참조 자료.
AOS에는 Kubernetes가 애플리케이션 요구 사항에 따라 네트워크 정책을 신속하게 변경할 수있는 풍부한 REST API 엔드 포인트 세트가 있다. 네트워크 설계에 사용 된 AOS 그래프 모델을 워크로드 프로비저닝과 통합하여 프라이빗 및 퍼블릭 클라우드 모두에 대한 종단간 관리 시스템을 향상시킬 수 있다.
AOS는 Cisco, Arista, Dell, Mellanox, HPE 및 Microsoft SONiC, Dell OPX 및 Cumulus Linux와 같은 개방형 네트워크 운영 체제 및 수많은 화이트 박스 시스템을 포함한 제조업체의 일반적인 공급 업체 장비 사용을 지원한다.
자세한 AOS 시스템 동작에 대한 내용은 아래의 링크를 참조하라.
[쿠버네티스를 위한 AWS VPC CNI]
AWS VPC CNI는 Kubernetes 클러스터를위한 통합 AWS Virtual Private Cloud (VPC) 네트워킹을 제공한다. 이 CNI 플러그인은 높은 처리량 및 가용성, 낮은 대기 시간 및 최소 네트워크 지터(대기시간의 변동)를 제공한다. 또한 사용자는 Kubernetes 클러스터 구축을 위해 기존 AWS VPC 네트워킹 및 보안 모범 사례를 적용 할 수 있다. 여기에는 VPC 흐름 로그, VPC 라우팅 정책 및 네트워크 트래픽 격리를 위한 보안 그룹을 사용하는 기능이 포함된다.
이 CNI 플러그인을 사용하면 Kubernetes 포드가 VPC 네트워크에서와 동일한 포드 내부의 IP 주소를 가질 수 있다. CNI는 각 Kubernetes 노드에 노드의 포드에 대해 각 ENI의 보조 IP 범위를 사용하여 AWS Elastic Networking Interfaces (ENI)를 할당한다. CNI에는 빠른 포드 시작 시간을위한 ENI 및 IP 주소의 사전 할당 제어 기능이 포함되어 있으며 최대 2,000 개의 노드로 구성된 대규모 클러스터가 가능하다.
또한 네트워크 정책 시행을 위해 CNI를 Calico와 함께 실행할 수 있다. AWS VPC CNI 프로젝트는 GitHub에 대한 설명서가 포함 된 오픈 소스입니다.
[대용량 스위칭 네트워크에서의 대용량 패브릭(Big Cloud Fabric from Big Switch Networks)]
Big Cloud Fabric은 클라우드 네이티브 네트워킹 아키텍처로, 개인 클라우드 / 온-프레미스 환경에서 Kubernetes를 실행하도록 설계되었다. Big Cloud Fabric은 통합 된 물리적 및 가상 SDN을 사용하여로드 밸런싱, 가시성, 문제 해결, 보안 정책 및 컨테이너 트래픽 모니터링과 같은 고유 한 컨테이너 네트워킹 문제를 해결한다.
Big Cloud Fabric의 가상 포드 다중 테넌트 아키텍처(다중 고객을 완전히 분리하는 모델)를 통해 Kubernetes, RedHat OpenShift, Mesosphere DC / OS 및 Docker Swarm과 같은 컨테이너 오케스트레이션 시스템은 VMware, OpenStack & Nutanix와 같은 VM 오케스트레이션 시스템과 함께 기본적으로 통합된다. 고객은 원하는 수의 클러스터를 안전하게 상호 연결할 수 있으며 필요한 경우 이들간에 테넌트 간 통신이 가능하다.
BCF는 Gartner에 의해 최신 Magic Quadrant에서 선각자로 인식되었다.BCF Kubernetes 온-프레미스 배포 중 하나 (여러 지역에 걸쳐 여러 DC에서 실행되는 Kubernetes, DC / OS 및 VMware 포함)도 여기에서 참조된다.
[Cilium]
Cilium은 애플리케이션 컨테이너간에 네트워크 연결을 제공하고 투명하게 보호하기위한 오픈 소스 소프트웨어이다. Cilium은 L7 / HTTP를 인식하며 네트워크 주소 지정에서 분리 된 ID 기반 보안 모델을 사용하여 L3-L7에서 네트워크 정책을 시행 할 수 있다.
[화웨이의 CNI-Genie]
CNI-Genie는 Kubernetes가 런타임시 Kubernetes 네트워크 모델의 다른 구현에 동시에 액세스 할 수 있도록하는 CNI 플러그인이다. 여기에는 Flannel, Calico, Romana, Weave-net과 같은 CNI 플러그인으로 실행되는 모든 구현이 포함된다.
CNI-Genie는 각기 다른 CNI 플러그인의 포드에 여러 개의 IP 주소를 할당 할 수 있다.
[cni-ipvlan-vpc-k8s]
cni-ipvlan-vpc-k8s에는 Amazon을 사용하여 Amazon Virtual Private Cloud (VPC) 환경에서 Kubernetes를위한 간단한 호스트 로컬 저 지연 시간, 높은 처리량 및 호환 네트워킹 스택을 제공하는 CNI 및 IPAM 플러그인 세트가 포함되어 있다. L2 모드에서 Linux 커널의 IPvlan 드라이버를 사용하여 ENI (Elastic Network Interfaces) 및 AWS 관리 IP를 포드에 바인딩한다.
플러그인은 VPC 내에서 구성하고 배포 할 수 있도록 간단하게 설계되었다. Kubelets는 오버레이 네트워크 관리, BGP 관리, 소스 / 대상 검사 비활성화 또는 VPC 라우팅 테이블을 조정하여 각 호스트에 인스턴스 별 서브넷을 제공하는 등의 권장 복잡성을 요구하지 않고 필요에 따라 IP 사용량을 부팅 한 다음 자체 구성 및 확장한다. VPC 당 50-100 개 항목으로 제한). 즉, cni-ipvlan-vpc-k8s는 AWS 내에서 Kubernetes를 대규모로 배포하는 데 필요한 네트워크 복잡성을 크게 줄인다.
[Contiv]
Contiv는 다양한 사용 사례에 대해 구성 가능한 네트워킹 (BGP를 사용하는 기본 l3, vxlan을 사용하는 오버레이, 클래식 l2 또는 Cisco-SDN / ACI)을 제공합니다. Contiv는 모두 오픈소스이다.
[Contrail / Tungsten Fabric]
Tungsten Fabric을 기반으로하는 Contrail은 진정한 개방형 멀티 클라우드 네트워크 가상화 및 정책 관리 플랫폼이다. Contrail 및 Tungsten Fabric은 Kubernetes, OpenShift, OpenStack 및 Mesos와 같은 다양한 오케스트레이션 시스템과 통합되어 있으며 가상 머신, 컨테이너 / 포드 및 베어 메탈 워크로드에 대해 서로 다른 격리 모드를 제공한다.
[DANM]
DANM은 Kubernetes 클러스터에서 실행되는 통신 워크로드를위한 네트워킹 솔루션이다. 다음과 같은 구성 요소로 구성된다.
- 고급 기능으로 IPVLAN 인터페이스를 프로비저닝 할 수있는 CNI 플러그인
- 여러 클러스터 전체의 불연속 L3 네트워크를 관리하고 요청시 동적, 정적 또는 IP 할당 체계를 제공하지 않는 내장 IPAM 모듈
- 자체 CNI를 통해 또는 SRI-OV 또는 Flannel과 같은 널리 사용되는 CNI 솔루션에 작업을 동시에 위임하여 여러 네트워크 인터페이스를 컨테이너에 연결할 수있는 CNI 메타 플러그인
- 모든 Kubernetes 호스트의 VxLAN 및 VLAN 인터페이스를 중앙에서 관리 할 수있는 Kubernetes 컨트롤러
- Kubernetes의 서비스 기반 서비스 검색 개념을 확장하여 포드의 모든 네트워크 인터페이스에서 작동하는 다른 Kubernetes 컨트롤러
이 도구 세트를 통해 DANM은 여러 개의 분리 된 네트워크 인터페이스를 제공 할 수 있으며 포드에 대해 다른 네트워킹 백엔드 및 고급 IPAM 기능을 사용할 수 있다.
[Flannel]
Flannel은 Kubernetes 요구 사항을 충족하는 매우 간단한 오버레이 네트워크이다. 많은 경우 성공적으로 적용이 가능하다.
[Google Compute Engine (GCE)]
Google Compute Engine 클러스터 구성 스크립트의 경우 고급 라우팅을 사용하여 각 VM에 서브넷을 할당한다 (기본값은 / 24-254 IP). 해당 서브넷에 바인딩 된 모든 트래픽은 GCE 네트워크 패브릭에 의해 VM으로 직접 라우팅된다. 이것은 아웃 바운드 인터넷 액세스를 위해 NAT 인 VM에 할당 된 "기본"IP 주소에 추가되며. Linux 브리지 (cbr0)는 해당 서브넷에 존재하도록 구성되며 docker의 --bridge 플래그로 전달된다.
Docker를 다음과 같은 옵션으로 실행한다.
DOCKER_OPTS="--bridge=cbr0 --iptables=false --ip-masq=false"
|
이 브리지는 노드의 .spec.podCIDR에 따라 Kubelet (-network-plugin = kubenet 플래그로 제어)에 의해 생성된다.
Docker는 이제 cbr-cidr 블록에서 IP를 할당합니다. 컨테이너는 cbr0 브리지를 통해 서로 노드에 도달 할 수 있다. 이러한 IP는 모두 GCE 프로젝트 네트워크 내에서 라우팅 가능하다.
그러나 GCE 자체는 이러한 IP에 대해 전혀 알지 못하므로 아웃 바운드 인터넷 트래픽을 위해 IP를 NAT하지 않는다. iptables 규칙을 사용하여 GCE 프로젝트 네트워크 외부의 IP (10.0.0.0/8)에 바인딩 된 트래픽을 가장하는 (일명 SNAT-마치 패킷이 노드 자체에서 온 것처럼 보이도록 만들기 위해) 사용된다.
iptables -t nat -A POSTROUTING ! -d 10.0.0.0/8 -o eth0 -j MASQUERADE
|
마지막으로 커널에서 IP 전달이 활성화되어 있으므로 커널은 브리지 된 컨테이너에 대한 패킷을 처리한다.
sysctl net.ipv4.ip_forward=1
|
결과적으로 모든 포드는 각자에게 연결되고 인터넷을 통해서 트래픽을 전달할 수 있다.
[Jaguar]
Jaguar는 OpenDaylight 기반의 Kubernetes 네트워크를위한 오픈 소스 솔루션이다. Jaguar는 vxlan을 사용하여 오버레이 네트워크를 제공하고 Jaguar CNIPlugin은 포드 당 하나의 IP 주소를 제공한다.
[k-vswitch]
k-vswitch는 Open vSwitch를 기반으로하는 간단한 Kubernetes 네트워킹 플러그인이다. Open vSwitch의 기존 기능을 활용하여 작동하기 쉽고 성능이 뛰어나고 안전한 강력한 네트워킹 플러그인을 제공한다.
[Knitter]
Knitter는 Kubernetes에서 여러 네트워킹을 지원하는 네트워크 솔루션이다. 테넌트 관리 및 네트워크 관리 기능을 제공한다. Knitter에는 응용 프로그램의 IP 주소 유지, IP 주소 마이그레이션 등과 같은 여러 네트워크 계층 외에 엔드 투 엔드 NFV 컨테이너 네트워킹 솔루션 세트가 포함되어 있다.
[Kube-OVN]
Kube-OVN은 기업을위한 OVN 기반 kubernetes 네트워크 패브릭입니다. OVN / OVS의 도움으로 서브넷, QoS, 고정 IP 할당, 트래픽 미러링, 게이트웨이, 오픈 플로우 기반 네트워크 정책 및 서비스 프록시와 같은 고급 오버레이 네트워크 기능을 제공한다.
[Kube-router]
Kube-router는 Kubernetes를위한 특수 목적의 네트워킹 솔루션으로 고성능 및 운영 단순성을 제공한다. Kube-router는 Linux LVS / IPVS 기반 서비스 프록시, 오버레이가없는 Linux 커널 전달 기반 포드 대 포드 네트워킹 솔루션 및 iptables / ipset 기반 네트워크 정책 집행자를 제공한다.
[L2네트워크와 리눅스 브리징]
"베어 메탈"환경의 간단한 스위치와 같은 "dumb"L2 네트워크가있는 경우 위의 GCE 설정과 유사한 작업을 수행 할 수 있어야한다. 이 지침은 매우 우연히 시도되었지만 작동하는 것으로 보이지만 철저히 테스트되지 않았다. 이 기술을 사용하여 프로세스를 완료 한 경우 알려주십시오. 이에 대한 훌륭한 튜토리얼이 있습니다. 항목에서 "리눅스 브릿지 장치들"을 참고 하세요.
[Mutlus(다중 네트워크 플러그인)]
Multus는 Kubernetes의 CRD 기반 네트워크 객체를 사용하여 Kubernetes의 멀티 네트워킹 기능을 지원하는 멀티 CNI 플러그인이다.
Multus는 CNI 사양을 구현하는 모든 참조 플러그인 (예 : Flannel, DHCP, Macvlan) 및 타사 플러그인 (예 : Calico, Weave, Cilium, Contiv)을 지원하며, Multus는 Kubernetes의 클라우드 네이티브 및 NFV 기반 응용 프로그램과 함께 Kubernetes의 SRIOV, DPDK, OVS-DPDK 및 VPP 워크로드를 지원한다.
[NSX-T]
VMware NSX-T는 네트워크 가상화 및 보안 플랫폼이다. NSX-T는 다중 클라우드 및 다중 하이퍼 바이저 환경에 네트워크 가상화를 제공 할 수 있으며 이기종 엔드 포인트 및 기술 스택이있는 새로운 애플리케이션 프레임 워크 및 아키텍처에 중점을 둔다. 이러한 환경에는 vSphere 하이퍼 바이저 외에도 KVM, 컨테이너 및 베어 메탈과 같은 다른 하이퍼 바이저가 포함된다.
NSX-T Container Plug-in (NCP)은 NSX-T와 Kubernetes와 같은 컨테이너 오케 스트레이터 간의 통합뿐만 아니라 NSX-T와 PKS (Pivotal Container Service) 및 OpenShift와 같은 컨테이너 기반 CaaS / PaaS 플랫폼 간의 통합을 제공합니다.
Plugin Document는 여기(
서 확인할 수 있다.
[Nuage Networks VCS (Virtualized Cloud Services)]
Nuage(https://www.nuagenetworks.net)는 확장 성이 뛰어난 정책 기반 SDN (Software-Defined Networking) 플랫폼을 제공한다. Nuage는 개방형 표준을 기반으로하는 풍부한 기능의 SDN 컨트롤러와 함께 데이터 플레인 용 오픈 소스 Open vSwitch를 사용한다.
Nuage 플랫폼은 오버레이를 사용하여 Kubernetes Pod와 비 Kubernetes 환경 (VM 및 베어 메탈 서버)간에 완벽한 정책 기반 네트워킹을 제공하며, Nuage의 정책 추상화 모델은 애플리케이션을 염두에두고 설계되었으며 애플리케이션에 대한 세분화 된 정책을 쉽게 선언 할 수 있게 한다. 플랫폼의 실시간 분석 엔진을 통해 Kubernetes 애플리케이션에 대한 가시성과 보안 모니터링이 가능하다.
[OpenVSwitch]
OpenVSwitch는 다소 발달된 오버레이 네트워크를 구축하는 복잡한 방법으로, 이것은 네트워킹 영역의 몇몇 “Big Shop- 대형 벤더를 의미” 에 의해 승인되었다.
[OVN (Open Virtual Networking)]
OVN은 Open vSwitch 커뮤니티에서 개발 한 오픈 소스 네트워크 가상화 솔루션이다. 논리적 스위치, 논리적 라우터, 상태 저장 ACL,로드 밸런서 등을 만들어 서로 다른 가상 네트워킹 토폴로지를 구축 할 수 있다. 이 프로젝트에는 ovn-kubernetes에 특정 Kubernetes 플러그인 및 설명서가 있다.
[Project Calico]
Project Calico는 오픈 소스 컨테이너 네트워킹 공급자 및 네트워크 정책 엔진이다.
Calico는 Linux (오픈 소스) 및 Windows (독점-Tigera에서 사용 가능)에 대해 인터넷과 동일한 IP 네트워킹 원칙을 기반으로 Kubernetes 포드를 연결하기위한 확장 성이 뛰어난 네트워킹 및 네트워크 정책 솔루션을 제공한다. Calico는 캡슐화 또는 오버레이없이 구축되어 고성능의 대규모 데이터 센터 네트워킹을 제공 할 수 있다. 또한 Calico는 분산 방화벽을 통해 Kubernetes 포드에 대해 세분화 된 의도 기반 네트워크 보안 정책을 제공한다.
Calico는 Flannel, 일명 운하(aka canal - 문서가 project calico로 이행되었다.) 또는 기본 GCE, AWS 또는 Azure 네트워킹과 같은 다른 네트워킹 솔루션과 함께 정책 시행 모드로 실행될 수도 있다.
[Romana]
Romana는 오버레이 네트워크없이 Kubernetes를 배포 할 수있는 오픈 소스 네트워크 및 보안 자동화 솔루션이다. Romana는 Kubernetes 네트워크 정책을 지원하여 네트워크 네임 스페이스에서 격리를 제공한다.
[Waveworks의 Weave Net]
Weave Net은 Kubernetes 및 호스팅 응용 프로그램에 탄력적이고 사용하기 쉬운 네트워크이다. Weave Net은 CNI 플러그인 또는 독립형으로 실행된다. 두 버전 모두 실행하기 위해 구성이나 추가 코드가 필요하지 않으며 두 경우 모두 Kubernetes의 표준과 같이 네트워크에서 포드 당 하나의 IP 주소를 제공한다.
댓글 없음:
댓글 쓰기
참고: 블로그의 회원만 댓글을 작성할 수 있습니다.