DevOps Engineer at a tech vendor with 51-200 employees
Real User
Top 10
2024-09-26T07:17:00Z
Sep 26, 2024
The primary area for improvement would be the complexity involved when working with Google Kubernetes Engine, especially when using Terraform. It can be more complex compared to AWS. Additionally, the process of managing IAM roles and integration with other Google services can be cumbersome and could use some simplification.
The monitoring part requires some serious improvements in Google Kubernetes Engine, as it does not have very good monitoring consoles. If Google Kubernetes Engine comes up with monitoring consoles, that would be helpful. During deployment, if the product provides users with an interactive kind of proper dashboard, which gives status or feedback on deployment, it will be helpful.
Principal Enterprise Architect at a tech vendor with 51-200 employees
Real User
Top 20
2023-11-23T10:41:37Z
Nov 23, 2023
The product's stability is an area of concern where improvements are required. Google Kubernetes Engine needs to mature more to be able to offer more stability compared to its competitors like Amazon and Microsoft, which have allowed for aggressive growth due to the area covered in terms of offering the complimentary services offered around Kubernetes. Google is behind even though it offers a robust platform. Google needs to offer more intensive services to fulfill the needs of customers and serve as a one-box or one-stop solution that covers everything enterprises need. Google needs to evolve more in terms of the richness of the services offered.
Team Lead at a tech services company with 201-500 employees
Real User
Top 20
2023-10-12T07:09:33Z
Oct 12, 2023
The solution's support is terrible. Even the GCP engineers have been tracing some concerns. The dedicated GKE support engineer often tries to find solutions when raised tickets. Support engineers don't know about it. Regarding AWS or Azure support, GKE support needs a lot of improvement. The documentation is another issue. Even though the support engineers keep referring to the documentation, it's not current because the cloud keeps evolving. They need to update the documentation frequently. The controller policy will be compatible with version 1.26 of Kubernetes. We assumed we needed to upgrade to 1.26 fast, as we were running 1.25. However, after spending two and a half months, we realized it works with 1.25 as well. Even the GCP engineers were not aware that it was compatible with 1.25. Google Kubernetes Engine has a limited layer of support, and not many workloads are feasible. Some application teams need the Kubernetes platform. However, we can't recommend GKE, even though the cost would be lower than EKS and OpenShift. We can't trust GCP support when major issues arise.
I would like to see the ability to create multiple notebook configurations. In a cluster, we can create multiple notebooks, which means multiple machine configurations. This would be better because if we have a job that requires high CPU, then we can have a notebook available for that job with a high CPU machine type. And if we have a job that requires high memory, then we can have a notebook available for that job with a high memory machine type.
There is room for improvement in this solution. For example, auto-scaling can be complex. We expect it to be easier to set up and manage, even for our customers.
Consultant at a manufacturing company with 10,001+ employees
Real User
Top 5
2023-07-18T08:33:50Z
Jul 18, 2023
There is room for improvement in the cluster updates process. Specifically, when managing both non-production and production clusters, we need a sequential functionality. This means being able to upgrade non-production clusters first and then the production clusters. Having this sequential upgrade capability would be beneficial. Therefore, I am looking for a sequential functionality for cluster upgrades.
There is room for improvement in terms of visibility and observability of solutions. One of the things I missed a bit is the visibility and availability of solutions. If I compare it to a different solution, it is a bit behind.
The current version is quite good. However, a new version, 1.26, is not yet stable. GKE offers regular, stable, and rapid versions, but this one is being used for the rapid version and hasn't been thoroughly tested yet. I think DCP may be quicker in releasing more stable versions.
There is a limitation for our infrastructure. It's very complex to see in one dashboard all the components and all the behavior on performance. I am looking for some additional tools for that. If I want to check the disk or file storage, it gets complex. There should be an integrated dashboard so that we can manage everything through a single pane.
Chief Architect at a energy/utilities company with 10,001+ employees
Real User
Top 20
2023-01-26T10:48:11Z
Jan 26, 2023
We would like to see some improvement in the ease of integration with this solution. We would also like to see the addition of some automated realization of data pipelines.
Director at a tech services company with 11-50 employees
Real User
2022-10-12T13:43:51Z
Oct 12, 2022
The user interface is a bit confusing sometimes. You need to navigate between the various consoles we have. It's hard to figure out where things are. It's frustrating. The documentation could be a bit better.
Solutions Architect at a tech services company with 11-50 employees
Real User
2022-08-15T13:03:44Z
Aug 15, 2022
Their documentation is a little here and there. Sometimes, the information is not clear or updated. Their documentation should be a little bit better. They have a good marketplace, but it is still evolving and is not as mature for some services.
The console for this solution could be improved because it is very limited. In addition, features like a desktop for the Docker image, drag and drop into a node could be added. In terms of visualization, the solution could also provide some integration with other tools. We have heard about Grafana and AppDynamics offering these features, but they still require better tools. Google is going in the right direction because they believe in open source integration and give opportunities to other players to work with them. However, they should provide packages where they integrate more features to demonstrate more encouragement in the marketplace. Training, tutorials, tooling, samples, and more case studies should be included in the next release.
There are multiple flavors of GKE. That's why we deploy it for different use cases. There are different issues with each of the use cases. When it comes to using Kubernetes as a commodity, which means allowing Google to manage your virtual machines, they still don't have all the features baked in. Our issue is that you have no ability to change it because Google manages it. Our biggest issue right now is that it just requires a little bit more control over some of these Google managed versions of virtual machines. One of the biggest issues right now is the Kubernetes backup system. That's being handled right now by Google, but it's in beta. There are no fundamental issues like we have in EKS or Azure with a private cluster. They nickel and dime you with features or they're pushing you to their own observability tools. We want to use our own observability tools. The whole thing is integrated with Google monitoring and logging all that stuff in the cloud, so it's not necessarily bad. It's just that we want to use our tools. Service mesh management is an issue as well. There's only one service management, so we would like to use console service mesh so we can use the managed project there. We don't like the way Google deploys things. We like to deploy things ourselves, and that can cause friction in terms of how we deploy things. We have to spend a little bit of extra time on coding. Fundamentally, I don't see any issues with it right now.
It's maybe a controversial topic, as Kubernetes itself should be just your bottom layer. However, within your own engine, you expect to do more with time. Since we're putting so much into the cluster, it would be nice if some of this stuff was already done, baked into the cluster. Our critique is that we have to do too much work to get the cluster production-ready. Most people just start it and think that's production. That's not really production. That's just bootstrapping the cluster, with all the tools that you need. A lot of people rely on cloud tools, or a cloud-built system, to get going. We would like to have that baked into the cluster. Due to our usage pattern of the cluster and how heavily we use it, our expectation is to have more tools baked into the cluster. There should be more emphasis on tools developed immediately from the cluster to support application development versus relying on third-party vendors, like Jenkins. The third-party vendors have to adapt to Kubernetes, and that creates a problem, as there's always a delay. Third parties don't have much incentive to do anything right away. That means we have to wait for these guys to catch up. We don't have a big enough team to actually change every open source code, as there's so much of it.
There are some security issues, but it might just be because we are not up to speed yet as much as we should be and so we haven't found it in the documentation yet. That's why I don't want to confuse this. Still, it could be a little bit easier to understand and implement. They could also probably improve their monitoring features. We mostly don't use the graphical display. We use command lines, so this isn't a big issue for us.
Solution Architect at a tech consulting company with 501-1,000 employees
Real User
Top 5
2019-06-13T12:36:00Z
Jun 13, 2019
The network configuration has to be simplified. I would like to see a more user-friendly interface. Currently, it is a little complex, and the technical guides are not easy to follow. Compared to other applications, the documentation needs a lot of improvement. Cluster-based software support needs to be improved.
Head of Infra and Applications support department at a financial services firm with 201-500 employees
Real User
2019-05-22T07:18:00Z
May 22, 2019
I think that security is an important point, and there should be additional features for the evaluation of data in containers that will create a more secure environment for usage in multi-parent models.
Kubernetes Engine is a managed, production-ready environment for deploying containerized applications. It brings our latest innovations in developer productivity, resource efficiency, automated operations, and open source flexibility to accelerate your time to market.
The primary area for improvement would be the complexity involved when working with Google Kubernetes Engine, especially when using Terraform. It can be more complex compared to AWS. Additionally, the process of managing IAM roles and integration with other Google services can be cumbersome and could use some simplification.
The product's integration with third-party vendors needs improvement.
The notifications are not informative. It's a little confusing at times.
The product could be cheaper.
The tool's configuration features need improvement.
The monitoring part requires some serious improvements in Google Kubernetes Engine, as it does not have very good monitoring consoles. If Google Kubernetes Engine comes up with monitoring consoles, that would be helpful. During deployment, if the product provides users with an interactive kind of proper dashboard, which gives status or feedback on deployment, it will be helpful.
The product's stability is an area of concern where improvements are required. Google Kubernetes Engine needs to mature more to be able to offer more stability compared to its competitors like Amazon and Microsoft, which have allowed for aggressive growth due to the area covered in terms of offering the complimentary services offered around Kubernetes. Google is behind even though it offers a robust platform. Google needs to offer more intensive services to fulfill the needs of customers and serve as a one-box or one-stop solution that covers everything enterprises need. Google needs to evolve more in terms of the richness of the services offered.
The product’s visible allocation feature needs improvement.
The solution's support is terrible. Even the GCP engineers have been tracing some concerns. The dedicated GKE support engineer often tries to find solutions when raised tickets. Support engineers don't know about it. Regarding AWS or Azure support, GKE support needs a lot of improvement. The documentation is another issue. Even though the support engineers keep referring to the documentation, it's not current because the cloud keeps evolving. They need to update the documentation frequently. The controller policy will be compatible with version 1.26 of Kubernetes. We assumed we needed to upgrade to 1.26 fast, as we were running 1.25. However, after spending two and a half months, we realized it works with 1.25 as well. Even the GCP engineers were not aware that it was compatible with 1.25. Google Kubernetes Engine has a limited layer of support, and not many workloads are feasible. Some application teams need the Kubernetes platform. However, we can't recommend GKE, even though the cost would be lower than EKS and OpenShift. We can't trust GCP support when major issues arise.
I would like to see the ability to create multiple notebook configurations. In a cluster, we can create multiple notebooks, which means multiple machine configurations. This would be better because if we have a job that requires high CPU, then we can have a notebook available for that job with a high CPU machine type. And if we have a job that requires high memory, then we can have a notebook available for that job with a high memory machine type.
There is room for improvement in this solution. For example, auto-scaling can be complex. We expect it to be easier to set up and manage, even for our customers.
There is room for improvement in the cluster updates process. Specifically, when managing both non-production and production clusters, we need a sequential functionality. This means being able to upgrade non-production clusters first and then the production clusters. Having this sequential upgrade capability would be beneficial. Therefore, I am looking for a sequential functionality for cluster upgrades.
I use the Firebase tool with GKE and it would be helpful if the solution can give notifications when we reach the budget limit.
There is room for improvement in terms of visibility and observability of solutions. One of the things I missed a bit is the visibility and availability of solutions. If I compare it to a different solution, it is a bit behind.
The solution does not have a visual interface. The solution could be improved by adding some visual drag-and-drop features.
The current version is quite good. However, a new version, 1.26, is not yet stable. GKE offers regular, stable, and rapid versions, but this one is being used for the rapid version and hasn't been thoroughly tested yet. I think DCP may be quicker in releasing more stable versions.
There is a limitation for our infrastructure. It's very complex to see in one dashboard all the components and all the behavior on performance. I am looking for some additional tools for that. If I want to check the disk or file storage, it gets complex. There should be an integrated dashboard so that we can manage everything through a single pane.
We would like to see some improvement in the ease of integration with this solution. We would also like to see the addition of some automated realization of data pipelines.
The user interface is a bit confusing sometimes. You need to navigate between the various consoles we have. It's hard to figure out where things are. It's frustrating. The documentation could be a bit better.
Their documentation is a little here and there. Sometimes, the information is not clear or updated. Their documentation should be a little bit better. They have a good marketplace, but it is still evolving and is not as mature for some services.
An area in which Google Kubernetes Engine could improve is configuration.
The console for this solution could be improved because it is very limited. In addition, features like a desktop for the Docker image, drag and drop into a node could be added. In terms of visualization, the solution could also provide some integration with other tools. We have heard about Grafana and AppDynamics offering these features, but they still require better tools. Google is going in the right direction because they believe in open source integration and give opportunities to other players to work with them. However, they should provide packages where they integrate more features to demonstrate more encouragement in the marketplace. Training, tutorials, tooling, samples, and more case studies should be included in the next release.
The user interface could be improved. In the next release, I'd like to see better notifications.
There are multiple flavors of GKE. That's why we deploy it for different use cases. There are different issues with each of the use cases. When it comes to using Kubernetes as a commodity, which means allowing Google to manage your virtual machines, they still don't have all the features baked in. Our issue is that you have no ability to change it because Google manages it. Our biggest issue right now is that it just requires a little bit more control over some of these Google managed versions of virtual machines. One of the biggest issues right now is the Kubernetes backup system. That's being handled right now by Google, but it's in beta. There are no fundamental issues like we have in EKS or Azure with a private cluster. They nickel and dime you with features or they're pushing you to their own observability tools. We want to use our own observability tools. The whole thing is integrated with Google monitoring and logging all that stuff in the cloud, so it's not necessarily bad. It's just that we want to use our tools. Service mesh management is an issue as well. There's only one service management, so we would like to use console service mesh so we can use the managed project there. We don't like the way Google deploys things. We like to deploy things ourselves, and that can cause friction in terms of how we deploy things. We have to spend a little bit of extra time on coding. Fundamentally, I don't see any issues with it right now.
It's maybe a controversial topic, as Kubernetes itself should be just your bottom layer. However, within your own engine, you expect to do more with time. Since we're putting so much into the cluster, it would be nice if some of this stuff was already done, baked into the cluster. Our critique is that we have to do too much work to get the cluster production-ready. Most people just start it and think that's production. That's not really production. That's just bootstrapping the cluster, with all the tools that you need. A lot of people rely on cloud tools, or a cloud-built system, to get going. We would like to have that baked into the cluster. Due to our usage pattern of the cluster and how heavily we use it, our expectation is to have more tools baked into the cluster. There should be more emphasis on tools developed immediately from the cluster to support application development versus relying on third-party vendors, like Jenkins. The third-party vendors have to adapt to Kubernetes, and that creates a problem, as there's always a delay. Third parties don't have much incentive to do anything right away. That means we have to wait for these guys to catch up. We don't have a big enough team to actually change every open source code, as there's so much of it.
It should support the latest GP use. I also think it should support load balancing.
There are some security issues, but it might just be because we are not up to speed yet as much as we should be and so we haven't found it in the documentation yet. That's why I don't want to confuse this. Still, it could be a little bit easier to understand and implement. They could also probably improve their monitoring features. We mostly don't use the graphical display. We use command lines, so this isn't a big issue for us.
The network configuration has to be simplified. I would like to see a more user-friendly interface. Currently, it is a little complex, and the technical guides are not easy to follow. Compared to other applications, the documentation needs a lot of improvement. Cluster-based software support needs to be improved.
I think that security is an important point, and there should be additional features for the evaluation of data in containers that will create a more secure environment for usage in multi-parent models.