Skip to content

Commit f79c8ee

Browse files
(DOCSP-19468): two 1.13 known issues (#767)
1 parent 376db4e commit f79c8ee

File tree

1 file changed

+98
-0
lines changed

1 file changed

+98
-0
lines changed

source/reference/known-issues.txt

Lines changed: 98 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -10,6 +10,104 @@ Known Issues in the |k8s-op-full|
1010
:depth: 1
1111
:class: singlecol
1212

13+
.. _disable_auth_pods_never_reconcile:
14+
15+
``mongos`` Instances Fail to Reach Ready State After Disabling Authentication
16+
-----------------------------------------------------------------------------
17+
18+
.. note::
19+
20+
This issue applies only to :term:`sharded clusters <sharded cluster>`
21+
that meet the following criteria:
22+
23+
- Deployed using the |k8s-op-short| 1.13.0
24+
- Use X.509 authentication
25+
- Use :k8sdocs:`kubernetes.io/tls
26+
</concepts/configuration/secret/#tls-secrets>` secrets for |tls|
27+
certificates for the MongoDB Agent
28+
29+
If you disable authentication by setting
30+
:setting:`spec.security.auth.enabled` to ``false``, the |mongos| Pods
31+
never reach a ``ready`` state.
32+
33+
As a workaround, delete each |mongos| Pod in your deployment.
34+
35+
Run the following command to list all of your Pods:
36+
37+
.. code-block:: sh
38+
39+
kubectl get pods
40+
41+
For each Pod with a name that contains ``mongos``, delete it with the
42+
following command:
43+
44+
.. code-block:: sh
45+
46+
kubectl delete pod <podname>
47+
48+
When you delete a Pod, Kubernetes recreates it. Each Pod that Kubernetes
49+
recreates receives the updated configuration and can reach a ``READY``
50+
state. To confirm that all of your |mongos| Pods are ``READY``, run the
51+
following command:
52+
53+
.. code-block:: sh
54+
55+
kubectl get pods -n <namespace>
56+
57+
A response like the following indicates that all of your |mongos| Pods
58+
are ``READY``:
59+
60+
.. code-block:: sh
61+
:copyable: false
62+
:emphasize-lines: 7-8
63+
64+
NAME READY STATUS RESTARTS AGE
65+
mongodb-enterprise-operator-6495bdd947-ttwqf 1/1 Running 0 50m
66+
my-sharded-cluster-0-0 1/1 Running 0 12m
67+
my-sharded-cluster-1-0 1/1 Running 0 12m
68+
my-sharded-cluster-config-0 1/1 Running 0 12m
69+
my-sharded-cluster-config-1 1/1 Running 0 12m
70+
my-sharded-cluster-mongos-0 1/1 Running 0 11m
71+
my-sharded-cluster-mongos-1 1/1 Running 0 11m
72+
om-0 1/1 Running 0 42m
73+
om-db-0 2/2 Running 0 44m
74+
om-db-1 2/2 Running 0 43m
75+
om-db-2 2/2 Running 0 43m
76+
77+
.. _app-db-secret-no-reconcile:
78+
79+
Update |tls| Secret for the Application Database
80+
------------------------------------------------
81+
82+
.. note::
83+
84+
This issue applies only to |onprem| resources deployed using the
85+
|k8s-op-short| 1.13.0.
86+
87+
The |k8s-op-short| doesn't reconcile resources when you modify the
88+
secret that contains the Application Database's |tls| certificate.
89+
To force the |k8s-op-short| to reconcile resources, scale the operator
90+
down to zero replicas, then scale it up to one.
91+
92+
.. note::
93+
94+
This is a safe operation. Scaling the
95+
``mongodb-enterprise-operator`` deployment does not affect the
96+
availability of your deployed |onprem| and database resources.
97+
98+
Run the following command to scale down:
99+
100+
.. code-block:: sh
101+
102+
kubectl scale deployment mongodb-enterprise-operator --replicas=0 -n <namespace>
103+
104+
Run the following command to scale up:
105+
106+
.. code-block:: sh
107+
108+
kubectl scale deployment mongodb-enterprise-operator --replicas=1 -n <namespace>
109+
110+
13111
.. _k8s-private-cluster-on-gke:
14112

15113
Update Google Firewall Rules to Fix WebHook Issues

0 commit comments

Comments
 (0)