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. 

The primary use case of the solution is container orchestration for a microservices-based architecture.

I worked on deployment in the cloud and on-premises.

The solution has improved our organization by providing a computing layer abstraction between the cloud provider and on-premise. This has given us higher consistency in management and deployment strategies. The solution also reduces the effect of discrepancies between development and production environments.

The most valuable feature of the platform is the auto-healing and auto-scaling ability to offload to the platform tasks that were previously managed by humans.

There is a large ecosystem of products surrounding Kubernetes, making it difficult to identify the right solution due to the vast number of options.

I have been using the solution for six years.

The solution is a stable mature platform.

Scaling is a straightforward and standard process. With the integration provided by the cloud provider, we can even enable automatic scalability.

Setting up without Kubernetes provider services is complex.

I give the solution a nine out of ten.

There is a large amount of overhead associated with maintenance, as we have to maintain everything from the operating system to the application. The cycle of updates and patches for the platform itself is very frequent, with a new version released every four months and various security patches in between. This makes the maintenance task very large if we have to do it ourselves.

The main benefit of Kubernetes is that it is currently the standard for container orchestration. Kubernetes is available across different cloud providers, providing consistency in management and portability that is not available with other products.

In the beginning, the solution may feel as if it has a lot of moving parts that are confusing and overwhelming.

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 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 this solution for the hosting of micro-services. Kubernetes helps us to orchestrate all the containers hosting these micro-services.

One of the most valuable features is the ability to manage containers and pods. The solution monitors if applications are live and if issues are picked up, it automatically resolves these. This solution keeps our application in working condition. 

This is an open source solution, which gives the community the opportunity to request specific features which the Kubernetes team then work on and add to the solution.

We would to have additional features related to security within the API, instead of needing to install an add-on. 

I have used this solution for almost four years. 

This is a stable solution. 

This is a scalable solution. We are able to ramp up certain campaigns which this solution manages well. We have 400 to 500 people using this solution. 

This solution took one and a half years to get ready in production. We needed to explore a lot of add-ons in order to deploy into the Kubernetes cluster. 

This is a really useful solution that is particularly useful for organizations using micro-services. This solution is not suitable for use with monolithical applications. Kubernetes works well in an on premises or cloud environment.

The suitability of this solution may vary from company to company.

I would rate this solution an eight out of ten. 

If our project requires a cloud deployment we will use a cloud provider's version of Kubernetes. For example, Azure or AWS Kubernetes Elastic Services. We try to make use of whatever is provided by the cloud providers. 

If the project requires an on-premise solution we use products from various vendors, such as Red Hat or other open-source products that can be downloaded and installed for free.

We are using Kubernetes for container management.

Kubernetes use cases are typically containerized application hosting. This is the basic use case that we do. Another use case can be deploying new application microservices which are loosely coupled and containerized using microservices-based architectures.

We can achieve a reduction of almost 50% to 60% of effort in operations by using Kubernetes.

The most valuable feature is the Zero Touch Operations, which involves a new way of performing operations and support. We do not have to do maintenance, the operations are very simple.

Kubernetes can improve by providing a service offering catalog that can be readily populated in Kubernetes. 

The service catalog, for example, could be a CRM application on Kubernetes or an eCommerce retail application packaged on Kubernetes and to be readily deployable. Instead of somebody trying to figure out all the configurations of hosting this on Kubernetes, if something was readily available, which the developers for these CRM or eCommerce products, they could partner with either AWS, Google, or Azure and make the deployment of such applications readily available on Kubernetes. 

This would allow very little work for a business to go live. The business can quickly straight away and subscribe, launch, and use. It is not difficult for an IT team to be involved to create an application environment to start up. It's would be much easier for businesses to use it directly and start off the applications.

I have been using Kubernetes for approximately three weeks.

The stability of Kubernetes depends on how we have designed it. Our design is stable because I know how to design it and if something goes wrong how to fix it.

The scalability is superb, it is highly scalable.

We have 75,000 employees in our organization that is using this solution.

Technical support is not used very frequently. We use advanced-level support occasionally. It is only in certain circumstances when we have some advanced complexity that we reach out to an expert.

A person with a moderate level of knowledge on Kubernetes, with the help of the community forum, and documentation, most of their problems can be solved.

We do not need any particular company, such as Red Hat, to come in and support the Kubernetes environment, or some other company, such as Ubuntu Canonical to be signed up for a contract to support Kubernetes. It's not required.

The initial setup is straightforward, it was not complex.

The maintenance for Kubernetes is very minimal.

You need to pay for a license if you buy branded products. For example, if you take the services from Azure, AWS, or Google, the price of the Kubernetes cluster is inclusive of the service that's being offered to us on a pay-and-use model.

I haven't tried all the advanced features of Kubernetes, but I feel it is meeting most of the requirements of a new design architecture for applications to be hosted. I don't see any particular functionality which is not available for me as of now.

The open-source ecosystem is providing lots of ideas to solve all kinds of problems. The open-source ecosystem of developers, implementers, and integrators is providing lots of ideas. If there is something I may not know, I look up to the community forum and receive answers. There are no issues of finding something, however, Kubernetes by itself has to improve. It is a matter of the implementer to discover ideas to solve the problem. The Kubernetes engine is designed very well.

I would highly recommend this solution to others.

I rate Kubernetes 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.

It's a mobile phone application with a website written in Angular 8. It's a strategic microservices solution. There are a lot of containers and resources. The application is written in Java, and we are using Spring Boot, the second version. We are also using the application-gateway of Azure.

If you want to do the microservices strategy, you need to split the services to the smaller work. There must be containers in Docker. There are not that many good solutions for Docker. So right now, if you need to use Docker, you choose Kubernetes because they are number one for the container orchestration solution.

The auto-repair function in Kubernetes is perfect. When something breaks, the auto-repair function automatically repairs it. If you are running the content in Kubernetes, you have a good setup. You do not need to do anything for the management of this. So, the automation of Kubernetes is number one.

The Kubernetes dashboard can be improved. It is currently a mess. We were using Rancher earlier, and everyone was happy with the dashboard. Right now, we are using Kubernetes, and it's not working with Microsoft workstations. Aks is using mcr.microsoft.com/oss/kubernetes/dashboard:v2.0.0-rc7 for dashboard. It has problems with auth. It constantly deletes tokens in kube/config file. And auth with kube/config file is not working on mac. It does not work on chrome in windows 10. It is still laggy and slow. Auto refresh function is not working correctly and you need to refresh your browser. Older versions have similar problems. There is no restart function such as in rancher. There is no possible to restart or scale more deployments at the same time. You need to write script for that. Graphics design is out of date. After a while of not clicking anywhere it give you 401 and you need to login again.

I have been using this solution for two to three years. 

The stability is totally perfect because if something breaks, it gets auto-repaired. We had only one failure, but it was not the failure of Kubernetes, it was the failure of Azure machine.

The scalability is great. You have scale sets, and every scale set has node tools. You have different types of refurbishing, and you have a node count. If I need more CPU or more information, I just change the node count, and everything is run in the cloud. It will automatically pull the new node to Kubernetes in the product label, and the load will run there. 

I also used the downscale and upscale features. You can also automate the scaling, but I didn't try that. I would love to use that. I am using manual scaling. If I need a new installation, it takes two to ten minutes in a cluster. This can also be done by the junior admins in one click.

Support is the only problem we face with this solution. I don't know which plan we have, but our software is stable. We are also a customer of a reseller, and we need to open tickets with the reseller. After that, we open a ticket in Microsoft Azure, but it takes two or three weeks to get an answer from the technical guy from Microsoft, which is terrible. It could be because we have the basic support.

We were using Rancher 1.6 before, but it reached the end of life. Right now, the version is Rancher 2. In my opinion, I don't need to put another layer of Rancher 2 when I already have a good solution from Azure. So, I chose the Azure solution.

The initial setup is more complex because you don't only set up Kubernetes. You also need to set up some CI/CD solution, and you need a setup to back up your workload to the Kubernetes. If you want to deploy the workload to Kubernetes and you want to do it efficiently, you need to have Helm. Helm is for catalog package for Kubernetes. So, you need to know how to work with Helm. 

You need to create docket files or some DevOps scripts for deploying ability. The solution is complex. You definitely need to have an experienced DevOps person. If you have juniors in your company, they will not know how to set up the solution, which is not good. You need to have experience in tech DevOps.

For small setups, it doesn't matter. You run Kubernetes, put some containers, and you play with it. That's okay. However, if you want to run it in production with everything, it needs experienced DevOps staff. We have a team of up to 10 developers and DevOps members.

Yes, I am a certified administrator. Deployment was very easy. I deployed the Kubernetes service alone to run some workload in Asia. There is an automation feature in this solution. You only open one page and fill some requirements, and everything goes out to the team. It was great. 

I had everything scripted in the platform with code in 50 minutes, but this is only for Kubernetes, the infrastructure, and the network stuff. I had scripted everything again, but it was in the Ops script; not in the platform. I could deploy the complete workload within one hour.

The management layer is free, which is perfect. You don't need to pay money for the management layer, but in AWS develop service, you need to pay. I think it is €75 per month for the management layer. It is free here, so you can have as many Kubernetes clusters as you need. You are paying just for the workload, that is, for the machine, CPU, memory, and everything. 

I am still using the basic Docker Compose, which needs low care. I tried Rancher 2, but I don't have it in production. I also used Elastic Kubernetes Service (EKS), and I also tried the Google Cloud Platform. 

I think Google Cloud Platform is the best one, but here in Slovakia, we don't have enough support for Google Cloud, which will become a problem. If I can choose from the integration, I think the Google integration is the best because we could get into the Google products, but here in Europe, we don't have the support for Google Cloud Platform. 

Kubernetes is a great product. I am currently also helping a customer with the implementation of AKS because they only have a private cloud, and they want to have a hybrid cloud. I highly recommend to use this feature, and not to install Kubernetes manually or use some third-party tools. The Azure community service is better implemented than AWS community service. 

They are not good at planning the upgrades for Kubernetes. So, you really need to constantly upgrade the cost. The upgrade is automatic, but Azure changed the integration of load balancing, and I was forced to re-deploy all costs, which costed my company. We need two clusters at the same time from every environment. So, this was not good. I contacted the support, but there was no way to change the integration of the load balancer. I hope this will never happen again in the future.

I would rate Kubernetes an eight out of ten. The dashboard and support could be better.