Kubernetes Reviews

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Positive

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

We use Kubernetes to orchestrate the containers for deploying our Docker images to Kubernetes. I'm an Azure DevOps lead.

Kubernetes has some advanced features like auto-scaling and a good self-healing facility. If Kubernetes runs in the form of ports and one of the ports dies, a new one automatically appears. These advanced features help us to deploy our application and makes life easier.

I find the auto-scaling feature very good because rather than manually decreasing the number of nodes, we can define the threshold.

The UI should be improved. It would be helpful if it was more graphical. Kubernetes currently runs perfectly with the Linux environment because it has Docker as a container runtime, and Docker works perfectly with the Linux operating system. It should also be able to run with the MacBook and Windows OS, similar to Linux and it would be helpful if they would include this in the next release. 

I've been using this solution for four years. 

The solution is stable. 

If you're using a cloud service provider there's no problem with scalability. When there's a newer version, we'll upgrade our Kubernetes cluster to the latest version. 

We previously had an on-prem solution using some tools like ClearCase, which is a centralized repository we used to work under. Given that everyone is migrating to cloud, we've done the same, migrating our applications to AWS and Azure Kubernetes.

Although it doesn't take long to deploy, Kubernetes is difficult to set up even if it's the small, mini one-node Kubernetes cluster. For a cloud deployment, it's either Azure or AWS. The cloud service provider will take care of the master node. We currently have a DevOps team of seven people. If we have a big cluster, we can it into multiple clusters, one for the Dev team, one for the QA team, and one for production; each team can work on its cluster and deployment can be done quickly. 

Pricing depends on the cloud service provider. Comparing AWS and Azure, Google Cloud has a much better pricing model, as does Linode. We receive a monthly licensing account.

It's important to learn the architecture of Kubernetes and know what each and every component of Kubernetes does. It makes the deployment easier. Whether or not you choose Kubernetes depends on your use case. If you have a business model that requires minimal changes with fixed requirements then Kubernetes might not be the way to go. If you're constantly needing to make changes, Kubernetes is a great solution. 

I rate the solution eight out of 10. 

We use Kubernetes to run some content as SaaS-based applications, and there are a few more in the pipeline to migrate from the IBM MQ server and mounting to containerization.

The best thing about Kubernetes is orchestration. It is very good. We will not see much downtime unless there are some human errors. We do not see much downtime or issues with the container or automation.

I'm a beginner, and I recently started working with Kubernetes. As of now, I don't see any bugs. However, it would be better if it could be deployed without coding.

I have been using Kubernetes for about six months.

Kubernetes is stable for now. Since we are in the process of migrating, I cannot tell for sure. But my friends have been working on it and do not have any problems. 

Kubernetes is a scalable solution. That is the reason we do not see much downtime. It is always available as needed.

Because I have an infrastructure background, it is difficult for me to code some parts. So, I depended on some experts here to deploy this solution. It is not very difficult for them.

I would tell potential users that Kubernetes is a very good solution and they should use it.

On a scale from one to ten, I would give Kubernetes a nine.

We use Kubernetes to deploy a software solution that the company sells to enterprises. Originally, our company offered their software installed without Kubernetes, but they plan to move all future customers to Kubernetes. I would say it's extensively deployed, and they plan to increase it as much as their customer base will accept it.

Kubernetes provides a standardized way to deliver software in a scalable form. The customers of the software already have people who know how to manage Kubernetes, or they can easily hire employees who do. Packaging up the software to run would require a lot of specialized knowledge.

Kubernetes provides scalable clustering for containers and other means of deployment.

Kubernetes is incredibly complicated, so one area of improvement is the ease of administration. I would like a user interface that you can run to help you debug and diagnose problems and suggest how to configure things.

I've been using Kubernetes for about four months. I started using it at HPE and actually switched to be able to work more with it at the new place.

Kubernetes is generally stable. 

Kubernetes is scalable if it's well-administered. 

As far as I know, there's not any customer support. There's customer support for the cloud instances. If you are running Amazon EKS, they might have support for that. It's open-source software, so there isn't Kubernetes support, but I could be completely wrong about that.

The complexity depends on how you deploy it and what flavor you choose. If you're using a cloud provider like Google, AWS, or Azure, they each have a flavor of Kubernetes you can deploy. It is easier to deploy one of those than downloading and installing it on your servers. There's also something called K3S, a lightweight version of Kubernetes that can run much more easily. It's designed to be used in the Internet of Things. It's relatively scalable and can be used independently, but there are different packages, just like Linux has different distributions.

The maintenance required also depends on how you implement it. It's going to require at least one person who knows Kubernetes. I imagine it might need multiple people to maintain the solution if you're not using the cloud versions.

Kubernetes is open source.

I rate Kubernetes 8.5 out of 10. My advice is to hire people who have demonstrated experience or are prepared to spend significant time taking courses because it's deep and broad, and there's a lot to learn. It isn't straightforward, but it would be hard to simplify it, considering what it does.

At my company, we use Kubernetes to host our databases and applications. We work in the telecom domain, and our products use database technologies like Oracle, Postgres, and Cloudgres. We use Kubernetes to host NoSQL databases like Couchbase and Postgres and for some of our containerized applications. We are involved in multiple projects, not just a single one.

Kubernetes is a microservice. So, the best thing about Kubernetes is that most of the containerized applications are centralized. You don't need to develop specific company applications on top of container images. Kubernetes also provides flexibility in maintenance. It takes away most of the maintenance part, such as if a port crashes, it comes up automatically, making deployment very easy. We just need to run a few commands to deploy the application, and maintenance is taken care of by Kubernetes. Upgrading applications becomes smooth, requiring less effort and time.

Resource utilization, cost savings, and portability are additional advantages of Kubernetes. It is available in the public clouds, and portability becomes very easy. When it comes to networking, Kubernetes offers very flexible containerization with the added benefit of CSI.

There are several areas where Kubernetes could improve. For example, in one of our database projects, we needed a storage layer that would work on safer sites. Our application is a permanent one that requires low latency and is intensive in terms of networking. It works on every single URL and needs access to the database. After researching several solutions available in the market, we went with Portworx for the database back-end storage layer. However, we encountered an issue when we brought down one of the worker nodes in a cluster of three nodes. The pod that was hosted around that worker node was not responding on other worker nodes, even though it was responding. We found out that there was a feature in the alpha stages in the stable site that could have solved this issue, but we don't enable alpha features in our production environment. Therefore, we increased the replication factor in the storage layer from one to two to avoid this issue. Our application is latency-sensitive and demands low latency in terms of network and response time.

So, increasing a replica of the storage level will also cause double the I/O, which has additional costs involved. We did extensive research on that and found that the feature needs to be stabilized; certain improvements are required. 

I have been using Kubernetes for around two years now, and I'm familiar with it. I worked closely with both the implementation team and the engineering team as well as the research and development team.

It is a stable solution. 

Scaling up and down is easy in Kubernetes, so adding or removing worker nodes is simple and straightforward.

The engineering team uses it the most. We started with three projects, and now I can see around 150 to 200 people using it.

There is a good support community available.

It's free and open-source; anyone can use it. So there are no hidden fees or anything regarding Kubernetes.

I would encourage you to start with Docker containers first, get the hang of it, and then move on to Kubernetes.

Understand the Docker concepts, software, container networking, and how container images are built. Once that's done, it becomes easy to enter into the Kubernetes world. Kubernetes is an orchestration tool that builds on top of Docker containerization.

I would rate it as excellent because it is very easy to deploy applications, manage ports, and expose applications both within and outside the cluster. Kubernetes also has a good reach and can be used in both private and public clouds, and there is plenty of support in terms of documentation and online forums to help users who run into any issues.