Kubernetes Reviews

Our organization has an extensive online platform available to our customers, who are geographically spread between the United States, Japan, and other parts of the Far East. The platform's backbone comprises around 120 microservices, and we use Kubernetes to host most of them.

The Desired State Configuration is a handy feature; we can deploy a certain number of pods, and the tool will ensure that the state is maintained in our desired configuration.

The features regarding scalability are also valuable. As part of our DevOps, I am involved in some enhancements where we plan to use pod scaling and the available AKS node scaling features. These are available native to AKS, but we do have to set up some matrices to control scaling and define scaling rules. The fact that we can achieve that dynamically is a significant part of why we use the solution.

Kubernetes is an excellent platform for hosting microservices, especially container-based microservices.

The solution has some issues regarding availability during high loads. Worker nodes are sometimes unavailable, affecting the overall availability of the applications. This is a bug or underlying problem with the tool, and Azure and other providers are looking into improving this by releasing new versions of Kubernetes that fix some of the platform's issues.

We usually encounter a few bugs, and as part of our partnership with Microsoft, we tend to share that data and receive active support from them. They are constantly improving the product.  

Many options are available from third-party vendors and open-source providers that build upon AKS, or Kubernetes in general, especially regarding monitoring and telemetry. Perhaps incorporating similar features into the native solution would be a good improvement. However, the solution, with the core engine and the supporting ecosystem of open-source projects and other available features, covers the entire spectrum of what we need to do.

I've worked on different projects using Kubernetes as an application hosting platform for two or three years.  

The product is stable; it has benefited from a few years of worldwide production-level experience and customer feedback. That's the base, open-source version of Kubernetes. There are numerous vendors with their own flavors of the solution, like AKS and Amazon, which are also pretty stable. Rancher isn't open source, but it has many features that make it easy to maintain, so it's also stable.

We have around 2000 total users, including end users and DevOps users. 

I have contacted technical support on a couple of occasions.

Neutral

We used a version of Rancher Kubernetes to manage an on-premise instance of the solution. I'm very familiar with the tool, but I'm not up to date with any of the new offerings available with Rancher.  

AKS and other managed Kubernetes instances are quite easy to set up. However, depending on the project requirements, it can become more complex.

For example, a previous project I worked on had some stringent rules around networking policies, traffic routing, etc. The tight security policies meant we had to use a highly customized virtual network upon which the AKS instances were hosted. We went with a Kubernetes networking model, which might have been called a container networking model. This model required each pod to be provided with an IP that was part of the actual IP range within a network, so pods had real IP addresses. This kind of implementation becomes more complex.

In terms of native setup, Kubernetes has its own internal networking system and cluster IPs, which facilitates easy pod scaling, so native implementation is relatively easy. When projects have higher security requirements, the implementation gets a little more complex, but it's still much more straightforward than a self-hosted cluster.

An entirely self-hosted Kubernetes cluster is the most complex. We have to set up every aspect, including the master nodes, worker nodes, and networking, which requires dedicated Kubernetes administrator resources. We previously implemented an on-premise Kubernetes cluster, and it takes significant effort and dedicated resources to manage that sort of cluster.

I would say the solution is worth the money, but it depends on the required workloads, the type of workload, and the scaling requirements etc.

Ultimately, we're using the computing power on the nodes, so they need to be appropriately scaled according to the workload. With intensive workloads requiring large machines, I'm curious to know how much savings one would have purely in hardware cost compared to using standalone VMs.

I would rate the solution an eight out of ten. 

The solution is deployed on a private virtual network belonging to our organization and in the Azure cloud. The interconnections with on-premise are purely through VPN gateways and so on.

Regarding POC-type projects, I recommend using a trial version of Kubernetes with Rancher or a very lightweight configuration of AKS. It's essential to consider the factors involved in analysis and precisely what you want to find out. Based on that, tests can be conducted to determine the solution's available benefits. It also depends on the kind of workload; if that consists of microservices that can be easily containerized, then it's worth investing some time and effort into AKS. POCs can generate some numbers regarding costs, performance, scalability etc. 

If the setup is well designed and the appropriate workloads are shifted to Kubernetes, there's a lot of flexibility available for DevOps to scale their applications. There are also many available monitoring, telemetry, service discovery, and service mesh features. If the architecture is well-planned and devised, the Kubernetes platform can provide significant benefits.

We use this solution to assist with our infrastructure development work.

This solution provides a comprehensive way to scale up our ports and containers, without having to use multiple products.

The solution does not work with third-party tools, or alternative cloud providers, which limits the extent that we can utilize it to.

We would like to see visualization support added to this solution, in order to provide a wider single view of the infrastructure. 

We have been working with this solution for six months.

We have found this solution to be very stable; the only issues that have occurred have been from human error in the configuration.

This solution is extremely scalable, if a business has the budget available to do so.

The technical support for this solution is good, as long as you can provide extensive details on the issue that has arisen.

The initial setup of this product is quite complex, and requires time to understand what is needed to implement it properly. However, once the expertise has been gained, the deployment is quick and straightforward.

The solution was deployed using a third-party consultant.

This solution provides a platform for all development projects, which means that once it is implemented for one project, it can then be used for all future ones. 

The solution itself is open-source, so there is no cost attached to it. However, it requires a virtual machine to operate, which does come at a cost; a choice of a pay as you go model, or a monthly charge via an enterprise agreement. 

There is a pricing calculator available, where organizations can determine the level and number of virtual machines required, and how much that will cost.

It is important to understand the structure of the solution as a system in its own right, and we would recommend that organizations invest in vendor neutral training before implementation begins.

I would rate this solution an eight out of ten.

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.

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.

Kubernetes is used for cloud-native development. We deploy it to the hybrid cloud, like private in Azure and public cloud in Amazon AWS. Kubernetes is underlying, and we do not use Kubernetes directly. We use products that use underlying Kubernetes like OpenShift or Tanzu.

I like that it has really boosted cloud-native development and stood the test of time. The underlying architecture allows one to scale as per the business KPIs much faster. The underlying architecture is the master that works faster than the nodes. Then there are pods within those slave nodes, and there is a control pan as a part of the core architecture of the Kubernetes. Once you have the cluster up and running, you can monitor that and deploy your applications into the Kubernetes cluster. 

They should update Kubernetes more regularly. Kubernetes is open-source and supported by cloud-native communities. But there are other proprietary versions of Kubernetes like VMware, which runs Tanzu with underlying Kubernetes architecture, or Red Hat, which runs OpenShift. 

These have priority over the open-source project over the last five years. The Cloud Native Foundation is currently out with version number two. The first version came out 14 years ago. We really don't know when we will see another version or improvement with this totally open-source project.

Scalability can be improved. It should be flexible enough to run two instances that can be changed immediately to four, six, or eight swiftly. They could also simplify the logging process.

I have been using Kubernetes for about five years.

Kubernetes is stable.

Kubernetes is scalable because the underlying architecture allows you to scale faster.

The initial setup and installation are straightforward. You can install and deploy it within a matter of hours.

Kubernetes is open-source.

I would recommend it because of the microservices architecture that allows you to write cloud-native code in the Kubernetes environment. Kubernetes has become a leading choice for most big companies, and they are making their own products based on the underlying Kubernetes architecture. 

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

We use Kubernetes to orchestrate the containers for deploying our Docker images to Kubernetes. I'm an Azure DevOps lead.

Kubernetes has some advanced features like auto-scaling and a good self-healing facility. If Kubernetes runs in the form of ports and one of the ports dies, a new one automatically appears. These advanced features help us to deploy our application and makes life easier.

I find the auto-scaling feature very good because rather than manually decreasing the number of nodes, we can define the threshold.

The UI should be improved. It would be helpful if it was more graphical. Kubernetes currently runs perfectly with the Linux environment because it has Docker as a container runtime, and Docker works perfectly with the Linux operating system. It should also be able to run with the MacBook and Windows OS, similar to Linux and it would be helpful if they would include this in the next release. 

I've been using this solution for four years. 

The solution is stable. 

If you're using a cloud service provider there's no problem with scalability. When there's a newer version, we'll upgrade our Kubernetes cluster to the latest version. 

We previously had an on-prem solution using some tools like ClearCase, which is a centralized repository we used to work under. Given that everyone is migrating to cloud, we've done the same, migrating our applications to AWS and Azure Kubernetes.

Although it doesn't take long to deploy, Kubernetes is difficult to set up even if it's the small, mini one-node Kubernetes cluster. For a cloud deployment, it's either Azure or AWS. The cloud service provider will take care of the master node. We currently have a DevOps team of seven people. If we have a big cluster, we can it into multiple clusters, one for the Dev team, one for the QA team, and one for production; each team can work on its cluster and deployment can be done quickly. 

Pricing depends on the cloud service provider. Comparing AWS and Azure, Google Cloud has a much better pricing model, as does Linode. We receive a monthly licensing account.

It's important to learn the architecture of Kubernetes and know what each and every component of Kubernetes does. It makes the deployment easier. Whether or not you choose Kubernetes depends on your use case. If you have a business model that requires minimal changes with fixed requirements then Kubernetes might not be the way to go. If you're constantly needing to make changes, Kubernetes is a great solution. 

I rate the solution eight out of 10. 

This is a container orchestration platform used to organize our containers. Most of our applications are developed containers. We need Kubernetes to manage the network and volumes. We had approximately 50 tech team members using this solution. 

This solution is cost effective and fast. We are able to use Kubernetes to orchestrate hundreds of container images which has been a major benefit. 

There is a feature called Terraform and, based on the reviews I have read, it could be improved. 

I have been using this solution for two years. 

This is a stable solution. 

You can scale Kubernetes up and down easily.

When it comes to support, we have mostly used the documentation provided for the solution. 

The initial setup is straightforward but you do need to know the basics. The speed and ease of the set up depends on how fast you want the application to be and the amount of traffic your application generates.

When I first started using Kubernetes, it was quite challenging. I would rate the set up a two and a half out of five.

Kubernetes is open source and is an orchestration platform. It is a cost effective solution and its pricing depends on your company and how you use it.

We evaluated solutions like OpenShift and Rancher. The great thing about Openshift is that it is ready to use out of the box. When using Kubernetes, you have to set everything up on your own. Besides that, there are not many differences between Kubernetes and the other solutions. 

This is a very good registration platform. It saves costs and is fast. You can deploy thousands of replicas of your application all at once, as long as you have enough resources. 

I would rate this solution 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.