Kubernetes Reviews

We have several use cases, but our primary use is for microservices.

One of the most valuable features is the thickness of the cloud platform or on-prem file, which makes the solution straightforward to shift and scale. It works well with different types of deployment strategies and networks.

The product features good integrations with other platforms. 

It would be great if Kubernetes could handle a level of data backup.

We have been using the solution for around five years. 

The solution is stable, and I rate it ten out of ten here. 

The platform is scalable, and we have over 30 customers using it. 

Most of our users have a basic knowledge of our definitions and account flows, so the standard practice is to raise issues when we encounter them. Kubernetes technical support can deal well with the kind of problems we face.

The initial deployment was straightforward; we used Kubespray in Ansible, and it took less than an hour.

Kubernetes is free; it's open-source software.

I rate the solution ten out of ten. 

The tool does everything we need, and we believe we have made the best choice.

I'm hesitant to recommend the platform as I prefer people to decide for themselves what is best for them, and I don't want to push a solution if someone doesn't need it. Some users will have issues only Kubernetes can solve, and they should find out how to leverage it.

This solution is used for serving DevOps.

Kubernetes is quite controversial. It increases developers' overhead and allows them to provide trolling updates and zero downtime. In addition, it has increased the possibility of delivery of new features without training downtime of the application.

All the current features are quite harmonic, and they require each other.

We have been using this solution for about two years, and it is deployed on the public cloud.

I rate the scalability a ten out of ten. It is infinitely scalable, and no feature can scale like Kubernetes. How much we use the solution depends on the company's business needs.

We did not use other solutions and have only used Kubernetes.

I rate the initial setup a four out of ten. It requires call writing come, YAML files and help to chart things done. You need to add something new to improve the solution and handle the traffic. The deployment was completed in-house, and one person was enough to complete the deployment.

We have not seen a return on investments. It's saved the possibility of rollout and zero downtime from projects. It's like the biggest advantage of the human ordinate.

It is an open-source solution, so it is free to use. People on the internet always advocate for cheaper options. If you want to use a managed solution, you'll have to pay for it, and it can be expensive if you manage it on your own.

I rate this solution an eight out of ten. Regarding advice, if you have a small infrastructure, do not go with full Kubernetes. Instead, use smaller solutions like K3s or Rancher and full Kubernetes if you have a vast infrastructure.

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.

There are many use cases. It's a concept of microservices-based architecture. You will find that Kubernetes is the most reliable solution. I work for a digital advertising company, for example. When you have advertisements that are served on the top of a website, or a sidebar or something, you fill those spaces with digital advertisements. It's a complete market product, and our end customers are media houses and advertisement agencies.

We are using 600 or 700 or more microservices on microservice-based architecture, and, in order to run the microservices, we use the container-based technique as it is a much more reliable platform. It's more secure due to the use of isolation techniques. Currently, we are running an almost 190 node cluster. That is a very big cluster.

This is how it is used in an advertising context: if there is a cricket game being streamed on a web portal, which has a very high viewership, a lot of companies will want to promote their ads while this particular match is playing. The portal itself is responsible for managing its streaming activity. At the same time, our company is there to display the ads on the sidebars. In such a scenario, where a high volume of people are working on some content and to handle the advertisement from the various media outlets, we need a very good auto-scaling structure. Kubernetes works well for this. At any given point in time, there is a concept for a horizontal port auto scaler based on CCP utilization. Kubernetes itself tries to increase the number of ports, which means it'll try to increase the number of instances, which are running.

Another example of how we use Kubernetes is in a banking environment. In this case, they have an on-prem version. They do not have a cloud solution at all. Occasionally, there is a high volume of transactions happening. They need flexibility. They need high availability and the very beautiful thing about the Kubernetes is that, behind the scenes, these companies are doing their own development of their own applications.

At any given point of time, if version one of the application is currently running in their data centers in form of Kubernetes, it is very easy for them to launch version two. If version one is running, and another version is running slowly, we can divert all the requests, which are coming to version one over to version two. The moment a customer accepts that particular product, we remove version one, and version two is ready. There is no downtime and no complexity. 

The deployment strategy is great. If we look into any other framework, we do not have a good deployment strategy here. The Kubernetes framework itself gives you fantastic deployment strategies with rolling updates. 

We can completely decouple solutions, which means we can scale as much as we want. Technically there are no limitations. The way you can scale up and scale down your cluster with very few commands is amazing.

With the high availability, I can put some intelligence on the top of it. We're capable of handling any type of application nowadays. While there were limitations in previous versions, we don't need to maintain the previous state of the application. The moment our application restarts, we are not required to remember what we have used before. We do not require memory. 

The product is highly scalable. 

Security-wise, there are a lot of frameworks that are available. 

The product offers security, scalability, high availability deployment, and scheduling mechanisms. These are all features that people are passionate about. 

There are a lot of complexities. They're a lot of components that are working together internally. If you look into the installation methods nowadays, it's better, however, previously, it was a very complex process. It's improving. It could still be better. Currently, we do have a very simple method in order to install Kubernetes. 

They need to focus on more security internally. The majority of the security is coming from external frameworks which means I need to deploy a third-party framework to improve the security. For example, there's Notary, OPPI, or KubeCon. Basically, there are some areas where I need to take the help of a third party. 

The solution requires networking dependence. Kubernetes does not have its own networking component. Once again, I need to work with a third party. It is fully integrated, no doubt about that, however, I need to be dependent on third-party components to make it work.  I want Kubernetes to improve security-wise and make their own stack available inside the core Kubernetes engine to make the secure implementation. If they can integrate the networking component inside the core component that would be best. With dependency removed it would give more choice to the customer. 

Currently, they're improving immutable structures and a lot of things. They're coming out with version 1.21 in order to reduce some security issues. They are removing the direct dependency from Docker. There are many areas they're working on. 

A policy enforcement engine is something people are really looking for, which could be part of the four component vertical port auto scaler. A horizontal port auto scaler is already available, however, a vertical port auto scaler should be available. 

If there was a built-in solution for login and a monitoring solution, if they can integrate some APIs or drivers where I can attach directly any monitoring tool, that would be great.  

I've worked with the solution for almost six or seven years. I've worked on this particular product rigorously. Earlier, I used to work with on-premises solutions which involved deploying the Kubernetes cluster with the hardware in a cube spray, which is the latest method.

The performance completely depends on the user. Typically, it's stable. 1.20 is a quite stable product as they have improved in many areas. Currently, that is the one stable version. Technically, yes, they are making their products stable. No doubt about that. That said, stability is an ongoing process. They are trying to improve the product in different areas. 

Performance-wise, it completely depends upon how you define and how you design your cluster. For example, what are the components you are using? How have you made your particular cluster, and under what type of workload? I've worked on medium to large scale workloads, and, if you rate out of five, I'd give it a 4.5. It's got a very good performance.

I would recommend this solution to large enterprises. That said, small enterprises still have very simple options available to them which are reliable and secure. It is very easy to manage. Still, it's more suitable for a large-scale company or maybe something that's in the mid-range, and for a small organization, I do not recommend it.

The scalability is quite impressive in this product.

The major setback of the product is the technical support. They might provide some sort of email support, however, you cannot rely on it. 

You never know when you are going to get the response and unfortunately, when it comes to having a third-party component that you can use to build your Kubernetes cluster, those are also open source, and there is often no technical support, no email support, no chat support. Many have community-based support, which you can depend on. 

This is a major setback for the user. It's the reason customers need to hire a consultant who is rigorously working with the product. In my case, as a consultant, 24/7 I'm using the Kubernetes container and OpenShift. 

Due to the lack of support, other companies take advantage. For example, Red Hat. Red Hat says, they'll give support for Kubernetes, however, you have to use their product, which is called OpenShift. If you look into the OpenShift, OpenShift is basically Kubernetes. There's only one more abstraction layer provided by Red Hat. However, Red Hat will say, I will give you the support, and it's a product made by them, so they know the loopholes. They know the way to troubleshoot it. They know what to debug. They can provide support - if you use them. Rancher is another company that does this. It's basically a Kubernetes product, with Rancher as the abstraction layer, and they will provide support to their clients. Cloud providers also have jumped onto this particular approach. If I get something directly from the Cloud provider and the Cloud provider is taking responsibility, then I don't have to worry about troubleshooting and support at all. What I need to worry about is only my client or workers and my application, which is running on the top of a particular stack. That's it.

Previously, the initial setup was complex however, right now It's pretty simple.

Nowadays, deployment will take ten to 15 minutes, depending upon the number of clusters you want. If I talk about the single master and a simple testing purpose, it's ten to 15 minutes. A multi-master technique will take possibly one hour or maybe less. It's pretty fast. In previous versions, it would take an entire day to deploy. There used to be a lot of dependencies. 

A lot of maintenance is required in terms of image creation. Maintenance is required as well as far as the volume is concerned as space is one of the main challenges. Network support is necessary which means continuous monitoring and log analysis are needed. 

If I set up the cluster as well as operational maintenance activity, I need proactive monitoring and proactive log analysis. I need someone who can manage the users, authorization, and authentication mechanisms. Kubernetes does not have an authorization authentication mechanism. I need to depend on a third-party utility. Sometimes a developer will ask you to create a user and give some provisional space. There are many activities, daily activities, that need to be covered.

In the world of management, Kubernetes does not have its own mechanism. That's why there has to be some administrator who can provide the volume to the Kubernetes administrator and the Kubernetes administrator can decide to whom they give the space. If an application is required, they will try to increase the space. 

I work as a freelancing consultant. I am actually providing consulting for the company, which I work for. I help my end customers who are service providers. I work as an independent consultant for this particular product.

Even though the solution is open-source, one major service we need to pay for is storage. Normally we are using the storage from EMC or NetApps or IBM. These companies created their own stack of provisions and if I want to use their storage for my Kubernetes clusters, these are the license stacks that I need to purchase.

Storage is the major component, as the licensing is based on that. Technically, there's an operating system license, which is something that I need to pay by default for every node, that I'm using. Other than that, with any other framework now, OPPA is completely free. Calico is completely free. A lot of frameworks are available. A framework is going to make sure that our entire Kubernetes cluster is based on compliance and is compliance-specific. Whichever customer I'm handling, I always look for ways to save them money because at end of the day, as they're investing in a lot of operational costs. I try to seek out mostly open-source products which are stable and reliable. Still, even if I do that, storage is an area where people need to pay the money.

The company I am working for is just a customer and end-user. 

1.20 is a quite stable version at this moment, however, Kubernetes does have another more recent version of 1.24.

For us, 40% of customers are working on the cloud and 60% of customers that have compliance policies are deployed in their own cluster and are not using a managed service from the cloud.

There are a lot of caches available. Using the cloud-based instances as one of the nodes in the Kubernetes cluster is acceptable. The question would be how many people are using manage services by any cloud provider for Kubernetes, and that is 30% or 40% of customers. They said they don't want to manage their cluster on their own. They don't want to have the headache of managing the cluster. They are focused on their business application and their business. This is what they want. That's why they are going for managed services. They don't have to do anything at all. Everything can be controlled by the cloud provider.

On the other hand, 60% of people are looking for something that offers full control. That way, at any given point of time, if they want to upgrade Kubernetes, they can. For example, there is an open policy agent, which is a policy enforcement utility or framework, which is available on the top of Kubernetes. By default, if I want to use policy enforcement on the top of the cloud, I do have multiple choices on the top of the cloud. There are some restrictions, however. With on-premises, people want everything to be their hand so they can implement anything. 

One of the major things I would recommend to users is that whenever they are doing capacity planning if they are looking at deploying the Kubernetes on top of their on-prem solution, it will likely require the purchase of hardware. In those cases, I recommend they make sure they understand what type of workload they are putting on the top of their cluster, and calculate that properly. They need to understand how much consumption is in order to understand their hardware requirements in order to get the right sizing on the one-time purchase. They need to know the number of microservices they are using and the level of power consumption in terms of CPU and memory. They will also want to calculate how much it'll scale.

Kubernetes will provide all the scalability a company needs. You can add the node and remove the node quickly. However, if you miscalculate the hardware capacity itself the infrastructure may not be able to handle it. That's why it is imperative to make sure that capacity planning is part of the process. I'd also advise companies to do a POC first before going into real production.

I'd rate the solution at a nine out of ten.

We are an IT services company, and I am part of a team of DevOps engineers deploying Kubernetes for customers. We deploy it on a virtual machine, so you can deploy it anywhere. 

The use case depends on the customer's deployment. For example, if the customer has microservices for lots of applications, they can use Kubernetes to segregate new microservices into different segments. They're not using a monolithic application. The same application has different components.

The best feature is autoscaling. It's effortless to use for scaling deployment parts, CI/CD, etc. 

Kubernetes should improve its consistency across different types of deployments. My customers tell me that they get much better performance when Kubernetes is deployed on VM versus PaaS services from Azure. 

I have been using Kubernetes for about two and a half years.

Kubernetes is highly stable. 

The scalability is an excellent aspect of Kubernetes. It can scale up horizontally and vertically. You can scale by cluster and node. Scalabiity is the best part of Kubernetes.

We have never contacted Kubernetes support. If have a problem, we raise a ticket to Microsoft, and their engineers will help us. 

Deploying Kubernetes is straightforward. The total deployment time depends on the number of applications and repositories we have on that day. If you are only setting up Kubernetes, it takes about five to 10 minutes, excluding the front-end IP, etc. 

Kubernetes is an open-source tool, so you only need to pay for your infrastructure. If you have your own data center, you can install Kubernetes and containerize the server, but if you're using PaaS services from Azure, so you must pay Azure for your utilizing their services. The total cost of ownership depends on your configuration. 

I rate Kubernetes eight out of 10. If your team has experience with containerization, they should work on Kubernetes. It will make development and deployment easier. 

I recommend first containerizing your application and running it in a dev environment to test it and get some experience before implementing it in a production environment.

The most valuable features of Kubernetes are the integration with Docker and there is plenty of documentation available. We work with Docker as a container, and it is more integrated with Docker than VMware Tanzu.

Kubernetes could improve by having better integration with VMware solutions.

I have been using Kubernetes for approximately three years.

Kubernetes is stable. They are the leader in their category.

If the platform for Kubernetes is VMware it is not scalable, but if the platform is Linux, it's scalable.

There are approximately 15 developers and five network administrators using the solution in my organization.

The technical support from Kubernetes is good.

I have used VMware Tanzu previously and I would like to work with it more because it is better integrated with other VMware solutions, such as vCenter, vSphere, vSAN, and NSX.

I have done the initial setup of Kubernetes many times, for me the setup is easy. If I am focused I can complete the full implementation in one or two days.

We have received a return on investment from using Kubernetes.

The price of Kubernetes could be lower. However, it is less expensive than VMware Tanzu. Additionally, technical support is expensive. The overall cost of the solution is approximately $1,000 annually.

Kubernetes is the leader in this category, and are very good. However, if the platform they want to implement is VMware, I would advise using VMware 10.

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.

We use Kubernetes mainly for the apps. We are a government organization, and we have many public-facing apps. We also run all our microservices run on Kubernetes.

I like that it gives you all the flexibility, for example, auto-scaling. Everything is figured out exactly right. It manages all your workloads without much intervention. It can scale in, scale out, and with security. Everything looks pretty good compared to the old legacy way of working.

Kubernetes has been tested and proven. I don't think there's anything that needs improvement, and it has been working very well. But the plugins could be better. That is one pain point we had, and we had to get in with many other open standards, like Calico networking and more. 

I have been using Kubernetes for about three years.

Kubernetes is stable.

Kubernetes was good, and it would automatically scale in and scale-out. We never had issues with scalability.

I have both Cloud Foundry and Kubernetes. Cloud Foundry is much better suited for an organization with less operational stuff. With about three people, you can manage all the apps in it. But Kubernetes needs patching and more, which makes it a bit tricky.

Kubernetes is open source. But we have to manage Kubernetes as a team, and the overhead is a bit high. In comparison, platforms like Cloud Foundry have much lower operational overheads. With Kubernetes, I have to manage the code, and I have to hire the developers. If someone has a product, a developer should know exactly what he's writing or there's high availability, and all those things which impact costs.

I would recommend Kubernetes to new users.

On a scale from one to ten, I would give Kubernetes an eight.