I’ve written a few articles about Cluster API (you can see a list of the articles here), but even though I strive to make my articles easy to understand and easy to follow along many of those articles make an implicit assumption: that readers are perhaps already somewhat familiar with Linux, Docker, tools like kind, and perhaps even Kubernetes. Today I was thinking, “What about folks who are new to this? What can I do to make it easier?” In this post, I’ll talk about the first idea I had: creating a “bootstrapper” AMI that enables new users to quickly and easily jump into the Cluster API Quick Start.

Normally, in order to use the Quick Start, there are some prerequisites that are needed first (these are all clearly listed on the Quick Start page):

• You need kubectl installed
• You need kind (which in turn requires Docker) or an existing Kubernetes cluster up and running

For Linux users (like myself), these prerequisites are pretty easy/simple to handle. But what if you’re a Windows or Mac user? Yes, you could use Docker Desktop and then install kind (or use docker-machine, if you’re feeling adventurous). Then you’d have to also install clusterctl, clusterawsadm, etc. With that in mind, I decided to build an AWS AMI that has all these prerequisites installed already—thus enabling new users to simply spin up an instance and hit the ground running.

The AMI has the following tools already installed:

• The AWS CLI (it just needs to be configured with your credentials)
• kubectl (version 1.18.2)
• Docker CE (the latest version for Ubuntu 18.04; you’ll need to add the “ubuntu” user to the “docker” group to avoid having to use sudo)
• kind (version 0.8.1)
• clusterctl (version 0.3.5)
• clusterawsadm (version 0.5.3)

With these tools all pre-installed, new users can immediately jump right into the Quick Start, and not have to worry about any of the steps that call for downloading or installing a binary—everything needed is already there.

There is one drawback right now, though: until such time as I can figure out how to securely share the AMI I’ve built without impacting my own AWS account (and monthly bill!), you’ll have to build it yourself using Packer and Ansible and the files from this GitHub repository.

To build your own “CAPI bootstrapper image”:

1. Make sure you have Packer and Ansible installed. (Sorry, I tried to eliminate as much upfront work as possible, but there’s only so much that can be done.)
2. Ensure your AWS access is working (make sure the AWS CLI works, for example).
3. Clone my “packer-templates” GitHub repository to your local system.

4. From the cloned repository, run this command:

   packer build templates/aws-capi-bootstrapper-1.18.2.json
   

   You may need to specify the full path to the packer binary, depending on how/where it is installed.

Once the Packer process completes, you’ll have an AMI with all the prerequisites for getting started with Cluster API on AWS. Spin up an instance based on that AMI and you’re almost completely ready to roll; the only additional step needed is to configure the AWS CLI in the instance with your credentials, as mentioned earlier. (I can’t do that for you.)

Hopefully this helps someone. The Ansible roles and Packer template are both pretty simplistic right now; if you’re experienced with these tools and are interested in improving them, I welcome PRs to the repository. If you have questions or suggestions for feedback, you’re welcome to find me on Twitter or in the Kubernetes Slack community. I’d love to hear from you.

…

Read MoreMaking it Easier to Get Started with Cluster API on AWS

A rapid, disorganized shift to the cloud can open the door to data theft, ransomware, malware, and other cyberattacks, says IBM X-Force. …

Read MoreHow to better defend your cloud-based environments against cyberattack

Applications are now open for the nanodegree program, which will help Udacity train developers on the Microsoft Azure cloud infrastructure. …

Read MoreMicrosoft and Udacity partner in new $4 million machine-learning scholarship program for Microsoft Azure

News

Sabina Weston

The four-hour-long outage took down the company's own service status page

…

Read MoreIBM Cloud suffers major global outage

I recently had a need to test a configuration involving the use of a single NAT Gateway servicing multiple private subnets across multiple availability zones (AZs) within a single VPC. While there are notable caveats with such a design (see the “Caveats” section at the bottom of this article), it could make sense in some use cases. In this post, I’ll show you how I used TypeScript with Pulumi to automate the creation of this design.

For the most part, if you’re familiar with Pulumi and using TypeScript with Pulumi, this will be pretty straightforward. The code I’ll show you makes a couple assumptions:

1. It assumes you’ve already created the VPC and the subnets earlier in the code. I’ll reference the VPC object as vpc.
2. I’ll assume you’ve already created subnets in said VPC, and that the subnet-to-AZ ratio is 1:1 (exactly one subnet of each type—public or private—in each AZ). The code will reference the subnet IDs as pubSubnetIds (for public subnets) or privSubnetIds (for private subnets). (How to create the subnets and capture the list of IDs is left as an exercise for the reader. If you’d be interested in seeing how I do it, let me know.)

The first step is creating an Elastic IP to assign to the NAT Gateway:

let natGwEip = new aws.ec2.Eip("natgw-eip", { vpc: true,
});

Next, create the NAT Gateway itself:

let natGw = new aws.ec2.NatGateway("natgw", { allocationId: natGwEip.id, subnetId: pubSubnetIds[0],
});

This creates the NAT Gateway and attaches it to the first public subnet in the list of public subnet IDs stored in pubSubnetIds. You could, obviously, attach it to a different public subnet as needed.

Next, create a route table that will provide Internet access via the NAT Gateway:

let natGwRoute = new aws.ec2.RouteTable("natgw-route", { vpcId: vpc.id, routes: [ { cidrBlock: "0.0.0.0/0", natGatewayId: natGw.id }, ],
});

Finally, associate this route table with the private subnets. The code below iterates across the number of AZs in the specified region (again, I’ll leave exactly how to gather that information as an exercise for readers; let me know if you are interested in seeing that portion of code) and make a route table association for each subnet/AZ:

let privRtAssoc = [];
for (let i = 0; i < numberOfAZs; i++) { privRtAssoc.push(new aws.ec2.RouteTableAssociation(`priv-rta-${i+1}`, { routeTableId: natGwRoute.id, subnetId: privSubnetIds[i], }));
};

When you run pulumi up to create this infrastructure, you’ll end up with a single NAT Gateway, attached to one public subnet and multiple private subnets. Instances in each private subnet will be able to access Internet-based resources via the single NAT Gateway.

Caveats

It’s important to note that outbound traffic will have to cross AZ boundaries in order to egress onto the Internet, and therefore will be subject to cross-AZ data transfer fees (see this article by Corey Quinn for more details). Be sure to understand your traffic patterns and understand the impact of this sort of design on your traffic patterns and your billing before going down this path. (Of course, that’s good advice for any design.) This article also has some good information on reducing data transfer charges for your NAT Gateway(s) (thanks to reader Amey Bhide for the link!).

Feel free to connect with me on Twitter, or find me in any one of a number of Slack communities (including the Pulumi Slack community), if you have questions, comments, or suggestions for improvement.

…

Read MoreCreating a Multi-AZ NAT Gateway with Pulumi

Aruba’s president outlined the steps necessary to harness data in a way that generates actionable insights and introduced the Aruba Edge Services platform. …

Read MoreAruba Atmosphere Digital keynote: Co-founder challenges organizations to “Define your edge”