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.
+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:
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:
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?
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.