Tutorial Highlights & Transcript
00:00 - Intro
00:20 - What is EKS Anywhere?
01:30 - Overview of EKS Anywhere
03:14 - What are we Building?
04:20 - Demo - Setting up EKS Anywhere
The first thing we need to do is we need to set up our trust. We’re going to set it as an environment variable. To start provisioning a cluster again, we use CTL Anywhere, then the first thing is to generate the config. Use our cluster name. And then we need to tell it which type of cluster we’re provisioning. And that’s done with a provider. As I was mentioning before, the only two setups right now are either a local development cluster using Docker, or vSphere, or the regular AWS cluster using EKSCTL. Alright, so in this case, I’m going to say my provider is Docker. And this will output a configuration file, and we’re just going to save it to what’s there. This generated a file, we can see it here, demo. If I open this, this will look very, very similar to a normal EKS CTL cluster, and it’s configuring things like the network, the version, and the number of worker nodes, as you can see, here, it’s 122, Kubernetes version and worker count is one. And that’s it. This is a super simple one because it’s in Docker. If you tried to do one with vSphere, that configuration file is a bit larger because it includes VMware-specific configurations that you need to modify here after generating the file like credentials and things like that. But for Docker, it’s simpler, of course. Now that we have this file here, the cluster configuration. We can do EKS CTL Anywhere. Now the command would be Create cluster and you give it a file. It will be Demo.YAML.
This part right here, it can take up to 20 minutes, maybe depending on where you’re running it. For me, it has taken between 15 and 20 minutes for the times I’ve tested this, so we’re not going to wait 15 minutes. If we exit this folder, you’ll see that I already have some other things here. This Friday demo, EKSAnywhere.YAML, was the cluster configuration file I generated before. This one is the same thing we just saw inside the demo folder. It’s just the one I created before. And once you run the Create cluster command, it will provision the cluster using Docker. If we do Docker ps here, for example, you see I have some containers running. And if you notice there’s also this demo folder I created when we started just to do the initial point. But we have this Friday demo EKS Anywhere folder. And that was created after I ran the Create cluster command. In there, we have some more configurations. But this is the important one. The Kube config file for this cluster is inside that folder. To be able to run Kube CTL commands against that local cluster, I need to export my Kube config. I’m going to export this. It’s my current directory. Then the folder with the cluster name and then the Kube config file here. Now that is exported, I can do Kube CTL commands, and those should work. For example, get namespaces.
Now that it’s properly configured, I can run Kube CTL commands, you can see here we have quite a few namespaces. We can also check for running thoughts to check in all namespaces. This is what’s currently running. It’s just a cluster requirement. The Kube proxy, the API server, and some extra things that are part of the Anywhere in the EKS Anywhere cluster bootstrapping. This is a fully functional Kubernetes cluster already. Granted, it’s not a super-powerful cluster right now because it’s running on a laptop, but you get the idea.
13:10 - Deploying EKS Connector into EKS Anywhere Cluster
On those, by default, it will have the current user that ran the command, that’s the user that will be allowed to see the workloads connect to the cluster. What we do there is we edit those files to include any other IAM users or IAM roles that we want to have access to the cluster in the AWS console. And then we apply those manifests. That creates a bunch of things like secrets, config maps. Now we have some more files here. And this last blue line gives us a command. It says from Kube CTL apply EKS Connector yellow, because Connector cluster role and EKS Connector console dashboard full access. This one is Connector. This one, we don’t have to modify anything. This is just the deployment of the Connector pod and a bunch of config maps or secrets or somewhere in here there is a token that was generated by AWS when you do it manually, you add cluster here register at the end. We’ll put a token in the files and that token lasts for like three days. you have three days to register your cluster. And if you don’t do it on those three days, then you have to run the register command again to get a fresh token. All that is here now. No need to modify this one. We do need to modify the cluster role. Here it’s just the permissions to be able to do stuff in the cluster from AWS to be able to see things so what I’m going to put here is the role the SSL role that we use in AWS. We say this and the other one is the dashboard full access. Again, this is just permissions. And here you can see my user is already set if we want to add the role just add another block. Remember we didn’t have any cluster here before running the register. Now if we refresh we have the Friday demo Anywhere cluster but it’s pending and it will remain on a pending state until we apply these files. Okay, so everything was created. Now we should have some new pods trying to start. Here we have the EKS Connector pod. It’s initializing which gives it a few seconds to complete. Okay, almost there, we have the first one started. And I think the first one is enough for it to show. Now we have our cluster name here for the demo Anywhere. It’s on its status of active we can see the version. And on the provider, we can see this is an EKS Anywhere cluster.
Here we can see this cluster has two notes running, and we can see the current resources. The same stuff you will be able to see on a regular EKS cluster, but this is not running on AWS. This is running an on-premise machine. I forgot to show you this. This is when you run the EKS Anywhere create cluster command. This is what you see. I took a screenshot because as I mentioned, it takes like 15 minutes to complete. But yeah, this is the output of that.
DevOps Team Lead
Carlos has been a Senior DevOps Engineer at nClouds since 2017 and works with customers to build modern, well-architected infrastructure on AWS. He has a long list of technical certifications, including AWS Certified DevOps Engineer - Professional, AWS Certified Solutions Architect - Professional, and AWS Certified SysOps Administrator - Associate.