Welcome to Technology Short Take #126! I meant to get this published last Friday, but completely forgot. So, I added a couple more links and instead have it ready for you today. I don’t have any links for servers/hardware or security in today’s Short Take, but hopefully there’s enough linked content in the other sections that you’ll still find something useful. Enjoy!

Networking

• Here’s a primer on hot potato routing vs. cold potato routing. ‘Nuff said.
• This isn’t necessarily networking-related, but it does pertain to a very well-known content creator who specializes in networking. Ivan Pepelnjak recently announced that he’s migrated his site over to Hugo.
• Andreas Wittig takes a look at some advanced AWS networking pitfalls to avoid.
• Josh VanDeraa shows how to use Netmiko, NTC-Templates, Telegraf, Prometheus, and Grafana for monitoring VPN infrastructure (a more critical piece of infrastructure these days given all the remote work going on).
• James McClay has a post talking about the use of BIND9 on Ubuntu 18.04 in an OSPF-routed lab topology using Cisco IOSv and Free Range Routing (FRR).

Servers/Hardware

Nothing this time around!

Security

I don’t have anything to include this time, but I’ll stay alert for content I can include next time.

Cloud Computing/Cloud Management

• Caleb Lloyd discusses how he believes CustomResourceDefinitions (CRDs) are responsible for Google removing the free control plane for GKE clusters.
• My colleague Dustin Scott has a post up on his new blog that takes readers through the process of provisioning an air-gapped Kubernetes cluster using Cluster API for vSphere (CAPV). Dustin has done a good job of including some useful details in this post.
• I recently stumbled across this regular list of AWS open source news and updates by Ricardo Sueiras.
• Steven Wade tackles the challenge of staying ahead of Kubernetes API deprecations, leveraging conftest and Rego policies.
• Alastair Cooke’s post regarding no VMotion on AWS initially struck me as simplistic, but after reading it a second time I caught the deeper meaning that I think Alastair was trying to get across. It is summed up, for me, in this quote: “The crucial architectural difference here is that vSphere wants us to stop thinking about individual physical servers, and AWS wants us to stop thinking about individual VMs.” It’s not just about VMotion; it’s about the bigger architectural shifts that need to be made.
• Matt Bagnara, another colleague on my team, recently wrote a post on Jenkins X on Kubernetes (with a little Cluster API thrown in).
• William Lam has a list of useful interactive and graphical UI tools for Kubernetes.
• Nick Korte chronicles a newcomer’s voyage into Azure Functions and Function Apps.
• Joe Duffy recently wrote a post on Pulumi’s new “policy as code” functionality (which was experimental before the Pulumi 2.0 launch today) and using that for enforcing tagging on AWS resources.
• Romain Decker joins the static site club, and has started a four-part series on how he hosts his Hugo-powered site on AWS with S3, CloudFront, and Lambda. Only two posts are live so far (part 1 and part 2), but this is shaping up to be a great series.

Operating Systems/Applications

• Josh Reichardt shows readers a neat trick for making shell scripts idempotent using Terraform. I also really liked his post on text processing tools.
• Cody De Arkland exposes the anatomy of his macOS terminal.
• Brice Dereims gives a walkthrough of using Code Stream for continuous deployment.
• Bryan Culver explains how to use a monorepo (a repository containing multiple applications/services) of Docker images with make and GitHub Actions.
• Simon Bernier St-Pierre talks about kubie, a tool created to—in Simon’s words—“improve my day to day life at work”. Basically, it’s a companion to kubectl that helps manage Kubernetes contexts, but in a different way than more well-known tools like kubectx. Personally, I prefer ktx.
• Rahul Joshi has a four-part series on “Docker for Noobs” (start here with part 1; the other parts in the series are linked from there).
• Vincent Bernat talks about safer SSH agent forwarding.

Storage

• Cody Hosterman, of Pure Storage, takes a look at Pure Storage’s support of the recently-released vSphere 7.
• Chris Mellor reports on something of a “scandal” wherein Western Digital is selling drives that use shingled magnetic recording (SMR) in use cases where that technology can cause noticeable performance problems.

Virtualization

• Frank Denneman follows-up his post on initial placement of vSphere Pods with an article on scheduling vSphere Pods (the link to the initial placement article was in Technology Short Take 125).
• Stijn Vermoesen describes what’s involved in installing the vRealize Build Tools fling (part 1 and part 2).

Career/Soft Skills

• I recently learned about the Johari window, an aid for understanding the self. It got me thinking about what my blind spots might be.

That’s all for now. If you have questions, comments, or suggestions for how I can improve the Technology Short Take series (or this site in general), I welcome all feedback. Feel free to contact me on Twitter, hit me up in any one of a number of Slack channels (Kubernetes, CNCF, Pulumi, to name a few), or drop me an e-mail (my address isn’t too hard to find).

…

Read MoreTechnology Short Take 126

News

Bobby Hellard

Move is designed to target customers in highly-regulated industries

…

Read MoreSlack brings data residency to the UK

News

Sabina Weston

Political ad restrictions will be expanded across the board after a rise in coronavirus-related scams

…

Read MoreGoogle says all advertisers will now be subject to verification checks

I’ve written a few different posts on setting up etcd. There’s this one on bootstrapping a TLS-secured etcd cluster with kubeadm, and there’s this one about using kubeadm to run an etcd cluster as static Pods. There’s also this one about using kubeadm to run etcd with containerd. In this article, I’ll provide yet another way of setting up a “best practices” etcd cluster, this time using a tool named etcdadm.

etcdadm is an open source project, originally started by Platform9 (here’s the blog post announcing the project being open sourced). As the README in the GitHub repository mentions, the user experience for etcdadm “is inspired by kubeadm.”

Getting etcdadm

The instructions in the repository indicate that you can use go get -u sigs.k8s.io/etcdadm, but I ran into problems with that approach (using Go 1.14). At the suggestion of the one of the maintainers, I also tried Go 1.12, but it failed both on my main Ubuntu laptop as well as on a clean Ubuntu VM. However, running make etcdadm in a clone of the repository worked, and one of the maintainers indicated the documentation will be updated to reflect this approach instead. So, for now, it would appear that cloning the GitHub repository and running make etcdadm is your best approach for obtaining a binary build of the tool.

Setting up an Etcd Cluster

Once you have a binary build of etcdadm, the process for setting up an etcd cluster is—as the documentation in the repository indicates—pretty straightforward.

1. First, copy the etcdadm binary to the system(s) that will comprise the cluster.

2. On the system that will be the first node in the cluster, run etcdadm init. This will create a certificate authority (CA) for the TLS certs, then use that CA to create TLS certificates for the etcd node. Finally, it will bootstrap the etcd cluster with one only member, itself, and then will output a command to run on subsequent nodes. The command will look something like etcdadm join https://10.11.12.13:2379.

   As part of the bootstrapping process, etcdadm will install the etcd and etcdctl binaries (the default location is into /opt/bin), and will create a systemd unit to run etcd as a service. You can use systemctl to check the status of the etcd unit, and you can use etcdctl to check the health of the cluster (among other things).

3. Copy the CA certificate and key from the first node to the next node you’re going to add to the cluster. The CA certificate and key are found as /etc/etcd/pki/ca.crt and /etc/etcd/pki/ca.key, respectively. Place these files in the same location on the next node, then run the command output by etcdadm init in the previous step.

4. Repeat step 3 for each additional node you add to the cluster, keeping in mind you should use odd numbers of nodes in the cluster. Generally speaking, a cluster of 3 nodes will work just fine in the vast majority of cases.

Once you’ve added the desired number of nodes to the etcd cluster, you can use this etcdctl command to check the health of the cluster:

ETCDCTL_API=3 /opt/bin/etcdctl --cert /etc/etcd/pki/peer.crt \
--key /etc/etcd/pki/peer.key --cacert /etc/etcd/pki/ca.crt \
--endpoints https://10.45.88.87:2379 endpoint health --cluster

Assuming you get healthy responses to the above command, you’re good to go. Pretty easy, right? This is why I tweeted earlier today that I think there is real promise in this tool.

How I Tested

To test etcdadm, I first used Vagrant to spin up an Ubuntu 18.04 VM for building the etcdadm binary. After I had the binary, I used Pulumi to launch three AWS EC2 instances in their own VPC. I then used these instances to test the process of bootstrapping the etcd cluster using etcdadm.

While etcdadm is still an early project, I would recommend keeping an eye on its development. In the meantime, I’d love to hear any feedback from you, so feel free to find me on Twitter or hit me up on the Kubernetes Slack instance.

…

Read MoreSetting up etcd with etcdadm