생성할 클러스터 수 결정

다중 작업자 노드, 구역 및 클러스터 간에 앱을 분배하면 사용자에게 작동 중지 시간이 발생할 가능성이 낮아질 수 있습니다. 로드 밸런싱 및 격리 등의 기본 제공 기능을 사용하면 호스트, 네트워크 또는 앱에서 잠재적 장애가 발생할 때 복원성이 높아집니다.

생성하는 클러스터의 수는 워크로드, 회사 정책 및 규정, 비즈니스 요구사항, 고객과 맺은 서비스 수준 계약, 사용하려는 리소스, 컴퓨팅 리소스로 수행하려는 작업에 따라 달라집니다.

• 다중 클러스터: 다중 클러스터는 일반적으로 관리하기가 더 복잡하지만, 다음과 같은 중요한 목표를 달성하는 데 도움이 될 수 있습니다.

  • 워크로드를 격리하는 데 필요한 보안 정책을 준수합니다.
  • 여러 버전의 Kubernetes 또는 기타 클러스터 소프트웨어(예: Calico)에서 앱을 실행하는 방법을 테스트합니다.
  • 다양한 지역의 사용자를 위해 더 높은 성능을 달성하세요.
  • 네임스페이스 수준에서 여러 RBAC 정책을 사용자 지정하고 관리하는 대신 클러스터 인스턴스 수준에서 액세스를 구성하여 클러스터 내 액세스를 제어하는 사용자 액세스를 간소화하세요.
  • 워커 노드 수를 더 적게 유지하세요. 가상 머신을 확장할 때 네트워크 대역폭은 약 1000Mbps입니다. 클러스터에 수백 개의 워커 노드가 필요한 경우, 구성을 노드 수가 더 적은 여러 클러스터로 나누거나 베어 메탈 노드를 주문할 수 있습니다.
  • 5,000개 이상의 서비스와 같이 더 많은 수의 서비스 통합 을 허용합니다.
  • 앱에 더 높은 가용성을 제공하세요. 다중 존 클러스터에서 3개의 존을 사용하는 것과 마찬가지로, 여러 존에 걸쳐 세 개의 클러스터를 구성함으로써 애플리케이션의 가용성을 더욱 높일 수 있습니다.
  • 업무량을 처리할 수 있는 더 작은 규모의 기계를 구입하여 비용을 절감하십시오.

• 더 많은 워커 노드가 있는 하나의 클러스터: 클러스터 수가 적으면 고정 리소스에 대한 운영 노력과 클러스터당 비용을 줄이는 데 도움이 될 수 있습니다. 클러스터를 더 만드는 대신 하나의 클러스터에 워커 풀을 추가하여 앱 및 서비스 구성 요소에 사용할 수 있는 컴퓨팅 리소스의 종류를 달리할 수 있습니다. 앱 개발 시 앱을 사용하는 리소스는 동일한 구역에 있습니다. 동일한 구역에 없으면 다중 구역에 밀접하게 연결되어서 대기 시간, 대역폭 또는 상관된 실패를 가정할 수 있습니다. 하지만 클러스터가 하나뿐인 경우에는 네임스페이스, 리소스 할당량, 레이블을 활용하여 클러스터를 체계적으로 관리하는 것이 더욱 중요해집니다.

필요한 위치 수 결정

클러스터는 단일 위치 또는 여러 위치의 워커 노드에 복제본을 배포할 수 있습니다. 이 선택은 다음 섹션에서 사용할 수 있는 클러스터 유형에 영향을 줄 수 있습니다.

세 개의 구역 간에 워크로드를 분배하면 구역이 사용 불가능하게 되는 경우에 앱의 고가용성이 보장됩니다. HA 구성을 위해 IBM Cloud SLA(Service Level Agreements)를 충족하도록 모든 세 개의 가용성 구역에 공평하게 작업자 노드를 분산시켜야 합니다.

구역 실패는 모든 실제 컴퓨팅 호스트 및 NFS 스토리지에 영향을 줍니다. 실패에는 전원, 냉각, 네트워킹 또는 가동 중단 및 자연 재해(예: 홍수, 지진 및 허리케인)가 포함됩니다. 영역 장애로부터 보호하려면 외부 로드 밸런서에 의해 부하가 분산되는 두 개의 서로 다른 영역에 클러스터를 두거나, 여러 영역에 마스터를 분산하는 다중 영역 위치에 클러스터를 만들거나, 다른 영역에 두 번째 클러스터를 설정하는 것을 고려해야 합니다.

클러스터 유형 선택

사용 가능한 작업자 노드 특성 및 격리 레벨은 사용할 컨테이너 플랫폼, 클러스터 유형 및 인프라 제공자와 클러스터를 작성할 IBM Cloud Kubernetes Service 위치에 따라 다릅니다. 클래식, VPC 또는 Satellite 클러스터 중에서 선택할 수 있습니다. 필요한 클러스터 유형은 클러스터 수와 위치에 대해 내린 결정에 따라 결정됩니다.

VPC 클러스터

워커 노드는 VPC 인프라 상에서 가상 서버 인스턴스로 프로비저닝됩니다. VPC는 새로 생성되는 클러스터에 권장되는 인프라 유형입니다. 기본적으로 네트워크 격리 기능을 제공하며, 전용 호스트 및 ‘기본적으로 보안 유지(Secure by Default)’ 기능을 포함한 최신 ‘ IBM Cloud Kubernetes Service ’ 기능을 지원합니다.

Satellite 클러스터

워커 노드는 온프레미스 하드웨어를 비롯해 AWS, Azure, GCP 등 다른 클라우드 제공업체의 가상 머신을 포함한 사용자 자체 인프라에 프로비저닝됩니다. IBM Cloud 데이터 센터 외부에서 IBM Cloud 에서 관리하는 클러스터를 실행해야 할 경우 Satellite 를 사용하십시오.

클래식 클러스터

워커 노드는 IBM Cloud 클래식 인프라의 가상 머신 또는 베어 메탈 머신에 프로비저닝됩니다. 베어 메탈 워커 노드, 소프트웨어 정의 스토리지(SDS) 플레버 또는 기존 클래식 인프라 리소스와의 연결이 필요한 경우 Classic을 사용하십시오.

클러스터용 운영 체제 선택

사용 가능한 운영 체제는 선택한 클러스터 유형에 따라 다릅니다.

Ubuntu 24

자세한 내용은 Ubuntu 24.04 릴리즈 노트를 참조하세요. Ubuntu 24에서는 NTP가 timesyncd 을 사용하며 관련 명령이 업데이트될 수 있습니다.

새로운 OS로 전환하시나요? 새 Ubuntu 버전으로 마이그레이션하기를 참조하세요.

클러스터 이름 지정 전략 정의

이름 충돌을 방지하려면 계정 내 리소스 그룹 및 지역 전체에서 클러스터에 고유한 이름을 지정하는 것을 고려하십시오. 클러스터가 생성된 후에는 클러스터 이름을 변경할 수 없습니다.

각 클러스터의 워커 노드 수를 결정합니다

클러스터에 대해 설정하는 가용성 레벨은 IBM Cloud HA SLA(Service Level Agreement) 이용 약관에 따른 적용 범위에 영향을 줍니다. 예를 들어, SLA 이용 약관에 따라 전체 HA 적용을 받으려면 최소 총 여섯 개의 작업자 노드, 즉 세 개의 구역에 고르게 분산된 구역당 두 개의 작업자 노드로 다중 구역 클러스터를 설정해야 합니다.

클러스터의 총 작업자 노드 수에 따라 클러스터의 앱에서 사용할 수 있는 컴퓨팅 용량이 결정됩니다. 클러스터에 여러 개의 워커 노드를 구성하면, 워커 노드 중 하나에 장애가 발생했을 때 전체 시스템을 보호할 수 있습니다. 워커 노드 장애에는 전원, 냉각, 네트워크와 같은 하드웨어 장애와 VM 자체의 문제가 포함될 수 있습니다.

• 다중 존 클러스터 Classic VPC: 존당 최소 두 개의 워커 노드를 확보할 계획이므로, 총 세 개의 존에 걸쳐 여섯 개의 노드가 배치됩니다. 또한 총 워크로드의 필요한 용량 중 최소 150%가 되도록 클러스터의 총 용량을 계획하십시오. 이에 따라 한 개의 구역이 작동 중지되면 워크로드를 유지보수하는 데 사용할 수 있는 리소스를 보유하게 됩니다.

• 단일 영역 클러스터: 클러스터에 최소 3개의 워커 노드를 포함하도록 계획하십시오. 또한 사용자는 클러스터에 사용 가능한 CPU 및 메모리 용량 중에 한 개의 추가 노드분을 필요로 합니다. 앱에 필요한 리소스가 워커 노드에서 사용할 수 있는 리소스보다 적다면, 하나의 워커 노드에 배포하는 파드 수를 제한할 수 있습니다.

다음 사항에 유의하십시오.

• 클러스터 오토스케일러 를 사용해 워크로드를 감당할 수 있는 충분한 워커 노드가 항상 있는지 확인해 보세요.
• Kubernetes는 클러스터에 속할 수 있는 작업자 노드의 최대수를 제한합니다. 자세한 내용은 워커 노드 및 포드 할당량에 대한 내용을 참조하십시오.

워커 노드 플레이버 선택

워커 노드는 물리적 하드웨어에서 실행되는 분산 컴퓨팅 클러스터( VM )입니다. 작업자 노드 특성은 사용자가 작업자 노드를 프로비저닝할 때 확보할 수 하는 CPU, 메모리 및 디스크 용량과 같은 컴퓨팅 리소스에 대해 설명합니다.  동일한 특성의 작업자 노드는 작업자 노드 풀에서 그룹화됩니다.

클러스터 유형을 선택할 때 워커 노드 플레이버 위치와 머신 유형이 결정에 어떤 영향을 미치는지 이미 생각해 보셨을 것입니다. 워커 노드 플레이버를 선택할 때 다음 사항을 고려하세요.

• 테넌시: 필요한 하드웨어 격리 수준에 따라 가상 작업자 노드를 여러 IBM 고객이 공유(멀티 테넌시) 또는 사용자 전용(단일 테넌시) 노드로 설정할 수 있습니다. 베어메탈 머신은 항상 전용으로 설정됩니다. 공유 노드와 전용 노드 중 어느 쪽을 선택할지 결정할 때는, 앱 환경에 필요한 인프라 격리 수준과 규정 준수 요건에 대해 법무 부서와 상의해 보는 것이 좋습니다.

  • 공유: CPU 및 메모리와 같은 물리적 리소스는 동일한 물리적 하드웨어에 배포된 모든 가상 머신 간에 공유됩니다. 모든 가상 머신이 독립적으로 실행될 수 있도록 보장하기 위해, 가상 머신 모니터(하이퍼바이저라고도 함)는 실제 리소스를 격리된 엔티티로 세그먼트화하고 이를 전용 리소스로서 가상 머신에 할당합니다(하이퍼바이저 격리). 기반 하드웨어의 비용이 여러 고객 간에 공유되므로, 공유 노드는 일반적으로 전용 노드보다 비용이 저렴합니다.
  • 전용: 모든 물리적 리소스가 나만을 위한 전용 리소스입니다. 동일한 실제 호스트에서 가상 머신으로서 여러 작업자 노드를 배치할 수 있습니다. 멀티 테넌트 설정과 유사하게, 하이퍼바이저는 모든 작업자 노드가 사용 가능한 실제 리소스의 해당 공유를 가져오도록 보장합니다.

• 머신 유형: 선택할 수 있는 머신 유형이 여러 가지 있습니다.

  • 가상 머신: 유연성 향상, 프로비저닝 시간 단축, 자동 확장성 기능, 비용 효율적인 가격을 원한다면 가상 머신을 사용하세요. 테스트 및 개발 환경, 스테이징 및 프로덕션 환경, 마이크로서비스 및 비즈니스 앱과 같은 가장 일반적인 용도의 유스 케이스에 VM을 사용할 수 있습니다. 하지만 성능 면에서는 타협이 필요합니다.

  • 베어 메탈(물리적) 서버: 데이터 또는 RAM을 많이 사용하는 워크로드에 고성능 컴퓨팅이 필요한 경우, 베어 메탈 워커 노드로 클러스터를 구성하는 것을 고려해 보세요. 워크로드에 대한 격리 및 리소스 이용을 사용자가 완전히 제어하므로, 사용자는 베어메탈 머신을 사용하여 환경에 대한 HIPAA 및 PCI 규제 준수를 달성할 수 있습니다. 베어메탈은 메모리 또는 CPU와 같이 머신의 실제 리소스에 직접 액세스를 제공합니다. 이 설정은 호스트에서 실행되는 가상 머신에 실제 리소스를 할당하는 가상 머신 하이퍼바이저를 제거합니다. 대신, 모든 베어메탈 머신의 리소스가 작업자 전용으로만 사용되므로 리소스를 공유하거나 성능을 저하시키는 "시끄러운 이웃(noisy neighbors)" 문제를 신경쓰지 않아도 됩니다. 실제 특성에는 가상 특성보다 더 많은 로컬 스토리지가 있으며, 일부에는 데이터 가용성 향상을 위한 RAID 구성이 있습니다. 워커 노드의 로컬 스토리지는 단기 처리에만 사용되며, 워커 노드를 업데이트하거나 재로드할 때 주 디스크와 보조 디스크의 데이터는 모두 삭제됩니다. 베어 메탈 작업자는 기존 클러스터와 VPC 베어 메탈 구성 모두에서 이용할 수 있습니다.

    베어 메탈 워커 노드의 요금 청구 방식은 인프라 유형에 따라 다릅니다. 기존의 베어 메탈 서버는 월 단위로 요금이 청구됩니다. 클래식 베어 메탈 서버를 해당 월이 끝나기 전에 해지하더라도, 해당 월 말일까지 요금이 청구됩니다. 클래식 베어 메탈 서버를 주문하거나 취소한 후에는 IBM Cloud 인프라 계정에서 수동으로 처리되므로, 완료까지 영업일 기준 1일 이상 소요될 수 있습니다. VPC 베어 메탈 서버는 최소 약정 기간 없이 시간 단위로 요금이 청구됩니다.

  • SDS 머신: 소프트웨어 정의 스토리지(SDS) 버전에는 물리적 로컬 스토리지를 위한 추가 원시 디스크가 있습니다. 주 로컬 디스크 및 보조 로컬 디스크와 달리, 이러한 원시 디스크는 워커 노드 업데이트 또는 재로드 시 데이터가 삭제되지 않습니다. 데이터가 컴퓨팅 노드와 공존하므로 SDS 머신은 고성능 워크로드에 적합합니다. SDS(Software-Defined Storage) 특성은 클래식 클러스터에서만 사용 가능하며 VPC 클러스터에서는 지원되지 않습니다.

    워크로드에 대한 격리 및 리소스 이용을 사용자가 완전히 제어하므로, 사용자는 SDS 머신을 사용하여 환경에 대한 HIPAA 및 PCI 규제 준수를 달성할 수 있습니다.

    일반적으로 다음과 같은 경우에 SDS 머신을 사용합니다. * 다음과 같은 SDS 애드온을 사용하는 경우 Portworx SDS 애드온을 사용하는 경우, SDS 기기를 사용하십시오. * 앱이 StatefulSet 로컬 스토리지가 필요한 앱이라면, SDS 머신을 사용하고 Kubernetes 로컬 영구 볼륨을 프로비저닝할 수 있습니다. * 추가 원시 로컬 스토리지를 요구하는 사용자 정의 앱이 있는 경우입니다.

• 비용: 일반적으로 부하가 큰 작업은 베어 메탈 물리적 서버에서 실행하는 것이 더 적합하지만, 비용 효율적인 테스트 및 개발 작업의 경우 공유 또는 전용 하드웨어 기반의 가상 머신을 선택할 수 있습니다.

• 위치: 클러스터를 배치할 위치를 결정합니다. 원하는 경우 필요한 클러스터 수 또는 클러스터 유형도 알려줄 수 있습니다. 예를 들어, 몬트리올에 위치해야 한다는 것을 알고 있다면 선택의 폭을 좁히는 데 도움이 됩니다. 사용 가능한 위치 를 확인하세요.

• 규모: 특히 고성능 시스템에서 처리할 때 효율성이 높아지도록 설계된 워크로드의 경우, 더 큰 노드가 더 작은 노드보다 비용 효율적일 수 있습니다. 그러나 대규모 워커 노드가 다운될 경우, 클러스터에 충분한 용량이 확보되어 있어 모든 워크로드 포드를 클러스터 내의 다른 워커 노드로 안전하게 재할당할 수 있도록 해야 합니다. 소규모 워커 노드를 사용하면 안전하게 확장할 수 있습니다. 용량에 대해 자세히 알아보세요.

• GPU: GPU 머신을 사용하여 AI, 머신러닝, 추론 등과 같은 연산 집약적인 워크로드에 필요한 처리 시간을 단축할 수 있습니다.

• 저장소: 모든 VM 에는 OS 파일 시스템, 컨테이너 런타임, kubelet 등 VM 의 실행에 필요한 정보를 저장하기 위한 디스크가 기본으로 포함되어 있습니다. 작업자 노드에 있는 로컬 스토리지는 단기 처리만을 위한 것이며, 작업자 노드를 삭제, 다시 로드, 대체 또는 업데이트하면 스토리지 디스크의 내용은 삭제됩니다. 또한, 클래식 및 VPC 인프라는 디스크 설정에 따라 다릅니다.

  • 클래식 VMs: 클래식 VM에는 연결된 두 개의 디스크가 있습니다. 주 저장 디스크에는 OS 파일 시스템용으로 25GB가 할당되어 있으며, 보조 저장 디스크에는 컨테이너 런타임 및 kubelet 와 같은 데이터를 저장하기 위한 100GB가 할당되어 있습니다. 신뢰성을 확보하기 위해 주 저장소 및 보조 저장소 볼륨은 스토리지 영역 네트워킹(SAN) 대신 로컬 디스크로 구성됩니다. 신뢰성을 갖게 되면 로컬 디스크에 바이트를 직렬화하는 경우 처리량이 많아지고 네트워크 장애로 인한 파일 시스템 성능 저하를 줄일 수 있습니다. 보조 디스크는 기본적으로 암호화되어 있습니다.
  • VPC 컴퓨팅 VM: VPC VM에는 네트워크를 통해 연결된 블록 스토리지 볼륨인 기본 디스크가 하나 있습니다. 스토리지 계층은 기타 네트워킹 계층으로부터 분리되지 않고, 네트워크와 스토리지 트래픽 둘 모두 동일한 네트워크에 라우팅됩니다. 기본 스토리지 디스크는 OS 파일 시스템, 컨테이너 런타임 및 kubelet 등의 데이터를 저장하는 데 사용되며 기본적으로 암호화됩니다. VPC 클러스터의 경우 워커 노드에 보조 디스크를 프로비저닝할 수도 있습니다. 이 선택적 디스크는 귀하의 계정에 프로비저닝되어 있으며, VPC 콘솔에서 확인할 수 있습니다. 이러한 디스크에 대한 요금은 각 작업자의 비용과 별개이며 청구서에 다른 항목으로 표시됩니다. 이러한 보조 볼륨도 계정의 할당량 사용량에 포함됩니다. 기본 포드 강제 종료(default pod evictions)를 방지하기 위해, Kubernetes 데이터 디스크(클래식 환경에서는 보조 디스크, VPC 환경에서는 기본 부팅 디스크) 용량의 10%가 시스템 구성 요소를 위해 예약됩니다.

  상태 저장 앱에서 데이터는 앱의 시작 및 실행을 유지하는 중요한 역할을 수행합니다. 데이터가 잠재적인 실패로부터 복구할 수 있을 정도로 가용성이 높은지 확인하십시오. IBM Cloud Kubernetes Service에서 데이터를 지속하기 위한 여러 옵션을 선택할 수 있습니다. 예를 들어, Kubernetes 고유의 지속적 볼륨을 사용하여 NFS 스토리지를 프로비저닝하거나 IBM Cloud 데이터베이스 서비스를 사용하여 데이터를 저장할 수 있습니다. 자세한 내용은 ‘고가용성 데이터 계획’을 참조하십시오.

  워크로드를 지원하기에 적합한 스토리지 구성을 갖춘 맛 또는 기기 유형을 선택하십시오. 일부 특성에는 다음과 같은 디스크와 스토리지 구성이 혼합되어 있습니다. 예를 들어, 일부 특성에는 원시 SSD 보조 디스크와 함께 SATA 기본 디스크가 있을 수 있습니다.

사용 가능한 맛의 목록은 VPC 맛 또는 클래식 맛을 참조하세요.

리소스에 대한 워커 노드 용량 결정하기

워커 노드의 성능을 최대한 활용하려면 리소스를 설정할 때 다음 사항을 고려하세요:

• 앱이 수행하는 작업 고려하기: 먼저 앱 크기를 사용 가능한 워커 노드 플레이버 중 하나의 용량에 맞춰 조정합니다. 또한 앱이 대용량 이미지나 많은 수의 이미지를 불러오는지 여부도 고려해 보세요. 이러한 이미지는 워커 노드의 로컬 저장 공간을 차지할 수 있기 때문입니다.

• 코어 강도 유지: 각 머신에는 특정 수의 코어가 있습니다. 앱의 워크로드에 따라 코어당 팟(Pod)의 수에 대한 한계를 설정하십시오(예: 10).

• 노드 과부하 방지: 스케줄링이 필요할 수 있는 다른 파드를 위한 여유 공간을 확보하기 위해 워커 노드의 사용률을 약 75% 수준으로 유지하십시오. 앱이 작업자 노드에서 사용할 수 있는 리소스보다 더 많은 리소스를 필요로 하는 경우 이 요구사항을 충족시킬 수 있는 다른 작업자 노드 특성을 사용하십시오. 앱의 워크로드에 따라 노드당 팟(Pod)의 수에 대한 한계를 설정하십시오(예: 40).

• 서비스 선택: 몇 개의 클러스터를 만들지 고민할 때 몇 개의 서비스 통합을 포함하기로 결정했나요? 이러한 통합 서비스와 추가 기능은 클러스터 리소스를 소비하고 이에 영향을 미치는 포드를 생성할 수 있습니다.

• 앱의 복제본: 원하는 작업자 노드의 수를 판별하기 위해 실행할 앱의 복제본 수를 고려할 수도 있습니다. 예를 들어, 워크로드에 32개의 CPU 코어가 필요함을 알게 되고 앱의 16개의 복제본을 실행할 계획인 경우 각 복제본 팟(Pod)에는 2개의 CPU 코어가 필요합니다. 작업자 노드당 한 개의 앱 팟(Pod)만 실행할 경우 이 구성을 지원하도록 클러스터 유형에 대한 적절한 수의 작업자 노드를 주문할 수 있습니다.

• 런타임 요구 사항을 위한 공간을 남겨두세요: 워커 노드는 운영 체제 또는 컨테이너 런타임과 같은 필수 구성 요소를 실행하기 위해 일정량의 CPU 및 메모리 리소스를 예약해야 합니다.

  예약 용량 및 예약 인스턴스는 지원되지 않습니다.

클러스터 내에 생성할 네임스페이스의 개수를 선택합니다

클러스터를 공유하는 여러 팀과 프로젝트가 있을 때 다중 네임스페이스를 설정하십시오. 네임스페이스는 리소스 할당량 및 기본 제한를 사용하여 클러스터 리소스를 분할하는 방법입니다. 새 네임스페이스 작성 시 적절한 RBAC 정책을 설정하여 액세스를 제어하십시오. 자세한 내용은 ‘ Kubernetes ’ 문서의 “네임스페이스를 사용하여 클러스터 공유하기”를 참조하십시오.

사용자가 12명인 소형 클러스터와 유사한 리소스(예: 동일한 소프트웨어의 다른 버전)가 있는 경우 다중 네임스페이스가 필요하지 않을 수 있습니다. 대신 레이블을 사용할 수 있습니다.

컨테이너 격리 및 보안 에서 이 결정에 대한 보안 정보를 검토하세요.

네임스페이스에 대한 리소스 요청 및 제한 설정하기

모든 팀이 클러스터 내에서 서비스를 배포하고 애플리케이션을 실행하는 데 필요한 리소스를 확보할 수 있도록 하려면, 각 네임스페이스에 대해 리소스 할당량을 설정해야 합니다. 리소스 할당량은 배포 제약 조건을 결정하며, 여기에는 배포할 수 있는 ‘ Kubernetes ’ 리소스의 수와 해당 리소스가 사용할 수 있는 CPU 및 메모리 양 등이 포함됩니다. 할당량을 설정한 후에 사용자는 자체 배치의 리소스 요청 및 한계를 포함해야 합니다.

배포를 생성할 때는 앱의 포드가 리소스 구성이 가장 이상적인 머신에만 배포되도록 제한을 설정하세요. 예를 들어, 데이터베이스 애플리케이션을 md1c.28x512.4x4tb와 같이 상당한 양의 로컬 디스크 스토리지가 있는 베어메탈 머신으로 제한하려고 할 수 있습니다.

앱의 고가용성 확보

컨테이너 및 팟(Pod)은 설계상 수명이 짧으며 예상치 않게 실패할 수 있습니다. 예를 들어, 앱에서 오류가 발생하는 경우 컨테이너 또는 팟(Pod)이 손상될 수 있습니다. 앱의 가용성을 높이려면, 워크로드를 처리할 수 있는 충분한 인스턴스는 물론, 장애 발생 시를 대비한 추가 인스턴스도 확보해야 합니다. 자동 스케일링 를 설정하여 인스턴스가 충분한지 확인할 수 있습니다.

다음 단계

계획 프로세스를 계속 진행하려면 VPC 클러스터 네트워킹 과 클래식 클러스터 네트워킹 중에서 선택하세요. 클러스터 만들기를 시작할 준비가 되었다면 먼저 클러스터를 만들 계정 준비하기 에서 시작하세요.