Navigation

Considerations

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:

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.

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:

error when creating "my-ops-manager.yaml":
admission webhook "ompolicy.mongodb.com" denied the request:
shardPodSpec field is not configurable for application databases as
it is for sharded clusters and appdb replica sets

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:

  1. Decide which CustomResourceDefinitions you want to install. You can install any number of the following:

    Value Description
    mongodb Install the CustomResourceDefinitions for database resources and watch those resources.
    mongodbusers Install the CustomResourceDefinitions for MongoDB user resources and watch those resources.
    opsmanagers Install the CustomResourceDefinitions for Ops Manager resources and watch those resources.
  2. Install each CustomResourceDefinition that you want the Kubernetes Operator to manage from the helm_chart/crds directory:

    kubectl apply -f helm_chart/crds/{value}.mongodb.com.yaml
    
  3. Install the Helm Chart and specify which CustomResourceDefinitions you want the Kubernetes Operator to watch.

    Separate each custom resource with a comma:

    helm install <chart-name> helm_chart \
         --operator.watchedResources="{mongodb,mongodbusers}" \
         --skip-crds