Enterprise organisations need cloud. They need cloud computing services to be fast to deploy, flexible to operate and robust to operate. But what all those attributes really come down to is the fact that businesses need cloud computing services that scale. Remy Vandepoel, technical cloud evangelist at OVHcloud explains the role of the Kubernetes Operator tool in making this whole process possible. But what is this technology, how does it fit into the world of microservices and what do we need to know about its implementation power and nuances?
As Red Hat reminds us, a Kubernetes operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is both deployed on Kubernetes and managed using the Kubernetes API (Application Programming Interface) and kubectl tooling.
With what is estimated (again, by Red Hat) to be over two-thirds of organisations now using microservices, Vandepoel reminds us that since the dawn of Docker, businesses across the world have reaped the benefits of containerization – even if the real roots of microservices lie with SOA and SOAP in the 90s!
As we know, the ability to split up a large, monolithic application into a large number of smaller, more agile components has enabled business to be far more flexible, allowing distinct parts of the application to be monitored, managed, improved or swapped around independent of the rest of the functionality.
“However, this also means more complexity for DevOps teams,” said Vandepoel. “Kubernetes helps with this to some extent by orchestrating containers, taking routine tasks and automating them. However, really complex deployments require a lot more work – we’re not just talking about twenty or thirty microservices across one application, we’re potentially talking about thousands across multiple applications, servers and regions. So also, for each object, DevOps needs to manage ingress, services, deployment, upgrades, testing and so on.”
Software takes the Helm
This is where further automation comes in.
The OVHcloud team say that they have seen a lot of users will start to reach for management suites like Helm to manage Kubernetes packages. Helm is of course a useful tool used by a lot of software engineers because, for example, it can provide developers with – amongst other things – a global chart that describes all ingress services. It’s also a good way to manage complexity if you’re doing rollbacks, but it does have its limitations.
“The main limitation is that Helm only really helps with installing and upgrading microservices and the life of the DevOps team is a lot more complex than this. Human operators need support during the entire lifespan of the application, measuring, providing insights and so on, and Helm doesn’t provide services for the latter parts of the lifespan,” explained Vandepoel. “What we really need to do is automate more and ideally, take some of the knowledge of a human operator and work it into automated processes. This would free DevOps staff to work on more innovative tasks and avoid spending their time on low value, day-to-day operations.”
Controllers & custom resources
Drawing its decision to talk about this technology based upon conversations with its customers in real world deployment environments, OVHcloud highlights the Kubernetes Operator option, which combines two simple tools together. Firstly, it uses Kubernetes Controllers. These are ‘reconciliation loops’, which can look at the current state of a cluster and compare it with the desired state stored in a .yaml file, then make or request the changes needed to make the two states match. The controllers observe, they find the difference and then they act.
“But this isn’t always enough, because our environments are frequently different, new or unusual, and we can’t always describe system elements to Kubernetes Operators straightaway,” clarified Vandepoel. “This is where Custom Resource Definitions (CRDs) come in. CRDs allow us to introduce our own APIs into a system, so that we can manage more than just containers. For example, CRDs can allow you to define and manage routers, using Kubernetes. Kubernetes Operators combine these two concepts to encode human knowledge within CRDs, defining the system environment and then apply controllers to automate key tasks. Voila!”
He provides working examples associated with a fairly mundane task: database administration. Looking at, backup, database backup can be a complex task, but by thinking through it logically, it can be automated. What Vandepoel says we need to do is define a CRD to represent the database cluster and each instance and then use the controller to define the process.
“For example, the controller needs to check whether it’s time to run a backup and if it is, it needs to stop data being written to each instance so that it can perform the backup correctly. We then need to get the controller to carry out the snapshot and store it in the right environment. There may be other nuance to the process because your environment is slightly different, but like most processes, it’s essentially a flowchart,” he advises.
Similarly, cloud-native developers can use operators to create new database shards. Again, they use the CRD to represent the database cluster and each instance – and then use the controller to define the process. In this case, the controller needs to check how loaded up each instance is and check this against the desired state to decide whether or not to create a new instance. If the load is near or above the limit, then it creates a new shard.
Choose your own Operator
“Operators can be as simple or as complex as you need, from basic installations and upgrades to full ‘autopilot’ cases, such as the example above, deciding that a database cluster needs a new instance and provisioning it without any human intervention,” confirmed Vandepoel. “Operators are relatively straightforward to create. You need to create the project and write the CRD, specifying the resources to be watched and what actions are necessary – and on the other side, you also need to define the reconciliation logic in the controllers, building the overall operator.”
There are a number of other tools in this space that can make life easier.
Kubebuilder will help build APIs, this is an SDK for rapidly building and publishing Kubernetes APIs in Go. It builds on top of the canonical techniques used to build the core Kubernetes APIs to provide simple abstractions that reduce boilerplate and toil. The OVHcloud team say that Operator Framework can also help; this technology has an SDK that helps build, test and iterate in either Helm, Ansible or Go. OperatorHub.io is also worth checking because it already has a large number of open-source operators that have been written to help you avoid reinventing the wheel.
Microservice migraines & merriment
Given the position OVHcloud takes to provide its customers with a variety of cloud services, we can reasonably get some idea of how broad the complexity factors are for a cloud provider (as the company is) that delivers public and private cloud products, shared hosting and dedicated server solutions in 140 countries worldwide.
The firm also specialises in domain name registration, telephony services and plain and simple Internet access. Perhaps it’s no wonder that Vandepoel rounds out this discussion by saying that microservices can be both an incredible asset of great merriment and a source of considerable migraine headaches. But the resounding message here is that with the right tools and automation, even the most complicated environments can be tamed.