IBM Cloud Docs
VPC 서브넷 구성

VPC 서브넷 구성

Virtual Private Cloud

IBM Cloud® Kubernetes Service VPC 클러스터에 서브넷을 추가하여 사용 가능한 포터블 공인 IP 주소 또는 사설 IP 주소의 풀을 변경합니다.

이 페이지의 컨텐츠는 VPC 클러스터에 특정합니다. 클래식 클러스터에 대한 정보는 클래식 클러스터에 대한 서브넷 및 IP 주소 구성.

IBM Cloud Kubernetes Service의 VPC 네트워킹 개요

IBM Cloud Kubernetes Service 클러스터의 VPC 네트워킹에 대한 기본 개념을 이해합니다.

서브넷

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

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

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

VPC 서브넷에 몇 개의 IP 주소가 필요한가요?

VPC 서브넷을 만들 때 클러스터에 충분한 IP 주소(예: 256)로 서브넷을 만들어야 합니다. VPC 서브넷에 있는 IP 주소의 수는 나중에 변경할 수 없습니다.

다음 IP 주소 예약에 유의하십시오.

  • 기본적으로 5개의 IP 주소가 각 서브넷의 VPC에 의해 예약됩니다.
  • 클러스터에 작업자 노드가 있는 각 영역에 있는 서브넷의 IP 주소 1개가 VPE(가상 사설 엔드포인트)게이트웨이에 필요합니다.
  • 클러스터의 각 작업자 노드에 1개의 IP 주소가 필요합니다.
  • 작업자 노드를 업데이트 또는 대체할 때마다 1개의 IP 주소가 필요합니다. 이러한 IP 주소는 나중에 재확보되어 다시 사용할 수 있게 됩니다.
  • 공용 또는 사설 로드 밸런서를 작성할 때마다 2개의 IP 주소가 필요합니다. 다중 구역 클러스터가 있는 경우에는 서브넷에 예약된 IP 주소가 없도록 이러한 2개의 IP 주소가 각 구역에 분산됩니다.
  • 클러스터에 대해 설정하는 기타 네트워킹 리소스(예: VPNaaS 또는 LBaaS 오토스케일링)에는 추가 IP 주소가 필요하거나 다른 서비스 제한사항이 있을 수 있습니다. 예를 들어, LBaaS 오토스케일링은 로드 밸런서당 최대 16개 IP 주소로 스케일링 업할 수 있습니다.

VPC 서브넷에 어떤 IP 범위를 사용할 수 있나요?

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

사용자 정의 범위 서브넷을 사용하여 클러스터를 작성해야 하는 경우에는 사용자 정의 주소 접두부에 대한 안내를 참조하십시오. 그러나 작업자 노드에 대해 사용자 정의 범위 서브넷을 사용하는 경우에는 작업자 노드 서브넷의 IP 범위가 클러스터의 팟(Pod) 서브넷과 겹치지 않도록 해야 합니다. 팟(Pod) 서브넷은 클러스터 작성 중에 선택하는 서브넷 및 클러스터의 인프라 유형에 따라 달라집니다.

  • 클러스터 생성 시 --pod-subnet 옵션에서 자체 파드 서브넷을 지정한 경우, 파드에는 이 범위의 IP 주소가 할당됩니다.
  • 클러스터 작성 중에 사용자 정의 팟(Pod) 서브넷을 지정하지 않으면 클러스터가 기본 팟(Pod) 서브넷을 사용합니다. VPC에서 작성하는 첫 번째 클러스터의 기본 팟(Pod) 서브넷은 172.17.0.0/18입니다. 이 VPC에서 작성하는 두 번째 클러스터의 기본 팟(Pod) 서브넷은 172.17.64.0/18입니다. 각 후속 클러스터에서 팟(Pod) 서브넷 범위는 다음으로 사용 가능한, 겹치지 않는 /18 서브넷입니다.

기존 인프라 액세스를 위한 서브넷은 어떻게 생성하나요?

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

클러스터의 파드 및 서비스에 대한 서브넷을 지정할 수 있나요?

클러스터를 IBM Cloud Direct Link 또는 VPN 서비스를 통해 온프레미스 네트워크에 연결하려는 경우, 팟(Pod)에 사설 IP 주소를 제공하는 사용자 정의 서브넷 CIDR과 서비스에 사설 IP 주소를 제공하는 사용자 정의 서브넷 CIDR을 지정하여 서브넷 충돌을 방지할 수 있습니다.

클러스터 생성 중에 사용자 정의 파드 및 서비스 서브넷을 지정하려면 ibmcloud ks cluster create CLI 명령에서 --pod-subnet--service-subnet 옵션을 사용합니다.

클러스터가 사용하는 팟(Pod) 및 서비스 서브넷을 보려면 Pod Subnet 출력에서 Service Subnetibmcloud ks cluster get 필드를 검색하십시오.

팟(Pod)

기본 범위

VPC에서 작성하는 첫 번째 클러스터의 기본 팟(Pod) 서브넷은 172.17.0.0/18입니다. 이 VPC에서 작성하는 두 번째 클러스터의 기본 팟(Pod) 서브넷은 172.17.64.0/18입니다. 각 후속 클러스터에서 팟(Pod) 서브넷 범위는 다음으로 사용 가능한, 겹치지 않는 /18 서브넷입니다.

크기 요구사항

사용자 정의 서브넷을 지정하는 경우 작성하려는 클러스터의 크기와 나중에 추가할 작업자 노드 수를 고려하십시오. 서브넷에는 클러스터의 최대 4개의 작업자 노드에 충분한 팟(Pod) IP를 제공하는 최소 /23의 CIDR이 있어야 합니다. 더 큰 클러스터의 경우에는 8개의 작업자 노드에 충분한 팟(Pod) IP 주소를 보유하기 위해 /22를 사용하고 16개의 작업자 노드에 충분한 팟(Pod) IP 주소를 보유하기 위해 /21을 사용하는 등의 방식을 사용하십시오.

VPC 클러스터의 경우 --pod-subnet 옵션에 포함하여 서브넷 크기를 지정할 수 있습니다. 예: --pod-subnet 0.0.0.0/X. 여기서 X 는 필수 팟 (Pod) 서브넷 크기입니다. 그러면 팟 (Pod) 서브넷이 자동으로 선택됩니다. 팟 (Pod) 서브넷을 자동으로 할당할 때 할당은 172.17.0.0 에서 시작되고 가장 큰 서브넷은 13 로 제한되며 가장 작은 서브넷 크기는 23 로 제한됩니다.

워커 노드에는 전역 제한이 있습니다. 한 지역의 모든 클러스터에서 작업자 노드는 500개를 초과할 수 없습니다.

범위 요구사항

팟(Pod) 및 서비스 서브넷은 서로 겹칠 수 없으며 팟(Pod) 서브넷은 작업자 노드의 서브넷과 겹칠 수 없습니다. 선택하는 서브넷은 다음 범위 중 하나에 있어야 합니다.

  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.255.255

  • 198.18.0.0 - 198.19.255.255

서비스

기본 범위
클러스터에 배치된 모든 서비스에는 기본적으로 172.21.0.0/16 범위의 사설 IP 주소가 지정됩니다.
크기 요구사항
사용자 정의 서브넷을 지정하는 경우 서브넷은 /24 이상의 크기인 CIDR 형식으로 지정되어야 하며 클러스터에서 최대 255개 이상의 서비스를 허용합니다.
범위 요구사항
팟(Pod) 및 서비스 서브넷은 서로 겹칠 수 없습니다. 선택하는 서브넷은 다음 범위 중 하나에 있어야 합니다.
  • 172.17.0.0 - 172.17.255.255

  • 172.21.0.0 - 172.31.255.255

  • 192.168.0.0 - 192.168.255.255

  • 198.18.0.0 - 198.19.255.255

퍼블릭 게이트웨이

퍼블릭 게이트웨이를 통해 서브넷과 서브넷에 연결된 모든 작업자 노드는 인터넷에 아웃바운드 연결을 설정할 수 있습니다. 작업자 노드가 클러스터 외부의 공용 엔드포인트에 액세스해야 하는 경우 작업자 노드가 배치되는 VPC 서브넷에서 퍼블릭 게이트웨이를 사용으로 설정할 수 있습니다.

IBM Cloud 서비스에서 프라이빗 클라우드 서비스 엔드포인트를 지원하지 않는 경우 작업자 노드는 공용 게이트웨이가 접속된 서브넷에 연결되어 있어야 합니다. 해당 작업자 노드의 팟(Pod)은 서브넷의 퍼블릭 게이트웨이를 통해 공용 네트워크를 거쳐 서비스와 안전하게 통신할 수 있습니다. 인터넷에서 LoadBalancer 서비스 또는 ALB로 인바운드 네트워크 트래픽을 허용하기 위해 퍼블릭 게이트웨이가 서브넷에 필요하지 않습니다.

하나의 VPC내에서는 구역마다 하나의 퍼블릭 게이트웨이만 작성할 수 있지만 해당 퍼블릭 게이트웨이는 구역 내의 여러 서브넷에 접속할 수 있습니다. 퍼블릭 게이트웨이에 대한 자세한 정보는 VPC의 네트워킹 문서를 참조하십시오.

가상 사설 엔드포인트(VPE)

작업자 노드는 클러스터의 가상 사설 엔드포인트(VPE) 를 통해 Kubernetes 마스터와 통신할 수 있습니다.

VPE는 엔드포인트 게이트웨이에 바인드된 가상 IP 주소입니다. VPC에서 클러스터당 하나의 VPE 게이트웨이 리소스가 작성됩니다. 클러스터에 작업자 노드가 있는 각 구역의 하나의 서브넷의 하나의 IP 주소가 VPE 게이트웨이에 자동으로 사용되며, 이 구역의 작업자 노드는 이 IP 주소를 사용하여 Kubernetes 마스터와 통신합니다. 클러스터에 대한 VPE 게이트웨이 세부 정보를 보려면 VPC용 가상 사설 엔드포인트 게이트웨이 대시보드를 열고 iks-<cluster_ID> 형식의 VPE 게이트웨이를 찾습니다.

작업자 노드는 기본적으로 VPC에서 작성된 VPE를 자동으로 사용합니다. 하지만 클러스터의 퍼블릭 클라우드 서비스 엔드포인트를 사용으로 설정한 경우, 작업자와 마스터 간의 트래픽 절반은 공용 엔드포인트를 통해 설정되고 나머지 반은 VPE를 통해 설정되어 공용 또는 사설 네트워크의 잠재적 가동 중단으로부터 보호됩니다.

VPE에 사용되는 서브넷에서는 IP 주소를 삭제하지 마십시오.

네트워크 세그먼트화

네트워크 세그먼트화는 네트워크를 다중 하위 네트워크로 분할하기 위한 접근 방식을 말합니다. 하나의 서브네트워크에서 실행되는 앱은 다른 서브네트워크의 앱을 보거나 이에 액세스할 수 없습니다. VPC 서브넷을 위한 네트워크 세그먼트화 옵션에 대한 자세한 정보는 이 클러스터 보안 주제를 참조하십시오.

서브넷은 클러스터 내 작업자 노드 간에 연결을 위한 채널을 제공합니다. 또한 동일한 VPC의 사설 서브넷에 연결된 모든 시스템이 작업자 노드와 통신할 수 있습니다. 예를 들어, 하나의 VPC에 있는 모든 서브넷은 기본 제공 VPC 라우터를 사용하는 사설 계층 3 라우팅을 통해 통신할 수 있습니다.

서로 통신해야 하는 다중 클러스터가 있는 경우 동일한 VPC에 클러스터를 작성할 수 있습니다. 그러나 클러스터가 통신할 필요가 없는 경우에는 클러스터를 별도의 VPC에 작성하여 향상된 네트워크 세그먼테이션을 수행할 수 있습니다. 또한 VPC 서브넷에 대한 액세스 제어 목록(ACL)을 작성하여 사설 네트워크의 트래픽을 중재할 수도 있습니다. ACL은 각 VPC 서브넷에 대해 허용되는 ingress 및 egress를 정의하는 인바운드 및 아웃바운드 규칙으로 구성됩니다.

VPC 네트워킹 제한사항

클러스터에 대한 VPC 서브넷을 작성할 때 다음과 같은 기능과 제한사항을 염두에 두십니다.

  • 각 VPC 서브넷의 기본 CIDR 크기는 /24이며, 이는 253개의 작업자 노드를 지원할 수 있습니다. 한 클러스터에 구역당 250개 이상의 작업자 노드를 배치하려는 경우 더 큰 크기의 서브넷 작성을 고려하십시오.
  • VPC 서브넷을 작성한 후에는 크기를 조정하거나 해당 IP 범위를 변경할 수 없습니다.
  • 동일한 VPC 내의 다중 클러스터는 VPC 서브넷을 공유할 수 있습니다. 하지만 여러 클러스터 간에 사용자 정의 팟(Pod) 및 서비스 서브넷을 공유할 수 없습니다.
  • VPC 서브넷은 단일 캠퍼스 다중 영역에 바인딩되며 여러 영역이나 지역에 걸쳐 있을 수 없습니다.
  • 서브넷을 작성한 후에는 다른 구역, 지역 또는 VPC로 서브넷을 이동할 수 없습니다.
  • 구역의 기존 서브넷에 연결된 작업자 노드가 있는 경우 클러스터의 해당 구역에 대한 서브넷을 변경할 수 없습니다.
  • 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16172.20.0.0/16 범위는 금지됩니다.
  • 하나의 VPC내에서는 구역마다 하나의 퍼블릭 게이트웨이만 작성할 수 있지만 해당 퍼블릭 게이트웨이는 구역 내의 여러 서브넷에 접속할 수 있습니다.
  • 클래식 액세스 기본 주소 접두부가 IBM Cloud Kubernetes Service 제어 플레인의 서브넷과 충돌합니다. 자동 기본 주소 접두사를 사용하지 않고 VPC를 만든 다음 해당 범위 내에서 클러스터의 주소 접두사 및 서브넷을 직접 만들어야 합니다.

VPC 서브넷 작성 및 퍼블릭 게이트웨이 연결

클러스터에 대한 VPC 서브넷을 작성하고 선택적으로 퍼블릭 게이트웨이를 서브넷에 연결합니다.

콘솔에 VPC 서브넷 작성

IBM Cloud 콘솔을 사용하여 클러스터에 대한 VPC 서브넷을 작성하고 선택적으로 서브넷에 퍼블릭 게이트웨이를 연결합니다.

  1. VPC 서브넷 대시보드에서 작성을 클릭하십시오.
  2. 서브넷의 이름을 입력하고 작성한 VPC의 이름을 선택하십시오.
  3. 서브넷을 작성할 위치 및 구역을 선택하십시오.
  4. 작성할 IP 주소의 수를 지정하십시오.
    • VPC 서브넷은 클러스터에서 작업자 노드 및 로컬 로드 밸런서 서비스에 IP 주소를 제공하므로 충분한 IP 주소가 있는 VPC 서브넷을 작성하십시오(예: 256). VPC 서브넷에 있는 IP 수를 나중에 변경할 수 없습니다.
    • 특정 IP 범위를 입력하는 경우 예약 범위 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16172.20.0.0/16을 사용하지 마십시오.
  5. 서브넷에 퍼블릭 게이트웨이를 연결할지 여부를 선택하십시오. 공용 네트워크 게이트웨이는 클러스터가 공용 엔드포인트(예: 다른 앱의 공용 URL) 또는 퍼블릭 클라우드 서비스 엔드포인트만 지원하는 IBM Cloud 서비스에 액세스해야 하는 경우에 필요합니다.
  6. 서브넷 작성을 클릭하십시오.
  7. 서브넷을 사용하여 클러스터를 작성하거나 작업자 풀을 새로 작성하거나 기존 작업자 풀에 서브넷을 추가하십시오. 클러스터 작성 중에, 또는 구역에서 작업자 노드를 추가할 때 클러스터에 연결한 서브넷을 삭제하지 마십시오. 클러스터에서 사용한 VPC 서브넷을 삭제하면 서브넷의 IP 주소를 사용하는 로드 밸런서에 문제가 발생하고 새 로드 밸런서를 작성하지 못할 수 있습니다.

CLI에 VPC 서브넷 작성

IBM Cloud CLI를 사용하여 클러스터에 대한 VPC 서브넷을 작성하고 선택적으로 서브넷에 퍼블릭 게이트웨이를 연결하십시오.

시작하기 전에

  1. 명령행에서 IBM Cloud 계정에 로그인하고 VPC 클러스터를 작성할 IBM Cloud 지역 및 리소스 그룹을 대상으로 지정하십시오. 지원되는 지역은 다른 지역에 VPC 작성을 참조하십시오. 클러스터의 리소스 그룹은 VPC 리소스 그룹과 다를 수 있습니다. 프롬프트가 표시되면 IBM Cloud 인증 정보를 입력하십시오. 페더레이션 ID가 있는 경우 --sso 옵션을 사용하여 로그인합니다.
    ibmcloud login -r <region> [-g <resource_group>] [--sso]
    
  2. 클러스터를 작성할 동일한 지역에서 VPC를 작성하십시오.

VPC 서브넷을 작성하려면 다음 단계를 수행하십시오.

  1. 서브넷을 작성할 VPC의 ID를 가져오십시오.

    ibmcloud ks vpcs
    
  2. 서브넷을 작성하십시오. 이 명령의 옵션에 대한 자세한 정보는 CLI 참조를 참조하십시오.

    ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address>
    
    • VPC 서브넷은 클러스터에서 작업자 노드 및 로컬 로드 밸런서 서비스에 IP 주소를 제공하므로 충분한 IP 주소가 있는 VPC 서브넷을 작성하십시오(예: 256). VPC 서브넷에 있는 IP 수를 나중에 변경할 수 없습니다.
    • 다음 예약 범위를 사용하지 마세요: 172.16.0.0/16, 172.18.0.0/16, 172.19.0.0/16, 172.20.0.0/16.
  3. 클러스터를 작성할 구역에 퍼블릭 게이트웨이가 있는지 확인하십시오. 하나의 VPC내에서는 구역마다 하나의 퍼블릭 게이트웨이만 작성할 수 있지만 해당 퍼블릭 게이트웨이는 구역 내의 여러 서브넷에 접속할 수 있습니다.

    ibmcloud is public-gateways
    

    출력 예

    ID                                     Name                                       VPC                          Zone         Floating IP                  Created                     Status      Resource group
    26426426-6065-4716-a90b-ac7ed7917c63   test-pgw                                   testvpc(36c8f522-.)          us-south-1   169.xx.xxx.xxx(26466378-.)   2019-09-20T16:27:32-05:00   available   -
    2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   team3(ff537d43-.)            us-south-2   169.xx.xxx.xxx(2ba9a280-.)   2019-08-02T10:30:29-05:00   available   -
    
    • 각 구역에 퍼블릭 게이트웨이가 이미 있는 경우에는 이 퍼블릭 게이트웨이의 ID를 기록해 두십시오.
    • 각 구역에 퍼블릭 게이트웨이가 없는 경우, 퍼블릭 게이트웨이를 작성하십시오. <cluster>-<zone>-gateway 형식으로 퍼블릭 게이트웨이의 이름 지정을 고려하십시오. 출력에서 퍼블릭 게이트웨이의 ID를 기록해 두십시오.
    ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
    

    출력 예

    ID               26466378-6065-4716-a90b-ac7ed7917c63
    Name             mycluster-us-south-1-gateway
    Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
    Status           pending
    Created          2019-09-20T16:27:32-05:00
    Zone             us-south-1
    VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    Resource group   -
    
  4. 퍼블릭 게이트웨이 및 서브넷의 ID를 사용하여 퍼블릭 게이트웨이를 서브넷에 연결하십시오.

    ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
    

    출력 예

    ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
    Name                mysubnet1
    IPv4 CIDR           10.240.xx.xx/24
    Address available   250
    Address total       256
    ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
    Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
    Created             2019-08-21T09:43:11-05:00
    Status              available
    Zone                us-south-1
    VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    
  5. 서브넷을 사용하여 클러스터를 작성하거나 작업자 풀을 새로 작성하거나 기존 작업자 풀에 서브넷을 추가하십시오. 클러스터 작성 중에, 또는 구역에서 작업자 노드를 추가할 때 클러스터에 연결한 서브넷을 삭제하지 마십시오. 클러스터에서 사용한 VPC 서브넷을 삭제하면 서브넷의 IP 주소를 사용하는 로드 밸런서에 문제가 발생하고 새 로드 밸런서를 작성하지 못할 수 있습니다.

클래식 액세스를 위한 VPC 서브넷 작성

VPC를 작성할 때 클래식 액세스를 사용으로 설정하는 경우에는 클래식 액세스 기본 주소 접두부가 자동으로 작성되는 서브넷의 IP 범위를 결정합니다. 하지만, 클래식 액세스 VPC 서브넷의 기본 IP 범위가 IBM Cloud Kubernetes Service 제어 플레인의 서브넷과 충돌합니다. 따라서 그 대신 자동 기본 주소 접두부가 없는 VPC를 작성하고 사용자 정의 주소 접두부를 작성해야 합니다. 그 후 클러스터의 서브넷을 작성할 때마다 작성한 주소 접두부 범위 내에 서브넷을 작성합니다.

콘솔에서 클래식 액세스를 위한 VPC 서브넷 작성

  1. 기본 주소 접두부가 없는 클래식 액세스 VPC를 작성하십시오.
    1. Virtual Private Cloud 대시보드에서 작성을 클릭하십시오.
    2. 이름, 리소스 그룹 및 태그의 세부사항을 입력하십시오.
    3. 클래식 리소스에 대한 액세스 사용에 대한 선택란을 선택하고 각 구역의 기본 접두부 작성에 대한 선택란을 선택 취소하십시오.
    4. VPC의 지역을 선택하십시오.
    5. Virtual Private Cloud 작성을 클릭하십시오.
  2. 각 구역에서 주소 접두부를 작성하십시오.
    1. VPC의 이름을 클릭하여 세부사항을 보십시오.
    2. 주소 접두부 탭을 클릭하고 작성을 클릭하십시오.
    3. 서브넷을 작성할 각 구역에 대해 하나 이상의 주소 접두부를 작성하십시오. 주소 접두사는 다음 범위 중 하나에 속해야 합니다: 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255.
  3. 사용자의 주소 접두부를 사용하는 서브넷을 작성하십시오.
    1. VPC 서브넷 대시보드에서 작성을 클릭하십시오.
    2. 서브넷의 이름을 입력하고 클래식 액세스 VPC의 이름을 선택하십시오.
    3. 서브넷을 작성할 위치 및 구역을 선택하십시오.
    4. 이 구역에 대해 작성한 주소 접두부를 선택하십시오.
    5. 작성할 IP 주소의 수를 지정하십시오. VPC 서브넷은 클러스터에서 작업자 노드 및 로컬 로드 밸런서 서비스에 IP 주소를 제공하므로 충분한 IP 주소가 있는 VPC 서브넷을 작성하십시오(예: 256). VPC 서브넷에 있는 IP 수를 나중에 변경할 수 없습니다.
    6. 서브넷에 퍼블릭 게이트웨이를 연결할지 여부를 선택하십시오. 공용 네트워크 게이트웨이는 클러스터가 공용 엔드포인트(예: 다른 앱의 공용 URL) 또는 퍼블릭 클라우드 서비스 엔드포인트만 지원하는 IBM Cloud 서비스에 액세스해야 하는 경우에 필요합니다.
    7. 서브넷 작성을 클릭하십시오.
  4. 서브넷을 사용하여 클러스터를 작성하십시오. 클러스터 작성 중에, 또는 구역에서 작업자 노드를 추가할 때 클러스터에 연결한 서브넷을 삭제하지 마십시오. 클러스터에서 사용한 VPC 서브넷을 삭제하면 서브넷의 IP 주소를 사용하는 로드 밸런서에 문제가 발생하고 새 로드 밸런서를 작성하지 못할 수 있습니다.

CLI에서 클래식 액세스를 위한 VPC 서브넷 작성

  1. 명령행에서 IBM Cloud 계정에 로그인하고 VPC 클러스터를 작성할 IBM Cloud 지역 및 리소스 그룹을 대상으로 지정하십시오. 지원되는 지역은 다른 지역에 VPC 작성을 참조하십시오. 클러스터의 리소스 그룹은 VPC 리소스 그룹과 다를 수 있습니다. 프롬프트가 표시되면 IBM Cloud 인증 정보를 입력하십시오. 페더레이션 ID가 있는 경우 --sso 옵션을 사용하여 로그인합니다.
    ibmcloud login -r <region> [-g <resource_group>] [--sso]
    
  2. 기본 주소 접두부가 없는 클래식 액세스 VPC를 작성하십시오. 출력에서 VPC ID를 복사하십시오.
    ibmcloud is vpc-create <name> --classic-access --address-prefix-management manual
    
  3. 서브넷을 작성할 각 구역에 대해 하나 이상의 주소 접두부를 작성하십시오. 주소 접두사는 다음 범위 중 하나에 속해야 합니다: 10.0.0.0 - 10.255.255.255, 172.17.0.0 - 172.17.255.255, 172.21.0.0 - 172.31.255.255, 192.168.0.0 - 192.168.255.255.
    ibmcloud is vpc-address-prefix-create <prefix_name> <vpc_id> <zone> <prefix_range>
    
  4. 각 구역에서 사용자의 주소 접두부를 사용하는 서브넷을 작성하십시오. 이 명령의 옵션에 대한 자세한 정보는 CLI 참조를 참조하십시오. VPC 서브넷은 클러스터에서 작업자 노드 및 로컬 로드 밸런서 서비스에 IP 주소를 제공하므로 충분한 IP 주소가 있는 VPC 서브넷을 작성하십시오(예: 256). VPC 서브넷에 있는 IP 수를 나중에 변경할 수 없습니다.
    ibmcloud is subnet-create <subnet_name> <vpc_id> --zone <vpc_zone> --ipv4-address-count <number_of_ip_address> --ipv4-cidr-block <prefix_range>
    
  5. 선택사항: 서브넷에 공용 네트워크 게이트웨이를 접속하십시오. 공용 네트워크 게이트웨이는 클러스터가 공용 엔드포인트(예: 다른 앱의 공용 URL) 또는 퍼블릭 클라우드 서비스 엔드포인트만 지원하는 IBM Cloud 서비스에 액세스해야 하는 경우에 필요합니다.
    1. 각 구역에서 퍼블릭 게이트웨이를 작성하십시오. <cluster>-<zone>-gateway 형식으로 퍼블릭 게이트웨이의 이름 지정을 고려하십시오. 출력에서 퍼블릭 게이트웨이의 ID를 기록해 두십시오.
      ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
      
      출력 예
      ID               26466378-6065-4716-a90b-ac7ed7917c63
      Name             mycluster-us-south-1-gateway
      Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
      Status           pending
      Created          2019-09-20T16:27:32-05:00
      Zone             us-south-1
      VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
      Resource group   -
      
    2. 공용 게이트웨이 및 서브넷의 ID를 사용하여 서브넷에 공용 게이트웨이를 연결하십시오.
      ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
      
      출력 예
      ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
      Name                mysubnet1
      IPv4 CIDR           10.240.xx.xx/24
      Address available   250
      Address total       256
      ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
      Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
      Created             2019-08-21T09:43:11-05:00
      Status              available
      Zone                us-south-1
      VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
      
  6. 서브넷을 사용하여 클러스터를 작성하십시오. 클러스터 작성 중에, 또는 구역에서 작업자 노드를 추가할 때 클러스터에 연결한 서브넷을 삭제하지 마십시오. 클러스터에서 사용한 VPC 서브넷을 삭제하면 서브넷의 IP 주소를 사용하는 로드 밸런서에 문제가 발생하고 새 로드 밸런서를 작성하지 못할 수 있습니다.

퍼블릭 게이트웨이를 사용하여 공용 네트워크 트래픽을 서브넷으로 제한

적은 수의 작업자 노드가 VPC 서브넷 퍼블릭 게이트웨이를 통한 외부 액세스를 가질 수 있도록 허용하여 IBM Cloud® Kubernetes Service 클러스터의 보안을 향상시킵니다.

작업자 노드의 팟(Pod)이 공용 외부 엔드포인트에 연결되어야 하는 경우에는 퍼블릭 게이트웨이를 해당 작업자 노드가 있는 서브넷에 연결할 수 있습니다. 예를 들어 VPC 클러스터가 자동으로 프라이빗 클라우드 서비스 엔드포인트를 지원하는 다른 IBM Cloud 서비스(예: IBM Cloud Container Registry)에 연결될 수 있습니다. 하지만 퍼블릭 클라우드 서비스 엔드포인트만 지원하는 IBM Cloud 서비스에 액세스해야 하는 경우 팟(Pod)에서 공용 네트워크를 통해 요청을 전송할 수 있도록 서브넷에 공용 게이트웨이를 접속시킬 수 있습니다.

퍼블릭 게이트웨이를 클러스터에 있는 하나의 서브넷에만 연결하여 클러스터에서 이 네트워크 트래픽을 격리할 수 있습니다. 그런 다음 연결된 퍼블릭 게이트웨이를 사용하여 외부 엔드포인트에 대한 액세스 권한이 필요한 앱 팟(Pod)을 서브넷에만 배치할 수 있습니다.

VPC 클러스터에서 서브넷은 하나의 구역으로 제한됩니다. 퍼블릭 게이트웨이를 하나의 서브넷에만 연결하고 해당 서브넷의 작업자 노드에 대해서만 공용 액세스 권한이 필요한 앱 팟(Pod)을 스케줄하는 경우 이 팟(Pod)은 클러스터의 하나의 구역으로 격리됩니다.

  1. 클러스터가 배치된 VPC의 지역을 대상으로 합니다.

    ibmcloud target -r <region>
    
  2. 작업자 노드가 있는 구역에 퍼블릭 게이트웨이가 있는지 확인하십시오. 하나의 VPC내에서는 구역마다 하나의 퍼블릭 게이트웨이만 작성할 수 있지만 해당 퍼블릭 게이트웨이는 구역 내의 여러 서브넷에 접속할 수 있습니다.

    ibmcloud is public-gateways
    

    출력 예

    ID                                     Name                                       VPC                          Zone         Floating IP                  Created                     Status      Resource group
    26426426-6065-4716-a90b-ac7ed7917c63   test-pgw                                   testvpc(36c8f522-.)          us-south-1   169.xx.xxx.xxx(26466378-.)   2019-09-20T16:27:32-05:00   available   -
    2ba2ba2b-fffa-4b0c-bdca-7970f09f9b8a   pgw-73b62bc0-b53a-11e9-9838-f3f4efa02374   team3(ff537d43-.)            us-south-2   169.xx.xxx.xxx(2ba9a280-.)   2019-08-02T10:30:29-05:00   available   -
    
    • 작업자가 있는 구역과 클러스터가 있는 VPC에서 이미 퍼블릭 게이트웨이를 보유하고 있는 경우 게이트웨이의 ID를 기록해 두십시오.

    • 작업자가 있는 구역 및 클러스터가 있는 VPC에 공용 게이트웨이가 없으면 공용 게이트웨이를 작성하십시오. <cluster>-<zone>-gateway 형식으로 퍼블릭 게이트웨이의 이름 지정을 고려하십시오. 출력에서 퍼블릭 게이트웨이의 ID를 기록해 두십시오.

      ibmcloud is public-gateway-create <gateway_name> <VPC_ID> <zone>
      

      출력 예

      ID               26466378-6065-4716-a90b-ac7ed7917c63
      Name             mycluster-us-south-1-gateway
      Floating IP      169.xx.xx.xxx(26466378-6065-4716-a90b-ac7ed7917c63)
      Status           pending
      Created          2019-09-20T16:27:32-05:00
      Zone             us-south-1
      VPC              myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
      Resource group   -
      
  3. 클러스터의 작업자 노드를 나열합니다. 퍼블릭 게이트웨이를 사용한 구역의 경우 하나의 작업자 노드에 대한 기본 IP를 기록해 두십시오.

    ibmcloud ks worker ls -c <cluster_name_or_ID>
    

    출력 예

    ID                                                   Primary IP     Flavor   State    Status   Zone         Version
    kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac   10.240.02.00   c2.2x4   normal   Ready    us-south-2   1.32.5
    kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623   10.240.01.00   c2.2x4   normal   Ready    us-south-1   1.32.5
    
  4. 작업자 노드에 대해 설명하십시오. 다음 예의 레이블 출력에서 레이블 ibm-cloud.kubernetes.io/subnet-id의 서브넷 ID를 기록해 두십시오(예: 5f5787a4-f560-471b-b6ce-20067ac93439).

    kubectl describe node <worker_primary_ip>
    

    출력 예

    NAME:               10.240.01.00
    Roles:              <none>
    Labels:             arch=amd64
    beta.kubernetes.io/arch=amd64
    beta.kubernetes.io/instance-type=c2.2x4
    beta.kubernetes.io/os=linux
    failure-domain.beta.kubernetes.io/region=us-south
    failure-domain.beta.kubernetes.io/zone=us-south-1
    ibm-cloud.kubernetes.io/ha-worker=true
    ibm-cloud.kubernetes.io/iaas-provider=gc
    ibm-cloud.kubernetes.io/internal-ip=10.240.0.77
    ibm-cloud.kubernetes.io/machine-type=c2.2x4
    ibm-cloud.kubernetes.io/os=UBUNTU_20_64
    ibm-cloud.kubernetes.io/region=us-south
    ibm-cloud.kubernetes.io/sgx-enabled=false
    ibm-cloud.kubernetes.io/subnet-id=5f5787a4-f560-471b-b6ce-20067ac93439
    ibm-cloud.kubernetes.io/worker-id=kube-bl25g33d0if1cmfn0p8g-vpcprod-default-00001093
    ibm-cloud.kubernetes.io/worker-pool-id=bl25g33d0if1cmfn0p8g-5aa474f
    ibm-cloud.kubernetes.io/worker-pool-name=default
    ibm-cloud.kubernetes.io/worker-version=1.15.3_1517
    ibm-cloud.kubernetes.io/zone=us-south-1
    kubernetes.io/arch=amd64
    kubernetes.io/hostname=10.240.0.77
    kubernetes.io/os=linux
    Annotations:        node.alpha.kubernetes.io/ttl: 0
    ...
    
  5. 공용 게이트웨이 및 서브넷의 ID를 사용하여 서브넷에 공용 게이트웨이를 연결하십시오. 이 구역의 해당 서브넷에 배치된 작업자 노드에는 외부 엔드포인트에 대한 액세스 권한이 있습니다.

    ibmcloud is subnet-update <subnet_ID> --public-gateway-id <gateway_ID>
    

    출력 예

    ID                  91e946b4-7094-46d0-9223-5c2dea2e5023
    Name                mysubnet1
    IPv4 CIDR           10.240.xx.xx/24
    Address available   250
    Address total       256
    ACL                 allow-all-network-acl-36c8f522-4f0d-400c-8226-299f0b8198cf(585bc142-5392-45d4-afdd-d9b59ef2d906)
    Gateway             mycluster-us-south-1-gateway(26466378-6065-4716-a90b-ac7ed7917c63)
    Created             2019-08-21T09:43:11-05:00
    Status              available
    Zone                us-south-1
    VPC                 myvpc(36c8f522-4f0d-400c-8226-299f0b8198cf)
    
  6. 앱의 배포 파일에서 4단계에서 찾은 서브넷 ID 레이블에 대한 선호도 규칙을 추가합니다.

    예제 YAML의 친화도 섹션에서 ibm-cloud.kubernetes.io/subnet-id은(는) key이고 <subnet_ID>은(는) value입니다.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: with-node-affinity
    spec:
      template:
        spec:
          affinity:
            nodeAffinity:
              requiredDuringSchedulingIgnoredDuringExecution:
                nodeSelectorTerms:
                - matchExpressions:
                  - key: ibm-cloud.kubernetes.io/subnet-id
                    operator: In
                    values:
                    - <subnet_ID>
    ...
    
  7. 업데이트된 배치 구성 파일을 적용하십시오.

    kubectl apply -f with-node-affinity.yaml
    
  8. 앱 팟(Pod)이 올바른 작업자 노드에 배치되었는지 확인하십시오.

    1. 클러스터 내의 팟(Pod)을 나열하십시오. 출력에서 앱의 팟(Pod)을 식별하십시오. 해당 팟(Pod)이 있는 작업자 노드의 NODE 사설 IP 주소를 기록해 두십시오.

      kubectl get pods -o wide
      

      이 출력 예에서 앱 팟(Pod) cf-py-d7b7d94db-vp8pq는 IP 주소 10.240.01.00의 작업자 노드에 있습니다.

      NAME                   READY     STATUS              RESTARTS   AGE       IP               NODE
      cf-py-d7b7d94db-vp8pq  1/1       Running             0          15d       172.30.xxx.xxx   10.240.01.00
      
    2. 클러스터의 작업자 노드를 나열합니다. 출력에서 퍼블릭 게이트웨이가 접속된 구역의 작업자 노드를 찾으십시오. 이전 단계에서 식별한 사설 IP 주소의 작업자 노드가 이 구역에 배치되었는지 확인하십시오.

      ibmcloud ks worker ls --cluster <cluster_name_or_ID>
      

      출력 예

      ID                                                   Primary IP     Flavor   State    Status   Zone         Version
      kube-bl25g33d0if1cmfn0p8g-vpctest-default-000005ac   10.240.02.00   c2.2x4   normal   Ready    us-south-2   1.32.5
      kube-bl25g33d0if1cmfn0p8g-vpctest-default-00000623   10.240.01.00   c2.2x4   normal   Ready    us-south-1   1.32.5
      
  9. 선택사항: 액세스 제어 목록(ACL)을 사용하여 클러스터 네트워크 트래픽을 제어하는 경우 팟(Pod)이 액세스해야 하는 외부 공용 엔드포인트에 대한 ingress 및 egress를 허용하도록 이 서브넷의 ACL에서 인바운드 및 아웃바운드 규칙을 작성하십시오.