Closed emmanuelm41 closed 3 years ago
Hi, I was able to reproduce the issue, and tried to fix it with the changes you are proposing; although the variable is now properly set, the data pods are not up and running. Those are the changes:
@ bitnami/mongodb-sharded/templates/shard/shard-data-statefulset.yaml:121 @ spec:
fieldRef:
fieldPath: metadata.name
- name: MONGODB_MONGOS_HOST
- value: {{ include "common.names.fullname" $ }}
+ value: {{ include "mongodb-sharded.serviceName" $ }}
- name: MONGODB_INITIAL_PRIMARY_HOST
value: {{ printf "%s-shard%d-data-0.%s-headless.%s.svc.%s" (include "common.names.fullname" $ ) $i (include "common.names.fullname" $ ) $.Release.Namespace $.Values.clusterDomain }}
- name: MONGODB_REPLICA_SET_NAME
@ bitnami/mongodb-sharded/values.yaml:786 @ mongos:
schedulerName:
## Use StatefulSet instead of Deployment
##
- useStatefulSet: false
+ useStatefulSet: true
## When using a statefulset, you can enable one service per replica
## This is useful when exposing the mongos through load balancers to make sure clients
## connect to the same mongos and therefore can follow their cursors
@ bitnami/mongodb-sharded/values.yaml:989 @ clusterDomain: cluster.local
service:
## Specify an explicit service name
##
- name:
+ name: my-new-service
## Additional service annotations (evaluate as a template)
## ref: https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
##
@ bitnami/mongodb-sharded/values.yaml:997 @ service:
## Service type
## ref: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
##
- type: ClusterIP
+ type: LoadBalancer
## External traffic policy
## ref: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types
##
And this is how it is rendered:
$ helm template mongo --set service.name=my-new-service . | grep 'MONGODB_MONGO' -C 4
zsh: correct 'template' to 'templates' [nyae]? n
- name: MONGODB_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MONGODB_MONGOS_HOST
value: my-new-service
- name: MONGODB_INITIAL_PRIMARY_HOST
value: mongo-mongodb-sharded-shard0-data-0.mongo-mongodb-sharded-headless.default.svc.cluster.local
- name: MONGODB_REPLICA_SET_NAME
--
- name: MONGODB_POD_NAME
valueFrom:
fieldRef:
fieldPath: metadata.name
- name: MONGODB_MONGOS_HOST
value: my-new-service
- name: MONGODB_INITIAL_PRIMARY_HOST
value: mongo-mongodb-sharded-shard1-data-0.mongo-mongodb-sharded-headless.default.svc.cluster.local
- name: MONGODB_REPLICA_SET_NAME
But when installing the chart, although the env. var. is properly set, the issue is still there:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongo-mongodb-sharded-configsvr-0 1/1 Running 0 22m
mongo-mongodb-sharded-mongos-0 1/1 Running 0 22m
mongo-mongodb-sharded-shard0-data-0 0/1 Running 8 22m
mongo-mongodb-sharded-shard1-data-0 0/1 Running 8 22m
$ kubectl logs -f mongo-mongodb-sharded-shard1-data-0
09:25:09.54 INFO ==> Setting node as primary
mongodb 09:25:09.57
mongodb 09:25:09.58 Welcome to the Bitnami mongodb-sharded container
mongodb 09:25:09.58 Subscribe to project updates by watching https://github.com/bitnami/bitnami-docker-mongodb-sharded
mongodb 09:25:09.58 Submit issues and feature requests at https://github.com/bitnami/bitnami-docker-mongodb-sharded/issues
mongodb 09:25:09.58
mongodb 09:25:09.58 INFO ==> ** Starting MongoDB Sharded setup **
mongodb 09:25:09.61 INFO ==> Validating settings in MONGODB_* env vars...
mongodb 09:25:09.63 INFO ==> Initializing MongoDB Sharded...
mongodb 09:25:09.65 INFO ==> Writing keyfile for replica set authentication...
mongodb 09:25:09.66 INFO ==> Enabling authentication...
mongodb 09:25:09.67 INFO ==> Deploying MongoDB Sharded with persisted data...
mongodb 09:25:09.68 INFO ==> Trying to connect to MongoDB server my-service-name...
cannot resolve host "my-new-service": lookup my-new-service on 10.30.240.10:53: no such host
cannot resolve host "my-new-service": lookup my-new-service on 10.30.240.10:53: no such host
cannot resolve host "my-new-service": lookup my-new-service on 10.30.240.10:53: no such host
cannot resolve host "my-new-service": lookup my-new-service on 10.30.240.10:53: no such host
It should be something else, I will continue taking a look. If you are able to find any clue on your side we'll be happy to review any PR/contribution. Thanks!
Thanks for your quick answer. The way I fixed it was using the fullname as the value on shardsvr.service.name
. I took the value the chart generated as fullname, and set it as service name. In that way, everything worked.
In your examlple, I should have worked! Could you check if the LoadBalancer service is up? It is not necessary to use a LoadBalancer, it could be a ClusterIP too. You need a service provider in order to set a LoadBalancer. I am not sure where you did the test. I did it on a cloud service provider.
Yep, you're totally right. I was testing it on a shared cluster and I thought it was configured in a different way.
Everything is up and running with the above change:
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
mongo3-mongodb-sharded-configsvr-0 1/1 Running 0 22m
mongo3-mongodb-sharded-mongos-0 1/1 Running 0 22m
mongo3-mongodb-sharded-shard0-data-0 1/1 Running 0 22m
mongo3-mongodb-sharded-shard1-data-0 1/1 Running 0 22m
I just created a PR (see below) addressing this issue.
Which chart: mongodb-sharded v3.7.0
Describe the bug When I deployed this chart in a Kubernetes cluster, mongos and configsrv were successfully initialized, but the shared-data-X were not. They fail with the legend "cannot resolve pre-prod-mongodb-service: no such host". The sharded-data look for mongos instance with the env variable MONGODB_MONGOS_HOST, but this variable is set to common.names.fullname and not to mongodb-sharded.serviceName.
To Reproduce Steps to reproduce the behavior:
The namespace this chart will be installed to,
if not specified the chart will be installed to "default"
namespace: dev
Custom helm options
helm:
The directory of the chart in the repo. Also any valid go-getter supported
URL can be used there is specify where to download the chart from.
If repo below is set this value if the chart name in the repo
chart: "mongodb-sharded"
An https to a valid Helm repository to download the chart from
repo: "https://charts.bitnami.com/bitnami"
Used if repo is set to look up the version of the chart
version: "3.7.0"
Force recreate resource that can not be updated
force: false
How long for helm to wait for the release to be active. If the value
is less that or equal to zero, we will not wait in Helm
timeoutSeconds: 600
Custom values that will be passed as values.yaml to the installation
Global Docker image parameters
Please, note that this will override the image parameters, including dependencies, configured to use the global value
Current available global Docker image parameters: imageRegistry, imagePullSecrets and storageClass
global:
imageRegistry: myRegistryName
imagePullSecrets:
- myRegistryKeySecretName
storageClass: myStorageClass
Bitnami MongoDB(R) Sharded image version
ref: https://hub.docker.com/r/bitnami/mongodb-sharded/tags/
values:
MongoDB(R) credentials
version.BuildInfo{Version:"v3.3.3-rancher3", GitCommit:"657df59bbba1d9e175cf5080d4885bd57d037906", GitTreeState:"clean", GoVersion:"go1.13.15"}
Client Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.7", GitCommit:"1dd5338295409edcfff11505e7bb246f0d325d15", GitTreeState:"clean", BuildDate:"2021-01-13T13:23:52Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.6", GitCommit:"8a62859e515889f07e3e3be6a1080413f17cf2c3", GitTreeState:"clean", BuildDate:"2021-04-15T03:19:55Z", GoVersion:"go1.15.10", Compiler:"gc", Platform:"linux/amd64"}