Kubernetes Reviews

We are platinum partners with Oracle and we are preferred partners with Microsoft. I work for an organization which is on both sides of the coin. We are a service integrator organization. We don't have a specific loyalty, we blend in and provide the services. I'm a solutions architect.

I like the interface of this solution. When you're using it in real time, it seems to be a little easier to use versus the other options. 

If you're using the solution on the desktop, you eventually have to download the Azure package and install it before you can actually use the Azure commands in Kubernetes. There are more community packages that have been released, rather than releases by Kubernetes. I understand that it's an open server and people can contribute to it, that's how it works. However, sometimes people get misguided and that's where we need some support. It would make a difference. 

I've been using this solution for almost three months. 

It's a pretty stable solution. We have about 40 plus people who use it.

I would turn to community support as a first step. The blogs, which cover it, have given me a little bit more insight in terms of how and what and all of that. But when it comes to community, I've not asked much, but I've learned from it. I've watched some videos and see there is some online free training. I haven't been in a situation where I needed external support from Kubernetes.

We used to use Dockers. We explored Kubernetes because we want to do market platform, which is basically a show or an article together and we wanted to use a single platform for both Oracle and Azure. Not that Dockers didn't do it, but we did kind of wonder what would be the better option. 

The initial setup was relatively easy. I mean I've obviously used some of the apps before, but this seemed to be a little easier for me. I think when I used it in the Azure implementation earlier this year, it didn't give me too much heartburn although it takes a little bit more than you expect. I can just start the QP CDL and push out the command and start it. If I'm using it with Dynatrace, it's the same thing, but when it came to deploying the package into the local machine and then running it, and then trying to get the right connection within Azure it was more difficult. 

I would recommend going through the training to see what the limitations are within Kubernetes. There's not a lot of training, but what training is available should be used so people can understand the difference between Docker and Kubernetes. If somebody has used Docker previously, they can see the difference even though the methods are the same. It's the same madness, but it will help you to better position things like command line interfaces.

We had a bit of a struggle when I was trying to implement it in Azure. But if you look at the Oracle implementation, it worked really well so I would rate this solution a seven out of 10. 

My primary use case of this solution is for infrastructure implementations - we allocate an EC2 instance and then define how many worker nodes are needed to run the application and the managed nodes.

More automation could improve the product - specifically, it would be useful to be able to shut down any IT machines that are currently not in use.

I have been using Kubernetes for around a year and a half.

I think this solution is stable.

I think Kubernetes is scalable in a vertical manner, depending on the type of instances in the worker mode. If you don't have resources, you can certainly add another worker node and expand the cluster.

With the latest edition of Kubernetes, there is a concern in terms of infrastructure regarding AWS support. There is no specific contact point for issues with Kubernetes, so we have to rely on the internet and blogs in order to work out what has gone wrong. 

The setup was not straightforward. There were certain challenges in setting up the product requiring a lot of time on proper configuration and compiling. The first time we deployed took a lot of time but now we can do it in around a week.

You don't need a license for Kubernetes, but you do have to pay for usage.

I would rate Kubernetes as ten out of ten.

We primarily use the solution for deploying containers and scheduling the jobs to the Kubernetes for our server-side deployment.

Before we switched to Kubernetes, we had been using a solution that required a manual interaction with the server. Every time you need to scale it up and down, it was a lot of hassle. With this solution, we were able to add continuous integration with Kubernetes. We can trigger the automatic deployment and it will just be deployed and nobody needs to go and do anything. In terms of scaling, we can define the scalability rules, which will grow as the traffic grows, as opposed to past instances where you needed to change the instances of the CPO, etc.

Since we are saving so much time, we're also saving our company money. We're saving a few hours of work a week at this point.

The ease of use in the solution is a very valuable aspect for us.

The scalability of the product is excellent. Scalability is particularly important to us due to the fact that we have available traffic that requires our service to scale up and down according to the load on the service.

It would be very interesting if they could introduce a template engine to set dynamic values in the deployment time. It would be ideal if it could be native in Kubernetes as it would be much easier.

I've been using the solution for three to four years.

In this particular deployment, we've had the solution running for a little bit less than a year, and we have had zero stability issues. It's extremely stable. There are no bugs and glitches. It works without fail and is very reliable.

We had one instance once where it disappeared once for an instant, and nobody even noticed anything was wrong. That said, I do not think that was a fault of Kubernetes. It was more about an AWS issue.

From the perspective of managing Kubernetes and deploying and updating, we have two developers (one team leader and a DevOps). We taught four people to actively use and manage it. Then, almost everyone is using some service that is running on Kubernetes (about 15 or so people), therefore, it's widely used at our organization.  

We do have plans to increase usage in the future. We're planning to scale as we go where we will add more services and more deployments into Kubernetes.

We don't directly reach out to technical support. Rather, we tend to use their available documentation for troubleshooting.

We are using it on AWS, and it was fairly easy to deploy. As far as I know on other platforms, it is also quite easy as they have a faster-managed service. However, if I deploy it manually myself and manage the nodes by myself, it's pretty complex. Therefore, it can get pretty complex. Using the AWS managed solution removes the complexity for us.

The deployment took us about two days with testing, et cetera.

At the first stage, we had to wrap everything on our server-side, with the applications in the Docker containers. Then we deployed the ETS to the cloud and then we deployed the containers into the ETS. After that, we switched the browser to point to the newly deployed containers and load balance cells instead of the old machines. After that, we switched off the old machine.

We handled the deployment ourselves. We didn't need the assistance of any consultants or integrators.

Technically, we pay either way. We had the machine that we paid and we switched it off. We didn't really save on money investment so much as stability investment. We invested in this environment in order to attain a more stable and predictable application. That was our ROI.

The solution can be more expensive for smaller companies. If you run it on a smaller scale it's pricey. However, if you scale up or use it on a larger scale, it's pretty competitive in the pricing.

For example, on Amazon, the billing is mostly for the machines that you're using. If you have a lot of containers, hundreds of containers, running on the ECS, it can even be more expensive than if you were running the same containers on some deployment as you're paying for the nodes that are running the machines. If you can use fewer containers in the same machine it can be cheaper. It really depends on deployment. 

If you decide to take the managed service, be aware that it's $100-$200 extra monthly. It's not much, and it's worth the cost.

We did evaluate Amazon's Elastic Container cluster before ultimately choosing this product.

Kubernetes is multi-platform. You can run it on any cloud and you can also run it on your local machine. The implementation is also much more straightforward with Kubernetes and deployment is easier. Even though the product is from Amazon themselves, Kubernetes is easier to maintain and deploy.

I would advise new users to take the managed solution. Don't deploy it by yourself. Just take a managed service. It's really worth it. I advise this due to the fact that it's a lot of time and effort. It's not that expensive in terms of overhead. It may be $100 or $200 or something like that monthly. When you pay $3,000, let's say, the $100 doesn't really matter. However, the work that your DevOps will have will be costly. They will initially invest to maintain your unmanaged deployment. 

On a scale from one to ten, I would rate this solution a ten.

Kubernetes is a container management platform, and all our microservices are deployed on this platform.

There are features that come out of the box with Kubernetes, with respect to scaling, reliability, etc. It's the leading container management platform. There are other competing ones, but this is the leading one.

It has multiple instances of the application running. If one of them goes down, the other one automatically spins up.

It would be nice if they could make it easier for developers and infrastructure staff to automate some of the pieces that they have to do manually at the moment.

This is a solution I've been using for four or five years.

It's stable. It's managed by the cloud provider.

Depending on the SLAs with respect to scalability, we can scale up and down as per our demand. We could increase the number of nodes instantaneously for our requirements. In our company, we have 5,000 people around the world using Kubernetes.

As for initial setup, If it is on an on-premises environment then it's a little bit tricky, but if it's on public cloud, then they have an offering where you can spin up clusters within minutes. Those are managed by the cloud providers. On cloud platforms, the initial setup is easy, but if you want to spin up your own cluster and manage that, then it could be a lot of work. Spinning up might be easy, but maintaining that cluster could be a lot of work.

Look at your use cases to make sure that Kubernetes is required. It is generally required when there are concerns with scalability or when there is a need for a solution that is highly available and highly scalable. If this is the case, then it makes sense to use Kubernetes.

It could be used as a global tool as well. Some of the nodes would be on-premises and on the cloud or multi-cloud.

However, if you have a simple application which is used by your own company and some internal applications, and is not used by many people, and scalability is not the concern, then you shouldn't go for Kubernetes.

I would rate this solution at eight on a scale from one to ten.

We use Kubernetes as a container management solution. We use the Kubernetes solution for security analysis on Verizon's client systems.

Kubernetes container services can be used for deploying applications and they can be deployed on the path layer. You deploy Kubernetes, and inside it, you deploy VMs and application containers. If you take Cloud Foundry inside the data cells, you deploy the application and data. This is how the solution operates.

The solution is easy to use.

I have been using Kubernetes for approximately two years.

The solution is stable.

Kubernetes is scalable.

The support could be faster at resolving issues.

We have approximately 12 workers that do the implementation.

The solution requires a license to use it.

I would recommend this Kubernetes to others, it is a good technology.

I rate Kubernetes an eight out of ten.

We deploy microservices. We provide the screen namespaces. 

Kubernetes' integration with AWS Lambda is great. I barely had to write any code to connect from EKS to Lambda, so Kubernetes is programmer friendly.

Kubernetes could adopt UI-based approach. A UI-based approach would be really useful in the CI/CD pipeline. They should make everything a little bit more user-friendly.  For example, when I'm deploying, it would be nice to load my code and be able to see which components need to be connected. 

I've been using Kubernetes for more than two years. 

Kubernetes support is fine. That is not a problem.

Deploying Kubernetes is straightforward. Some are using GitLab. However, it does take a little bit of time, and it could be faster. 

Licenses for Kubernetes are on a yearly basis.

I rate Kubernetes nine out of 10. I would recommend it.

Kubernetes is a container management platform. 

I use it to be able to sell it to my customers. I am evaluating it and its general features.

I would like to have more knowledge and a good understanding of Kubernetes, what it can do, and what the use cases are to meet the customer's requirements or environment. 

By using it, I can properly advise the clients of what Kubernetes can, and can't do.

Scalability is the most valuable feature.

With Kubernetes, you also get High Availability.

Kubernetes can be used for most companies, but for some companies that may be too small, it may not be worth the investment, as it is expensive.

I have been working with Kubernetes for two years.

We are using the latest version.

Kubernetes is a stable product.

Kubernetes is a scalable product.

We have multiple sales teams, some are responsible for large enterprises businesses, some for medium-sized companies.

The documentation they have available is good.

I have not contacted technical support. 

Much like other products such as Red Hat, for example, have their own support.

I work with any product that is related to Kubernetes.

The initial setup was straightforward. 

It's simple, and it is easy to deploy.

We provide implementation services for our clients as well as maintenance.

In addition to Kubernetes, you have to pay for support.

The price could be cheaper.

They offer many different licensing models. There are many options to choose from.

I would recommend this solution to others. 

It is my job to do this and I feel that it is the future of every company.

We are integrators, and we are working on becoming partners, to obtain the certificate.

I would rate Kubernetes a nine out of ten.

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.