클러스터 아키텍처
Google Distributed Cloud (GDC) 에어 갭 적용 어플라이언스는 조직 인프라 클러스터라고 하는 세 개의 베어메탈 노드를 모두 포함하는 단일 클러스터를 운영합니다. 클러스터에서 포드 워크로드로 실행되는 전용 관리 API 서버는 관리 플레인 API를 호스팅합니다. 이 클러스터에서 VM과 Kubernetes 포드를 모두 포함하는 사용자 워크로드를 실행할 수 있습니다. 이 클러스터 모델에는 사용자 클러스터가 없습니다.
네트워크 아키텍처
EL8000에는 기기 내부에 4개의 별도 레이어 2 (L2) 네트워크를 만드는 백플레인이 포함되어 있습니다.
- Integrated Lights-Out (iLO) 콘솔 (1GbEth)
- 관리 네트워크 (1GbEth)
- 데이터 네트워크 A (10GbEth)
- 데이터 네트워크 B (10GbEth)
다음 다이어그램은 L2 네트워크가 Mellanox 스위치 (https://www.hpe.com/psnow/doc/a00043975enw.html?jumpid=in_pdp-psnow-qs)에 연결되는 방식을 보여줍니다. 블레이드의 각 네트워크는 단일 네트워크 스위치에 연결됩니다. 각 서버 블레이드의 모든 iLO 콘솔 네트워크는 네트워크 스위치 1에 연결됩니다. 관리 네트워크는 네트워크 스위치 2에 연결되고 데이터 네트워크는 스위치 3과 4에 연결됩니다.
고객 네트워크 포트 (15 및 17)는 클러스터 (VLAN 100)에 액세스할 수 있으며 인그레스 CIDR로의 트래픽만 허용됩니다. 수신 CIDR은 서비스에 사용할 수 있으며 범위는 경계 게이트웨이 프로토콜 (BGP)을 통해 고객 네트워크에 공지됩니다.
관리 네트워크 포트 (16 및 18)는 시스템 관리 (VLAN 501)에 액세스할 수 있으므로 고객은 더 넓은 네트워크에서 기기를 사용하고 로컬 연결만 사용하여 시스템 관리 작업을 실행할 수 있습니다.
하위 네트워크 토폴로지
물리적 네트워크
GDC는 단일 테넌트 모드로 작동하는 하이브리드 클러스터로 구성됩니다. 인프라 클러스터라고 하는 하이브리드 클러스터는 시스템 클러스터와 관리자 클러스터가 병합된 클러스터입니다.
물리적 설계는 어플라이언스 인프라 클러스터와 외부 고객 네트워크 간의 게이트웨이 역할을 하는 Mellanox SN2010을 중심으로 합니다.
인프라 클러스터는 베어메탈 노드 (BM) 3개로 구성됩니다. BM의 연결은 다음과 같이 분류할 수 있습니다.
- VLAN 100을 통한 데이터 네트워크 연결 (서브넷 198.18.2.0/24)
BM에는 본딩되어 TOR 스위치에 연결된 포트가 2개(
NIC0P1및NIC0P2)인 NIC가 있습니다.BM1및BM2은 스위치에 직접 연결되는 반면BM3은 관리되지 않는 스위치를 사용하여 TOR에 연결됩니다. - 관리 네트워크 연결 ( 서브넷 198.18..0/24)은 VLAN 501을 통해 이루어집니다. ILO 및 MGMT 인터페이스는 1G 인터페이스를 사용하여 이 VLAN을 통해 연결됩니다. BM 노드의 ILO 인터페이스와 MGMT 인터페이스는 관리되지 않는 스위치를 사용하여 스위치에 연결됩니다.
- 가능성: VLAN 200~203, 서브넷 198.18.1.x에 OTS 네트워킹 추가
Mellanox 스위치에서 고객 라우터로의 연결은 외부 연결을 제공합니다. 이 연결에는 10G 인터페이스가 사용되며 BGP 프로토콜은 고객에게 외부 네트워크 IP를 공지하는 데 사용됩니다. 고객은 외부 IP를 사용하여 어플라이언스 장치에서 제공하는 필수 서비스에 액세스합니다.
논리 네트워크
다양한 트래픽을 분리하는 두 개의 가상 근거리 통신망 (VLAN)이 있습니다.
- VLAN 100: 고객이 제공한 IPv4 서브넷이 있는 클러스터 (인그레스 가상 인터넷 프로토콜 주소 (VIP), 클러스터/노드 IP)
- VLAN 501: 고객이 제공한 IPv4 서브넷을 사용하는 관리 (iLO, Mgmt)
상위 네트워크 토폴로지
클러스터는 계층 2 (L2) 부하 분산을 사용하여 구성됩니다. 클러스터의 인그레스 VIP는 노드와 동일한 서브넷에서 가져옵니다. 인그레스 VIP가 노드에 할당되면 노드는 주소 결정 프로토콜 (ARP)을 사용하여 TOR에서 노드에 연결할 수 있도록 합니다.
BGP를 사용하여 고객 네트워크와 피어링하고 클러스터의 인그레스 범위 (고객이 제공한 집계된 프리픽스)를 고객 네트워크에 공지합니다. 랙이 새 위치로 이동하면 클러스터 인그레스 범위를 새 고객 네트워크에 광고할 수 있습니다. 랙이 새 위치로 이동하면 고객 네트워크에 연결된 TOR 인터페이스의 IP 주소를 수동으로 업데이트하고 BGP 피어링 정보를 업데이트하여 새 BGP 피어를 추가해야 합니다.
클러스터에서 사용되는 모든 IP는 랙의 externalCidrBlock에서 할당되거나 하드코딩됩니다 (클러스터 내부 IP의 경우). 다음 다이어그램에서 externalCidrBlock 예는 10.0.0.0/24입니다.
클러스터 IP 범위
베어메탈 클러스터에서 구성해야 하는 IP 범위가 여러 개 있습니다.
- 포드 CIDR: 클러스터의 포드에 IP를 할당하는 데 사용되는 IP 범위입니다. 이 범위는 섬 모드를 사용하므로 물리적 네트워크 (ToR)가 포드 CIDR을 알 필요가 없습니다. 유일한 요구사항은 범위가 클러스터 포드가 액세스해야 하는 서비스와 겹치지 않아야 한다는 것입니다. 클러스터를 만든 후에는 포드 CIDR을 변경할 수 없습니다.
- 서비스 CIDR: 포드 CIDR과 동일한 요구사항을 사용하여 내부 클러스터 서비스에 사용됩니다.
- 노드 CIDR: Kubernetes 클러스터 노드의 IP 주소입니다. 클러스터를 만든 후에는 이러한 주소도 변경할 수 없습니다.
- 인그레스 범위: 외부로 노출된 클러스터의 서비스에 사용되는 IP 주소 범위입니다. 외부 클라이언트는 이러한 IP를 사용하여 클러스터 내 서비스에 액세스합니다. 클라이언트가 인그레스 IP에 도달할 수 있도록 이 범위가 고객 네트워크에 공지되어야 합니다.
- 컨트롤 플레인 VIP: Kubernetes
api-server에 액세스하기 위해 클러스터에서 공지합니다 (인그레스 VIP와 유사). 클러스터가 L2 부하 분산 모드에 있는 경우 이 VIP는 노드와 동일한 서브넷에 있어야 합니다.
클러스터의 포드 CIDR과 서비스 CIDR이 하드코딩됩니다.
포드 CIDR은 192.168.0.0/16이고 서비스 CIDR은 10.96.0.0/12입니다. 이러한 IP는 클러스터 외부에 노출되지 않으므로 클러스터는 동일한 두 CIDR을 사용합니다.
노드는 GDC cell.yaml에 설정된 externalCidrBlock의 IP 주소로 프로비저닝됩니다. 이러한 IP 주소는 랙이 프로비저닝되기 전에 고객이 제공합니다.
클러스터의 인그레스 범위와 컨트롤 플레인 VIP도 externalCidrBlock에서 할당됩니다. TOR는 이러한 VIP가 랙 외부의 클라이언트에서 액세스할 수 있도록 고객 네트워크에 externalCidrBlock를 공지해야 합니다.