小编Ada*_*ris的帖子

我公司已经运行Kuberenetes一年多了,GitLab运行了大约6个月.我们最近升级到GitLab 9.x,并且无法通过Kube了解CI + app配置的决定.这个功能很棒,很想让它在我们的环境中工作.

似乎GitLab希望您只有一个集群设置,其中一个集群内的所有环境都被命名空间分解,这将等同于您的服务/应用程序和应用程序,这将等同于您的环境.这就是GitLab希望我的Kuberenetes环境看起来像一个单独的集群,您的服务被分解为命名空间:

namespace = hello-world
app = development
app = qa
app = production

在现实世界的例子中,我们更倾向于使用与单个集群相同的相反方案

DEVELOPMENT CLUSTER
namespace = development
app = hello-world

QA CLUSTER
namespace = qa
app = hello-world

PRODUCTION CLUSTER
namespace = production
app = hello-world

将命名空间作为应用程序并将应用程序作为环境,我们将无法升级到最新版本的kube而无需升级所有内容.也许我错过了一些东西,但是基于我正在阅读的东西,经过测试后,它看起来就像它的设计方式.

作为参考,这是我的CI现在看起来像是使部署板+终端满意

development:
    <<: *deploy_definition
    stage: development
    environment: hello-world
    script:
        deploy.sh -a "hello-world"

但它应该是这样的

development:
    <<: *deploy_definition
    stage: development
    environment: development
    script:
        deploy.sh -a "hello-world"

为了增加这种混淆,它们只为您提供了一个Kubernetes master来连接到集成选项卡.

这是正确的,还是我错过了什么？