Expondo aplicações Spin no SpinKube com Gateway API: Além do Ingress tradicional

A Gateway API não é apenas um "Ingress v2"; trata-se de uma abordagem inteiramente reformulada para expor serviços dentro do Kubernetes, eliminando a necessidade de codificar capacidades de roteamento em annotations proprietárias e não estruturadas de fornecedores específicos. Neste artigo, exploraremos como expor aplicações WebAssembly construídas com o framework CNCF Spin e servidas pelo SpinKube utilizando a Gateway API.

O que é o SpinKube

O SpinKube, um projeto sandbox da CNCF, é uma stack open-source para execução de aplicações serverless em WebAssembly (Spin apps) sobre Kubernetes. Embora o SpinKube utilize primitivos do Kubernetes como Deployments, Services e Pods, não há containers envolvidos na execução das apps. Em vez disso, ele utiliza uma implementação de containerd-shim para disparar processos nos nós de trabalho (worker nodes), garantindo baixíssima latência e alta densidade de execução.

Para empresas brasileiras que buscam eficiência operacional (FinOps), o SpinKube representa uma oportunidade de reduzir drasticamente o consumo de recursos em comparação com containers tradicionais.

O que é Gateway API

A Gateway API é a sucessora moderna e orientada a papéis (role-oriented) do legado recurso de Ingress. Ela foi projetada para fornecer uma interface de rede mais expressiva e extensível. Diferente do Ingress, que frequentemente depende de uma emaranhado de anotações de vendor para lidar com lógicas complexas, a Gateway API divide o gerenciamento de tráfego em recursos atômicos: GatewayClass, Gateway, e rotas (como HTTPRoute ou GRPCRoute).

Essa separação permite que administradores de infraestrutura gerenciem os pontos de entrada enquanto desenvolvedores controlam como seus serviços específicos são expostos, habilitando nativamente padrões avançados como canary rollouts, roteamento baseado em headers e traffic mirroring.

Preparando o Ambiente

Para acompanhar este guia técnico, você precisará das seguintes ferramentas:

• spin CLI: Para build das apps.
• Rust com o target wasm32-wasip1.
• kubectl e helm: Para interação com o cluster.

Build e Deployment das Spin Apps no Kubernetes

Iniciamos compilando o código-fonte das nossas aplicações de exemplo para WebAssembly. Execute o comando spin build dentro de cada pasta de aplicação:

Copiar# Build da aplicação greeter
pushd apps/greeter
spin build

 Building component greeter with `cargo build --target wasm32-wasip1 --release`
     Finished `release` profile [optimized] target(s) in 0.21s
 Finished building all Spin components

popd

# Build da aplicação prime_numbers
pushd apps/prime-numbers
spin build

  Building component prime-numbers with `cargo build --target wasm32-wasip1 --release`
    Finished `release` profile [optimized] target(s) in 0.18s
  Finished building all Spin components
popd

Após a compilação, utilizamos spin registry push para distribuir o artefato OCI. No exemplo, utilizaremos o ttl.sh, um registro efêmero para testes.

Copiargreeter_app_artifact=ttl.sh/spin-greeter:24h
primenumbers_app_artifact=ttl.sh/spin-prime-numbers:24h

pushd apps/greeter
spin registry push $greeter_app_artifact --build
popd

pushd apps/prime-numbers
spin registry push $primenumbers_app_artifact --build
popd

Agora, geramos e aplicamos os manifestos Kubernetes utilizando o comando spin kube scaffold:

Copiarspin kube scaffold --from $greeter_app_artifact | kubectl apply -f -
spin kube scaffold --from $primenumbers_app_artifact | kubectl apply -f -

Os recursos SpinApp serão criados conforme o exemplo abaixo:

Copiarapiv1: core.spinkube.dev/v1alpha1
kind: SpinApp
metadata:
  name: spin-greeter
spec:
  image: "ttl.sh/spin-greeter:24h"
  executor: containerd-shim-spin
  replicas: 2

Instalando a Gateway API e o Controller

Para utilizar a Gateway API, devemos instalar os CRDs no cluster e um controlador compatível. Utilizaremos o NGINX Gateway Fabric neste laboratório.

Instalação dos CRDs:

Copiarkubectl kustomize "https://github.com/nginx/nginx-gateway-fabric/config/crd/gateway-api/standard?ref=v2.3.0" | kubectl apply -f -

Instalação do Controlador via Helm:

Copiarhelm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric --create-namespace -n nginx-gateway

Criando Recursos de Gateway

O recurso Gateway define o ponto de entrada do tráfego. Ele pode ser compartilhado entre múltiplas aplicações e namespaces.

Copiarapiv1: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: spinkube
  namespace: default
spec:
  gatewayClassName: nginx
  listeners:
  - protocol: HTTP
    port: 8080
    name: http
    allowedRoutes:
      namespaces:
        from: Same

Após o deployment, o Cloud Controller do seu provedor (como AWS, Azure ou GCP) atribuirá um EXTERNAL-IP ao serviço spinkube-nginx.

Definindo as Rotas (HTTPRoute)

Agora, vinculamos as aplicações ao Gateway usando HTTPRoute, empregando roteamento baseado em prefixo de caminho (PathPrefix) e filtros de URLRewrite.

Copiarapiv1: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: greeter
  namespace: default
spec:
  parentRefs:
  - name: spinkube
  rules:
  - backendRefs:
    - name: spin-greeter
      port: 80
    filters:
    - type: URLRewrite
      urlRewrite: 
        path:
          replacePrefixMatch: /
          type: ReplacePrefixMatch
    matches:
    - path:
        type: PathPrefix
        value: /greeter

Testando o Acesso

Com a infraestrutura pronta, validamos o acesso externo via curl usando o IP público do Gateway:

Copiar# Testando a app greeter
curl -i http://<EXTERNAL_IP>:8080/greeter/hello/NuvemOnline

# Testando a app prime-numbers
curl -i http://<EXTERNAL_IP>:8080/prime-numbers/above/999

Conclusão: O Impacto Estratégico

A migração para a Gateway API não é apenas uma mudança técnica, mas uma melhoria na governança de TI. Para gestores, isso significa uma separação clara entre quem cuida da infraestrutura de borda (SysAdmins/SREs) e quem define as regras de negócio das rotas (Desenvolvedores).

Em cenários de escala com centenas de micro-aplicações serverless rodando em SpinKube, essa robustez de roteamento é o que garante a estabilidade e a facilidade de manutenção a longo prazo, mitigando riscos de configurações incorretas que são comuns no modelo de anotações do Ingress tradicional.

---

Artigo originalmente publicado por Thorsten Hans, SpinKube Maintainer and Senior Developer Advocate, Akamai em Cloud Native Computing Foundation.