Kubernetes Reviews

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. 

It's a mobile phone application with a website written in Angular 8. It's a strategic microservices solution. There are a lot of containers and resources. The application is written in Java, and we are using Spring Boot, the second version. We are also using the application-gateway of Azure.

If you want to do the microservices strategy, you need to split the services to the smaller work. There must be containers in Docker. There are not that many good solutions for Docker. So right now, if you need to use Docker, you choose Kubernetes because they are number one for the container orchestration solution.

The auto-repair function in Kubernetes is perfect. When something breaks, the auto-repair function automatically repairs it. If you are running the content in Kubernetes, you have a good setup. You do not need to do anything for the management of this. So, the automation of Kubernetes is number one.

The Kubernetes dashboard can be improved. It is currently a mess. We were using Rancher earlier, and everyone was happy with the dashboard. Right now, we are using Kubernetes, and it's not working with Microsoft workstations. Aks is using mcr.microsoft.com/oss/kubernetes/dashboard:v2.0.0-rc7 for dashboard. It has problems with auth. It constantly deletes tokens in kube/config file. And auth with kube/config file is not working on mac. It does not work on chrome in windows 10. It is still laggy and slow. Auto refresh function is not working correctly and you need to refresh your browser. Older versions have similar problems. There is no restart function such as in rancher. There is no possible to restart or scale more deployments at the same time. You need to write script for that. Graphics design is out of date. After a while of not clicking anywhere it give you 401 and you need to login again.

I have been using this solution for two to three years. 

The stability is totally perfect because if something breaks, it gets auto-repaired. We had only one failure, but it was not the failure of Kubernetes, it was the failure of Azure machine.

The scalability is great. You have scale sets, and every scale set has node tools. You have different types of refurbishing, and you have a node count. If I need more CPU or more information, I just change the node count, and everything is run in the cloud. It will automatically pull the new node to Kubernetes in the product label, and the load will run there. 

I also used the downscale and upscale features. You can also automate the scaling, but I didn't try that. I would love to use that. I am using manual scaling. If I need a new installation, it takes two to ten minutes in a cluster. This can also be done by the junior admins in one click.

Support is the only problem we face with this solution. I don't know which plan we have, but our software is stable. We are also a customer of a reseller, and we need to open tickets with the reseller. After that, we open a ticket in Microsoft Azure, but it takes two or three weeks to get an answer from the technical guy from Microsoft, which is terrible. It could be because we have the basic support.

We were using Rancher 1.6 before, but it reached the end of life. Right now, the version is Rancher 2. In my opinion, I don't need to put another layer of Rancher 2 when I already have a good solution from Azure. So, I chose the Azure solution.

The initial setup is more complex because you don't only set up Kubernetes. You also need to set up some CI/CD solution, and you need a setup to back up your workload to the Kubernetes. If you want to deploy the workload to Kubernetes and you want to do it efficiently, you need to have Helm. Helm is for catalog package for Kubernetes. So, you need to know how to work with Helm. 

You need to create docket files or some DevOps scripts for deploying ability. The solution is complex. You definitely need to have an experienced DevOps person. If you have juniors in your company, they will not know how to set up the solution, which is not good. You need to have experience in tech DevOps.

For small setups, it doesn't matter. You run Kubernetes, put some containers, and you play with it. That's okay. However, if you want to run it in production with everything, it needs experienced DevOps staff. We have a team of up to 10 developers and DevOps members.

Yes, I am a certified administrator. Deployment was very easy. I deployed the Kubernetes service alone to run some workload in Asia. There is an automation feature in this solution. You only open one page and fill some requirements, and everything goes out to the team. It was great. 

I had everything scripted in the platform with code in 50 minutes, but this is only for Kubernetes, the infrastructure, and the network stuff. I had scripted everything again, but it was in the Ops script; not in the platform. I could deploy the complete workload within one hour.

The management layer is free, which is perfect. You don't need to pay money for the management layer, but in AWS develop service, you need to pay. I think it is €75 per month for the management layer. It is free here, so you can have as many Kubernetes clusters as you need. You are paying just for the workload, that is, for the machine, CPU, memory, and everything. 

I am still using the basic Docker Compose, which needs low care. I tried Rancher 2, but I don't have it in production. I also used Elastic Kubernetes Service (EKS), and I also tried the Google Cloud Platform. 

I think Google Cloud Platform is the best one, but here in Slovakia, we don't have enough support for Google Cloud, which will become a problem. If I can choose from the integration, I think the Google integration is the best because we could get into the Google products, but here in Europe, we don't have the support for Google Cloud Platform. 

Kubernetes is a great product. I am currently also helping a customer with the implementation of AKS because they only have a private cloud, and they want to have a hybrid cloud. I highly recommend to use this feature, and not to install Kubernetes manually or use some third-party tools. The Azure community service is better implemented than AWS community service. 

They are not good at planning the upgrades for Kubernetes. So, you really need to constantly upgrade the cost. The upgrade is automatic, but Azure changed the integration of load balancing, and I was forced to re-deploy all costs, which costed my company. We need two clusters at the same time from every environment. So, this was not good. I contacted the support, but there was no way to change the integration of the load balancer. I hope this will never happen again in the future.

I would rate Kubernetes an eight out of ten. The dashboard and support could be better. 

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.

I was probably using Kubernetes from the operational side. The service requires high availability, ensuring 99.99% KPI for our customers. So, we primarily used Kubernetes for this purpose and for managing our services.

Kubernetes has everything. Its design structure is quite advanced, and its offerings are extensive. The practical feature was the seamless failover.

The big part has been the design of the environment and the configuration training itself. Then, they program in the test environment, establishing whether everything else is working. Once we hit the deployment on the test environment or the staging, we move to live. The challenging phase of that exercise is if you don't get the configuration right from the beginning to be able to adjust and change.

Kubernetes's configuration could be made easier, especially at the network level, including aspects like IPs and ports. Integrating it into our services was quite challenging.

I have been using Kubernetes for eight years.

The product is stable.

We service about three point four million transactions.

We had approximately twenty-two servers, with eleven on each side. So, we've got two sides, with eleven servers on one side being SQL servers. It took us about three months to set up the infrastructure, and the installation configuration took about one and a half months.

Six engineers were required for the solution's deployment.

The return on investment in terms of the services that we were offering was quite good. However, as we started to scale down, we lost the contract. Therefore, maintaining the environment then became very expensive.

The solution is expensive. The salaries of Kubernetes engineers were much higher. They came at a high price. Resources also came at a high price, and therefore, it became very expensive to continue with Kubernetes

The tool is not difficult to maintain, but if you've got problems, troubleshooting and devising can be challenging.

It was beneficial and very complex. The skills development for the team working on it was a little steep. It's more complex compared to other solutions similar to it. It's quite robust and nice, but the learning curve is steep.

In terms of resource management, for instance, if you run out of memory or usage capacity, Kubernetes seamlessly moves your workload from one node to another without any issues.

I recommend the tool primarily for enterprise businesses that can afford the cost associated with Kubernetes, including the end-to-end resources needed, such as people, systems, processes, and so forth.

Overall, I rate the solution an eight out of ten.

Kubernetes is for orchestration. We use it for various large microservice-based architectures and web services. That's the ideal use case, but it's suitable for any kind of service that can be decomposed and needs to be scaled. Of course, it's much easier to deploy services that are stateless. It requires more skills to deploy anything stateful or data-based.

Kubernetes is a bit complex, and there's a steep learning curve. At the same time, I cannot imagine how it could be easier.  You need many add-ons to it, and the commercial releases of Kubernetes should address that. 

For example, Red Hat OpenShift comes with all the add-ons included, but Kubernetes itself is free software so, of course, you need some skills to use it.

I've been using Kubernetes for four years.

Kubernetes is highly stable, but it's a complicated system with complex dynamics, so it needs to be monitored constantly.

Kubernetes' scalability is good. We have participated in operating clusters with hundreds of nodes.

Kubernetes is an open-source solution, so there is no tech support. You have to look up solutions online. You can purchase tech support, but we haven't used that service so far.

We used Marathon Mesos in the past, but it's obsolete these days.

Installing Kubernetes is complex. You need extensive skills and knowledge to do it from scratch.I didn't do install the solution by myself. A colleague is an expert in this, so he handled it. 

You can probably deploy the bare-bones cluster within days, but it requires some study, which can take much longer. And if you want extra features, it will take more time. Kubernetes has a lot of features, so it could take three days or three weeks to deploy if you keep adding to it.

We are focusing on open-source Kubernetes that doesn't require a license, but we use OpenShift for customers. It's a licensed, supported solution by Red Hat.

I rate Kubernetes nine out of 10. I recommend Kubernetes, but it's not for the faint of heart. Deploying Kubernetes from scratch is a real technical challenge because you need to understand lots of technology. 

It's much easier to start with Kubernetes from some cloud provider or use a commercial solution like OpenShift. Doing the pure vanilla open-source Kubernetes is possible but requires expertise, which is hard to come by.

We deploy our software solution in the Kubernetes environment. 

Honestly, there is not much I like about Kubernetes. It's very complicated to deal with. I just do it because I have to.

There is plenty of room for improvement with the configuration and runtime monitoring. That would make Kubernetes much easier to use. 

I have been dealing with Kubernetes for almost two years. 

Once you get it configured properly, it's a stable solution. The problem is that getting there is complicated.

Kubernetes is scalable, but again, it's such a complicated product.

I've never had to use the tech support.

I would not say that the initial setup is straightforward: the configuration can take me either 45 minutes or a week and a half. 

I try to do it by myself, but I often wind up having to look up directions.

I have not seen a return on investment with Kubernetes.

I would rate this solution an eight out of ten.

We are using it for hosting applications. Customers are hosted on the Kubernetes Service AKS.

They've introduced an enterprise option, which is quite helpful. 

It is always up to date. They're also automatically updating when the new version is ready.

There's a lot of community support if you need to get help. 

There are a couple of improvements there also need to be at play.

For example, if we deploy without RBACs to the cluster, it can't be deployed. When there's like GCPW or AWS, there is room. Even though we have deployed the clusters without RBACs enabled, we can add the RBACs later. However, Microsoft has limitations. There are features in Google Cloud or AWS that aren't in Azure. They need to implement a couple more tools in Azure. 

The application gateway, app gateway, needs to be improved. It's not fully developed yet.

I've been using the solution for around two years. 

The stability is good. It's always up to date and running well. There are no glitches and it doesn't rah or freeze. We did have one bug once however it has since been fixed. It is reliable.

We have 18 to 20 people using the solution and they are in DevOps. However, I've never tried to scale it. I'm not sure how well it would scale or not. 

We have used community help in the past and found it useful. They are helpful and responsive when you need to get a hold of them.

Positive

The deployment has a moderate level of difficulty. It takes around 30 minutes to 40 minutes to get everything up and running.

We pay a monthly fee in order to sue the solution. 

We're not a partner. We are end-users.

I'm not sure of the exact version of the solution we are using. 

Microsoft is hosted on their environment. We can't host it in our own environment. We are using the Azure Kubernetes AKS. If it's Azure, it needs to be hosted on its own Azure Cloud. We can't host it, for example, on-premises. 

I would advise potential new users to learn about it and try it out.

I'd rate the solution seven out of ten.