Summary and comparison of Kubernetes Operators against other methods

To complete our examination of why and when to use Kubernetes Operators, let's look back at the credential rotation scenario to compare the example operator with an alternative approach of simply scripting a set of steps to provide the same functionality.

What you learned from the credential rotation scenario

By following the articles and tutorial in this learning path, you walked through the implementation of an operator that handles the rotation of credentials for the back-end database in a distributed application. We used the Operator SDK to encode the steps illustrated in the following diagram.

Automate by using an operator

As a reminder, what you learned is:

• The setup and deployment of our new operator caused a new custom resource definition (CRD) for credential rotation to be created, along with a controller that handles updates to resources of that kind.
• When our new controller spotted a new CR of this kind, it performed the steps needed to affect the credential rotation without any human intervention. To do this, the controller:
  • Created a service resource key for the IBM Cloudant database deployed in the IBM Cloud.
  • Updated the Kubernetes Secret with the new resource key.
  • Restarted the web application instances.
  • Deleted the previous resource key for Cloudant in the IBM Cloud.

The implementation demonstrated how we embedded the necessary logic for these steps into a controller that has access to internal cloud-native concepts and support, such as cluster and state changes. We showed how this functionality can be triggered by a simple resource creation by using kubectl. We demonstrated that a natural by-product of using an operator is ensuring that our status is visible through standard Kubernetes commands, and we can easily add logging to our operator to create an audit trail of what transpires.

However, before declaring victory for operators, we should look at how else we might implement such functionality. Scripting is a standard tool used by admins who manage Kubernetes clusters. Therefore, it is worth comparing how a solution can work this way.

Alternative solution: Automate with scripting

You can automate the credential rotation steps by creating a script that uses commands such as kubectl and curl to create and modify the various objects and resources.

First, you must consider whether this script will run outside of the cluster with the standard external access commands and controls. As such, you must ensure that you have the required access rights. For this credential rotation example, they are:

• An Access token that enables you to use curl to create the new resource for the Cloudant database and to delete the old one at the end.
• The required cluster access rights so you can create and update the Secret and then update the deployment, perhaps by describing them in your kubeconfig files.

After you secure the correct tokens and access rights, the script steps are as follows:

• Use curl with the appropriate token to create the new resource key.
• Use kubectl to update the Secret with the new credential.
• Use kubectl to update the deployment with a timestamp and cause it to restart the pods.
• Use curl with the appropriate token to delete the old resource key.

Unfortunately, as anyone who has ever scripted something similar to the previous steps knows, things don't always go to plan. So, as part of the script, you must:

• Check the error status back from each command and take an appropriate action.
• Ideally, add some logging that the cluster's log management system could easily use, so there is an audit trail of the actions that were applied externally.

This adds some extra "housekeeping" duties that you must handle yourself.

Why use a Kubernetes Operator?

Considering the two solutions to the credential rotation scenario, it's not surprising that the logic steps are the same. There are two important questions to consider:

• Where is it best to place this logic?
• How difficult is it to provide a full, production-ready version with all of the required error checks, logging, and auditing?

While it remains true that you can almost always implement a solution via scripting, the advantages of using Kubernetes Operators are strong. These include:

• Built-in support for responding to resource-driven action. For example, supporting the creation of a "rotation request" resource by using kubectl as the trigger to act. This provides a simple mechanism to integrate this new capability into other internal tooling. It needs only to be able to create a CR.
• Less hands-on interaction and human errors after the operator is deployed. If you deploy a CR instance for the request, it executes declaratively as usual by Kubernetes. This results in fewer human errors.
• Security handled within the operator. Moves the permissions that are required for operations to the operator itself, rather than an individual who wants to start the operation (who needs only permission to create the CR). As an operator is deployed in the cluster, it has direct access to the cluster with no need for cluster authentication and authorization. The operator role-based access control (RBAC) is setup during deployment.
• Maintenance logic is tightly coupled to your application. As an application vendor, embedding your application-specific maintenance logic in an operator means that it is more tightly coupled to your application architecture within your development process. As your architecture changes over time, this coupling minimizes the possibility that a separate script will get left behind and no longer conform.
• Automated updates to libraries. Often, the logic might need to use additional libraries to integrate with other systems. You can use standard build mechanisms to ensure that your operator has the correct updated versions.
• Cloud-native support. Direct support for internal cloud-native concepts for operators that are implemented by using Golang.
• Record of requests. All requests are logged and audited so that a record of them exists. These logs are easily integrated into whatever log management system that you are using. By default, they are most likely already captured.
• Kubernetes events. You can generate Kubernetes events to show the different responsibilities and phases of the overall controller process. As a result, you can use a simple kubectl get object command to monitor the progress of the rotation (you can also easily integrate this monitoring into other internal tooling).
• Easier error handling Operators make it easier to handle errors from cluster commands since you use the Kubernetes Go client.

An extension of 12-factor applications

Our team thinks of an operator as a natural extension of 12-factor applications because operators ensure that application-specific maintenance functionality can be implemented, updated, and deployed separately from other unrelated application logic. But, most importantly, it is still treated as a full, first-class citizen with all of the same support as other functionality in the application.

Next steps

Now that we explained why and when you should use operators, your next steps are to understand how to build operators and to get experience building your first simple operator. Get started using Kubernetes Operators is a comprehensive learning path that provides the information you need to build your first operator. After you complete that learning path, the Kubernetes Operators Intermediate course is a great next step for you to take.