Este tópico descreve como funcionam as rotas e os domínios no Kf e como os programadores e os administradores configuram rotas e domínios para uma app implementada no cluster do Kf.
Tem de criar um domínio e rotas para dar acesso externo à sua aplicação.
Encaminhamento interno
As apps Kf podem comunicar internamente com outras apps no cluster diretamente através da rede de malha fornecida pelo Cloud Service Mesh sem sair da rede do cluster. Por predefinição, todo o tráfego é encriptado através do TLS mútuo.
Todas as apps implementadas no cluster Kf são fornecidas com um ponto final interno configurado por predefinição. Pode usar o endereço app-name.space-name.svc.cluster.local para comunicação interna entre apps. Para usar este endereço interno, não são necessários passos adicionais. O TLS mútuo está ativado por predefinição para rotas internas. Tenha em atenção que este endereço interno só é acessível a partir dos pods que executam as apps e não é acessível a partir do exterior do cluster.
Balanceamento de carga de apps
O tráfego é encaminhado pelo Istio para instâncias íntegras de uma app através de uma política de round-robin. Atualmente, não é possível alterar esta política.
Capacidades de planeamento de trajetos
As rotas indicam à entrada do cluster onde entregar o tráfego e o que fazer se não estiverem disponíveis apps no endereço indicado. Por predefinição, se não estiver disponível nenhuma app numa rota e a rota receber um pedido, devolve um código de estado HTTP 503.
As rotas são compostas por três partes: anfitrião, domínio e caminho. Por exemplo, no URI payroll.mydatacenter.example.com/login:
- O anfitrião é
payroll - O domínio é
mydatacenter.example.com - O caminho é
/login
As rotas têm de conter um domínio, mas o anfitrião e o caminho são opcionais. Várias rotas podem partilhar o mesmo anfitrião e domínio se especificarem caminhos diferentes. Várias apps podem partilhar o mesmo trajeto e o tráfego é dividido entre elas. Isto é útil se precisar de suportar implementações azul/verde antigas. Se várias apps estiverem associadas a caminhos diferentes, a prioridade é do caminho mais longo para o mais curto.
Usar trajetos
As secções seguintes descrevem como usar a CLI kf para gerir rotas.
Apresentar trajetos
Os programadores podem listar as rotas do espaço atual através do comando kf routes.
$ kf routes
Getting Routes in Space: my-space
Found 2 Routes in Space my-space
HOST DOMAIN PATH APPS
echo example.com / echo
* example.com /login uaa
Criar trajeto
Os programadores podem criar rotas através do comando kf create-route.
# Create a Route in the targeted Space to match traffic for myapp.example.com/*
$ kf create-route example.com --hostname myapp
# Create a Route in the Space myspace to match traffic for myapp.example.com/*
$ kf create-route -n myspace example.com --hostname myapp
# Create a Route in the targeted Space to match traffic for myapp.example.com/mypath*
$ kf create-route example.com --hostname myapp --path /mypath
# You can also supply the Space name as the first parameter if you have
# scripts that rely on the old cf style API.
$ kf create-route myspace example.com --hostname myapp # myapp.example.com
Depois de criar uma rota, se não estiverem associadas apps à mesma, é devolvido um código de estado HTTP 503 para quaisquer pedidos correspondentes.
Mapeie um trajeto para a sua app
Os programadores podem tornar a respetiva app acessível numa rota através do comando kf map-route.
$ kf map-route MYAPP mycluster.example.com --host myapp --path mypath
Desassocie um trajeto
Os programadores podem remover a respetiva app do acesso numa rota através do comando kf
unmap-route.
$ kf unmap-route MYAPP mycluster.example.com --host myapp --path mypath
Elimine um caminho
Os programadores podem eliminar uma rota através do comando kf delete-route.
$ kf delete-route mycluster.example.com --host myapp --path mypath
A eliminação de uma rota impede que o tráfego seja encaminhado para todas as apps que estão a ouvir na rota.
Rotas declarativas no manifesto da app
As rotas podem ser geridas de forma declarativa no ficheiro de manifesto da app. São criados se ainda não existirem.
---
applications:
- name: my-app
# ...
routes:
- route: example.com
- route: www.example.com/path
Pode ler mais acerca das propriedades de rotas suportadas na documentação do manifesto.
Tópicos avançados
CRDs de encaminhamento
Existem quatro tipos relevantes para o encaminhamento:
- VirtualService
- Rota
- Serviço
- App
Cada app tem um serviço, que é um nome abstrato atribuído a todas as instâncias em execução da sua app. O nome do serviço é o mesmo que o da app. Uma rota representa um único URL externo. As rotas monitorizam constantemente as alterações às apps. Quando uma app pede para ser adicionada a uma rota, a rota atualiza a respetiva lista de apps e, em seguida, o VirtualService. Um VirtualService representa um único domínio e une uma lista de todas as rotas num espaço que pertencem a esse domínio.
O Istio lê a configuração nos VirtualServices para determinar como encaminhar o tráfego.