<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Envoy Gateway on Maxime Moreillon</title>
    <link>https://articles.maximemoreillon.com/tags/envoy-gateway/</link>
    <description>Recent content in Envoy Gateway on Maxime Moreillon</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sun, 20 Sep 2026 00:00:00 +0900</lastBuildDate><atom:link href="https://articles.maximemoreillon.com/tags/envoy-gateway/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Exposing Envoy Gateway on ports 80 and 443 with hostPort</title>
      <link>https://articles.maximemoreillon.com/articles/envoy-gateway-hostport/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0900</pubDate>
      
      <guid>https://articles.maximemoreillon.com/articles/envoy-gateway-hostport/</guid>
      
      <description>&lt;p&gt;In &lt;a href=&#34;https://articles.maximemoreillon.com/articles/ingress-nginx-controller-to-envoy-gateway/&#34;&gt;my article on migrating to Envoy Gateway&lt;/a&gt;, I exposed Envoy through a &lt;code&gt;NodePort&lt;/code&gt; service and pointed the router&amp;rsquo;s port-forwards at the assigned ports, as a &lt;code&gt;NodePort&lt;/code&gt; cannot use the standard HTTP and HTTPS ports. Accessing apps directly on the local LAN, however, then requires specifying a non-standard port in the URL. On a single-node homelab cluster, &lt;code&gt;hostPort&lt;/code&gt; avoids this: it binds a container port directly on the node&amp;rsquo;s network interface, so the node answers on ports 80 and 443 with nothing in between. Unlike &lt;code&gt;hostNetwork&lt;/code&gt;, the pod keeps its own network namespace.&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>Nextcloud Notes re-syncing everything behind Envoy Gateway</title>
      <link>https://articles.maximemoreillon.com/articles/nextcloud-notes-envoy-gateway-header-case/</link>
      <pubDate>Sun, 20 Sep 2026 00:00:00 +0900</pubDate>
      
      <guid>https://articles.maximemoreillon.com/articles/nextcloud-notes-envoy-gateway-header-case/</guid>
      
      <description>&lt;p&gt;After &lt;a href=&#34;https://articles.maximemoreillon.com/articles/ingress-nginx-controller-to-envoy-gateway/&#34;&gt;moving from Ingress NGINX to Envoy Gateway&lt;/a&gt;, the Nextcloud Notes app on my phone started taking around 40 seconds to sync, with the loader spinning the whole time.&lt;/p&gt;
&lt;h2 id=&#34;the-problem&#34;&gt;The problem&lt;/h2&gt;
&lt;p&gt;The Envoy access log showed why: every sync downloaded the whole collection.&lt;/p&gt;
&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;GET /index.php/apps/notes/api/v1/notes?pruneBefore=0   200   4.8 MB
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;With around 5,000 notes, that is a lot of data to fetch for a sync that usually has nothing to update. According to the &lt;a href=&#34;https://github.com/nextcloud/notes/blob/main/docs/api/v1.md&#34;&gt;Notes API documentation&lt;/a&gt;, a client is supposed to send the &lt;code&gt;Last-Modified&lt;/code&gt; timestamp and the &lt;code&gt;ETag&lt;/code&gt; of the previous response, so that the server only returns what changed. Behind Ingress NGINX, this worked. Behind Envoy Gateway, &lt;code&gt;pruneBefore&lt;/code&gt; was always &lt;code&gt;0&lt;/code&gt;.&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>Retiring Oauth2-Proxy in favor of Envoy Gateway</title>
      <link>https://articles.maximemoreillon.com/articles/retiring-oauth2-proxy/</link>
      <pubDate>Fri, 18 Sep 2026 00:00:00 +0900</pubDate>
      
      <guid>https://articles.maximemoreillon.com/articles/retiring-oauth2-proxy/</guid>
      
      <description>&lt;p&gt;Oauth2-Proxy is a convenient solution to add authentication with OIDC on applications that do not ship with it natively. It integrates well with the &lt;a href=&#34;https://github.com/kubernetes/ingress-nginx&#34;&gt;Ingress NGINX controller&lt;/a&gt; but the latter is now deprecated.&lt;/p&gt;
&lt;p&gt;A replacement for Ingress NGINX is the Gateway API, a newer Kubernetes standard for traffic routing with several available implementations — &lt;a href=&#34;https://gateway.envoyproxy.io/&#34;&gt;Envoy Gateway&lt;/a&gt;, Istio, Cilium, and NGINX Gateway Fabric among them. This article uses Envoy Gateway. Since Envoy Gateway provides its own OIDC authentication, Oauth2-Proxy is no longer needed for this purpose.&lt;/p&gt;</description>
      
    </item>
    
    <item>
      <title>Migrating from Ingress NGINX Controller to Envoy Gateway</title>
      <link>https://articles.maximemoreillon.com/articles/ingress-nginx-controller-to-envoy-gateway/</link>
      <pubDate>Thu, 17 Sep 2026 00:00:00 +0900</pubDate>
      
      <guid>https://articles.maximemoreillon.com/articles/ingress-nginx-controller-to-envoy-gateway/</guid>
      
      <description>&lt;p&gt;As the &lt;a href=&#34;https://github.com/kubernetes/ingress-nginx&#34;&gt;Ingress NGINX controller&lt;/a&gt; is now deprecated, replacing it with the Gateway API is in order. The Gateway API is a newer Kubernetes standard for traffic routing with several available implementations — &lt;a href=&#34;https://gateway.envoyproxy.io/&#34;&gt;Envoy Gateway&lt;/a&gt;, Istio, Cilium, and NGINX Gateway Fabric among them. Here, I have chosen Envoy Gateway as it is backed by the CNCF and provides all needed features, including native OIDC authentication, which removes the need for Oauth2-Proxy (see &lt;a href=&#34;https://articles.maximemoreillon.com/articles/retiring-oauth2-proxy/&#34;&gt;this article&lt;/a&gt;).&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
