Up until my recent discovery of Terraform, the process I had been using to test CoreOS and Kubernetes was somewhat cumbersome and manual. There are still some manual steps and processes involved in the bootstrap and cluster creation process that need to get sorted out, but now I can bring environments up and down, quickly and automatically. This is a HUGE time saver and also makes testing easier because these changes can happen in a matter of minutes rather than hours and can all be self documented for others to reference in a Github repo. Great success.
NOTE: This method seems to be broken as of the 0.14.2 release of Kubernetes. The latest version I could get to work reliably was v0.13.1. I am following the development and looking forward to the v1.0 release but won’t revisit this method until something stable has been shipped because there are still just too many changes going on. With that said, v0.13.1 has a lot of useful functionality and this method is actually really easy to get working once you have the groundwork laid out.
Another benefit is that as the project develops and matures, the only thing that will need modified are the cloud configs I am using here. So if you follow along you can use my configs as a template, feel free to use this as a base and modify the configs to get this working with a newer release. As I said I will be revisiting the configs once things slow down a little and a v1 has been released.
Terraform
So the first component that we need to enable in this workflow is Terraform. From their site, “Terraform is a tool for building, changing, and combining infrastructure safely and efficiently.” Basically, Terraform is a command line tool for allowing you to implement your infrastructure as code across a variety of different infrastructure providers. It should go without saying, being able to test environments across different platforms and cloud providers is a gigantic benefit. It doesn’t lock you in to any one vendor and greatly helps simplify the process of creating complex infrastructures across different platforms.
Terraform is still a young project but has been maturing nicely and currently supports most of the functionality needed for this method to work (the missing stuff is in the dev pipeline and will be released in the near future). Another benefit is that Terraform is much easier to use and understand than CloudFormation, which is a propriety cloud provisioning tool available to AWS customers, which could be used if you are in a strictly AWS environment.
The first step is to download and install Terraform. In this example I am using OSX but the instructions will be similar on Linux or other platforms.
cd /tmp
wget https://dl.bintray.com/mitchellh/terraform/terraform_0.3.7_darwin_amd64.zip
unzip terraform_0.3.7_darwin_amd64.zip
mv terraform* /usr/local/bin
After you have moved the binary you will need to source your shell. I use zsh so I just ran “source ~/.zshrc” to update the path for terraform.
To test terraform out you can check the version to make sure it works.
terraform version
Now that Terraform is installed you will need to get some terraform files set up. I suggest making a local terraform directory on your machine so you can create a repo out of it later if desired. I like to split “services” up by creating different directories. So within the terraform directory I have created a coreos directory as well as a kubernetes directory, each with their own variables file (which should be very similar). I don’t know if this approach is a best practice but has been working well for me so far. I will gladly update this workflow if there is a better way to do this.
Here is a sample of what the file and directory layout might look like.
cloud-config
etcd-1.yml
etcd-2.yml
etcd-3.yml
kube-master.yml
kube-node.yml
etcd
dns.tf
etcd.tf
variables.tf
kubernetes
dns.tf
kubernetes.tf
variables.tf
As you can see there is a directory for Etcd as well as Kubernetes specific configurations. You may also notice that there is a cloud-config directory. This will be used as a central place to put configurations for the different services.
Etcd
With Terraform set up, the next component needed for this architecture to work is a functioning etcd cluster. I chose to use a separate 3 node cluster (spread across 3 AZ’s) for improved performance and resliency. If one of the nodes goes down or away with a 3 node cluster it will still be operational, where if a 1 node cluster goes away you will be in much more trouble. Additionally if you have other services or servers that need to leverage etcd you can just point them to this etcd cluster.
Luckily, with Terraform it is dead simple to spin up and down new clusters once you have your initial configurations set up and configured correctly.
At the time of this writing I am using the current stable version of CoreOS, which is 633.1.0, which uses version 0.4.8 of etcd. According to the folks at CoreOS, the cloud configs for old versions of etcd should work once the new version has been released so moving to a the new 2.0 release should be easy once it hits the release channel but some tweaks or additional changes to the cloud configs may need to occur.
Configuration
Before we get in to the details of how all of this works, I would like to point out that many of the settings in these configuration files will be specific to users environments. For example I am using an AWS VPC in the “us-east-1” region for this set up, so you may need to adjust some of the settings in these files to match your own scenario. Other custom components may include security groups, subnet id’s, ssh keys, availability zones, etc.
Terraform offers resources for basically all network components on AWS so you could easily extend these configurations to build out your initial network and environment if you were starting a project like this from scratch. You can check all the Terraform resources for the AWS provider here.
Warning: This guide assumes a few subtle things to work correctly. The address scheme we are using for this environment is a 192.168.x.x, leveraging 3 subnets to spread the nodes out across for additional availability (b, c, e) in the US-East-1 AWS region. Anything in the configuration that has been filled in with “XXX” represents a custom value that you will need to either create or obtain in your own environment and modify in the configuration files.
Finally, you will need to provide AWS credentials to allow Terraform to communicate with the API for creating and modifying resources. You can see where these credentials should be filled in below in the variables.tf file.
variables.tf
variable "access_key" {
description = "AWS access key"
default = "XXX"
}
variable "secret_key" {
description = "AWS secret access key"
default = "XXX"
}
variable "region" {
default = "us-east-1"
}
/* CoreOS AMI - 633.1.0 */
variable "amis" {
description = "Base CoreOS AMI"
default = {
us-east-1 = "ami-d6033bbe"
}
}
Here is what an example CoreOS configs look like.
etcd.tf
provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${var.region}"
}
/* Etcd cluster */
resource "aws_instance" "etcd-01" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1e"
instance_type = "t2.micro"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = XXX"
private_ip = "192.168.1.10"
user_data = "${file("../cloud-config/etcd-1.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "20"
}
}
resource "aws_instance" "etcd-02" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1b"
instance_type = "t2.micro"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = "XXX"
private_ip = "192.168.2.10"
user_data = "${file("../cloud-config/etcd-2.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "20"
}
}
resource "aws_instance" "etcd-03" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1c"
instance_type = "t2.micro"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = "XXX"
private_ip = "192.168.3.10"
user_data = "${file("../cloud-config/etcd-3.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "20"
}
}
Below I have created a configuration file as a simaple way to create DNS records dynamically when spinning up the etcd cluster nodes.
dns.tf
resource "aws_route53_record" "etcd-01" {
zone_id = "XXX"
name = "etcd-01.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.etcd-01.private_ip}"]
}
resource "aws_route53_record" "etcd-02" {
zone_id = "XXX"
name = "etcd-02.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.etcd-02.private_ip}"]
}
resource "aws_route53_record" "etcd-03" {
zone_id = "XXX"
name = "etcd-03.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.etcd-03.private_ip}"]
}
Once all of the configurations have been put in place and all look right you can test out what your configuration will look like with the “plan” command:
cd etcd
terraform plan
Make sure to change in to your etcd directory first. This will examine your current configuration and calculate any changes. If your environment is completely unconfigured then this command will return some output that explains what terraform is planning to do.
If you don’t want the input prompts when you run your plan command you can append the “-input=false” flag to bypass the configurations.
If everything looks okay with the plan you can tell Terraform to “apply” your conifgs with the following:
terraform apply
OR
terraform apply -input=false
If everything goes accordingly, after a few minutes you should have a new 3 node etcd cluster running on the lastest stable version of CoreOS with DNS records for interacting with the nodes! To double check that the servers are being created you can check the AWS console to see if your newly defined servers have been created. The console is a great way to double check that things all work okay and that the right values were created.
If you are having trouble with the cloud configs check the end of the post for the link to all of the etcd and Kubernetes cloud configs.
Kubernetes
The Kubernetes configuration is very similar to etcd. It uses a variables.tf, kubernetes.tf and dns.tf file to configure the Kubernetes cluster.
The following configurations will build a v0.13.1 Kubernetes cluster with 1 master, and 3 worker nodes to begin with. This config can be extended easily to scale the number of worker nodes to basically as many as you want (I could easily image the hundreds or thousands), simply by changing a few number in the configuration, barely adding any overhead to our current process and workflow, which is nice. Because of these possibilities, Terraform allows for a large amount of flexibility in how you manage your infrastructure.
This configuration is using c3.large instances so be aware that your AWS bill may be affected if you spin nodes up and fail to turn them off when you are done testing.
provider "aws" {
access_key = "${var.access_key}"
secret_key = "${var.secret_key}"
region = "${var.region}"
}
/* Kubernetes cluster */
resource "aws_instance" "kube-master" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1e"
instance_type = "c3.large"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = "XXX"
private_ip = "192.168.1.100"
user_data = "${file("../cloud-config/kube-master.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "20"
}
}
resource "aws_instance" "kube-e" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1e"
instance_type = "c3.large"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = "XXX"
count = "1"
user_data = "${file("../cloud-config/kube-node.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "100"
}
}
resource "aws_instance" "kube-b" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1b"
instance_type = "c3.large"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = "XXX"
count = "1"
user_data = "${file("../cloud-config/kube-node.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "100"
}
}
resource "aws_instance" "kube-c" {
ami = "${lookup(var.amis, var.region)}"
availability_zone = "us-east-1c"
instance_type = "c3.large"
subnet_id = "XXX"
security_groups = ["XXX"]
key_name = "XXX"
count = "1"
user_data = "${file("../cloud-config/kube-node.yml")}"
root_block_device = {
device_name = "/dev/xvda"
volume_type = "gp2"
volume_size = "100"
}
}
And our DNS configuration.
resource "aws_route53_record" "kube-master" {
zone_id = "XXX"
name = "kube-master.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.kube-master.private_ip}"]
}
resource "aws_route53_record" "kube-e" {
zone_id = "XXX"
name = "kube-e-test.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.kube-e.0.private_ip}"]
}
resource "aws_route53_record" "kube-b" {
zone_id = "XXX"
name = "kube-b.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.kube-b.0.private_ip}"]
}
resource "aws_route53_record" "kube-c" {
zone_id = "XXX"
name = "kube-c.example.domain"
type = "A"
ttl = "300"
records = ["${aws_instance.kube-c.0.private_ip}"]
}
The variables file for Kubernetes should be identical to the etcd configuration so I have chosen not to place it here. Just refer to the previous etcd/variables.tf file.
Resources
Since each cloud-config is slightly different (and would take up a lot more space) I have included those files in the below gist. You will need to populate the “ssh_authorized_keys:” section with your own SSH public key and update any of the IP addresses to reflect your environment. I apologize if there are any typo’s, there was a lot of cut and paste.
Cloud configs – https://gist.github.com/jmreicha/7923c295ab6110151127
Much of the configurations that I am using are based on the Kubernetes docs, as well as some of the specific cloud configs that I have adapted, which can be found here.
Another great place to get help with Kubernetes is the IRC channel which can be found on irc.freenode.net in the #google-containers channel. The folks that hang out there are super friendly and can almost always answer any questions you have.
As I said, development is still pretty crazy. You can check the releases page to check out all the latest stuff.
Conclusion
Yes this can seem very convoluted at first but if everything works how it should, you now have a quick and easy way to spin up identical etcd and/or a Kubernetes environments up or down at will, which is pretty powerful. Also, this method is dramatically easier than most of the methods I have come across so far in my own adventures and testing.
Once you get through the initial confusion and learning curve this workflow becomes a huge timesaver for testing out different versions of Kubernetes and also for experimenting with etcd. I haven’t quite automated the entire process but I imagine that it would be easy to spin entire environments up and down by gluing all of these pieces together with some simple shell scripts.
If you need to make any configuration updates, for example to put a new version of Kubernetes in place, you will need first update your Kubernetes master/node cloud configs and then rerun terraform apply to have it recreate your environment.
The cloud config changes will destroy any nodes that rely on the old configuration. Therefore, you will need to make sure that if you make any changes to your cloud config files you are prepared to deal with the consequences! Ideally you should get your etcd cluster to a good spot and then leave it alone and just play around with the Kubernetes components since both of those components have been separated in order to change the components out independently.
With this workflow you can already start to see the power of terraform even with this one example. Terraform is quickly becoming one of my favorite automation and cloud tools and is providing a very easy way to define and build infrastructure though code and configurations.
Read More
