【发布时间】:2019-10-11 00:47:02
【问题描述】:
我创建了一个 nodejs 应用程序并尝试将其与 kubernetes 集群上的 mongodb 连接。 nodejs 和 mongodb 应用程序是我集群中的独立 pod。
当我显示状态时,mongodb 和应用程序正在运行,我可以将我连接到 mongodb pod 并添加数据
NAME READY STATUS RESTARTS AGE
my-backend-core-test-5d7b78c9dc-dt4bg 1/1 Running 0 31m
my-frontend-test-6868f7c7dd-b2qtm 1/1 Running 0 40h
my-mongodb-test-7d55dbff74-2m6cm 1/1 Running 0 34m
但是当我尝试与这个脚本建立连接时:
const urlDB = "my-mongodb-service-test.my-test.svc.cluster.local:27017";
console.log("urlDB :: ", urlDB);
mongoose.connect('mongodb://'+urlDB+'/test', { useNewUrlParser: true }).then(() => {
console.log("DB connected")
}).catch((err)=> {
console.log("ERROR")
})
我的 nodejs 应用程序出现以下错误:
> my-core@1.0.0 start /usr/src/app
> node ./src/app.js
urlDB :: my-mongodb-service-test.my-test.svc.cluster.local:27017
ERROR
正如在 kubernetes 上解释的那样,我假设使用 service-name.namespace.svc.cluster.local (my-mongodb-service-test.my-test.svc.cluster.local:27017) 在不同的 pod 之间进行通信
mongo 日志显示了一个不同的主机,对应于我的 pod 而不是服务。如何在我的 yaml 文件中配置主机?
mongodb 日志:
2019-05-24T10:57:02.367+0000 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-05-24T10:57:02.374+0000 I CONTROL [initandlisten] MongoDB starting : pid=1 port=27017 dbpath=/data/db 64-bit host=my-mongodb-test-7d55dbff74-2m6cm
2019-05-24T10:57:02.374+0000 I CONTROL [initandlisten] db version v4.0.9
2019-05-24T10:57:02.374+0000 I CONTROL [initandlisten] git version: fc525e2d9b0e4bceff5c2201457e564362909765
2019-05-24T10:57:02.374+0000 I CONTROL [initandlisten] OpenSSL version: OpenSSL 1.0.2g 1 Mar 2016
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] allocator: tcmalloc
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] modules: none
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] build environment:
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] distmod: ubuntu1604
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] distarch: x86_64
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] target_arch: x86_64
2019-05-24T10:57:02.375+0000 I CONTROL [initandlisten] options: { net: { bindIp: "0.0.0.0" } }
2019-05-24T10:57:02.376+0000 I STORAGE [initandlisten] Detected data files in /data/db created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wiredTiger'.
2019-05-24T10:57:02.377+0000 I STORAGE [initandlisten]
2019-05-24T10:57:02.377+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine
2019-05-24T10:57:02.377+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem
2019-05-24T10:57:02.377+0000 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=485M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,statistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2019-05-24T10:57:03.521+0000 I STORAGE [initandlisten] WiredTiger message [1558695423:521941][1:0x7f2d2eeb0a80], txn-recover: Main recovery loop: starting at 2/140416 to 3/256
2019-05-24T10:57:03.719+0000 I STORAGE [initandlisten] WiredTiger message [1558695423:719280][1:0x7f2d2eeb0a80], txn-recover: Recovering log 2 through 3
2019-05-24T10:57:03.836+0000 I STORAGE [initandlisten] WiredTiger message [1558695423:836203][1:0x7f2d2eeb0a80], txn-recover: Recovering log 3 through 3
2019-05-24T10:57:03.896+0000 I STORAGE [initandlisten] WiredTiger message [1558695423:896185][1:0x7f2d2eeb0a80], txn-recover: Set global recovery timestamp: 0
2019-05-24T10:57:03.924+0000 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten]
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten] ** WARNING: You are running this process as the root user, which is not recommended.
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten]
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten]
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'
2019-05-24T10:57:03.947+0000 I CONTROL [initandlisten]
2019-05-24T10:57:03.984+0000 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory '/data/db/diagnostic.data'
2019-05-24T10:57:03.986+0000 I NETWORK [initandlisten] waiting for connections on port 27017
mongodb yaml
apiVersion: v1
kind: Service
metadata:
name: my-mongodb-service-test
namespace: my-test
spec:
selector:
app: my-mongodb
env: test
ports:
- port: 27017
targetPort: 27017
protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-mongodb-test
namespace: my-test
labels:
app: my-mongodb
env: test
spec:
selector:
matchLabels:
app: my-mongodb-test
replicas: 1
template:
metadata:
labels:
app: my-mongodb-test
spec:
containers:
- name: mongo
image: mongo:4.0.9
command:
- mongod
- "--bind_ip"
- "0.0.0.0"
imagePullPolicy: Always
ports:
- containerPort: 27017
name: mongo
hostPort: 27017
protocol: TCP
volumeMounts:
- mountPath: /data/db
name: mongodb-volume
volumes:
- name: mongodb-volume
hostPath:
path: /home/debian/mongodb
【问题讨论】:
-
你试过用这个作为 URL = "my-mongodb-service-test:27017";
-
还在mongo服务的元数据中添加标签:标签:app:my-mongodb-service-test
-
能否请您打印堆栈跟踪而不是“错误”?它会提供更多关于这个问题的想法。
-
No my-mongodb-service-test:27017 不起作用,我在发布之前尝试了很多解决方案。我的问题的 2 种可能性 mongodb 的配置由于错误的主机名而阻止连接,请参阅日志。我不知道如何在 kubernetes 上进行配置。其次,我的 pod mongo 无法从 nodejs pod 访问,如何检查我不知道我只是在 kubernetes 上启动
-
关于堆栈跟踪它只是 err => true :( 奇怪
标签: node.js mongodb kubernetes database-connection