Book Image

The Kubernetes Operator Framework Book

By : Michael Dame
1 (1)
Book Image

The Kubernetes Operator Framework Book

1 (1)
By: Michael Dame

Overview of this book

From incomplete collections of knowledge and varying design approaches to technical knowledge barriers, Kubernetes users face various challenges when developing their own operators. Knowing how to write, deploy, and pack operators makes cluster management automation much easier – and that's what this book is here to teach you. Beginning with operators and Operator Framework fundamentals, the book delves into how the different components of Operator Framework (such as the Operator SDK, Operator Lifecycle Manager, and OperatorHub.io) are used to build operators. You’ll learn how to write a basic operator, interact with a Kubernetes cluster in code, and distribute that operator to users. As you advance, you’ll be able to develop a sample operator in the Go programming language using Operator SDK tools before running it locally with Operator Lifecycle Manager, and also learn how to package an operator bundle for distribution. The book covers best practices as well as sample applications and case studies based on real-world operators to help you implement the concepts you’ve learned. By the end of this Kubernetes book, you’ll be able to build and add application-specific operational logic to a Kubernetes cluster, making it easier to automate complex applications and augment the platform.
Table of Contents (16 chapters)
1
Part 1: Essentials of Operators and the Operator Framework
4
Part 2: Designing and Developing an Operator
9
Part 3: Deploying and Distributing Operators for Public Use

Planning for deprecation and backward compatibility

In the previous section, we discussed the work needed to release a new version of an Operator. While the processes for bundling and publishing a new version are relatively simple in terms of the effort required, implementing a new API version is not an insignificant task. As such, doing so should be done only as necessary in order to minimize the use of engineering resources and disruption to users.

Of course, it will occasionally be unavoidable that incompatible changes must be introduced, for example, in the case of deprecation. Some of this deprecation might even come from upstream, where it is beyond your direct control (see the Complying with Kubernetes standards for changes section). However, the frequency of such changes can often be controlled through careful planning. In this section, we'll discuss some ways to plan for deprecation and support backward compatibility without causing undue strain on your engineers...