feat(content): add Gateway API v1.6 blog post (EN/PT-BR)

content/en/blog/gateway-api-v1-6/index.md

@@ -0,0 +1,106 @@
+---
+title: "Gateway API v1.6 — TCPRoute and UDPRoute Graduate to Standard"
+description: "Kubernetes Gateway API v1.6.0 brings TCPRoute and UDPRoute to Standard (GA) for portable raw L4 TCP/UDP routing, introduces the experimental XBackend resource, and moves experimental APIs to their own group, gateway.networking.x-k8s.io."
+summary: "Gateway API v1.6.0 is out. TCPRoute and UDPRoute graduate from Experimental to Standard in v1, giving workloads like databases, DNS, VoIP, gaming and IoT a portable way to route raw L4 traffic. The release also adds the new experimental XBackend resource and splits experimental APIs into the gateway.networking.x-k8s.io group."
+date: 2026-08-03
+draft: false
+tags: ["kubernetes", "gateway-api", "networking", "service-mesh", "cncf"]
+categories: ["infrastructure"]
+featureimage: "cover.png"
+featureimagecaption: "Gateway API v1.6 cover — TCPRoute and UDPRoute graduate to Standard"
+---
+
+The Kubernetes SIG Network community released **Gateway API v1.6.0** on June 30, 2026, and it is a milestone release: **TCPRoute and UDPRoute graduate from Experimental to Standard (GA)** in the `v1` API version. For the first time, you can route raw TCP and UDP traffic through Gateway API with a portable, vendor-neutral API — no more falling back to a plain `Service` or to implementation-specific CRDs.
+
+![Gateway API v1.6](cover.png)
+
+## What's New in Gateway API v1.6
+
+- **TCPRoute and UDPRoute are now Standard** (`v1`), enabling portable raw L4 traffic routing.
+- **A new experimental resource, XBackend**, arrives in the `gateway.networking.x-k8s.io/v1alpha1` group as a general-purpose decorator for backends.
+- **Experimental APIs get their own group**: new experimental resources live under `gateway.networking.x-k8s.io` with an `X` prefix, instead of the old version-string scheme.
+- **Six implementations are conformant with v1.6** on the day of the announcement.
+
+## TCPRoute and UDPRoute Graduate to Standard
+
+Raw Layer 4 routing has been the most requested feature in Gateway API's history. Before v1.6, workloads that need protocol-level TCP or UDP traffic — databases, DNS, VoIP, gaming, IoT telemetry — had to rely on plain Kubernetes `Service` objects or on CRDs tied to a specific implementation.
+
+With `TCPRoute` and `UDPRoute` in the `v1` API version, that changes. A `Gateway` declares a listener with `protocol: TCP` (or `UDP`) and an `allowedRoutes.kinds` list that includes the route type. The route attaches to the listener through `parentRefs` — with an optional `sectionName` and `port` — and forwards to a backend via `rules[].backendRefs`.
+
+Here is what a TCP setup looks like:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1
+kind: Gateway
+metadata:
+  name: tcp-gateway
+spec:
+  gatewayClassName: example
+  listeners:
+    - name: tcp
+      protocol: TCP
+      port: 3306
+      allowedRoutes:
+        kinds:
+          - group: gateway.networking.k8s.io
+            kind: TCPRoute
+---
+apiVersion: gateway.networking.k8s.io/v1
+kind: TCPRoute
+metadata:
+  name: database
+spec:
+  parentRefs:
+    - name: tcp-gateway
+      sectionName: tcp
+      port: 3306
+  rules:
+    - backendRefs:
+        - name: database
+          port: 3306
+```
+
+`UDPRoute` follows exactly the same pattern — just swap `protocol: TCP` for `protocol: UDP` on the listener and use `kind: UDPRoute` (with a matching `allowedRoutes.kinds` entry) on the route.
+
+**Deprecation note:** the `v1alpha2` versions of `TCPRoute` and `UDPRoute` are deprecated as of v1.6 and will be removed in a future release. Existing `v1alpha2` users should plan to migrate to `v1`.
+
+## XBackend: A New Experimental Resource (GEP-4894)
+
+Alongside the GA graduation, v1.6 introduces a new experimental API called **XBackend**, a general-purpose decorator for `Service` and other backend types. It lives in the new API group `gateway.networking.x-k8s.io/v1alpha1`.
+
+The first version of `XBackend` supports `ExternalHostname` destinations — an Extended/Optional feature that is useful for egress scenarios and agentic AI workloads. Because an `ExternalHostname` resolves to an address outside the cluster, keep the *confused deputy* security consideration in mind: any controller that proxies to external hostnames should be explicit about which hostnames it is allowed to reach.
+
+The community is also working on moving Session Persistence configuration from `XBackendTrafficPolicy` into `XBackend`, as well as adding support for retries and TLS origination.
+
+## Experimental APIs Move to Their Own Group
+
+v1.6 also changes *how* experimental APIs are versioned. New experimental resources now live in a separate API group, `gateway.networking.x-k8s.io`, and their type names carry an `X` prefix — for example `XBackend` and `XMesh`. When a resource graduates to Standard, it is renamed into `gateway.networking.k8s.io` and the `X` prefix is dropped (for example, `XMesh` becomes `Mesh`).
+
+`TCPRoute` and `UDPRoute` were the last resources to graduate under the old version-string scheme (`v1alpha2` → `v1`). Going forward, the `X`-prefixed group makes it clear at a glance which resources are still experimental.
+
+## Conformance: Six Implementations
+
+Gateway API conformance is enforced through a formal test suite, and the following six implementations were conformant with v1.6 on publication day:
+
+- Agentgateway
+- Airlock Microgateway
+- GKE Gateway
+- kgateway
+- NGINX Gateway Fabric
+- Traefik Proxy
+
+## Try It Yourself
+
+If you want to try TCP or UDP routing today, any of the conformant implementations above is a good starting point. The project maintains user guides for [TCP](https://gateway-api.sigs.k8s.io/guides/user-guides/tcp/) and [UDP](https://gateway-api.sigs.k8s.io/guides/user-guides/udp/) routing, plus full [documentation](https://gateway-api.sigs.k8s.io/) and the [v1.6.0 release notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.6.0).
+
+## Get Involved
+
+Gateway API is the role-oriented, expressive service networking standard for Kubernetes, built under SIG Network. To get involved:
+
+- Join **#sig-network-gateway-api** on the [Kubernetes Slack](https://slack.k8s.io/)
+- Check the SIG Network calendar for community meetings
+- Browse and contribute to the [gateway-api repository](https://github.com/kubernetes-sigs/gateway-api)
+
+---
+
+At **EF-TECH**, we specialize in Kubernetes, cloud computing, and infrastructure automation. We help teams design and operate modern service networking — Gateway API included. [Contact us](/en/contato/) to learn how we can help your team. For more articles like this, visit our [blog](/en/blog/).

content/pt-br/blog/gateway-api-v1-6/index.md

@@ -0,0 +1,106 @@
+---
+title: "Gateway API v1.6 — TCPRoute e UDPRoute tornam-se Standard"
+description: "O Gateway API v1.6.0 do Kubernetes traz TCPRoute e UDPRoute para Standard (GA) com roteamento L4 TCP/UDP portável, apresenta o novo recurso experimental XBackend e separa as APIs experimentais no grupo gateway.networking.x-k8s.io."
+summary: "O Gateway API v1.6.0 chegou. TCPRoute e UDPRoute deixam o estágio Experimental e passam a Standard na versão v1, oferecendo a workloads como bancos de dados, DNS, VoIP, jogos e IoT uma forma portátil de rotear tráfego L4 puro. A release também adiciona o novo recurso experimental XBackend e separa as APIs experimentais no grupo gateway.networking.x-k8s.io."
+date: 2026-08-03
+draft: false
+tags: ["kubernetes", "gateway-api", "redes", "service-mesh", "cncf"]
+categories: ["infraestrutura"]
+featureimage: "cover.png"
+featureimagecaption: "Capa do Gateway API v1.6 — TCPRoute e UDPRoute promovidos a Standard"
+---
+
+A comunidade Kubernetes SIG Network lançou o **Gateway API v1.6.0** em 30 de junho de 2026, e esta é uma release marcante: **TCPRoute e UDPRoute deixam o estágio Experimental e passam a Standard (GA)** na versão de API `v1`. Pela primeira vez, você consegue rotear tráfego TCP e UDP puro com o Gateway API usando uma API portátil e neutra de fornecedor — sem precisar recorrer a um `Service` comum ou a CRDs específicos de cada implementação.
+
+![Gateway API v1.6](cover.png)
+
+## O Que Há de Novo no Gateway API v1.6
+
+- **TCPRoute e UDPRoute agora são Standard** (`v1`), habilitando roteamento portátil de tráfego L4 puro.
+- **Um novo recurso experimental, XBackend**, chega no grupo `gateway.networking.x-k8s.io/v1alpha1` como um decorator de uso geral para backends.
+- **APIs experimentais ganham grupo próprio**: novos recursos experimentais passam a viver em `gateway.networking.x-k8s.io` com o prefixo `X`, em vez do antigo esquema de versões.
+- **Seis implementações são conformes com o v1.6** no dia do anúncio.
+
+## TCPRoute e UDPRoute tornam-se Standard
+
+O roteamento puro na camada 4 (L4) é um dos recursos mais pedidos na história do Gateway API. Antes do v1.6, workloads que precisam de tráfego TCP ou UDP em nível de protocolo — bancos de dados, DNS, VoIP, jogos, telemetria de IoT — dependiam do `Service` comum do Kubernetes ou de CRDs atrelados a uma implementação específica.
+
+Com `TCPRoute` e `UDPRoute` na versão de API `v1`, isso muda. Um `Gateway` declara um listener com `protocol: TCP` (ou `UDP`) e uma lista `allowedRoutes.kinds` que inclui o tipo de rota. A rota se conecta ao listener por meio de `parentRefs` — com `sectionName` e `port` opcionais — e encaminha o tráfego para um backend via `rules[].backendRefs`.
+
+Veja como fica uma configuração TCP:
+
+```yaml
+apiVersion: gateway.networking.k8s.io/v1
+kind: Gateway
+metadata:
+  name: tcp-gateway
+spec:
+  gatewayClassName: example
+  listeners:
+    - name: tcp
+      protocol: TCP
+      port: 3306
+      allowedRoutes:
+        kinds:
+          - group: gateway.networking.k8s.io
+            kind: TCPRoute
+---
+apiVersion: gateway.networking.k8s.io/v1
+kind: TCPRoute
+metadata:
+  name: database
+spec:
+  parentRefs:
+    - name: tcp-gateway
+      sectionName: tcp
+      port: 3306
+  rules:
+    - backendRefs:
+        - name: database
+          port: 3306
+```
+
+A `UDPRoute` segue exatamente o mesmo padrão — basta trocar `protocol: TCP` por `protocol: UDP` no listener e usar `kind: UDPRoute` (com a entrada correspondente em `allowedRoutes.kinds`) na rota.
+
+**Nota sobre depreciação:** as versões `v1alpha2` de `TCPRoute` e `UDPRoute` estão deprecadas a partir do v1.6 e serão removidas em uma release futura. Quem ainda usa `v1alpha2` deve planejar a migração para `v1`.
+
+## XBackend: um novo recurso experimental (GEP-4894)
+
+Junto com a promoção a GA, o v1.6 introduz uma nova API experimental chamada **XBackend**, um decorator de uso geral para `Service` e outros tipos de backend. Ela vive no novo grupo de API `gateway.networking.x-k8s.io/v1alpha1`.
+
+A primeira versão do `XBackend` suporta destinos `ExternalHostname` — um recurso Extended/Opcional útil para cenários de egress e workloads de IA agêntica. Como um `ExternalHostname` resolve para um endereço fora do cluster, vale lembrar da consideração de segurança conhecida como *confused deputy*: qualquer controlador que faça proxy para hostnames externos deve ser explícito sobre quais hostnames ele pode acessar.
+
+A comunidade também está trabalhando para mover a configuração de Session Persistence do `XBackendTrafficPolicy` para dentro do `XBackend`, além de adicionar suporte a retries e TLS origination.
+
+## APIs experimentais ganham grupo próprio
+
+O v1.6 também muda *como* as APIs experimentais são versionadas. Novos recursos experimentais agora vivem em um grupo de API separado, `gateway.networking.x-k8s.io`, e os nomes de seus tipos recebem o prefixo `X` — por exemplo, `XBackend` e `XMesh`. Quando um recurso passa a Standard, ele é renomeado para `gateway.networking.k8s.io` e o prefixo `X` é removido (por exemplo, `XMesh` vira `Mesh`).
+
+`TCPRoute` e `UDPRoute` foram os últimos recursos a serem promovidos sob o antigo esquema de versões (`v1alpha2` → `v1`). Daqui para frente, o grupo com prefixo `X` deixa claro de imediato quais recursos ainda são experimentais.
+
+## Conformidade: seis implementações
+
+A conformidade do Gateway API é garantida por uma suíte de testes formal, e as seis implementações a seguir eram conformes com o v1.6 no dia da publicação:
+
+- Agentgateway
+- Airlock Microgateway
+- GKE Gateway
+- kgateway
+- NGINX Gateway Fabric
+- Traefik Proxy
+
+## Experimente Você Mesmo
+
+Se quiser testar roteamento TCP ou UDP hoje, qualquer uma das implementações conformes acima é um bom ponto de partida. O projeto mantém guias de usuário para roteamento [TCP](https://gateway-api.sigs.k8s.io/guides/user-guides/tcp/) e [UDP](https://gateway-api.sigs.k8s.io/guides/user-guides/udp/), além da [documentação completa](https://gateway-api.sigs.k8s.io/) e das [notas da release v1.6.0](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v1.6.0).
+
+## Participe
+
+O Gateway API é o padrão de service networking do Kubernetes: orientado a papéis, expressivo e construído sob o SIG Network. Para participar:
+
+- Entre no canal **#sig-network-gateway-api** no [Slack do Kubernetes](https://slack.k8s.io/)
+- Acompanhe o calendário do SIG Network para as reuniões da comunidade
+- Explore e contribua com o [repositório do gateway-api](https://github.com/kubernetes-sigs/gateway-api)
+
+---
+
+Na **EF-TECH**, somos especialistas em Kubernetes, cloud computing e automação de infraestrutura. Ajudamos equipes a projetar e operar service networking moderno — incluindo o Gateway API. [Entre em contato](/pt-br/contato/) para saber como podemos ajudar sua equipe. Para mais artigos como este, visite nosso [blog](/pt-br/blog/).