We also use Google’s storage solution. It is similar to Amazon S3. I recommend the product because Google has good infrastructure and service management overall. It is a big brand but has fewer services than AWS. The vendor is fighting hard to reach a status where they get more services and get more involved with AI. We have a partnership with Google. We resell the solution. Overall, I rate the product a seven out of ten.
Packaged App development Senior Analyst at Accenture
Real User
Top 5
2024-03-13T15:23:00Z
Mar 13, 2024
We had a training session where they covered the features of Google Kubernetes Engine, allowing us to become familiar with all the commands that can be used in Kubernetes. You won't need to have its feature to encrypt the data. Instead, a config map and secret feature are available. There's ample data recovery capability, particularly during operations like saving and performing other tasks. It's pretty impressive. Google Kubernetes Engine provides certain features for free, especially for self-learning purposes. We install it on my local machine and deploy applications without incurring costs. Overall, I rate the solution an eight or nine out of ten.
The inter-system communication, including the ports used, is all described within Docker. The product manages these Docker pieces and builds the bigger picture. We integrate it as part of our DevOps script. It's all connected, with actions for the desktop, the CD Engine, and deployment on managed Kubernetes instances on Google Cloud. It's all automated and works well together. I rate the overall product a nine out of ten.
I recommend others try the solution and see if it suits and meets your budget. I recommend the solution to others because of the scalability, reliability, and ease of use it offers. I rate the overall tool an eight out of ten.
Team Lead at a tech services company with 201-500 employees
Real User
2023-10-12T07:09:33Z
Oct 12, 2023
I'm familiar with Kubernetes, but not many customers are using GKE. For instance, I've been involved in one project using GKE for about six to seven months; before that, another project used GKE for a year. However, I can only recall one project that used GKE for four months, about one and a half years ago. My work revolves around Kubernetes, but it's not exclusively focused on GKE. The maintenance of the solution is at an intermediate level, as there are some issues. We encounter problems with the Ingress controller and the GKE clusters. We have some open cases with GKE and have been trying to find solutions. Some aspects seem easy, while others are challenging to troubleshoot. Moreover, the documentation lacks comprehensive recommendations for GKE; we often have to rely solely on Google's official documentation. Overall, I rate the solution a five out of ten.
Those who want to implement their workload in Kubernetes can create it. It's automatically scalable. So you don't have to maintain your service. It will be automatically adjusted based on your workload and needs. The other thing is, when you are using microservice kind of development, like, now it is the programming language for microservices. So when we use microservices, it can be easily managed using Kubernetes. It makes it easy to find an error because the solution is really helpful. And if microservices, the whole application won't fail. Just the deployment notes, that may cause an error in our application. That's the only failure. The whole application won't fail. So it would be helpful. You have to use a microservice kind of development in your development environment and try to implement it as a container and delete the container workloads in Kubernetes. Using deployment or domain service, and our project will be automatically maintained. Overall, I would rate the solution a nine out of ten.
The auto-scaling can be complicated, so they should be prepared for that. It is difficult to hand over the solution to customers because of scaling up and scaling down issues. If Google improves that aspect, it'll be easier to manage. Overall, I would rate the solution a nine out of ten.
Consultant at a manufacturing company with 10,001+ employees
Real User
Top 5
2023-07-18T08:33:50Z
Jul 18, 2023
My advice would be to go for Google Kubernetes Engine if they seek stability, a well-tested product, and a reliable solution. It's suitable for those who value those qualities. Overall, I would rate the solution an eight out of ten.
My advice to others looking to use Google Kubernetes Engine is to pay attention to maintenance and utilize automation and platform tools to build and manage it. Do not do it manually. Many maintenance errors should be managed automatically, especially by Google. Otherwise, you need to be very attentive to the cluster due to maintenance issues. I suggest automating most of the manual tasks. There is a distribution of Google called Autopilot that handles it, although I haven't personally worked with it. I recommend considering its usage rather than doing everything manually. Maybe it's related to the specific solution we chose, but ultimately, it's about pricing. Overall, I would rate the solution a nine out of ten.
We're actually certified as well Kubernetes vendor. We're using version 1.19. The most up-to-date is 1.20. We're never on the latest version, we're always like a version behind, or even two versions behind, to give them time to sort through their issues. We're using 1.19 in both Azure's, Google Cloud's, and EKS, however, EKS might be two versions behind, maybe. Most of the time we're deploying in, as a private cluster within the cloud. It's isolated from public infrastructure. That's for security reasons. We don't want our cluster to be exposed to the public internet. We also have a hybrid deployment Azure on-premises. This is just to make things easier for integration purposes. On-premise, it's connected to the cloud and then we can just use the same tools to be Kube-Native source. We develop the same tools for Kubernetes and then we can just deploy Kubernetes on-premises or in the cloud, it doesn't matter. We also are doing multi-cloud as well, and we're deploying from Google Cloud into AWS. With Azure, we have one giant cloud right now. That way, we can partition a cluster and see multiple clouds and multiple visions. If Google Cloud goes down for whatever reason, as it happened, two years ago, due to bad configurations, too many clusters in a cloud, we're covered. We do multi-cloud as the solution is critical and we can't afford to have it go down. We are basically are a full-service company. We do everything for our clients - including application development and everything that entails. I'd advise users to take security seriously. Don't just deploy things on the internet. Make sure your cluster's secure. You want to be able to tell your clients that you have a secure implementation of a cluster. That requires a little bit of cloud set up with every cloud to create a private network, private subnetwork, manage the ingress and egress, so input and outputs of the requests coming into your cluster. These are things you have to think about when you deploy, just initially before you get started. All the clouds support it, you just have to know how to set up your VPC, virtual private network connection tier with every cloud and how to set up subnets to isolate your cluster to specific subnets, so it's not exposed on the internet, it's private and then any requests coming from the internet have to go to your load balancer directly to your cluster. However, if you manage that and some peoples' requests going out of your cluster, you won't be able to manage those as well, since they're on NAT and a cloud router as well. So you know what's coming in, what's going out. You can monitor your traffic coming in and within your cluster. These days a lot of people just use the containers directly from third-party sources or public repositories in the docker containers in which the Kubernetes cluster runs and those could come with malware. You want basically, in the main cluster, to have security policies implemented for every cluster. You don't get that from your cluster loggers. You have to get that from third-party vendors. This is where the competition comes with the Kubernetes. In general, I would rate the solution at an eight out of ten.
My advice to anybody considering this solution is to understand that you need to have everything ready before implementation. You need to have a migration strategy. I would rate Google Kubernetes Engine an eight out of ten.
Management and deployment of a lot of containers could be very easy. It saves us time. I think Kubernetes is really a fast developing and easy to use platform. I would probably rate it as nine out of ten since it does have a little bit of room for improvement.
This is a really good product for independent applications or microservices. The downtime is minimal, and we have even made it zero downtime for deployment. However, when they are cluster-based applications, it is really complex. I would rate this solution an eight out of ten.
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
My advice is not to implement this solution unless there is a genuine demand for it from the business side. It can be useful to start from the bottom of the infrastructure and take it to the highest level because it requires changes in the development and business levels to work with this technology. I think that there is enough documentation available to start to work with this product. The technology provides a very good opportunity to grow and improve. I would rate this solution a six out of ten.
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.
We also use Google’s storage solution. It is similar to Amazon S3. I recommend the product because Google has good infrastructure and service management overall. It is a big brand but has fewer services than AWS. The vendor is fighting hard to reach a status where they get more services and get more involved with AI. We have a partnership with Google. We resell the solution. Overall, I rate the product a seven out of ten.
We had a training session where they covered the features of Google Kubernetes Engine, allowing us to become familiar with all the commands that can be used in Kubernetes. You won't need to have its feature to encrypt the data. Instead, a config map and secret feature are available. There's ample data recovery capability, particularly during operations like saving and performing other tasks. It's pretty impressive. Google Kubernetes Engine provides certain features for free, especially for self-learning purposes. We install it on my local machine and deploy applications without incurring costs. Overall, I rate the solution an eight or nine out of ten.
The inter-system communication, including the ports used, is all described within Docker. The product manages these Docker pieces and builds the bigger picture. We integrate it as part of our DevOps script. It's all connected, with actions for the desktop, the CD Engine, and deployment on managed Kubernetes instances on Google Cloud. It's all automated and works well together. I rate the overall product a nine out of ten.
I recommend others try the solution and see if it suits and meets your budget. I recommend the solution to others because of the scalability, reliability, and ease of use it offers. I rate the overall tool an eight out of ten.
I rate the overall product a seven out of ten.
It is a nice tool. I recommend it to others and rate it a nine out of ten.
I'm familiar with Kubernetes, but not many customers are using GKE. For instance, I've been involved in one project using GKE for about six to seven months; before that, another project used GKE for a year. However, I can only recall one project that used GKE for four months, about one and a half years ago. My work revolves around Kubernetes, but it's not exclusively focused on GKE. The maintenance of the solution is at an intermediate level, as there are some issues. We encounter problems with the Ingress controller and the GKE clusters. We have some open cases with GKE and have been trying to find solutions. Some aspects seem easy, while others are challenging to troubleshoot. Moreover, the documentation lacks comprehensive recommendations for GKE; we often have to rely solely on Google's official documentation. Overall, I rate the solution a five out of ten.
Those who want to implement their workload in Kubernetes can create it. It's automatically scalable. So you don't have to maintain your service. It will be automatically adjusted based on your workload and needs. The other thing is, when you are using microservice kind of development, like, now it is the programming language for microservices. So when we use microservices, it can be easily managed using Kubernetes. It makes it easy to find an error because the solution is really helpful. And if microservices, the whole application won't fail. Just the deployment notes, that may cause an error in our application. That's the only failure. The whole application won't fail. So it would be helpful. You have to use a microservice kind of development in your development environment and try to implement it as a container and delete the container workloads in Kubernetes. Using deployment or domain service, and our project will be automatically maintained. Overall, I would rate the solution a nine out of ten.
The auto-scaling can be complicated, so they should be prepared for that. It is difficult to hand over the solution to customers because of scaling up and scaling down issues. If Google improves that aspect, it'll be easier to manage. Overall, I would rate the solution a nine out of ten.
My advice would be to go for Google Kubernetes Engine if they seek stability, a well-tested product, and a reliable solution. It's suitable for those who value those qualities. Overall, I would rate the solution an eight out of ten.
I would rate the product a nine out of ten.
My advice to others looking to use Google Kubernetes Engine is to pay attention to maintenance and utilize automation and platform tools to build and manage it. Do not do it manually. Many maintenance errors should be managed automatically, especially by Google. Otherwise, you need to be very attentive to the cluster due to maintenance issues. I suggest automating most of the manual tasks. There is a distribution of Google called Autopilot that handles it, although I haven't personally worked with it. I recommend considering its usage rather than doing everything manually. Maybe it's related to the specific solution we chose, but ultimately, it's about pricing. Overall, I would rate the solution a nine out of ten.
The solution is cloud-based. There are more tools available that are more visually intuitive. Overall, I rate the solution a nine out of ten.
Overall, I would rate the solution a seven out of ten.
I'd rate it an eight out of ten.
We would rate this solution an eight out of ten.
I rate Google Kubernetes Engine eight out of 10.
I am yet to explore all of its features. I would rate it an eight out of ten.
I'd rate Google Kubernetes Engine as eight out of ten.
I rate this solution seven out of ten. I believe Google Kubernetes Engine is the best solution in the market.
I would give Kubernetes a rating of eight out of ten.
I would rate this solution 8 out of 10.
I rate Google Kubernetes Engine eight out of 10.
We're actually certified as well Kubernetes vendor. We're using version 1.19. The most up-to-date is 1.20. We're never on the latest version, we're always like a version behind, or even two versions behind, to give them time to sort through their issues. We're using 1.19 in both Azure's, Google Cloud's, and EKS, however, EKS might be two versions behind, maybe. Most of the time we're deploying in, as a private cluster within the cloud. It's isolated from public infrastructure. That's for security reasons. We don't want our cluster to be exposed to the public internet. We also have a hybrid deployment Azure on-premises. This is just to make things easier for integration purposes. On-premise, it's connected to the cloud and then we can just use the same tools to be Kube-Native source. We develop the same tools for Kubernetes and then we can just deploy Kubernetes on-premises or in the cloud, it doesn't matter. We also are doing multi-cloud as well, and we're deploying from Google Cloud into AWS. With Azure, we have one giant cloud right now. That way, we can partition a cluster and see multiple clouds and multiple visions. If Google Cloud goes down for whatever reason, as it happened, two years ago, due to bad configurations, too many clusters in a cloud, we're covered. We do multi-cloud as the solution is critical and we can't afford to have it go down. We are basically are a full-service company. We do everything for our clients - including application development and everything that entails. I'd advise users to take security seriously. Don't just deploy things on the internet. Make sure your cluster's secure. You want to be able to tell your clients that you have a secure implementation of a cluster. That requires a little bit of cloud set up with every cloud to create a private network, private subnetwork, manage the ingress and egress, so input and outputs of the requests coming into your cluster. These are things you have to think about when you deploy, just initially before you get started. All the clouds support it, you just have to know how to set up your VPC, virtual private network connection tier with every cloud and how to set up subnets to isolate your cluster to specific subnets, so it's not exposed on the internet, it's private and then any requests coming from the internet have to go to your load balancer directly to your cluster. However, if you manage that and some peoples' requests going out of your cluster, you won't be able to manage those as well, since they're on NAT and a cloud router as well. So you know what's coming in, what's going out. You can monitor your traffic coming in and within your cluster. These days a lot of people just use the containers directly from third-party sources or public repositories in the docker containers in which the Kubernetes cluster runs and those could come with malware. You want basically, in the main cluster, to have security policies implemented for every cluster. You don't get that from your cluster loggers. You have to get that from third-party vendors. This is where the competition comes with the Kubernetes. In general, I would rate the solution at an eight out of ten.
My advice to anybody considering this solution is to understand that you need to have everything ready before implementation. You need to have a migration strategy. I would rate Google Kubernetes Engine an eight out of ten.
Management and deployment of a lot of containers could be very easy. It saves us time. I think Kubernetes is really a fast developing and easy to use platform. I would probably rate it as nine out of ten since it does have a little bit of room for improvement.
This is a really good product for independent applications or microservices. The downtime is minimal, and we have even made it zero downtime for deployment. However, when they are cluster-based applications, it is really complex. I would rate this solution an eight out of ten.
My advice is not to implement this solution unless there is a genuine demand for it from the business side. It can be useful to start from the bottom of the infrastructure and take it to the highest level because it requires changes in the development and business levels to work with this technology. I think that there is enough documentation available to start to work with this product. The technology provides a very good opportunity to grow and improve. I would rate this solution a six out of ten.