Installation using Kubespray¶
The guide is to use Kubespray for creating an AWS Kubernetes cluster running Cilium as the CNI. The guide uses:
- Kubespray v2.6.0
- Latest Cilium released version (instructions for using the version are mentioned below)
$ git clone --branch v2.6.0 https://github.com/kubernetes-sigs/kubespray
Install dependencies from
$ cd kubespray $ sudo pip install -r requirements.txt
We will use Terraform for provisioning AWS infrastructure.
Configure AWS credentials¶
Export the variables for your AWS credentials
export AWS_ACCESS_KEY_ID="www" export AWS_SECRET_ACCESS_KEY ="xxx" export AWS_SSH_KEY_NAME="yyy" export AWS_DEFAULT_REGION="zzz"
Configure Terraform Variables¶
We will start by specifying the infrastructure needed for the Kubernetes cluster.
$ cd contrib/terraform/aws $ cp contrib/terraform/aws/terraform.tfvars.example terraform.tfvars`
Open the file and change any defaults particularly, the number of master, etcd, and worker nodes. You can change the master and etcd number to 1 for deployments that don’t need high availability. By default, this tutorial will create:
- VPC with 2 public and private subnets
- Bastion Hosts and NAT Gateways in the Public Subnet
- Three of each (masters, etcd, and worker nodes) in the Private Subnet
- AWS ELB in the Public Subnet for accessing the Kubernetes API from the internet
- Terraform scripts using
CoreOSas base image.
#Global Vars aws_cluster_name = "kubespray" #VPC Vars aws_vpc_cidr_block = "XXX.XXX.192.0/18" aws_cidr_subnets_private = ["XXX.XXX.192.0/20","XXX.XXX.208.0/20"] aws_cidr_subnets_public = ["XXX.XXX.224.0/20","XXX.XXX.240.0/20"] #Bastion Host aws_bastion_size = "t2.medium" #Kubernetes Cluster aws_kube_master_num = 3 aws_kube_master_size = "t2.medium" aws_etcd_num = 3 aws_etcd_size = "t2.medium" aws_kube_worker_num = 3 aws_kube_worker_size = "t2.medium" #Settings AWS ELB aws_elb_api_port = 6443 k8s_secure_api_port = 6443 kube_insecure_apiserver_address = "0.0.0.0"
Apply the configuration¶
terraform init to initialize the following modules
$ terraform init
Once initialized , execute:
$ terraform plan -out=aws_kubespray_plan
This will generate a file,
aws_kubespray_plan, depicting an execution
plan of the infrastructure that will be created on AWS. To apply, execute:
$ terraform init $ terraform apply "aws_kubespray_plan"
Terraform automatically creates an Ansible Inventory file at
Installing Kubernetes cluster with Cilium as CNI¶
Kubespray uses Ansible as its substrate for provisioning and orchestration. Once the infrastructure is created, you can run the Ansible playbook to install Kubernetes and all the required dependencies. Execute the below command in the kubespray clone repo, providing the correct path of the AWS EC2 ssh private key in
ansible_ssh_private_key_file=<path to EC2 SSH private key file>
We recommend using the latest released Cilium version by editing
roles/download/defaults/main.yml. Open the file, search for
cilium_version, and replace the version with the latest released. As an example, the updated version entry will look like:
$ ansible-playbook -i ./inventory/hosts ./cluster.yml -e ansible_user=core -e bootstrap_os=coreos -e kube_network_plugin=cilium -b --become-user=root --flush-cache -e ansible_ssh_private_key_file=<path to EC2 SSH private key file>
To check if cluster is created successfully, ssh into the bastion host with the user
# Get information about the basiton host $ cat ssh-bastion.conf $ ssh -i ~/path/to/ec2-key-file.pem core@public_ip_of_bastion_host
Execute the commands below from the bastion host. If
kubectl isn’t installed on the bastion host, you can login to the master node to test the below commands. You may need to copy the private key to the bastion host to access the master node.
$ kubectl get nodes $ kubectl get pods -n kube-system
You should see that nodes are in
Ready state and Cilium pods are in
Deploy the connectivity test¶
You can deploy the “connectivity-check” to test connectivity between pods.
kubectl apply -f https://raw.githubusercontent.com/cilium/cilium/1.8.1/examples/kubernetes/connectivity-check/connectivity-check.yaml
It will deploy a series of deployments which will use various connectivity paths to connect to each other. Connectivity paths include with and without service load-balancing and various network policy combinations. The pod name indicates the connectivity variant and the readiness and liveness gate indicates success or failure of the test:
NAME READY STATUS RESTARTS AGE echo-a-5995597649-f5d5g 1/1 Running 0 4m51s echo-b-54c9bb5f5c-p6lxf 1/1 Running 0 4m50s echo-b-host-67446447f7-chvsp 1/1 Running 0 4m50s host-to-b-multi-node-clusterip-78f9869d75-l8cf8 1/1 Running 0 4m50s host-to-b-multi-node-headless-798949bd5f-vvfff 1/1 Running 0 4m50s pod-to-a-59b5fcb7f6-gq4hd 1/1 Running 0 4m50s pod-to-a-allowed-cnp-55f885bf8b-5lxzz 1/1 Running 0 4m50s pod-to-a-external-1111-7ff666fd8-v5kqb 1/1 Running 0 4m48s pod-to-a-l3-denied-cnp-64c6c75c5d-xmqhw 1/1 Running 0 4m50s pod-to-b-intra-node-845f955cdc-5nfrt 1/1 Running 0 4m49s pod-to-b-multi-node-clusterip-666594b445-bsn4j 1/1 Running 0 4m49s pod-to-b-multi-node-headless-746f84dff5-prk4w 1/1 Running 0 4m49s pod-to-b-multi-node-nodeport-7cb9c6cb8b-ksm4h 1/1 Running 0 4m49s pod-to-external-fqdn-allow-google-cnp-b7b6bcdcb-tg9dh 1/1 Running 0 4m48s
If you deploy the connectivity check to a single node cluster, pods that check multi-node
functionalities will remain in the
Pending state. This is expected since these pods
need at least 2 nodes to be scheduled successfully.
$ cd contrib/terraform/aws $ terraform destroy