고가용성 클러스터 전략 만들기

생성할 클러스터 수 결정

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

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

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

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

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

필요한 위치 수 결정

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

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

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

클러스터 유형 선택

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

VPC 클러스터

워커 노드는 표준 인프라 또는 전용 호스트의 가상 워커 노드를 사용하여 프로비저닝할 수 있습니다. 속도를 중요하게 고려한다면 VPC 클러스터가 최선의 선택일 수 있습니다.

Satellite 클러스터

작업자 노드는 AWS, Azure, GCP 등과 같은 클라우드 제공업체의 가상 머신에서 프로비저닝할 수 있습니다. 워커 노드는 자체 온프레미스 인프라를 사용하여 프로비저닝할 수도 있습니다.

클래식 클러스터

워커 노드는 가상 및 베어메탈 워커 노드에서 생성할 수 있습니다. 추가 로컬 디스크가 필요한 경우 Portworx와 같은 소프트웨어 정의 스토리지 솔루션을 위해 디자인된 베어메탈 특성 중 하나를 선택할 수도 있습니다.

클러스터용 운영 체제 선택

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

Red Hat Enterprise Linux (RHEL) 버전 8

클래식 VPC Satellite

Red Hat Enterprise Linux는 보안을 염두에 두고 구축되었으며 중요한 워크로드에 맞게 조정된 견고하고 확장 가능한 환경을 기업에게 제공합니다. 조직은 Red Hat Enterprise Linux 플랫폼과 IBM Cloud의 인프라를 결합하여 고가용성, 재해 복구 및 간소화된 관리 기능을 이용할 수 있습니다. RHEL 8에 대한 개요는 Linux에서 IBM Cloud을 실행하는 이유는 무엇인가요?을 참조하세요.

Red Hat Enterprise Linux CoreOS (RHCOS)

VPC Satellite

버전 4.15 이상에서 생성된 클러스터에 사용할 수 있습니다. Red Hat Enterprise Linux CoreOS (RHCOS)는 Red Hat OpenShift Container Platform (OCP)를 위해 특별히 설계되었습니다. Red Hat Enterprise Linux (RHEL)의 안정성과 보안을 활용하면서도 가볍고 최소한의 기능으로 컨테이너화된 워크로드를 효율적이고 대규모로 실행하는 데 중점을 둔 RHCOS입니다. RHEL 구성 요소로 구성되어 있으므로 RHEL과 동일한 수준의 보안과 함께 컨테이너 중심의 최소 설치 공간, 읽기 전용 파일 시스템, 이미지 기반 배포 등의 추가 혜택을 누릴 수 있습니다. RHCOS에 대한 개요는 Red Hat Enterprise Linux CoreOS(RHCOS )를 참조하세요. VPC 클러스터용 RHCOS 워커 노드는 RHCOS를 지원하는 버전에서 생성된 클러스터에서만 사용할 수 있습니다. RHCOS를 지원하지 않는 버전에서 지원하는 버전으로 업그레이드된 클러스터는 RHCOS 워커를 사용할 수 없습니다.

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

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

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

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

클러스터의 총 작업자 노드 수에 따라 클러스터의 앱에서 사용할 수 있는 컴퓨팅 용량이 결정됩니다. 클러스터에 여러 개의 워커 노드를 설정하여 워커 노드 장애가 발생하는 동안 설정을 보호할 수 있습니다. 워커 노드 장애에는 전원, 냉각 또는 네트워킹과 같은 하드웨어 중단과 VM 자체의 문제가 포함될 수 있습니다.

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

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

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

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

워커 노드 플레이버 선택

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

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

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

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

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

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

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

    베어메탈 서버는 월별로 비용이 청구됩니다. 월말 전에 베어메탈 서버를 취소하는 경우 해당 월말까지 비용이 청구됩니다. 베어메탈 서버를 주문하거나 취소하면 해당 프로세스는 IBM Cloud 인프라 계정에서 수동으로 완료됩니다. 그래서 완료하는 데 영업일 기준으로 이틀 이상 걸릴 수 있습니다.

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

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

    일반적으로 다음과 같은 경우에 SDS 머신을 사용합니다.

    • 다음과 같은 SDS 애드온을 사용하는 경우 Portworx 와 같은 SDS 머신을 사용하는 경우
    • 앱이 로컬 스토리지가 필요한 StatefulSet 앱인 경우, SDS 머신을 사용하고 Kubernetes 로컬 영구 볼륨을 프로비저닝할 수 있습니다.
    • 추가 원시 로컬 스토리지를 요구하는 사용자 정의 앱이 있는 경우입니다.

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

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

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

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

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

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

  상태 저장 앱에서 데이터는 앱의 시작 및 실행을 유지하는 중요한 역할을 수행합니다. 데이터가 잠재적인 실패로부터 복구할 수 있을 정도로 가용성이 높은지 확인하십시오. Red Hat OpenShift on IBM Cloud에서 데이터를 지속하기 위한 여러 옵션을 선택할 수 있습니다. 예를 들어, 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 클러스터 네트워킹 과 클래식 클러스터 네트워킹 중에서 선택하세요. 클러스터 만들기를 시작할 준비가 되었다면 먼저 클러스터를 만들 계정 준비하기 에서 시작하세요.