Kubernetes Reviews

At my company, we use Kubernetes to host our databases and applications. We work in the telecom domain, and our products use database technologies like Oracle, Postgres, and Cloudgres. We use Kubernetes to host NoSQL databases like Couchbase and Postgres and for some of our containerized applications. We are involved in multiple projects, not just a single one.

Kubernetes is a microservice. So, the best thing about Kubernetes is that most of the containerized applications are centralized. You don't need to develop specific company applications on top of container images. Kubernetes also provides flexibility in maintenance. It takes away most of the maintenance part, such as if a port crashes, it comes up automatically, making deployment very easy. We just need to run a few commands to deploy the application, and maintenance is taken care of by Kubernetes. Upgrading applications becomes smooth, requiring less effort and time.

Resource utilization, cost savings, and portability are additional advantages of Kubernetes. It is available in the public clouds, and portability becomes very easy. When it comes to networking, Kubernetes offers very flexible containerization with the added benefit of CSI.

There are several areas where Kubernetes could improve. For example, in one of our database projects, we needed a storage layer that would work on safer sites. Our application is a permanent one that requires low latency and is intensive in terms of networking. It works on every single URL and needs access to the database. After researching several solutions available in the market, we went with Portworx for the database back-end storage layer. However, we encountered an issue when we brought down one of the worker nodes in a cluster of three nodes. The pod that was hosted around that worker node was not responding on other worker nodes, even though it was responding. We found out that there was a feature in the alpha stages in the stable site that could have solved this issue, but we don't enable alpha features in our production environment. Therefore, we increased the replication factor in the storage layer from one to two to avoid this issue. Our application is latency-sensitive and demands low latency in terms of network and response time.

So, increasing a replica of the storage level will also cause double the I/O, which has additional costs involved. We did extensive research on that and found that the feature needs to be stabilized; certain improvements are required. 

I have been using Kubernetes for around two years now, and I'm familiar with it. I worked closely with both the implementation team and the engineering team as well as the research and development team.

It is a stable solution. 

Scaling up and down is easy in Kubernetes, so adding or removing worker nodes is simple and straightforward.

The engineering team uses it the most. We started with three projects, and now I can see around 150 to 200 people using it.

There is a good support community available.

It's free and open-source; anyone can use it. So there are no hidden fees or anything regarding Kubernetes.

I would encourage you to start with Docker containers first, get the hang of it, and then move on to Kubernetes.

Understand the Docker concepts, software, container networking, and how container images are built. Once that's done, it becomes easy to enter into the Kubernetes world. Kubernetes is an orchestration tool that builds on top of Docker containerization.

I would rate it as excellent because it is very easy to deploy applications, manage ports, and expose applications both within and outside the cluster. Kubernetes also has a good reach and can be used in both private and public clouds, and there is plenty of support in terms of documentation and online forums to help users who run into any issues. 

I was probably using Kubernetes from the operational side. The service requires high availability, ensuring 99.99% KPI for our customers. So, we primarily used Kubernetes for this purpose and for managing our services.

Kubernetes has everything. Its design structure is quite advanced, and its offerings are extensive. The practical feature was the seamless failover.

The big part has been the design of the environment and the configuration training itself. Then, they program in the test environment, establishing whether everything else is working. Once we hit the deployment on the test environment or the staging, we move to live. The challenging phase of that exercise is if you don't get the configuration right from the beginning to be able to adjust and change.

Kubernetes's configuration could be made easier, especially at the network level, including aspects like IPs and ports. Integrating it into our services was quite challenging.

I have been using Kubernetes for eight years.

The product is stable.

We service about three point four million transactions.

We had approximately twenty-two servers, with eleven on each side. So, we've got two sides, with eleven servers on one side being SQL servers. It took us about three months to set up the infrastructure, and the installation configuration took about one and a half months.

Six engineers were required for the solution's deployment.

The return on investment in terms of the services that we were offering was quite good. However, as we started to scale down, we lost the contract. Therefore, maintaining the environment then became very expensive.

The solution is expensive. The salaries of Kubernetes engineers were much higher. They came at a high price. Resources also came at a high price, and therefore, it became very expensive to continue with Kubernetes

The tool is not difficult to maintain, but if you've got problems, troubleshooting and devising can be challenging.

It was beneficial and very complex. The skills development for the team working on it was a little steep. It's more complex compared to other solutions similar to it. It's quite robust and nice, but the learning curve is steep.

In terms of resource management, for instance, if you run out of memory or usage capacity, Kubernetes seamlessly moves your workload from one node to another without any issues.

I recommend the tool primarily for enterprise businesses that can afford the cost associated with Kubernetes, including the end-to-end resources needed, such as people, systems, processes, and so forth.

Overall, I rate the solution an eight 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.

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. 

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.

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.

Kubernetes is a container-based platform that is used for microservices-based applications. 

You can containerize and deploy your ports, as well as expose them over the internet, to get your applications running.

The performance is good.

The services it provides you are good.

It runs in multiple availability zones.

The configuration is a bit complicated.

Because the platform provided is so simple, additional configuration is required to get your apps up and running.

There are some issues with the upgrades. When updates are released, the older versions are decommissioned. 

The updates are quite frequent and are lengthy. It takes about an hour each time.

I have been working with Kubernetes for approximately two years.

It's cloud-agnostic Kubernetes, we have it available in Azure, AWS, and GCP.

In the two years that I have been using Kubernetes, I have not experienced any issues with the stability of this solution.

Our main e-commerce application is running in Kubernetes. Currently, we have three applications running, and we are trying to onboard different applications.

You need to have knowledge of Kubernetes to manage the cluster and to complete the deployment.

It can take 20 to 30 minutes to configure the Kubernetes cluster.

Once the setup is complete you can have your dependencies running in Kubernetes.

You need a core technical person, who is a DevOps engineer who has experience working on Kubernetes to deploy and maintain this solution.

We evaluated ECS, which is a service offered by Amazon.

It's an orchestration tool, but it has certain limitations.

I would highly recommend this solution to anyone who is considering using it.

I would rate Kubernetes a nine out of ten.