Kubernetes: Entrada: permitir vários hosts

1 para isso também. Conforme mencionado por @klausenbusk e por mim em https://github.com/kubernetes/kubernetes/issues/41881 , isso seria um longo caminho.

Eu prefiro ter um caractere curinga ou uma opção apenas de subdomínio, então posso especificar host: web.* ou host: api.web.* e fazer com que qualquer coisa que _inicie_ com esse padrão seja transmitida, deixando o serviço ignorante quanto ao seu domínio final (está sendo executado em .example.com ? .prod.example.com ? .beta.example.com ? .it.internal ?), mas qualquer coisa que o mova além do monolítico atual "deve listar todo o domínio único em host: é um grande passo em frente.

Pessoalmente, também acho que o controlador de ingresso (que geralmente é implantado por administradores de cluster) deve ter uma restrição que diz, "atender apenas os seguintes domínios ou subdomínios deles ...", mas isso é um problema separado.

Outro +1. Acho que quase qualquer pessoa com um caso de uso de ingresso não trivial se beneficiará com isso.

+1

+1

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Evite que os problemas sejam fechados automaticamente com um comentário /lifecycle frozen .

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou @fejta .
/ lifecycle stale

/ remove-lifecycle stale

Aparentemente, não consigo removê-lo do velho ...

parece que funcionou @deitch !

Também gostaria de ver esse recurso, mas, como solução alternativa, uso IDs YAML. Aqui está como ficaria para um determinado exemplo.

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

Não tenho muito a acrescentar, exceto dizer que seria muito bem-vindo. Esperançosamente, as regras para APIs beta ainda permitem alguma flexibilidade para modificar isso.

mesmo aqui - tem que adicionar vários domínios, ou seja,

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

o que não é realmente confortável na implementação atual ...

então, vote a favor ...

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

Isso é muito necessário: ((

1 para este recurso.

Também tentei uma solução alternativa sugerida por
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 para este recurso.

Os problemas ficam obsoletos após 90 dias de inatividade.
Marque o problema como novo com /remove-lifecycle stale .
Problemas obsoletos apodrecem após 30 dias adicionais de inatividade e, eventualmente, fecham.

Se for seguro encerrar este problema agora, faça-o com /close .

Envie feedback para sig-testing, kubernetes / test-infra e / ou fejta .
/ lifecycle stale

/ remove-lifecycle stale

recurso realmente necessário

Caso de uso que ainda não vi, temos alguns domínios que se parecem com api[0-9].domain.io - os domínios curinga existentes não cobrem esse caso. O conjunto é pequeno o suficiente para ser gerenciado manualmente usando IDs do yaml, mas seria ideal para não precisar desse fallback (por exemplo, nomes de domínio regex)

Nós realmente precisamos desse recurso

Outro voto para este recurso

outra solução alternativa para o uso de loop de alcance:

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

e em valores yaml:

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

e definir uma variável fullName ...

Ainda assim, eu preferiria um array ou regex ou ... para o elemento hosts

É quase certo que isso não esteja acontecendo no Ingress, mas devemos ter isso em mente para que a API siga o Ingress (haverá propostas em breve?)

API para seguir o Ingress, @thockin? Existe uma substituição em andamento?

É quase certo que isso não esteja acontecendo no Ingress

Não? Parece um recurso solicitado com frequência para evitar muitas duplicações. - Quais são as nossas alternativas?

Pode ser útil para alguém, eu uso a opção de

Pode ser útil para alguém, eu uso a opção de

@catalinpan como funciona na sua extremidade? Meu alias de servidor não funciona com esta configuração.

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 vale a pena verificar se a versão de entrada do nginx que você tem suporta a implementação de alias. Se a versão for mais recente, verifique aqui como deve ser a sintaxe rewrite-target .
Há um caso em que seu alias não funcionará se houver outro ingresso que use o mesmo domínio, aqui está a explicação.

Contanto que o caso acima não se aplique a você e o registro DNS de two-app.foobar.dev aponta para o mesmo balanceador de carga que one-app.foobar.dev seu exemplo deve funcionar.

Eu gerencio o alias do servidor no Route 53 usando o terraform por causa do meu caso de uso específico, várias implantações em diferentes regiões = vários CNAMEs do alias do servidor apontando para vários hosts com verificações de saúde e mais algumas opções.

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

Abaixo está um exemplo de algo que eu uso.

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

Esse recurso seria ótimo para usuários do traefik que também estão usando o recurso automático Let's Encrypt. Aqui, traefik espera uma lista de domínios separados por vírgulas como o Host (https://docs.traefik.io/v1.7/configuration/acme/#onhostrule), onde o primeiro domínio se tornará o domínio principal do certificado e todos os outros serão SAN s.

@catalinpan Também estou tendo problemas com a anotação do alias do servidor.
Tenho quase a mesma configuração que @angelogwapo. Eu tenho dois domínios:

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

Ambos estão apontando para o mesmo balanceador de carga. Ambos têm um certificado TLS válido.
Abaixo da minha configuração. Sou direcionado para a página correta, mas o certificado TLS só é válido para o domínio mencionado como host. Quando eu navego para o outro domínio, recebo o certificado falso do controlador de entrada do Kubernetes. E vice versa. Qualquer ajuda é apreciada ...

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

A propósito, estou usando a versão 0.27 que deve conter esta alteração: https://github.com/kubernetes/ingress-nginx/pull/4472/files#diff -9bba411a7c28f1ef63c3a5339db109d5

@jacqinthebox : Sua configuração Ingress realmente configura apenas um host ( one-app.one-domain.dev ). Claro, seu tls configura os dois, mas você ainda precisa de uma regra para cada domínio. Veja especificamente a matriz em spec.rules . Atualmente, não há nada que diga ao NGINX para qual serviço o segundo domínio deve ser proxy.

EDIT : Meu mal, fui muito rápido. Não percebi que você estava falando sobre a anotação de alias do servidor.

@jacqinthebox

Ambos estão apontando para o mesmo balanceador de carga. Ambos têm um certificado TLS válido.

você pode usar vários domínios independentes em um segredo TLS
`` `tls:

• hosts:
  
  
  
  • one-app.one-domain.dev
  
  
  • two-app.two-domain.dev
    
    secretName: all-app-tls
    
    `` `
  
  

Você sempre pode usar um gráfico de leme para criar a configuração dup para cada domínio em uma matriz. "Se" você estiver usando o leme, é claro :)

+1

@kramarz , Obrigado, este workround funciona para mim.

A solução alternativa também funciona perfeitamente com https://github.com/jetstack/cert-manager .
Aqui está meu exemplo

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 obrigado por isso. Funcionou um pouco para mim, mas depois de adicionar domain.com a spec.rules[0].host e www.domain.com,domain.se,www.domain.se a nginx.ingress.kubernetes.io/server-alias , recebo o seguinte erro: controller.go:1155] Conflicting hostname (domain.com) and alias (www.domain.se). Removing alias to avoid conflicts.

Alguma sugestão?