当前位置: 首页 > 知识库问答 >
问题:

库伯内特斯如何为MongoDb传递连接字符串?

庄元龙
2023-03-14

这是我的appsettings.json

{
  "ConnectionStrings": {
    "PackingService": "mongodb://127.0.0.1:27017/test"
  },
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
    }
  },
  "AllowedHosts": "*"
}

这是我的应用部署

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: test
  name: test
spec:
  selector:
    matchLabels:
      app: test
  strategy: {}
  template:
    metadata:
      labels:
        io.kompose.network/dbnet: "true"
        app: test
    spec:
      containers:
      - env:
        - name: ConnectionStrings
          value: mongodb://localhost/test
        - name: MONGO_PORT
          valueFrom:
            configMapKeyRef:
              key: MONGO_PORT
              name: env
        - name: NODE_ENV
          value: development
        image: mlrd/smartboxes
        imagePullPolicy: ""
        name: test-api
        ports:
        - containerPort: 80
        resources: {}
      restartPolicy: Always
      serviceAccountName: ""
      volumes: null
status: {}

这是我为Mongob服务

apiVersion: v1
kind: Service
metadata:
  name: mongodb
  labels:
    app: mongodb
spec:
  ports:
    - port: 27017
  selector:
    app: mongodb

当我想连接到数据库时,这不起作用,抛出一个错误超时,什么是发送连接字符串到应用程序的正确方法。yaml文件?我应该设置aspnetcore环境变量吗?我应该换些什么吗?json配置文件?抱歉缺乏知识

共有2个答案

吕霖
2023-03-14

在您的情况下,MongoDB是使用部署创建的,并且您正在使用服务公开它。

在您的服务中,您不需要声明类型。这使我认为您正在尝试使用ClusterIP服务类型从Kubernetes内部连接到MongoDB。

在显示的 appsettings.json 中,在连接字符串中引用 127.0.0.1。您可能知道,这是读取文件的本地服务器的名称对象。

在您的情况下,您的客户机服务器将与MongoDB分开。这意味着您的连接尝试不是指向< code>127.0.0.1,而是指向您的Kubernetes服务资源的名称。在这种情况下,< code>mongodb。

这里还有两点需要考虑。

1) 如果发起请求的客户端服务器位于另一个Kubernetes命名空间中,则需要配置连接字符串以正确引用Kubernets上使用的FQDN。

根据上面的配置,这可能看起来像:mongodb.default.svc.cluster.local

2)如果您的客户端服务器在您的集群外部。例如,您的笔记本电脑或开发服务器。然后您需要将您的服务类型从ClusterIP修改为加载LoadBalorer的内容。或者使用入口来公开它。

我希望这个答案能帮助你解决你的问题。如果您需要任何进一步的澄清或信息,请随时提问!

周正真
2023-03-14

由于mongodb是作为一个单独的pod部署的,并且由一个服务公开,因此您不能使用localhost127.0.0.1如果您在与应用程序相同的命名空间中创建了mongodb服务,那么您应该使用mongodb.svc.cluster.local。如果mongodb服务在不同的命名空间中,请使用<code>mongodb.namespacename.svc.cluster.local</code>

 类似资料:
  • 我正在分布式模式下使用 cp-kafka-connect Helm chart 在 Google Kubernetes Engine (GKE) 上部署 Kafka-connect。 一个工作的Kafka集群与代理和动物园管理员已经在同一个GKE集群上运行。我知道我可以通过发送帖子请求到endpoint来创建连接器,一旦它可用。但是,Kafka连接容器进入运行状态,然后开始加载jar文件,直到所有

  • 我怎样才能使用入口呢?我尝试使用NodePort和--Target etPort=1001,我在servicePort中添加了80在。 kubectl公开部署测试--Target-port=1001--type=NodePort 我得到了错误 找不到后端-404 我使用的是正确的方法还是需要遵循其他方法?

  • 我假设没有愚蠢的问题,所以这里有一个我找不到直接答案的问题。 现在的情况 我目前有一个运行1.15的Kubernetes集群。AKS上的x,通过Terraform部署和管理。AKS最近宣布Azure将在AKS上停用Kubernetes的1.15版本,我需要将集群升级到1.16或更高版本。现在,据我所知,直接在Azure中升级集群不会对集群的内容产生任何影响,即节点、豆荚、秘密和当前在那里的所有其他

  • 我按照https://docs.atlas.mongodb.com/security-vpc-peering/创建了VPC对等互连并检查了激活的双方(GCP和Atlas)。我的GCP VPC本机已启用。 MongoDB cidr192.168.0.0/16 GCP pod ip10.4.0.0/16 我将10.4.0.0/16添加到Atlas白名单中,并尝试通过其中一个POD中的专用连接字符串进行

  • 我在Kubernetes是个新手。我想知道在kubernetes环境中最好的生产部署场景是什么。 在过去的学派中,我习惯于将Web服务器(例如Nginx或Apache)放在DMZ层,而将其放在其他层(我们称之为层)。这样,只有web服务器在DMZ上,恶意攻击只能在web服务器VM上进行。 据我所知,K8S部署不再需要这种方法;这是因为K8S自己处理网络、吊舱和流量。所以我在考虑最确定的部署方案。

  • 据我所知,作业对象应该在一定时间后收获豆荚。但是在我的GKE集群(库伯内特斯1.1.8)上,“kubectl get pods-a”似乎可以列出几天前的豆荚。 所有这些都是使用乔布斯API创建的。 我确实注意到在使用 kubectl 删除作业后,pod 也被删除了。 我在这里主要担心的是,我将在批量作业中在集群上运行成千上万个pod,并且不想让内部待办系统过载。