VPC 클러스터 네트워킹 이해

클러스터를 작성할 때는 특정 클러스터 컴포넌트가 서로 통신할 수 있도록, 그리고 클러스터 외부의 네트워크 또는 서비스와도 통신할 수 있도록 네트워킹 설정을 선택해야 합니다.

VPC 서브넷을 사용한 작업자 간 통신

VPC 클러스터를 처음 생성하기 전에, 워커 노드를 배포할 각 존에 VPC 서브넷을 생성해야 합니다. VPC 서브넷은 지정된 사설 IP 주소 범위(CIDR 블록)이며 동일한 실제 회선에 연결된 것처럼 작업자 노드 및 팟(Pod)의 그룹을 구성합니다.

클러스터를 작성할 때는 각 구역의 기본 VPC 서브넷을 지정합니다. 클러스터에 추가하는 각 작업자 노드는 해당 구역의 VPC 서브넷에 있는 사설 IP 주소로 배치됩니다. 작업자 노드가 프로비저닝된 후 작업자 노드 IP 주소는 reboot 오퍼레이션 후에도 지속되지만 작업자 노드 IP 주소는 replaceupdate 오퍼레이션 후에 변경됩니다.

서브넷은 클러스터 내 작업자 노드 간에 연결을 위한 채널을 제공합니다. 또한 동일한 VPC의 사설 서브넷에 연결된 모든 시스템이 작업자 노드와 통신할 수 있습니다. 예를 들어, 하나의 VPC에 있는 모든 서브넷은 기본 제공 VPC 라우터를 사용하는 사설 계층 3 라우팅을 통해 통신할 수 있습니다. 서로 통신해야 하는 다중 클러스터가 있는 경우 동일한 VPC에 클러스터를 작성할 수 있습니다. 그러나 클러스터가 통신할 필요가 없는 경우에는 클러스터를 별도의 VPC에 작성하여 향상된 네트워크 세그먼테이션을 수행할 수 있습니다. 또한 VPC 서브넷에 대한 액세스 제어 목록(ACL)을 작성하여 사설 네트워크의 트래픽을 중재할 수도 있습니다. ACL은 각 VPC 서브넷에 대해 허용되는 ingress 및 egress를 정의하는 인바운드 및 아웃바운드 규칙으로 구성됩니다.

VPC 클러스터를 작성하고 클러스터 작성 중에 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트 모두 사용 가능한 경우 기본적으로 퍼블릭 클라우드 서비스 엔드포인트는 클러스터의 Red Hat OpenShift 웹 콘솔과 같은 컴포넌트에 액세스하는 데 사용됩니다. 콘솔 팟(Pod)이 보안을 설정할 수 있도록 공용 서비스 엔드포인트를 통해 인터넷으로 안전한 공용 연결을 설정하려면 작업자 노드가 배치된 각 VPC 서브넷에 퍼블릭 게이트웨이를 사용으로 설정해야 합니다.

VPC 클러스터를 작성하고 클러스터 작성 중에 프라이빗 클라우드 서비스 엔드포인트만 사용 가능한 경우 기본적으로 프라이빗 클라우드 서비스 엔드포인트는 Red Hat OpenShift 웹 콘솔 또는 OperatorHub와 같은 Red Hat OpenShift 컴포넌트에 액세스하는 데 사용됩니다. 클러스터에서 이 컴포넌트에 액세스하거나 kubectl 명령을 실행하려면 VPN 연결 등을 통해 사설 VPC 네트워크에 연결되어 있어야 합니다.

VPC 서브넷에 대한 기본 IP 주소는 10.0.0.0 – 10.255.255.255입니다. VPC 구역당 IP 주소 범위의 목록은 VPC 기본 주소 접두부를 참조하십시오.

VPC를 작성할 때 클래식 액세스를 사용으로 설정하는 경우에는 클래식 액세스 기본 주소 접두부가 자동으로 작성되는 서브넷의 IP 범위를 결정합니다. 그러나 클래식 액세스 VPC 서브넷의 기본 IP 범위는 Red Hat OpenShift on IBM Cloud 제어 플레인의 서브넷과 충돌합니다. 대신, 자동 기본 주소 접두사를 포함하지 않은 상태로 VPC를 생성한 다음, 해당 범위 내에서 클러스터에 사용할 자체 주소 접두사와 서브넷을 생성해야 합니다.

사용자 정의 범위 서브넷을 사용하여 클러스터를 작성해야 합니까? 사용자 정의 주소 접두부에 대한 이 지침을 확인하십시오. 작업자 노드에 대해 사용자 정의 범위 서브넷을 사용하는 경우 작업자 노드 서브넷이 클러스터의 팟(Pod) 서브넷과 겹치지 않는지 확인해야 합니다.

클러스터 작성 중에, 또는 구역에서 작업자 노드를 추가할 때 클러스터에 연결한 서브넷을 삭제하지 마십시오. 클러스터에서 사용한 VPC 서브넷을 삭제하면 서브넷의 IP 주소를 사용하는 로드 밸런서에 문제가 발생하고 새 로드 밸런서를 작성하지 못할 수 있습니다.

클러스터에 대한 VPC 서브넷을 작성할 때 다음과 같은 기능과 제한사항을 염두에 두십니다. VPC 서브넷에 대한 자세한 정보는 VPC의 서브넷 특성을 참조하십시오.

  • 각 VPC 서브넷의 기본 CIDR 크기는 /24이며, 이는 253개의 작업자 노드를 지원할 수 있습니다. 한 클러스터에 구역당 250개 이상의 작업자 노드를 배치하려는 경우 더 큰 크기의 서브넷 작성을 고려하십시오.
  • VPC 서브넷을 작성한 후에는 크기를 조정하거나 해당 IP 범위를 변경할 수 없습니다.
  • 동일한 VPC 내의 다중 클러스터는 서브넷을 공유할 수 있습니다.
  • VPC 서브넷은 단일 존 또는 리전에만 연결되며, 여러 존이나 리전에 걸쳐 설정할 수 없습니다.
  • 서브넷을 작성한 후에는 다른 구역, 지역 또는 VPC로 서브넷을 이동할 수 없습니다.
  • 구역의 기존 서브넷에 연결된 작업자 노드가 있는 경우 클러스터의 해당 구역에 대한 서브넷을 변경할 수 없습니다.
  • 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16172.20.0.0/16 범위는 금지됩니다.

가상 사설 엔드포인트 또는 클라우드 서비스 엔드포인트를 사용한 작업자 대 마스터 및 사용자 대 마스터 통신

Red Hat OpenShift on IBM Cloud 다양한 유형의 서비스 엔드포인트를 사용하여 권한이 부여된 클러스터 사용자와 워커 노드가 Kubernetes 마스터와 연결을 설정합니다. 권한 부여된 클러스터 사용자는 클라우드 서비스 엔드포인트를 통해 Kubernetes 마스터와 통신합니다. 클러스터 버전에 따라 작업자 노드는 클라우드 서비스 엔드포인트 또는 VPC 가상 사설 엔드포인트를 통해 Kubernetes 마스터와 통신합니다.

클러스터를 작성하기 전에 서비스 엔드포인트를 사용하려면 계정을 사용으로 설정해야 합니다. 서비스 엔드포인트를 사용으로 설정하려면 ibmcloud account update --service-endpoint-enable true를 실행하십시오.

Red Hat OpenShift on IBM Cloud의 VPC 클러스터에서는 프라이빗 클라우드 서비스 엔드포인트를 사용 안함으로 설정하거나 퍼블릭 클라우드 서비스 엔드포인트만 사용하여 클러스터를 설정할 수 없습니다.

VPC 클러스터는 기본적으로 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트를 모두 포함하여 작성됩니다. 사설 네트워크에만 연결되는 작업자 노드로 클러스터를 작성하려면 클러스터 작성 중에 개인 서비스 엔드포인트만 사용으로 설정해야 합니다. 공용 서비스 엔드포인트를 사용으로 설정하지 마십시오. 예를 들어, CLI에서 프라이빗 클라우드 서비스 엔드포인트만 포함된 VPC 클러스터를 생성하려면 --disable-public-service-endpoint 옵션을 지정하십시오. 이 옵션을 포함하면, 클러스터가 생성될 때 기본적으로 사설 네트워크에서만 애플리케이션을 노출하는 라우터와 Ingress 컨트롤러가 함께 구성됩니다. 나중에 앱을 공용 네트워크에 노출시키려는 경우에는 공용 라우터 및 Ingress 제어기를 수동으로 작성해야 합니다.

VPC 클러스터에서의 작업자 대 마스터 통신

Kubernetes 마스터와의 워커 노드 통신은 기본적으로 VPC 가상 사설 엔드포인트(VPE) 를 사용합니다. 클러스터의 VPE 게이트웨이는 리전에 따라 CLUSTERID.vpe.private.REGION.containers.cloud.ibm.com 또는 CLUSTERID.private.REGION.containers.cloud.ibm.com 중 하나의 호스트명 형식을 사용합니다. 작업자에서 마스터로 전송되는 모든 트래픽은 이 사설 VPE 게이트웨이를 통해 라우팅됩니다.

VPE 게이트웨이 연결에 실패하고 클러스터에서 아웃바운드 트래픽 보호 기능이 비활성화된 경우, 워커 노드는 퍼블릭 클라우드 서비스 엔드포인트로 전환됩니다. 이 대체 처리는 VPE 게이트웨이에 연결할 수 없는 경우에만 발생하며, 정상 작동 중에는 발생하지 않습니다. 아웃바운드 트래픽 보호가 활성화된 경우, 공용 엔드포인트로 대체되는 일이 발생하지 않습니다.

퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트 또는 VPE를 통한 통신을 보호하기 위해, Red Hat OpenShift on IBM Cloud 는 클러스터가 생성될 때 Kubernetes 마스터 노드와 워커 노드 간에 Konnectivity 연결을 자동으로 설정합니다. 워커 노드는 TLS 인증서를 통해 마스터와 안전하게 통신하며, 마스터는 Konnectivity 연결을 통해 워커와 통신합니다.

VPC 클러스터에서의 사용자 대 마스터 통신

퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트를 사용으로 설정하거나 프라이빗 클라우드 서비스 엔드포인트만 사용으로 설정하여 권한 부여된 클러스터 사용자가 Kubernetes 마스터와 통신하도록 허용할 수 있습니다.

  • 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트: 기본적으로 권한 부여된 클러스터 사용자가 시작한 마스터에 대한 모든 호출은 퍼블릭 클라우드 서비스 엔드포인트를 통해 라우팅됩니다. 권한 부여된 클러스터 사용자가 VPC 네트워크에 있거나 VPC VPN 연결을 통해 연결되어 있는 경우, 마스터는 프라이빗 클라우드 서비스 엔드포인트를 통해 개인용으로 액세스할 수 있습니다.
  • 프라이빗 클라우드 서비스 엔드포인트에만 해당: 프라이빗 클라우드 서비스 엔드포인트를 통해 마스터에 액세스하려면 권한 부여된 클러스터 사용자가 VPC 네트워크에 있거나 VPC VPN 연결을 통해 연결되어 있어야 합니다.

컨텍스트 기반 제한을 사용하여 클러스터의 서비스 엔드포인트에 대한 네트워크 액세스를 보호할 수 있습니다. 허용 목록에 포함된 서브넷에서 발신된, 클러스터 마스터에 대한 승인된 요청만 클러스터의 서비스 엔드포인트를 통해 허용됩니다. 컨텍스트 기반 제한을 사용하면 무단 스캔 활동을 방지하는 데 도움이 됩니다. 자세한 내용은 컨텍스트 기반 제한 사용하기를 참조하세요.

작업자와 기타 서비스 또는 네트워크 간의 통신

작업자 노드가 기타 IBM Cloud 서비스, 온프레미스 네트워크, 기타 VPC 및 IBM Cloud 클래식 인프라 리소스와 안전하게 통신할 수 있도록 하십시오.

사설 또는 공용 네트워크를 통한 기타 IBM Cloud 서비스와의 통신

작업자 노드는 사설 네트워크를 통해 프라이빗 클라우드 서비스 엔드포인트를 지원하는 기타 IBM Cloud 서비스(예:IBM Cloud® Container Registry)와 자동으로 안전하게 통신할 수 있습니다. IBM Cloud 서비스가 프라이빗 클라우드 서비스 엔드포인트를 지원하지 않는 경우 작업자 노드는 서브넷의 퍼블릭 게이트웨이를 통해 공용 네트워크로 서비스와 안전하게 통신할 수 있습니다.

VPC 서브넷의 액세스 제어 목록(ACL)을 사용하는 경우에는 작업자 노드가 이러한 서비스와 통신할 수 있도록 인바운드 또는 아웃바운드 규칙을 작성해야 합니다.

온프레미스 데이터 센터의 리소스와 통신

온프레미스 데이터 센터와 클러스터를 연결하기 위해 IBM Cloud® Virtual Private Cloud VPN 또는 IBM Cloud® Direct Link를 설정할 수 있습니다.

클러스터를 온프레미스 네트워크에 연결하려는 경우 다음 유용한 정보를 확인하십시오.

  • IBM 제공 기본 범위인, 팟(Pod)에 대한 172.30.0.0/16 범위 및 서비스에 대한 172.21.0.0/16 범위와의 서브넷 충돌이 있을 수 있습니다. CLI를 통해 클러스터를 생성할 때, --pod-subnet 옵션에서 파드용 사용자 지정 서브넷 CIDR을, --service-subnet 옵션에서 서비스용 사용자 지정 서브넷 CIDR을 지정하면 서브넷 충돌을 방지할 수 있습니다.
  • 사용자의 VPN 솔루션이 요청의 소스 IP 주소를 유지하는 경우에는 작업자 노드가 클러스터의 응답을 온프레미스 네트워크로 다시 라우팅할 수 있도록 사용자 정의 정적 라우트를 작성할 수 있습니다.
  • 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16172.20.0.0/16 서브넷 범위는 Red Hat OpenShift on IBM Cloud 제어 플레인 기능용으로 예약되어 있으므로 금지됩니다.

기타 VPC의 리소스와 통신

전체 VPC를 사용자 계정에 있는 다른 VPC에 연결하려는 경우에는 IBM Cloud VPC VPN 또는 IBM Cloud® Transit Gateway를 사용할 수 있습니다.

  • IBM Cloud VPC VPN을 시작하려면 VPN을 사용하여 두 개의 VPC 연결의 단계에 따라 각 VPC의 서브넷에 VPC 게이트웨이를 작성하고 두 VPC 게이트웨이 간에 VPN 연결을 작성하십시오. VPC에서 액세스 제어 목록 (ACL) 또는 보안 그룹을 사용자 정의한 경우, ACL및 보안 그룹이 작업자 노드가 다른 VPC의 작업자 노드와 통신할 수 있도록 허용하는지 확인해야 합니다.
  • IBM Cloud Transit Gateway를 시작하려면 Transit Gateway 문서를 참조하십시오. Transit Gateway 인스턴스는 동일한 지역에 있는 VPC 간에 라우팅(로컬 라우팅)하거나 서로 다른 지역에 있는 VPC 간에 라우팅(글로벌 라우팅)하도록 구성할 수 있습니다.

IBM Cloud 클래식 리소스와의 통신

클러스터를 IBM Cloud 클래식 인프라의 리소스에 연결해야 하는 경우에는 클래식 액세스가 가능한 VPC를 설정하거나 IBM Cloud Transit Gateway를 사용할 수 있습니다.

  • 클래식 액세스가 가능한 VPC를 시작하려면 클래식 인프라에 대한 액세스 설정을 참조하십시오. VPC를 작성할 때 클래식 액세스를 사용으로 설정해야 하며, 클래식 액세스를 사용하도록 기존 VPC를 변환할 수 없습니다. 또한 지역당 하나의 VPC에 대해서만 클래식 인프라 액세스를 설정할 수 있으며, 하나의 지역에서 클래식 인프라 액세스가 가능한 VPC를 둘 이상 설정할 수 없습니다.
  • IBM Cloud Transit Gateway를 시작하려면 Transit Gateway 문서를 참조하십시오. IBM Cloud Transit Gateway를 사용하여 여러 지역에 있는 VPC와 IBM Cloud 클래식 인프라에 있는 리소스 간의 액세스를 관리하는 등의 방법으로 여러 VPC를 클래식 인프라에 연결할 수 있습니다.

작업자 노드에서 실행되는 앱에 대한 외부 통신

클러스터 외부로부터 작업자 노드에서 실행되는 앱으로의 사설 또는 공용 트래픽 요청을 허용하십시오.

클러스터 앱에 대한 개인용 트래픽

클러스터에 앱을 배치할 때 클러스터와 동일한 사설 네트워크에 있는 사용자 및 서비스에서만 앱에 액세스할 수 있도록 설정하려고 할 수 있습니다. 사설 로드 밸런싱은 앱을 일반 사용자에게 노출하지 않고 클러스터 외부의 요청에서 앱을 사용할 수 있도록 하는 데 적합합니다. 나중에 공용 네트워크 서비스를 사용하여 앱을 공용으로 노출하기 전에 액세스, 요청 라우팅 및 기타 구성을 테스트하기 위해 사설 로드 밸런싱도 사용할 수 있습니다.

클러스터 외부에서 앱으로의 개인용 트래픽 요청을 허용하려는 경우에는 LoadBalancer 서비스와 같은 사설 Kubernetes 네트워킹 서비스를 사용할 수 있습니다. 예를 들면, 클러스터에서 Kubernetes LoadBalancer 서비스를 작성하면 클러스터 외부의 VPC에 VPC용 로드 밸런서가 자동으로 작성됩니다. VPC 로드 밸런서는 다중 구역이며 작업자 노드에서 자동으로 열리는 사설 NodePort를 통해 앱에 대한 요청을 라우팅합니다. VPC ALB 및 NLB의 경우 kube-lbaas-<cluster-id> 형식의 보안 그룹이 로드 밸런서에 자동으로 연결됩니다.

자세한 정보는 사설 외부 로드 밸런싱 계획을 참조하십시오.

클러스터 앱에 대한 공용 트래픽

공용 인터넷에서 앱에 액세스할 수 있도록 하려는 경우에는 공용 네트워킹 서비스를 사용할 수 있습니다. 작업자 노드가 사설 VPC 서브넷에만 연결되어 있는 경우에도 공용 네트워킹 서비스용으로 작성된 VPC 로드 밸런서는 앱에 공용 URL을 제공하여 사설 네트워크에 있는 앱으로 공용 요청을 라우팅할 수 있습니다. 앱이 공용으로 노출되면, 공용 URL을 갖고 있는 사용자는 요청을 앱에 전송할 수 있습니다.

LoadBalancer 서비스 작성과 같은 공용 Kubernetes 네트워킹 서비스를 사용할 수 있습니다. 예를 들면, 클러스터에서 Kubernetes LoadBalancer 서비스를 작성하면 클러스터 외부의 VPC에 VPC용 로드 밸런서가 자동으로 작성됩니다. VPC 로드 밸런서는 다중 구역이며 작업자 노드에서 자동으로 열리는 사설 NodePort를 통해 앱에 대한 요청을 라우팅합니다. VPC ALB 및 NLB의 경우 kube-lbaas-<cluster-id> 형식의 보안 그룹이 로드 밸런서에 자동으로 연결됩니다.

VPC 클러스터 네트워크 설정을 위한 예제 시나리오

이제 클러스터 네트워킹의 기본사항을 이해했으므로 다양한 VPC 클러스터 네트워크 설정이 워크로드 요구사항을 충족할 수 있는 몇 가지 예제 시나리오를 확인합니다.

시나리오: VPC 클러스터에서 인터넷 연결 앱 워크로드 실행

이 시나리오에서는 인터넷에서의 요청에 액세스할 수 있는 VPC 클러스터의 워크로드를 실행합니다. 공용 액세스가 보안 그룹에 의해 제어되므로 원치 않는 공용 요청은 거부되지만 일반 사용자는 앱에 액세스할 수 있습니다. 또한 작업자가 프라이빗 클라우드 서비스 엔드포인트를 지원하는 IBM Cloud 서비스에 자동으로 액세스할 수 있습니다.

인터넷에 노출된 애플리케이션 워크로드를 실행하는 VPC 클러스터의 네트워크 구성.
인터넷에 노출된 애플리케이션 워크로드를 실행하는 VPC 클러스터의 네트워크 구성

작업자 간 통신

이 설정을 수행하기 위해, 사용자는 작업자 노드를 배치할 각 구역에 VPC 서브넷을 작성합니다. 웹 콘솔 또는 OperatorHub와 같은 기본 Red Hat OpenShift 컴포넌트를 실행하려면 이러한 서브넷에 퍼블릭 게이트웨이가 필요합니다. 그런 다음 이러한 VPC 서브넷을 사용하는 VPC 클러스터를 작성합니다.

작업자 대 마스터 및 사용자 대 마스터 통신

작업자 대 마스터 및 사용자 대 마스터 통신을 공용 및 사설 네트워크를 통해 허용할지, 또는 사설 네트워크를 통해서만 허용할지 선택할 수 있습니다.

  • 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트: 작업자 노드와 마스터 간의 통신은 프라이빗 클라우드 서비스 엔드포인트를 통해 사설 네트워크를 거쳐 설정됩니다. 기본적으로 권한 부여된 클러스터 사용자가 시작한 마스터에 대한 모든 호출은 퍼블릭 클라우드 서비스 엔드포인트를 통해 라우팅됩니다.
  • 개인 서비스 엔드포인트에만 해당: 작업자 노드와 클러스터 사용자 모두에서 마스터로의 통신은 프라이빗 클라우드 서비스 엔드포인트를 통해 사설 네트워크를 거쳐 설정됩니다. 클러스터 사용자가 VPN 네트워크에 있거나 VPC VPN 연결을 통해 연결되어 있어야 합니다.

작업자와 기타 서비스 또는 네트워크 간의 통신

앱 워크로드에 다른 IBM Cloud 서비스가 필요한 경우, 작업자 노드는 사설 VPC 네트워크를 통해 프라이빗 클라우드 서비스 엔드포인트를 지원하는 다른 IBM Cloud 서비스와 자동으로 안전하게 통신할 수 있습니다.

작업자 노드에서 실행되는 앱에 대한 외부 통신

앱을 테스트한 후 공용 Kubernetes LoadBalancer 서비스를 작성하거나 기본 공용 Ingress 애플리케이션 로드 밸런서(ALB)를 사용하여 앱을 인터넷에 노출할 수 있습니다. 이러한 서비스 중 하나를 사용할 때 클러스터 외부의 VPC에 자동으로 작성되는 VPC 로드 밸런서는 트래픽을 앱으로 라우팅합니다. VPC ALB에 자동으로 적용되는 kube-lbaas-<cluster-id> 보안 그룹을 사용자가 작성하고 관리하는 보안 그룹으로 대체하여 클러스터의 보안을 개선하고 앱에 대한 공용 네트워크 트래픽을 제어할 수 있습니다. ALB에 적용되는 경우 보안 그룹은 ALB를 통해 클러스터에 허용되는 인바운드 트래픽을 제어합니다.

이 시나리오의 클러스터를 시작할 준비가 되셨습니까? 고가용성 설정을 계획한 후에는 VPC 클러스터 만들기 를 참조하세요.

온프레미스 데이터 센터를 VPC 클러스터로 확장

이 시나리오에서는 VPC 클러스터의 워크로드를 실행합니다. 그러나 온프레미스 데이터 센터에 있는 사설 네트워크에서 서비스, 데이터베이스 또는 기타 리소스에서만 이러한 워크로드에 액세스할 수 있도록 하려 합니다. 클러스터 워크로드가 사설 네트워크를 통한 통신을 지원하는 몇몇 다른 IBM Cloud 서비스에 액세스해야 할 수도 있습니다.

온프레미스 데이터 센터를 확장하는 VPC 클러스터의 네트워크 구성.
온프레미스 데이터 센터를 확장하는 VPC 클러스터의 네트워크 구성

작업자 간 통신

이 설정을 수행하기 위해, 사용자는 작업자 노드를 배치할 각 구역에 VPC 서브넷을 작성합니다. 웹 콘솔 또는 OperatorHub와 같은 기본 Red Hat OpenShift 컴포넌트를 실행하려면 이러한 서브넷에 퍼블릭 게이트웨이가 필요합니다. 그런 다음 이러한 VPC 서브넷을 사용하는 VPC 클러스터를 작성합니다.

작업자 노드, 팟(Pod), 서비스에 대한 기본 범위와 온프레미스 네트워크의 서브넷 간에 서브넷 충돌이 있을 수 있습니다. VPC 서브넷을 작성하는 경우, 이 서브넷을 사용하여 사용자 정의 주소 접두부를 선택하고 클러스터를 작성할 수 있습니다. 또한, 클러스터를 생성할 때 ibmcloud oc cluster create 명령어에서 --pod-subnet --service-subnet 옵션을 사용하여 포드 및 서비스에 대한 사용자 지정 서브넷 CIDR을 지정할 수 있습니다.

작업자 대 마스터 및 사용자 대 마스터 통신

클러스터를 작성하면, 프라이빗 클라우드 서비스 엔드포인트만 사용하여 사설 네트워크를 통한 작업자와 마스터 간 통신 및 사용자와 마스터 간 통신을 허용할 수 있습니다. 클러스터 사용자가 VPN 네트워크에 있거나 VPC VPN 연결을 통해 연결되어 있어야 합니다.

작업자와 기타 서비스 또는 네트워크 간의 통신

온프레미스 데이터 센터와 클러스터를 연결하기 위해 VPC VPN 서비스를 설정할 수 있습니다. IBM Cloud VPC VPN은 전체 VPC를 온프레미스 데이터 센터에 연결합니다. 앱 워크로드에 프라이빗 클라우드 서비스 엔드포인트를 지원하는 다른 IBM Cloud 서비스가 필요한 경우, 작업자 노드가 사설 VPC 네트워크를 통해 이러한 서비스와 자동으로 안전하게 통신할 수 있습니다.

작업자 노드에서 실행되는 앱에 대한 외부 통신

앱을 테스트한 후 사설 Kubernetes LoadBalancer 서비스를 작성하거나 기본 사설 Ingress 애플리케이션 로드 밸런서(ALB)를 사용하여 앱을 사설 네트워크에 노출할 수 있습니다. 이러한 서비스 중 하나를 사용할 때 클러스터 외부의 VPC에 자동으로 작성되는 VPC 로드 밸런서는 트래픽을 앱으로 라우팅합니다. VPC 로드 밸런서는 VPC 서브넷에 대한 연결이 있는 온프레미스 시스템이 앱에 액세스할 수 있도록 사설 네트워크에만 앱을 노출합니다. 클러스터의 기본 VPC 보안 그룹을 수정하여 클러스터의 보안을 향상시키고 앱에 대한 공용 트래픽을 제어할 수 있습니다. 보안 그룹은 작업자 노드에 대해 허용되는 인바운드 트래픽을 정의하는 규칙으로 구성됩니다.

이 시나리오의 클러스터를 시작할 준비가 되셨습니까? 고가용성 설정을 계획한 후에는 VPC 클러스터 만들기 를 참조하세요.

다음 단계

계획 프로세스를 계속 진행하려면 구성해야 하는 암호화 수준을 결정하여 클러스터의 민감한 정보를 보호하는 방법에 대해 알아보세요. 네트워킹 설정을 시작할 준비가 되었다면 기본 클러스터 VPC 네트워킹에 의한 보안 이해하기 로 이동하세요.