Algumas apps são úteis sem serem acessíveis fora do cluster, mas a maioria tem de estar disponível fora do cluster num ou mais pontos finais HTTP. Em Kf, esta é a função dos trajetos.
Por predefinição, cada app é acessível a outros processos no cluster através do endereço da app interno do cluster: app-name.space-name. Pode usar este endereço quando implementar uma ou mais apps num cluster que precisam de comunicar entre si. Permitem que o tráfego vá diretamente de uma app para outra, em vez de sair do cluster e voltar a entrar. Isto torna as comunicações mais seguras, rápidas e garante a utilização do serviço no cluster local.
Se a sua app precisar de ser acessível a partir do exterior do cluster, tem de criar rotas para a mesma.
O domínio interno do cluster
O domínio interno do cluster para cada app tem algumas caraterísticas especiais.
- A sua utilização nas apps permite o planeamento de rotas Este-Oeste (ponto a ponto).
- O tráfego enviado para o mesmo é equilibrado entre os pods de apps em execução.
- Pode estabelecer ligação a pontos finais não HTTP através do domínio interno.
As rotas permitem-lhe criar URLs personalizados além do domínio interno 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 anfitrião e um domínio, mas o caminho é opcional. 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.