You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you need a Kubernetes solution, see the [Kubernetes documentation on picking the right solution](https://kubernetes.io/docs/setup). For testing, MongoDB recommends [Kind](https://kind.sigs.k8s.io/).
The MongoDB Community Kubernetes Operator is a [Custom Resource Definition](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) and a controller.
42
-
43
-
To install the MongoDB Community Kubernetes Operator:
44
-
45
-
1. Change to the directory in which you cloned the repository.
46
-
2. Install the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
b. Verify that the Operator installed successsfully:
63
-
```
64
-
kubectl get pods --namespace <my-namespace>
65
-
```
66
-
67
-
## Upgrade the Operator
68
-
69
-
To upgrade the MongoDB Community Kubernetes Operator:
70
-
71
-
1. Change to the directory in which you cloned the repository.
72
-
2. Invoke the following `kubectl` command to upgrade the [Custom Resource Definitions](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
mongodb://<metadata.name of the MongoDB resource>-svc.<namespace>.svc.cluster.local:27017/?replicaSet=<replicasetname>
96
-
```
97
-
98
-
### Upgrade your MongoDB Resource Version and Feature Compatibility Version
99
-
100
-
You can upgrade the major, minor, and/or feature compatibility versions of your MongoDB resource. These settings are configured in your resource definition YAML file.
101
-
102
-
- To upgrade your resource's major and/or minor versions, set the `spec.version` setting to the desired MongoDB version.
103
-
104
-
- To modify your resource's [feature compatibility version](https://docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/), set the `spec.featureCompatibilityVersion` setting to the desired version.
105
-
106
-
If you update `spec.version` to a later version, consider setting `spec.featureCompatibilityVersion` to the current working MongoDB version to give yourself the option to downgrade if necessary. To learn more about feature compatibility, see [`setFeatureCompatibilityVersion`](https://docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/) in the MongoDB Manual.
107
-
108
-
### Deploying on OpenShift
109
-
110
-
If you want to deploy the operator on OpenShift you will have to provide the environment variable `MANAGED_SECURITY_CONTEXT` set to `true` for both the mongodb and mongodb agent containers, as well as the operator deployment.
111
-
112
-
See [here](deploy/crds/mongodb.com_v1_mongodb_openshift_cr.yaml) for an example of how to provide the required configuration for a MongoDB ReplicaSet.
113
-
114
-
See [here](deploy/openshift/operator_openshift.yaml) for an example of how to configure the Operator deployment.
115
-
116
-
#### Example
117
-
118
-
Consider the following example MongoDB resource definition:
119
-
120
-
```yaml
121
-
apiVersion: mongodb.com/v1
122
-
kind: MongoDB
123
-
metadata:
124
-
name: example-mongodb
125
-
spec:
126
-
members: 3
127
-
type: ReplicaSet
128
-
version: "4.0.6"
129
-
```
130
-
To upgrade this resource from `4.0.6` to `4.2.7`:
131
-
132
-
1. Edit the resource definition.
133
-
134
-
a. Update `spec.version` to `4.2.7`.
135
-
136
-
b. Update `spec.featureCompatibilityVersion` to `4.0`.
137
-
138
-
```yaml
139
-
apiVersion: mongodb.com/v1
140
-
kind: MongoDB
141
-
metadata:
142
-
name: example-mongodb
143
-
spec:
144
-
members: 3
145
-
type: ReplicaSet
146
-
version: "4.2.7"
147
-
featureCompatibilityVersion: "4.0"
148
-
```
149
-
150
-
**NOTE:** Setting `featureCompatibilityVersion` to `4.0` disables [4.2 features incompatible with MongoDB 4.0](https://docs.mongodb.com/manual/release-notes/4.2-compatibility/#compatibility-enabled).
You can configure the MongoDB Community Kubernetes Operator to use TLS certificates to encrypt traffic between:
160
-
161
-
- MongoDB hosts in a replica set, and
162
-
- Client applications and MongoDB deployments.
163
-
164
-
### Prerequisites
165
-
166
-
Before you secure MongoDB resource connections using TLS, you must:
167
-
168
-
1. Create a PEM-encoded TLS certificate for the servers in the MongoDB resource using your own Certificate Authority (CA). The certificate must have one of the following:
169
-
170
-
- A wildcard `Common Name` that matches the domain name of all of the replica set members:
171
-
172
-
```
173
-
*.<metadata.name of the MongoDB resource>-svc.<namespace>.svc.cluster.local
174
-
```
175
-
- The domain name for each of the replica set members as `Subject Alternative Names` (SAN):
176
-
177
-
```
178
-
<metadata.name of the MongoDB resource>-0.<metadata.name of the MongoDB resource>-svc.<namespace>.svc.cluster.local
179
-
<metadata.name of the MongoDB resource>-1.<metadata.name of the MongoDB resource>-svc.<namespace>.svc.cluster.local
180
-
<metadata.name of the MongoDB resource>-2.<metadata.name of the MongoDB resource>-svc.<namespace>.svc.cluster.local
181
-
```
182
-
183
-
1. Create a Kubernetes ConfigMap that contains the certificate for the CA that signed your server certificate. The key in the ConfigMap that references the certificate must be named `ca.crt`. Kubernetes configures this automatically if the certificate file is named `ca.crt`:
1. Create a Kubernetes secret that contains the server certificate and key for the members of your replica set. For a server certificate named `server.crt` and key named `server.key`:
To secure connections to MongoDB resources using TLS:
201
-
202
-
1. Add the following fields to the MongoDB resource definition:
203
-
204
-
- `spec.security.tls.enabled`: Encrypts communications using TLS certificates between MongoDB hosts in a replica set and client applications and MongoDB deployments. Set to `true`.
205
-
- `spec.security.tls.optional`: (**Optional**) Enables the members of the replica set to accept both TLS and non-TLS client connections. Equivalent to setting the MongoDB[`net.tls.mode`](https://docs.mongodb.com/manual/reference/configuration-options/#net.tls.mode) setting to `preferSSL`. If omitted, defaults to `false`.
206
-
207
-
---
208
-
**NOTE**
209
-
210
-
When you enable TLS on an existing replica set deployment:
211
-
212
-
a. Set `spec.security.tls.optional` to `true`.
213
-
214
-
b. Apply the configuration to Kubernetes.
215
-
216
-
c. Upgrade your existing clients to use TLS.
217
-
218
-
d. Remove the `spec.security.tls.optional` field.
219
-
220
-
e. Complete the remaining steps in the procedure.
221
-
222
-
---
223
-
- `spec.security.tls.certificateKeySecretRef.name`: Name of the Kubernetes secret that contains the server certificate and key that you created in the [prerequisites](#prerequisites-1).
224
-
- `spec.security.tls.caConfigMapRef.name`: Name of the Kubernetes ConfigMap that contains the Certificate Authority certificate used to sign the server certificate that you created in the [prerequisites](#prerequisites-1).
mongodb://<metadata.name of the MongoDB resource>-svc.<namespace>.svc.cluster.local:27017/?replicaSet=<replica set name>
26
+
```
27
+
28
+
## Upgrade your MongoDB Resource Version and Feature Compatibility Version
29
+
30
+
You can upgrade the major, minor, and/or feature compatibility versions of your MongoDB resource. These settings are configured in your resource definition YAML file.
31
+
32
+
- To upgrade your resource's major and/or minor versions, set the `spec.version` setting to the desired MongoDB version.
33
+
34
+
- To modify your resource's [feature compatibility version](https://docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/), set the `spec.featureCompatibilityVersion` setting to the desired version.
35
+
36
+
If you update `spec.version` to a later version, consider setting `spec.featureCompatibilityVersion` to the current working MongoDB version to give yourself the option to downgrade if necessary. To learn more about feature compatibility, see [`setFeatureCompatibilityVersion`](https://docs.mongodb.com/manual/reference/command/setFeatureCompatibilityVersion/) in the MongoDB Manual.
37
+
38
+
## Deploying on OpenShift
39
+
40
+
If you want to deploy the operator on OpenShift you will have to provide the environment variable `MANAGED_SECURITY_CONTEXT` set to `true` for both the mongodb and mongodb agent containers, as well as the operator deployment.
41
+
42
+
See [here](deploy/crds/mongodb.com_v1_mongodb_openshift_cr.yaml) for an example of how to provide the required configuration for a MongoDB ReplicaSet.
43
+
44
+
See [here](deploy/operator_openshift.yaml) for an example of how to configure the Operator deployment.
45
+
46
+
### Example
47
+
48
+
Consider the following example MongoDB resource definition:
49
+
50
+
```yaml
51
+
apiVersion: mongodb.com/v1
52
+
kind: MongoDB
53
+
metadata:
54
+
name: example-mongodb
55
+
spec:
56
+
members: 3
57
+
type: ReplicaSet
58
+
version: "4.0.6"
59
+
```
60
+
To upgrade this resource from `4.0.6` to `4.2.7`:
61
+
62
+
1. Edit the resource definition.
63
+
64
+
a. Update `spec.version` to `4.2.7`.
65
+
66
+
b. Update `spec.featureCompatibilityVersion` to `4.0`.
67
+
68
+
```yaml
69
+
apiVersion: mongodb.com/v1
70
+
kind: MongoDB
71
+
metadata:
72
+
name: example-mongodb
73
+
spec:
74
+
members: 3
75
+
type: ReplicaSet
76
+
version: "4.2.7"
77
+
featureCompatibilityVersion: "4.0"
78
+
```
79
+
80
+
**NOTE:** Setting `featureCompatibilityVersion` to `4.0` disables [4.2 features incompatible with MongoDB 4.0](https://docs.mongodb.com/manual/release-notes/4.2-compatibility/#compatibility-enabled).
0 commit comments