Understanding the Kubernetes Cluster Architecture

Lab Steps

Logging in to the Amazon Web Services Console
Understanding the Kubernetes Cluster Architecture
Connecting to the Kubernetes Cluster Through a Bastion Host
Configuring Kubernetes Authentication
Configuring Kubernetes Authorization
Configuring Kubernetes Network Policies
Using Kubernetes Pod Security Contexts
Working with Kuberenetes Secrets
Validate AWS Lab
Need help? Contact our support team

Here you can find the instructions for this specific Lab Step.

If you are ready for a real environment experience please start the Lab. Keep in mind that you'll need to start from the first step.


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:

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 kubectl on the master. SSH agent forwarding makes this easy to accomplish.
  • Run kubectl on the bastion host, and configure it to connect to the API server on the master
  • Use proxy mode of kubectl to access the API server through 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.