Kubernetes Reviews

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 use this solution to containerize applications. Some of these applications function in Jira, the local tool center. There, we push them to a centralized platform.

It has a complete loading feature set for replica site deployment.

Currently, in Kubernetes, all of the health deployments or monitoring, and the discrete tools need to be configured. Changing this would make it much easier. Otherwise, we have to rely on a external tool to implement the monitoring.

I have been using Kubernetes for a year and a half 

The stability of the solution is a nine out of ten.

The scalability is good. Ten users use this solution at present. 

The initial setup takes twenty minutes. 

Overall, I rate the solution a nine out of ten.

We are basically integrators for Kubernetes because it is open source. And if we go further for any supported version, like Red Hat OpenShift or AWS EKS, Azure AKS. So Azure Kubernetes Service and Elastic Kubernetes Service. So that's where we are a partner as well, partner and integrator.

Our clients use it mainly for application modularization or new applications in microservices, build, and deployment. So where, like, if the client was running it on a monolithic application or legacy application, and they wanted to refactor their application, we convert it to microservices. That means building those container images, and then running them on a platform like Kubernetes so that it can run across different nodes across the data center, and we can manage it. 

Basically, it is more of running as container images. So whenever that application requires more scale-out, features, refactoring, or application modernization, that's where we use this Kubernetes platform to run such applications.

There are many good features. I feel that the scale-out features, like replica sets, are very good. The number of running containers can be autoscaled. So, if there is more load on the application, it will automatically replicate the number of container images running. I feel that that is a very good feature, where there is no need to worry about the incoming load or response time or taking care of scaling. It automatically takes care of it.

Kubernetes is open source, which is both beneficial and negative depending on the responsibilities. Supported versions like Red Hat, Amazon, Microsoft, or Google are pricey. 

It's good for bigger organizations, but for smaller organizations or a few workloads, it may be too heavy, not easy to deploy, and the ROI may be less because it requires a control plane, worker nodes, and multiple VMs to run. It's good for bigger organizations where many applications are run, but overkill for handling one or two small applications.

I've been using it for at least the last four or five years. I've been solutioning and setting it up on various cloud providers like AWS and Azure.

It is quite stable compared to three or four years ago. If you are using a supported version and not a very old version, then it is good.

It is scalable. We can add nodes and then more container images.

Some plugins for monitoring, patching, and operating are automatically available, so those are easy. Some may not be, like in the case of an older environment that may not have supported plugins, so those have to be developed.

The customer service and support are satisfactory. Setting up is more effort-based. Later on, it is okay. Lab features and admissions are required.

Positive

It requires initial effort. Later on, managing is okay, but initially, it requires skilled people to deploy it properly due to networking between nodes and worker and control planes.

The deployment time varies depending on the deployment. A simple POC for one VM can be deployed in an hour. For a dev-test environment, it may be around two hours. For production with many nodes, it may be four to five hours. It depends on the configuration, deployment type, and number of nodes.

Kubernetes improved the deployment and scaling processes. It requires underlying infrastructure nodes, which are a control plane (sometimes called a master plane), and worker nodes to run images or workloads. Because the underlying servers or virtual machines can be autoscaled or provisioned through policy, there is no need to take care of the rest. Once the application is deployed as a container image, Kubernetes automatically scales. It's just a matter of adding servers as worker nodes on which multiple applications or microservices can run. There is no need to deploy again.

In a typical scenario, we used to create virtual machines, install operating systems like Windows or Linux, and then deploy the application. Kubernetes eases deployment time, and we can run multiple applications from containers on the same node. 

Even for each application, there may be different types of containers, like for front end or middleware connecting to a database. So there are a couple of such options.

For deployment, around one person is good enough for an average setup. For support, one to two people are required, at least one person for each shift.

I would rate the pricing a six out of ten, with ten being expensive. It's a bit costlier for smaller organizations.

It's good for bigger organizations, but for smaller organizations or a few workloads, it may be too heavy, not easy to deploy, and the ROI may be less because it requires a control plane, worker nodes, and multiple VMs to run. 

It's good for bigger organizations where many applications are run, but overkill for handling one or two small applications.

I would recommend using it. 

I would rate it an eight out of ten, with one being bad and ten being very good. 

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 for our data science machine learning platform to orchestrate UPCR Hub containers with UPCR Hub partners. We also use it to orchestrate data pipelines.

Kubernetes allows us to update without downtime and to easily deploy new software, which is very beneficial for our operations.

For us, having fast storage classes is very important. We focus on implementing these for different storage types. The use of file system storage is also crucial.

Although we face issues when migrating to new versions of Kubernetes, such as misunderstandings on using new features or integration with proxy services, these issues can be addressed with proper preparation.

I have been using Kubernetes for a few years, possibly three or four.

Recently, Kubernetes has been stable in our setup. Any issues we faced were during version migrations.

Scalability is not a concern for us since we operate on-premises with standard loads and not many users.

There is a lot of guidance available through guides and forums, and I have no problem finding relevant information.

Positive

Usually, the setup involves two people, primarily to maintain the best practices in case one person is unavailable.

It's hard to estimate ROI directly. It depends on the expertise of our team and the in-premises scenario we operate in.

Since we use Kubernetes on-premises, the costs are related to our expertise and the personnel we hire.

I'd rate the solution eight out of ten.

The following is a list of the cases when I prefer Kubernetes for application hosting:

1. Micro-services infrastructure + possible use of some service meshes, like Istio or Linkerd.
2. Cost efficiency; we are using Kubernetes in conjunction with AWS Spot Instances or Google Cloud preemptible VMs.
3. Standards-compliant infrastructures like HIPAA, PCI SOC, DSS, and ISOxxxx.
4. Highly-available or fault-tolerant infrastructures, due to some sort of self-recovery and self-healing.
5. Infrastructures with automatically scalable applications.

It's unified our technology stack across on-premises infrastructures and public clouds, including Amazon Web Services, Azure, and Google Cloud Platform. Kubernetes provides great integrations with other open-source tools, like Prometheus, Grafana, Elastic Stack, Fluentd, OAuth providers, and others.

Kubernetes distributions are also great because we adopt the platforms for different requirements. These include the AWS Elastic Kubernetes Service, Google Kubernetes Engine, Azure Kubernetes Engine, Rancher, etc.

It allows us to build custom-tailored infrastructures from small to big companies and satisfy various requirements, such as providing a proper level of RPO, RTO, scalability, cost-efficiency, and support high availability/fault tolerance.

The most valuable features of Kubernetes are:

1. Containers self-healing and self-recovery.
   
2. Unifications allow for internal Kubernetes components to be migrated between Kubernetes providers in an easier manner.
   
3. Kubernetes as a service from the major cloud providers including AWS, Google Cloud, Azure, Digital Ocean, IBM, etc. Kubernetes as a service helps in infrastructure migration from on-premises to cloud, or from cloud to cloud.
   
4. This product has a rich toolset from the community including CNI plug-ins, Helm packages, operators, dashboards, various integrations, etc.
   
5. Built-in scaling features, it's really great!

Some improvements that we would like to see are:

1. Have reacher built-in features and probably incorporate some features from the community toolset, like KEDA for pod scaling.
   
2. There are even more tools from the community for monitoring, log collectors, authorization, and authentication.
   
3. Have some sort of simplifications for wider adoption.
   
4. This product should have a more advanced built-in scheduler that uses real application metrics in the scheduling strategy.
   
5. Wider integration with cloud providers in terms of volumes and key management services.
   
6. Add support of traffic encryption option from container to container, and Ingress to the container.

We have been using Kubernetes as a self-hosted service, managed by external solutions, like Rancher, or a cloud-provider managed service (Azure AKS, Google GKE, Amazon EKS) for between three and four years.

This product is pretty stable, especially in the managed service option, but as with all platforms, it has some issues. As an example, during an update Kubernetes version on Amazon EKS from 1.17 to 1.18 Amazon duplicates workers count from 4 to 12 (should be from 4 to 8), upgrades takes more than 1 hour (should be about 10-20 minutes) and suddenly this leads to the short-time interruption of some applications during re-scheduling. In the end, we were forced to write our own rolling update scripts for updating the Kubernetes version on the nodes instances, which completes the upgrade in 10 minutes without application downtime. But again, this is an issue related to managed Kubernetes (in particular, Amazon EKS platform).

Great scalability, especially for the small and mid-size setup with fewer than 100 nodes.

We have used various platforms for managing Docker containers, such as Rancher, Azure App Service, and Portainer.

The first adoption was hard because the Kubernete's learning curve is pretty high.

The in-house team only.

It's open-source and free, so pricing should not be applied here.

Google Kubernetes Engine is free in the simplest setup, AWS Kubernetes Engine costs about $50 (depending on the region), in a three master setup, so it's almost the same as the cost of the EC2 instances and it's totally fine from my point of view.

We prefer Kubernetes due to the unification and the next level of the platform itself.

At our company, we use the solution internally and integrate it with other products. Kubernetes is helping our organization shift from bare metal servers to cloud infrastructure. 

At our company, we use the solution to create nodes and multiple databases for our organization's clients. Kubernetes also helps me run SQL servers and other similar applications. Using some internal tools at our company, we convert our Kubernetes virtual machine into a GUI-based system that works seamlessly. 

The solution also helps our company develop custom hosting solutions across different servers. The cost of developing custom solutions is also reduced by utilizing Kubernetes. 

Kubernetes helps seamlessly build cloud infrastructure for development and testing. The tool assists in the production of small-scale databases for SMEs. Kubernetes empowers the customization of products developed by our company and accelerates the development process. 

With Kubernetes, a complete product with major functionalities can be developed in a day or two, as might have been discussed by a company in the SOP. MVP or demo product development is also possible with Kubernetes. The development of applications with all required components by the client, including the infrastructure, backup, security, and operating system, becomes very fast with Kubernetes. 

The most valuable features of Kubernetes for me will be automated rollouts or rollbacks, storage orchestration and high-end availability. The storage tasks and load balancing of applications also become easier with Kubernetes.  

The virtual machines from Kubernetes should be GUI-based. The virtual machines can be used only as a command prompt or CLI with Kubernetes. It should allow integration with other interfaces developed using different open-source technologies. Kubernetes should provide centralized free training that is easily available. The product should be made more viable and user-friendly for innovative users. 

I have been using Kubernetes for two years. 

The solution is stable, but there are glitches occasionally. At our company, we are using Kubernetes for customization, so glitches are expected. 

The solution is scalable, but it's mostly based on bare metal servers, so a user cannot exceed a specified limit. Suppose I have a fifteen-core CPU; then, all the nodes will simultaneously use all the resources, which can lead to downtime in the server. When you try to work with proprietary or open-source systems like Kubernetes a common error occurs where the database backup is not utilized. 

The solution provider's customer support needs to be improved. I would rate the customer support as six out of ten. 

Neutral

The product's deployment is straightforward. Only experienced and trained engineers can carry out the deployment. The solution's deployment can be completed within a couple of hours, even if it includes scripting or creating a development/testing environment. But in some rare cases the deployment time can be longer if it involves extensive R&D. 

About three professionals are needed for the deployment of the solution: one architect, one developer, and another individual for maintenance. 

The solution can generate a good ROI and save 50% of the cost for a company. 

It's an affordable solution. I would rate the pricing a five out of ten. 

At our company, we have worked with KubeVirt as well. KubeVirt helps our company convert CLI to a GUI-based product. 

I would rate Kubernetes as seven out of ten. I would advise others to learn Python or YAML programming language before using Kubernetes. 

We use this solution to orchestrate all of our microservice containers, and our deployed services within the infrastructure of large companies and small scale startups.

This tool has made deploying, scaling and managing applications very straightforward for us, and fail-safes are easily integrated, which saves us a lot of time.

We find the smooth, instant fail-safes in this solution to be very useful, as this allows for easy revival of dying quads or failing applications.

The scaling feature, and the fact that it is automated, is one of our favorite features of this product. There is also good API support, to improve application integration and cluster monitoring, and a dashboard for log monitoring purposes.

We would like to see more validation tools added to this solution, this would provide pre-deployment analysis that developers could use before publishing their infrastructure.

We have also found that the documentation that is offered with this solution could be better.

We have been working with this solution for two years.

We have found this to be a very robust solution. The only time stability issues occur is when there is a problem with cloud connectivity.

The scalability of this solution is very good.

The technical support for this solution is very good. There is a support community set up, and a lot of available online instruction for how to deal with certain issues or to learn more about the available features.

The initial setup of this solution was complex, as there is no tool to help with the process.

We implemented the solution in-house.

This is an open-source solution, so there are no licensing costs associated with its use.

We would recommend that organizations utilize the sample repository available with this solution, to work on configuration tweaks before deploying the product. This will save future issues occurring from changes that do not suit the business needs.

We would rate this solution a nine out of ten.