This is the source of the kube-aws
tool and the installation artifacts used by the official Kubernetes on AWS documentation.
View the full instructions at https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html.
CoreOS is interested in learning more about how people are launching clusters on AWS - fill out this survey to help us out.
This survey is meant for those who are currently running at least some workloads (dev, staging, or prod) on Kubernetes on AWS. Once we have received enough responses, we will share our learnings, anonymized and in aggregate, with the general Kubernetes community.
Go to the releases and download the latest release tarball for your architecture.
Currently, binaries coming from the final release for each version are signed so you should download the corresponding signature (.sig) as well. If you've decided to download a non-final release you can skip down to "Extract the binary:".
Import the CoreOS Application Signing Public Key:
gpg2 --keyserver pgp.mit.edu --recv-key FC8A365E
Validate the key fingerprint:
gpg2 --fingerprint FC8A365E
The correct key fingerprint is 18AD 5014 C99E F7E3 BA5F 6CE9 50BD D3E0 FC8A 365E
Validate the tarball's GPG signature:
PLATFORM=linux-amd64
# Or
PLATFORM=darwin-amd64
gpg2 --verify kube-aws-${PLATFORM}.tar.gz.sig kube-aws-${PLATFORM}.tar.gz
Extract the binary:
tar zxvf kube-aws-${PLATFORM}.tar.gz
Add kube-aws to your path:
mv ${PLATFORM}/kube-aws /usr/local/bin
The supported way to provide AWS credentials to kube-aws is by exporting the following environment variables:
export AWS_ACCESS_KEY_ID=AKID1234567890
export AWS_SECRET_ACCESS_KEY=MY-SECRET-KEY
Amazon KMS keys are used to encrypt and decrypt cluster TLS assets. If you already have a KMS Key that you would like to use, you can skip this step.
Creating a KMS key can be done via the AWS web console or via the AWS cli tool:
$ aws kms --region=us-west-1 create-key --description="kube-aws assets"
{
"KeyMetadata": {
"CreationDate": 1458235139.724,
"KeyState": "Enabled",
"Arn": "arn:aws:kms:us-west-1:xxxxxxxxx:key/xxxxxxxxxxxxxxxxxxx",
"AWSAccountId": "xxxxxxxxxxxxx",
"Enabled": true,
"KeyUsage": "ENCRYPT_DECRYPT",
"KeyId": "xxxxxxxxx",
"Description": "kube-aws assets"
}
}
You'll need the KeyMetadata.Arn
string for the next step:
$ mkdir my-cluster
$ cd my-cluster
$ kube-aws init --cluster-name=<my-cluster-name> \
--external-dns-name=<my-cluster-endpoint> \
--region=us-west-1 \
--availability-zone=us-west-1c \
--key-name=<key-pair-name> \
--kms-key-arn="arn:aws:kms:us-west-1:xxxxxxxxxx:key/xxxxxxxxxxxxxxxxxxx"
There will now be a cluster.yaml file in the asset directory.
-
In the simplest case, you can have kube-aws generate both your TLS identities and certificate authority for you.
$ kube-aws render credentials --generate-ca
This is not recommended for production.
-
It is recommended that, for production, you supply your own immediate certificate signing authority.
$ kube-aws render credentials --ca-cert-path=/path/to/ca-cert.pem --ca-key-path=/path/to/ca-key.pem
For more information on operating your own CA, check out this awesome guide.
-
In certain cases, such as users with advanced pre-existing PKI infrastructure, you may wish to pre-generate all cluster TLS assets. In this case, make sure the file tree below exists in your cluster assets directory before running
kube-aws up
.ls -R credentials/ credentials/: admin-key.pem apiserver-key.pem ca.pem etcd-client.pem etcd.pem worker.pem admin.pem apiserver.pem etcd-client-key.pem etcd-key.pem worker-key.pem
The next command generates the default set of cluster assets in your asset directory. These assets are templates that are used to create, update and interact with your Kubernetes cluster.
$ kube-aws render stack
You can now customize your cluster by editing asset files:
-
cluster.yaml
This is the configuration file for your cluster. It contains the configuration parameters that are templated into your userdata and cloudformation stack.
-
userdata/
cloud-config-worker
cloud-config-controller
This directory contains the cloud-init cloud-config userdata files. The CoreOS operating system supports automated provisioning via cloud-config files, which describe the various files, scripts and systemd actions necessary to produce a working cluster machine. These files are templated with your cluster configuration parameters and embedded into the cloudformation stack template.
-
stack-template.json
This file describes the AWS cloudformation stack which encompasses all the AWS resources associated with your cluster. This JSON document is templated with configuration parameters, we well as the encoded userdata files.
-
credentials/
This directory contains the unencrypted TLS assets for your cluster, along with a pre-configured
kubeconfig
file which provides access to your cluster api via kubectl.
You can also now check the my-cluster
asset directory into version control if you desire. The contents of this directory are your reproducible cluster assets. Please take care not to commit the my-cluster/credentials
directory, as it contains your TLS secrets. If you're using git, the credentials
directory will already be ignored for you.
kube-aws
can optionally create an A record for the controller IP in an existing hosted zone.
Edit the cluster.yaml
file:
externalDNSName: my-cluster.staging.core-os.net
createRecordSet: true
hostedZone: staging.core-os.net
If createRecordSet
is not set to true, the deployer will be responsible for making externalDNSName routable to the controller IP after the cluster is created.
The validate
command check the validity of the cloud-config userdata files and the cloudformation stack description:
$ kube-aws validate
$ kube-aws up
This command can take a while.
$ kubectl --kubeconfig=kubeconfig get nodes
It can take some time after kube-aws up
completes before the cluster is available. Until then, you will have a connection refused
error.
$ kube-aws up --export
Read the cluster update documentation.
Run the ./build
script to compile kube-aws
locally.
This depends on having:
- golang >= 1.5
The compiled binary will be available at bin/kube-aws
.
go test $(go list ./... | grep -v '/vendor/')
The various templates are located in the pkg/config/templates/
folder of the source repo. go generate
is used to pack these templates into the source code. In order for changes to templates to be reflected in the source code:
go generate ./pkg/config
This command is run automatically as part of the build
script.
The following links can be useful for development:
Submit a PR to this repository, following the contributors guide. The documentation is published from this source.