Kubernetes Reviews

The solution use case is project-oriented in our organization. Some of our company's clients demand the use of Kubernetes on container technology, while other clients don't. The last time, as part of the company team, I used Kubernetes to create an infrastructure blueprint. My responsibility in our company is to monitor all Kubernetes projects, from DevOps to security operations. 

In our organization, Kubernetes is primarily used to test data environments and develop databases accordingly. The solution is also used in the data migration process. Previously, our company was working on migrating from JSON platforms to the latest Azure cloud platforms using Kubernetes structures. 

The feedback process offered by the solution is crucial. 

I expect the implementation of additional tools in future versions of Kubernetes. Every time our company has a setup that uses Kubernetes, a local API creation is required for communication. Presently, our organization is using Slack for API creation, I would prefer a built-in feature from Kubernetes that allows the same operation. 

The presence of a monitoring board in Kubernetes can deter users from utilizing third-party tools like Dynatrace. 

I have been working with Kubernetes for three years. 

I would rate the stability a nine out of ten. The solution has shown great stability to the teams of our company.  

The downside scaling and rendering with Kubernetes in our company is handled by a third-party client; we only raise tickets with them. I would rate the scalability of Kubernetes as seven out of ten. I am satisfied with the scalability of the product offered to our organization. There are around 1500 to 2000  Kubernetes users in our company.

Our organization's entire IT blueprint team uses the solution extensively for the nonproduction environment. The usage of Kubernetes may increase in our organization depending upon requirements, as we have no plans to scale down the use, and the upscaling license is already available to us. 

Our organization has a monthly meeting with the vendor to discuss issues and their respective solutions. Due to the aforementioned meeting, reaching out to customer support is usually not required. 

Before using Kubernetes in our organization, we were using JSON Container Systems and mostly IBM containers. For migration to cloud and be at par with the global market, our company shifted to Kubernetes. 

I would rate the initial setup process an eight out of ten. The product is quite reasonable and easy to implement. At our company, we work with the cloud version of Kubernetes and the deployment took us around a year. The local cluster deployment of the solution took us around five months. Our company's solution portfolio was up and running within six quarters. 

I am working with the orchestration team on the solution deployment, and we orchestrate microprocessing and all the VM processing in the cloud structure. First, the basic IT team manages the setup process, and then it's handed over to the orchestration team. A vendor team of six to seven professionals was needed to deploy the solution initially. 

Two DevOps professionals from our organization's internal team are needed to maintain Kubernetes. 

At our company, the solution was implemented through a vendor team in DCX and TCS. 

Other companies in our industry are interested in moving towards agile systems, but our company is not highly interested in it. Our organization is more focused on shifting toward AI and robotics technology for creating tools that function in multiple environments. At our company, we have already created a blueprint that supports the same tools and cloud systems for security and development operations, which saves a huge cost. 

I would advise others to create an agile system in the firm. Companies should shift towards cloud technology, AI learning, and similar advanced technologies. The ROI for Kubernetes in our organization was around 36 to 40%. 

I would rate the pricing a seven out of ten. The total expenditure for Kubernetes involves an initial license fee and the scalability cost. 

At our company, we also used JSONs and ran an SQL or Oracle-based database. All the VMs in our organization were using old versions so we moved towards the cloud technology, we eventually shifted to both AWS and Azure to use along with Kubernetes. The architects of our company have made the decision to shift to the cloud. 

Kubernetes offers the option to manage multiple VMs thus helping users leverage the high scalability of the system module. In our company, we lacked horizontal and vertical scalability before using Kubernetes, when a general container technology was being used and less number of environments were covered. 

Kubernetes has helped our organization work in a nonproduction environment in addition to a live environment that was already being used. If testing servers are needed, Kubernetes makes it possible to scale in real-time. 

Our company has a few Splunk professionals who are also looking into the recovery aspects of Kubernetes. I receive a weekly report about the recovery using Kubernetes, but the dedicated team is aware of and manages the recovery details.  Kubernetes is doing well with failover and recovery in our company's environments, as the system hasn't gone down in a long while. 

I would overall rate Kubernetes a seven out of ten. I would recommend others to check latest reviews to gather information about the solution before adopting it, including competitor products and their architecture. 

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.

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

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.

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.