Take this short, multiple choice survey and tell us about your company’s multicloud approach–or lack of one. …

Read MoreMulticloud: Does your company use multiple cloud providers?

I’ve been using Kustomize with Cluster API (CAPI) to manage my AWS-based Kubernetes clusters for quite a while (along with Pulumi for managing the underlying AWS infrastructure). For all the time I’ve been using this approach, I’ve also been unhappy with the overlay-based approach that had evolved as a way of managing multiple workload clusters. With the recent release of CAPI 1.0 and the v1beta1 API, I took this opportunity to see if there was a better way. I found a different way—time will tell if it is a better way. In this post, I’ll share how I’m using Kustomize components to help streamline managing multiple CAPI workload clusters.

Before continuing, I feel it’s important to point out that while the bulk of the Kustomize API is reasonably stable at v1beta1, the components portion of the API is still in early days (v1alpha1). So, if you adopt this functionality, be aware that it may change (or even get dropped).

More information on Kustomize components can be found in the Kustomize components KEP or in this demo document. The documentation on Kustomize components is somewhat helpful as well. I won’t try to rehash information found in those sources here, but instead build on that information with a CAPI-focused use case. Finally, if you’re unfamiliar with using Kustomize with CAPI, start with this introduction and then read the post on transformer configurations for v1beta1.

So, what are Kustomize components? In the context of CAPI, let’s say that you have a discrete change or configuration you’d like to make to a base CAPI manifest. Perhaps it’s changing the imageLookupBaseOS setting, as described in this post, to influence AMI selection. You could use a JSON 6902 patch, similar to this, to make that change:

[ { "op": "add", "path": "/spec/template/spec/imageLookupBaseOS", "value": "ubuntu-20.04" }
]

You could turn this into a Kustomize component using the following kustomization.yaml:

---
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
patchesJson6902: - path: spec-template-spec-base-os.json target: group: infrastructure.cluster.x-k8s.io kind: AWSMachineTemplate name: ".*" version: v1beta1 - path: spec-template-spec-base-os.json target: group: infrastructure.cluster.x-k8s.io kind: AWSMachine name: ".*" version: v1beta1

Note the kind: Component and the v1alpha1 API version, which distinguish this file from a typical kustomization.yaml. This file references the JSON 6902 patch shared earlier and applies that patch to all AWSMachine and AWSMachineTemplate objects.

Congratulations, you’ve defined your first component! Now, what do you do with it?

To use a component you’ve defined, simply include it in a kustomization.yaml like this:

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources: - ../base
components: - ../components/ubuntu-20.04

This is a more “traditional” kustomization.yaml that specifies a base resource, but then instead of referencing a list of transformers or generators or patches, it references the component you defined earlier. You are, of course, not limited to using just one component. Here’s an example from my own lab configuration files:

---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources: - ../capi-base
components: - ../components/dev - ../components/us-west-2 - ../components/calico-cni - ../components/aws-ccm - ../components/aws-ebs-csi - ../components/ubuntu-20.04

In this configuration, I’m referencing a number of different components:

• The “dev” component controls the number of MachineDeployments and how many replicas each MachineDeployment manages. If I need more MachineDeployments with more replicas, I can simply swap out this component for the “prod” component.
• The “calico-cni” component adds labels that cause the workload cluster to match against a ClusterResourceSet, thereby automatically installing the Calico CNI plugin. (Curious about ClusterResourceSets? Read this or this.)
• Similarly, the “aws-ccm” and “aws-ebs-csi” components add labels for ClusterResourceSets that install the external AWS cloud provider and EBS CSI driver, respectively. (See this post for more details on using the external AWS cloud provider.)
• The “ubuntu-20.04” component sets the AMIs to Ubuntu 20.04.

The awesome thing about using components is that I can define the change I want just once—as a component—and then reference it from multiple overlays. Each overlay becomes a list of references to components, instead of slightly-different copies of other overlays. This is a huge improvement over duplicating patches for multiple workload clusters.

Overall, I’m far more pleased with using components to describe Kustomize overlays for CAPI workload clusters than previous approaches.

I hope this is helpful to others. If you have any questions, want to talk about it in more detail, or have suggestions for how I can improve, please don’t hesitate to contact me. Reach out to me on Twitter, or find me on the Kubernetes Slack community.

…

Read MoreUsing Kustomize Components with Cluster API

Commentary: Intel has fallen behind in key markets, but CEO Gelsinger plans to spend very, very big to change that. …

Read MoreIntel CEO Pat Gelsinger’s “insane” plan to restore the company’s glory days

Welcome to Technology Short Take #147! The list of articles is a bit shorter than usual this time around, but I’ve still got a good collection of articles and posts covering topics in networking, hardware (mostly focused on Apple’s processors), cloud computing, and virtualization. There’s bound to be something in here for most everyone! (At least, I hope so.) Enjoy your weekend reading!

Networking

• Chris Parker shares the reason why 65535 is not part of the private autonomous system range. It’s an interesting history lesson and explanation, even if you aren’t a networking nerd.
• Dmytro Shypovalov discusses ARP problems in EVPN. I laughed at his comment regarding people stepping on rakes (read the post).
• Evgeny Khabarov’s part 4 in a series on using Envoy as an API gateway talks about authentication and authorization (aka AuthN/AuthZ). In particular, Khabarov focuses on Envoy’s ext_authz filter, which is what allows Envoy to check with an authorization service to see if a request is permitted or denied.
• I was having a bit of difficulty fully grokking the Original Destination feature in Envoy, and I found this article to be helpful in understanding how it works and is configured. Another very helpful resource on this topic is this masterpiece by Jimmy Song.
• Julia Evans shares some tools to explore BGP.

Servers/Hardware

• David Sparks shares the specs for his new 16" MacBook Pro as well as the rationale for how he arrived at that configuration. I must confess that I am intrigued by the M1 Pro and M1 Max, but having just bought a “regular” M1 a few months ago I’m not sure I can justify the purchase. And, to be honest, my “regular” M1 is plenty snappy for what I do.
• AnandTech takes a closer look at Apple’s A15 SoC (system on a chip), which debuted in the iPhone 13.

Security

• Senthil Raja Chermapandian asks the question, “Are Kubernetes Network Policies really useful?” I see their utility as being less useful now with the rising adoption of service meshes and L7-aware CNI plugins like Cilium, but I do still believe there are valid use cases for them.
• Thomas Reed with Malwarebytes Labs has a lengthy post on how macOS attacks are evolving.

Cloud Computing/Cloud Management

• Now that Cluster API has hit 1.0 (and v1beta1 status, indicating pretty stable APIs), the Cluster API community moves on to addressing how to manage the lifecycle of groups of Kubernetes clusters. See this blog post from Fabrizio Pandini for more details.
• Want to use the Kong API Gateway with Knative? Fear not, the folks from Direktiv share their knowledge on running services with Knative and Kong.
• William Lam shares some information on using kube-vip with VMware’s new Tanzu Community Edition (TCE).
• Jacob Schulz brought this article on Terraform modules to my attention; if you aren’t already familiar with Terraform modules, you may find it helpful.
• In this article, Alex Feiszli lays out the argument for a “wide” cluster over multiple clusters, and advocates for potentially spreading that “wide” cluster over multiple cloud providers. I have to say that, in general, I disagree with this architecture. There are a number of reasons (and I won’t go into great detail), but some of them include blast radius (if your one control plane goes down, you’re in for a world of hurt), lack of support for multiple cloud provider integrations (you’ll have to give up most, if not all, cloud provider integrations), and increased complexity (among other things, having to add and maintain additional node labels and node selectors is additional work).
• Speaking of labels, Aviad Shikloshi wrote an article on best practices for Kubernetes labels and annotations.
• Chris Evans attempts to define hybrid cloud and multi-cloud.

Operating Systems/Applications

• Kevin Alvarez shares how to potentially speed up ARM64 build times using Docker BuildX and AWS Graviton2 instances.

Virtualization

• Chris Evans shares his take on VMware’s Project Capitola.
• Frank Denneman discusses a potential gotcha in the user interface for configuring DRS in vSphere 7.
• Jason Boche walks through deploying EKS Anywhere on vSphere.
• William Lam reviews the minimum vSphere editions and features that are required for Tanzu Community Edition (TCE).

Career/Soft Skills

• I loved this article about the “follow your feet” saying. I’d never heard it before, but I like the idea of applying this to your IT career. Ask the questions you think are stupid questions. Chase down the ideas that seem like they have promise, even if they aren’t fully fleshed out yet. Try that new combination of technologies that you think may hold promise for your team or your company. In other words, follow your feet.
• I really enjoyed this article on rent vs. buy in one’s career.

That’s all, folks! (Bonus points if you get this reference.) If you have any questions, comments, or feedback, I’d love to hear from you! Feel free to contact me on Twitter, or find me in any of a variety of Slack communities.

…

Read MoreTechnology Short Take 147