이 문서에서는 kubeception을 사용하는 사용자 클러스터가 포함된 Google Distributed Cloud 설치를 위해 IP 주소를 계획하는 방법을 보여줍니다.
kubeception이란 무엇인가요?
kubeception은 Kubernetes 클러스터를 사용하여 다른 Kubernetes 클러스터를 만들고 관리하는 아이디어를 나타내는 용어입니다. Google Distributed Cloud의 맥락에서 kubeception은 사용자 클러스터의 제어 영역이 관리자 클러스터의 하나 이상의 노드에서 실행되는 경우를 나타냅니다.
kubeception은 사용하지 않는 것이 좋습니다. 대신 Controlplane V2를 사용하는 것을 권장합니다. Controlplane V2를 사용하면 사용자 클러스터의 제어 영역 노드는 사용자 클러스터 자체에 있습니다.
시작하기 전에
Google Distributed Cloud 개요 및 설치 개요를 읽어보세요.
IP 주소 할당의 예시
이 섹션에서는 다음 요소를 포함하는 설치에 고정 IP 주소를 할당하는 방법의 예시를 보여드립니다.
관리자 워크스테이션
관리자 클러스터
워커 노드가 5개인 고가용성(HA) 사용자 클러스터 1개
워커 노드가 4개인 HA가 아닌 사용자 클러스터 1개
관리자 클러스터 노드
관리자 클러스터에는 7개의 노드가 있습니다.
- 관리자 클러스터의 제어 영역을 실행하는 노드 1개
- 관리자 클러스터에 대한 부가기능을 실행하는 노드 2개
- HA 사용자 클러스터의 제어 영역을 실행하는 노드 3개
- HA가 아닌 사용자 클러스터의 제어 영역을 실행하는 노드 1개
부하 분산
이 예시에서는 클러스터가 MetalLB 부하 분산기를 사용한다고 가정합니다. 이 부하 분산기는 클러스터 노드에서 실행되므로 부하 분산에 추가 VM이 필요하지 않습니다.
서브넷
이 예시에서는 각 클러스터가 자체 VLAN에 있고 클러스터가 다음 서브넷에 있다고 가정합니다.
| VM | 서브넷 | 기본 게이트웨이 |
|---|---|---|
| 관리자 워크스테이션 및 관리자 클러스터 | 172.16.20.0/24 | 172.16.20.1 |
| 사용자 클러스터 1 | 172.16.21.0/24 | 172.16.21.1 |
| 사용자 클러스터 2 | 172.16.22.0/24 | 172.16.22.1 |
다음 3개의 VLAN과 서브넷을 보여주는 다이어그램입니다. VIP는 클러스터의 특정 노드와 연결된 것으로 표시되지 않습니다. 이는 MetalLB 부하 분산기가 개별 서비스의 VIP를 공지하는 노드를 선택할 수 있기 때문입니다. 예를 들어 사용자 클러스터 1에서 한 워커 노드는 172.16.21.31을, 다른 워커 노드는 172.16.21.32를 공지할 수 있습니다.
IP 주소 예시: 관리자 워크스테이션
이 예시에서 관리자 워크스테이션은 관리자 클러스터(172.16.20.0/24)와 동일한 서브넷에 위치합니다. 노드 주소에 가까운 주소는 관리자 워크스테이션에 적합합니다. 예를 들어 172.16.20.20 같은 주소가 해당합니다.
IP 주소 예시: 관리자 클러스터 노드
노드가 7개인 관리자 클러스터의 경우 IP 주소 8개를 따로 설정해야 합니다. 클러스터 업그레이드, 업데이트, 자동 복구 중에 필요하기 때문에 추가 주소가 필요합니다. 예를 들어 관리자 클러스터의 노드에 다음 IP 주소를 따로 설정할 수 있습니다.
| 관리자 클러스터의 노드 IP 주소 |
|---|
| 172.16.20.2 - 172.16.20.9 |
IP 주소 예시: 관리자 클러스터 서브넷의 VIP
다음 표에서는 관리자 클러스터의 부하 분산기에서 구성할 VIP를 지정하는 방법의 예시를 보여줍니다. 사용자 클러스터의 Kubernetes API 서버에 대한 VIP는 관리자 클러스터 서브넷에 있어야 합니다. 이 예시에서 사용자 클러스터의 Kubernetes API 서버가 관리자 클러스터의 노드에서 실행되기 때문입니다. 클러스터 구성 파일에서 Kubernetes API 서버의 VIP를 지정하는 필드를 controlPlaneVIP라고 합니다.
| VIP | IP 주소 |
|---|---|
| 관리자 클러스터의 Kubernetes API 서버의 VIP | 172.16.20.30 |
| 관리자 클러스터 부가기능 VIP | 172.16.20.31 |
| 사용자 클러스터 1의 Kubernetes API 서버의 VIP | 172.16.20.32 |
| 사용자 클러스터 2의 Kubernetes API 서버의 VIP | 172.16.20.33 |
IP 주소 예시: 사용자 클러스터 1 노드
노드가 5개인 사용자 클러스터의 경우 IP 주소를 6개 따로 설정해야 합니다. 클러스터 업그레이드, 업데이트, 자동 복구 중에 필요하기 때문에 추가 주소가 필요합니다. 예를 들어 사용자 클러스터 1의 노드에 다음 IP 주소를 따로 설정할 수 있습니다.
| 사용자 클러스터 1의 노드 IP 주소 |
|---|
| 172.16.21.2 - 172.16.21.7 |
IP 주소 예시: 사용자 클러스터 1 서브넷의 VIP
다음 표에서는 사용자 클러스터 1의 부하 분산기에서 구성할 VIP를 지정하는 방법의 예시를 보여줍니다.
| VIP | 설명 | IP 주소 |
|---|---|---|
| 사용자 클러스터 1의 인그레스 VIP | 사용자 클러스터 1의 부하 분산기에서 구성됨 | 172.16.21.30 |
| 사용자 클러스터 1의 서비스 VIP | LoadBalancer 유형의 서비스에 대한 10개 주소입니다.필요에 따라 사용자 클러스터 1의 부하 분산기에서 구성됩니다. 이 범위에는 인그레스 VIP가 포함됩니다. MetalLB 부하 분산기의 요구사항입니다. |
172.16.21.30 - 172.16.21.39 |
IP 주소 예시: 사용자 클러스터 2 노드
노드가 4개 있는 사용자 클러스터의 경우 IP 주소 5개를 따로 설정해야 합니다. 클러스터 업그레이드, 업데이트, 자동 복구 중에 필요하기 때문에 추가 주소가 필요합니다. 예를 들어 사용자 클러스터 2의 노드에 다음 IP 주소를 따로 설정할 수 있습니다.
| 사용자 클러스터 2의 노드 IP 주소 |
|---|
| 172.16.22.2 - 172.16.22.6 |
IP 주소 예시: 사용자 클러스터 2 서브넷의 VIP
다음 테이블에서는 사용자 클러스터 2의 부하 분산기에서 구성할 VIP를 지정하는 방법의 예시를 보여줍니다.
| VIP | 설명 | IP 주소 |
|---|---|---|
| 사용자 클러스터 2의 인그레스 VIP | 사용자 클러스터 2의 부하 분산기에서 구성됨 | 172.16.22.30 |
| 사용자 클러스터 2의 서비스 VIP | LoadBalancer 유형의 서비스에 대한 10개 주소입니다.필요에 따라 사용자 클러스터 2의 부하 분산기에서 구성됩니다. 이 범위에는 인그레스 VIP가 포함됩니다. MetalLB 부하 분산기의 요구사항입니다. |
172.16.22.30 - 172.16.22.39 |
IP 주소 예시: 포드 및 서비스
클러스터를 만들기 전에 포드 IP 주소에 사용할 CIDR 범위와 Kubernetes 서비스의 ClusterIP 주소에 사용할 또 다른 CIDR 범위를 지정해야 합니다.
포드 및 서비스에 사용할 CIDR 범위를 결정합니다. 예를 들면 다음과 같습니다.
| 목적 | CIDR 범위 |
|---|---|
| 관리자 클러스터의 포드 | 192.168.0.0/16 |
| 사용자 클러스터 1의 포드 | 192.168.0.0/16 |
| 사용자 클러스터 2의 포드 | 192.168.0.0/16 |
| 관리자 클러스터의 서비스 | 10.96.232.0/24 |
| 사용자 클러스터 1의 서비스 | 10.96.0.0/20 |
| 사용자 클러스터 2의 서비스 | 10.96.128.0/20 |
앞의 예시는 다음과 같은 사항을 보여줍니다.
포드 CIDR 범위는 여러 클러스터에서 동일할 수 있습니다.
일반적으로 서비스보다 더 많은 포드가 필요하므로 특정 클러스터의 경우 서비스 CIDR 범위보다 큰 포드 CIDR 범위가 필요할 수 있습니다. 사용자 클러스터의 예시 포드 범위는 192.168.0.0/16이고, 여기에는 2^(32-16) = 2^16개의 주소가 있습니다. 하지만 사용자 클러스터의 예시 서비스 범위는 10.96.0.0/20이며, 여기에는 주소가 2^(32-20) = 2^12개만 있습니다.
겹침 방지
네트워크에서 연결할 수 있는 IP 주소와 겹치지 않도록 기본이 아닌 CIDR 범위를 사용하는 것이 좋습니다. 서비스 범위와 포드 범위는 클러스터 내부에서 연결하려는 클러스터 외부의 주소와 겹치지 않아야 합니다.
예를 들어 서비스 범위가 10.96.232.0/24이고 포드 범위가 192.168.0.0/16 (192.168.0.1 - 192.168.255.254)이라고 가정해 보겠습니다. 포드에서 이러한 범위 중 하나의 주소로 전송되는 트래픽은 클러스터 내 트래픽으로 처리되며 클러스터 외부의 대상에 도달하지 않습니다.
특히 서비스 범위와 포드 범위는 다음과 겹치지 않아야 합니다.
모든 클러스터에 있는 노드의 IP 주소
부하 분산기 머신에서 사용하는 IP 주소
제어 영역 노드 및 부하 분산기에서 사용하는 VIP
vCenter 서버, DNS 서버, NTP 서버의 IP 주소
서비스 및 포드 범위는 RFC 1918 비공개 주소 공간에 있는 것이 좋습니다.
다음은 RFC 1918 주소를 사용을 권장하는 이유입니다. 포드 또는 서비스 범위에 외부 IP 주소가 포함되어 있다고 가정해보세요. 포드에서 이러한 외부 주소 중 하나로 전송되는 모든 트래픽은 클러스터 내 트래픽으로 취급되며 외부 대상에 도달하지 않습니다.
DNS 서버 및 기본 게이트웨이
구성 파일을 작성하기 전에 관리자 워크스테이션 및 클러스터 노드에서 사용할 수 있는 DNS 서버의 IP 주소를 알아야 합니다.
또한 각 서브넷에 기본 게이트웨이의 IP 주소를 알아야 합니다. 앞의 예시에서 각 서브넷의 기본 게이트웨이는 범위의 첫 번째 주소입니다. 예를 들어 관리자 클러스터의 서브넷에서 기본 게이트웨이는 172.16.20.1로 표시됩니다.