Understanding the Kubernetes Cluster Architecture
As part of the Lab start-up procedure, this Lab provisions a fully functional and secure Kubernetes cluster. It takes around 10 minutes to fully provision. In the meantime, you will review the architecture of the cluster to prepare for the Lab.
There are many ways to quickly create ready-to-use Kubernetes clusters. Focusing on public clouds, each cloud provider offers different approaches including:
- Google Cloud Platform: Google Container Engine (GKE, the K is for Kubernetes) is a fully managed solution in Google's cloud.
- Microsoft Azure: Azure Kubernetes Service (AKS) is a fully managed solution in Azure.
- Amazon Web Services: Amazon Elastic Container Service for Kubernetes (EKS) is a fully managed Kubernetes solution in AWS. Additionally, the Kubernetes Operations (kops) command-line utility, and an AWS Quick Start CloudFormation template by Heptio can be used to easily create a cluster.
This Lab builds upon the AWS Quick Start template to create the cluster for this Lab. In what follows, you will learn the features of the architecture and how to interact with the cluster.
The diagram below shows the high-level architecture of the main AWS resources that are provisioned:
All of the nodes are in a single availability zone. This is the recommended architecture for creating highly-available clusters. Each availability zone has a replicated cluster, and load balancing is performed across the availability zones. Kubernetes cluster federation is another option for managing multiple clusters. Further discussion of configuring highly-available Kubernetes clusters is outside of the scope of this Lab.
The Kubernetes nodes and master exist in a private subnet; this is a security best practice. To access Kubernetes applications from outside of the cluster, you can use Kubernetes Services with a load balancer. Kubernetes will provision an elastic load balancer (ELB), and automatically configure the load balancer to distribute requests to the appropriate cluster nodes.
The nodes are contained in an Auto Scaling group. No Auto Scaling policies are created, but it would be easy to dynamically size your cluster in production. The launch configuration of the Auto Scaling group runs scripts to automatically join new nodes to the cluster.
A bastion host is provided for connecting to the master and nodes in the private subnet. This is the EC2 instance you will SSH into. It will have the name bastion-host in the EC2 instances list. All the instances are running Ubuntu Linux. Therefore, you will use the SSH user name ubuntu when you log in to the bastion host with SSH.
There are a few options for managing the cluster:
- SSH into the master node through the bastion host and use
kubectlon the master. SSH agent forwarding makes this easy to accomplish.
- Run kubectl on the bastion host, and configure it to connect to the
API serveron the master
- Use proxy mode of
kubectlto access the
API serverthrough the bastion host from clients outside of the VPC
- Access the Kubernetes API server through a load balancer
In this Lab Step, you reviewed the resources that are provisioned for you in this Lab. In the upcoming Lab Steps, you will log in to the bastion host (instance name bastion-host). Remember to use the user name of ubuntu when connecting.