Accessing the Cluster: Understanding the Protocol
In this lesson, we will figure out how the different components in our cluster are communicating with each other and what we need to establish our communication with the worker nodes.
We'll cover the following
Exploring the AWS ELB#
We need a way to access the cluster. So far, we saw that we can, at least, interact with the Kubernetes API. Every time we executed kubectl, it communicated with the cluster through the API server. That communication is established through AWS Elastic Load Balancer (ELB). Let’s take a quick look at it.
The output, limited to the relevant parts, is as follows.
Judging from the Listener section, we can see that only port 443 is opened, thus allowing only SSL requests.
The three instances belong to managers. We can safely assume that this load balancer is used only for the access to Kubernetes API. In other words, we are still missing access to worker nodes through which we’ll be able to communicate with our applications. We’ll come back to this issue in a moment.
The entry that matters, from user’s perspective, is DNSName. That is the address we need to use if we want to communicate with Kubernetes’ API Server. Load Balancer is there to ensure that we have a fixed address and that requests will be forwarded to one of the healthy masters.
Finally, the name of the load balancer is api-devops23-k8s-local-ivnbim. It is important that you remember that it starts with api-devops23. You’ll see soon why the name matters.
Looking into the kubectl Configuration#
We can confirm that the DNSName is indeed the door to the API by examining kubectl configuration.
The output, limited to the relevant parts, is as follows.
We can see that the devops23.k8s.local is set to use amazonaws.com subdomain as the server address and that it is the current context. That is the DNS of the ELB.
The fact that we can access the API does not get us much closer to having a way to access applications we are soon to deploy. We already learned that we can use Ingress to channel requests to a set of ports (usually 80 and 443).
However, even if we deploy Ingress, we still need an entry point to the worker nodes. We need another load balancer sitting above the nodes.
Fortunately, kops has a solution for this.
In the next lesson, we will add a load balancer to establish communication with the nodes in our cluster.
