Installing KuberDock at Amazon Web Services

Navigation:  Installation >

Installing KuberDock at Amazon Web Services

Previous pageReturn to chapter overviewNext page



1. You need an AWS account. Visit to get started.

2. Install and configure AWS Command Line Interface (AWS CLI).

3. You need an AWS instance profile and role with the Administrator Access policy (see below).

4. You need to generate a pair of AWS access key ID and secret access key that will be used by KuberDdock.


In CentOS environment, AWS CLI can be installed as follows:


yum install python-pip

pip install -U pip

pip install awscli


If you use another operating system or need more detailed instructions of how to install and configure AWS CLI please refer Installing the AWS Command Line Interface - AWS Command Line Interface.


Note. KuberDock deploy script creates AWS Virtual Private Cloud (VPC) instances.

Note. KuberDock deploy script will create EBS storage to use it as persistent storage. Please find detailed information and instructions are in Managing Elastic Block Storage (EBS) on Amazon AWS as KuberDock persistent storage. This functionality is under development at the moment.


Getting started with AWS


You may skip this section if you are aware of how to setup Amazon Web Services (AWS) and get permissions necessary to deploy KuberDock.


To start AWS usage log in its official site and select the Security Credentials item in the My Account dropdown:




In the pop-up dialog box, click Get Started with IAM Users button:




Click Create new user in the new form:




The next screen presents user’s security credentials — Access Key ID and Secret Access Key — as on the example below:





The keys may be downloaded as a text file by clicking Download Credentials button or merely copied directly from the screen.


On the Permissions tab of the next form click Attach Policy:




You will be presented with the list of available permission policies on the Attach Policy screen. At least the Administrator Access policy is needed to use Kubernetes:




Then it is necessary to obtain Amazon Machine Image (AMI) of Centos 7.


This may be accomplished visiting AWS Marketplace. Search there for the image CentOS 7 (x86_64) - with Updates HVM:




Click Continue and on the Manual Launch tab click Accept Software Terms:




Now KuberDock cluster may be deployed using created user’s credentials.


KuberDock setup instructions


1. Download archive with installation script:




2. Unpack it to any folder:


tar xvfz aws-kd-deploy.tar.gz


3. Change defaults in cluster/aws/ or export as environment variables:


export KUBE_AWS_ZONE=eu-west-1c // specify appropriate region, available for amazon servers

export MASTER_SIZE=m3.medium // choose appropriate server type for KuberDock master available on amazon

export NUM_NODES=2 // number of nodes in KuberDock

export NODE_SIZE=m3.medium // choose appropriate server type available on amazon

export AWS_S3_REGION=eu-west-1 // specify time zone for Amazon Simple Storage Service (S3)

export AWS_EBS_DEFAULT_SIZE=20 // This variable is available from KuberDock .1.5.0; default size of EBS for node which is used for a local persistent storage.


4. To access AWS programmatically, an access key is used. The key consists of an access key ID (something like ‘AKIAIOSFODNN7EXAMPLE’) and a secret access key (something like ‘wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY’). As AWS does not provide the keys for user accounts, user should create it by own efforts according to Amazon documentation and then export such environment variables:


export AWS_ACCESS_KEY_ID=your_aws_access_key_id

export AWS_SECRET_ACCESS_KEY=your_aws_secret_access_key


5. By default, all AWS instances assume names starting with the prefix ‘kuberdock’. The default prefix is saved in the variable:




in the file


6. When being deployed at AWS KuberDock uses ZFS as a default Local Storage backend. This can be changed via environment variable KD_USE_ZFS:


export KD_USE_ZFS=no


Another controlled variable of the file is the default EBS volume size in GB. It is named AWS_EBS_DEFAULT_SIZE and is set to 20 (GB):


# EBS Storage initial size




This variable prescribes initial size of EBS volume for persistent storage when a node is created. It is also used as the default increment when the storage is expanded.


7. A pair of public and private cryptography keys are used for encryption and decryption of login information, in digital signing, etc. The pair will be automatically generated during the deployment and the public key is imported in AWS under the name captured in the variable AWS_SSH_KEY_NAME on the file The name consists of the prefix kuberdock and the key fingerprint:




If there is necessity to use a particular, but not the automatically generated private key, it should be saved as $HOME/.ssh/kube_aws_rsa (referred by the variable AWS_SSH_KEY of the file since the auto-generated key is saved in this way.


Regardless of the manner to obtain the keys it is expected that the public key will be saved in the same directory and under the same name as the private one, but with the file extension *.pub.


Note that only keys owner can have right to read them, otherwise the deployment will be aborted.


The cluster can be accessed after installation using the private key in a command like:


ssh -i ~/.ssh/kube_aws_rsa [email protected]


8. Run installation script:




By default, the script will provide a new Amazon VPC and a KuberDock cluster with 2 nodes in us-west-2b (Oregon) with m3.medium instances running on CentOS 7. As a result you will get an external IP of KuberDock master and admin login and password.


Note that Amazon VPC has its own limit where only 50 routes per one route table can be added. It means that maximum 50 nodes can be added to KuberDock cluster. You can submit a request for an increase a maximum to 100, see Amazon official documentation.


When more than 100 nodes needed, Amazon VPC shouldn’t be used. For this purpose KuberDock should be deployed not by means of AWS KD deploy script which creates VPC, but by running script at instances created and prepared before. During the deployment, VXLAN should be explicitly specified as a backend