Kubernetes Reviews

We use the product to manage application deployment by troubleshooting and collecting logs.

The most valuable features of Kubernetes have been autoscaling and its resilience mechanisms.

The platform could be more convenient to use. While the Kubernetes CLI is powerful, the interface needs to be improved. The users often navigate between various third-party IDEs. Thus, a more consolidated or standardized interface could streamline the user experience, allowing easier access without the need to balance between multiple tools.

We have been using Kubernetes for three years.

The platform is stable. However, it depends on the cloud configuration. I rate the stability a ten out of ten.

The product is scalable. We have 20 Kubernetes users working on and deploying it. We plan to increase the usage.

We contact Microsoft in case of any queries as we are working with Azure Kubernetes services.

The complexity of the initial setup depends on Kubernetes services. It is easy to configure while working in an Azure environment. The Azure portal simplifies the process through configurations with tools like Terraform. It is complicated to create the platform on virtual machines and on-premise machines. We can deploy it within 20 to 30 minutes using data pipelines.

Microsoft provides reasonable costs for Kubernetes.

I advise others to work with Kubernetes if they are developing or running the cloud native configuration. However, there are more cost-effective solutions. I rate it a nine out of ten.

We use Kubernetes to run some content as SaaS-based applications, and there are a few more in the pipeline to migrate from the IBM MQ server and mounting to containerization.

The best thing about Kubernetes is orchestration. It is very good. We will not see much downtime unless there are some human errors. We do not see much downtime or issues with the container or automation.

I'm a beginner, and I recently started working with Kubernetes. As of now, I don't see any bugs. However, it would be better if it could be deployed without coding.

I have been using Kubernetes for about six months.

Kubernetes is stable for now. Since we are in the process of migrating, I cannot tell for sure. But my friends have been working on it and do not have any problems. 

Kubernetes is a scalable solution. That is the reason we do not see much downtime. It is always available as needed.

Because I have an infrastructure background, it is difficult for me to code some parts. So, I depended on some experts here to deploy this solution. It is not very difficult for them.

I would tell potential users that Kubernetes is a very good solution and they should use it.

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

Kubernetes is our platform of choice for running things in production, applications, and the like. Everything we build runs on Kubernetes, it's our platform of choice. I'm the principal devs engineer.

Kubernetes has improved our time to market because it's quite lightweight and easy to install. 

The most important feature is container orchestration. Kubernetes provides us with a mechanism to deploy or run in an automated fashion across nodes. I don't need to worry if it's running on node one or node two, it's all taken care of by Kubernetes. 

They have a very minimal interface to do certain things and that could be enhanced so that someone who is not as comfortable on CLI can also use the interface and play around with the cluster. Commercial offerings like Red Hat OpenShift offer it, but the open-source community edition from CNCF doesn't. I'd like to see an incubating project there. It's not one organization that is contributing to Kubernetes, it's a CNCF project, i.e. an open-source contributing forum.

They could possibly promote some data APIs to the production stage. They have a lot of APIs which are in beta stage which they continue to test. Perhaps it's time to upgrade them to a more product-release stage. I think it would offer peace of mind to customers in terms of stability. 

I've been using this solution for four years. 

This is a stable product if you are on a long-term support release. It's quite widely tested and used.

Kubernetes is highly scalable. We have around 150 users and it's used daily, mainly by developers and engineers. 

Kubernetes has a very active and vibrant community forum and people can join Slack Workspace and ask questions there. They announce new releases there too and people help out. If there are issues, you can open tickets, open GitHub issues and things like that.

We previously worked with Apache Hadoop but it was becoming somewhat cumbersome and complex to install.

Deployment complexity depends on the use case. I can install it on my laptop and it's easy but if it's being installed on production it needs to be set up in a cluster formation. That kind of deployment is moderately complex, and that's where we come into the picture, providing the automation for that. For someone without any knowledge in the area, deployment might require a third-party consultant or an integrator to help with that. 

I have some basic experience with Rancher and Red Hat OpenShift, which has a very nice graphical interface. An administrator, developer, or even a user can do a lot of stuff other than just seeing what applications are running. It's something that separates the commercial offerings from the community version of Kubernetes. If there were something like that in the open-source version, it would be a game changer. Of course, the commercial version also comes with hours of tech support and guides.

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.

We use the solution to manage the containers efficiently.

The solution has a well-defined interface for every other function like network, CRA container, and run-time interfaces. It is fantastic as open-source software, very generic, and easy to use.

The solution's learning courses for the new users and developers must be easier to understand. Presently, they are very abstract, and it is challenging for users to find data.

I have been using the solution for a year and a half.

It is a stable solution.

The solution is easily scalable. I rate it ten out of ten. Our technical team for the solution consists of ten executives. At the same time, there are two million end users.

I took help from the solution's technical team for Stack Overflow. Their service was good, and I rate it ten out of ten.

Positive

We switched to Kubernetes for better scalability, maintenance, and administration.

The solution's initial setup was straightforward. I've used Rancher Kubernetes engine to set the cluster. The deployment took two days to complete. The process involved downloading the binary file and configuring it to servers.

We deployed the solution with the help of our in-house team. The team of three, including data engineers and data operations managers, execute maintenance for it.

I have seen a return on investment for the solution. 

We use the solution's open-source version.

It is easy to maintain distributed systems and applications using the solution. Although, it requires a few new features to improve managing the volumes. I rate it ten out of ten.