Using Mitmproxy to Observe kubectl Traffic

When I first started learning Kubernetes, I had the idea that observing the network traffic between a client system using kubectl and the Kubernetes API Server would be a useful thing to do. The source of the idea is unclear; I am unsure why I thought this would be useful as a learning tool. Regardless, I continued on with learning Kubernetes and never really pursued this idea—until this week. I found it can be a useful troubleshooting technique, but I will leave it up to you to determine if it is a useful learning technique. In this post, I will show you how to observe kubectl traffic using mitmproxy.

This technique is inspired by/informed by Ahmet Alp Balkan’s similarly-named blog post from 2019. Unfortunately, I found the instructions there to be incomplete (most likely just due to the passage of time and continued evolution of the tools involved).

I used the following tools and environments in my testing:

• The tests were conducted on a Linux system running Ubuntu 24.04.4. The commands should work similarly on macOS.
• Mitmproxy was installed from the Ubuntu repositories using apt.
• kubectl version 1.33.3 was used to communicate to a self-managed cluster on AWS (in other words, not Amazon EKS) running Kubernetes 1.32.9. The cluster was bootstrapped using kubeadm. I wouldn’t expect any major/significant differences with other versions of kubectl or Kubernetes.
• I was using a client certificate to authenticate to Kubernetes. It’s unclear to me how this might work—if it works at all—with alternate authentication mechanisms.

Prepare Client Certificates

Before you can start mitmproxy, you’ll first need to extract the client certificates from the Kubeconfig file. A couple of ways exist to do this; a blog post of mine from 2022 contains what I believe is the easiest way. The method involves yq (to extract information from the Kubeconfig) and base64 (to decode the client certificate and client key). Refer to the linked blog post for full details.

1. First, extract the client certificate (adjust the users[0] as needed based on the Kubeconfig file):

   yq '.users[0].user.client-certificate-data' < kubeconfig | base64 -d >> client-cert.pem
   

2. Next, extract the client key:

   yq 'users[0].user.client-key-data'< kubeconfig | base64 -d >> client-cert.pem
   

Running Mitmproxy and Watching Traffic

Now that you have the client certificate and key in hand, you’re ready to launch mitmproxy and observe some traffic. Mitmproxy requires a few specific configuration flags for this use case:

• You’ll need to disable HTTP/2 support with --set http2=false.
• Mitmproxy must be configured with the client certificate you extracted above (using --set client_certs=client-cert.pem).
• In this particular case, since the cluster CA isn’t trusted, mitmproxy also has to be told not to verify the upstream certificate with --set ssl_insecure=true.

Putting all this together, the full command looks like this:

mitmproxy -p 5000 --set ssl_insecure=true --set http2=false --set client_certs=client-cert.pem

Then, in a separate window, run your kubectl command:

HTTPS_PROXY=:5000 kubectl get po -A --insecure-skip-tls-verify

You should see the traffic pop up in the window running mitmproxy, and can review the traffic flow(s) in detail.

As explanation: the HTTPS_PROXY part redirects traffic through the instance of mitmproxy you just launched, and --insecure-skip-tls-verify tells kubectl not to verify the upstream certificate—which it can’t do because it’s seeing mitmproxy’s certificate, not the cluster’s certificate.

There you go—now you can observe traffic between kubectl and the Kubernetes API server. As I mentioned at the start of this post, this technique is useful for troubleshooting. I did not find it useful as a learning tool, but others might.

I hope you find this useful. Thanks to Ahmet for setting me down the right path! If you have questions, feel free to reach out. I’m available on social platforms (X/Twitter, Mastodon, Bluesky, and LinkedIn), or you can drop me an email. I’d be happy to help if I’m able.

Running the Azure CLI in a Container

Like perhaps some readers, I am quite particular about what gets installed on my systems. I try to keep my systems as “clean” as possible, doing my best to avoid tools that have an extensive list of dependencies that must be installed and updated. Where that isn’t possible—such as with the Azure CLI, which has a massive number of Python modules that are required in order for the tool to function—I will use various isolation mechanisms. For the Azure CLI, that’s typically been a Python virtual environment. Somewhat recently, though, I had an idea to try using a container. In this post, I’ll share what worked and what did not work when trying to run the Azure CLI in a container.

First, though, a disclaimer: I am not an Azure expert, nor am I a Python expert. I know enough to get by. If I share something here that’s incorrect, please contact me and constructively show me my errors so that I can fix them.

Before I started down this path, I was sure this would be a slam dunk. I mean, this is what containers are for, right? If you do some web searches for running the Azure CLI in a container, you’ll find articles that give you this command line:

docker run -it mcr.microsoft.com/azure-cli

(Note that this assumes you are using Docker instead of something like Podman.)

This does work, as long as you’re willing to operate in an interactive shell in the container. I was looking for something a bit different: I wanted to create an alias for az that executed the container in my current shell instead of putting me into a separate shell inside the container. Something like this, for example:

alias az="docker container run --rm mcr.microsoft.com/azure-cli az"

I quickly found that you need to map in your Azure configuration directory from outside the container, or your configuration won’t persist. (In theory you could remove the --rm parameter and keep the container around.) Now the docker command in your alias starts to look like this:

docker container run --rm -v ${HOME}/.azure:/root/.azure mcr.microsoft.com/azure-cli az

Oh, you need access to your SSH keys? You’ll have to map those in, too:

docker container run --rm -v ${HOME}/.azure:/root/.azure \
-v ${HOME}/.ssh:/root/.ssh mcr.microsoft.com/azure-cli az

Except that then I remember that I am running as root in the container, and so any files created by the Azure CLI will be owned as root outside the container, too. No worries; I’ll just run it as a different user ID. Unfortunately, that involves building and maintaining my own container image to specify that the Azure CLI should run as something other than root. At this point, you’ll likely come to the same conclusion I did, and decide that a Python virtual environment is fine.

I was about to classify this experiment as “Death by a Thousand Cuts”, because every time I turned around I was finding some annoyance or blocker caused by Docker and containers. And then I remembered Distrobox.

Distrobox uses a container, but the container is “tightly integrated” with the host. For example, a Distrobox container shares the home directory of the user. For this use case, this makes the situation appreciably simpler—I no longer need to map in volumes for the Azure configuration or for my SSH keys.

Getting this working with Distrobox was only a few steps:

1. Create a new Distrobox container (I chose to use Debian 13):

   distrobox create -n azcli -i debian:13
   

2. Enter the new container with distrobox enter azcli and install a few tools. (This is one oddity of Distrobox: it will use the ~/.bashrc from your host, which may references tools that don’t exist in the container. In my situation, I needed to install Starship and a few command-line tools.)

3. Install the Azure CLI in the Distrobox container by following the Linux installation instructions. (One side note here: I chose Debian 13, but technically Debian 13 isn’t yet supported.)

4. In the Distrobox container, export the Azure CLI so it is accessible from the host system:

   distrobox-export -b /usr/bin/az
   

If you omit step 4, then you are sort of back to where I was earlier in this article—you’ll enter the Distrobox container and run the az commands from a separate shell. However, once you complete step 4 (which is done from within the Distrobox container), then on the host you will run az. That’s it! All of the files, all the dependencies, etc., are all stored in the Distrobox container. Your system remains “clean.”

Wrapping Up and Additional Resources

After trying to use a “standard” Docker container, I was convinced that trying to run the Azure CLI in a container was more work than just falling back to a plain old Python virtual environment. With Distrobox, though, it’s a piece of cake! Just create the Distrobox container, install the Azure CLI, export it, and you’re done.

I hope you’ve found this article helpful. I encourage you to check out Distrobox, either via the Distrobox web site or via the GitHub repository. Feel free to find me online (X/Twitter, Mastodon, Bluesky, or LinkedIn) and let me know what sort of cool things you end up doing with Distrobox!

Technology Short Take 191

Welcome to Technology Short Take #191! This is my semi-regular collection of links related to technology disciplines, including networking, security, cloud computing, storage, and programming/development. I hope that I’ve managed to curate an interesting and useful set of links for readers. Enjoy!

Networking

• I learned a new acronym from Ivan Pepelnjak in his article on “not so passive” OPSFv2 interfaces in Cisco IOS/XR: QDS (Quick and Dirty Solution). I am totally using that from now on.
• Via Ivan (hat tip to my colleague Russ for pointing me in this direction), I also learned that all is not well in network automation land with Ansible. Although some parts of it are apparently now resolved, this does raise questions about the viability of Ansible for network automation.
• Doug Dawson talks about the new Amazon Eero Signal, a cellular backup to a primary broadband connection for users using their Eero mesh systems. I agree with Doug—the pricing seems high to me. I generally like the Eero devices, although there have been times when I really could use a bit more control over the settings.

Security

• The APNIC blog features a guest article discussing the use of tunneling protocols to infiltrate networks. The article specifically discusses Generic Routing Encapsulation (GRE) and Virtual Extensible LAN (VXLAN). It’s worth a read if your network uses either of these technologies.

Cloud Computing/Cloud Management

• Somewhere along the way I missed the CDK deprecation announcement. If I am not mistaken, this leaves Pulumi as the only cloud-independent IaC tool that lets you use a general purpose programming language.
• Managing dependencies between containers can be difficult at times; this blog post by Nicolas Fränkel introduced me to wait4x, a tool one can use to help simplify these types of situations.

Operating Systems/Applications

• I appreciated reading Mitchell Hashimoto’s AI adoption journey. I feel it does provide a more realistic approach to how someone in a role like his might leverage an LLM or coding agent.
• Michael Christofides taught me about bloat in this article on read efficiency issues in Postgres queries.
• Ricardo Katz discusses a few somewhat-recent security vulnerabilities in kgateway, an open source Gateway API implementation that leverages Envoy Proxy.
• I am squarely in agreement with Martin Fowler on the topic of agentic email—this seems like a dangerous combination, so tread carefully. (I am squarely in disagreement with Martin’s characterization of servant leadership as gaslighting, but that’s another topic for another day.)
• You know AI has gone too far when you find it has “continvoucly morged” your content.
• Earlier this week I stumbled across hazelnut, a terminal-based file organizer for Linux systems. The macOS app Hazel inspired hazelnut. Neat!

Programming/Development

• Tuan Nguyen’s article on parsing a YAML file in Golang was helpful for me recently. I had struggled with how to do this without a struct, and the article provides a couple of examples of using a map instead of a struct for this purpose.
• Simon Willison is starting to write about agentic engineering patterns—that is, patterns for software engineering when working with agents.

Virtualization

• Lightweight Linux VMs (sometimes called “micro-VMs”) are gaining in popularity. Deno recently introduced Deno Sandbox, built on lightweight Linux VMs, to provide code security for untrusted code.
• William Lam provides some information on using cross-vCenter vMotion to help with migrating away from vSphere 7 (which is now reached end of support).
• Who out there is messing around with Incus? I am considering trying it out.
• I noticed this past week that you can now use nested virtualization to run hypervisors on “regular” EC2 instances.

Career/Soft Skills

• Tom Hollingsworth writes about managing your attention, which is something I’m increasingly seeing. I spoke about this some time ago when I advised folks to turn off new email notifications and switch to checking your email less frequently so you could focus on getting work done.
• I also saw this post by Scott H Young about managing your energy instead of your time, which—to me, at least—relates to Tom’s post in the previous bullet. In the follow-up post explaining what energy is, Young (or one of the linked articles/studies) refers to energy as a “mental resource.” It seems to me, as an uneducated layman, that managing your energy levels would also entail managing the cognitive zap you get from constant context switches due to notifications. I could be wrong (it wouldn’t be the first time, nor will it be the last).
• One final thought in this thread: Scott Young’s article on how to make hard work feel less hard talks about making tasks less effortful. This sounds a lot like “reducing the friction” for common tasks, which I have discussed in the past (here is one example). Friction is something that Murat Demirbas has also recently discussed, although his example is more organizational than personal. Either way, the concept of friction in our work is definitely a valid concept, and something we should take into account as we work toward managing both our attention and our energy.

That’s all for now. I will return in a couple of weeks with the next installation, and a fresh set of links from around the internet. In the meantime, I invite you to drop me a line (my email is not hard to find) or hit me up on social media (X/Twitter, Mastodon, Bluesky, or LinkedIn) and let me know if you’ve found something useful. I love to hear from readers!

Technology Short Take 190

Welcome to Technology Short Take #190! This is the first Tech Short Take of 2026, and it has been nearly three months (wow!) since the last one. I can’t argue that I fell off the blogging bandwagon over the end of 2025 and early 2026. I won’t get into all the reasons why (if you’re interested then feel free to reach out and I’ll fill you in). Enough about me—let’s get to the technical content! Here’s hoping you find something useful.

Networking

• Here’s a little something on the lighter side about what causes network outages.
• As the lead-in to this article on Starlink’s performance during a solar superstorm says, “It’s not science fiction.” Solar storms can have a real impact on Earth, and satellites in low-Earth orbit (LEO) are not exempt from that impact.

Servers/Hardware

• William Lam reviews the Mini PC and SFF (small form factor) hardware announcements from CES 2026.

Security

• The scale of DDoS attacks continues to grow, as evidenced by this report of a 15 Tbps attack on Microsoft Azure.
• Microsoft having the ability to give away your Windows PC’s data encryption key is horrifying.

Cloud Computing/Cloud Management

• While doing some reading on Terragrunt, I also came across this open source tool for performing operations against multiple Git repositories. I don’t have a use case for it, but it is cool!
• While on the topic of Terragrunt: let me say that I appreciate the work that went into their online docs! From what I’ve read so far, they are well-written, clear, concise, and informative. Well done!
• And while still on the topic of Terragrunt: it was this article from Axel Mendoza on why they use Terragrunt over Terraform/OpenTofu that sent me down the Terragrunt rabbit hole.
• The most recent installation of Ricardo Sueiras’ AWS open source newsletter pointed me to a couple of tools that look really handy: s3sh (available from GitHub) and taws (also available from GitHub).
• Nick Buraglio has a great comparison of hosted email options.

Operating Systems/Applications

• Howard Oakley’s “loss of confidence” in macOS is one reason why I started using Linux more. I just kept finding things in macOS that didn’t work like they should, which was made worse by the fact that Apple (the company) just doesn’t seem to care.
• It is still kind of raw, but I found a Markdown preview tool for Linux called Inlyne. Pretty cool! I am looking forward to seeing how it develops.
• This treatise from Mike Swanson on “backseat software” is absolute gold. Go read it. Now. Seriously, this is good stuff. I was nodding so vigorously as I was reading it that I almost gave myself a headache!

Storage

• Looking for some information on vSAN Encryption in VMware Cloud Foundation? I think Eric Sloof has exactly the document you need. (You may also find this related article from Eric useful as well.)

Virtualization

• Eric Sloof writes about the evolution of the VCDX. As an early VCDX (number 39), I am of two minds regarding this change. On one hand, it makes sense; they need more than just architects to pursue this certification. On the other hand, they are (in some ways) “softening” the certification. It will be interesting to see if this helps the designation grow, or if it continues to fade into obscurity.

Career/Soft Skills

• Murat Demirbas talks a bit about momentum, and how maintaining momentum (the “the messy daily pushes” as he puts it) should be how you organize and structure your workflows. I can see his point, certainly, although I would warn folks against interpreting his “produce something every day” advice as meaning that you need to publish something every day. That path leads to burn out. Produce something, sure, but allow for that something to be something that only you’ll see.
• This article about getting better at technical writing contains some good guidelines.
• This discussion of feeling uncomfortable and how it relates to growing personally really resonated with me. No, not because of Werner’s fear of public speaking; rather, it was about how it is necessary to move outside of your comfort zone in order to grow. I am getting ready to potentially embark on something that really pushes me outside my comfort zone, and it is scary. I also know, though, that it is the only way to grow.

That’s all, folks! (Bonus points for you if you recognize that reference.) I am always up to hear from readers, so I invite you to reach out using various social media platforms (X/Twitter, Mastodon, Bluesky, LinkedIn), Slack, or old-fashioned email. Thanks for reading!

Setting up a VPC Route Server with Pulumi

If you need to work with BGP in your AWS VPCs—so that BGP-learned routes can be injected into a VPC route table—then you will likely need a VPC Route Server. While you could set up a VPC Route Server manually, what’s the fun in that? In this post, I will walk you through a Pulumi program that will set up a VPC Route Server. Afterward, I will discuss some ways you could check the functionality of the VPC Route Server to show that it is indeed working as expected.

To make things as easy as possible, I have added a simple Pulumi program to my GitHub “learning-tools” repository in the aws/vpc-route-server directory. This program sets up a VPC Route Server and its associated components for you, and I will walk through this program in this blog post.

The first step is creating the VPC Route Server itself. The VPC Route Server has no prerequisities, and the primary configuration needed is setting the ASN (Autonomous System Number) the Route Server should use:

rs, err := vpc.NewRouteServer(ctx, "rs", &vpc.RouteServerArgs{
    AmazonSideAsn: pulumi.Int(65534),
    Tags: pulumi.StringMap{
        "Name":    pulumi.String("rs"),
        "Project": pulumi.String("vpc-route-server"),
    },
})

Next, you will need to associate the Route Server with a VPC. This requires a VPC ID, as you might expect; this ID could come from a configuration value passed in by the user, or from a VPC created earlier in this or another Pulumi program.

rsa, err := vpc.NewRouteServerVpcAssociation(ctx, "rsa", &vpc.RouteServerVpcAssociationArgs{
    RouteServerId: rs.ID(),
    VpcId:         pulumi.String(userSuppliedVpcId),
})

With that association in place, the next component is a Route Server Endpoint. This endpoint is created in a subnet, and will have an IP address assigned from that subnet. This IP address is what your BGP peer will use to establish a peering relationship to exchange routes.

rse, err := vpc.NewRouteServerEndpoint(ctx, "rse", &vpc.RouteServerEndpointArgs{
    RouteServerId: rs.RouteServerId,
    SubnetId:      pulumi.String(userSuppliedPrivateSubnetId),
    Tags: pulumi.StringMap{
        "Name":    pulumi.String("rse"),
        "Project": pulumi.String("vpc-route-server"),
    },
}, pulumi.DependsOn([]pulumi.Resource{rsa}))

In working with the VPC Route Server, I’ve found that sometimes the dependencies between components don’t quite work as expected. Because the endpoint references the rs resource (the Route Server itself), the endpoint has a implicit dependency on that resource. However, if the VPC association isn’t complete, then you can run into errors. To address that problem, the code above uses pulumi.DependsOn to create an explicit dependency on the VPC association. This way, both the Route Server and the association of the Route Server to a VPC are complete before the program attempts to create the endpoint.

The Route Server needs to know where to inject the routes it learns, and that’s handled by creating a propagation. The propagation links the Route Server to a route table in the associated VPC. Here’s the Pulumi code from the example in the “learning-tools” repository:

_, err = vpc.NewRouteServerPropagation(ctx, "rs-prop", &vpc.RouteServerPropagationArgs{
    RouteServerId: rs.RouteServerId,
    RouteTableId:  pulumi.String(userSuppliedPrivateRouteTableId),
}, pulumi.DependsOn([]pulumi.Resource{rsa}))

The use of pulumi.DependsOn makes the propagation, like the endpoint, dependent on the VPC association. This helps eliminate errors related to the order of resource creation or deletion.

The last step is creating a peer for the Route Server. This tells the Route Server what the “other side” of a BGP peering relationship looks like. The “other side” could be an EC2 instance running a BGP daemon, or it could be a Kubernetes node on a cluster running a CNI that supports BGP (like Cilium). Whatever the “other side” is, you’ll need to be sure the configuration you pass to the Route Server peer matches the configuration in use by the other side. Otherwise, establishing the BGP peering relationship will fail.

_, err = vpc.NewRouteServerPeer(ctx, "rs-peer-01", &vpc.RouteServerPeerArgs{
    BgpOptions: &vpc.RouteServerPeerBgpOptionsArgs{
        PeerAsn:               pulumi.Int(65001),
        PeerLivenessDetection: pulumi.String("bgp-keepalive"),
    },
    PeerAddress:           pulumi.String(userSuppliedPeerIpAddress),
    RouteServerEndpointId: rse.RouteServerEndpointId,
    Tags: pulumi.StringMap{
        "Name":    pulumi.String("rs-peer-01"),
        "Project": pulumi.String("vpc-route-server"),
    },
}, pulumi.DependsOn([]pulumi.Resource{rs, rse}))

In the definition of the Route Server peer, you point it to the IP address of some other device or instance running BGP. In the other device or instance, you will point it to the IP address of the Route Server endpoint. This way, each member of the BGP peering relationship knows how to connect to the other member.

All of the code above is found in the aws/vpc-route-server directory in my GitHub “learning-tools” repository.

Once you run pulumi up to create all the resources, verifying the creation is a matter of using the AWS CLI:

aws ec2 describe-route-servers # to get the Route Server ID
aws ec2 describe-route-server-endpoints
aws ec2 get-route-server-propagations --route-server-id <id>
aws ec2 describe-route-server-peers 

Some of these commands don’t (yet) support some of the same filtering mechanisms as other AWS CLI commands, so you may find it necessary to use jq to filter the output on the client side.

Verifying the operation of the Route Server is a bit more complex—you will need something to run BGP and peer with the Route Server to exchange routes. As I mentioned earlier, Cilium can do this for a Kubernetes cluster, but you could also use an EC2 instance running FRR or some other BGP daemon. This is a topic I might explore in a future blog post; if it’s something you’re interested in seeing, please let me know.

If you have any questions or comments, please reach out to me. I love hearing from readers and would be happy to do my best to answer any queries or respond to feedback. You can reach me via email (my address is on this site), via various social media sites (X/Twitter, Bluesky, Mastodon), or via Slack (I’m in several Slack communities, including the Kubernetes Slack community). I hope you found this information helpful, and thanks for reading!

Technology Short Take 189

Welcome to Technology Short Take #189, Halloween Edition! OK, you caught me—this Tech Short Take is not scary. I’ll try harder next year. In the meantime, enjoy this collection of links about data center-related technologies. Although this installation is lighter on content than I would prefer, I am publishing anyway in the hopes of trying to get back to a somewhat-regular cadence. Here’s hoping you find something useful and informative!

Posts from the Past, October 2025

Every now and then, I publish one of these “Posts from the Past” articles that looks back on content I’ve created and posted over the life of this site. This year marks 20 years of content—I can hardly believe it! Don’t worry, though; you won’t have to go through 20 years of past posts. Here is a selection of posts from mid- to late October over the last decade or so. I hope you find something useful, informative, or at least entertaining!

Using Git Pre-Commit Hooks

A while ago I wrote an article about linting Markdown files with markdownlint. In that article, I presented the use case of linting the Markdown source files for this site. While manually running linting checks is fine—there are times and situations when this is appropriate and necessary—this is the sort of task that is ideally suited for a Git pre-commit hook. In this post, I’ll discuss Git pre-commit hooks in the context of using them to run linting checks.

Technology Short Take 188

Welcome to Technology Short Take #188! I’m back once again with a small collection of articles and links related to a variety of data center-related technologies. I hope you find something useful!

Networking

• Scott Hogg discusses using dual-stack network configurations on your DNS name servers as part of an overall IPv6 deployment plan.
• Leon Adato explains why knowing what’s under the hood helps when it comes to networking telemetry.
• Via Ivan Pepelnjak, I found Suresh Vina’s article on using netlab to build network labs.

Security

• The use of malicious software packages continues to be a vector for attacks; here’s the latest discovery of malicious Go and npm packages.
• James Kettle explains why HTTP/1.1 must die.
• Gary Marcus and Nathan Hamiel discuss why the combination of LLMs plus coding agents has the potential to result in a security nightmare.
• Weaponized RAR files are delivering a backdoor to Linux systems using only a filename—more details in the linked article.
• WhatsApp patches a zero-click exploit targeting iOS and macOS devices. I don’t use WhatsApp, but I know lots of folks that do (it’s especially popular among my international friends). If you’re a WhatsApp user, be sure to update.
• More software supply chain attacks, this time targeting CrowdStrike’s npm packages, have been observed as part of a larger campaign known as “Shai-Hulud.”

Cloud Computing/Cloud Management

• Mike Roberts explains why you probably don’t want to use AWS’ new GitHub Actions Lambda Deployment action.
• What would you do if AWS deleted your account and all your data?
• AWS has finally released universal macOS installers for the AWS CLI.

Operating Systems/Applications

• Adam Thompson shares how to improve Logitech MX Master 3 mouse support on Arch Linux.
• Mitchell Hashimoto shares some lessons learned when they rewrote the Ghostty GTK application.
• Some of the creators of Open Policy Agent (OPA) are joining Apple. Interesting.
• Simon Späti shares details on their journey from macOS to Arch Linux with Omarchy.
• Here is a useful post on systemd service hardening.
• The details of this post on Apple’s new Memory Integrity Enforcement (MIE) are a bit beyond me, I’ll be honest. I’m of two minds on the new technology. On one hand, it’s nice to see progress at fixing memory safety-related bugs and exploits. On the other hand, this progress could only be achieved, as the article states, through combining “the unique strengths of Apple silicon hardware with our advanced operating system security.” In other words, more tightly coupling the hardware and the OS.

Programming/Development

• Go has changed the way the language handles GOMAXPROCS in the 1.25 release.

Virtualization

• In advance of VMware Explore 2025—which apparently is/was this week in Las Vegas—William Lam shares an update on the nested ESXi 8.0 and ESXi 9.0 virtual appliance.

Career/Soft Skills

• Ashley Willis talks about the value and importance of the quiet season. I particularly found this sentence applicable to my own life: “So yes, I’m writing again. And maybe I’m less ’everywhere’ than I used to be. But I’d rather show up less often and have something worth saying than burn myself out trying to convince the world I’m still here.” Well said, IMO.
• All too true.
• I don’t know if I would go so far as to say I am an AI hater, but I am most definitely opposed to AI in its current form. (I don’t even like calling it “AI” when it’s really nothing more than a statistical model for putting words together. But that’s another discussion for another day…) As the author says, being a hater is a “kind of integrity” all its own—so I say, if you’re an AI hater, don’t be afraid to say so.

It’s time to wrap up now—but don’t be sad, I’ll be back soon with more content. In the meantime, if you’d like to reach out to me to provide some feedback on this article or any article, I’d love to hear from you! Feel free to contact me via Bluesky, via Mastodon, via X/Twitter, via Slack (I frequent a number of different communities, including the Kubernetes Slack instance) or even via email. Thanks for reading!

Creating a Talos Linux Cluster on AWS with Pulumi, 2025 Edition

A little over two years ago, I wrote a post on creating a Talos Linux cluster on AWS using Pulumi. At the time of that post, the Pulumi provider for Talos was still a prerelease version. Since then, the Talos provider has undergone some notable changes necessitating an update to the example code I have on GitHub. For your reading pleasure, therefore, I present you with the 2025 edition of a tutorial for using Pulumi to create a Talos Linux cluster on AWS.

Technology Short Take 187

Welcome to Technology Short Take #187! In this Technology Short Take, I have a curated collection of links on topics ranging from BGP to blade server hardware to writing notes using a “zettelkasten”-style approach, along with a few other topics thrown in here and there for fun. I hope you find something useful!

Technology Short Take 186

Welcome to Technology Short Take #186! Yes, it’s been quite a while since I published a Technology Short Take; life has “gotten in the way,” so to speak, of gathering links to share with all of you. However, I think this crazy phase of my life is about to start settling down (I hope so, anyway), and I’m cautiously optimistic that I’ll be able to pick up the blogging pace once again. For now, though, here’s a collection of links I’ve gathered since the last Technology Short Take. I hope you find something useful here!

Bootstrapping Dual-Stack Kubernetes on Flatcar with Kubeadm

Recently I needed to be able to stand up a dual-stack (IPv4/IPv6) Kubernetes cluster on Flatcar Container Linux using kubeadm. At first glance, this seemed like it would be relatively straightforward, but as I dug deeper into it there were a few quirks that emerged. Given these quirks, it seemed like a worthwhile process to write up and publish here. In this post, you’ll see how to use Butane and kubeadm to bootstrap a dual-stack IPv4/IPv6 Kubernetes cluster on AWS.

Technology Short Take 185

Welcome to Technology Short Take #185, the first of 2025! I’m excited for the opportunity to continue to bring readers articles and links of interest across data center- and cloud-related technologies (along with some original content along the way). I had originally intended for this post to be my last post of 2024, but personal challenges got in the way. Enough of that, though—on to the content!

Using Multiple AWS Regions with Pulumi and S3 Backend

For a while now, I’ve been using Direnv to manage environment variables when I enter or leave certain directories. Since I have to work with more than one AWS account, one of the use cases for me has been populating AWS-specific environment variables, like AWS_REGION or AWS_PROFILE. This generally works really well for me, but recently I ran into a bit of a corner case involving multiple AWS regions, Pulumi, and using S3 as the Pulumi backend. In this post, I’ll share the workaround that allows this configuration to work as expected.

Technology Short Take 184

Welcome to Technology Short Take #184! This Tech Short Take is a bit shorter than the usual ones, but then again this week—at least in the US—is a bit shorter than most weeks due to the Thanksgiving holiday. Even so, I hope that I’ve managed to include some information that folks find useful. Also, thanks to some feedback from readers, I’ve tried hard to ensure that links are more descriptive and informative than they’ve sometimes been in the past; let me know how I did. Now, on to the content!

EKS, Bottlerocket, and Cilium with Pulumi

In late 2023, I added some Go code for use with Pulumi to stand up an Amazon Elastic Kubernetes Service (EKS) cluster “from scratch,” meaning without using any prebuilt Pulumi components (like the AWSX VPC component or the EKS component). The code is largely illustrative for newer users, written to show how to stitch together all the components needed for an EKS cluster. In this post, I’ll show you how to modify that code to use Bottlerocket OS as the node OS for your EKS cluster—and share some information on installing Cilium into (onto?) the cluster.

Technology Short Take 183

Welcome to Technology Short Take #183! Fall is in the air; the nights and mornings are cooler and the leaves are turning (or have already turned in some areas!). I’ve got a slightly smaller collection of links for you this time around, but I do hope that you’ll find something shared here useful. Enjoy!

Technology Short Take 182

Welcome to Technology Short Take #182! I have a slightly bulkier list of links for you today, bolstered by some recent additions to my RSS feeds and supplemented by some articles I found through social media. There should be enough here to keep folks entertained this weekend—enjoy!

Preloading Extra Images with Kubernetes Image Builder

The Image Builder project is a set of tools aimed at automating the creation of Kubernetes disk images—such as VM templates or Amazon Machine Images (AMIs). (Interesting side note: Image Builder is the evolution of a much older Heptio project where I was a minor contributor.) I recently had a need to build a custom AMI with some extra container images preloaded, and in this post I’ll share with you how to configure Image Builder to preload additional container images.

• Storing Pulumi State in the Project Directory 23 Aug 2024
• Review: Lenovo ThinkPad X1 Carbon Gen11 21 Aug 2024
• Technology Short Take 181 16 Aug 2024
• Using SOPS with Pulumi 14 Aug 2024
• Bootstrapping Talos Linux over SSH 5 Aug 2024
• Using Vale to Improve my Writing 29 Jul 2024
• Technology Short Take 180 26 Jul 2024
• Using a Git Commit Template 15 Jul 2024
• Technology Short Take 179 28 Jun 2024
• Technology Short Take 178 31 May 2024
• Endpoint Selectors and Kubernetes Namespaces in CiliumNetworkPolicies 30 May 2024
• Getting Barrier Working Between Arch Linux and Ubuntu 29 May 2024
• Technology Short Take 177 17 May 2024
• Tracking EC2 Instances used by EKS with AWS CLI 17 Apr 2024
• Tracking ENIs used by EKS with AWS CLI 15 Apr 2024
• Technology Short Take 176 15 Mar 2024
• Linting your Markdown Files 1 Mar 2024
• Technology Short Take 175 23 Feb 2024
• Technology Short Take 174 9 Feb 2024
• Using NAT Instances on AWS with Pulumi 5 Feb 2024
• Using SSH with the Pulumi Docker Provider 22 Jan 2024
• Technology Short Take 173 19 Jan 2024
• Technology Short Take 172 5 Jan 2024
• Selectively Replacing Resources with Pulumi 3 Jan 2024
• Dynamically Enabling the Azure CLI with Direnv 18 Dec 2023
• Conditional Git Configuration 15 Dec 2023
• Automatically Transforming Git URLs 11 Dec 2023
• Technology Short Take 171 8 Dec 2023
• Saying Goodbye to the Full Stack Journey 17 Nov 2023
• Guest Post: Moving Secrets Where They Belong 12 Oct 2023