Kubernetes Reviews

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.

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. 

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 Kubernetes for deployment of TIBCO software analyst. We then use Rancher to deploy the Kubernetes cluster.

Kubernetes is POD technology so you can run the number of containers you need to host one by one and use similar microservices for the containers. This is a great feature of Kubernetes. The product provides auto rollback functionality and a scale-up and scale-down functionality. These are the main features that we didn't previously have. For scaling or restarting PODs or any services is very easy. We can configure the commands to easily scale up and scale down, based on the load requirement. If some business servers added more load, then we increase the POD, and increase the services. 

Kubernetes lacks some flexibility compared to other products such as OpenShift. 

I've been using this solution for four years. 

The solution is stable.

The initial setup is straightforward. We have our own Terraform script to deploy the Ansible. It provisions the orchestration and deploys Kubernetes and we install Rancher over Kubernetes and deploy the entire orchestration. We don't use any third parties. We carry out our own maintenance because we don't want to be dependent on third parties.

We use the open source solution and only move to the commercial platform for the purpose of node vulnerability. We use Instana and Qualys agents for security monitoring vulnerability purposes. 

For anyone wanting to use this solution, it's important to know the basics of Linux. In addition, Docker plays an important role and it's worth checking the YAML files before moving to Kubernetes. 

I rate this solution nine out of 10. 

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.

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.

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.