Considerations¶
On this page
Set MANAGED_SECURITY_CONTEXT
for Kubernetes Operator OpenShift Deployments¶
When you deploy the Kubernetes Operator to OpenShift, you must set the
MANAGED_SECURITY_CONTEXT
flag to true
. This value is set for
you:
- In the mongodb-enterprise-openshift.yaml file.
- In the values-openshift.yaml file.
Both files are included in the MongoDB Enterprise Kubernetes Operator GitHub repository.
To learn more, see the Operator installation and choose the method you want to use.
Docker Container Details¶
MongoDB builds the container images from the latest builds of the following operating systems:
If you get your Kubernetes Operator from… | …the Container uses |
---|---|
quay.io mongodb-enterprise-operator repository or GitHub | Ubuntu 16.04 |
quay.io mongodb-enterprise-operator-ubi repository | Red Hat UBI 8 |
OpenShift | Red Hat UBI 8 |
MongoDB, Inc. updates all packages on these images before releasing them every three weeks.
Check Messages from the Validation Webhook¶
The Kubernetes Operator uses a validation Webhook to prevent users from applying invalid resource definitions. The webhook rejects invalid requests.
The ClusterRole and ClusterRoleBinding for the webhook are included in the default configuration files that you apply during the installation. To create the role and binding, you must have cluster-admin privileges.
If you create an invalid resource definition, the webhook returns a message similar to the following that describes the error to the shell:
When the Kubernetes Operator reconciles each resource, it also validates that resource. The Kubernetes Operator doesn’t require the validation webhook to create or update resources.
If you omit the validation webhook, or if you remove the webhook’s role
and binding from the default configuration, or have insufficient
privileges to run the configuration, the Kubernetes Operator issues warnings,
as these are not critical errors. If the Kubernetes Operator encounters a
critical error, it marks the resource as Failed
.
GKE deployments
GKE has a known issue with the webhook when deploying to private clusters. To learn more, see Update Google Firewall Rules to Fix WebHook Issues.
Customize the CustomResourceDefinitions that the Kubernetes Operator Watches¶
Earlier versions of the Kubernetes Operator would crash on startup if any one of the MongoDB CustomResourceDefinitions was not present in the cluster. For instance, you had to install the CustomResourceDefinition for Ops Manager even if you did not plan to deploy it with the Kubernetes Operator.
You can now specify which custom resources you want the Kubernetes Operator to watch. This allows you to install the CustomResourceDefinition for only the resources that you want the Kubernetes Operator to manage.
You must use helm
to configure the Kubernetes Operator to watch only the
custom resources you specify. Follow the relevant helm
installation instructions,
but make the following adjustments:
Decide which CustomResourceDefinitions you want to install. You can install any number of the following:
Value Description mongodb
Install the CustomResourceDefinitions for the database resources and also watch those resources. mongodbusers
Install the CustomResourceDefinitions for the MongoDB user resources and also watch those resources. opsmanagers
Install the CustomResourceDefinitions for the Ops Manager resources and also watch those resources. Install each CustomResourceDefinition that you want the Kubernetes Operator to manage from the helm_chart/crds directory:
Install the Helm Chart and specify which CustomResourceDefinitions you want the Kubernetes Operator to watch.
Separate each custom resource with a comma: