Kubernetes: Ingress: 여러 호스트 허용

이것도 +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 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

분명히, 나는 오래된에서 그것을 제거 할 수 없습니다 ...

@deitch 가 효과가

이 기능도 보고 싶지만 해결 방법으로 YAML ID를 사용합니다. 다음은 주어진 예를 찾는 방법입니다.

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-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

이것은 많이 필요합니다 :((

이 기능에 대해 +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-testing, kubernetes/test-infra 및/또는 fejta에 피드백을 보내십시오.
/수명 주기 부실

/remove-lifecycle 부실

정말 필요한 기능

아직 본 적이 없는 사용 사례입니다. api[0-9].domain.io 처럼 보이는 일부 도메인이 있습니다. 기존 와일드카드 도메인은 이 경우를 다루지 않습니다. 집합은 yaml ID를 사용하여 수동으로 관리할 수 있을 만큼 충분히 작지만 대체(예: 정규식 도메인 이름)가 필요하지 않은 경우 이상적입니다.

이 기능이 정말 필요합니다

이 기능에 대한 또 다른 투표

범위 루프를 사용하는 또 다른 해결 방법:

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

그리고 값 yaml에서:

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

변수 fullName을 설정하고...

여전히 호스트 요소에 대해 배열이나 정규식 또는 ...를 선호합니다.

이것은 Ingress에서 발생하지 않는 것이 거의 확실하지만 API가 Ingress를 따를 수 있도록 염두에 두어야 합니다(곧 제안이 올까요?)

Ingress를 팔로우하는 API, @thockin? 작업에 교체가 있습니까?

이것은 Ingress에서 거의 발생하지 않습니다.

아니요? 많은 중복을 피하기 위해 자주 요청되는 기능인 것 같습니다. -- 우리의 대안은 무엇입니까?

누군가에게 유용할 수 있습니다. nginx 수신에서 server-alias 옵션을 사용하여 단일 수신에 대해 여러 도메인을 갖습니다.

누군가에게 유용할 수 있습니다. nginx 수신에서 server-alias 옵션을 사용하여 단일 수신에 대해 여러 도메인을 갖습니다.

@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 때문에 terraform을 사용하여 Route 53에서 서버 별칭을 관리합니다.

예시:
CNAME two-app.foobar.dev --> one-app-ew1.foobar.dev
CNAME two-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's Encrypt 기능도 사용하는 traefik 사용자에게 매우 좋습니다. 여기서 traefik은 쉼표로 구분된 도메인 목록을 호스트로 예상합니다(https://docs.traefik.io/v1.7/configuration/acme/#onhostrule). 여기서 첫 번째 도메인은 인증서의 기본 도메인이 되고 다른 모든 것은 SAN s가 됩니다.

@catalinpan 나도 서버 별칭 주석으로 어려움을 겪고 있습니다.
@angelogwapo와 거의 동일한 구성을 가지고 있습니다. 두 개의 도메인이 있습니다.

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

둘 다 동일한 로드 밸런서를 가리키고 있습니다. 둘 다 유효한 TLS 인증서가 있습니다.
내 구성 아래. 올바른 페이지로 연결되지만 TLS 인증서는 호스트로 언급된 도메인에만 유효합니다. 다른 도메인으로 이동하면 Kubernetes 수신 컨트롤러 가짜 인증서가 표시됩니다. 그 반대. 도움을 주시면 감사하겠습니다...

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, 이 변경 사항을 포함해야 하는 버전 0.27을 사용하고 있습니다. https://github.com/kubernetes/ingress-nginx/pull/4472/files#diff -9bba411a7c28f1ef63c3a5339db109d5

@jacqinthebox : Ingress 구성은 실제로 하나의 호스트( one-app.one-domain.dev )만 구성합니다. 물론 tls 둘 다 구성하지만 각 도메인에 대해 여전히 하나의 규칙이 필요합니다. 특히 spec.rules 아래의 배열을 참조하십시오. 현재 두 번째 도메인이 프록시해야 하는 서비스를 NGINX에 알려주는 것은 없습니다.

편집 : 내 나쁜, 내가 너무 빨랐다. 나는 당신이 서버 별칭 주석에 대해 이야기하고 있다는 것을 몰랐습니다.

@jacqinthebox

둘 다 동일한 로드 밸런서를 가리키고 있습니다. 둘 다 유효한 TLS 인증서가 있습니다.

하나의 TLS 비밀에서 여러 독립 도메인을 사용할 수 있습니다.
``` tls:

• 호스트:
  
  
  
  • one-app.one-domain.dev
  
  
  • two-app.two-domain.dev
    
    secretName: all-app-tls
    
    ```
  
  

항상 helm 차트를 사용하여 어레이의 각 도메인에 대한 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.

어떤 제안?