← AWS Podcast
AWS Podcast
#732: How to gain Multi-Cluster Visibility across Kubernetes Clusters with the EKS Dashboard
00:24:53
In this episode, we'll explore how the new Amazon EKS Dashboard solves key challenges in managing Ku
Loading summary
Transcript31 lines
- [00:00]
Shruti
This is episode 732 of the AWS podcast, released on August 4th, 2025. Hello everyone. Welcome to another episode of the AWS Podcast. In today's episode, we are going to dive deep into how you can centralize visibility of your Kubernetes clusters across AWS regions and accounts with EKS Dashboard. This is a new capability that the team has launched recently, and joining me to talk about it is Sriram Ranganathan. Welcome Sriram. Can you introduce yourself?
- [00:38]
Sriram Ranganathan
Hey Shruti. Nice to be here. I'm a product manager working on Amazon. EKS focus on multiple features like add ons upgrades, control plane and multi cluster. And EKS Dashboard is one of the features that my team recently launched in them. Happy to be here talking about this feature.
- [00:55]
Shruti
Great. All right, well, let's dive right in. So first, taking a step back, what are some of the challenges that teams and organizations typically face when they are managing multiple Kubernetes clusters, and especially across different AWS accounts and across different regions?
- [01:18]
Sriram Ranganathan
Yeah, that's a really great question. So when we talk to our customers, what we see is customers usually start off with a handful of clusters, and as their business grows and their business needs grows, they slowly expand to multiple different clusters, either within the same account or in different accounts, either within the same region or across different regions for various needs. It could be for scalability needs, it could be for data residency needs, it could be for resiliency purposes. The ends are needless. And what we typically hear from our customers is as their fleet of Kubernetes cluster grows, they soon start losing visibility into the different clusters that are running within their organization. So governance becomes a problem. And keeping up to date on security for all of those clusters also becomes quite a big of a problem. Because with Kubernetes, because of the open source nature, you need to keep those clusters and any other affiliated resources up to date. And without having the centralized visibility, customers do not know what their exposure to is or what their current security landscape looks like. So let's take the example. If I have like 200 or 300 different clusters running across different accounts and regions, how do I know which version of Kubernetes those clusters are running on, which accounts are hosting those clusters, which regions are running those clusters, what versions are they running on, and what is my timeline before which I should update those clusters? So that is a classic example of a visibility challenge that most customers run into. That is just one example. And that's not the only example and other example of a challenge that we Typically ask from customers is like Kubernetes has this plug and play nature. So by default, in order to make a Kubernetes cluster production ready, you need to add a lot of add ons, like the networking add ons, the storage add ons, observability add ons and each of them come with multiple different versions. So let's say for example, on an average I'm using 10 add ons per cluster and each of them are running on different versions. How do I know if tomorrow there is a CV for an add on? What is my exposure across different clusters? So that is another challenge that we typically hear from customers. So this dashboard is aimed at answering some of those questions, basically giving you the 10,000ft view of your entire Kubernetes clusters, the different managed node groups, the different EKs add ons, and what are the metadata and properties associated with those so that you can quickly dive deep, figure out what is your impact and quickly address those challenges.
- [03:54]
Shruti
Right, right. So big challenges you're trying to solve are fragmented visibility across accounts, across regions. It, you know, kind of brings up this visual of trying to manage multiple like bridges, branch offices without a single headquarters. And so this is trying to give that centralized visibility. And then also it sounds like it also is a way to ensure consistent best practices across different accounts, across different regions and so on and so forth.
- [04:24]
Sriram Ranganathan
That is right. It gives you essentially the single pane of class view, allowing you to govern and do operational planning. So if you have to upgrade clusters, you really need to plan because you need to upgrade the applications, you need to look at what could break if I upgrade my cluster and and plan. So this gives you at least the visibility into, okay, what are the clusters that I need to immediately focus on? What are the different properties? Are they meeting my internal guidelines? So let's say, for example, I require all of the production clusters to be enrolled, let's say for example, in zonal shift auto configuration. So how do I know which of my clusters are not following zonal shift practices for resiliency purposes? So I can quickly dive deep and figure those things out. So there are a lot of these dimensions across which you can look at your entire Kubernetes fleet and see if they are following your organizational standards, best practices and other things.
- [05:15]
Shruti
Awesome. Okay, so let's get into the specifics now. Right. Can you maybe walk us through some key capabilities and features of the EKS dashboard and how they help solve these challenges? It will be. I know that a dashboard is such a visual sort of a Service and a product. So it might be a little tricky, but if you maybe can call out specific features and what and why they were built, that would be really helpful.
- [05:46]
Sriram Ranganathan
Okay, we'll start off with the most common request that we get, which is visibility across your entire Kubernetes clusters broken down by different versions. Customers definitely want to know If I have 200 or 300 different clusters running, what is the distribution of those clusters by different versions so that anything that is at the tail end of the cluster version lifecycle, I want to keep them upgraded. That is one. The other use case that we are trying to address is EKS comes in two levels of upgrade policy support. One we call as the standard support and then there is the extended support. There is a price difference between what is in standard support versus what is in extended support. So if you are not keeping your plus states up to date and you have enrolled in extended support, I definitely want to know which are those clusters because I'm paying additional for those clusters and we want to upgrade them first. So how do I know which clusters are running on extended support? The other challenge that we are also trying to address is like depending on the upgrade policy that your clusters are enrolled in, whether it is standard versus extended. If you do not upgrade those clusters within the end of support date or end of extended support days, EKS automatically auto upgrades the control plane of those clusters. How do I know within the next 30 days, 60 days or 90 days which clusters are going to get auto upgraded by EKS if I do not take an action today? And that is like an expandable time view, you can adjust the time frame to look at. Okay, in the next six months I want to see which clusters are going to get auto upgraded. You can always adjust that. If you want the one year view, you can always do that. So that is one more use case that I can think of like that there are various other use cases at a cluster level. Some of the other use cases that we get is as an organization, we do not like any of our production Kubernetes clusters to have Kubernetes API server have a public access. I want to see how many clusters have public access endpoints because I want to disable it. How do I easily identifying it without diving into each cluster? Can you give me a broad level view? So that is one aspect of the things that we are trying to solve. The other things that we are also trying to solve is we. A Kubernetes cluster comes in three different resources. One is the control plane itself and then There is the data plane which could have like self managed node groups, or you can have node groups that are nodes that are managed by karpenter, or you can have managed node groups. Essentially we are trying to provide a view from the perspective of managed node groups because that is One of the APIs that we provide and we have visibility into the metadata surrounding those managed node groups. So let's say for example, you want to see the distribution of managed node groups by different kubernetes version. You can view that through this dashboard as well. Another use case is with respect to finding the distribution of different army families. So let's say for example, you want to find different node groups that are running different types of armies. You can always do that. Be it the bottle rocket army, the AL2 army, the AL 2023 Army. You want to see the distribution of those, you can always visualize that and dive into those specific node groups. Or let's say for example, a particular version of an army has some kind of a cv. You want to identify which are those node groups and upgrade them. You can see the distribution by different army versions. Click on them and it will give you the exact exposure of that army across different node groups in different clusters. The same thing can be extended to add ons. Each cluster might be running 10 to 15 different add ons. How do you know like which add ons are running on which cluster? Which versions of add ons are running on which clusters? I can always see that directly from the dashboard. And the good part is, while it starts off with an aggregated view, you can click on that aggregated view and it exactly filters down to the set of affected resources.
- [09:40]
Shruti
Awesome. Awesome. One follow up question I have here is, does the dashboard also provide some cluster health metrics or not?
- [09:53]
Sriram Ranganathan
Yes, it does provide the low severity cluster health issues directly through the dashboard. So let's say for example, if your clusters are running out of IP addresses, or if your node group has certain health issues, or if your add on has health issues in terms of insufficient number of replicas or any other health issues, you can visualize it directly from the dashboard and then you can take action on them to fix those.
- [10:18]
Shruti
Right? Awesome. Now you also did kind of talk about two different types of EKS modes. The one that where customers have to pay a little bit more. Can you just repeat that for a second? Because I had a follow up on that.
- [10:35]
Sriram Ranganathan
Sure. So EKS cluster has a defined life cycle. By default we enter every cluster when it is released. A new version is released, it goes in, starts off in standard support. So that goes on for about 14 months and then after 14 months it enters into extended support for the next 12 months. So total lifecycle is 26 months. During the first 14 months you pay the standard support charges, which is $0.10 per hour for cluster management fee. Beyond the 14 months, if you have not upgraded the cluster and if it is enrolled in extended support, then you pay an additional $0.50 for the same cluster. So it's a total of $0.60 per hour starting from that period onwards.
- [11:18]
Shruti
Right, right. So I mean it sounds like the dashboard can help teams forecast and manage these extended support costs. Does it actually go give them this cost like forecasted cost information or does it just show, hey, these are the clusters that are all the extended support that are signed up for extended support and kind of leaves the bath to the customers?
- [11:42]
Sriram Ranganathan
That is a great question. The answer is yes and yes to both. It gives you the breakdown of clusters which are enrolled in extended support versus clusters which are just on standard support. Additionally, we also forecast and show like, if you leave these clusters in extended support for the next 30 days, what is the additional control train management fee that you are looking at for 60 days? What is that additional charges? And we give the projection for up till one year. In that one year, let's say, for example, within a specified timeframe that you are interested in, there might be clusters that are going to enter into extended support, in which case we prorate and automatically adjust the calculation to give you a ballpark in terms of what is the cluster management fee that you're looking at. One thing to note is this is just focusing on the EKS charges. This is not focusing on the additional nodes EC2 instances that might be attached to your cluster. So this is purely focused on EKS charges.
- [12:39]
Shruti
Right, Right. That clarification is extremely important.
- [12:43]
Sriram Ranganathan
Yes.
- [12:44]
Shruti
Okay, so that was the one follow up and then the second follow up I had was you did talk about sort of, you know, being able to upgrade versions and things like that. What role does dashboard play in planning and executing these cluster upgrades? Is it primarily sort of this, you know, information that it surfaces about what version each cluster is on or is there any sort of capabilities around being able to plan for cluster upgrades at a certain cadence?
- [13:15]
Sriram Ranganathan
Yeah, so there are two different things. One is obviously giving you a quick inventory of things that you should focus on. So let's say you are upgrading from 129 to 130 clusters and you want to plan and see how many clusters are there on version 129, you can simply go to the dashboard, click on the clusters which are showing 129. It gives you the full inventory of clusters that you need to focus on. But it does not stop there. It also gives you for each clusters, are there any upgrade insights which will affect the cluster when you upgrade it? What I mean by that is Upgrade insights is a feature which was launched about a couple of years back. It tells you like if you upgrade the cluster without focusing on certain things, will the cluster upgrade break? Are there going to be errors associated with the cluster? Are there going to be warnings associated to the cluster? That's called as upgrade insights. So the dashboard also tells you for each of the clusters, are there any error level upgrade insights? Are there any warning level upgrade insights? Are there any unknown level upgrade insights so that you can look at those and then plan your upgrades.
- [14:16]
Shruti
Makes sense. And then one last thing. Can you maybe double click on the add on management across multiple clusters? You mentioned that earlier, but it would be good to get one level deep in.
- [14:29]
Sriram Ranganathan
That sounds good. So you can think about add ons as operational capabilities that you add to a kubernetes cluster. So kubernetes cluster itself, when you create a cluster, it's not production ready. You need to add a lot of these capabilities to your cluster to make it production ready. As an example, you need let's say a EBS CSI driver for you to use block storage. You need an EFS CSI driver to use some kind of file storage. You might use CloudWatch agent to basically have observability capabilities. Or you might install something like an OPA Gatekeeper or Kiverno for policy management, other things. So there are a lot of these additional capabilities that you add. So you can think about add ons as these capabilities that are adding additional functionality to your kubernetes cluster. And each cluster might have 10 to 15 different functions like these. So let's imagine if you have 200, 300 different clusters and you have 1015 different add ons running, all of them might be using different set of add ons. How do you know like what add ons are running on which cluster? So let's say tomorrow, if one version of let's say EBS CSI driver has some kind of a vulnerability and you want to upgrade it to the next version. How do you quickly identify without going into each cluster to figure out what is my exposure? I don't want to query 300 different clusters to figure out what version of EBS CSI is running. So you can come here, you can just Go to the exact affected version, you can filter by that and see which clusters are hosting those. That will allow you to immediately take an action. So you save a lot of time in terms of figuring out your exposure of different components across different clusters.
- [16:13]
Shruti
That's awesome. That's awesome. Actually, that's a really good segue into my next question, which is it sounds like there's lots of great filtering, sorting kind of functionality available to create whatever view that is useful for the operator. What are some of the reporting and export capabilities that are available for teams that are wanting to do this sort of a deeper analysis or report it out to their, you know, to their leaders or whatever, what have you?
- [16:44]
Sriram Ranganathan
Yeah, so while this feature is a console only feature with no SDK or API access, but we do have an ability wherein you can download the entire data set directly from the console. So it's an export to CSV option which will allow you to get hold of the entire data and then you can ingest it into any visualization tool of your choice. Or if you are only interested in a specific set of affected resources, you can apply the filters within the dashboard and just export that filtered view. So you have both the options. So depending on your use case, you can choose to either download the entire data set or narrow it down to your specific filtering criteria and then export that particular data and then you can ingest it with any other visualization tool, if that's your preference.
- [17:33]
Shruti
Right, right. And so you can do it, download it into a CSV file and it could be filtering on specific regions or accounts. This filtering, at least in many cases, is also available in console like you are. You can still do it there, but. But if you want it offline into a different tool, you can do that through this CS port. Okay, so these are some really useful capabilities. And as you might imagine, organizations may not want everyone in the organizations to have access to EKS Dashboard. So how does Dashboard integrate with AWS organizations and what is involved in setting it up? How does it all work?
- [18:20]
Sriram Ranganathan
Sounds good. Yeah, that's a really good question. So this feature natively works in integration with AWS organizations. So only if your accounts are nested under AWS organizations, you will be able to use this feature. So if there is an account that is a standalone account outside AWS organization, this feature will not be available to such accounts. So, so imagine an organization which has like hundreds of accounts nested under AWS organizations, and you want access to this particular dashboard, all you need to do is log into the AWS organization's Management account. And there is a one time enablement of this feature. You click on a button called as Enable Trusted Access from the Dashboard Settings page and that basically allows EKs to create SLR for us to render the Dashboard. So you can just stop there and start accessing the Dashboard. But as a best practice, we recommend that you do not use the Management account for accessing the Dashboard because Management account has lot more privileged capabilities. So that's where the concept of a delegated administrator account comes in. A delegated administrator account can be any account within the AWS organization that you can choose and nominate as the delegated admin. What it essentially means is you're giving it some some admin functions for the EKS service. In this case, the admin function is viewing the Dashboard. It does not have any other privileges other than viewing the Dashboard, and you can use the delegated administrator to start accessing this particular dashboard. So essentially two accounts get access per organization. The management account by default gets access once it enables trusted access. And once you enroll a delegated admin account, that account will also start getting the same view and you can start using that particular account for viewing the Dashboard going forward.
- [20:08]
Shruti
Awesome. Great. That is really helpful to know of how to operationalize this. So in closing, because we've been chatting for a while now, I'm curious sort of what else is on the roadmap for EKS dashboard? What else can you share about it?
- [20:29]
Sriram Ranganathan
Sure. So after the initial rollout, we have been focusing on improving the widgets in terms of the verbiage and adding some more insights to the dashboard itself. So any improvements to the widgets, that will keep happening on a rolling basis. Other than that, we also have a feature wherein we many customers have asked us how can we reduce the scope of this particular dashboard? By default, it gives the view of the entire organization, but I might have different organizational units within my organization and how do I reduce it? So we are working on a feature called as Scope Delegated Administrator, wherein you can define multiple different delegated administrators, each of which can have its own scope in terms of what visibility they get from the organization. So that will give you a restricted view of the organization. So if you have like different organizational units that just want to look at their clusters, it'll allow you to slice and dice by that dimension. So we are working with other AWS service teams to make that particular feature generally available. But that's something that's definitely on the roadmap.
- [21:39]
Shruti
Awesome. One question I had, which I don't know if it pertains to the roadmap. Maybe it is true today, but I know that was likely at re invent that we launched support for EKS hybrid nodes. Does the dashboard also give you visibility into everything that you said for those hybrid nodes, sort of a setup?
- [22:06]
Sriram Ranganathan
The answer is yes and no. In terms of whether you will be able to see which clusters are enrolled in hybrid nodes, feature or auto mode features, that is work in progress. So we would definitely be able to provide a distribution in terms of how many clusters are using auto mode or how many clusters are using hybrid nodes. That's a feature that is going to come out probably within the next three months. It does not go into the specifics of what those hybrid nodes are made up of, similar to what you see with managed node groups. So the visibility will be restricted to just the cluster level view, which shows okay, how many clusters are enrolled in hybrid nodes. So that's precisely what we are working on. Hybrid nodes similar to self managed nodes is very difficult for us to figure out the different properties of an hybrid node because this they are not exactly provisioned using our APIs, so we have limited visibility into those. But anything that is provisioned as a managed node group, we definitely have more visibility into it and we can give you the high level properties that will allow you to start planning your operational activities.
- [23:11]
Shruti
Awesome. Okay, well this was a really great sort of technical deep dive into what all the capabilities of EKS Dashboard are. If our listeners want to learn more about how to get started with EKS Dashboard, what should they use, where should they go?
- [23:31]
Sriram Ranganathan
Yeah, so we have like multiple launch materials that are available to you. You can just search for the EKS Dashboard launch blog and we also have a deep dive blog or the other place to get started is you can go to the EKS User Guide. There is a dedicated page for EKS Dashboard. You can refer to it in terms of how to set it up and as you start using it, if you have any feedback, feel free to reach out to us. Our roadmap is public so you can go to GitHub, go to containers Roadmap and directly provide your feedback to the service team on this particular feature. And we would be happy to engage you with respect to your feedback and see how, what we can prioritize and when we can prioritize it. Or if you prefer to engage through your account team, that's also fine. Please keep your feedback coming. That is what will help us improve the product.
- [24:22]
Shruti
Yes, we are very customer obsessed as you just heard Sriyam say. So we will drop links for all of those resources on the podcast in the show notes for the podcast. And yes, please reach out with feedback through whichever mechanism best works for you. All right. Well, thank you so much, Sriyam, for joining, and thank you to our audience for tuning in. Until next time, keep on building.