With the help of HashiCorp Packer  and Amazon EKS AMI repository, we can create custom Amazon Linux AMIs for EKS.

As a part of our AWS Support Services, we often receive similar requests from our AWS customers.

Today, let’s see the steps followed by our Support Techs to help our customers to create custom Amazon Linux AMIs for EKS.

 

Creating custom Amazon Linux AMIs for EKS

We must using the following for creating a custom Amazon Linux AMI for Amazon EKS:

• The HashiCorp packer.
• The build specification and the configuration scripts from the Amazon EKS AMI repository.

Installing HashiCorp packer

Now let’s see the steps to install and configure HashiCorp packer.

1. Firstly, we need to install HashiCorp Packer from the HashiCorp website.

2. After that, we need to allow Packer to make calls to AWS API operations by configuring the AWS account credentials. We can use secret key and secret access key(static credentials), an environment variable, shared credential files, or an Amazon EC2 role.

Cloning Amazon EKS AMI repository

We should run the below command to clone the the Amazon EKS AMI repository to our workstation.

$ git clone https://github.com/awslabs/amazon-eks-ami && cd amazon-eks-ami

With eks-worker-al2.json as the build specification, packer is excected through a series of makefile targets. Using amazon-ebs Packer builder, the build process launches an instance.

For installing software and performing the configuration tasks, the Packer shell provisioner runs the install-worker.sh script on the instance. After that the Packer creates an AMI from the instance and terminates the instance after the AMI is created.

Providing custom source AMI

We need to set the variables source_ami_id, source_ami_owners, and aws_regionin the Packer configuration file eks-worker-al2.json. to confiure a custom source AMI.

For example:

"source_ami_id": "SOURCE_AMI_ID", #  ID of our source image
"source_ami_owners": "AWS_ACCOUNT_ID", #  account where this image is stored
"aws_region": "AWS_DEFAULT_REGION", # AWS Region of the source AMI

Follow the steps in Providing our own Kubernetes binaries to provide custom worker binaries. Also follow the steps in the section Building an Amazon EKS worker AMI using default binaries to build the image using default Kubernetes binaries.

Providing our own Kubernetes binaries

Note: Providing our own Kubernetes binaries is optional.

By default the binaries are downloaded  from the Amazon EKS public Amazon S3 bucket amazon-eks when Packer provisions the instance.

1. We should run the following command to check out the available binaries provided in the default bucket.

$ aws s3 ls s3://amazon-eks
$ aws s3 ls s3://amazon-eks/kubernetes_version/kubernetes_build_date/bin/linux/arch/

2. After that, copy the binaries to our own S3 bucket using the AWS CLI after preparing binaries through our own build process.

For example,

$ aws s3 cp kubelet s3://my-custom-bucket/kubernetes_version/kubernetes_build_date/bin/linux/arch/kubelet

Building an Amazon EKS worker AMI using default binaries

For starting the build process, we can use the source AMI configured in eks-worker-al2.json to invoke make with parameters.
For example,

$ make k8s \
binary_bucket_name=my-custom-bucket \
binary_bucket_region=eu-west-1 \
kubernetes_version=1.14.8 \
kubernetes_build_date=2021-09-05

Building an Amazon EKS worker AMI using default binaries

1. We need to confirm that the eks-worker-al2.json file is updated with the correct base AMI to build the Amazon EKS worker AMI using a custom base AMI and the default Kubernetes binaries.

2. Run the following command to trigger the build process by providing the Kubernetes version as the parameter.
For example,

$ make 1.14 # Build a Amazon EKS Worker AMI for k8s 1.14

[Need help with more AWS queries? We’d be happy to assist]

Conclusion

To conclude, today we discussed the steps followed by our Support Engineers to help our customers to create custom Amazon Linux AMIs for EKS.