Kubernetes Reviews

For Kubernetes, I'm mainly developing blueprints for both dedicated AKS and Azure AKS. Those are the main use cases. 

Currently, our dedicated AKS Blueprint is the one used in production and is fairly stable. We work on a shared AKS site use case, primarily for cost reduction and maximizing cloud investment.

I'm a vendor and provider for my client. That's my main role under this group. We provide an end-to-end lifecycle, not just spinning things up but also providing other sub-components to complete the building of an AKS product. We can customize it based on client requirements.

One of the most significant improvements we've seen is in the area of dedicated AKS clusters. It's become much more team-efficient because of the use of blueprints. With blueprints, you have everything you need, from IAC infrastructure support to spinning up your AKS deployment to the deployment of Kubernetes operators like search-manager for TLS lifecycle management and other integration operators for products that require them. And it goes beyond that with application deployment as well. 

It's a plug-in type approach, so if I want to integrate a monitoring tool like a data-managed log, I can just set it through and rerun the blueprint. It automatically populates all the necessary parameters and variables before running it. 

Lastly, there are the operational playbooks for things like upgrading your cluster, restarting it, scaling, and patching software. So, basically, think of it as a single unit deployment that contains all the roles you need to perform your AKS lifecycle end-to-end.

Some of the DLP features from Microsoft, like service mesh, are still open topics for us. Currently, we support the open-source Istio version, not the Microsoft Istio plugin. So we have to balance whether these features from Microsoft will help you in the long term or if you'll look for open-source alternatives certified by the CNCF. For example, building a storage and cloud-native foundation isn't something we can incorporate into our solution. We're not relying solely on what's available from Microsoft. 

Other items, like KEDA, aren't really applicable to the client infrastructure or requirements, so we're looking for alternatives. But for things like workload identity, which is AKS integrated with other directories, that can be leveraged. And NSG (Network Security Groups), can be used as a policy with your Azure Kubernetes. So there are many things, but we're selective in choosing the right features for AKS based on client requirements.

For us, it's the shared AKS. It's really complex because each workstream has its own set of requirements that need to be satisfied within the shared AKS blueprint. 

But we need a starting point, so we began with basic Azure Active Directory role assignments and creating Kubernetes-native RBAC roles, like cluster-wide or namespace isolation. The fundamentals need to be there for workstreams to easily understand and adapt when they transition to the shared AKS.

The most challenging aspect is cost tracking. How do you keep track of the cost per tenant within the AKS cluster, how much they consume in terms of resources? It's still a work in progress.

For dedicated AKS, the difference is that if a workstream has a budget or compliance requirements, they can spin up a dedicated AKS for their applications only. We have a stable solution for that, but the hosting cost for a dedicated AKS, especially if running only a few applications, might not be as cost-effective as a shared AKS, where multiple workstreams can work on a single cluster.

I have experience with Kubernetes, AKS, to be exact. I just started last year in October. The latest one is 1.27. The version itself doesn't matter too much as long as it's supported by a vendor like Microsoft. We use the latest stable version for AKS.

I would rate the stability a ten out of ten. As long as your cluster is properly provisioned, you won't have any problems.

It's so simple to scale. But the main thing is to choose the right virtual machine size. We really pin that down. For example, I start with three nodes for my worker nodes. In the future, if I need another set of nodes, I can decide whether to use spot virtual machine nodes or stay with the typical or recommended virtual machines for workers. 

In the financial service sector, I'd rate scalability an eight out of ten. But do it in a controlled manner, not auto-scaling. If your application has a bug and you enable the autoscaler, it will spike your costs. If someone deploys an application with a bug, that's automatically a problem. So, in our case, we do manual scaling of nodes based on capacity, requirements, and workload protection.

We are early adopters of this product. So, the number of users depends on the application running on AKS. Many users are using it in our banking application environment. The goal is to have it on an organizational level. Whoever adapts containerization for their application will have the choice to host it in an AKS cluster or in a simple Azure container resource. For my current client, we use it every day, 24/7.

Microsoft itself is very supportive when it comes to questions or technical issues within their cloud system. They are our number one, main vendor support. For any AKS factor problem that isn't quickly addressed in their documentation, we always go directly to Microsoft.

We are at level four escalation. For example, Let's say you're provisioning an AKS and encounter an issue with the provisioning of your private DNS node, and it appears that you've already met the one network limit per subnet. That would be a P1 priority one ticket, and Microsoft should fix it as soon as possible.

Positive

Outside my current project, I used OpenShift for a different company.

My current company already used AKS, and they aren't looking for other Kubernetes solutions at this time.

With the use of our blueprint, my experience with the initial setup has been a ten out of ten where one is difficult and ten is easy. 

We just need to run the playbook, and everything spins up automatically using ARM templates. In the ARM template, we define the target specs for the AKS cluster, such as the target version and node count. Then we run the playbook, and it spins everything up for us.

This solution is hosted on the cloud but when it comes to application modernization or lift-and-shift strategies, sometimes the AKS hosted in the cloud still needs to communicate with the on-premises side, application to application.

Everything is in-house development. It was really challenging at the start because we had to integrate other stuff. Spinning up AKS isn't as simple as it sounds, especially in the financial services industry, where security is a top priority. We work on a zero-trust model, so every execution within the Azure cloud ecosystem requires authentication, authorization, and access control. That's where the challenge comes in. 

But since we have our blueprints and roles that handle these integrations and requirements, it's become much easier for us to spin up AKS. We don't use the Azure portal UI much anymore. Everything is done through ARM templates and can also be run through a DevOps process.

Completing the blueprints took six years. But when I joined the project, I just contributed to some part of it. So, basically, six months in my contribution.

Deployment can be done in fifteen minutes in a zero-trust architecture. But to develop the blueprint solution itself, you need one year. One person can deploy it, actually, from the consumer perspective. And only one person can execute or provision the whole thing. It could be a DevOps persona, a system engineer, or an application guy. It depends. However, one of the criteria or skills that is required is having some knowledge of Kubernetes.

Maintenance itself should be handled by the private team who used the blueprint. For example, I have a team of five people: three developers, one tester, and one business analyst. Any of them—maybe a tester or one of the developers—can manage the entire dedicated AKS loop. If they go with shared AKS, there should be some managed hosting for operational models. That takes care of the requests of each project team. So it depends.

For the dedicated AKS, whoever owns it should be the one to take care of everything once they use the blueprint. Management, maintenance, release process, and so on.

One of the key benefits is modernizing your application deployment, leading to faster time to market. It's really fast-paced if it's done properly. If you have a solid AKS and a solid DevOps process, you'll automatically get an ROI, not just in terms of cost but also in how quickly you can see your business application progress. 

You can see how quickly you can roll back and apply hotfixes for production issues compared to on-premises, where you'd need a series of approvals. 

With the cloud, all you need is an approved RFC, for example, a change ticket, and then you can execute the self-service button that will roll out your new application version seamlessly. We're using a single-image unit that takes care of everything.

I'd say we're still at a seven out of ten, where one is no return on investment, and ten is a hundred percent return on investment because the transformation or adoption is still in progress when it comes to our journey to the cloud.

It's expensive if it's not correctly configured. Moreover, AKS is just one resource. We have to think about other resources, like Azure key vault, PostgreSQL, or BizTalk, for example. We have to integrate those. But for the AKS itself, it's relatively cheap as long as it's properly configured. I'd rate the pricing a five out of ten.

There are additional costs for some things in Kubernetes. For example, if you want to integrate your AKS with Azure monitoring, like analytics, that will spike your costs. It's not just the AKS itself. We have to be careful when selecting solutions. That's why, in our organization, we look for alternatives like Splunk or AppDynamics. But if you're going to use only the AKS, it's cheaper if you configure it correctly.

There's no one-size-fits-all solution. It depends on a few factors. First, I'd consider the skill set of your existing workforce. Transitioning to a new technology is a journey, so make sure you have people who are familiar with the cloud provider you choose. I have some bias toward Microsoft, not because I prefer it, but because integrating different on-premises devices, resources, and systems is already available within Azure due to Azure Active Directory or Entra ID.  

Aside from that integration, I've experienced zero trust, and it works well with other components, like HashiCorp's Vault and Azure service principals. In general, when you work with the cloud, you should have a trust-based model. It's easy to spin up resources, but without a trust model—like understanding which client ID is working on a resource with a specific object ID—it's hard to track incidents end-to-end. I haven't experienced that with other cloud providers, and it's even challenging to implement on-premises. With Microsoft, you can integrate and implement zero-trust architecture (ZTA).

As for AKS itself, you have deployment options. You can isolate an AKS that's internet-exposed, build one accessible only within the corporate network, or create one accessible only from on-premises. There are different requirements for how to track security issues for your cloud resources, regardless of the provider. That's one of the main considerations nowadays.

Kubernetes is not for everyone, especially if people aren't skilled enough to work on it. Kubernetes itself is just a plain blanket, and you still need to add more components to make it more useful. 

So, I'd say it's an out of ten, but it depends on maturity. If you have good, technically skilled people, then I'd say you can rate it as a ten, especially if you have a lot of self-service processes in your overall landscape. It's about reducing manual work, basically.

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'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.

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.

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.

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 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.