Kubernetes Reviews

People are creating a company that is transforming technology and moving from legacy to container technology. So, they are to be able to develop their ability to go to the public cloud easily. They will reroute the application in containers and need to be able to manage it. One of the use cases is becoming cloud-native. They want to be cloud-dependent and cloud-dependent, so you need a new format and containers to move applications easily in any cloud. For this, you need technology to manage multi-cloud applications and balance them.

The tool's most valuable feature is the auto-scaling feature. However, Kubernetes is not used alone; it is part of a complete deployment pipeline integrated with DevOps. This pipeline includes automation and deployment capabilities. 

One area where Kubernetes could improve is troubleshooting. The current process for troubleshooting and installation can be challenging, especially with a large ecosystem. Better tools and artificial intelligence capabilities developed to assist with troubleshooting, configuration, and support would be helpful. This improvement would be particularly beneficial for large enterprise customers.

I have been using the product for five to six years. 

The tool's stability is complex. Some rules are unclear, and the control plane's management can be challenging. Sizing the system effectively requires expertise, as it's not always straightforward.

My impression of Kubernetes' scalability is positive. It supports both vertical and horizontal scaling. However, you need to monitor your infrastructure to understand how it performs.

For Kubernetes, we serve small, medium, and enterprise businesses. We have some very small customers, but they are less common. The majority of our clients are medium-sized businesses. Typically, these medium-sized customers use three clusters—one for testing, one for integration, and one for production. They usually have a minimum of three worker nodes per cluster, so around ten worker nodes in total. For large customers, their infrastructure includes more than 50 worker nodes.

I think Kubernetes is easy to deploy, but there are difficulties depending on the infrastructure where we deploy. For example, storage and security are implemented differently. Depending on the environment, it takes about two hours to deploy. For on-premises deployments, you used to need to set up the infrastructure first. Nowadays, with cloud-native solutions, Kubernetes can directly interact with services like AWS, Azure, and VMware.

Pricing isn't a major concern for us. Since we resell Kubernetes services and focus on providing support, integration, and education, we don't usually have pricing issues. Our customers are more concerned with getting the right support and services than the cost. So, the value we provide is more important than the actual pricing. Pricing might change in the future, but it’s not a big issue for us right now.

Kubernetes presents several challenges, particularly with internal culture and operational changes. One significant challenge is transitioning to a DevOps approach, which requires adapting how you monitor and manage applications. With the tool, applications can be updated frequently without downtime, necessitating a shift in operations and monitoring practices. This change is a big adjustment, especially for teams used to traditional methods.

I would recommend the tool. The solution is relatively simple to understand and deploy across various environments, including Azure, AWS, on-premises, and Google Cloud. Kubernetes also provides good support, even for smaller companies, making it a valuable option regardless of company size.

I rate the overall solution a seven 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. 

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. 

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.

Kubernetes is used t deploy all our applications. 

The deployment is one of the most valuable feature. The solution is also easy to use. 

The user-interface in regards to the other solution can be improved. 

I have been using Kubernetes since 2020. 

It is a highly scalable solution. There are twenty people using Kubernetes.

The initial setup and deployment is quite easy. We have one tech team and one Data Science team. 

If you are building an MVP or you are starting small, then Kubernetes might not be the best option because there are some charges associated with it.\  But if you are building an application that might scale rapidly, then you should definitely go with Kubernetes. 

If your deployments happen very frequently, then it is definitely the solution you should use, because you can restore previous versions if something fails.

I rate the overall solution a nine out of ten. 

We use the solution to manage the containers efficiently.

The solution has a well-defined interface for every other function like network, CRA container, and run-time interfaces. It is fantastic as open-source software, very generic, and easy to use.

The solution's learning courses for the new users and developers must be easier to understand. Presently, they are very abstract, and it is challenging for users to find data.

I have been using the solution for a year and a half.

It is a stable solution.

The solution is easily scalable. I rate it ten out of ten. Our technical team for the solution consists of ten executives. At the same time, there are two million end users.

I took help from the solution's technical team for Stack Overflow. Their service was good, and I rate it ten out of ten.

Positive

We switched to Kubernetes for better scalability, maintenance, and administration.

The solution's initial setup was straightforward. I've used Rancher Kubernetes engine to set the cluster. The deployment took two days to complete. The process involved downloading the binary file and configuring it to servers.

We deployed the solution with the help of our in-house team. The team of three, including data engineers and data operations managers, execute maintenance for it.

I have seen a return on investment for the solution. 

We use the solution's open-source version.

It is easy to maintain distributed systems and applications using the solution. Although, it requires a few new features to improve managing the volumes. I rate it ten out of ten.

The primary use case of the solution is container orchestration for a microservices-based architecture.

I worked on deployment in the cloud and on-premises.

The solution has improved our organization by providing a computing layer abstraction between the cloud provider and on-premise. This has given us higher consistency in management and deployment strategies. The solution also reduces the effect of discrepancies between development and production environments.

The most valuable feature of the platform is the auto-healing and auto-scaling ability to offload to the platform tasks that were previously managed by humans.

There is a large ecosystem of products surrounding Kubernetes, making it difficult to identify the right solution due to the vast number of options.

I have been using the solution for six years.

The solution is a stable mature platform.

Scaling is a straightforward and standard process. With the integration provided by the cloud provider, we can even enable automatic scalability.

Setting up without Kubernetes provider services is complex.

I give the solution a nine out of ten.

There is a large amount of overhead associated with maintenance, as we have to maintain everything from the operating system to the application. The cycle of updates and patches for the platform itself is very frequent, with a new version released every four months and various security patches in between. This makes the maintenance task very large if we have to do it ourselves.

The main benefit of Kubernetes is that it is currently the standard for container orchestration. Kubernetes is available across different cloud providers, providing consistency in management and portability that is not available with other products.

In the beginning, the solution may feel as if it has a lot of moving parts that are confusing and overwhelming.