Kubernetes Reviews

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 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.

We are not using the Google version, but the open source Kubernetes.

This product can be deployed both on cloud or on-premises.

Our use case is mostly for multi-services or the applications which you will try to modernize. Investors will come from monolithic applications to mostly cloud-native applications. When I say cloud-native applications, that means each service component will be part of one container. You need a container orchestration or a management platform. So Kubernetes is actually a management or an orchestration platform for containers. Basically, it works with microservice applications.

One of Kubernetes' top features is its agility, it is very fast. You can deploy a container pretty quickly compared to a virtual machine. That is one strong feature. A second feature is its flexibility because you can use it on any platform. You can use it on Google or AWS or Microsoft or IBM or any clouds. So flexibility of deployment and agility are the top features. It also helps in your maintenance cycles when you do maintenance on your environment.

For improvements, I would say it's actually still evolving so they are already making a lot of improvements along the way. Each and every release comes with new features so I think they're doing well.

One feature I would actually like to see is the network monitoring part. When we talk about communities, it's mostly the computer side. But it does have some enhancements on the networking side which they have recently released. I would like to see more enhancement where we can monitor the networks of the Kubernetes cluster or the Kubernetes workloads.

This Kubernetes product is new so I would say I have been using it around two years.

I am using version 1.18, not the latest one.

Stability is still a question because it depends upon which flavor you're installing. It could be on-prem or it could be cloud, it could be open source. It's still debatable.

That said, stability-wise I haven't seen any problem myself up to now, but I might not be right. There are many other people who are deploying this in a production environment. I haven't done it myself in production so I would not be the correct person to answer that. But for me, I haven't found any stability issues.

Kubernetes definitely has good scalability. 

The number of users on it can vary. It can be used by very small organizations to very large and complex organizations. There is a customer I was working with who has more than 80,000 employees around the globe. But not everyone is a user of this technology. If you're asking about the users of this technology, I would say around 1,000 - 5,000.

Their technical support depends upon which flavor you're installing. Mostly, if you're going to the cloud version, support is definitely provided by the vendors. Like Microsoft provides its own support, AWS provides their own, and even IBM does the same. But if you're deploying on your own prem, that's where the question is. It depends. It's not a product sold by a single company, it's an open source, so big companies like J.P Morgan or Citibank have it deployed on their own premises and support will be their internal teams who will be working on that.

Installation is not a straightforward thing. It's a process that you have to follow step by step. On-prem is a little tedious because you have to spend some time to get this installed and create a platform. But people are mostly inclined towards cloud. They use Kubernetes on the cloud.

I did install it myself in my lab and the install itself doesn't take much time, about a couple of hours. But to go through the documentation takes time. You have to understand each and every component and then try to install that. So it's a combination of both understanding the documentation and then installing. Because it's a new technology, it does take a little bit of time.

It depends. If you talk to a customer and you get a project with them that they want to deploy, you're going to need a project manager or a technical architect, and then you'll need at least one or two guys who can do the hands on deployment. It's not a fairly large team, but you will need a project manager, a technical architect and an engineer.

There are different types of licenses. You have a subscription-based license if you are talking about cloud. This has both yearly or monthly available. Or you can go on number of workloads, based on how much workload you're putting on the cloud.

I would definitely recommend Kubernetes for others who want to start using it.

I would say it is no longer in its inception phase, but it is still in the early phase. The product hasn't matured enough. There are customers who are looking to take this maybe around two years down the line. On a scale of one to ten, I would give Kubernetes an eight.

We use the solution to modernize our IT landscape. We use infrastructure and platform surfaces for our data center. More recently we have added a container as a surface, which is this solution.

The easy deployment of containers is one of the main features I have found useful. In large scale developments, it is less hassle working with containers than virtual machines. It is easier to manage these containers instead of virtual machines, although there is a steep learning curve to graps the benefits of it.

This solution is not very easy to use. We are looking also for some tools surrounding this solution to manage the environment and to secure it better. These two are areas that have caused some issues. We want to integrate it with what you call continuous integration and delivery. 

It must be scalable, cost-effective, more agile when it comes to developing and managing the environment for DevOps. All these things go together, it must be cured to allow better manageability. That is what we all are doing in most large companies.

In a future release, the solution could become more like a core engine, in which tools like OpenShift are centered. You could see how all kinds of tools could help to better improve the management, security, or scalability of the product. Additionally, we will need more than the core in our organization, there needs to be more additional management tools moving forward.

I have been using the solution for approximately one year.

When it comes to my own environment, I have had no issues with scalability but it is not easy. This is just the development environment. Regarding my company, within my department, we are running a sandbox environment just for testing and that is going well. I am not sure how things will go if you go fully into production with this solution.

We will look for additional products to deal with the difficulties with scalability. There are several vendors that offer these products. Although this solution was made for scalability, it does not come out of the box this way.

We currently have approximately 30 users using the solution in my organization.

I am not aware exactly how the on-premises installation went for the IT team at my organization. For my local environment where I am testing this solution myself, the installation has been very easy. This is mostly because it is a local environment. We also have a cloud environment, where we have a hybrid data center and this cloud environment installation was fairly easy too.

The deployment was done by an internal team in my organization. 

Maintenance is required for all software versions. We need to manage different areas of the solution such as the cloud-native landscape tooling, registry, DevOps environment, and security toolings. There are three areas that need upgrades, versioning, scalability, and the toolset surrounding the solution. You can not run it on its own, you need additional tools. All of this maintenance is taken care of by our administration IT department.

The solution is affordable.

We plan on using the solution in the future. We are a large data center and we just need to have several options available. We need to have a traditional deployment of Infrastructure as a service, with virtual machines. We need also a platform as a service for very rapid and smaller applications and container management, container as a service which is this solution for all others. We expect that the virtual machines in the next 10 years will decrease and container-based services will increase.

I recommend the solution to others. It is a very good product and the strength can be that other vendors can create their security and management toolings around it allowing it to become a type of core engine. If those other vendors were not there, I think I would be more critical. Within my department, we were a bit late adopting the solution than other parts of the organization. We are still growing and experimenting, we have some clusters already in production. A lot of the product tools are open source which in some cases means the support is also not readily available. You have to adapt to it, but also be cautious when it comes to the support and the steep learning curve issues that you can expect.

I rate Kubernetes an eight out of ten.

If our project requires a cloud deployment we will use a cloud provider's version of Kubernetes. For example, Azure or AWS Kubernetes Elastic Services. We try to make use of whatever is provided by the cloud providers. 

If the project requires an on-premise solution we use products from various vendors, such as Red Hat or other open-source products that can be downloaded and installed for free.

We are using Kubernetes for container management.

Kubernetes use cases are typically containerized application hosting. This is the basic use case that we do. Another use case can be deploying new application microservices which are loosely coupled and containerized using microservices-based architectures.

We can achieve a reduction of almost 50% to 60% of effort in operations by using Kubernetes.

The most valuable feature is the Zero Touch Operations, which involves a new way of performing operations and support. We do not have to do maintenance, the operations are very simple.

Kubernetes can improve by providing a service offering catalog that can be readily populated in Kubernetes. 

The service catalog, for example, could be a CRM application on Kubernetes or an eCommerce retail application packaged on Kubernetes and to be readily deployable. Instead of somebody trying to figure out all the configurations of hosting this on Kubernetes, if something was readily available, which the developers for these CRM or eCommerce products, they could partner with either AWS, Google, or Azure and make the deployment of such applications readily available on Kubernetes. 

This would allow very little work for a business to go live. The business can quickly straight away and subscribe, launch, and use. It is not difficult for an IT team to be involved to create an application environment to start up. It's would be much easier for businesses to use it directly and start off the applications.

I have been using Kubernetes for approximately three weeks.

The stability of Kubernetes depends on how we have designed it. Our design is stable because I know how to design it and if something goes wrong how to fix it.

The scalability is superb, it is highly scalable.

We have 75,000 employees in our organization that is using this solution.

Technical support is not used very frequently. We use advanced-level support occasionally. It is only in certain circumstances when we have some advanced complexity that we reach out to an expert.

A person with a moderate level of knowledge on Kubernetes, with the help of the community forum, and documentation, most of their problems can be solved.

We do not need any particular company, such as Red Hat, to come in and support the Kubernetes environment, or some other company, such as Ubuntu Canonical to be signed up for a contract to support Kubernetes. It's not required.

The initial setup is straightforward, it was not complex.

The maintenance for Kubernetes is very minimal.

You need to pay for a license if you buy branded products. For example, if you take the services from Azure, AWS, or Google, the price of the Kubernetes cluster is inclusive of the service that's being offered to us on a pay-and-use model.

I haven't tried all the advanced features of Kubernetes, but I feel it is meeting most of the requirements of a new design architecture for applications to be hosted. I don't see any particular functionality which is not available for me as of now.

The open-source ecosystem is providing lots of ideas to solve all kinds of problems. The open-source ecosystem of developers, implementers, and integrators is providing lots of ideas. If there is something I may not know, I look up to the community forum and receive answers. There are no issues of finding something, however, Kubernetes by itself has to improve. It is a matter of the implementer to discover ideas to solve the problem. The Kubernetes engine is designed very well.

I would highly recommend this solution to others.

I rate Kubernetes a nine out of ten.

The following is a list of the cases when I prefer Kubernetes for application hosting:

1. Micro-services infrastructure + possible use of some service meshes, like Istio or Linkerd.
2. Cost efficiency; we are using Kubernetes in conjunction with AWS Spot Instances or Google Cloud preemptible VMs.
3. Standards-compliant infrastructures like HIPAA, PCI SOC, DSS, and ISOxxxx.
4. Highly-available or fault-tolerant infrastructures, due to some sort of self-recovery and self-healing.
5. Infrastructures with automatically scalable applications.

It's unified our technology stack across on-premises infrastructures and public clouds, including Amazon Web Services, Azure, and Google Cloud Platform. Kubernetes provides great integrations with other open-source tools, like Prometheus, Grafana, Elastic Stack, Fluentd, OAuth providers, and others.

Kubernetes distributions are also great because we adopt the platforms for different requirements. These include the AWS Elastic Kubernetes Service, Google Kubernetes Engine, Azure Kubernetes Engine, Rancher, etc.

It allows us to build custom-tailored infrastructures from small to big companies and satisfy various requirements, such as providing a proper level of RPO, RTO, scalability, cost-efficiency, and support high availability/fault tolerance.

The most valuable features of Kubernetes are:

1. Containers self-healing and self-recovery.
   
2. Unifications allow for internal Kubernetes components to be migrated between Kubernetes providers in an easier manner.
   
3. Kubernetes as a service from the major cloud providers including AWS, Google Cloud, Azure, Digital Ocean, IBM, etc. Kubernetes as a service helps in infrastructure migration from on-premises to cloud, or from cloud to cloud.
   
4. This product has a rich toolset from the community including CNI plug-ins, Helm packages, operators, dashboards, various integrations, etc.
   
5. Built-in scaling features, it's really great!

Some improvements that we would like to see are:

1. Have reacher built-in features and probably incorporate some features from the community toolset, like KEDA for pod scaling.
   
2. There are even more tools from the community for monitoring, log collectors, authorization, and authentication.
   
3. Have some sort of simplifications for wider adoption.
   
4. This product should have a more advanced built-in scheduler that uses real application metrics in the scheduling strategy.
   
5. Wider integration with cloud providers in terms of volumes and key management services.
   
6. Add support of traffic encryption option from container to container, and Ingress to the container.

We have been using Kubernetes as a self-hosted service, managed by external solutions, like Rancher, or a cloud-provider managed service (Azure AKS, Google GKE, Amazon EKS) for between three and four years.

This product is pretty stable, especially in the managed service option, but as with all platforms, it has some issues. As an example, during an update Kubernetes version on Amazon EKS from 1.17 to 1.18 Amazon duplicates workers count from 4 to 12 (should be from 4 to 8), upgrades takes more than 1 hour (should be about 10-20 minutes) and suddenly this leads to the short-time interruption of some applications during re-scheduling. In the end, we were forced to write our own rolling update scripts for updating the Kubernetes version on the nodes instances, which completes the upgrade in 10 minutes without application downtime. But again, this is an issue related to managed Kubernetes (in particular, Amazon EKS platform).

Great scalability, especially for the small and mid-size setup with fewer than 100 nodes.

We have used various platforms for managing Docker containers, such as Rancher, Azure App Service, and Portainer.

The first adoption was hard because the Kubernete's learning curve is pretty high.

The in-house team only.

It's open-source and free, so pricing should not be applied here.

Google Kubernetes Engine is free in the simplest setup, AWS Kubernetes Engine costs about $50 (depending on the region), in a three master setup, so it's almost the same as the cost of the EC2 instances and it's totally fine from my point of view.

We prefer Kubernetes due to the unification and the next level of the platform itself.

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.