Kubernetes Reviews

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.

We're using it to deploy our machine learning solutions.

Every public cloud has their own version of Kubernetes. For example, Google has its own version, which is known as the Google Kubernetes Engine. AWS has its own version, which is known as the Elastic Kubernetes Services, EKS.

Our entire data team is using the solution. It's between 2,000 and 3,000 people.

The most valuable feature is that it's a container orchestrator. It has a huge user base and it is easily incorporated into all of the public clouds. This is why we wanted to use Kubernetes.

Some of their services could be improved. Kubernetes deploys containers as ports, and there are some services required to communicate between the ports because communication isn't built into the ports by default.

I would also like to have Spark as another distributor service on Kubernetes.

Security could be improved. It would be helpful if there were other security modules built into Kubernetes. Security has to be implemented properly.

I have used Kubernetes for about three years.

Kubernetes is a highly stable product.

It's highly scalable.

We haven't needed to contact technical support.

The initial setup was really easy. It depends on which public cloud you're using and whether you're setting it up yourself. If you're doing the deployment yourself, it takes some time. 

With the public cloud, you just have to click a few options in the UI and then it's done. It doesn't take very much time to deploy.

If you're using a public cloud, the cost depends on the number of nodes you are planning to deploy Kubernetes on. If you have two nodes, it's basically the runtime of these two nodes. With six nodes, it will be the runtime of all six.

I would rate this solution as 10 out of 10 because it doesn't have any competitors. It's a container orchestrator with a huge user base.

My advice is to make sure that the services are hooked up properly. If they aren't, your ports won't be able to properly communicate. Secondly, you should set up the entire cluster properly so that the nodes also communicate between each other. If some ports aren't open, then the nodes may not be able to communicate.

We produce software that connects multiple Kubernetes clusters together. All 50 employees of our company use Kubernetes.

We're building an application for Kubernetes users to consume.

We're creating CRDs for our software, so I would say maybe that the deployment model of Kubernetes is simpler than the life cycle management.

The network policies and RBAC management across multi-clusters could be improved. This is an issue we're trying to solve in the market.

I've been using Kubernetes for around four years.

I rate Kubernetes eight out of 10 for stability. 

For a single cluster, I would rate Kubernetes eight out of 10 for scalability. 

Deploying Kubernetes is complex. If you are deploying Kubernetes as a standalone solution, it's complex all around. However, it's a bit easier if you use one of the cloud providers' managed services.

We deploy it on the cloud. I have the deployment scripted, so it only takes me 10 minutes. I wrote Terraform scripts for that. We have about six people on our DevOps team. 

If you're switching from VMs to Kubernetes, you will see a return because you can pack more into the Kubernetes architecture using containers rather than VMs. You'll see some more savings on your infrastructure, as well.

The cost depends on the cloud provider, so I would give it a six out of 10 for affordability.

I rate Kubernetes a solid eight out of 10. It's only going to grow as time goes on. I recommend contacting a professional to help you deploy Kubernetes.

Currently, I'm working with Adidas. They are working with a third party called Giant Swarm. We take care of the Kubernetes installation, like the infra site. Everything else is handled on AWS.

They have utilized different EC2 instances in order to create Kubernetes nodes, the master node, and a couple of worker nodes. My company doesn't use Elastic Kubernetes services. That is an inbuilt, AWS-provided, AWS-managed service. It's an on-premises managed cluster.

We have multiple applications and different Docker images that are used as part of different projects. Some of the projects use Java-based microservices, and some of the projects use TIBCO as a middleware application server.

The end product is the Docker images, and the ultimate use of Kubernetes is to have an automated deployment job created on Jenkins to deploy those Docker images and Kubernetes clusters. Kubernetes is an orchestrated way of deployment for different applications. It's a shared platform service.

We're deploying the latest version. It's deployed on an AWS public cloud.

It's difficult to count end users because we generally deploy the application in production. Adidas itself has end users with their e-commerce website. The number could be in the millions.

The autoscaling feature is the most valuable. Kubernetes itself is an orchestration tool. It automatically detects the load, and it automatically spins up the new Pod in the form of a new microservice deployment.

Autoscaling is a very important feature. It never interacts with deployment because once any application is deployed in the Kubernetes cluster based on load, it uses the existing application in a different Pod and creates a replica of the deployed application.

There are some UI services available for Kubernetes, but it's not very user friendly if we deploy multiple applications that can be viewed on the UI itself.

I'm expecting more improvement on the UI development side, which can be reflected in each object that is part of Kubernetes, like the Pod, deployment set, ReplicaSet, ConfigMap, Secrets, and PersistentVolume.

Those could be visible for the authorized user from the UI itself. It would help to interact and check the status of these objects if there's an issue with the data or memory.

I've been using Kubernetes for three years.

I would rate the stability as five out of five. 

I would rate the scalability as five out of five.

If we have a problem, we raise a ticket and they respond immediately. Technical support is very fast.

Compared with Docker Swarm, Kubernetes is far better. Docker provides an enhanced orchestration tool, but it's very unstable. You cannot scale or utilize that tool in production. Kubernetes is far better and has a lot of excellent features.

I would rate deployment as two out of five because it's not easy.

It took four to five days to finish deployment. If we start certain deployments from scratch, we have a DevOps team that works on the deployment scripts and creates Helm charts in order to create different Kubernetes services like the deployment set, the ConfigMap, and Secrets. Everything is set up by the DevOps team.

There were about five people involved in implementation, but it depends on the workload. If we needed to create the deployment setup for a single microservice, one person is enough because we have a standard template to use in order to create the standard deployment set. Once the Helm chart is ready, it's just a matter of triggering the deployment.

We created the automation setup using Bitbucket, Jenkins, Helm and Kubernetes. We created a Helm chart first, then placed it in the Harbor repository. It was already automated with the Bitbucket pull request job. In case of any change in microservices, a respective development team creates the pull request to merge the code.

It automatically triggers Jenkins, compiles the microservices, and creates the Docker images. Once the Docker image has been created, it pushes other respective emails in the Harbor repository or Artifactory, which is just like a Docker repository.

There is another job in Jenkins. Once the new email is created, the deployment is a script that's also managed by a different Jenkins pipeline. It automatically triggers and does the deployment in respective Kubernetes services using a Helm chart.

Everything is well-automated. It's pretty simple after setup is completed. Setup is a one-time activity, but it takes a lot of effort because it's very complex.

A third party takes care of maintenance. We don't have access to the cluster level.

Deployment was done by Adidas itself. The cluster setup was done by a third party. The cluster availability was provided by a third party. The deployment team then deployed the microservices Docker images to Kubernetes.

A third party manages the Kubernetes cluster, and it's quite complex. I have experience with creating clusters. As soon as we started using EKS, Elastic Kubernetes Services, which is managed by AWS itself, it was very simple. We don't need to take care of the cluster stability or cluster scaling.

For example, microservice itself is a micro application. The whole activity takes about five minutes.

Kubernetes is open-source. It's free, but we're charged for AWS utilization.

I would rate this solution as 10 out of 10.

Kubernetes is an excellent tool with many rich features. I would definitely recommend it. From a learning perspective, users should start with Minikube.
It's a single-node Kubernetes cluster that shows how Kubernetes utilizes their main component, which hosts different elements like the Kube Controller Manager, SCD database, and scheduler.

Everything is a very compact Minikube. You can start with the Minikube deployment, and as soon as you feel comfortable, you can extend your deployment to the main Kubernetes cluster with different nodes because it's very helpful for autoscaling. There's node level and Pod level scaling. Both of these features are available in Kubernetes, so it's very flexible.

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.

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

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

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

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

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

Kubernetes is generally stable. 

Kubernetes is scalable if it's well-administered. 

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

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

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

Kubernetes is open source.

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

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.

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.