자주 묻는 질문 IBM Cloud® Kubernetes Service

IBM Cloud® Kubernetes Service 사용에 관한 자주 묻는 질문( 자주 묻는 질문 )을 확인해 보세요.

Kubernetes란 무엇입니까?

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

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

IBM Cloud Kubernetes Service 클러스터를 작성하는 방법은 무엇입니까?

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

학습서를 따르겠습니다.
먼저 시작하기 문서를 검토한 후 사용 가능한 학습서 중 하나를 선택하십시오.
고유한 클러스터 환경을 디자인하려고 합니다.
먼저 시작하기 문서를 검토한 후 클러스터 환경 전략을 작성 하십시오.

IBM Cloud Kubernetes Service는 어떻게 작동합니까?

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

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

IBM Cloud Kubernetes Service를 사용해야 하는 이유는 무엇입니까?

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

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

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

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 튜토리얼을 사용해 보십시오.

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

IBM Cloud Kubernetes Service의 모든 클러스터는 IBM에서 IBM 소유 IBM Cloud 인프라 계정으로 관리하는 전용 Kubernetes 마스터에 의해 제어됩니다. Kubernetes 마스터(모든 마스터 컴포넌트, 컴퓨팅, 네트워킹 및 스토리지 리소스 포함)는 IBM 사이트 신뢰성 엔지니어(SRE)에 의해 지속적으로 모니터링됩니다. SRE는 최신 보안 표준을 적용하고, 악성 활동을 발견하고 교정하며 IBM Cloud Kubernetes Service의 신뢰성 및 가용성을 보장하기 위해 작업을 수행합니다. 클러스터를 프로비저닝할 때 자동으로 설치되는 추가 기능(예: 로깅을 위한 Fluentd)은 IBM에서 자동으로 업데이트합니다. 그러나 일부 추가 기능에 대한 자동 업데이트를 사용 안함으로 설정하고 마스터 및 작업자 노드와 별도로 수동으로 업데이트할 수 있습니다. 자세한 정보는 클러스터 추가 기능 업데이트를 참조하십시오.

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

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

IBM Cloud Kubernetes Service으로 이동할 수 있는 워크로드 유형은 무엇입니까?

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

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

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

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

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

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

이미 앱이 있는 경우 해당 앱을 IBM Cloud Kubernetes Service로 마이그레이션할 수 있습니다. 새 앱을 개발하려면 stateless, 클라우드 네이티브 앱 개발을 위한 지침을 참조하십시오.

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

IBM Cloud Code Engine 서비스를 통해 서버리스 앱과 작업을 실행할 수 있습니다. Code Engine에서는 사용자의 이미지를 빌드할 수도 있습니다. Code Engine의 경우, 이는 빌드된 기본 기술과 상호작용할 필요가 없도록 설계되었습니다. 그러나 Kubernetes 또는 Knative를 기반으로 한 기존 도구가 있는 경우 Code Engine에서 해당 도구를 계속 사용할 수 있습니다. 자세한 정보는 Kubernetes를 사용한 애플리케이션과의 상호작용을 참조하십시오.

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

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

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

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

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

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

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

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

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

클러스터 컴포넌트 및 각 컴포넌트의 보안 표준을 따르는 방법에 대한 자세한 정보는 IBM Cloud Kubernetes Service에 대한 보안을 참조하십시오.

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

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

API 키를 설정하는 사용자에게는 어떤 권한이 필요한가요? 사용자에게 이러한 권한을 부여하려면 어떻게 해야 하나요?

최소한 관리자 또는 준수 관리 역할에는 클러스터를 작성할 수 있는 권한이 있습니다. 그러나 클러스터에서 사용하는 다른 서비스 및 통합에 대한 추가 권한이 필요할 수 있습니다. 자세한 정보는 클러스터 작성 권한 을 참조하십시오.

사용자의 권한을 확인하려면, IBM Cloud 콘솔에서 해당 사용자의 액세스 정책 및 액세스 그룹을 검토하거나, ibmcloud iam user-policies <user> 명령을 사용하십시오.

API 키가 특정 사용자를 기준으로 할당된 경우, 해당 리전 및 리소스 그룹 내의 다른 클러스터 사용자에게는 어떤 영향이 미치나요?

계정의 지역 및 리소스 그룹 내 다른 사용자는 IBM Cloud Kubernetes Service 클러스터와 인프라 및 기타 서비스에 액세스하는 데 필요한 API 키를 공유합니다. 사용자가 IBM Cloud 계정에 로그인하면 API 키를 기반으로 하는 IBM Cloud IAM 토큰이 CLI 세션에 대해 생성되어 인프라 관련 명령을 클러스터에서 실행할 수 있습니다.

특정 리전 및 리소스 그룹에 대한 API 키를 설정한 사용자가 회사를 퇴사하면 어떻게 되나요?

사용자가 퇴사할 경우 IBM Cloud 계정 소유자가 해당 사용자의 권한을 제거할 수 있습니다. 그러나 사용자의 특정 액세스 권한을 제거하거나 계정에서 사용자를 완전히 제거하기 전에 다른 사용자의 인프라 인증 정보를 사용하여 API 키를 재설정해야 합니다. 그렇지 않으면 계정 내의 다른 사용자가 IBM Cloud 인프라 포털에 액세스할 수 없게 되고 인프라 관련 명령이 실패할 수 있습니다. 자세한 정보는 사용자 권한 제거를 참조하십시오.

API 키가 유출된 경우 클러스터를 어떻게 잠글 수 있나요?

클러스터에서 지역 및 리소스 그룹에 대해 설정된 API 키가 손상된 경우 해당 키를 인증으로 사용하여 호출이 이루어질 수 없도록 API 키를 삭제하십시오. Kubernetes API 서버에 대한 액세스 보안 설정에 대한 자세한 정보는 Kubernetes API 서버 및 etcd 보안 주제를 참조하십시오.

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

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

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

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

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

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

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

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

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

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

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

클래식 또는 VPC 클러스터
클러스터에는 항상 하나 이상의 작업자 노드가 있어야 합니다. 워커 노드가 0개인 클러스터를 구성할 수 없으며, 워커 노드의 전원을 끄거나 요금 청구를 일시 중지할 수 없다는 점에 유의하십시오.
Satellite 클러스터
클러스터는 단일 복제본 토폴로지를 사용하여 작성할 수 있으며, 이는 하나의 작업자 노드만을 의미합니다. 단일 복제본 토폴로지를 사용하여 Satellite 클러스터를 작성하는 경우 나중에 작업자 노드를 추가할 수 없습니다.

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

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

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

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

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

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

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

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

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

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

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

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

IBM Cloud Kubernetes Service 마스터는 어떻게 구성되어 있나요?

다중 구역 위치에 클러스터를 작성하면 고가용성 마스터가 자동으로 배치되며 메트로 구역에 세 개의 복제본이 분산됩니다. 예를 들어, 클러스터가 dal10, dal12 또는 dal13 구역에 있으면 마스터의 복제본은 댈러스 다중 구역 메트로의 각 구역에 전개됩니다.

마스터가 다른 존에 있는 워커들과 통신할 수 있도록 제가 별도로 설정해야 할 사항이 있나요?

VPC 다중 구역 클러스터를 작성한 경우, 각 구역의 서브넷은 구역에서 마스터와 작업자 노드 간의 통신을 허용하는 액세스 제어 목록(ACL)을 사용하여 자동으로 설정됩니다. 클래식 클러스터에서 클러스터용 다중 VLAN, 동일한 VLAN의 다중 서브넷 또는 다중 구역 클래식 클러스터가 있는 경우에는 작업자 노드가 사설 네트워크에서 서로 간에 통신할 수 있도록 IBM Cloud 인프라 계정에 대해 VRF(Virtual Router Function)를 사용으로 설정해야 합니다. VRF를 사용으로 설정하려면 VRF 사용을 참조하십시오. VRF가 이미 사용으로 설정되었는지 확인하려면 ibmcloud account show 명령을 사용하십시오. VRF를 사용할 수 없거나 사용하지 않으려면 VLAN Spanning을 사용으로 설정하십시오. 이 작업을 수행하려면 ‘ 네트워크 > 네트워크 VLAN 스패닝 관리 ’ 인프라 권한이 필요하며, 해당 권한이 없는 경우 계정 소유자에게 권한을 활성화해 달라고 요청할 수 있습니다. VLAN 스패닝이 이미 활성화되어 있는지 확인하려면 ibmcloud ks vlan spanning get --region 명령 을 사용하십시오.

단일 영역 클러스터를 다중 영역 클러스터로 전환할 수 있나요?

단일 영역 클러스터를 다중 영역 클러스터로 변환하려면 가용 영역이 두 개 이상인 위치에 클러스터를 설정해야 합니다.

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

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

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

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

앱 간에 워크로드를 로드 밸런싱하려면 ALB및 NLB의 공인 IP 주소를 CIS 글로벌 로드 밸런서 또는 사용자 고유 글로벌 로드 밸런서에 추가하십시오.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 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 인프라: IBM Cloud Kubernetes Service 은 다음 보안 표준에 부합하는 통제 조치를 시행하고 있습니다:

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

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

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

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

클러스터에 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 ks cluster create classic 또는 ibmcloud ks 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자 정책을 참조하십시오.

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

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

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

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

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

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

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

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

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

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

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

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

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

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