Voice of the DBA

Tag: kubernetes

  • The Inefficiencies of Kubernetes

    A report of cloud Kubernetes usage shows that these resources are being under-utiliized, over-provisioned, and costing more than necessary for many organizations. From the previous year, average CPU declined from 13% to 10%, and memory is used at only around 23%. Companies are over-provisioning their clusters, which is understandable. No one wants to have systems overloaded and users complaining about performance.

    However, this is a similar tension to what we see with virtualization on-premises. Operations people want to leave plenty of CPU/RAM/IO headroom for systems to handle bursting or increasing workloads. Management wants to get all the use they can out of their investment and would prefer we provision systems as closely as possible to their expected workloads. Containers and orchestrators should allow a closer match, but only if there are workloads that burst enough to require additional containers and pods to be deployed. That does happen with memory occasionally at a little over 5% of containers exceed their memory, but that’s not a significant amount.

    Managing a Kubernetes cluster is a specialized skill and most organizations don’t have the skills or experience to do it well. My view is that if you want to use an orchestrator, you’re better off letting the cloud providers manage the infrastructure and scale up and down as needed. There are autoscaling technologies to help Operations staff better manage their capacity and costs, but this is an additional skill people need.

    While I do think some companies are adopting cloud native technologies and rewriting their applications to run in containers and Kubernetes clusters, I find many more companies are hesitant to adopt a very complex technology on top of the complexity of teaching their developers to work within containers for their applications. Certainly in the Microsoft space, I don’t see a lot of database servers running in containers. Despite some of the advantages of upgrades and downgrades, the unfamiliarity with the ins and outs of containers leads most teams to continue to manage the database separately.

    Resource matching to a workload is a problem we’ve had for years and Kubernetes doesn’t make this any easier to deal with. The cloud is supposed to help us better manage our resources, but there is a lot of knowledge needed to do this well. Add in the cost/performance issues in the cloud and it’s no wonder that many companies have overprovisioned their resources to ensure systems continue running. I don’t know whether lots of IT staffers are optimistic about their workload growth or scared of potential problems from overloaded systems, but unless organizations carefully manage all their resources, they are likely to continue to see larger cloud bills than they like.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Kubernetes is Cool, But …

    Kubernetes is cool, and I think it’s really useful in helping us scale and manage multiple systems easily in a fault-tolerant way. Actually, I don’t think Kubernetes per se is important itself; more it seems that the idea of some orchestration engine to manage containers and systems is what really matters. As a side note, there are other orchestrators such as Mesos, OpenShift, and Nomad.

    However, do we need to know Kubernetes to use it for databases? This is a data platform newsletter, and most of us work with databases in some way. I do see more databases moving to the cloud, and a few moving to containers. I was thinking about this when I saw a Simple Talk article on Kubernetes for Complete Beginners. It’s a basic article that looks at what the platform consists of, how it works, and how to set up a mini Kubernetes platform on your system. It’s well written and interesting, but …

    Do we need to know anything about it? Are we running databases in containers, or will we? I think it’s possible that we might run any of our databases in containers. They are like lightweight VMs and there isn’t a reason why we wouldn’t run a database in a container. With external storage, of course, which gives you a cluster-like environment where your storage moves to a new node if the first one fails. That’s a good use case. Deploying consistent environments quickly is a good use case. Using Kubernetes to manage the containers is great, but …

    I don’t think we need to know much about Kubernetes. I don’t think most of us should run it and should outsource any container orchestration to the cloud if we decide to implement database containers. These orchestration engines are quite complex today, and there is a lot of expertise needed to manage them. I don’t know that expertise is worth trying to find, train, and retain for most organizations. We should just outsource the container management to someone else.

    We might need to know how we change the configuration of some resources, but that’s minor knowledge, and really, I suspect that outsourced K8S (shorthand for Kubernetes) will have GUI tools that let you easily pick and choose the CPUs, memory, etc. and then an export of the JSON or YAML or whatever is needed for the config. Most of us likely need the skills to export, save (in a VCS) the files, and then submit them to the cluster.

    A few years ago I went through a bunch of courses and reading material on Kubernetes. I set up some small clusters, I experimented with pods, I even was excited to think about managing containers for various services. What I discovered is that Kubernetes is complex, hard, and something I want someone else to run. Once I set up a cluster in Azure I thought I’d never want to do this on-premises again.

    Much like email. I have run email servers, but …

    I’d like to never run one again, which is how I feel about Kubernetes.

    I think containers have proven more complex and harder to work with than many people thought. I know there are plenty of people using them, but it’s a minority. I see many more organizations still building monoliths, or microservices that run as processes, or client-server apps. Not that many people are excited and using containers. That may change, and if you go to the cloud, containers give you portability that many other solutions don’t, so I’d recommend them there. However, they are still a bit immature, and hard to manage. I think it will be a while before we see lots of databases on containers.

    Even if we do, I’m not sure we need to learn Kubernetes as database people.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

  • How Hard is Kubernetes?

    We’ve run Kubernetes inside Redgate for some research projects (like Spawn) and we are building some skills running this orchestrator. At the same time, we’ve had no shortage of challenges in keeping the clusters up at times, patching, fixing issues, upgrading to new configurations, etc. Like any software, there is work involved with managing the orchestrator.

    I’ve watched Andrew Pruski and Anthony Nocentino write about containers and Kubernetes and overall they’ve made me view the clusters like email. It’s useful and I want to use it, but I don’t want to manage or administer it. I’d want some service like AKS or EKS instead. Let someone else build expertise.

    If you use containers, do you have an orchestrator running in your data center? Mercedes does, with over 900 clusters. They found value early on with container technologies and built in-house expertise within their research arm. I think a large organization like Mercedes likely can make this investment pay off, especially as they likely don’t depend on any one person to understand and manage Kubernetes. They can afford someone like Andrew or Anthony quitting and taking another position.

    The rest of us can’t really do that, certainly not without our organization feeling containers and orchestration is a core competency.

    The key for Mercedes is automation. They note that if they added 500 more clusters, they’d need just one more engineer. That’s a key for any of us that want to manage growing numbers of systems without spending a lot of our time reviewing resumes and hoping we can hire good staff. Hiring is hard, and finding good people even harder. When you find them, set them free codifying their knowledge using DevOps, scripting, automation, and more.

    Then educate others and teach them what your talented engineer is doing. Mercedes notes that finding people is hard, and educating existing people is easier. DevOps, better coding, understanding APIs and declarative scripting are not hard skills, but they are something people need to practice to develop familiarity and skill. We want staffers to be able to easily pick up the work of another, understand it, and extend or improve it. We don’t want to depend on the person that wrote it.

    The way Mercedes has attacked this technology is the way I’d have developers and administrators tackle DevOps. Take advantage of the power of modern software development and infrastructure tools and empower your staff to make things better. They are likely to enjoy their jobs more and remain employed, reducing your need to struggle with the vagaries of finding and hiring good people, a problem no one has solved well.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher, Spotify, or iTunes.

  • Containers, Kubernetes, and SQL Server

    Abstract: Containers and Kubernetes have become buzzwords in the application development world, but how do these technologies fit with SQL Server? This session will discuss the basics of containers and Kubernetes and explain how we can use containers with databases in SQL Server. We will also briefly look at the future of SQL Server with Kubernetes support.

    Level: 100

    Slide Deck: ContainersKubernetesSQLServer.pptx

    Code:  Containers_Kubernetes_SQLServer.zip

    Speaking Events: