web-dev-qa-db-ja.com

Kubernetesの動的ワイルドカードサブドメイン上り

現在、GKEでKubernetesを使用して、Ingressリソースでさまざまなサブドメインの製品のさまざまな部分にサービスを提供しています。例えば： api.mydomain.com、console.mydomain.comなど.

ingress.yml（current）：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
spec:
  rules:
  - Host: api.mydomain.com
    http:
      paths:
        - backend:
            serviceName: api-service
            servicePort: 80
  - Host: console.mydomain.com
    http:
      paths:
        - backend:
            serviceName: console-service
            servicePort: 80

L7 GCEロードバランサーが適切な場所にルーティングされることで、これは素晴らしい働きをします。しかし、私がやりたいのは、本番環境に移行する前に、新機能をテストして実証するために、サブドメインとして多くの機能ブランチ展開を展開することです。これらはnew-stylesheet.console.mydomain.comまたはupgraded-algorithm.api.mydomain.com、GitLab CIの environments に触発されました。

以下は、各デプロイメントの潜在的なワークフローです。

  1. Feature-api-deployment.ymlを作成する
  2. Feature-api-service.ymlを作成する
  3. Ingress.ymlを新しいサブドメインルールで更新します：feature.api.mydomain.com指定serviceName: feature-api-service

ただし、すべてのサブドメイン->サービスマッピングを列挙して維持すると、デプロイメントを分解し、大量のGCEバックエンド（デフォルトの割り当ては5 ...）が作成されるため、理想的ではありません。

これを処理するために見落としているKubernetesに組み込まれているものはありますか？このようなものは、一致したサブドメインに基づいてターゲットサービスを選択するのに理想的です。

ingress.yml（必要）

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
spec:
  rules:
  - Host: *.api.mydomain.com
    http:
      paths:
        - backend:
            serviceName: {value of *}-api-service
            servicePort: 80
networkingkubernetesload-balancinggoogle-kubernetes-engine
18
Nick Faughey

確かに、kubernetesで使用できるワイルドカードドメインのようなものはありませんが、 Helm を使用して、必要なものが得られる可能性があります。

Helmを使用すると、マニフェスト内に変数をテンプレート化できるため、ブランチの名前をhelmに含めることができます values file

そこから、ビルドパイプラインでgitlab-ciにhelmのインストールを実行させることができます。チャートを正しく構成すると、パイプライン名のhelm引数を指定できます。

この種のワークフローについてのすばらしいブログ投稿があります here -うまくいけば、これで目的の場所にたどり着くでしょう。

6
jaxxstorm

ローカルでサービスを利用できます

my-svc.svc.cluster.local

この場合のようにサブドメインとサービス名が一致する限り、サブドメインを解析してプロキシーがそれをhttp：// $ serviceに渡すことができる単純なNGINXプロキシを作成できます。

0
cloudpre