Kubernetes Reviews

We primarily use the solution for deploying containers and scheduling the jobs to the Kubernetes for our server-side deployment.

Before we switched to Kubernetes, we had been using a solution that required a manual interaction with the server. Every time you need to scale it up and down, it was a lot of hassle. With this solution, we were able to add continuous integration with Kubernetes. We can trigger the automatic deployment and it will just be deployed and nobody needs to go and do anything. In terms of scaling, we can define the scalability rules, which will grow as the traffic grows, as opposed to past instances where you needed to change the instances of the CPO, etc.

Since we are saving so much time, we're also saving our company money. We're saving a few hours of work a week at this point.

The ease of use in the solution is a very valuable aspect for us.

The scalability of the product is excellent. Scalability is particularly important to us due to the fact that we have available traffic that requires our service to scale up and down according to the load on the service.

It would be very interesting if they could introduce a template engine to set dynamic values in the deployment time. It would be ideal if it could be native in Kubernetes as it would be much easier.

I've been using the solution for three to four years.

In this particular deployment, we've had the solution running for a little bit less than a year, and we have had zero stability issues. It's extremely stable. There are no bugs and glitches. It works without fail and is very reliable.

We had one instance once where it disappeared once for an instant, and nobody even noticed anything was wrong. That said, I do not think that was a fault of Kubernetes. It was more about an AWS issue.

From the perspective of managing Kubernetes and deploying and updating, we have two developers (one team leader and a DevOps). We taught four people to actively use and manage it. Then, almost everyone is using some service that is running on Kubernetes (about 15 or so people), therefore, it's widely used at our organization.  

We do have plans to increase usage in the future. We're planning to scale as we go where we will add more services and more deployments into Kubernetes.

We don't directly reach out to technical support. Rather, we tend to use their available documentation for troubleshooting.

We are using it on AWS, and it was fairly easy to deploy. As far as I know on other platforms, it is also quite easy as they have a faster-managed service. However, if I deploy it manually myself and manage the nodes by myself, it's pretty complex. Therefore, it can get pretty complex. Using the AWS managed solution removes the complexity for us.

The deployment took us about two days with testing, et cetera.

At the first stage, we had to wrap everything on our server-side, with the applications in the Docker containers. Then we deployed the ETS to the cloud and then we deployed the containers into the ETS. After that, we switched the browser to point to the newly deployed containers and load balance cells instead of the old machines. After that, we switched off the old machine.

We handled the deployment ourselves. We didn't need the assistance of any consultants or integrators.

Technically, we pay either way. We had the machine that we paid and we switched it off. We didn't really save on money investment so much as stability investment. We invested in this environment in order to attain a more stable and predictable application. That was our ROI.

The solution can be more expensive for smaller companies. If you run it on a smaller scale it's pricey. However, if you scale up or use it on a larger scale, it's pretty competitive in the pricing.

For example, on Amazon, the billing is mostly for the machines that you're using. If you have a lot of containers, hundreds of containers, running on the ECS, it can even be more expensive than if you were running the same containers on some deployment as you're paying for the nodes that are running the machines. If you can use fewer containers in the same machine it can be cheaper. It really depends on deployment. 

If you decide to take the managed service, be aware that it's $100-$200 extra monthly. It's not much, and it's worth the cost.

We did evaluate Amazon's Elastic Container cluster before ultimately choosing this product.

Kubernetes is multi-platform. You can run it on any cloud and you can also run it on your local machine. The implementation is also much more straightforward with Kubernetes and deployment is easier. Even though the product is from Amazon themselves, Kubernetes is easier to maintain and deploy.

I would advise new users to take the managed solution. Don't deploy it by yourself. Just take a managed service. It's really worth it. I advise this due to the fact that it's a lot of time and effort. It's not that expensive in terms of overhead. It may be $100 or $200 or something like that monthly. When you pay $3,000, let's say, the $100 doesn't really matter. However, the work that your DevOps will have will be costly. They will initially invest to maintain your unmanaged deployment. 

On a scale from one to ten, I would rate this solution a ten.

The use case in this organization is basically to containerize the applications. It covers both the operational and technology side. I work in the train industry here and that is a medium-sized enterprise. I'm a cloud architect and we are customers of Kubernetes. 

A valuable feature is the management of containers and not having to worry about the high availability or scalability, especially when launching it in the cloud. I like that they provide a managed platform as a service, and you don't really have to worry too much about the master nodes that control the workloads. You tell them what you want: This is a minimum number of container instance, or a maximum number of container instance in this tier. It automatically gets taken care of. What I like about Kubernetes is that it actually manages the containers for you so there are no concerns  regarding availability. If something fails, it launches another one and it scales out which is good. 

That's a good question. I'm not that experienced but there are definitely challenges in Kubernetes, if you are managing the cluster yourself. So doing all the admin work, managing the masters, there are some learning curves involved. If some of those things could be simplified, that would be awesome.

I've been dealing with this solution for around four years. 

Kubernetes is quite stable and has pretty wide community support. Even the enterprises are using it so if you're talking about a stable release and the nightly build and those sorts of things, definitely the enterprise use the latest stable build. And then, when they come across any issues they probably look for the next release or maybe batches and whatnot. But I guess it's fairly stable and it's just like any other open source solution. And the fact is that it's backed by so many large companies, especially Google, so there's no stability problem at all.

The scalability of this solution is fine. 

Deployment is pretty quick. I haven't done much of a bigger scale deployment as such, generally small to medium scale deployment and I've made use of the cloud-based approach. I don't have any issues there. 

I like the solution but it depends on the size of your workload. For example, Docker is good for a very small workload or maybe if you are just deploying using Docker, building and deploying your CICD-based tasks. But if you require a more complex solution, using containers or maybe when you have a high traffic workload, even with simple architecture, you might be looking at Kubernetes to optimize the workload.

There are other solutions on the market like Serverless, I would use that in preference to Kubernetes which can sometimes be difficult to manage. You can always make use of Serverless. For that reason, I would rate Kubernetes a seven out of 10. 

We are platinum partners with Oracle and we are preferred partners with Microsoft. I work for an organization which is on both sides of the coin. We are a service integrator organization. We don't have a specific loyalty, we blend in and provide the services. I'm a solutions architect.

I like the interface of this solution. When you're using it in real time, it seems to be a little easier to use versus the other options. 

If you're using the solution on the desktop, you eventually have to download the Azure package and install it before you can actually use the Azure commands in Kubernetes. There are more community packages that have been released, rather than releases by Kubernetes. I understand that it's an open server and people can contribute to it, that's how it works. However, sometimes people get misguided and that's where we need some support. It would make a difference. 

I've been using this solution for almost three months. 

It's a pretty stable solution. We have about 40 plus people who use it.

I would turn to community support as a first step. The blogs, which cover it, have given me a little bit more insight in terms of how and what and all of that. But when it comes to community, I've not asked much, but I've learned from it. I've watched some videos and see there is some online free training. I haven't been in a situation where I needed external support from Kubernetes.

We used to use Dockers. We explored Kubernetes because we want to do market platform, which is basically a show or an article together and we wanted to use a single platform for both Oracle and Azure. Not that Dockers didn't do it, but we did kind of wonder what would be the better option. 

The initial setup was relatively easy. I mean I've obviously used some of the apps before, but this seemed to be a little easier for me. I think when I used it in the Azure implementation earlier this year, it didn't give me too much heartburn although it takes a little bit more than you expect. I can just start the QP CDL and push out the command and start it. If I'm using it with Dynatrace, it's the same thing, but when it came to deploying the package into the local machine and then running it, and then trying to get the right connection within Azure it was more difficult. 

I would recommend going through the training to see what the limitations are within Kubernetes. There's not a lot of training, but what training is available should be used so people can understand the difference between Docker and Kubernetes. If somebody has used Docker previously, they can see the difference even though the methods are the same. It's the same madness, but it will help you to better position things like command line interfaces.

We had a bit of a struggle when I was trying to implement it in Azure. But if you look at the Oracle implementation, it worked really well so I would rate this solution a seven out of 10. 

I am currently learning the system, connecting the containers, and assessing the power of it.

The most valuable feature is the support for Docker containers.

The management needs to be improved.

I have been working with Kubernetes for approximately five months.

To this point, we have not needed to contact technical support.

The initial setup is a little bit complex for non-technical people in the business domain. It takes about a month to deploy.

Our in-house team is responsible for deployment and maintenance.

This is a good product and I can recommend it. That said, it will be better in the future.

I would rate this solution an eight out of ten.

It is a very good solution for deploying microservices in an application. It has a lot of freedom in it, which makes it very interesting. 

It is also web-enabled. You can run services in other virtual applications and virtual machines. 

It would be useful to have a basic and stable interface for monitoring and quick deployment purposes, especially when the deployments are big like a proof of concept or proof of technology. Currently, you need to use the Kubernetes console for all functionalities. 

It is not a quick-to-learn product if you are not from a Linux background. You need to be very skilled at Linux to learn it quickly. It took me two to three months because I mostly work with Microsoft products. For people who are not from a Linux background, the learning curve is a little bit longer.

It is very scalable, and it expands very well. Scalability is a very useful and important feature, especially when you work in a cloud environment.

It is scalable for an enterprise. You can scale up or scale down depending upon the environment or deployment. You can scale vertically with the size of the nodes. You can also scale the number of nodes. 

If you are using a service, you don't really need any initial setup. You just deploy it in a physical or virtual environment. 

Its deployment and configuration are very easy for open systems. I have experience in working only with Red Hat, and the deployment is very automatic. 

I would recommend this product. It is very close to being a 100% agnostic solution. It is just a step away from becoming a server-less solution like Fusion, which, although, is designed for running for a short time.

I use Kubernetes on the platform layer to deepen a platform. In some cases, when the same solution was developed without Kubernetes, some customers had issues on platforms like AWS, Azure, and Google.

I would rate Kubernetes an eight out of ten.

We primarily use the solution for orchestration.

Most of the clients we work with are enjoying the DevOps aspects of Kubernetes. They want to be able to safely and quickly deploy new applications. Others just enjoy the modern way they can deploy containers without being a DevOp company. 

The most valuable aspect of the solution is the scalability.

Kubernetes is quite complex. That's the reason there are some companies that are developing tools simplifying the life of the administrator. There are Kubernetes distributions, like Rancher. Rancher is one of my favorites. There are others too, like OpenShift, for example.

I would love to see a feature like VMware's vMotion, meaning a workload can be transferred from one host to another without being restarted. While true cloud native applications typically don't need such a feature, there is still a lot of single-container legacy applications out in the field. These applications get unavailable while being rescheduled to another node, for example when doing node maintenance.

I'd been dealing with the solution for the past three or four years.

The solution if very, very stable. It's a very mature product. While there is no software without bugs, it has 20 or more years of development behind it that makes it very robust.

The solution is extremely scalable. It's one of its greatest selling points. It also works for businesses of any size, from small to large.

Technical support is something I handle myself. I don't need to reach out to the Kubernetes team in order to troubleshoot issues.

We do have manufacturers of specific products that also have their own support we can access if we need to.

I have some experience with Docker. I also have a lot of VMware virtualization experience, although that doesn't have much to do with containers, per se.

That said, almost every software provider tries to adapt their solution to Kubernetes due to the fact that Kubernetes is gaining a lot of attention from everywhere. It's going to be the preferred way to deploy applications.

The complexity of the solution depends on the size of the installation and the product you choose. If you choose Kubernetes without any other tools, like Rancher or OpenShift, it's going to be very difficult and complex. However, if you have the chance to use one of those, it's much easier.

Once the solution is up and running, it requires monitoring, software updates, replacement when something fails, etc. Most of the time it's the provider that manages the infrastructure.

The solution is open-source. There are no licensing fees to speak of. It's under an Apache license, so anybody can use it. Some products that go on top of it, however, are licensed. 

I am a consultant, and I am just providing information about how to use this kind of software within specific companies.

Kubernetes is evolving now. 1.18 is the latest version, however, we don't have the newest version everywhere. That's the one we choose for new installs when we do them.

When it's deployed on the cloud, some of my customers are using public clouds such as Amazon, Google, or Microsoft. There are also some customers that use private clouds here in Switzerland. I work together with them.

If people are using modern technologies like containers or developing software by themselves, I would recommend this solution.

I'd rate the solution eight out of ten.

Kubernetes' most valuable features are scaling, deployment, and container management. Its integration with other pipeline tools is also good.

The setup process could be improved as it's quite complex, especially for newbies. In the next release, Kubernetes should include automatic deployment.

I've been working with Kubernetes for around a year and a half.

Kubernetes is a stable solution.

Kubernetes is easy to scale.

Kubernetes' technical support is good but could be a bit more responsive.

Positive

The initial setup was a bit complex.

I would rate Kubernetes as eight out of ten.

I primarily use Kubernetes to manage containers.

Kubernetes' most valuable features include scalability and deployment.

Kubernetes' VM functionality and security could be improved. 

I've been using Kubernetes for six months.

I would rate Kubernetes' stability eight out of ten.

I would rate Kubernetes' scalability ten out of ten.

The initial setup is straightforward so long as you have an understanding of the product. Deployment takes around forty-five minutes to an hour.

We implemented using an in-house team.

I would recommend Kubernetes to other users and rate it ten out of ten.