<p dir="auto">If it is happening now, it will happen again.</p>
<h2 dir="auto">Motivation</h2>
<p dir="auto">If I was setting up frontend infrastructure on kube, I might do something like this:</p>
<div class="snippet-clipboard-content notranslate position-relative overflow-auto" data-snippet-clipboard-copy-content="L1 [ Ingress ]  service state     &lt;- |
    |                                | per service Dos policy
(certs, geo)  --- (hostname, ip) --- [dos engine]
    | 
L2 [ Services ]  endpoint state
    | 
(enforces routing rules)
    | 
endpoints (produce web page)"><pre class="notranslate"><code class="notranslate">L1 [ Ingress ]  service state     &lt;- |
    |                                | per service Dos policy
(certs, geo)  --- (hostname, ip) --- [dos engine]
    | 
L2 [ Services ]  endpoint state
    | 
(enforces routing rules)
    | 
endpoints (produce web page)
</code></pre></div>
<p dir="auto">Today, there's only 1 routing rule at the Service layer (rr to all endpoints), and 1 routing rule at the ingress layer (http hostname, path prefix match). This is insufficent to express more complex group membership patterns we see in PetSet (leader election, broadcast) and common routing patterns observed in tiered applications (retry GET, traffic splitting, consistent hashing to memcache farm).</p>
<h2 dir="auto">Proposal</h2>
<p dir="auto">Add a new <code class="notranslate">RoutingRule</code> subtype and embed it either in the Ingress or Service. The subtype would implement rules like:</p>
<ol dir="auto">
<li>Leader (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="44716132" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/1542" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/1542/hovercard" href="https://github.com/kubernetes/kubernetes/issues/1542">#1542</a>, <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="91528665" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/10456" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/10456/hovercard" href="https://github.com/kubernetes/kubernetes/issues/10456">#10456</a>)</li>
<li>Broadcast (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="98217521" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/12026" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/12026/hovercard" href="https://github.com/kubernetes/kubernetes/issues/12026">#12026</a>)</li>
<li>Failover on error (It's been asked for before, can't find issue)</li>
<li>Hash based on incoming request or backend server (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="79745792" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/8731" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/8731/hovercard" href="https://github.com/kubernetes/kubernetes/issues/8731">#8731</a>)</li>
<li>Canary (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="154284964" data-permission-text="Title is private" data-url="https://github.com/kubernetes/kubernetes/issues/25485" data-hovercard-type="issue" data-hovercard-url="/kubernetes/kubernetes/issues/25485/hovercard" href="https://github.com/kubernetes/kubernetes/issues/25485">#25485</a>)</li>
<li>Vanilla lb algorithms</li>
</ol>
<p dir="auto">I'd like L2 in the diagram above to implement the rules, because storing all endpoints at L1 might not be practical. In my mind L1 is the layer you can duplicate across the globe and use at the edge of your network, or even  in someone elses DC.</p>
<p dir="auto">I can't decide what L2 is, I'm tempted to say it's a Service but:</p>
<ul dir="auto">
<li>sticky session and lb algorithms are common at L1 and L2</li>
<li>Services don't understand l7</li>
<li>The most obvious way to implement a majority of the routing rules is through a webserver</li>
<li>Ties in with the "internal ingress" concept</li>
<li>Service is no longer a simple intra-cluster, low latency "dumb" routing abstraction</li>
</ul>
<p dir="auto"><a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/smarterclayton/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/smarterclayton">@smarterclayton</a> <a class="user-mention notranslate" data-hovercard-type="user" data-hovercard-url="/users/thockin/hovercard" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/thockin">@thockin</a> @kubernetes/sig-network (we need a @kubernetes/lb)</p>