Sometimes I have trouble because, in our corporate network, there are various networks, etcetera. It's difficult to connect to some of the clusters, and it's easier to go through the UI when troubleshooting something. At some points, the UI seems limited to me with the functions it provides. You can get information like what kind of port is running on the cluster, but I haven't really explored the UI so far, so it's difficult for me to see the logs, for example. Or sometimes, you are only limited to the basic Kubernetes things. We have certain customizations installed in the cluster, and for that, you really have to use kubectl from the command line. You are not able to use the EKS UI to list certain custom resources. So maybe there can be some kind of improvement, but maybe it's just me that I haven't really explored the UI that much.
I would like to see a warm-up time for AWS Fargate, similar to what GCP Cloud Run has. This would improve internal security. I would also really love to see lower costs compared to other cloud vendors. AWS can get quite expensive.
The main thing to improve with Amazon EKS is the price. However, these services can be very expensive. For example, in countries like Turkey, the cost is too high. That's why we offer our cloud solutions locally. We developed hybrid solutions, but their prices are still very high.
When it comes to Amazon EKS, there are IAM permissions and RBAC. When you create an IAM user, you give the privileges on the cluster level, but there won't be anything inside the clusters. In the clusters and their respective files, you will have to map the IAM user created with the help of AWS. The documentation part of the product is an area of concern that needs to be made easier from an improvement perspective.
Assigning roles and responsibilities to interact with a created cluster as a user over a command prompt is cumbersome on AWS. Initially, we create a user to interact with a cluster. Since everyone can't use the cluster, we need to assign some permissions to that specific user. It is very cumbersome to assign permissions to users to interact with a cluster. We always get errors, and it takes many days to resolve that permission issue before the user can start interacting with the cluster.
If you compare Amazon EKS with OpenShift, the latter provides users with a solution that is fully managed through automation. Amazon EKS is not a solution that can be fully managed through automation, making it an area of concern where improvement is required. Amazon EKS should be manageable through a web portal or web interface, a feature that exists in OpenShift. Amazon EKS should be available as a fully managed service since we use Helm chart to deploy the product in our company right now. The initial setup phase of the product is an area where certain improvements can be made.
Amazon EKS provides very minimum information during the upgrade of the node group. When the upgrade doesn't work well, it doesn't give enough information for us to troubleshoot. So it would be great if Amazon EKS provided more information in such cases. Amazon EKS should enable some AIOps.
Specialist Data Analysis vehicle safety at Cubeware
Real User
2022-10-27T13:01:20Z
Oct 27, 2022
We have problems with setting up virtual environments and installing the right packages. I believe the initial setup could be a better experience and faster customer support.
The solution should include a popup for clusters so that all relevant information is visible at the bottom of a page. When clusters exist or are running, there isn't much detail on the first phase so navigating and clicking on different options is required to search for relevant information.
Cloud Architect & Devops engineer at KdmConsulting
Real User
2022-07-09T03:27:16Z
Jul 9, 2022
The main area of improvement is that a cluster is required on-premises, which takes a lot of time. For example, we must drain the total nodes during an upgrade from version 1.21 to version 1.22 with on-premises. After draining the total nodes, our container will shut down, and it will be recreated after upgrading. But with the AWS Kubernetes Services, the upgrade from version 1.21 to 1.22 is completed with one click. It's straightforward for the users. In any secure services, nodes are working on the EC2 services. Whatever the EC2 services, the specified AMI is available. This AMI is an auto-security package that is automatically upgraded per the company's need. It is also secure.
Materials Program Management Specialist at a manufacturing company with 10,001+ employees
Real User
2021-10-26T22:03:02Z
Oct 26, 2021
Amazon EKS is predominately public. However, the government has started to have a lot of interest in Kubernetes and is receiving more education on Kubernetes and Amazon EKS. If we can have the security of Amazon EKS align with the security that is set out by the government it would be much better.
When we switched to EKS, historically it wasn't good. There were issues with bugs in it. They didn't have managed pools, which means small subsections of the clusters that you divided into pools like a mini-cluster in your cluster. However, now they have managed pools. For the last several versions, the issue was with their kind of networking plug-in, the security plug-ins, and things like that. That EKS layer on top of the Kubernetes, they add themselves to each cloud, however, only with fewer standards and a little more issues. They need to work on the Amazon plugins on the Kubernetes cluster. We just updated to a cluster 1.18, but we were on that cluster 1.13 which had many bugs and issues. Moving up to 1.19 in the middle of last year, we had some issues which they had to fix. One thing that is probably not the greatest in Amazon is the ideology. They really want you to stick to cloud tools. They want you to use the managed version of the databases and our preference is to use the Kubernetes-managed databases. This doesn't fit well with the AWS philosophy, which is then passed on to the AWS engineers and they push that, push ideology on us as well, saying "You know what, we want you to use this database." We're not dogmatic. If they want us to use a specific database, we use it, as the cluster is very dynamic. We don't need to deploy a database within a cluster, we can use the cloud database. To us, it's just a connection string, so it's not inefficient for us. It's just based on the client. However, you can see there's a little bit of an ideology dogma baked into the AWS philosophy just to keep you in the cloud.
Amazon Elastic Kubernetes Service (Amazon EKS) is a fully managed Kubernetes service. Customers such as Intel, Snap, Intuit, GoDaddy, and Autodesk trust EKS to run their most sensitive and mission critical applications because of its security, reliability, and scalability.
EKS is the best place to run Kubernetes for several reasons. First, you can choose to run your EKS clusters using AWS Fargate, which is serverless compute for containers. Fargate removes the need to provision and manage...
Sometimes I have trouble because, in our corporate network, there are various networks, etcetera. It's difficult to connect to some of the clusters, and it's easier to go through the UI when troubleshooting something. At some points, the UI seems limited to me with the functions it provides. You can get information like what kind of port is running on the cluster, but I haven't really explored the UI so far, so it's difficult for me to see the logs, for example. Or sometimes, you are only limited to the basic Kubernetes things. We have certain customizations installed in the cluster, and for that, you really have to use kubectl from the command line. You are not able to use the EKS UI to list certain custom resources. So maybe there can be some kind of improvement, but maybe it's just me that I haven't really explored the UI that much.
I would like to see a warm-up time for AWS Fargate, similar to what GCP Cloud Run has. This would improve internal security. I would also really love to see lower costs compared to other cloud vendors. AWS can get quite expensive.
The solution's graphical interface is not the best. It could be better in terms of enabling some integrations or managing the configuration.
The main thing to improve with Amazon EKS is the price. However, these services can be very expensive. For example, in countries like Turkey, the cost is too high. That's why we offer our cloud solutions locally. We developed hybrid solutions, but their prices are still very high.
They could add logging features. At present, we use external tools to increase and decrease the number of instances.
When it comes to Amazon EKS, there are IAM permissions and RBAC. When you create an IAM user, you give the privileges on the cluster level, but there won't be anything inside the clusters. In the clusters and their respective files, you will have to map the IAM user created with the help of AWS. The documentation part of the product is an area of concern that needs to be made easier from an improvement perspective.
Assigning roles and responsibilities to interact with a created cluster as a user over a command prompt is cumbersome on AWS. Initially, we create a user to interact with a cluster. Since everyone can't use the cluster, we need to assign some permissions to that specific user. It is very cumbersome to assign permissions to users to interact with a cluster. We always get errors, and it takes many days to resolve that permission issue before the user can start interacting with the cluster.
I'd like improved traffic handling and additional application details within the system.
The product’s pricing needs improvement.
If you compare Amazon EKS with OpenShift, the latter provides users with a solution that is fully managed through automation. Amazon EKS is not a solution that can be fully managed through automation, making it an area of concern where improvement is required. Amazon EKS should be manageable through a web portal or web interface, a feature that exists in OpenShift. Amazon EKS should be available as a fully managed service since we use Helm chart to deploy the product in our company right now. The initial setup phase of the product is an area where certain improvements can be made.
There is room for improvement in stability. I faced some problems with the App. The problem is actually the app, with the different teams fixing it.
I would like to see a cloud setup bank management feature.
The management of the nodes in Amazon EKS should be improved. AWS should reduce the constant upgrades of the nodes of Amazon EKS or EC2 machines.
I'm having difficulty getting my AWS clusters to communicate with my local machine.
I am not impressed with the tool's Amazon console. It also needs to add security features.
It is challenging to host the applications in the existing VPC of the solution. They should include some essential configuration features to it.
The tool's setup is complex.
Amazon EKS provides very minimum information during the upgrade of the node group. When the upgrade doesn't work well, it doesn't give enough information for us to troubleshoot. So it would be great if Amazon EKS provided more information in such cases. Amazon EKS should enable some AIOps.
An area for improvement in Amazon EKS is the user experience. The platform could be more user-friendly. Only an expert can manage and use it.
The graphical user interface could be better.
They should improve the security and include some cloud-native project integrations. In addition, they should enhance the Jira integration.
We have problems with setting up virtual environments and installing the right packages. I believe the initial setup could be a better experience and faster customer support.
The solution could be improved by adding monitoring, filtering, and logging capabilities to its current CloudWatch features.
The solution should include a popup for clusters so that all relevant information is visible at the bottom of a page. When clusters exist or are running, there isn't much detail on the first phase so navigating and clicking on different options is required to search for relevant information.
The main area of improvement is that a cluster is required on-premises, which takes a lot of time. For example, we must drain the total nodes during an upgrade from version 1.21 to version 1.22 with on-premises. After draining the total nodes, our container will shut down, and it will be recreated after upgrading. But with the AWS Kubernetes Services, the upgrade from version 1.21 to 1.22 is completed with one click. It's straightforward for the users. In any secure services, nodes are working on the EC2 services. Whatever the EC2 services, the specified AMI is available. This AMI is an auto-security package that is automatically upgraded per the company's need. It is also secure.
The connectivity could be better.
There isn't something that is unique or outstanding. I'd like to see the solution add a service catalog.
Amazon EKS is predominately public. However, the government has started to have a lot of interest in Kubernetes and is receiving more education on Kubernetes and Amazon EKS. If we can have the security of Amazon EKS align with the security that is set out by the government it would be much better.
When we switched to EKS, historically it wasn't good. There were issues with bugs in it. They didn't have managed pools, which means small subsections of the clusters that you divided into pools like a mini-cluster in your cluster. However, now they have managed pools. For the last several versions, the issue was with their kind of networking plug-in, the security plug-ins, and things like that. That EKS layer on top of the Kubernetes, they add themselves to each cloud, however, only with fewer standards and a little more issues. They need to work on the Amazon plugins on the Kubernetes cluster. We just updated to a cluster 1.18, but we were on that cluster 1.13 which had many bugs and issues. Moving up to 1.19 in the middle of last year, we had some issues which they had to fix. One thing that is probably not the greatest in Amazon is the ideology. They really want you to stick to cloud tools. They want you to use the managed version of the databases and our preference is to use the Kubernetes-managed databases. This doesn't fit well with the AWS philosophy, which is then passed on to the AWS engineers and they push that, push ideology on us as well, saying "You know what, we want you to use this database." We're not dogmatic. If they want us to use a specific database, we use it, as the cluster is very dynamic. We don't need to deploy a database within a cluster, we can use the cloud database. To us, it's just a connection string, so it's not inefficient for us. It's just based on the client. However, you can see there's a little bit of an ideology dogma baked into the AWS philosophy just to keep you in the cloud.