Google Kubernetes Engine Reviews

The primary purpose for utilizing Google Kubernetes Engine (GKE) is for application deployment. This managed cloud service eliminates the need for operating our own Kubernetes cluster. Our applications are designed in a microservice architecture, meaning they are comprised of numerous smaller components, each running on its own container. GKE acts as an orchestration engine for these containers, managing and organizing them. In essence, GKE serves as a platform for both application development and deployment within a Kubernetes cluster. This is our main use case for GKE.

In addition to deploying applications, we also utilize GKE for deploying our machine learning models. By containerizing these models, we are able to deploy them within the Kubernetes cluster, making it easier for our applications to communicate with them. As the application and the model are co-located within GKE, it is simpler for us to manage this process and make predictions in a timely manner. This is an advantageous use case for us.

Machine learning is not a use case that we utilize GKE. Instead, we have our own platform in place to deal with GKE. Although GKE is an open engine, it still requires compliance, security, and observability. Thus, we provide these elements to our clients. This includes observability through the collection of metrics and logs from all containers within GKE, which we aggregate and display through dashboards and dashboarding tools. Additionally, we have built our own security system within GKE, which includes hosting security tools to manage passwords, secrets, and certificates. These tools are also deployed within GKE.

In addition to application deployment, our continuous integration and continuous deployment (CI/CD) pipeline are housed within GKE. Our pipeline includes tools, such as Jenkins and Slack, which aid in the building, containerization, and deployment of software. This comprehensive pipeline within GKE streamlines the development process and allows for the efficient and effective release of our software. Currently, GKE serves all of our use cases related to software development and deployment.

In our organization, GKE is utilized to orchestrate containers that hold microservices, which combine to form an application. Furthermore, we also utilize GKE to host self-hosted databases and build our own data pipelines. As a result, GKE acts as the foundation for our data platform, supporting multiple different types of databases within the cluster. The solution has been helpful for our organization.

The main advantage of GKE is that it is a managed service. This means that Google is responsible for managing the master node in the Kubernetes cluster system. As a result, we can focus on deploying applications to the slaves, while Google handles any updates and security patches. The fact that GKE is fully integrated into the Google ecosystem, including solutions such as BigQuery and VertexAI. This makes it easier for us to integrate these tools into our process. This integration ultimately speeds up our time to market and reduces the time and effort spent on managing infrastructure. The managed aspect of GKE allows us to simply deploy and utilize it without having to worry about the technicalities of infrastructure management. 

Recently, Google has introduced new features to GKE. One of the latest additions includes a managed backup service, which backs up the disks attached to the containers within the platform. This service is a valuable asset provided by Google. Furthermore, they also offer configuration management, providing all the necessary infrastructure and services to accompany the use of Kubernetes. This saves time and reduces the effort needed to manage the cluster, allowing for a more focused approach toward business-critical tasks, such as containers, building pipelines, and more. GKE provides the necessary support and resources to allow for rapid deployment and efficient management.

While the GKE cluster is secure, application-level security is an essential aspect that needs to be addressed. The security provided by GKE includes the security of communication between nodes within the cluster and the basic features of Kubernetes security. However, these features may not be sufficient for the security needs of an enterprise. Additional security measures must be added to ensure adequate protection. It has become a common practice to deploy security tools within a Kubernetes cluster. It would be ideal if these tools were included as part of the package, as this is a standard requirement in the industry. Thus, application-level security should be integrated into GKE for improved security measures.

Additionally, a crucial aspect that was previously lacking was a reliable backup system. Although Google has recently released a beta version of GKE backups, it still requires improvement. Within a cluster, many components, such as databases, have a state and a disk attached to them. Hence, it is essential to have both physical snapshots of the disk and logical backups of the data. However, the backup system offered by GKE is not yet fully developed and requires more work to become a robust enterprise feature. For enterprise applications, it is imperative to manage state and take regular backups due to the Service Level Agreements (SLAs) signed with clients, which often require multiple backups per day. Thus, further development and improvement of the backup system are necessary.

I have been using Google Kubernetes Engine for approximately six years.

GKE is extremely stable, with very few issues related to stability. This is due to frequent and continuous updates to the system. In the world of Kubernetes, it is common to maintain one version behind and two versions ahead, allowing for a clear understanding of upcoming releases and the ability to subscribe to the latest versions. Google is always at the forefront of updates and releases, and users have the option to either use the latest and most cutting-edge versions or stick with the stable and tried-and-true versions. There are no problems or concerns with stability in GKE.

GKE was designed with scalability as its core feature, offering both flexibility and scalability in its functionality. It is easily adaptable for scaling both horizontally and vertically, making it ideal for our machine-learning tasks as well. The ability to attach a GPU to a node in the Kubernetes cluster is a straightforward process, providing us with the option to deploy a Kubernetes cluster with or without video cards, based on our specific use case requirements. The horizontal scalability of GKE is instantaneous, as the solution was specifically engineered to excel in this aspect. The scalability of GKE is one of its most valuable features, making it a prime selling point.

Regarding support from GKE, I have limited knowledge. Our team is highly skilled in the field and would not require support from Google. In fact, I have communicated to Google that we do not require certification from them, as we are already Kubernetes certified and feel no need to be Google certified. I believe there is no return on investment for us in obtaining this certification. Despite Google's efforts to encourage us, we have informed them that they should focus on getting certified themselves rather than having us certified. Our team has a vast amount of experience and knowledge in the field, having been involved in the beta project even before Google knew the ins and outs of the technology. Therefore, we are capable of resolving any issues that arise on our own, without the need for assistance from Google.

This solution is better than Amazon and Azure.

Deploying GKE is a swift and seamless process, accomplished by running scripts. Our approach to infrastructure is based on the principle of infrastructure as code, utilizing Terraform for all operations. Google offers Terraform integration, further simplifying the process. Instead of manual intervention through the console or script writing, we choose to automate every aspect of our deployment, including GKE deployment, through Terraform. The cloud engineering provided by Google encompasses all the necessary tools to rapidly deploy and manage GKE, freeing us from the tedious task of managing individual components of the cluster.

Getting started with GKE is relatively simple, but ensuring proper deployment can be challenging. The ease of use, with just a click of the mouse button, does not guarantee secure and compliant deployment. Google should do more to educate users on the proper way to deploy GKE and provide resources such as recipes or integrate these best practices into the standard offering. For example, making the GKE public should be avoided as it poses a security risk, as each node in the cluster is publicly facing the internet, making it vulnerable to attacks by hackers who could target any of the nodes and potentially access a piece of the application and data.

The requirement of a private deployment in GKE comes with the need for extra configuration and networking setup, which can pose a challenge for developers and companies who are not familiar with the process. Although Google provides guidance and best practices, it is still necessary to have a good understanding of network engineering in order to successfully deploy Kubernetes. The complexity of the process can result in incorrect or insecure versions of Kubernetes being deployed, as seen with the recent hack on Tesla's GKE due to their improper deployment. Ideally, these configurations and setup steps should be integrated into the solution itself, eliminating the need for excessive technical expertise.

I rate the setup of Google Kubernetes Engine a seven out of ten.

The pricing for GKE is dependent on the type of machine or virtual machine (VM) that is selected for the nodes in the cluster. There is a degree of flexibility in choosing the specifications of the machine, such as the number of CPUs, GPUs, and so on. Google provides a variety of options, allowing the user to create the desired cluster composition. However, the cost can be quite steep when it comes to regional clusters, which are necessary for high availability and failover. This redundancy is crucial for businesses and is required to handle an increase in requests in case of any issues in one region, such as jumping to a different region in case of a failure in the Toronto region. While it may be tempting to choose the cheapest type of machines, this may result in a limited capacity and user numbers, requiring over-provisioning to handle additional requests, such as those for a web application.

The cost of using GKE, which includes having a redundant system and failover capacity, appears to be overly high. The requirement of having this extra capacity in case of disk failure or other issues means paying for the extra provision, which contributes to the elevated cost. This pricing model seems to be an unfair practice on Google's part as redundancy is a fundamental aspect of any business and must be paid for regardless of whether it is used or not. When it comes to general pricing, the choice of what is best for the specific use case is left to the user.

I rate Google Kubernetes Engine an eight out of ten.

We have somewhere around 20 microservices that we need to deploy for our product. We are using Kubernetes Engine to deploy those 20 microservices.

The feature that I like the most is the ease of use as compared to AWS. Its ease of use is very high, and I can quickly deploy clusters with a simple template.

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.

I've been using this solution for about a year.

It is pretty stable. I did not encounter any problems.

In the last 10 months, scaling was easy. There is an auto-scaling feature where I can just provide them with how many nodes I require, or I can create custom node pools where, for particular applications, I can deploy certain nodes. I haven't had any issues with scalability.

We have four or five users. They are DevOps engineers. Only two users are the owners. They have deployed Kubernetes Engine, and they manipulate the workload. Its usage would be twice or thrice a week.

I haven't encountered any issues so far, and I haven't raised any doubt with them. So, I haven't interacted with them. We are currently managing four or five projects with Kubernetes Engine. We haven't had any issues with any of them.

It is easy to set up. In AWS and other clouds, the support for Kubernetes is minimal, but in Google Cloud, it is much easier to set up. I would rate it a five out of five in terms of ease of setup.

It was set up in-house.

It is competitive, and it is not expensive. It is almost competitive with AWS and the rest of the cloud solutions.

We are spending around 3K USD per month. There are four projects that are currently running, and each one is incurring a cost of around 3K USD.

For Kubernetes, the components have to be broken down into machine cost, storage cost, and application cost, if you are using any private applications or any images. If you look at the compute instances for GCP, there are hundred different tiers. For example, you have general-purpose E2 machines, then you have high-compute machines, and then you have the GPU machines for T4. Those are pretty standard compute instances. Kubernetes Engine is just a layer on top of these compute instances to control your entire microservices architecture.

I would rate it a four out of five in terms of pricing.

I am yet to explore all of its features. I would rate it an eight out of ten.

Kubernetes Engine is a platform that spins off applications so they can be run at scale at a high level.

We are currently migrating from on-premises to the cloud version.

First of all, it's easier to control and manage the containers at all levels. It becomes easy to create CD, or continuous delivery, and it's easier to scale.

Kubernetes Engines is easy to deploy and manage.

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.

For me, Kubernetes Engines was pretty stable.

This is a very scalable product. We are increasing our use because our customer has a lot of products and he wants to migrate out of the application to cloud. He will use Kubernetes to do this.

As I work with different customers, it was a customer decision. I have no choice. I used Amazon Container Services, ACS, before. It was not bad, but I like Kubernetes better.

The initial setup was very easy because it's like a Google platform as a service. It's just one button to set it up. The deployment took only a few minutes.

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.

I have deployed the solution as a service into my private cloud, as well as into Azure infrastructure.

Google Kubernetes Engine is useful for cloud-native business applications, especially microservices-based architectures since business applications require scalability and resilience and must be highly available. Typically, Google Kubernetes Engine is used to deploy business applications and also to manage the integrations with the cloud services. There are a lot of SaaS solutions as service offerings provided by the Google Cloud Platform, so it helps with the integration to compile the solutions in the business space or, basically, the cloud-native space.

Google is the founder of Kubernetes. Google invented Kubernetes platform, and then later on, at some point in time, they had open-source scripts. Since Google started offering open-source scripts, a lot of other players in the market have adopted the same strategy for their products. Google Kubernetes Engine made a late entry into the market, but the good part that I like about it is that you have a seamless way of creating highly scalable and highly available solutions with it. On the tip of a command, you can scale in or scale out, and it offers every robust platform to implement DevOps processes for your automation solutions. The product fully supports the IaC concept.

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.

I haven't worked full-fledged with Google Kubernetes Engine. since I have used it from an experimentation perspective. It is mainly Kubernetes that I have worked for for more than three years. Google Kubernetes is basically a managed service, but Kubernetes 1.24 is what I have extensively used.

Stability-wise, I rate the solution a seven out of ten.

Scalability-wise, I rate the solution a six to seven out of ten.

My company's clients who use the solution are enterprise-sized businesses.

I have no experience with the solution's technical support because I have not done any production-related work revolving around Google Kubernetes Engine. I believe that Google provides better technical support, but I don't have the relevant background to speak about it.

I rate the product's initial setup phase a five or six on a scale of one to ten, where one is a difficult setup phase, and ten is an easy setup phase.

The concept revolving around Kubernetes is inherently complex when it comes to its setup phase. Kubernetes is not an easy domain to design and operate. The adoption of Kubernetes from a production perspective can be a bit of a complex task, not only for Google but for every other vendor in the world. The complexity is not much for a person who understands Kubernetes. With Google, considering its lack of maturity compared to the competitors, I will say the complexity during the setup phase may be a bit higher, based on which I rate the setup phase a six out of ten.

The solution is deployed on a public cloud by Google.

The solution can be deployed in a week since the major effort is in building the application, and getting the application to the production stage takes at least a week or so.

From an ROI perspective, the tool should be better, but since I have not done any production-grade application deployment on Google Kubernetes Engine, I won't be able to comment on the product's ROI part. As per my understanding, the overall Kubernetes ecosystem ensures a high ROI because it promotes the ability of a business, and that's what the platform is all about.

I rate the product's price a six on a scale of one to ten, where one is low price and ten is high price. The product is competitively priced.

I rate the overall product a seven out of ten.

I am impressed with the product's auto-scaling. 

I would like the solution to integrate with another Kubernetes product. I would also like it to monitor other platforms. It needs to also include scale-up container in the tool's next release. 

I have been working with the product for four years. 

I would rate the solution's stability a nine out of ten. 

I would rate the product's scalability a seven out of ten. It can scale up automatically. My company has 5 users for the solution. 

We rely on technical support from USA or India since it is not available in the local area. It is very difficult to get support. 

Neutral

I have used VMware's virtual machine before. We switched to the product since it offered flexibility and the ability to auto-scale. 

The product's setup is easy and I would rate it an eight out of ten. The deployment got completed in three hours. We relied on a DevOps engineer to complete the deployment and maintenance. 

We did the solution's deployment in-house. 

The solution is worth its money.

I would rate the solution's pricing a nine out of ten. The tool costs around 3000 dollars per month. There are no additional costs apart from these.

I would rate the product an eight out of ten. 

We use it for all applications.

The logs are important for detecting problems in our clusters. I use the fragment with this property, which is valuable.

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.

I have been using Google Kubernetes Engine for two years. For SunTrust, we use version 1.21, which is old. But on ComMaster, we use version 1.24.

It is not very stable, I would rate the stability an eight out of ten. 

I would rate the scalability a ten out of ten. Around 30 users are using Google Kubernetes Engine in your organization.

The customer service and support team is quite good. 

Positive

We can't say the initial setup was easy, but it wasn't difficult either. The deployment process was pretty fast. 

The pricing is average. For example, Tanzu Build Service is very expensive, but generally, it's okay. However, I understand that the on-to service is very expensive.

Overall, I would rate the solution a seven out of ten. 

The Google Kubernetes Engine is used for managing data workloads. As a part of the platform engineering team, we are uncertain about the specific data workloads running. Primarily, the application teams wanted to run specialized workflows, while the data engineering workflow preferred to opt for GKE. After a thorough evaluation of the different versions of the Kubernetes platform over a week, we informed the application teams about the available options. In case of confusion, we clarify the advantages and disadvantages of each feature. However, when the application teams express their preference for GKE, we support their decision, as they comprehensively understand the use cases for both EKS and GKE. This invariably leads to a smoother onboarding process, as we are well-equipped to cater to their specific requirements.

We are working and monitoring HTTPS on GKE. It has a great manager for license management. The controller policy item for that particular feature doesn't seem visible anywhere, which might be a bonus, but we are unfamiliar with it. As we explore the multiple flavors of Kubernetes clusters, we aim to enforce similar policies across all clusters. Overall, everything looks good, and hand tools are one of the unique features that set us apart from other vendors.

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 have been using Google Kubernetes Engine as an integrator for one year.

The initial setup is relatively easy, but unfortunately, some issues repeat. For instance, we always try to showcase our capabilities during working sessions with vendors, like when they come for a demo or even with AWS. However, when we require assistance, the installation seems straightforward, yet when an issue arises, we struggle to resolve it. We're trying to schedule a working session with GCP, but they are unavailable. Despite multiple follow-ups, when they finally arrive, the experience is not very productive, as the person often searches for solutions. Overall, the installation process is smooth. If we stick to the application, it seems to be working fine.

We use Terraform. It will take some time, but the cluster installation on the Google Kubernetes Engine will be completed within four or five hours.

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.

Our primary use case is to arrange the correct CICD (Continuous Integration / Continous Deployment) conveyor to provide for continuous changes in production.

The improvement is mainly connected to the speed of change implementation. In the case of the automatic convenor, we spent less time due to the automation of the process. Before using this solution, it was a lot of manual tasks and a lot of people participated in the process.

The most valuable feature is the horizontal staging of applications. Other important features include isolation of applications and more effective usage of infrastructure due to less consumption of resources by containers.

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.

We have not seen any signs of instability, and have an optimistic view of the solution.

Scalability is an important feature of this solution, and we are happy with it.

We have approximately one hundred people using the solution. It is mostly developers and quality assurance people who are working on the preparation for CICD.

Once we move to production, next year, our usage will increase.

I think technical support is good enough.

We did not use an integrated solution prior to this. Rather, it was done in a more traditional way. This included virtual machine creation, installation of additional software, and connection to an external CICD conveyor, etc. We are switching because we are interested in more widely using continuous technology.

Our motivation for switching is to simplify creating a CICD process. We have a lot of small changes and after testing, we will be using an automated process for product delivery.

We are currently in a test phase and are estimating the feasibility of moving this to production. Our plan is to finalize testing by the end of this year and move the solution to production at the beginning of next year.

We have two people working the maintenance of this solution, but frankly speaking, it is not enough. We are planning to improve our skills and capacity and expand these resources.

We communicate directly with somebody who is part of OpenShift. They are top guys and have enough experience to help us build our system. It's no problem.

We do not have a local team in Russia, but at some point, that may change and we will use a local integrator. 

We are planning to reach a positive ROI using this solution.

We are planning to use external support, and hire a commercial partner for it. Usually, this is about twenty percent of the solution.

We have been watching what is happening the market, and for some time it has been obvious that Kubernetes has the most followers and most potential. This is why we are starting with Kubernetes from the beginning.

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.