Kubernetes: 入力：複数のホストを許可する

これも+1。 @klausenbuskとhttps://github.com/kubernetes/kubernetes/issues/41881の私が参照しているように、これは大いに役立ちます。

ワイルドカードまたはサブドメインのみのオプションを使用することを好むので、 host: web.*またはhost: api.web.*を指定して、そのパターンで_開始_するものをすべて通過させ、サービスを最終ドメインに関して無視することができます（ .example.com ？ .prod.example.com ？ .beta.example.com ？ .it.internal ？で実行されていますか？）しかし、現在のモノリシックを超えて移動するものはすべて、単一ドメイン全体をリストする必要がありますhost:は、大きな前進です。

個人的には、イングレスコントローラー（通常はクラスター管理者によってデプロイされます）には、「次のドメインまたはそれらのサブドメインのみにサービスを提供する...」という制限が必要だと思いますが、それは別の問題です。

別の+1。 自明ではないイングレスのユースケースを持っているほとんどの人がこれから恩恵を受けると思います。

+1

+1

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

/lifecycle frozenコメントを使用して、問題が自動終了しないようにします。

この問題を今すぐ解決できる場合は、 /close 。

sig-testing、kubernetes / test-infra、および/または@fejtaフィードバックを送信します。
/ lifecycle stale

/ remove-lifecycle stale

どうやら、私はそれを古くなったものから取り除くことはできません...

@deitchで動作したようです！

この機能も見たいのですが、回避策としてYAMLIDを使用しています。 与えられた例でどのように見えるかを次に示します。

spec:
  rules:
  - host: foobar.com
    http: &http_rules
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80
  - host: api.foobar.com
    http: *http_rules
  - host: admin.foobar.com
    http: *http_rules
  - host: status.foobar.com
    http: *http_rules

これは大歓迎だと言う以外に、追加することはあまりありません。 うまくいけば、ベータAPIのルールにより、これを変更するための柔軟性がある程度得られます。

ここでも同じ-複数のドメインを追加する必要があります。

*.foobar.com
*.foobar.net
*.foobar.biz

現在の実装では本当に快適ではないもの...

だから、投票してください...

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecycle stale

これは大いに必要です：（（

この機能の+1。

@kramarzが提案した回避策も試し
Error: YAML parse error on mysite-web/templates/ingress.yaml: error converting YAML to JSON: yaml: line 4: mapping values are not allowed in this context

この機能の+1。

90日間操作がないと、問題は古くなります。
/remove-lifecycle staleして、問題を新規としてマークします。
古い問題は、さらに30日間非アクティブになると腐敗し、最終的には閉じます。

この問題を今すぐ解決できる場合は、 /close 。

SIG-テスト、kubernetes /テスト・インフラおよび/またはへのフィードバックを送信fejta 。
/ lifecycle stale

/ remove-lifecycle stale

確かに必要な機能

まだ見たことがないユースケースですが、 api[0-9].domain.ioように見えるドメインがいくつかあります。既存のワイルドカードドメインはこのケースをカバーしていません。 セットはyamlIDを使用して手動で管理するのに十分小さいですが、そのフォールバック（たとえば、正規表現ドメイン名）を必要としないのが理想的です。

この機能が本当に必要です

この機能への別の投票

範囲ループを使用する別の回避策：

rules:
          {{- range .Values.ingress.hosts }}
    - host: {{ . }}
      http:
        paths:
          - path: /
            backend:
              serviceName: {{ $fullName }}
              servicePort: 80
              {{- end }}

値yaml：

ingress:
  hosts:
    - "bla.blub"
    - "foo.bar"

変数fullNameを設定します。

それでも私はhosts要素に配列または正規表現または...を好む

これはIngressではほぼ確実に発生していませんが、APIがIngressに準拠することを覚えておく必要があります（提案は間もなく開始されますか？）

IngressをフォローするAPI、@ thockin？ 作品に代替品はありますか？

これはIngressではほぼ確実に発生していません

番号？ 多くの重複を避けるために頻繁に要求される機能のようです。 -私たちの選択肢は何ですか？

誰かに役立つかもしれませんが、nginx入力でserver-aliasオプションを使用して、1つの入力に複数のドメインを設定します。

誰かに役立つかもしれませんが、nginx入力でserver-aliasオプションを使用して、1つの入力に複数のドメインを設定します。

@catalinpanそれはあなたの側でどのように機能しますか？ 私のサーバーエイリアスはこの構成では機能しません。

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: foobar-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
    nginx.ingress.kubernetes.io/server-alias: "two-app.foobar.dev"
spec:
  tls:
  - secretName: tls-secret
  rules:
  - host: "one-app.foobar.dev"
    http:
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80

@angelogwapoは、使用しているnginx入力バージョンがエイリアスの実装をサポートしているかどうかを確認する価値があります。 バージョンが新しい場合は、ここでrewrite-target構文がどのようになるかを確認してください。
同じドメインを使用する別の入力がある場合、エイリアスが機能しない場合があります。ここで説明します。

長い上記のケースのようにのためにあなたとDNSレコードには適用されませんtwo-app.foobar.devと同じロードバランサにポイントone-app.foobar.devあなたの例では、動作するはずです。

特定のユースケース、異なるリージョンでの複数のデプロイ=ヘルスチェックといくつかのオプションを備えた複数のホストを指す複数のサーバーエイリアスCNAMEのために、Route53でサーバーエイリアスを管理しています。

例：
CNAME 2-app.foobar.dev-> one-app-ew1.foobar.dev
CNAME 2-app.foobar.dev-> one-app-ase1.foobar.dev

以下は私が使っているものの例です。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/server-alias: public_url
  name: app1
spec:
  tls:
  - hosts:
    - public_region_url
      secretName: my_wildcard
  rules:
    - host: public_region_url
      http:
        paths:
          - path: /
            backend:
              serviceName: app1
              servicePort: 80

この機能は、自動化されたLet'sEncrypt機能も使用しているtraefikのユーザーにとって便利です。 ここで、traefikは、ドメインのコンマ区切りリストをホスト（https://docs.traefik.io/v1.7/configuration/acme/#onhostrule）として想定しています。ここで、最初のドメインが証明書のメインドメインになり、他のすべてはSANます。

@catalinpan私もserver-aliasアノテーションに苦労しています。
@angelogwapoとほぼ同じ設定です。 私は2つのドメインを持っています：

• one-app.one-domain.dev
• two-app.two-domain.dev

どちらも同じロードバランサーを指しています。 どちらにも有効なTLS証明書があります。
私の設定の下。 正しいページに移動しますが、TLS証明書はホストとして指定されているドメインに対してのみ有効です。 他のドメインを参照すると、Kubernetes IngressControllerの偽の証明書が表示されます。 およびその逆。 どんな助けでもありがたいです...

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    app.kubernetes.io/instance: ngress-rules
    cert-manager.io/issuer: letsencrypt-prod
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/rewrite-target: /
    nginx.ingress.kubernetes.io/server-alias: two-app.two-domain.dev
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
  name: ingress-rules
  namespace: default
spec:
  rules:
  - host: one-app.one-domain.dev
    http:
      paths:
      - backend:
          serviceName: service1
          servicePort: 80
        path: /
      - backend:
          serviceName: service2
          servicePort: 80
        path: /portal/
  tls:
  - hosts:
    - one-app.one-domain.dev
    secretName: one-app-tls
  - hosts:
    - two-app.two-domain.dev
    secretName: two-app-tls

ところで、私はこの変更を含む必要があるバージョン0.27を使用しています： https ：

@jacqinthebox ： Ingress構成では、実際には1つのホスト（ one-app.one-domain.dev ）のみが構成されます。 もちろん、 tls両方を構成しますが、ドメインごとに1つのルールが必要です。 具体的には、 spec.rules下の配列を参照してください。 現在、2番目のドメインがプロキシする必要があるサービスをNGINXに指示するものはありません。

編集：私の悪い、私は速すぎた。 サーバーエイリアスアノテーションについて話していることに気づきませんでした。

@jacqinthebox

どちらも同じロードバランサーを指しています。 どちらにも有効なTLS証明書があります。

1つのTLSシークレットで複数の独立したドメインを使用できます
`` `tls：

• ホスト：
  
  
  
  • one-app.one-domain.dev
  
  
  • two-app.two-domain.dev
    
    secretName：all-app-tls
    
    `` `
  
  

いつでもヘルムチャートを使用して、アレイ内の各ドメインのdup構成を作成できます。 「もし」あなたがヘルムを使用しているのはもちろんです:)

+1

@kramarz 、ありがとう、この回避策は私のために働きます。

回避策はhttps://github.com/jetstack/cert-managerでも完全に機能し
これが私の例です

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
   name: site
   annotations:
      cert-manager.io/issuer: letsencrypt-prod
      nginx.ingress.kubernetes.io/server-alias: host2.com
spec:
   rules:
   - host: host1.com
     http:
      paths:
      - path: /
        backend:
           serviceName: site
           servicePort: 8080
   tls:
   - secretName: nice-name
     hosts:
     - host1.com
     - host2.com

@AndreKoepkeありがとうございます。 私にとっては多少は機能しましたが、 domain.comをspec.rules[0].hostに追加し、 www.domain.com,domain.se,www.domain.seをnginx.ingress.kubernetes.io/server-aliasに追加すると、次のエラーが発生します： controller.go:1155] Conflicting hostname (domain.com) and alias (www.domain.se). Removing alias to avoid conflicts.

助言がありますか？