Google Kubernetes Engine Reviews

We have everything in Kubernetes. We're basically moving everything from the cloud into Kubernetes - inverting the cloud. We have all that built for the CIT pipeline and have our tools within the cluster.

This is to support application development. The application side is always within the cluster. We have a security cluster. So everything is there. We have a database within the cluster as well. We don't need a managed database. There's a cloud database due to the fact that we use Kubernetes database. Everything goes into the cluster.

It makes it easy for us to be consistent across different environments, including development environments or in Oracle environments, as everything runs within the cluster.

The solution allows you to work on and from multiple clouds. You can use Google's cloud, or mix and match clouds across suppliers.

You can split into regions within your own cloud.

The deployment of the cluster is very easy. You just click a button and it's deployed, or just run a simple command and it deploys itself. You don't have to go through the steps of installing the cluster yourself. It's already deployed and managed.

The master of the cluster is also managed by Google. If there are any updates, they are responsible to handle that. It just takes a little bit of a load from our task load. You don't have to manage the master, or the version of the cluster yourself. 

You don't have to think about the installation process. They take care of the underlying infrastructure deployment and managing the versioning of the cluster. When we need to update, it's simple. They'll help us to easily, smoothly update those cluster nodes. You don't have to deal with that either.

When it comes to the Google Cloud, the Kubernetes advantage that's there for machine learning is that they have a CPU, which is a central processing unit, which is much faster than GPU. If the clients are willing to pay for it, we'll run the machine learning jobs within the Kubernetes cluster, then connect to Google CPU, which gives us the ability to finish the job much, much faster.

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.

We started using Kubernetes in 2015, around the time it started. Whenever Google launched their tools is about the time we started. Before that, we used Kubernetes, however, we were deploying it ourselves.

The solution is stable.

The solution is cloud-native and every cloud is using basically the same version. That's what makes it easy for us to move between clouds. Google wants users to integrate with their own cloud storage and security, however, which is where issues can arise. 

It allows you to create private clusters. There's no competitive advantage for cluster clouds right now, which is good for us, as it's a uniform-looking ecosystem that allows us to move between clouds easily.

Kubernetes is designed to scale horizontally and vertically as well. It scales quite well.

We have unlimited scaling through horizontal scaling. We can add more Kubernetes nodes. When applications do grow, we need to maybe horizontally scale applications or our databases. We just kick off another node when we need however much memory CPU and just keep on scaling it. Obviously, you pay for it, however, scaling is extremely easy.

A lot of time we automate the scaling as well. Based a little bit on AI and cloud automation processing, we detect the CPU usage or the GPU usage and if we exceed a certain threshold, the cluster automatically adds another data node, so it's self-serving. So scaling is almost automated around cases that we do.

The system knows by itself how to scale dynamically. The dynamic elastic scaling is baked into our systems as well. When people do use, for example, the machine learning special cluster, that one goes automatically from zero to 23 nodes depending on the users. A lot of times, we do shut it down, with just no usage. When people kick off a job, it automatically spins up on a new cluster node and deploys the job, gets another job, and spins up another one. It dynamically grows. We have to allocate pools that we have of an increased cluster in Google Cloud and it works well.

We basically are able to solve our own problems on our end. We don't need the assistance of technical support. We might have used it once in the past six or seven years and that is it.

The initial setup is very straightforward. Everything is basically done for you. It's nice and easy.

We can do the cluster management. There are cluster administrators who take a more serious role. They are responsible for the disks backing some of these applications, the databases, deployment of these tools, the infrastructure tools, et cetera.

We have application developers which work with the administrators to actually deploy the application, as you still have to just be meaningful in the cluster, and add some sort of business logic. Those have to work with our administrators so we get that done and we do support, and a lot of different tools, monitoring tools for visibility. It's important to us, because if we do, we follow a microservice architecture across applications. They're like little black boxes and we have to be able to see inside of them.

Multi-cloud is a sort of an expensive endeavor as the tools are overpriced. We're looking at options that aren't based on Anthos, which is Google's multi-cloud solution. 

While you pay money to Google, they also take a piece of the action as well.

CPU is very cheap, however, GPU is very expensive. If you want to iterate on your data client's tasks within a Kubernetes cluster, it will cost you.

There is no licensing cost. You pay for the cloud and you pay for what you use based on the CPU and RAM usage based on the VM, the virtual machines. The cluster is still made up of computers, so you pay for the computers that are backing the clusters. If you kick off a Kubernetes node, which has three nodes in your cluster, you have to pay for each of these nodes, these computers, these virtual machines that you get bootstrapped with. You just use the machine time as with any cloud and you get a price in Google for the machine type and your machine type is defined based on your CPU and RAM usage. If you want to have 60 GBs of RAM, you pay for that RAM or for CPUs.

The same thing is true if you ask for a GPU computer, as most of the virtual machines don't come with a video card unless you ask for it. Then you have to pay for that the computer and the video card

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.

I am just starting with it. I am testing different platforms. I've done some deployments, and with some samples, I've tried to install the Kubernetes application.

I am using its latest version.

It's easy to manage and deploy. It's the best. 

I can have some controls through some parameters, and it's very good. 

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.

I've been using this solution for two or three months.

It's stable.

I haven't yet used their support.

Its pricing is good. They bill us only per user. That's nice.

I'd rate it an eight out of ten.

All of our clients are using GKE lightly. The companies are big, but the usage is small.

GKE's plugin management and configuration sync are excellent features. The amount of data it provides is good, and I've been able to integrate it with the things I need.

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.

I have only been using GKE for a couple of months, but I have been working with Kubernetes for about six years and EKS for a year. 

GKE is scalable.

We were previously using basic Kubernetes that we set up and managed ourselves. I've also used EKS.

Setting up GKE is somewhat complex. There are lots of concepts that are involved and many options to consider. At the same time, you can easily automate it. It's easy to interact with the client and the APIs, and the documentation is good. Sometimes it is confusing, but you can find most of the stuff that you need.

I think EKS and AWS are very similar usages. I don't know if one is superior to the other. Google might be better at working with identities for workloads and resource integration. I think it's a bit better and easier than AWS's IM.

I rate Google Kubernetes Engine eight out of 10.

Google Kubernetes Engine's most valuable feature is container deployment.

An area in which Google Kubernetes Engine could improve is configuration.

I've been working with Google Kubernetes Engine for a few months.

Google Kubernetes Engine is stable.

Generally, Google Kubernetes Engine is easy to scale, but it can be difficult in some cases.

The initial setup is generally straightforward but can become a bit difficult with more complex projects.

The price for Google Kubernetes Engine could be lower - I'd rate its pricing at three out of five.

I'd rate Google Kubernetes Engine as eight out of ten.

This is Prophaze deployed in Kubernetes. So we have a Kubernetes. For example, Uber, they have all their sectors deployed in Kubernetes. There should be a native production for Kubernetes. We can have a separate cloud security solution for Kubernetes. Your solution has to be in Kubernetes. Because it should be a Kubernetes solution. So the WAF, in general, can be deployed in Kubernetes as a network solution.

It's like instantaneous scaling up. If you have a lot of traffic coming in, things like RAM and hard disk are easily able to scale.

It should support the latest GP use. I also think it should support load balancing.

I have worked with Google Kubernetes Engine for about three years. We are using version 10.

It's pretty much stable. I would say 99.9%, excellent.

Google Kubernetes Engine is very scalable, in fact, that is one of the best features.

For Google and Amazon, the Kubernetes is along the line of normal support. You email them or you can call them, but email is the preferable way of contacting them.

I heard about the normal service. Some of the eCommerce stuff, size or any of the other sites, you have a lot of traffic coming to your size. It is easy to buy if you have little traffic. You'll be able to buy and resell or if you still have money you can buy you two together. So, if you look at the last five years, people started to think about the cloud. You buy a cloud instance, you customize your configuration. People are now starting to look at Docker and Kubernetes.

The initial setup of Kubernetes Engine is quite straightforward. With just a few clicks, you can have it up and running.

We do everything from scratch here in our company. We have complete control over our selection. We use three people for maintenance.

Currently, it costs around $1000 per month which sorted our deployment. So once we get more clients, having a huge suffix, costs can go up. 

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.

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.

We primarily use this solution for authorization and service deployment.

The CLI commands are good.

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.

Stability-wise, this solution is really good. 

Scalability for this solution depends on the application. For normal microservice-related applications where there is no clustering, it is really evolved and easy to scale. However, for cluster-based applications such as MariaDB, or other cluster-based tools, scalability is complex and it needs to have more documentation.

We are using the solution for managing deployments, so there are only five or six users.

We have not subscribed to outside help for this solution. We have been using Google to search the forums for issues that we encounter. There is no defined place where I can refer problems and find answers. 

We did not use another solution prior to this one.

The initial setup is not straightforward. While it is not too difficult, there are some complexities. For example, sometimes when we add to the network there is an error and something goes wrong, which means that we have to start again, from scratch.

This is an open source solution, so there is no pricing or licensing.

I evaluated Docker Swarm, but compared to that, Kubernetes is very good. Docker Swarm is only for small applications.

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.

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.

We use the product to host a loyalty application.

The product has valuable security features. It can connect with multiple DevOps tools. It offers vouchers during service upgrades.

The product’s visible allocation feature needs improvement.

We have been using Google Kubernetes Engine for one year.

The product is overall stable.

The technical support services need improvement in terms of response time.

We use AWS EBS.

It is easy to install.

It is a nice tool. I recommend it to others and rate it a nine out of ten.

I use the tool to host a SaaS application.We also provision the clusters to help students learn how to use Kubernetes.

The solution is more user-friendly than AWS or Azure. I can also easily scale out the service in the future when the number of customers grows. GKE is the leader of Kubernetes service and it can be easily updated. I love the tool's user interfaces. 

I use the Firebase tool with GKE and it would be helpful if the solution can give notifications when we reach the budget limit. 

I have been working with the solution for more than 8 years. 

The product is stable. 

The tool is scalable and we have around 3000 users for the product. 

The tech support's service is good. 

Neutral

The solution's setup is very easy. 

The solution's ROI is good. 

The solution's price is reasonable. 

I would rate the product a nine out of ten.