<p>I have a single node kubernetes deployment running on a home server, on which I have several services running. Since it's a small local network, I wanted to block off a portion of the local address range that the rest of my devices use for pod ips, and then route to them directly.</p>

<p>For example, if I have a web server running, instead of exposing port 80 as an external port and port forwarding from my router to the worker node, I would be able to port forward directly to the pod ip.</p>

<p>I haven't had much luck finding information on how to do this though, is it possible? </p>

<p>I'm new to kubernetes so I am sure I am leaving out important information, please let me know so I can update the question.</p>

<hr>

<p>I got this working by using the macvlan CNI plugin from the <a href="https://github.com/containernetworking/cni" rel="nofollow noreferrer">reference plugins</a>. Using kubeadm to set up the cluster, these plugins are already installed and the cluster will be configured to use them. The only thing to do is drop in a cni.conf (in <code>/etc/cni/net.d</code>). Mine looks like this </p>

<pre><code>{
    "name": "net",
    "type": "macvlan",
    "mode": "bridge",
    "master": "eno1",
    "ipam": {
        "type": "host-local",
        "ranges": [[{ 
            "subnet": "10.0.0.0/8",
            "gateway": "10.0.0.1",
            "rangeStart": "10.0.10.2",
            "rangeEnd": "10.0.10.254" 
        }]],
        "routes": [
            { "dst": "0.0.0.0/0" }
        ]
    }
}
</code></pre>

<p>Putting this in place is all that is needed for coredns to start up and any pods you run will have ips from the range defined in the config. Since this is on the same subnet as the rest of my lan, I can freely ping these containers and my router even lets me play with their settings since they have mac addresses (if you dont want this use ipvlan instead of macvlan, you'll still be able to ping and port forward and everything, your router just wont be enumerating all the devices since they dont have hardware addresses). </p>

<p>Couple of caveats:</p>

<ol>
<li><p>Services won't work since they're all "fake" (e.g. they dont have interfaces its all iptables magic that makes them work). There's probably a way to make them work but it wasn't worth it for my use case</p></li>
<li><p>For whatever reason the DNS server keeps revering to 10.96.0.1. I have no idea where it got that address from, but I have been working around it by defining <code>dnsPolicy: None</code> and setting <code>dnsConfig.nameservers[0]</code> to my routers IP. There's probably a better solution for for it.</p></li>
<li><p>You should run kubeadm with <code>--service-cidr 10.0.10.0/24 --pod-network-cidr 10.0.10.0/24</code> or it seems like kubelet (or something) doesn't know how to talk to the pods. I actually don't know if <code>--service-cidr</code> matters but it seems like a good idea</p></li>
<li><p>Out of the box, your pods wont be able to talk to the master since they are using macvlan devices enslaving its ethernet and for whatever reason macvlan doesn't let you talk between host and guest devices. As you can imagine this isnt a good thing. Solution is to manually add a macvlan device on the host with the same subnet as your pods.</p></li>
<li><p>It seems like even ports you don't expose from the pod are usable from the lan devices (which isnt cool), probably since the iptables rules think that anything on the lan is cluster-internal. I haven't put much time into debugging this.</p></li>
</ol>

<p>This is probably some kind of cardinal sin for people used to using kubernetes in production, but its kind of cool and useful for a home setup, though it certainly feels like a hack sometimes.   </p>

<p>I believe the answer to your question is to use the <a href="https://github.com/containernetworking/plugins#ipam-ip-address-allocation" rel="nofollow noreferrer">dhcp IPAM</a> plugin to <a href="https://github.com/containernetworking/cni#readme" rel="nofollow noreferrer">CNI</a>, but being mindful about Pod address recycling. I say be mindful because it <em>might not</em> matter, unless you have high frequency Pod termination, but on the other hand I'm not sure where it falls on the Well That's Unfortunate™ spectrum if a Pod IP is recycled in the cluster.</p>

<p>The bad news is that I have not had any experience with these alternative CNI plugins to be able to speak to the sharp edges one will need to be mindful of, so hopefully if someone else has then they can chime in.</p>
