Kubernetes란 무엇입니까?

Kubernetes는 여러 호스트에서 발생하는 컨테이너화된 워크로드와 서비스를 관리하기 위한 오픈 소스 플랫폼으로, 수동 개입은 최소화하면서 컨테이너화된 앱을 배치, 자동화, 모니터링 및 스케일링하는 관리 도구를 제공합니다. 마이크로서비스를 구성하는 모든 컨테이너는 손쉬운 관리와 검색을 보증하는 논리 장치인 팟(Pod)으로 그룹화됩니다. 이러한 팟(Pod)은 이식성과 확장성이 뛰어나고 장애 시 자체 수리되는 Kubernetes 클러스터에서 관리되는 컴퓨팅 호스트에서 실행됩니다.

Kubernetes에 대한 자세한 정보는 Kubernetes 문서를 참조하십시오.

Red Hat OpenShift on IBM Cloud 클러스터를 작성하는 방법

Red Hat OpenShift on IBM Cloud 클러스터를 작성하려면 먼저 기본 클러스터 설정에 대한 튜토리얼을 따르거나 자체 클러스터 환경을 디자인할지 여부를 결정하십시오.

학습서를 따르겠습니다.

먼저 시작하기 문서를 검토한 후 사용 가능한 학습서 중 하나를 선택하십시오.

고유한 클러스터 환경을 디자인하려고 합니다.

먼저 시작하기 문서를 검토한 후 클러스터 환경 전략을 작성 하십시오.

Red Hat OpenShift on IBM Cloud는 어떻게 작동합니까?

Red Hat OpenShift on IBM Cloud를 사용하면 사용자 고유의 Red Hat OpenShift 클러스터를 작성하여 IBM Cloud에서 컨테이너화된 앱을 배치하고 관리할 수 있습니다. 컨테이너화된 앱은 작업자 노드라고 하는 IBM Cloud 인프라 컴퓨팅 호스트에서 호스팅됩니다. 컴퓨팅 호스트를 공유 리소스 또는 전용 리소스를 갖춘 가상 머신으로 프로비저닝하거나, GPU 및 소프트웨어 정의 스토리지(SDS) 사용에 최적화할 수 있는 베어 메탈 머신으로 프로비저닝할 수 있습니다. 작업자 노드는 IBM에서 구성, 모니터링 및 관리하는 고가용성 Red Hat OpenShift 마스터를 통해 제어됩니다. IBM Cloud Kubernetes Service API 또는 CLI는 클러스터 인프라 리소스를 처리하는 데 사용하고, Kubernetes API 또는 CLI는 배치 및 서비스를 관리하는 데 사용할 수 있습니다.

클러스터 리소스 설정 방법에 대한 자세한 정보는 서비스 아키텍처를 참조하십시오. 기능 및 이점 목록을 찾으려면 이점 및 서비스 오퍼링을 참조하십시오.

Red Hat OpenShift on IBM Cloud를 사용해야 하는 이유가 무엇입니까?

Red Hat OpenShift on IBM Cloud는 신속한 앱 제공을 위해 강력한 도구, 직관적인 사용자 환경 및 기본 제공 보안을 제공하는 관리 Red Hat OpenShift 오퍼링으로, IBM Watson®, AI, IoT, DevOps, 보안 및 데이터 분석 관련 클라우드 서비스에 바인딩할 수 있습니다. Kubernetes 의 공인 제공업체인 Red Hat OpenShift on IBM Cloud 는 지능형 스케줄링, 자가 복구, 수평 확장, 서비스 탐색 및 부하 분산, 자동화된 롤아웃 및 롤백, 비밀 정보 및 구성 관리를 지원합니다. 이 서비스는 또한 단순화된 클러스터 관리, 컨테이너 보안 및 격리 정책에 기반한 고급 기능, 자체 클러스터 디자인 기능 및 배치 일관성을 위한 통합 운영 도구도 제공합니다.

기능 및 이점에 대한 자세한 내용은 서비스 사용의 이점을 참조하십시오.

내 클러스터에서 사용 가능한 컨테이너 플랫폼은 무엇입니까?

IBM Cloud를 사용하여 두 개의 다른 컨테이너 관리 플랫폼 즉, 커뮤니티 Kubernetes의 IBM 버전 및 Red Hat OpenShift on IBM Cloud 중에서 사용자의 컨테이너화된 워크로드에 맞는 클러스터를 작성할 수 있습니다. 선택하는 컨테이너 플랫폼은 클러스터 마스터 및 작업자 노드에 설치됩니다. 나중에 버전을 업데이트할 수 있으나 이전 버전으로 롤백하거나 다른 컨테이너 플랫폼으로 전환할 수 없습니다. 여러 컨테이너 플랫폼을 사용하려면 각각 별도의 클러스터를 작성하십시오.

자세한 정보는 Red Hat OpenShift 및 커뮤니티 Kubernetes 클러스터 간의 비교를 참조하십시오.

Kubernetes

KubernetesUbuntu 운영 체제에서 실행되는 컨테이너화된 애플리케이션을 자동화하고, 확장하며, 관리하는 데 사용할 수 있는 프로덕션급 오픈 소스 컨테이너 오케스트레이션 플랫폼입니다. IBM Cloud Kubernetes Service 버전을 사용하여 커뮤니티에서 베타 이상으로 간주되는 커뮤니티 Kubernetes API 기능에 액세스할 수 있습니다. 변경될 수 있는 Kubernetes alpha 기능은 일반적으로 사용으로 기본 설정되어 있지 않습니다. Kubernetes를 사용하여 시크릿, 배치 및 서비스와 같은 여러 리소스를 결합하여 고가용성의 컨테이너화된 앱을 안전하게 작성하고 관리할 수 있습니다.

Red Hat OpenShift

Red Hat OpenShift on IBM Cloud 이는 Kubernetes 기반의 플랫폼으로, Red Hat Enterprise Linux 운영 체제에서 실행되는 컨테이너화된 애플리케이션 배포 프로세스의 속도를 높이기 위해 특별히 설계되었습니다. 다중 클라우드 시나리오에서 동일하게 작동하는 포터블 하이브리드 솔루션에 맞게 온프레미스 및 오프프레미스 클라우드에서 기존 Red Hat OpenShift 워크로드를 조정하고 스케일링할 수 있습니다. 시작하려면 Red Hat OpenShift on IBM Cloud 튜토리얼을 사용해 보십시오.

서비스는 관리 Red Hat OpenShift 마스터 및 작업자 노드와 함께 제공됩니까?

Red Hat OpenShift on IBM Cloud의 모든 클러스터는 IBM에서 IBM 소유 Red Hat OpenShift 인프라 계정으로 관리하는 전용 IBM Cloud 마스터에 의해 제어됩니다. Red Hat OpenShift 마스터(모든 마스터 컴포넌트, 컴퓨팅, 네트워킹 및 스토리지 리소스 포함)는 IBM 사이트 신뢰성 엔지니어(SRE)에 의해 지속적으로 모니터링됩니다. SRE는 최신 보안 표준을 적용하고, 악성 활동을 발견하고 교정하며 Red Hat OpenShift on IBM Cloud의 신뢰성 및 가용성을 보장하기 위해 작업을 수행합니다.

주기적으로, Red Hat OpenShift는 주 버전 업데이트, 부 버전 업데이트 또는 패치 업데이트를 릴리스합니다. 이러한 업데이트는 Red Hat OpenShift 마스터의 Red Hat OpenShift API 서버 버전 또는 다른 컴포넌트에 영향을 줄 수 있습니다. 패치 버전은 IBM에서 자동으로 업데이트하지만, 마스터 주 버전과 부 버전은 사용자가 업데이트해야 합니다. 자세한 정보는 마스터 업데이트를 참조하십시오.

표준 클러스터의 작업자 노드는 IBM Cloud 인프라 계정에 프로비전됩니다. 작업자 노드는 사용자 계정 전용이며 사용자는 작업자 노드 OS 및 Red Hat OpenShift on IBM Cloud 컴포넌트가 최신 보안 업데이트와 패치를 적용하도록 보장하기 위해 작업자 노드에 대한 시기 적절한 업데이트를 요청할 책임이 있습니다. 보안 업데이트 및 패치는 취약성 및 보안 규제 준수 문제를 발견하기 위해 작업자 노드에 설치된 Linux 이미지를 지속적으로 모니터링하는 IBM 사이트 신뢰성 엔지니어(SRE)가 제공합니다. 자세한 정보는 작업자 노드 업데이트를 참조하십시오.

Red Hat OpenShift on IBM Cloud으로 이동할 수 있는 워크로드 유형은 무엇입니까?

사용자들이 일반적으로 다양한 유형의 클라우드로 이전하는 워크로드 유형의 예시는 “워크로드를 IBM Cloud 로 이전하기”를 참조하십시오. 두 환경 모두에서 클러스터를 실행하는 하이브리드 접근법을 선택할 수도 있습니다.

내 인프라 배치를 자동화할 수 있습니까?

다중 클러스터, 공용 및 사설 환경 또는 클라우드 제공자에서도 앱을 실행할 경우 이 환경에서 배치 전략 작업을 수행할 수 있는 방법을 궁금해할 수 있습니다.

오픈 소스 Terraform 도구를 사용하여 Kubernetes 클러스터를 포함한 IBM Cloud 인프라의 프로비저닝을 자동화할 수 있습니다. 이 튜토리얼에 따라 단일 및 다중 구역 Kubernetes 및 OpenShift 클러스터를 작성 하십시오. 워크로드의 리소스 요청에 대한 응답으로 작업자 풀이 작업자 노드를 스케일링 업 및 다운하도록 클러스터 작성 후 Red Hat OpenShift on IBM Cloud 클러스터 오토스케일러도 설정할 수 있습니다.

실행할 수 있는 앱의 유형은 무엇입니까? 기존 앱을 이동할 수 있습니까? 아니면 새 앱을 개발해야 합니까?

컨테이너화된 앱은 클러스터 버전에 대해 지원되는 운영 체제 중 하나에서 실행할 수 있어야 합니다. 또한 사용자는 앱의 상태 추적성(statefulness)을 고려하려고 합니다. Red Hat OpenShift on IBM Cloud에서 실행될 수 앱 유형에 대한 자세한 정보는 앱 배치 계획을 참조하십시오.

이미 앱이 있으면 Red Hat OpenShift on IBM Cloud로 마이그레이션할 수 있습니다. 새 앱을 개발하려면 stateless, 클라우드 네이티브 앱 개발을 위한 지침을 참조하십시오.

서버리스 앱은 어떻습니까?

IBM Cloud Code Engine 서비스를 통해 서버리스 앱 및 작업을 실행할 수 있습니다. Code Engine에서 사용자의 이미지를 빌드할 수도 있습니다.

내 앱을 클러스터로 이동하기 전에 보유해야 하는 기술은 무엇입니까?

Red Hat OpenShift는 클러스터 관리자와 앱 개발자라는 두 가지 주요 인물에게 기능을 제공하도록 디자인되었습니다. 각 인물은 서로 다른 기술을 사용하여 클러스터에 앱을 배치하고 실행합니다.

클러스터 관리자의 주요 업무와 필요한 기술적 지식은 무엇인가요?

클러스터 관리자는 클러스터의 IBM Cloud 인프라를 설정하고, 운영하고, 보호하고, 관리해야 합니다. 일반 태스크에는 다음이 포함됩니다.

• 워크로드에 충분한 용량을 제공할 수 있도록 클러스터의 크기를 지정합니다.
• 회사의 고가용성, 재해 복구 및 규제 준수 표준을 만족시킬 수 있도록 클러스터를 디자인합니다.
• 사용자 권한을 설정하고 클러스터 내 조치를 제한하여 클러스터를 보호함으로써 컴퓨팅 리소스, 네트워크 및 데이터를 보호합니다.
• 네트워크 보안, 분할 및 규제 준수를 보장하기 위해 인프라 컴포넌트 간의 네트워크 통신을 계획하고 관리합니다.
• 데이터 상주 및 데이터 보호 요구사항을 만족시키기 위한 지속적 스토리지 옵션을 계획합니다.

클러스터 관리자는 컴퓨팅, 네트워크, 스토리지, 보안 및 규제 준수를 포함한 광범위한 지식을 갖고 있어야 합니다. 일반적인 회사에서 이 지식은 시스템 엔지니어, 시스템 관리자, 네트워크 엔지니어, 네트워크 설계자, IT 관리자 또는 보안 및 규제 준수 전문가와 같은 여러 전문가에게 분산되어 있습니다. 클러스터를 운영하는 데 필요한 지식을 갖추기 위해 회사의 여러 사람에게 클러스터 관리자 역할을 지정하는 것을 고려하십시오.

앱 개발자의 주요 업무와 기술적 역량은 무엇인가요?

개발자는 Red Hat OpenShift 클러스터에서 컨테이너화된 클라우드 네이티브 앱을 디자인하고, 개발하고, 보호하고, 테스트하고, 모니터링합니다. 이러한 앱을 개발하고 실행하려면 마이크로서비스 개념, 12-팩터 앱 지침, 마이크로서비스 아키텍처(Docker)및 컨테이너화 원칙, 그리고 사용 가능한 Red Hat OpenShift 배포 옵션에 대해 잘 알고 있어야 합니다.

Red Hat OpenShift 및 Red Hat OpenShift on IBM Cloud에서는 앱을 노출하고 개인용으로 유지하는 방법, 그리고 지속적 스토리지 추가, 다른 서비스 통합, 워크로드 및 민감한 데이터 보호를 수행하는 방법에 대해 다양한 옵션을 제공합니다. Red Hat OpenShift on IBM Cloud 의 클러스터로 앱을 이전하기 전에, 지원되는 운영 체제에서 앱을 컨테이너화된 앱으로 실행할 수 있는지, 그리고 Red Hat OpenShift 및 Red Hat OpenShift on IBM Cloud 에서 워크로드에 필요한 기능을 제공하는지 확인하십시오.

클러스터 관리자와 개발자들은 서로 소통하나요?

예. 클러스터 관리자는 클러스터에서 이 기능을 제공하는 데 필요한 워크로드 요구사항을 파악하고 개발자는 앱 개발 프로세스에서 고려해야 하는 사용 가능한 제한, 통합 및 보안 원리에 대해 알 수 있도록, 클러스터 관리자와 개발자는 빈번히 소통해야 합니다.

내 클러스터를 보안 설정하기 위한 옵션에는 무엇이 있습니까?

Red Hat OpenShift on IBM Cloud의 기본 제공 보안 기능을 사용하면 클러스터의 컴포넌트, 데이터 및 앱 배치를 보호하여 보안 준수 및 데이터 무결성을 보장할 수 있습니다. Red Hat OpenShift API 서버, etcd 데이터 저장소, 작업자 노드, 네트워크, 스토리지, 이미지 및 배치를 악의적인 공격으로부터 보호하려면 이 기능을 사용하십시오. 기본 제공 로깅 및 모니터링 도구를 사용하여 악의적인 공격과 의심스러운 사용량 패턴을 발견할 수도 있습니다.

클러스터 컴포넌트 및 각 클러스터에 대한 보안 표준을 충족하는 방법에 대한 자세한 정보는 Red Hat OpenShift on IBM Cloud에 대한 보안을 참조하십시오.

내 클러스터 사용자에게 제공하는 액세스 정책은 무엇입니까?

Red Hat OpenShift on IBM Cloud는 Cloud Identity and Access Management(IAM)를 사용하여 IAM 플랫폼 액세스 역할을 통해 클러스터 리소스에 대한 액세스 권한을 부여하고 IAM 서비스 액세스 역할을 통해 Kubernetes 역할 기반 액세스 제어(RBAC) 정책에 대한 액세스 권한을 부여합니다. 액세스 정책의 유형에 대한 자세한 내용은 ‘사용자에게 적합한 액세스 정책 및 역할 선택’을 참조하세요.

유출이 발생한 경우 클러스터 API 키를 어떻게 회전하나요?

API 키를 교체하는 방법에 대한 지침은 유출이 발생한 경우 클러스터 API 키를 교체하는 방법을 참조하세요.

클러스터에 영향을 주는 보안 게시판 목록은 어디에서 찾을 수 있습니까?

Red Hat OpenShift에서 취약성이 발견되면 Red Hat OpenShift는 보안 게시판에 CVE를 릴리스하여 사용자에게 알리고 사용자가 취약성을 해결하기 위해 수행해야 하는 조치에 대해 설명합니다. Red Hat OpenShift on IBM Cloud 사용자 또는 IBM Cloud 플랫폼에 영향을 미치는 Red Hat OpenShift 보안 게시판은 IBM Cloud 보안 게시판에 공개됩니다.

일부 CVE에는 Red Hat OpenShift on IBM Cloud의 정기 클러스터 업데이트 프로세스의 일부로 설치할 수 있는 버전에 대한 최신 패치 업데이트가 필요합니다. 악성 공격으로부터 클러스터를 보호하려면 적시에 보안 패치를 적용해야 합니다. 보안 패치에 포함된 내용에 대한 자세한 정보는 버전 변경 내역을 참조하십시오.

서비스가 베어메탈 및 GPU에 대한 지원을 제공합니까?

특정 VPC 작업자 노드 특성은 GPU 지원을 제공합니다. 자세한 정보는 VPC 특색 을 참조하십시오.

예, 작업자 노드를 싱글 테넌트 실제 베어메탈 서버로 프로비저닝할 수 있습니다. 베어메탈 서버는 데이터, GPU 및 AI와 같은 워크로드에 대해 고성능 이점을 제공합니다. 또한 모든 하드웨어 리소스가 사용자의 워크로드 전용으로 사용되므로 "사용량이 많은 다른 항목(noisy neighbors)"문제를 신경쓰지 않아도 됩니다.

사용 가능한 베어 메탈 구성 유형 및 베어 메탈이 가상 머신과 어떻게 다른지에 대한 자세한 내용은 계획 지침을 참조하십시오.

만들 수 있는 클러스터의 최소 크기는 얼마인가요?

최소 클러스터를 실행하는 것은 지원을 받기 위한 서비스 수준 협약(SLA)을 충족하지 못한다는 점에 유의하세요. 또한 Ingress와 같은 일부 서비스에는 고가용성 작업자 노드 설정이 필요합니다. 작업자 풀에 두 개의 노드만 있는 클러스터에서 이러한 서비스 또는 앱을 실행할 수 없습니다. 자세한 정보는 고가용성을 위한 클러스터 계획 을 참조하십시오.

클래식 또는 VPC 클러스터

클러스터에는 항상 두 개 이상의 작업자 노드가 있어야 합니다. 워커 노드가 0개인 클러스터를 구성할 수 없으며, 워커 노드의 전원을 끄거나 요금 청구를 일시 중지할 수 없다는 점에 유의하십시오.

Satellite 클러스터

클러스터는 단일 복제본 토폴로지를 사용하여 작성할 수 있으며, 이는 하나의 작업자 노드만을 의미합니다. 단일 복제본 토폴로지를 사용하여 Satellite 클러스터를 작성하는 경우 나중에 작업자 노드를 추가할 수 없습니다.

이 서비스는 어떤 버전을 지원하나요?

Red Hat OpenShift on IBM Cloud 은 동시에 여러 버전의 Red Hat OpenShift을 지원합니다. 새 버전(n)이 출시되면, 그보다 최대 2개 이전 버전까지( n-2 ) 지원됩니다. 최신 버전보다 세 개 이상 이전인 버전(n-3)은 먼저 더 이상 사용되지 않게 되고 그런 다음 지원되지 않게 됩니다.

지원되는 버전에 대한 자세한 내용과 한 버전에서 다른 버전으로 전환하기 위해 수행해야 하는 업데이트 절차에 대해서는 ‘ Red Hat OpenShift on IBM Cloud ’ 버전 정보를 참조하십시오.

서비스가 지원하는 작업자 노드 운영 체제는 무엇입니까?

클러스터 버전별로 지원되는 작업자 노드 운영 체제 목록은 Red Hat OpenShift on IBM Cloud 버전 정보 를 참조하십시오.

서비스를 사용할 수 있는 위치는 어디입니까?

Red Hat OpenShift on IBM Cloud는 전 세계에서 사용 가능합니다. Red Hat OpenShift on IBM Cloud 에서 지원하는 모든 리전에서 클러스터를 생성할 수 있습니다.

지원되는 지역에 대한 자세한 정보는 위치를 참조하십시오.

서비스는 고가용성입니까?

예. 기본적으로 Red Hat OpenShift on IBM Cloud는 다수의 컴포넌트(예: 복제본, 반친화성 및 서비스의 고가용성(HA)을 향상시키기 위한 기타 옵션이 있는 클러스터 마스터)를 설정합니다. 고가용성 아키텍처에서 클러스터 작업자 노드, 스토리지, 네트워킹 및 워크로드의 중복성 및 장애 허용을 구성하여 이를 향상시킬 수 있습니다. 기본 설정과 HA를 높이기 위한 옵션에 대한 개요는 고가용성 클러스터 전략 만들기 를 참조하세요.

최신 HA SLA(Service Level Agreement)는 IBM Cloud 이용 약관을 참조하십시오. 일반적으로 SLA 고가용성 이용 약관에 따라, HA 아키텍처에서 인프라 리소스를 구성하는 경우에는 세 개의 다른 가용성 구역에 공평하게 분배해야 합니다. 예를 들어, SLA 이용 약관에 따라 전체 HA 적용을 받으려면 최소 총 여섯 개의 작업자 노드, 즉 세 개의 구역에 고르게 분산된 구역당 두 개의 작업자 노드로 다중 구역 클러스터를 설정해야 합니다.

멀티존 클러스터는 어떻게 작동하나요?

리전 간에 여러 클러스터를 구성하고 싶다면 어떻게 해야 하나요?

하나의 지리적 위치의 서로 다른 지역에서(예: 미국 남부 및 미국 동부) 또는 지리적 위치 간에(예: 미국 남부 및 중앙 유럽) 다중 클러스터를 설정할 수 있습니다. 두 설정 모두 사용자의 앱에 대해 동일한 레벨의 가용성을 제공하지만, 데이터 공유 및 데이터 복제와 관련해서는 복잡도 역시 추가됩니다. 대부분의 경우에는 동일한 지리적 위치 내에 있는 것으로도 충분합니다. 그러나 사용자가 전세계에 걸쳐 있는 경우에는 사용자가 앱에 요청을 전송할 때 오래 기다리지 않도록 사용자가 있는 위치에 클러스터를 설정하는 것이 바람직합니다.

여러 클러스터에 걸쳐 워크로드의 부하 분산을 수행하려면 어떤 옵션이 있나요?

여러 클러스터 간에 워크로드를 로드 밸런싱하려면 Ingress, 라우터 또는 네트워크 로드 밸런서(NLB)를 사용하여 공용 네트워크에서 앱을 사용 가능하게 해야 합니다. 라우터 서비스와 NLB에는 앱에 액세스하는 데 사용할 수 있는 공인 IP 주소가 지정됩니다.

앱 간에 워크로드를 로드 밸런싱하려면 라우터 서비스 및 NLB의 공인 IP 주소를 CIS 글로벌 로드 밸런서 또는 자신의 글로벌 로드 밸런서에 추가하십시오.

사설 네트워크에서 워크로드의 부하 분산을 하고 싶다면 어떻게 해야 할까요?

IBM Cloud는 사설 네트워크에서 글로벌 로드 밸런서 서비스를 제공하지 않습니다. 그러나 지원되는 VPN 옵션 중 하나를 사용하여 온프레미스 네트워크에서 호스팅하는 사설 로드 밸런서에 클러스터를 연결할 수 있습니다. Ingress, 라우터 또는 네트워크 로드 밸런서(NLB)를 사용하여 사설 네트워크에 앱을 노출시키고, VPN 설정에서 사설 IP 주소를 사용하여 앱을 온프레미스 네트워크에 연결하십시오.

마스터 및 작업자 노드는 고가용성 노드입니까?

Red Hat OpenShift on IBM Cloud 아키텍처 및 인프라는 신뢰성, 짧은 처리 대기 시간 및 최대 가동 시간을 보장하도록 디자인되었습니다. 기본적으로, Red Hat OpenShift on IBM Cloud의 모든 클러스터는 Red Hat OpenShift 마스터 인스턴스 중 하나 이상이 사용 불가능하더라도 클러스터 리소스의 가용성과 접근성을 보장하기 위해 다중 Red Hat OpenShift 마스터 인스턴스를 사용하도록 설정되었습니다.

지역의 다중 구역에 있는 다중 작업자 노드에 워크로드를 분산시키면 클러스터의 고가용성을 높이고 앱을 작동 중단 시간으로부터 보호할 수 있습니다. 이러한 구성을 ‘다중 구역 클러스터’라고 하며, 워커 노드 하나나 전체 구역이 사용 불가능한 상황에서도 앱에 계속 접근할 수 있도록 보장합니다.

전체 리전 장애로부터 시스템을 보호하려면 여러 클러스터를 생성하고 이를 IBM Cloud 의 여러 리전에 분산시켜야 합니다. 클러스터에 대해 네트워크 로드 밸런서(NLB)를 설정하면 클러스터에 대해 교차 지역 로드 밸런싱 및 교차 지역 네트워킹을 구현할 수 있습니다.

가동 중단이 발생하더라도 반드시 사용 가능해야 하는 데이터가 있는 경우에는 데이터를 지속적 스토리지에 저장해야 합니다.

클러스터의 가용성을 획득하는 방법에 대한 자세한 정보는 Red Hat OpenShift on IBM Cloud의 고가용성을 참조하십시오.

내 앱이 존 간에 자동으로 분산되나요?

앱 설정 방식에 따라 다릅니다. 고가용성 배치 계획 및 고가용성 지속적 스토리지 계획을 참조하십시오.

워커 노드들은 암호화되어 있나요?

작업자 노드의 보조 디스크는 암호화되어 있습니다. 자세한 정보는 클러스터 암호화 개요를 참조하십시오. 작업자 풀을 작성한 후에는 작업자 노드 특성의 이름에 .encrypted(예: b3c.4x16.encrypted)가 있음을 알 수 있습니다.

서비스가 준수하는 규제 준수 표준은 무엇입니까?

IBM Cloud은 많은 데이터, 금융, 건강, 보험, 개인정보 보호, 보안, 기술 및 기타 국제 규제 준수 표준을 따라 빌드되었습니다. 자세한 정보는 IBM Cloud 규제 준수를 참조하십시오.

자세한 시스템 요구 사항을 확인하려면 Red Hat OpenShift on IBM Cloud 에 대한 소프트웨어 제품 호환성 보고서를 실행할 수 있습니다. 규제 준수는 클러스터 작업자 노드의 기반 인프라 제공자, 네트워킹 및 스토리지 리소스에 따라 달라진다는 점을 참고하십시오.

기존 인프라: Red Hat OpenShift on IBM Cloud 은 다음 보안 표준에 부합하는 통제 조치를 시행하고 있습니다:

• EU-US 프라이버시 실드 및 스위스-US 프라이버시 실드 프레임워크
• HIPAA(Health Insurance Portability and Accountability Act)
• Service Organization Control 표준(SOC 1 유형 2, SOC 2 유형 2)
• ISAE(International Standard on Assurance Engagements) 3402, 서비스 조직의 제어에 대한 보증 보고서
• ISO(International Organization for Standardization) 27001, ISO 27017, ISO 27018
• PCI DSS(Payment Card Industry Data Security Standard)

VPC 인프라: Red Hat OpenShift on IBM Cloud 은 다음 보안 표준에 부합하는 통제 조치를 시행하고 있습니다:

• EU-US 프라이버시 실드 및 스위스-US 프라이버시 실드 프레임워크
• HIPAA(Health Insurance Portability and Accountability Act)
• ISAE(International Standard on Assurance Engagements) 3402, 서비스 조직의 제어에 대한 보증 보고서

Satellite: IBM Cloud Satellite 문서 를 참조하십시오.

내 클러스터에서 다른 IBM Cloud 서비스를 사용할 수 있습니까?

자동화 사용, 보안 향상 또는 클러스터의 모니터링 및 로깅 기능 향상을 위해 IBM Cloud 플랫폼 및 인프라 서비스와 서드파티 공급업체의 서비스를 Red Hat OpenShift on IBM Cloud 클러스터에 추가할 수 있습니다.

지원되는 서비스 목록은 서비스 통합을 참조하십시오.

클러스터에 Cloud Pak 를 설치하려면 어떻게 해야 하나요?

기존 또는 새 IBM Cloud 클러스터에 모든 Cloud Pak 컴포넌트를 빠르게 설치하고 구성할 수 있도록 Cloud Paks가 Red Hat OpenShift 카탈로그와 통합되었습니다. Cloud Pak 를 설치하면, Cloud Pak 에 Schematics 가 프로비저닝되고, Schematics 작업 공간이 자동으로 생성됩니다. 나중에 작업공간을 사용하여 Cloud Pak 설치에 대한 정보에 액세스할 수 있습니다. Cloud Pak 서비스는 Cloud Pak URL을 통해 액세스하십시오. 자세한 내용은 Cloud Pak 설명서를 참조하세요.

내 클러스터용 내 Cloud Pak과 함께 제공되는 Red Hat OpenShift 권한을 사용할 수 있습니까?

예, Cloud Pak에 OpenShift Container Platform과 함께 설치되는 특정 작업자 노드 특성을 실행할 권한이 있는 경우 가능합니다. 귀하의 이용 권한을 확인하려면 다음에서 로그인하세요 IBM Passport Advantage. IBM Cloud ID가 IBM Passport Advantage ID에 일치해야 함을 주의하십시오.

--entitlement ocp_entitled 콘솔에서 ‘ Cloud Pak ’ 권한을 사용하여 클러스터를 생성하거나 기존 클러스터 내에 워커 풀을 생성할 수 있으며, ibmcloud oc cluster create classic 또는 ibmcloud oc worker-pool create classic CLI 명령어를 사용하여 생성할 수 있습니다. 사용 권한이 있는 작업자 노드의 정확한 수와 특성을 지정해야 합니다.

권한을 초과하지 마십시오. OpenShift Container Platform 권한을 다른 클라우드 제공자 또는 다른 환경에서 사용할 수 있음을 기억하십시오. 추후 청구 문제를 방지하려면 사용할 수 있는 권한만 사용하는지 확인하십시오. 예를 들어, 4CPU 및 16GB 메모리의 두 작업자 노드에 대한 OCP 라이센스에 대한 권한을 가지고 있을 수 있으며, 4CPU 및 16GB 메모리의 두 작업자 노드가 포함된 이 작업자 풀을 작성할 수 있습니다. 전체 권한을 사용했으며 다른 작업자 풀, 클라우드 제공자 또는 환경에 동일한 권한을 사용할 수 없습니다.

동일한 Red Hat OpenShift on IBM Cloud 클러스터에 여러 Cloud Pak을 설치할 수 있습니까?

예, 그러나 각 Cloud Pak 에 실행할 충분한 컴퓨팅 리소스가 있도록 작업자 노드를 더 추가해야 할 수 있습니다. 또한 Cloud Pak for Data와 같은 클러스터당 동일한 Cloud Pak 의 인스턴스를 하나만 설치하거나 Cloud Pak for Automation과 같은 동일한 클러스터의 다른 프로젝트에 여러 인스턴스를 설치할 수 있습니다. 크기 조정 정보는 Cloud Pak 문서를 참조하십시오.

Cloud Pak에 포함된 항목은 무엇입니까?

Cloud Pak은 일관성 있는 배치, 액세스 제어 및 비용 청구를 포함하여, 엔터프라이즈 유스 케이스에 대해 함께 작업하도록 최적화된 라이센스가 부여된 컨테이너형 번들 소프트웨어입니다. 워크로드에 맞춰 소프트웨어의 가상 프로세서 코어를 적절히 조합하여, 필요할 때 클라우드 팩의 구성 요소를 유연하게 활용할 수 있습니다. 또한 워크로드가 달라질 때 가상 프로세서 코어를 다르게 혼합할 수도 있습니다.

Cloud Pak에 따라, 라이센스가 부여된 IBM 및 오픈 소스 소프트웨어 번들이 로깅, 모니터링, 보안 및 액세스 기능과 함께 통합된 관리 환경에 제공됩니다.

• IBM 제품: Cloud Paks는 IBM 마켓플레이스에서 제공되는 라이선스 기반 IBM 소프트웨어 및 미들웨어의 기능을 확장하며, 이러한 제품을 사용자의 클러스터와 통합하여 하이브리드 클라우드 워크로드를 현대화하고, 최적화하며, 실행할 수 있도록 지원합니다.
• 오픈 소스 소프트웨어: Cloud Pak은 클라우드 기본 포터블 하이브리드 클라우드 솔루션에 대한 오픈 소스 컴포넌트도 포함할 수 있습니다. 일반적으로 오픈 소스 소프트웨어는 관리되지 않으며 컴포넌트를 최신으로 안전하게 보호할 책임은 사용자에게 있습니다. 그러나 Cloud Pak은 함께 실행하는 Cloud Pak 컴포넌트 및 워크로드의 전체 라이프사이클을 지속적으로 관리할 수 있도록 지원합니다. 이 오픈 소스 소프트웨어는 Cloud Pak 과 함께 제공되므로, IBM 의 지원 혜택을 누릴 수 있을 뿐만 아니라, 액세스 제어 및 청구와 같은 IBM Cloud 의 일부 기능과도 연동할 수 있습니다.

각 Cloud Pak 의 구성 요소를 확인하려면 Cloud Pak 문서를 참조하십시오.

Cloud Paks를 사용하는 데 있어 알아야 할 다른 사항이 있습니까?

Cloud Pak을 설정할 때 보안 컨텍스트 제한조건과 같은 Red Hat OpenShift 고유 리소스 관련 작업을 수행해야 합니다. oc CLI 또는 kubectl 버전 1.12 CLI를 사용하여 이러한 리소스와 상호작용해야 합니다(예: oc get scc). kubectl CLI 버전 1.11에는 kubectl get scc와 같은 Red Hat OpenShift 특정 리소스에 대한 명령을 실행할 때 오류가 발생하는 버그가 있습니다.

IBM은 내 클러스터에 사용하는 서드파티 및 오픈 소스 도구를 지원합니까?

IBM 의 오픈 소스 및 제3자 정책을 참조하십시오.

어떤 항목에 대해 비용이 청구됩니까? 내 클러스터의 비용을 예상하고 제어할 수 있습니까?

클러스터의 비용 관리를 참조하십시오.

내 클러스터를 이전 버전으로 다운그레이드할 수 있습니까?

아니오, 클러스터를 이전 버전으로 다운그레이드할 수 없습니다.

내 현재 클러스터를 다른 계정으로 이동할 수 있습니까?

아니오, 클러스터가 작성된 계정과 다른 계정으로 클러스터를 이동할 수 없습니다.

내 클러스터를 지원되는 상태로 유지하는 방법은 무엇입니까?

• 클러스터가 항상 지원되는 Red Hat OpenShift 버전을 실행하는지 확인하십시오.
• 새 Red Hat OpenShift 부 버전이 릴리스되면 이전 버전은 지원되지 않는 즉시 더 이상 사용되지 않습니다.

자세한 정보는 마스터 업데이트 및 작업자 노드를 참조하십시오.

내 클러스터가 지원되지 않는 운영 체제를 실행 중인 경우 차단되는 조작은 무엇입니까?

운영 체제가 지원되지 않는 경우 다음 조작이 차단됩니다.

• 작업자 다시 로드
• 업데이트 없이 작업자 대체
• 작업자를 업데이트로 대체
• 작업자 업데이트
• 작업자 풀 작성 (지원되지 않는 OS 사용)
• 작업자 풀 재조정
• 작업자 풀 크기 조정 (확장)
• 작업자 풀 구역 추가
• 인스턴스 그룹 크기 조정 (패치)
• 오토스케일러 제거 작업자 (v2/autoscalerRemoveWorker)

기밀 컨테이너의 비용은 얼마인가요?

IBM 는 기밀 컨테이너에 대해 추가 비용을 청구하지 않습니다. 비용은 표준 IBM Cloud 요금으로 VSI로 시작하는 각 기밀 포드에 대한 서비스 및 표준 VSI 요금이 동일하게 유지됩니다.

기밀 컨테이너를 위한 자체 CVM(podvm)을 구축할 수 있나요?

예. ConfigMap 은 사용자가 구성한 CVM(기밀 가상 머신)을 가리키도록 구성할 수 있습니다. IBM 는 직접 구축할 수 있도록 지원하지 않습니다. 이미지를 직접 만들면 IBM 지원팀에서 도와줄 수 없는 문제가 발생할 수 있습니다.

기밀 컨테이너의 수탁자로 무엇을 사용해야 하나요?

개발의 경우 VM 에서 Docker / Podman 에서 간단한 트러스티를 실행하는 것으로 충분합니다. 이러한 컨테이너는 OpenShift 에서 직접 구성할 수도 있습니다. 하지만 트러스티는 환경의 보안을 증명하는 주체이므로 신뢰할 수 없는 OpenShift 클러스터 내에서는 트러스티를 사용하지 마세요.

프로덕션의 경우 인텔 신뢰 기관을 사용하고 인텔 신뢰 기관을 사용하도록 INITDATA를 구성합니다. 클러스터에서 보안 그룹, 보안 기본값 OpenShift 권한 등을 통해 인텔과 통신할 수 있도록 허용해야 합니다.

기밀 컨테이너에 대한 지원은 어디서 받을 수 있나요?

OpenShift Red Hat OpenShift on IBM Cloud 의 샌드박스 컨테이너 운영자는 Red Hat 과 IBM 에서 모두 지원됩니다. 두 서비스 모두 표준 지원 채널을 사용하세요. OpenShift IBM Cloud 을 통해 라이선스를 받은 경우 으로 문의하세요. IBM Red Hat 에서 OpenShift 라이선스를 가져오신 경우 Red Hat 으로 문의하실 수 있습니다.

워커 노드당 몇 개의 피어 파드를 실행할 수 있나요?

워커 노드당 실행할 수 있는 피어 파드의 수는 여러 제한에 의해 제어됩니다:

1. PEERPODS_LIMIT_PER_NODE 설정: peer-pods-cm ConfigMap 에서 구성 가능한 이 제한은 워커 노드당 예약할 수 있는 피어 포드 VSI의 최대 수를 제어합니다. 기본값은 10입니다. 이 값을 늘릴 수 있지만 아래의 다른 제약 조건도 고려해야 합니다.

2. Kubernetes 포드 제한: Kubernetes 은 vCPUs ( vCPU 당 10개의 포드)를 기준으로 노드당 총 포드 수를 제한합니다. 예를 들어 16x64 워커 노드는 최대 110개의 파드를 지원할 수 있습니다. 각 피어 파드는 워커 노드의 Kubernetes 포드 구성에 의해 지원되므로, 실제 워크로드가 별도의 VSI에서 실행되더라도 이 제한이 적용됩니다.

3. 워커 노드 CPU 및 메모리: 각 피어 파드는 Kubernetes 파드 구성을 위해 워커 노드에서 약 250m CPU와 120Mi 메모리를 사용합니다. 워커 노드에 원하는 수의 피어 파드를 지원할 수 있는 충분한 CPU와 메모리가 있는지 확인해야 합니다.

PEERPODS_LIMIT_PER_NODE 값을 늘리려면:

1. openshift-sandboxed-containers-operator 네임스페이스에서 peer-pods-cm ConfigMap 을 업데이트합니다. 자세한 내용은 기밀 컨테이너 만들기를 참조하세요.

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"PEERPODS_LIMIT_PER_NODE":"24"}}'
   

2. 클라우드 API 어댑터 데몬 세트를 다시 시작합니다.

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. 새 한도가 적용되었는지 확인합니다.

   oc get nodes -o json | jq -r '[.items[] | select (.status.allocatable["kata.peerpods.io/vm"] != null)| .status.allocatable["kata.peerpods.io/vm"] | tonumber] | add'
   

최적의 PEERPODS_LIMIT_PER_NODE 값을 계산할 때는 작업자 노드 프로필을 고려하세요. 예를 들어, 16x64 작업자 노드(16 vCPUs )의 경우, CPU만을 기준으로 한 이론적 최대치는 노드당 약 24개의 피어 파드입니다(피어 파드당 250m CPU를 가정하고 다른 시스템 프로세스를 고려). 그러나 노드당 110개의 파드라는 Kubernetes 포드 제한도 적용됩니다.

부족 kata.peerpods.io/vm 오류는 무엇을 의미하나요?

피어 파드를 예약할 때 다음과 같은 오류가 표시되는 경우:

Warning FailedScheduling 0/30 nodes are available: 9 Insufficient kata.peerpods.io/vm. preemption: 0/30 nodes are available: 9 No preemption victims found for incoming pod.

이 오류는 작업자 노드에서 PEERPODS_LIMIT_PER_NODE 제한에 도달했음을 나타냅니다. kata.peerpods.io/vm 리소스는 각 워커 노드에서 사용할 수 있는 피어 파드 슬롯의 수를 나타냅니다.

이 문제를 해결하려면 다음과 같이 하십시오.

1. 현재 한도 및 할당을 확인합니다.

   oc get nodes -o json | jq '.items[] | {name: .metadata.name, allocatable: .status.allocatable["kata.peerpods.io/vm"], capacity: .status.capacity["kata.peerpods.io/vm"]}'
   

2. 현재 실행 중인 피어 포드 수를 확인합니다.

   oc get pods -A -o json | jq '.items[] | select(.spec.runtimeClassName == "kata-remote") | "\(.metadata.namespace)/\(.metadata.name)"' | wc -l
   

3. 워커 노드당 몇 개의 피어 파드를 실행할 수 있나요? 에 설명된 대로 PEERPODS_LIMIT_PER_NODE 값을 늘립니다.

4. 또는 클러스터에 워커 노드를 더 추가하여 총 용량을 늘릴 수도 있습니다.

기밀 컨테이너가 NIST 800-53 R5 과 같은 특정 보안 표준을 충족할 수 있나요?

OpenShift 샌드박스 컨테이너 오퍼레이터( 1.12.1 )로 업그레이드한 후 IAM 인증 오류가 발생하는 이유는 무엇인가요?

OpenShift 의 Sandboxed Containers Operator를 버전 1.12.1 으로 업그레이드한 후, Cloud API Adapter(CAA) 로그에서 다음과 유사한 오류가 표시될 수 있습니다

cloud-api-adaptor: cluster error with:
 Unauthorized
further details:
 {
    "StatusCode": 401,
    "Result": {
        "code": "A0007",
        "description": "You do not have the correct permissions to perform this action..."
    }
}

이 오류는 버전 1.12.1 부터 IBM Cloud IKS 클러스터 서비스 API를 통해 클러스터의 보안 그룹을 자동으로 가져오도록 하는 새로운 요구 사항이 도입되었기 때문에 발생합니다. IBMCLOUD_IAM_PROFILE_ID 를 인증(컴퓨팅 리소스 ID)에 사용할 경우, IAM 프로필에 클러스터 서비스 API를 조회하는 데 필요한 권한이 없을 수 있습니다.

이 문제를 해결하려면 다음 옵션 중 하나를 선택하십시오

1. 추가 IAM 권한 부여 (권장): IAM 프로필을 업데이트하여 IKS 클러스터 서비스 API에 대한 권한, 특히 GetClusterTypeSecurityGroups() 을 호출할 수 있는 권한을 포함시키십시오. IBM Cloud 관리자에게 문의하여 필요한 권한을 추가해 주십시오.

2. 보안 그룹 ID를 명시적으로 설정 : peer-pods-cm ConfigMap 에서 IBMCLOUD_VPC_SG_ID 환경 변수를 구성하여 클러스터 보안 그룹의 자동 조회를 우회하십시오:

   oc -n openshift-sandboxed-containers-operator patch cm peer-pods-cm \
     --type merge \
     -p '{"data":{"IBMCLOUD_VPC_SG_ID":"<your-security-group-id>"}}'
   

   그런 다음 Cloud API Adapter 데몬셋을 다시 시작합니다:

   oc -n openshift-sandboxed-containers-operator rollout restart daemonset/osc-caa-ds
   

3. API 키 인증 사용: IBMCLOUD_IAM_PROFILE_ID 인증에서 IBMCLOUD_API_KEY 인증으로 전환하세요. 후자의 경우 일반적으로 더 광범위한 권한을 부여합니다. IAM 프로필을 사용하는 대신, peer-pods-secret 의 시크릿을 본인의 API 키로 업데이트하십시오.

1.12.1 버전의 변경 사항에 대한 자세한 내용은 업스트림 cloud-api-adaptor 커밋(dde66055 )을 참조하십시오.

구체적인 보안 관심사에 대해 논의하려면 IBM 팀에 문의하세요.

VPC 워커 노드의 기본 표준 시간대는 무엇인가요?

2026년 1월 27일 릴리스된 패치 버전 4.16.56_1602 부터 향후 모든 VPC 클러스터용 패치는 워커 노드의 현지 시간을 UTC로 설정합니다.