Kubernetes: Ingress: Izinkan untuk beberapa host

Dibuat pada 24 Mar 2017  ·  38Komentar  ·  Sumber: kubernetes/kubernetes

Apakah ini permintaan bantuan?
Tidak

Kata kunci apa yang Anda cari di edisi Kubernetes sebelum mengajukan yang ini?
Pengontrol masuknya, "host", banyak host.

Saya menemukan masalah ini: https://github.com/kubernetes/ingress/issues/87 tetapi ditutup karena berada di repo yang salah.


Apakah ini LAPORAN BUG atau PERMINTAAN FITUR? (Pilih satu):
PERMINTAAN FITUR

Dengan implementasi saat ini, jika Anda memiliki beberapa sub-/domain yang perlu diarahkan ke layanan yang sama, Anda mendapatkan "banyak" kode duplikat.

Contoh:

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

Jadi saya mengusulkan agar bidang Host diubah dari FQDN tunggal menjadi larik FQDN.
Jadi saya bisa melakukan sesuatu seperti:

spec:
  rules:
  - host: ["foobar.com", "api.foobar.com", "admin.foobar.com", "status.foobar.com"]
    http:
      paths:
      - backend:
          serviceName: foobar
          servicePort: 80

Ini menghemat 18 baris dan membuat konfigurasi lebih jelas.

Mungkin dup dari: https://github.com/kubernetes/kubernetes/issues/41881 , tetapi ini tampaknya lebih mudah diterapkan.

cc @aledbf (Anda menutup masalah terakhir, tidak yakin apakah Anda "bekerja" di bagian k8s ini)

Versi Kubernetes (gunakan kubectl version ):

Client Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4", GitCommit:"7243c69eb523aa4377bce883e7c0dd76b84709a1", GitTreeState:"clean", BuildDate:"2017-03-07T23:53:09Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"5", GitVersion:"v1.5.4+coreos.0", GitCommit:"97c11b097b1a2b194f1eddca8ce5468fcc83331c", GitTreeState:"clean", BuildDate:"2017-03-08T23:54:21Z", GoVersion:"go1.7.4", Compiler:"gc", Platform:"linux/amd64"}

Lingkungan :
Digital Ocean, Core OS.

sinetwork triagunresolved

Komentar yang paling membantu

Saya juga ingin melihat fitur ini, tetapi sebagai solusinya, saya menggunakan id YAML. Berikut adalah bagaimana tampilannya untuk contoh yang diberikan.

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

Semua 38 komentar

+1 untuk ini juga. Seperti yang dirujuk oleh @klausenbusk dan saya di https://github.com/kubernetes/kubernetes/issues/41881 , ini akan sangat membantu.

Saya lebih suka memiliki opsi wildcard atau subdomain saja, jadi saya dapat menentukan host: web.* atau host: api.web.* dan memiliki apa pun yang _mulai_ dengan pola itu lewati, membiarkan layanan tidak mengetahui domain terakhirnya (apakah itu berjalan di .example.com ? .prod.example.com ? .beta.example.com ? .it.internal ?), tetapi apa pun yang memindahkannya melewati monolitik saat ini "harus mencantumkan seluruh domain tunggal di host: adalah langkah maju yang besar.

Secara pribadi, saya juga berpikir pengontrol masuknya (yang biasanya digunakan oleh admin cluster) harus memiliki batasan yang mengatakan, "hanya melayani domain atau subdomain berikut dari mereka ...", tetapi itu adalah masalah terpisah.

+1 lainnya. Saya pikir hampir semua orang dengan kasus penggunaan ingress non-sepele akan mendapat manfaat dari ini.

+1

+1

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Cegah masalah dari penutupan otomatis dengan komentar /lifecycle frozen .

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau @fejta .
/siklus hidup basi

/hapus siklus hidup basi

Rupanya, saya tidak bisa menghapusnya dari basi ...

sepertinya berhasil @deitch !

Saya juga ingin melihat fitur ini, tetapi sebagai solusinya, saya menggunakan id YAML. Berikut adalah bagaimana tampilannya untuk contoh yang diberikan.

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

Saya tidak punya banyak untuk menambahkan kecuali untuk mengatakan ini akan sangat welcome. Mudah-mudahan aturan untuk API beta masih memungkinkan fleksibilitas untuk memodifikasi ini.

sama di sini - harus menambahkan beberapa domain yaitu

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

apa yang kurang nyaman dalam implementasi saat ini...

jadi, suarakan ...

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

Ini sangat dibutuhkan :((

+1 untuk fitur ini.

Saya juga mencoba solusi yang disarankan @kramarz , dan saya mendapatkan kesalahan berikut:
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 untuk fitur ini.

Masalah menjadi basi setelah 90 hari tidak aktif.
Tandai masalah sebagai baru dengan /remove-lifecycle stale .
Masalah basi membusuk setelah 30 hari tambahan tidak aktif dan akhirnya ditutup.

Jika masalah ini aman untuk ditutup sekarang, silakan lakukan dengan /close .

Kirim umpan balik ke sig-testing, kubernetes/test-infra dan/atau fejta .
/siklus hidup basi

/hapus siklus hidup basi

fitur yang dibutuhkan memang

Kasus penggunaan yang belum saya lihat, kami memiliki beberapa domain yang terlihat seperti api[0-9].domain.io -- domain wildcard yang ada tidak mencakup kasus ini. Set ini cukup kecil untuk dikelola secara manual menggunakan ID yaml, tetapi akan ideal untuk tidak memerlukan fallback itu (mis., nama domain regex)

Kami sangat membutuhkan fitur ini

Suara lain untuk fitur ini

solusi lain menggunakan loop rentang:

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

dan dalam nilai yaml:

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

dan atur variabel fullName...

Masih saya lebih suka array atau regex atau ... untuk elemen host

Ini hampir pasti tidak terjadi di Ingress , tetapi kita harus ingat agar API mengikuti Ingress (proposal segera hadir?)

API untuk mengikuti Ingress, @thockin? Apakah ada pengganti dalam pengerjaan?

Ini hampir pasti tidak terjadi di Ingress

Tidak? Tampaknya fitur yang sering diminta untuk menghindari banyak duplikasi. -- Apa alternatif kami?

Mungkin berguna bagi seseorang, saya menggunakan opsi server-alias pada ingress nginx untuk memiliki banyak domain untuk satu ingress.

Mungkin berguna bagi seseorang, saya menggunakan opsi server-alias pada ingress nginx untuk memiliki banyak domain untuk satu ingress.

@catalinpan bagaimana cara kerjanya di pihak Anda? Server-alias saya tidak berfungsi dengan konfigurasi ini.

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 layak untuk diperiksa apakah versi nginx ingress yang Anda miliki mendukung implementasi alias. Jika versinya lebih baru, periksa di sini bagaimana seharusnya sintaks rewrite-target terlihat.
Ada kasus di mana alias Anda tidak akan berfungsi jika ada ingress lain yang menggunakan domain yang sama, berikut penjelasannya.

Selama kasus di atas tidak berlaku untuk Anda dan catatan DNS untuk two-app.foobar.dev menunjuk ke penyeimbang beban yang sama dengan one-app.foobar.dev contoh Anda akan berfungsi.

Saya mengelola alias server di Route 53 menggunakan terraform karena kasus penggunaan khusus saya, beberapa penerapan di berbagai wilayah = beberapa server alias CNAME yang menunjuk ke beberapa host dengan pemeriksaan kesehatan dan beberapa opsi lagi.

contoh:
CNAME two-app.foobar.dev --> one-app-ew1.foobar.dev
CNAME two-app.foobar.dev --> one-app-ase1.foobar.dev

Di bawah ini adalah contoh dari sesuatu yang saya gunakan.

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

Fitur ini akan sangat bagus untuk pengguna traefik yang juga menggunakan fitur Let's Encrypt otomatis. Di sini, traefik mengharapkan daftar domain yang dipisahkan koma sebagai Host (https://docs.traefik.io/v1.7/configuration/acme/#onhostrule), di mana domain pertama akan menjadi domain utama sertifikat dan semua yang lain akan menjadi SAN s.

@catalinpan Saya juga berjuang dengan anotasi server-alias.
Saya memiliki konfigurasi yang hampir sama dengan @angelogwapo. Saya memiliki dua domain:

  • satu-aplikasi.satu-domain.dev
  • dua-aplikasi.dua-domain.dev

Keduanya menunjuk ke loadbalancer yang sama. Keduanya memiliki sertifikat TLS yang valid.
Di bawah konfigurasi saya. Saya diarahkan ke halaman yang benar, tetapi sertifikat TLS hanya valid untuk domain yang disebutkan sebagai Host. Ketika saya menjelajah ke domain lain, saya disajikan Sertifikat Palsu Pengendali Ingress Kubernetes. Dan sebaliknya. Bantuan apa pun dihargai ...

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

Btw, saya menggunakan versi 0.27 yang seharusnya berisi perubahan ini: https://github.com/kubernetes/ingress-nginx/pull/4472/files#diff -9bba411a7c28f1ef63c3a5339db109d5

@jacqinthebox : Ingress sebenarnya hanya mengonfigurasi satu Host ( one-app.one-domain.dev ). Tentu, tls mengonfigurasi keduanya, tetapi Anda masih memerlukan satu aturan untuk setiap domain. Secara khusus lihat array di bawah spec.rules . Saat ini, tidak ada yang memberi tahu NGINX layanan mana yang harus diproksi oleh domain ke-2.

EDIT : Buruk saya, saya terlalu cepat. Saya tidak menyadari bahwa Anda berbicara tentang anotasi alias server.

@jacqinthebox

Keduanya menunjuk ke loadbalancer yang sama. Keduanya memiliki sertifikat TLS yang valid.

Anda dapat menggunakan beberapa domain independen dalam satu rahasia TLS
``` tl:

  • tuan rumah:

    • satu-aplikasi.satu-domain.dev

    • dua-aplikasi.dua-domain.dev

      secretName: semua-aplikasi-tls

      ```

Anda selalu dapat menggunakan diagram helm untuk membuat konfigurasi dup untuk setiap domain dalam array. "Jika" Anda menggunakan helm tentu saja :)

+1

@kramarz , Terima kasih, solusi ini berhasil untuk saya.

Solusinya juga berfungsi sempurna dengan https://github.com/jetstack/cert-manager .
Ini contoh saya

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 terima kasih untuk ini. Ini agak berhasil untuk saya tetapi setelah menambahkan domain.com ke spec.rules[0].host dan www.domain.com,domain.se,www.domain.se ke nginx.ingress.kubernetes.io/server-alias Saya mendapatkan kesalahan berikut: controller.go:1155] Conflicting hostname (domain.com) and alias (www.domain.se). Removing alias to avoid conflicts.

Ada saran?

Apakah halaman ini membantu?
0 / 5 - 0 peringkat