Kubernetes Reviews

We use Kubernetes to deploy a software solution that the company sells to enterprises. Originally, our company offered their software installed without Kubernetes, but they plan to move all future customers to Kubernetes. I would say it's extensively deployed, and they plan to increase it as much as their customer base will accept it.

Kubernetes provides a standardized way to deliver software in a scalable form. The customers of the software already have people who know how to manage Kubernetes, or they can easily hire employees who do. Packaging up the software to run would require a lot of specialized knowledge.

Kubernetes provides scalable clustering for containers and other means of deployment.

Kubernetes is incredibly complicated, so one area of improvement is the ease of administration. I would like a user interface that you can run to help you debug and diagnose problems and suggest how to configure things.

I've been using Kubernetes for about four months. I started using it at HPE and actually switched to be able to work more with it at the new place.

Kubernetes is generally stable. 

Kubernetes is scalable if it's well-administered. 

As far as I know, there's not any customer support. There's customer support for the cloud instances. If you are running Amazon EKS, they might have support for that. It's open-source software, so there isn't Kubernetes support, but I could be completely wrong about that.

The complexity depends on how you deploy it and what flavor you choose. If you're using a cloud provider like Google, AWS, or Azure, they each have a flavor of Kubernetes you can deploy. It is easier to deploy one of those than downloading and installing it on your servers. There's also something called K3S, a lightweight version of Kubernetes that can run much more easily. It's designed to be used in the Internet of Things. It's relatively scalable and can be used independently, but there are different packages, just like Linux has different distributions.

The maintenance required also depends on how you implement it. It's going to require at least one person who knows Kubernetes. I imagine it might need multiple people to maintain the solution if you're not using the cloud versions.

Kubernetes is open source.

I rate Kubernetes 8.5 out of 10. My advice is to hire people who have demonstrated experience or are prepared to spend significant time taking courses because it's deep and broad, and there's a lot to learn. It isn't straightforward, but it would be hard to simplify it, considering what it does.

This solution is deployed on cloud with Azure.

Managing the container was a challenge. The cloud-managed Kubernetes allow us to take care of a big system and deployment and container management without having a big operational team.

It's still difficult to manage based on my experience. There are a lot of things that need to be done to get it up and running initially. It's very complex. The whole system required a big team, and that's why we were using the managed version. If we were not using the managed version, then it would have been very difficult to manage the system. Overall, it's very powerful, but there are also a lot of complexities to manage.

In the version that we're currently using, we still have to pull in a lot for different tools, like the distribution data, distribution tracing tool, etc. For it to be fully functional, we still have to deploy more tools into it. It should come with more default rules built into it for log aggregation, distributed tracing, and monitoring, so they can definitely improve upon those things. If they had better tool integration for monitoring and log aggregation, then it would be much better.

I've been using this solution for two years.

It's stable.

It's scalable. There are two different ways you can do it. You can manage it yourself, and then you're responsible for scalability software. But if you use a cloud solution, Google GKE and Azure have AKS and AWS had EKS. If we use those kinds of services, the scalability becomes easier to manage. It's definitely scalable, but even that part is very complex to manage unless you're using a cloud managed service.

It was very complex to set up the initial structure for Kubernetes. Using managed services made it simpler.

I would rate this solution 9 out of 10.

Kubernetes is used t deploy all our applications. 

The deployment is one of the most valuable feature. The solution is also easy to use. 

The user-interface in regards to the other solution can be improved. 

I have been using Kubernetes since 2020. 

It is a highly scalable solution. There are twenty people using Kubernetes.

The initial setup and deployment is quite easy. We have one tech team and one Data Science team. 

If you are building an MVP or you are starting small, then Kubernetes might not be the best option because there are some charges associated with it.\  But if you are building an application that might scale rapidly, then you should definitely go with Kubernetes. 

If your deployments happen very frequently, then it is definitely the solution you should use, because you can restore previous versions if something fails.

I rate the overall solution a nine out of ten. 

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 have multiple use cases. We use it for pharmacy applications, databases, MySQL and web servers. We use Kubernetes for anything that runs normally.

The high availability of containerization is most valuable. We get density with planning containers, and the self-serving feature allows our developers to grab a container and complete testing. The self-serving feature is always in the cloud or locally integrated with Ceph or cluster.

The front end of Kubernetes could be built better as the front end is very rudimentary.

We have been using this solution for about five years. It is deployed both on-premises and on cloud but mainly on-premises.

It is a stable solution, and we don't have any issues.

It is very scalable. We can scale up, add notes, scale out horizontally, and scale the number of containers in a web server. We add triggers to the cluster, and it scales as needed. We have quite a few users of Kubernetes at our company, and it is very easy to add new developers as users.

The initial setup was straightforward. For testing, we fire up Kubernetes clusters about once a week for different departments. Depending on the containers, it generally takes about four hours to get a cluster up and running and connected to the storage. We've completed this many times and are familiar with the setup. We completed the setup ourselves.

The Kubernetes community edition is free, but we use OpenShift in production, which is the Red Hat version of Kubernetes.

We evaluated Swarm and some other solutions, but we eventually chose Kubernetes and OpenShift.

I rate this solution a nine out of ten. Regarding advice, in the retail field, where clients would require mobility and portability, and disposable computing, there is no comparison to Kubernetes.

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.

Our setups are all Kubernetes-based. Orchestration and all of that is done through Kubernetes.

The clustering is the most valuable aspect of the solution. Reviewing all the servers and hardware from one common place is great. That is the best part of it.

The solution is stable and reliable.

It's scalable. 

Maybe it's not the scope of this product, however, some analytics information could be more available through this. Otherwise, we have to integrate Dynatrace or some kind of tool. When it has all the servers maybe it's a different scope and it wouldn't work. Some analytics would be so great, however. We'd like insights on the services and their uses, which are very limited. We have to use a third party and paid services like Dynatrace or AppDynamics.

Sometimes what happens is, if we find, let's say, OutOfThread or OutOfMemory, where our threads are blocked. If you are doing real-time analysis, you can find them. However, if it's 24 hours after somebody reports, the product is already restarted. We don't have any information about that. Thread dump and memory dumps are not available. So then we have to wait for another crash to happen. There's a lack of backup storage. That's a daily problem. With Kubernetes, whenever we get this kind of production issue, we are clueless. We can see that time OutOfMemory happened, however, we don't have much information to work with.

Therefore, having a thread dump and memory dump, and seeing how many objects were created would be useful. 

Sometimes we go to drill down. It says CPU utilization is very high. If you go inside, you'll see nothing, no information as to why. Similarly, when it says there were a lot of network errors, however, there is no information available on the network errors. It just says 10% network error, 20% network error. Yet if you drill down, there is no information available. You don't know whether it was a server that timed out, the port was not available, or some other network issue. We need more transparency in that regard. 

Sometimes the DNS Lookup service does not work very reliably unless you enable cache or something. Recently, I used the latest version of Kubernetes, and DNS cache was available, which was not available in the earlier version. Now we notice we're facing a lot of difficulties, like ENOENT errors, or "Host not found" exceptions. Every day they'd say it was an application problem, however, we ultimately figured out the DNS cache was not working properly. With the latest version, when we enabled it, things sorted out. However, when we were trying to drill down in the Kubernetes, it was not giving any information. There's no clear-cut information here as well as to why this was happening. 

I've used the solution for the last five years. 

It's very stable. We have not faced any such problem through Kubernetes. There are no bugs or glitches. It doesn't crash or freeze. 

The solution is scalable. 

We have 15 to 20 people using the solution.

However, it's a two-way setup, and all those things are done by DevOps. That's why I'd say 15 users. As for the users are concerned, we have, let's say, 100 people. All 100 in one or the other form are going to Kubernetes, seeing the ports and seeing that information based on the services they are working on.

I don't think so we have any technical support for Kubernetes. Our DevOps team typically would look into issues. 

I didn't do the implementation. We get all the things set up for us. That said, we see a lot of information. Generally, we are more interested to go through how many parts are running, and what memory is given to each part. All those things we explore. It's very useful and intuitive.

I don't deal with the pricing aspect of the solution. 

I, myself, tried something a long back, however, I'm not able to recall what it was. I am a developer, so my focus is more on the other side of things. DevOps might have looked into other options. I'm not sure. 

We are end-users.

We use the solution both on-premises and in the cloud. 

I'd rate the solution seven 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.