3.4. MCG operator
The Multicloud Object Gateway (MCG) operator is an operator for OpenShift Data Foundation along with the OpenShift Data Foundation operator and the Rook-Ceph operator. The MCG operator is available upstream as a standalone operator.
The MCG operator performs the following primary functions:
- Controls and reconciles the Multicloud Object Gateway (MCG) component within OpenShift Data Foundation.
- Manages new user resources such as object bucket claims, bucket classes, and backing stores.
- Creates the default out-of-the-box resources.
A few configurations and information are passed to the MCG operator through the OpenShift Data Foundation operator.
3.4.1. Components 复制链接链接已复制到粘贴板!
The MCG operator does not have sub-components. However, it consists of a reconcile loop for the different resources that are controlled by it.
The MCG operator has a command-line interface (CLI) and is available as a part of OpenShift Data Foundation. It enables the creation, deletion, and querying of various resources. This CLI adds a layer of input sanitation and status validation before the configurations are applied unlike applying a YAML file directly.
3.4.2. Responsibilities and resources 复制链接链接已复制到粘贴板!
The MCG operator reconciles and is responsible for the custom resource definitions (CRDs) and OpenShift Container Platform entities.
- Backing store
- Namespace store
- Bucket class
- Object bucket claims (OBCs)
- NooBaa, pod stateful sets CRD
- Prometheus Rules and Service Monitoring
- Horizontal pod autoscaler (HPA)
Backing store
A resource that the customer has connected to the MCG component. This resource provides MCG the ability to save the data of the provisioned buckets on top of it.
A default backing store is created as part of the deployment depending on the platform that the OpenShift Container Platform is running on. For example, when OpenShift Container Platform or OpenShift Data Foundation is deployed on Amazon Web Services (AWS), it results in a default backing store which is an AWS::S3 bucket. Similarly, for Microsoft Azure, the default backing store is a blob container and so on.
The default backing stores are created using CRDs for the cloud credential operator, which comes with OpenShift Container Platform. There is no limit on the amount of the backing stores that can be added to MCG. The backing stores are used in the bucket class CRD to define the different policies of the bucket. Refer the documentation of the specific OpenShift Data Foundation version to identify the types of services or resources supported as backing stores.
Namespace store
Resources that are used in namespace buckets. No default is created during deployment.
Bucketclass
A default or initial policy for a newly provisioned bucket. The following policies are set in a bucketclass:
- Placement policy
Indicates the backing stores to be attached to the bucket and used to write the data of the bucket. This policy is used for data buckets and for cache policies to indicate the local cache placement. There are two modes of placement policy:
- Spread. Strips the data across the defined backing stores
- Mirror. Creates a full replica on each backing store
- Namespace policy
- A policy for the namespace buckets that defines the resources that are being used for aggregation and the resource used for the write target.
- Cache Policy
- This is a policy for the bucket and sets the hub (the source of truth) and the time to live (TTL) for the cache items.
A default bucket class is created during deployment and it is set with a placement policy that uses the default backing store. There is no limit to the number of bucket class that can be added.
Refer to the documentation of the specific OpenShift Data Foundation version to identify the types of policies that are supported.
Object bucket claims (OBCs)
CRDs that enable provisioning of S3 buckets. With MCG, OBCs receive an optional bucket class to note the initial configuration of the bucket. If a bucket class is not provided, the default bucket class is used.
NooBaa, pod stateful sets CRD
An internal CRD that controls the different pods of the NooBaa deployment such as the DB pod, the core pod, and the endpoints. This CRD must not be changed as it is internal. This operator reconciles the following entities:
- DB pod SCC
- Role Binding and Service Account to allow SSO single sign-on between OpenShift Container Platform and NooBaa user interfaces
- Route for S3 access
- Certificates that are taken and signed by the OpenShift Container Platform and are set on the S3 route
Prometheus rules and service monitoring
These CRDs set up scraping points for Prometheus and alert rules that are supported by MCG.
Horizontal pod autoscaler (HPA)
It is Integrated with the MCG endpoints. The endpoint pods scale up and down according to CPU pressure (amount of S3 traffic).
3.4.3. High availability 复制链接链接已复制到粘贴板!
As an operator, the only high availability provided is that the OpenShift Container Platform reschedules a failed pod.
3.4.4. Relevant log files 复制链接链接已复制到粘贴板!
To troubleshoot issues with the NooBaa operator, you can look at the following:
- Operator pod logs, which are also available through the must-gather.
- Different CRDs or entities and their statuses that are available through the must-gather.
3.4.5. Lifecycle 复制链接链接已复制到粘贴板!
The MCG operator runs and reconciles after OpenShift Data Foundation is deployed and until it is uninstalled.