서비스의 아키텍처 및 종속 항목
Red Hat® OpenShift® on IBM Cloud® 클러스터에 대한 샘플 아키텍처, 컴포넌트 및 종속 항목을 검토하십시오.
Red Hat OpenShift on IBM Cloud에서, 사용자의 클러스터는 Red Hat OpenShift 제공 기본 컴포넌트뿐만 아니라 애플리케이션 워크로드를 실행하도록 구성한 고객 관리 작업자 노드 및 API 서버 및 etcd와 같은 컴포넌트를 보호하는 IBM 관리 마스터를 구성합니다. 클러스터 내 기본 컴포넌트(예: Red Hat OpenShift 웹 콘솔 또는 OperatorHub)는 클러스터의 Red Hat OpenShift 버전에 따라 달라집니다.
클래식 Red Hat OpenShift 아키텍처
아키텍처 다이어그램을 검토한 다음 다음 표를 스크롤하여 클래식 인프라에서 실행되는 Red Hat OpenShift on IBM Cloud 클러스터의 마스터 및 워커 노드 구성 요소에 대해 설명합니다. OpenShift Container Platform 아키텍처에 대한 자세한 내용은 Red Hat OpenShift 문서를 참조하세요.
oc get nodes
를 실행할 때 작업자 노드의 역할이 master,worker
둘 다로 표시됨을 알게 됩니다. 이러한 노드는 IBM Cloud의 작업자 노드이며 IBM에서 관리하는 마스터 컴포넌트를 포함하지 않습니다. 대신, 이러한 노드는 클러스터 내에서 기본 리소스(예: OperatorHub 및 내부 레지스트리)를 설정하고 관리하는 데 필요한 OpenShift
Container Platform 컴포넌트를 실행하기 때문에 master
로 표시됩니다.
Red Hat OpenShift 마스터 구성요소
Red Hat OpenShift on IBM Cloud 클러스터의 IBM 관리 마스터에서 다음 컴포넌트를 검토하십시오.
이러한 컴포넌트는 수정할 수 없습니다. IBM은 컴포넌트를 관리하고 마스터 패치 업데이트 중에 컴포넌트를 자동으로 업데이트합니다.
OpenShift Container Platform 4에서, 많은 컴포넌트들이 관리의 용이함을 위해 해당 오퍼레이터에 의해 구성됩니다. 다음 표는 이러한 오퍼레이터와 컴포넌트를 함께 설명하며 컴포넌트가 클러스터에 제공하는 기본 기능에 초점을 맞춥니다.
- 단일 테넌시
-
마스터 및 모든 마스터 컴포넌트는 사용자 전용이며 다른 IBM 고객과 공유되지 않습니다.
- 복제본
-
Red Hat OpenShift API 서버 및 etcd 데이터 저장소를 포함한 마스터 컴포넌트에는 세 개의 복제본이 있으며 다중 구역 대도시에 있는 경우 보다 높은 가용성을 위해 구역에 분산됩니다. 마스터 컴포넌트는 8시간마다 백업됩니다.
cloud-controller-manager
-
클라우드 제어기 관리자는 클라우드 제공자별 컴포넌트(예: IBM Cloud 로드 밸런서)를 관리합니다.
cluster-health
-
클러스터 상태 컴포넌트는 클러스터의 상태를 모니터하고 서비스에 대한 IBM Cloud모니터링 및 메트릭과 통합됩니다.
cluster-policy-controller
-
는
cluster-policy-controller
는 클러스터 내에서 파드를 생성하는 데 필요한 정책 리소스를 유지 관리합니다. cluster-version-operator
-
클러스터 버전 오퍼레이터(CVO)는 클러스터에서 실행하는 기타 오퍼레이터를 설치하고 업데이트합니다. 자세한 내용은 GitHub 프로젝트를 참조하세요.
control-plane-operator
-
제어 플레인 오퍼레이터는 마스터에서 제어 플레인 컴포넌트의 설치 및 업데이트를 관리합니다.
etcd
,etcd-molecule
,etcd-operator
-
etcd는 서비스, 배치 및 팟(Pod) 등 클러스터의 모든 Kubernetes 리소스의 상태를 저장하는 고가용성의 키 값 저장소입니다. etcd의 데이터는 IBM이 관리하는 암호화된 스토리지 인스턴스에 8시간마다 백업됩니다.
kube-controller-manager
,openshift-controller-manager
-
Kubernetes 컨트롤러는 워크로드의 복제본 세트와 같은 클러스터 내 오브젝트의 상태를 감시합니다. 오브젝트의 상태가 변경되는 경우(예: 복제본 세트의 팟(Pod)이 작동 중지됨), 제어기 관리자는 정정 조치를 시작하여 필수 상태를 얻습니다. Red Hat OpenShift 제어기는 프로젝트 같은 Red Hat OpenShift API에 특정한 오브젝트에 대해 동일한 기능을 수행합니다.
kube-scheduler
-
Kubernetes 스케줄러는 새로 생성된 파드를 감시하고 용량, 성능 요구 사항, 정책 제약, 안티-친화 사양, 워크로드 요구 사항에 따라 배포할 위치를 결정합니다. 요구사항과 일치하는 작업자 노드를 찾을 수 없으면 팟(Pod)이 클러스터에 배치되지 않습니다.
manifests-bootstrapper
-
manifests-boot-strapper
작업은 클러스터의 마스터 노드로 참여하기 위해 필요한 인증서를 사용하여 마스터를 설정합니다. oauth-openshift
-
기본 제공 OAuth 서버는 IBM Cloud Identity and Access Management(IAM)와 통합하기 위해 자동으로 설정됩니다. 지원되는 기타 ID 제공자를 클러스터에 추가할 수 없습니다. IAM을 통해 클러스터에 인증하는 방법에 대한 자세한 정보는 Red Hat OpenShift 클러스터에 액세스를 참조하십시오.
openshift-apiserver
,openshift-apiserver-operator
,kube-apiserver
-
API 서버는 작업자 노드에서 마스터로의 모든 클러스터 관리 요청에 대한 기본 시작점입니다. API 서버는 팟(Pod) 또는 서비스 등의 Kubernetes 오브젝트 및 프로젝트나 사용자와 같은 Red Hat OpenShift 오브젝트의 상태를 변경하는 요청을 유효성 검증하고 처리합니다. 그런 다음, API 서버는 이 상태를 etcd 데이터 저장소에 저장합니다.
konnectivity-server
,konnectivity-operator
-
연결 서버는 연결 에이전트와 함께 작동하여 마스터를 작업자 노드에 안전하게 연결합니다. 이 연결은 팟(Pod) 및 서비스에 대한
apiserver proxy
호출과 kubelet에 대한oc exec
,attach
및logs
호출을 지원하고 웹훅을 변경 및 검증합니다. - 승인 제어기
-
허가 제어기는 Red Hat OpenShift on IBM Cloud 클러스터의 특정 기능을 위해 구현되었습니다. 허가 제어기를 사용하면 클러스터의 특정 조치가 허용되는지 여부를 판별하는 클러스터의 정책을 설정할 수 있습니다. 이 정책에서는 사용자가 조치를 수행할 수 없을 때의 조건을 지정할 수 있습니다(이 조치가 RBAC 역할을 사용하여 사용자에게 지정된 일반 권한의 일부인 경우에도). 따라서 허가 제어기는 API 요청이 Red Hat OpenShift API 서버에서 처리되기 전에 클러스터에 대한 추가 보안 계층을 제공할 수 있습니다. Red Hat OpenShift 클러스터를 만들면 다음 Kubernetes 어드미션 컨트롤러가 지정된 순서대로 Red Hat OpenShift 마스터에 자동으로 설치되며, 이는 사용자가 변경할 수 없습니다:
NamespaceLifecycle
LimitRanger
ServiceAccount
DefaultStorageClass
ResourceQuota
StorageObjectInUseProtection
PersistentVolumeClaimResize
Priority
BuildByStrategy
OriginPodNodeEnvironment
PodNodeSelector
ExternalIPRanger
NodeRestriction
SecurityContextConstraint
SCCExecRestrictions
PersistentVolumeLabel
OwnerReferencesPermissionEnforcement
PodTolerationRestriction
openshift.io/JenkinsBootstrapper
openshift.io/BuildConfigSecretInjector
openshift.io/ImageLimitRange
openshift.io/RestrictedEndpointsAdmission
openshift.io/ImagePolicy
openshift.io/IngressAdmission
openshift.io/ClusterResourceQuota
MutatingAdmissionWebhook
ValidatingAdmissionWebhook
-
클러스터에 자체 입학 컨트롤러를 설치하거나 Red Hat OpenShift on IBM Cloud 에서 제공하는 옵션 입학 컨트롤러 중에서 선택할 수 있습니다. 컨테이너 이미지 보안 적용: 설치 Portieris 를 설치하여 서명되지 않은 이미지의 컨테이너 배포를 차단하세요.
-
수동으로 허가 제어기를 설치했으며 이를 더 이상 사용하지 않으려면 반드시 이를 완전히 제거해야 합니다. 허가 제어기가 완전히 제거되지 않은 경우 클러스터에서 수행하려는 모든 조치를 차단할 수 있습니다.
Red Hat OpenShift 워커 노드 컴포넌트
Red Hat OpenShift on IBM Cloud 클러스터의 고객 관리 작업자 노드에서 다음 컴포넌트를 검토하십시오.
이러한 컴포넌트는 사용자가 클러스터에 배치하는 워크로드와 함께 사용할 수 있으므로 작업자 노드에서 실행됩니다. 예를 들어, 앱은 내부 레지스트리의 이미지에서 컨테이너를 실행하는 OperatorHub의 오퍼레이터를 사용할 수 있습니다. 사용자는 이러한 컴포넌트의 사용에 책임이 있지만 IBM은 사용자가 적용하도록 선택한 작업자 노드 패치 업데이트에서 이러한 컴포넌트의 업데이트를 제공합니다.
OpenShift Container Platform 에서는 관리의 용이성을 위해 많은 구성 요소가 해당 운영자에 의해 구성됩니다. 다음 표는 이러한 오퍼레이터와 컴포넌트를 함께 설명하며 컴포넌트가 클러스터에 제공하는 기본 기능에 초점을 맞춥니다.
- 단일 테넌시
- 작업자 노드 및 모든 작업자 노드 컴포넌트는 사용자 전용이며 다른 IBM 고객과 공유되지 않습니다. 그러나 워커 노드 가상 머신을 사용하는 경우 선택한 하드웨어 격리 수준에 따라 기본 하드웨어가 다른 IBM 고객과 공유될 수 있습니다.
- 운영 체제
- 클러스터 버전별 지원되는 운영 체제 목록은 버전 정보 를 참조하십시오.
- CRI-O 컨테이너 런타임
- 워커 노드는 컨테이너 런타임 인터페이스로 CRI-O 를 컨테이너 런타임 인터페이스로 사용합니다. 자세한 정보는 컨테이너 런타임을 참조하십시오.
- 프로젝트
- Red Hat OpenShift는 리소스를 어노테이션이 포함된 Kubernetes 네임스페이스인 프로젝트로 구성하며, 커뮤니티 Kubernetes 클러스터보다 훨씬 더 많은 컴포넌트를 포함하여 Red Hat OpenShift 기능(예: 카탈로그)을 실행합니다. 프로젝트의 컴포넌트 선택은 다음 행에 설명되어 있습니다. 자세한 내용은 프로젝트 작업을 참조하세요.
calico-system
,tigera-operator
- Calico는 클러스터에 대한 네트워크 정책을 관리하고, 컨테이너 네트워크 연결, IP 주소 지정 및 네트워크 트래픽 제어를 관리하도록 일부 컴포넌트를 포함합니다. Tigera 운영자는 Calico 컴포넌트의 라이프사이클을 설치하고 관리합니다.
default
- 이 프로젝트는 프로젝트를 지정하지 않거나 Kubernetes 리소스에 대한 프로젝트를 작성하지 않은 경우에 사용됩니다.
ibm-system
- 이 프로젝트에는 앱 팟(Pod)에 대한 요청을 위해 상태 검사 및 계층 4 로드 밸런싱을 제공하도록
ibm-cloud-provider-ip
에 대해 작업하는keepalived
배치도 포함됩니다. kube-system
- 이 프로젝트에는 작업자 노드에서 Kubernetes를 실행하는 데 사용되는 많은 컴포넌트가 포함되어 있습니다.
ibm-master-proxy
:ibm-master-proxy
는 작업자 노드에서 고가용성 마스터 복제본의 IP 주소로 요청을 전달하는 디먼 세트입니다. 단일 구역 클러스터의 마스터에는 3개의 복제본이 있습니다. 다중 구역 가능 구역에 있는 클러스터의 경우, 마스터에는 구역 간에 전개된 3개의 복제본이 있습니다. 고가용성 로드 밸런서는 마스터 도메인 이름에 대한 요청을 마스터 복제본에 전달합니다.kubelet
: kubelet는 모든 작업자 노드에서 실행되는 작업자 노드 에이전트이며, 작업자 노드에서 실행되는 팟(Pod)의 상태를 모니터하고 Kubernetes API 서버가 전송하는 이벤트를 감시하는 역할을 담당합니다. 이벤트를 기반으로, kubelet는 팟(Pod)을 작성 또는 제거하고 활성 상태 및 준비 상태 프로브를 보장하며 팟(Pod)의 상태를 다시 API 서버에 보고합니다.vpn
: 연결 에이전트는 연결 서버와 함께 작동하여 마스터를 작업자 노드에 안전하게 연결합니다. 이 연결은 팟(Pod) 및 서비스에 대한apiserver proxy
호출과 kubelet에 대한oc exec
,attach
및logs
호출을 지원합니다.- 기타 컴포넌트:
kube-system
프로젝트에는 파일 및 블록 스토리지에 대한 스토리지 플러그인, Ingress 애플리케이션 로드 밸런서(ALB) 및keepalived
와 같은 IBM 제공 리소스를 관리하기 위한 컴포넌트도 포함됩니다.
openshift-cloud-credential-operator
- 클라우드 인증 정보 운영자는 클라우드 제공자 인증 정보를 요청하는 Red Hat OpenShift 컴포넌트에 대한 제어기를 관리합니다. 제어기는 조작에 필요한 인증 정보만 사용하며
admin
같은 승격된 권한은 사용하지 않도록 합니다. 자세한 내용은 GitHub 프로젝트를 참조하세요. openshift-cluster-node-tuning-operator
- IBM 는 클러스터의 각 워커 노드에서 데몬 세트를 실행하여 워커 노드를 튜닝하는 노드 튜닝 오퍼레이터를 관리합니다.
openshift-cluster-samples-operator
- 샘플 운영자는 기본적으로 Red Hat OpenShift 클러스터와 함께 제공되는 일부 이미지 스트림 및 템플릿을 관리합니다. 이러한 템플릿은 Red Hat OpenShift 웹 콘솔의 개발자 관점에서 배포할 수 있습니다.
openshift-cluster-storage-operator
- 클러스터 스토리지 오퍼레이터는 기본 스토리지 클래스가 설정되었는지 확인합니다.
openshift-console
,openshift-console-operator
- Red Hat OpenShift 웹 콘솔은 클러스터에서 실행되는 Red Hat OpenShift 및 Kubernetes 리소스를 관리하는 데 사용할 수 있는 웹 기반 인터페이스입니다. 또한 콘솔을 사용하여
oc login
토큰을 표시하고 CLI에서 클러스터에 대해 인증할 수 있습니다. 자세한 정보는 Red Hat OpenShift 콘솔 탐색을 참조하십시오. openshift-dns
,openshift-dns-operator
- DNS 프로젝트에는 작업자 노드에 설정되는
iptables
규칙 및 클러스터에 들어가거나 클러스터를 나가도록 허용되는 프록시 요청에 대해 수신 네트워크 트래픽을 유효성 검증하도록 컴포넌트가 포함됩니다. openshift-image-registry
- Red Hat OpenShift 는 콘솔을 통해 이미지를 로컬로 관리하고 확인하는 데 사용할 수 있는 내부 컨테이너 이미지 레지스트리를 제공합니다. 또는
개인용 IBM Cloud Container Registry를 설정하거나 IBM Cloud Container Registry에서 내부 레지스트리로 이미지를 가져오기할
수 있습니다. 내부 레지스트리는 IBM Cloud 인프라 계정에 File Storage for Classic 볼륨을 제공하여 레지스트리 이미지를 저장합니다. File Storage 볼륨은
image-registry-storage
지속적 볼륨 청구(PVC)를 통해 프로비저닝됩니다. openshift-ingress
,openshift-ingress-operator
- Red Hat OpenShift 는 경로를 사용하여 호스트 이름에 앱의 서비스를 직접 노출하여 외부 클라이언트가 서비스에 도달할 수 있도록 합니다. 클러스터는 라우트를 작성하기 위해 Ingress 오퍼레이터를 사용합니다. Ingress 를 사용하여 앱을 외부에 노출하고 라우팅을 사용자 정의할 수도 있습니다. Ingress는 Ingress 오퍼레이터, Ingress 제어기 및 라우트 리소스의 세 가지 컴포넌트로 구성됩니다. Ingress 제어기는 서비스를 호스트 이름에 맵핑합니다. 기본적으로 Ingress 제어기에는 두 개의 복제본이 포함됩니다. Ingress 제어기가 고가용성을 위해 개별 컴퓨팅 호스트에서 실행될 수 있도록 클러스터에 둘 이상의 작업자 노드가 있는지 확인하십시오.
openshift-marketplace
- 마켓플레이스에는 기본적으로 제공되는 OperatorHub 가 기본적으로 Red Hat OpenShift 클러스터와 함께 제공됩니다. OperatorHub는 Red Hat 및 서드파티 제공자의 오퍼레이터를 포함합니다. 이러한 오퍼레이터는 커뮤니티에서 제공하며, 클러스터와 통합되지 않고 IBM이 지원하지 않는다는 점을 유의하십시오. Red Hat OpenShift 웹 콘솔의 OperatorHub 에서 운영자를 활성화할 수 있습니다.
openshift-monitoring
- OpenShift Container Platform 에는 메트릭 및 알림 관리 기능을 포함하는 클러스터용 기본 제공 모니터링 스택이 포함되어 있습니다. 기본 제공 모니터링 스택과 기타 옵션(예: IBM Cloud Monitoring)을 비교하려면 로깅 및 모니터링에 대한 옵션 이해를 참조하십시오.
openshift-multus
- OpenShift Container Platform 는 Multus 컨테이너 네트워크 인터페이스(CNI) 플러그인을 사용하여 여러 개의 파드 네트워크를 허용합니다. 그러나 다중 팟(Pod) 네트워크를 사용하도록 클러스터를 구성할 수는 없습니다. Red Hat OpenShift on IBM Cloud 클러스터는 기본적으로 클러스터에 대해 설정된 Calico만 지원합니다. 활성화하면 서비스 메시가 Multus 플러그인을 사용합니다.
openshift-network-operator
- CNO(클러스터 네트워크 운영자) 는 CNI 포드 네트워크 공급자 플러그인 및 DNS 운영자와 같이 기본적으로 설정되는 클러스터 네트워크 구성 요소를 관리합니다.
openshift-operator-lifecycle-manager
- 운영자 수명 주기 관리자(OLM )는 기본 구성 요소의 운영자 및 추가하는 사용자 지정 운영자를 포함하여 클러스터에서 실행되는 모든 운영자 및 카탈로그의 수명 주기를 관리합니다.
openshift-service-ca
,openshift-service-ca-operator
- 인증 기관(CA) 오퍼레이터는 인증서 서명을 실행하고 클러스터의 API 서버 리소스 및 구성 맵에 인증서를 삽입합니다. 자세한 내용은 GitHub 프로젝트를 참조하세요.
VPC 클러스터 서비스 아키텍처
다음 아키텍처 개요는 VPC 인프라 제공자에만 해당합니다. 클래식 인프라 제공자에 대한 아키텍처 개요는 클래식 클러스터 서비스 아키텍처를 참조하십시오.
아키텍처 다이어그램을 검토한 다음 다음 표를 스크롤하여 가상 프라이빗 클라우드(VPC) 컴퓨팅 인프라에서 실행되는 Red Hat OpenShift on IBM Cloud 클러스터의 마스터 및 워커 노드 구성 요소에 대한 설명을 확인하세요.
퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트가 있는 클러스터
다음 다이어그램에서는 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트가 둘 다 사용 가능한 경우 클러스터 컴포넌트 및 이 클러스터의 컴포넌트가 상호작용하는 방법을 보여줍니다. 두 서비스 엔드포인트가 사용으로 설정되었으므로 VPC는 서비스마다 인바운드 트래픽에 대한 공용 로드 밸런스를 작성합니다.
프라이빗 클라우드 서비스 엔드포인트만 있는 클러스터
다음 다이어그램에서는 프라이빗 클라우드 서비스 엔드포인트만 사용 가능한 경우 클러스터 컴포넌트 및 이 클러스터의 컴포넌트가 상호작용하는 방법을 보여줍니다. 프라이빗 클라우드 서비스 엔드포인트만 사용 가능하므로 VPC는 서비스마다 인바운드 트래픽에 대한 사설 로드 밸런서를 작성합니다.
VPC 마스터 및 워커 노드 구성 요소
마스터 및 워커 노드에는 클러스터용 클래식 클러스터 아키텍처에 설명된 것과 동일한 구성 요소가 포함됩니다. OpenShift Container Platform 아키텍처에 대한 자세한 내용은 Red Hat OpenShift 문서를 참조하세요.
- 마스터
- API 서버 및 etcd를 포함한 마스터 컴포넌트에는 세 개의 복제본이 있으며 보다 높은 가용성을 위해 구역에 분산됩니다. 마스터에는 클러스터용 클래식 클러스터 아키텍처에 설명된 것과 동일한 구성 요소가 포함되어 있습니다. 마스터 및 모든 마스터 컴포넌트는 사용자 전용이며 다른 IBM 고객과 공유되지 않습니다.
- 작업자 노드
- Red Hat OpenShift on IBM Cloud를 사용하면 클러스터가 관리하는 가상 머신은 작업자 노드라고 하는 인스턴스입니다. 이러한 작업자 노드 가상 머신 및 모든 작업자 노드 컴포넌트는 사용자 전용이며 다른 IBM 고객과 공유되지 않습니다. 그러나 기반 하드웨어는 다른 IBM 고객과 공유합니다. 작업자 노드는 Red Hat OpenShift on IBM Cloud에서 제공하는 자동화 도구(예: API, CLI, 콘솔 등)를 통해 관리합니다. 클래식 클러스터와 달리 VPC 컴퓨팅 작업자 노드는 인프라 포털 또는 별도의 인프라 청구에 표시되지 않지만, 대신 Red Hat OpenShift on IBM Cloud에서 작업자 노드에 대한 모든 유지보수 및 비용 청구 활동을 관리합니다.
- 워커 노드에는 클래식 클러스터 아키텍처에서 설명한 것과 동일한 구성 요소가 포함됩니다.
oc get nodes
를 실행할 때 작업자 노드의 역할이master,worker
둘 다로 표시됨을 알게 됩니다. 이러한 노드는 IBM Cloud의 작업자 노드이며 IBM에서 관리하는 마스터 컴포넌트를 포함하지 않습니다. 대신, 이러한 노드는 클러스터 내에서 기본 리소스(예: OperatorHub 및 내부 레지스트리)를 설정하고 관리하는 데 필요한 OpenShift Container Platform 컴포넌트를 실행하기 때문에master
로 표시됩니다.- 클러스터 네트워킹
- 지정하는 구역의 VPC 서브넷에 작업자 노드가 작성됩니다. 마스터와 작업자 노드 간의 통신이 사설 네트워크를 통해 수행됩니다. 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트가 사용 가능한 클러스터를 작성하는 경우 인증된 외부 사용자는
oc
명령을 실행하는 등과 같이 공용 네트워크를 통해 마스터와 통신할 수 있습니다. 프라이빗 클라우드 서비스 엔드포인트만 사용되는 클러스터를 작성하는 경우 인증된 외부 사용자는 사설 네트워크를 통해서만 마스터와 통신할 수 있습니다. 사설 네트워크에 VPC VPN, IBM Cloud Direct Link 또는 IBM Cloud Transit Gateway를 설정하여 온프레미스 네트워크, 기타 VPC 또는 클래식 인프라의 리소스와 통신하도록 클러스터를 설정할 수 있습니다. - 앱 네트워킹
- 가상 사설 클라우드 로드 밸런서는 클러스터에서 생성하는 모든 네트워킹 서비스에 대해 클러스터 외부의 VPC에 자동으로 생성됩니다. 예를 들면, VPC 로드 밸런서는 기본적으로 클러스터에 있는 라우터 서비스를 노출합니다. 앱에 대해 Kubernetes
LoadBalancer
서비스를 작성할 수도 있으며, 이렇게 하면 VPC 로드 밸런서가 자동으로 생성됩니다. VPC 로드 밸런서는 다중 구역이며 작업자 노드에서 자동으로 열리는 사설 노드 포트를 통해 앱에 대한 요청을 라우팅합니다. 퍼블릭 및 프라이빗 클라우드 서비스 엔드포인트가 사용 가능한 경우 기본적으로 라우터 및 VPC 로드 밸런서가 공용으로 작성됩니다. 프라이빗 클라우드 서비스 엔드포인트만 사용되는 경우 기본적으로 라우터 및 VPC 로드 밸런서가 개인용으로 작성됩니다. 자세한 정보는 VPC 클러스터의 공용 또는 사설 앱 네트워킹을 참조하십시오. Calico는 클러스터 네트워킹 정책 패브릭으로 사용됩니다. - 스토리지
- IBM Cloud Object Storage 및 Cloud Databases만 설정할 수 있습니다.