|
| 1 | +--- |
| 2 | +title: "Managing Domain Namespaces" |
| 3 | +date: 2019-09-19T10:41:32-05:00 |
| 4 | +draft: false |
| 5 | +--- |
| 6 | + |
| 7 | +Each WebLogic operator deployment manages a number of Kubernetes namespaces (for information about setting domain namespaces, see [Operator Helm configuration values]({{<relref "/userguide/managing-operators/using-the-operator/using-helm.md#operator-helm-configuration-values">}})). A number of Kubernetes resources |
| 8 | +must be present in a namespace before any WebLogic domain custom resources can be successfully |
| 9 | +deployed into it. |
| 10 | +Those Kubernetes resources are created either as part of the installation |
| 11 | +of the operator's Helm chart, or created by the operator at runtime. |
| 12 | + |
| 13 | +This FAQ describes some considerations to be aware of when you manage the namespaces while the WebLogic operator is running. For example: |
| 14 | + |
| 15 | +* [Check the namespaces that an operator manages](#checking-the-namespaces-that-an-operator-manages) |
| 16 | +* [Add a namespace for an operator to manage](#adding-a-kubernetes-namespace-to-an-operator) |
| 17 | +* [Delete a namespace from an operator's domain namespace list](#deleting-a-kubernetes-namespace-from-an-operator) |
| 18 | +* [Delete and recreate a Kubernetes namespace that an operator manages](#recreating-a-previously-deleted-kubernetes-namespace) |
| 19 | + |
| 20 | +For others, see [Common Mistakes and Solutions]({{<relref "/userguide/managing-operators/using-the-operator/using-helm.md#common-mistakes-and-solutions">}}). |
| 21 | + |
| 22 | +#### Checking the namespaces that an operator manages |
| 23 | +You can find the list of the namespaces that an operator manages using the `helm get values` command. |
| 24 | +For example, the following command shows all the values of the operator release `weblogic-operator`; the `domainNamespaces` list contains `default` and `ns1`. |
| 25 | + |
| 26 | +``` |
| 27 | +$ helm get values weblogic-operator |
| 28 | +domainNamespaces: |
| 29 | +- default |
| 30 | +- ns1 |
| 31 | +elasticSearchHost: elasticsearch.default.svc.cluster.local |
| 32 | +elasticSearchPort: 9200 |
| 33 | +elkIntegrationEnabled: false |
| 34 | +externalDebugHttpPort: 30999 |
| 35 | +externalRestEnabled: false |
| 36 | +externalRestHttpsPort: 31001 |
| 37 | +image: oracle/weblogic-kubernetes-operator:2.3.1 |
| 38 | +imagePullPolicy: IfNotPresent |
| 39 | +internalDebugHttpPort: 30999 |
| 40 | +istioEnabled: false |
| 41 | +javaLoggingLevel: INFO |
| 42 | +logStashImage: logstash:6.6.0 |
| 43 | +remoteDebugNodePortEnabled: false |
| 44 | +serviceAccount: default |
| 45 | +suspendOnDebugStartup: false |
| 46 | +
|
| 47 | +``` |
| 48 | + |
| 49 | +If you don't know the release name of the operator, you can use `helm ls` to list all the releases. |
| 50 | + |
| 51 | +#### Adding a Kubernetes namespace to an operator |
| 52 | +If you want a WebLogic operator deployment to manage a namespace, you need to add the namespace to the operator's `domainNamespaces` list. Note that the namespace has to be precreated, for example, using the `kubectl create` command. |
| 53 | + |
| 54 | +Adding a namespace to the `domainNamespaces` list tells the operator deployment or runtime |
| 55 | +to initialize the necessary Kubernetes resources for the namespace so that the operator is ready to host WebLogic domain resources in that namespace. |
| 56 | + |
| 57 | +When the operator is running and managing the `default` namespace, the following example Helm command adds the namespace `ns1` to the `domainNamespaces` list, where `weblogic-operator` is the release name of the operator, and `kubernetes/charts/weblogic-operator` is the location of the operator's Helm charts. |
| 58 | + |
| 59 | +``` |
| 60 | +$ helm upgrade \ |
| 61 | + --reuse-values \ |
| 62 | + --set "domainNamespaces={default,ns1}" \ |
| 63 | + --wait \ |
| 64 | + --force \ |
| 65 | + weblogic-operator \ |
| 66 | + kubernetes/charts/weblogic-operator |
| 67 | +``` |
| 68 | + |
| 69 | +{{% notice note %}} |
| 70 | +Changes to the `domainNamespaces` list might not be picked up by the operator right away because the operator |
| 71 | +monitors the changes to the setting periodically. The operator becomes ready to host domain resources in |
| 72 | +a namespace only after the required `configmap` (namely `weblogic-domain-cm`) is initialized in the namespace. |
| 73 | +{{% /notice %}} |
| 74 | + |
| 75 | +You can verify that the operator is ready to host domain resources in a namespace by confirming the existence of the required `configmap` resource. |
| 76 | + |
| 77 | +``` |
| 78 | +$ kubetctl get cm -n <namespace> |
| 79 | +``` |
| 80 | + |
| 81 | +For example, the following example shows that the domain `configmap` resource exists in the namespace `ns1`. |
| 82 | + |
| 83 | +``` |
| 84 | +bash-4.2$ kubectl get cm -n ns1 |
| 85 | +
|
| 86 | +NAME DATA AGE |
| 87 | +
|
| 88 | +weblogic-domain-cm 14 12m |
| 89 | +``` |
| 90 | + |
| 91 | +#### Deleting a Kubernetes namespace from an operator |
| 92 | +When you no longer want a namespace to be managed by an operator, you need to remove it from |
| 93 | +the operator's `domainNamespaces` list, so that the corresponding Kubernetes resources that are |
| 94 | +associated with the namespace can be cleaned up. |
| 95 | + |
| 96 | +While the operator is running and managing the `default` and `ns1` namespaces, the following example Helm |
| 97 | +command removes the namespace `ns1` from the `domainNamespaces` list, where `weblogic-operator` is the release |
| 98 | +name of the operator, and `kubernetes/charts/weblogic-operator` is the location of the operator Helm charts. |
| 99 | + |
| 100 | +``` |
| 101 | +$ helm upgrade \ |
| 102 | + --reuse-values \ |
| 103 | + --set "domainNamespaces={default}" \ |
| 104 | + --wait \ |
| 105 | + --force \ |
| 106 | + weblogic-operator \ |
| 107 | + kubernetes/charts/weblogic-operator |
| 108 | +
|
| 109 | +``` |
| 110 | + |
| 111 | +#### Recreating a previously deleted Kubernetes namespace |
| 112 | + |
| 113 | +If you need to delete a namespace (and the resources in it) and then recreate it, |
| 114 | +remember to remove the namespace from the operator's `domainNamespaces` list |
| 115 | +after you delete the namespace, and add it back to the `domainNamespaces` list after you recreate the namespace |
| 116 | +using the `helm upgrade` commands that were illustrated previously. |
| 117 | + |
| 118 | +{{% notice note %}} |
| 119 | +Make sure that you wait a sufficient period of time between deleting and recreating the |
| 120 | +namespace because it takes time for the resources in a namespace to go away after the namespace is deleted. |
| 121 | +In addition, as mentioned above, changes to the `domainNamespaces` setting is monitored by the operator |
| 122 | +periodically, and the operator becomes ready to host domain resources only after the required domain |
| 123 | +`configmap` (namely `weblogic-domain-cm`) is initialized in the namespace. |
| 124 | +{{% /notice %}} |
| 125 | + |
| 126 | +If a domain custom resource is created before the namespace is ready, you might see that the introspector job pod |
| 127 | +fails to start, with a warning like the following, when you review the description of the introspector pod. |
| 128 | +Note that `domain1` is the name of the domain in the following example output. |
| 129 | + |
| 130 | +``` |
| 131 | +Events: |
| 132 | + Type Reason Age From Message |
| 133 | + ---- ------ ---- ---- ------- |
| 134 | + Normal Scheduled 1m default-scheduler Successfully assigned domain1-introspect-domain-job-bz6rw to slc16ffk |
| 135 | +
|
| 136 | + Normal SuccessfulMountVolume 1m kubelet, slc16ffk MountVolume.SetUp succeeded for volume "weblogic-credentials-volume" |
| 137 | +
|
| 138 | + Normal SuccessfulMountVolume 1m kubelet, slc16ffk MountVolume.SetUp succeeded for volume "default-token-jzblm" |
| 139 | +
|
| 140 | + Warning FailedMount 27s (x8 over 1m) kubelet, slc16ffk MountVolume.SetUp failed for volume "weblogic-domain-cm-volume" : configmaps "weblogic-domain-cm" not found |
| 141 | +
|
| 142 | +``` |
| 143 | + |
| 144 | +If you still run into problems after you perform the `helm upgrade` to re-initialize a namespace |
| 145 | +that is deleted and recreated, you can restart the operator pod as shown |
| 146 | +in the following examples, where the operator itself is running in the |
| 147 | +namespace `weblogic-operator-namespace` with a release name of `weblogic-operator`. |
| 148 | + |
| 149 | +* Kill the operator pod, and let Kubernetes restart it. |
| 150 | + |
| 151 | +``` |
| 152 | +$ kubectl delete pod/weblogic-operator-65b95bc5b5-jw4hh -n weblogic-operator-namespace |
| 153 | +``` |
| 154 | + |
| 155 | +* Scale the operator deployment to `0` and then back to `1` by changing the value of the `replicas`. |
| 156 | + |
| 157 | +``` |
| 158 | +$ kubectl scale deployment.apps/weblogic-operator -n weblogic-operator-namespace --replicas=0 |
| 159 | +``` |
| 160 | + |
| 161 | +``` |
| 162 | +$ kubectl scale deployment.apps/weblogic-operator -n weblogic-operator-namespace --replicas=1 |
| 163 | +``` |
| 164 | + |
| 165 | +Note that restarting an operator pod makes the operator temporarily unavailable for managing its namespaces. |
| 166 | +For example, a domain that is created while the operator is restarting will not be started until the |
| 167 | +operator pod is fully up again. |
0 commit comments