This is my story and I'm sticking to it.
Now that I’m handing out IPv6 addresses to various VLANs on my network, I needed a way to see what percentage of my traffic was actually using IPv6. Enter pf, pflow, and ntop. pf is used by my router/firewall to process packets, and mark them for pflow processing. pflow is a psuedo device on the router/fw which exports pflow accounting data to a remote collector. ntop (and nprobe) is a collector and visualization application for digging into packet statistics.
It all started with a Ubuntu Blog blog post about a slimmer Ubuntu server image. I play around with virtual machines at home, many based on Ubuntu’s full-size server ISO. It would take 20-25 minutes to spin up a new VM using some prebuilt preseed files I had constructed to automate user creation and SSH key copying. I knew there was a better way, and it turns out, using the pre-built Ubuntu minimal image (subsequently called cloud image), combined with cloud-init infrastructure, I was able to spin up Ubuntu Cloud Image minimal VMs in under 2 minutes.
I remember using he.net year ago for their IPv6 tunnels years ago, and have painful memories of configuring it, both on the router and to share to the subnets on my home LAN. Not this time. Years ago, I had Comcast Business Internet service, which along with providing a static IPv4 address, provided IPv6 connectivity. Not only just a single /128, but a whole /56 if you asked for it. After spending days/weeks configuring both dhcp client and servers for prefix delegation, and slaac/rtadvd to hand out addresses to my various LAN segments, I was in business.
Kubernetes has some incredible features, one of them being Ingress. Ingress can be described as a way to give external access to a Kubernetes-run service, typically over HTTP(S). This is useful when you run webapps (Grafana, Binder) in your Kubernetes cluster that need to be accessed by users across your network. Typically, Ingress integrates with automation provided by public cloud providers like GCP/GKE, AWS, Azure, Digital Ocean, etc where the external IP and routing is done for you.
Several months after my last post, and lots of code hacking, I can rebuild CoreOS-based bare-metal Kubernetes cluster in roughly 20 minutes. It only took ~1300 lines of Python following Kelsey Hightower’s Kubernetes the Hard Way instructions. Why? The challenge. But really, why? I like to hack on code at home, and spinning up a new VM for another Django or Golang app was pretty heavyweight, when all I needed was an easy way to push it out via container.
It had been several months since I was away from my machines at home, and in that time, CoreOS changed their bare-metal installation procedures quite a bit. To the point where it almost seemed like an after-thought that folks would run CoreOS anywhere outside of GCE/AWS/Azure. Being that I don’t want to spend my money on cloud-based infrastructure when I’ve got a perfectly adequate 8-core machine at home with 32GB of ram and a few TB of storage, I knew I needed to update my virthelper scripts to get with the program.
I finally got around to wiring Cat6 to my desktop machines at home, and ripped out those powerline network adapters. I ran a test if iperf between my desktop and my router before and after the upgrade to see how things fared. iperf results before: desktop1:~$ iperf -f m -V -t 30 -c 10.10.0.1 ------------------------------------------------------------ Client connecting to 10.10.0.1, TCP port 5001 TCP window size: 0.08 MByte (default) ------------------------------------------------------------ [3] local 10.
I’d like to (try to) keep a running tab of all the technical, and non-technical, bits of information I pick up day to day. I’m hoping it might provide some insight into what I’m interested at the time, or little tidbits of helpful information I find laying around the web. Pain(less) NGINX Ingress Once I get my Kubernetes cluster back up at home, I want to create separate environments for promotions.
Step One: Build the CoreOS cluster. Step Two: Install Kubernetes Step 3: Configure Addons Step 4: Set up Ingress Things I learned It all started when I began hearing about this container thing outside of work. I’ve been a Google SRE going on 6 years, but knowing that the way we do containers internally on Borg is probably not how the rest of the world does reliable, scalable, infrastructure.
A while back, I wrote a post about setting up an L2TP/IPSec VPN on my home firewall/router. It required two daemons and a bunch of configuration that had hard coded IP addresses. While this solution used firmly-established practices (L2TP/IPSec), it felt too brittle. What happens when my dynamic IP address changes? Now I need to update config files, restart daemons, etc. There had to be a better way. Enter IKEv2. IKEv2 is a successor implementation to Internet Security Association and Key Management Protocol (ISAKMP)/Oakley, IKE version 1.