Kubernetes Reviews

My main use case for Kubernetes is deploying and managing scalable backend services and web applications in a production-like environment. For example, in one of my projects, a real-time chat application, I containerized the Node.js backend and frontend using Docker and deployed them on Kubernetes using Deployments. I used ReplicaSets to run multiple pod replicas for high availability and exposed the backend using a service for load balancing. Environment variables and configurations were managed using ConfigMaps and secrets. When traffic increased, I scaled the pods manually and also tested autoscaling using HPA based on CPU usage. For updates, I used rolling deployments so that the applications had zero downtime during releases. Kubernetes helped me simplify deployments, improve reliability, and handle scaling without manual intervention.

In my chat application project, the biggest pain point before using Kubernetes was manual deployment reliability. If the server crashed or traffic suddenly increased, the application would go down or become very slow, and scaling had to be done manually. After moving the chat application to Kubernetes, reliability improved significantly. Kubernetes automatically restarted failed pods, maintained the desired number of replicas, and load-balanced traffic across pods using services. This removed single point of failure issues. Another big improvement was deployment safety. Earlier, updates caused downtime because we had to stop and restart the server repeatedly. With Kubernetes rolling deployments and readiness probes, we were able to deploy new versions without downtime and safely roll back if something went wrong. Overall, Kubernetes reduces operational effort, improves uptime, and makes the system much more stable and predictable in production.

The best features Kubernetes provides, in my opinion, are self-healing, automated scaling, rolling deployments, and service discovery with load balancing. The feature that stands out most for me is self-healing. If a pod crashes or a node fails, Kubernetes automatically recreates the pod and maintains the desired state. This greatly improves my application's reliability and reduces the need for manual interventions. Another valuable feature is horizontal scaling, which allows us to easily scale applications up or down based on traffic, either manually or automatically using HPA. This helps handle peak load effectively and optimizes resource usage. Rolling updates and support are also extremely useful because they allow zero-downtime deployments and quick recovery if a release has issues. Finally, service discovery and built-in load balancing make it simple to expose applications and distribute traffic without needing external configuration.

On a broader level, Kubernetes has had a very positive impact on how we deploy and operate applications, especially in terms of reliability, deployment speed, and operational efficiency. Downtime has reduced significantly because of self-healing, multiple replicas, and rollback deployments. Even a small crisis used to cause service interruption, but with Kubernetes, the system now stays available automatically. The release cycle has become faster and safer, often completed in under ten to fifteen minutes with automated pipelines and rolling updates. Operational efforts have decreased significantly as well because there is less manual restarting of services, scaling servers, or handling configuration issues.

From a cost perspective, better resource utilization and scaling prevent over-provisioning, allowing us to scale only when necessary instead of having large servers running at all times. Overall, Kubernetes has improved system stability, speed of delivery, and the efficient use of infrastructure.

For improvements, I would definitely suggest some enhancements to Kubernetes. While Kubernetes is very powerful, there are still a few areas where it could be improved. Our challenge is the learning curve and operational complexity. For new team members, concepts such as networking, RBAC, Ingress, and troubleshooting distributed systems can take time to understand. Better built-in onboarding tools or simplified abstractions would help. Another pain point is debugging and observability. While kubectl provides good basic visibility, deep debugging across multiple services, pods, and nodes often requires external tooling such as Prometheus, Grafana, or centralized logging. Stronger native observability features would be very helpful. Networking and Ingress configuration can also be complex, especially when dealing with certificates, routing rules, and cloud-specific integrations. A more standardized experience across environments could reduce operational overhead. From a cost perspective, managing and optimizing resource usage at scale still requires careful monitoring and tuning. Better built-in cost visibility would be very helpful.

For the needed improvements, I think that covers most of my main concerns. The biggest areas for improvement are still around simplifying operations, better native observability, and easier cost visibility. If I had to add one more point, it would be around standardization and developer experience. Sometimes different clusters, cloud providers, or tooling setups behave slightly differently, which increases maintenance efforts. More consistent defaults and opinionated best practices could help teams adopt Kubernetes faster and with fewer surprises. Overall, despite these challenges, Kubernetes is a very mature and reliable platform, and the benefits clearly outweigh the limitations for most production use cases.

An additional area that could be improved is upgrade and version management. While managed services help coordinate Kubernetes version upgrades, API deprecations and compatibility with add-ons can still be time-consuming and risky for production environments. Better tooling and clearer migration automation would make upgrades safer and easier. Another improvement could be around documentation, consistency, and discoverability. Kubernetes documentation is very comprehensive, but for beginners, it can sometimes be overwhelming to navigate and identify best practice paths.

I have been using Kubernetes for the last one year.

Kubernetes is very stable in my experience. We have had very few cluster-level issues, with most incidents related to application configuration rather than Kubernetes itself. The platform handles node failure, pod starts, and rescheduling very well, keeping services running consistently. Upgrades and maintenance have also been very smooth with managed services, and downtime has been minimal. As long as best practices are followed, such as proper resource limits, health checks, and monitoring, Kubernetes provides a stable foundation for production workloads.

Self-healing has been very helpful in maintaining system stability. In one case, during a load test on our chat application, one of the backend pods crashed because of high memory usage and an unhandled exception. Normally, this would have caused partial downtime or required manual intervention to restart the service. But with Kubernetes, the liveness probe detected that the container was unhealthy, and the pod was automatically restarted within a few seconds. Since we had multiple replicas running behind the services, users did not notice any disruption, preventing a potential outage and saving a lot of troubleshooting time. Another time, when a node was restarted for maintenance, Kubernetes rescheduled the pods to other available nodes automatically, keeping the application available. Apart from self-healing, I really value declarative configuration because it allows us to version control infrastructure changes and easily reproduce environments. I also find ConfigMaps and secrets management very useful for separating configuration from application code and improving security and maintainability.

For Kubernetes scalability, during higher traffic periods or load testing, I scale backend services from a few replicas to multiple replicas within minutes using horizontal pod autoscaler based on CPU usage. Traffic is automatically distributed across pods using services without any manual intervention. When traffic reduces, the system scales down automatically, helping to optimize resource usage and cost. From a cluster perspective, adding or removing nodes is also very smooth in managed cloud infrastructures. Overall, Kubernetes gives a lot of flexibility to handle growth and spikes without re-architecting the system.

The customer support for services such as AWS and GKE has been very reliable, especially for infrastructure-related issues, such as cluster availability, networking, or service limits. Support tickets are usually handled within the expected SLAs, depending on the support plan. In addition to official support, Kubernetes community ecosystem is very strong. Documentation, GitHub issues, forums, and community blogs are extremely helpful for troubleshooting and best practices. Many common problems have well-documented solutions.

Before moving to Kubernetes, we mainly ran our application on virtual machines using Docker Compose and process managers such as PM2. While this setup worked for small-scale deployments, it had several limitations. Scaling was mostly manual, failover was not automatic, and deployments often caused downtime. If a server or process crashed, recovery required manual interventions. Load balancing and rolling updates also required extra custom setups. As traffic and the number of services grew, managing multiple environments and ensuring reliability became more complex and error-prone. We switched to Kubernetes to get built-in orchestration, auto-healing, scaling, service discovery, and zero-downtime deployments. Kubernetes gave us a standardized and automated way to manage workloads, significantly improving system stability and operational efficiency.

For day-to-day tasks, I mainly use Kubernetes for deployment management, monitoring, scaling, and troubleshooting. I regularly use kubectl to check pod health, logs, and resource usage and to verify that deployments and services are running correctly. I also manage configuration updates using ConfigMaps and secrets without rebuilding images. For releasing, I handle rolling updates and occasionally rollbacks if any issues arise. I monitor application behavior using basic metrics and logs to ensure performance and stability. I also focus on optimizing resource usage by tuning replica counts and request limits while ensuring clusters remain stable and cost-effective. Overall, Kubernetes has become a core part of how I operate and maintain applications in our production-like environment.

We have seen a positive return on investment from using Kubernetes, mainly in terms of time saving, operational efficiency, and improved reliability rather than direct headcount reduction. From a time perspective, the deployment release process has become much faster and more automated. What earlier required manual coordination and took thirty to forty minutes per release is now usually completed within ten to fifteen minutes. This improves developers' productivity and reduces deployment-related errors. Operationally, the team spends much less time on manual restarts, scaling, and incident recovery because Kubernetes handles self-healing and replica management automatically. This significantly reduces on-call workload and incident response efforts. On the infrastructure side, better resource utilization and auto-scaling help avoid over-provisioning. We observed roughly twenty to thirty percent improvements in resource efficiency, which translates into more controlled cloud spending as the system scales.

My experience with pricing and setup costs shows that Kubernetes itself is open source and free, so there is no licensing cost for the software. The main cost comes from the infrastructure and managed Kubernetes services provided by the cloud vendor. In our case, using AWS EKS, we pay for the control plane and underlying compute resources such as EC2 nodes, storage, and networking. Compared to managing our clusters, managed services reduce operational overhead and maintenance effort. The initial setup cost was mainly engineering time for cluster configuration, networking, security, CI/CD integration, and monitoring. There were no major upfront licensing costs. From a pricing perspective, costs are predictable based on node usage, storage, and traffic. Autoscaling helps control costs by scaling down during low usage periods. Overall, from a licensing standpoint, Kubernetes is cost-effective, and the main investment is in infrastructure and operational setup rather than software fees.

Before choosing Kubernetes, we evaluated other options. We looked at Docker Swarm, which was simpler to set up but lacked the advanced ecosystem, flexibility, and long-term community support compared to Kubernetes. We also evaluated AWS ECS, which integrates well with AWS and is easier to operate, but it is more vendor-locked and offers less portability and standardization across environments. Additionally, we briefly considered a PaaS-style approach, but it did not provide enough control over networking, scaling behavior, and infrastructure customization. We ultimately chose Kubernetes because of its strong ecosystem, cloud portability, mature tooling, scalability, and wide industry adoption, giving us the confidence for long-term growth and flexibility.

My advice to others looking into using Kubernetes is to have clarity about why they need Kubernetes. It is a very powerful tool, but it also adds complexity. It makes the most sense when you need scalability, reliability, and microservices management. Beginners should not directly choose Kubernetes due to its complexity because the documentation and everything may overwhelm them. I recommend starting with managed Kubernetes services to avoid operational overhead in the beginning, allowing teams to focus on application development rather than cluster maintenance.

If I want to add something more, an additional area that could be improved is upgrade and version management. While managed services help coordinate Kubernetes version upgrades, API deprecations and compatibility with add-ons can still be time-consuming and risky for production environments. Better tooling and clearer migration automation would make upgrades safer and easier. Another improvement could be around documentation, consistency, and discoverability. Kubernetes documentation is very comprehensive, but for beginners, it can sometimes be overwhelming to navigate and identify best practice paths.

For cost saving and resource optimization, we noticed meaningful improvements in resource usage and cost optimization. Although the numbers are approximate rather than exact, earlier, we were running mostly fixed-size servers to handle peak traffic, meaning many resources stayed under-utilized during normal load. After moving to Kubernetes, we were able to right-size our workload using CPU and memory requests and limits, and scaled replicas dynamically based on usage. In practice, this reduces the need for always-on extra servers. We saw roughly around twenty to thirty percent improvements in resource utilization, and in some cases, we could reduce the number of active nodes during low traffic periods. Auto-scaling also helped prevent over-provisioning instead of keeping capacity reserved all the time. We only scale up when traffic increases. This leads to more efficient infrastructure spending and better predictability of resource usage. Even though the environment is not extremely large, the optimization benefits are clearly visible and help control operational costs as the system grows.

In my organization, we primarily use Kubernetes in a public cloud environment. We run managed Kubernetes clusters, which helps reduce operational overhead such as control plane management, upgrades, and availability. For developers and testing, we also use local clusters such as Minikube or Docker Desktop Kubernetes, enabling developers to validate changes before deploying to the cloud environment. This setup gives a good balance between fast local development and a stable, scalable production environment in the cloud.

We purchased Kubernetes through AWS Marketplace because the cluster was provisioned using AWS tools and infrastructure, managing worker nodes, networking, and integration directly within AWS. We found it very helpful to integrate everything in the same environment.

For managed Kubernetes clusters, we initially used Google Kubernetes Engine (GKE). It was very stable and had strong native support for Kubernetes and easy cluster management. However, we are actually thinking of continuing with this because it solves all our problems effectively.

I believe Kubernetes is a strong platform for running scalable and reliable applications. It has helped us improve deployment consistency, availability, and operational efficiency. While there is a learning curve and some operational complexity, the benefits, in terms of automation, scalability, and ecosystem maturity, clearly outweigh the challenges. I would definitely recommend Kubernetes for teams building production-grade systems and who are ready to invest in good practices around automation, monitoring, and security. I would rate this product an eight out of ten.

My main use case for Kubernetes is to migrate from ECS to EKS, AWS Kubernetes 1.32 version.

Kubernetes offers excellent features including Datadog, Kubesystem, Kubecost, and CoreDNS.

Kubernetes has positively impacted my organization as 99% of microservices are running.

The positive impact has manifested in fast deployments and reduced downtimes.

Kubernetes can be improved, though I cannot specify exactly how at this time.

I have been using Kubernetes for ten years.

Kubernetes is fully stable.

Kubernetes' scalability is impressive.

I do not have support for AWS Kubernetes as I am learning Kubernetes as a personal endeavor.

I was using EC2 and ECS before Kubernetes, but EKS is far more functional.

I did not purchase Kubernetes through the AWS marketplace; I am using EKS as a native AWS solution.

I have had a good experience with pricing, but the setup costs are high.

I have seen a return on investment, and the metrics in return for the investment are very fast.

I have had a good experience with pricing, but the setup costs are high.

I did not evaluate other options before choosing Kubernetes.

I am using add-ons for EKS Kubernetes that stand out to me.

The useful add-ons help with administrating multiple clusters and accounts in AWS.

My company uses Kubernetes for microservices within the organization.

I advise others to look into using Kubernetes and not to pursue other options.

Kubernetes is something I want to emphasize before we wrap up.

I have given this review an overall rating of 80.

In my current role, I design and build production data pipelines, maintain and deploy critical infrastructure using Terraform, and manage AWS services such as EC2, RDS, and ELB. I also handle on-call issues as they arise and deploy data bundles to staging, acceptance, and production environments. These tasks are performed on a weekly basis or bi-weekly, depending on the training requirements.

Kubernetes is highly valuable for its node-based setup, which allows for the running of multiple pods. This feature is essential for infrastructure automation and application deployment. 

Kubernetes also offers rollback control and auto-scaling capabilities, which are crucial for maintaining an application's availability even if nodes or pods go down. 

Additionally, Kubernetes supports load balancing to distribute traffic efficiently across multiple pods.

We faced a challenge while migrating and upgrading versions of Kubernetes. After the upgrade, some pods were not up as expected, leading to downtime. The upgrade process required addressing these failures and adjusting for changes made by external services such as the AWS CodeBuild, which involved extensive investigation.

I have been using Kubernetes for the last three years. I'm employing EKS in my current role.

Our organization performs robust testing before sending changes to production, ensuring the stability of Kubernetes in live environments. We execute testing across multiple stages, such as testing, staging, acceptance, and pre-production, to prevent bugs from reaching customers.

The main benefit of Kubernetes' scalability is to ensure the application remains available. By using horizontal pod autoscalers, Kubernetes automatically adjusts the number of pods based on CPU, memory usage, or other metrics. Vertical pod autoscalers can also adjust resource requests and limits to match actual usage.

I would recommend Kubernetes to others, as many people are using it effectively. 

On a scale of one to ten, I would rate Kubernetes as eight out of ten.

The primary use case for Kubernetes in our environment involves deploying microservices. These microservices are hosted on the Kubernetes platform. We utilize Kubernetes within the insurance sector.

Kubernetes saves time in troubleshooting because it has a self-healing mechanism. If there is an unhealthy cluster or an unhealthy pod, it automatically heals and makes it operational again.

The most valuable feature of Kubernetes is its support for load balancing. This is important because there are many users who use our application, and load balancing ensures smooth operation for all users. 

Additionally, Kubernetes contributes to cost efficiency by saving time in troubleshooting due to its self-healing mechanism. It also features predefined YML files that streamline deployments.

There is room for improvement in this area, as Kubernetes could benefit from having more integrations, such as for scanning vulnerabilities.

I have been working with Kubernetes for three to four years.

I would rate the stability as five out of ten. If any containers take more space, sometimes the cluster goes down. Even though it has a feature to assign memory and CPU, doing so can hamper the services.

Kubernetes is a scalable platform, which is why we are using it. From one to ten, I would rate the scalability as eight out of ten.

Mirantis provides support for P1 related issues. However, due to time zone issues, problems can arise. Despite this, we have DevOps engineers who work parallelly to address any issues.

Positive

In previous companies, I worked with Red Hat's OpenShift. In comparison, OpenShift has more features, greater scalability, and more integration options. 

Currently, my company uses Mirantis Kubernetes due to its cost-effectiveness.

The setup is a little bit typical, yet not too difficult. It is easy to use.

We have DevOps engineers who manage the Kubernetes infrastructure. There are five to seven people on the team dedicated to this task.

I would recommend Red Hat's OpenShift for its feature set, scalability, and stability.

Our recommendation is to consider other platforms, like OpenShift, which are more efficient, more scalable, and have more support. 

I would rate the overall solution as eight out of ten.

We have clients that require us to deploy their monthly client structures in different locations, with different versions of the application running in various environments. For example, one version might be in one shop, and another version in a different shop. 

We create a container in Docker, and once the container is registered, any changes made can be deployed across all environments, ensuring consistency. Kubernetes handles the deployment process, ensuring everything runs smoothly. The Docker containers perform the necessary tasks for each deployment.

Kubernetes allows you to deploy containers in multiple complex environments. That's one of the main reasons vendors use it. It offers a container infrastructure where you can manage various applications, whether they use MongoDB, SaaS, or other services. Kubernetes acts as a broker to manage everything seamlessly.

Kubernetes improved our deployment and scaling processes. Previously, we used to deploy the application and then restart the server whenever there were changes.

Now, with Kubernetes and Spring Boot, we simply modify the YAML file and deploy it directly. Only the Docker image is different. Even that requires minimal changes.

With proper configurations, you don't need to intervene much. Spring Boot handles a lot for you. This allows you to focus on the end-user experience and scaling usage seamlessly.

GCP is one of the solutions that can manage and control the entire process on Google Cloud Platform. However, it’s not limited to GCP—userscan also use Amazon AWS or Azure. GCP provides disruption management and controller capabilities, which are critical.

I found it to be an excellent solution for application deployment. It's great for containerization. When considering containerization, Kubernetes offers better protection. However, with Azure, I didn't find it as effective in handling multiple clients within the same containerization environment.

In GCP App Engine for the year. Even before we started, we had to determine how many deployment environments we needed to deploy. You have to configure the GKE (Google Kubernetes Engine) to ensure it deploys across multiple servers, multiple deployments.

Generally, when we deploy the sync feature, we deploy it to synchronize something.

Perhaps there are some aspects related to its operation that could be improved.

One thing I noticed is when you have multiple deployments and your node count increases beyond eight or nine, the container creation process doesn't copy properties correctly. For instance, Kubectl wasn't working as expected with Docker Compose. I discovered that group secrets weren't being copied properly to all deployments. Permissions and other settings were fine, but this specific issue affected one group secret property.

Similarly, when using Kafka for messaging, it would send traffic but not to the correct topics. With multiple topics, like contact topics, Kubernetes wouldn't handle the routing properly.

These are the kinds of things I've observed where Kubernetes could improve. When sending messages to multiple friends using Kafka, Kubernetes doesn't provide direct access. You can use storage, but it's not ideal. That aspect definitely has room for improvement.

I had been using it since 2020, but with my new project, I stopped using it recently.

It has been stable. Let's consider this scenario: If we use a multi-factor processing system and it's not configured correctly, there will likely be performance issues. 

We need to have a clear understanding of our requirements when building an application. If we're expecting millions of users, the design and infrastructure need to handle that kind of load. Using a load balancer is crucial in such cases.

Kubernetes helps us manage high loads by distributing traffic across multiple systems and Docker containers. But if it's not properly configured and managed, there can be performance issues, especially under heavy load. I'm not saying it doesn't work; it still functions, but you might experience slowdowns. For example, saving data might take five minutes instead of one. These are the types of issues we've encountered. Maintenance tasks might also be affected if things aren't set up correctly.

When we have changes in Java application or other versions, we need to ensure that Kubernetes is updated. Kubernetes manages the deployment through configuration files and commands. 

Within those files, we can specify version numbers. If the version in the YAML file changes, Kubernetes will automatically download and update the application for the user. So from that perspective, it works well for scaling. However, when making updates, your Docker image needs to be able to handle the changes properly. Kubernetes will orchestrate the deployment, but the Docker image itself needs to be compatible.

Having a strong monitoring system is always beneficial. Even if you have on-premises support, a dedicated monitoring person or team is essential. They can be the point of contact for any critical issues that arise. You can discuss the problems you're facing or the solutions you're trying to implement. That kind of support is invaluable.

Positive

Our policy mandates using Azure Cloud only. We used GCP earlier, but recently, we moved to Azure. We used to deploy on Kubernetes, but due to cost considerations, we switched to Azure more recently.

For application security, we use Spring Security, along with wireless service security. Other than that, not much else.

It's Spring Security, along with a third-party tool to ensure that there are no vulnerabilities in the applications. The tool is called Viofixer. The service provided by this tool is limited to identifying vulnerabilities, but fixing them still needs to be done manually.

I also use MongoDB and SQL Server. Previously, we used Oracle, but the current project is using SQL Server and MongoDB.

The initial setup is not complex, but there are steps you need to follow. Once you have Docker set up for installations, Kubernetes doesn't handle much on its own. Docker does the heavy lifting for you. Kubernetes is just a container orchestration platform. It manages all your deployed containers.

Setting up the Kubernetes infrastructure might take an hour or two. The main time investment comes when you're making updates to your software. We customize the software, and then Kubernetes handles the deployment. This can be done in a matter of minutes with just a few Kubernetes commands. The deployment itself is very fast. But if your Docker image is large or Java-based, that might take longer. Kubernetes just orchestrates the containers; it doesn't take much time on its own.

There are not any major challenges with integrating Kubernetes into the infrastructure, but it's a process that takes some time. Initially, there might be a learning curve, especially with integrating different technologies like Python. But once you get past that, it becomes much smoother.

For deployment two people are enough. Initially, for maintenance might require three to four people, but once things are set up, one or two can handle it. I'm not entirely sure about the exact numbers, but we can manage the basics. The main requirement is the effort you're willing to put into making it successful.

The pricing depends on the project. Ultimately, it's a business decision, and they need to assess the risks and potential consequences. If the benefits outweigh the costs, then it's a worthwhile investment.

I'd estimate that it requires more than 10 to 15 percent upfront effort.

My clients had multiple different container orchestration solutions. Kubernetes might not perform well if you're deploying an application with thousands of Docker containers. It's better suited for GCP or environments with 10-15 machines. With cloud systems, you can scale up significantly, but you'll have to pay for those resources. If you have multiple deployment options and can leverage pay-per-use models, you'll need to factor in the costs of Google Cloud, AWS, or Azure. I've noticed costs around $0.053 per hour on AWS and GCP.

Kubernetes is a good solution, but consider the cloud platform carefully. GCP or AWS are better options. Kubernetes is just one component; the cloud provider is crucial.

Overall, I would rate it a nine out of ten.

We use Kubernetes to manage multiple pods where we store data, topics, and other resources within the Kubernetes cluster. 

We utilize it on Google Cloud Platform for this purpose. It is also used for container orchestration from lower to higher environments due to its ease of use and effective scaling capabilities.

Kubernetes is easy to use, maintain resources, and configure YAML efficiently. Its open-source nature makes it easier to deploy and manage containerized applications across any environment. 

Also, it provides the benefit of an n-plus-one architecture for port scaling.

Kubernetes can be complicated to understand. Improved documentation would help in gaining scalable knowledge and making it more understandable.

I have been using Kubernetes from September twenty two to currently now.

Kubernetes offers high stability, allowing for easy scaling of ports and containers, ensuring the environment and application stability across deployments.

Kubernetes is highly scalable, earning a rating of eight out of ten. It allows for easy scaling of projects and provides a reliable way to store and run applications.

I have minimal communication with Kubernetes support. I rate it between seven and eight because the application is stable, and I seldom require support.

Neutral

The initial setup wasn't overly difficult. I am not very experienced, so I would rate my setup experience a six out of ten.

For deploying Kubernetes, one expert is needed for deployment knowledge and two to three people for monitoring and maintenance.

Investing in Kubernetes has been beneficial. We receive revenue and returns from its deployment due to improved services and applications.

I do not have specific figures, however, Kubernetes is not expensive overall. It is affordable and justified in price.

I rate Kubernetes nine out of ten. It is one of the best products available currently. I do not have any advice for new evaluators.

We use Kubernetes for our data science machine learning platform to orchestrate UPCR Hub containers with UPCR Hub partners. We also use it to orchestrate data pipelines.

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

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

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

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

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

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

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

Positive

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

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

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

I'd rate the solution eight out of ten.

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. 

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.