<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gateway-Api on brtkwr.com</title><link>https://brtkwr.com/tags/gateway-api/</link><description>Recent content in Gateway-Api on brtkwr.com</description><generator>Hugo</generator><language>en</language><lastBuildDate>Thu, 28 May 2026 10:00:00 +0000</lastBuildDate><atom:link href="https://brtkwr.com/tags/gateway-api/index.xml" rel="self" type="application/rss+xml"/><item><title>When cert-manager can't help: GKE Gateway and Google Certificate Manager</title><link>https://brtkwr.com/posts/2026-05-28-cert-manager-vs-google-certificate-manager-for-gke-gateway/</link><pubDate>Thu, 28 May 2026 10:00:00 +0000</pubDate><guid>https://brtkwr.com/posts/2026-05-28-cert-manager-vs-google-certificate-manager-for-gke-gateway/</guid><description>&lt;h2 id="tldr">
 TL;DR
 &lt;a class="heading-link" href="#tldr">
 &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading">&lt;/i>
 &lt;span class="sr-only">Link to heading&lt;/span>
 &lt;/a>
&lt;/h2>
&lt;p>I had a Kubernetes service exposed via two different gateway flavours on different clusters. Two of them used an istio &lt;code>Gateway&lt;/code> with TLS terminated in-pod, where cert-manager handed it a wildcard cert via a regular &lt;code>Secret&lt;/code>. The third used a GKE-managed &lt;code>Gateway&lt;/code> (&lt;code>gatewayClassName: gke-l7-global-external-managed&lt;/code>), where TLS terminates at a Google Cloud Load Balancer that does not read Kubernetes Secrets. For that one I had to use Google Certificate Manager with a DNS-01 authorisation, then point the Gateway at the resulting cert map via a &lt;code>networking.gke.io/certmap&lt;/code> annotation. cert-manager does not fit this path.&lt;/p></description></item></channel></rss>