You are here, so there are two possibilities, either you already know about below terms/strings or you want to know more about these strings. In any case, I have to touch upon these strings before we proceed further.
Custom Resource Definitions ( CRD)
Custom Resources ( CR)
Operators/Controllers
Operator SDK
Custome Resource Definitions/CRDs:
In the Kubernetes API a resource is an endpoint that stores a collection of API objects of a certain kind. For example, the built-in pods resource contains a collection of Pod objects.
A custom resource is an object that extends the Kubernetes API or allows you to introduce your own API into a project or a cluster.
A custom resource definition (CRD) file defines your own object kinds and lets the API Server handle the entire lifecycle. Deploying a CRD into the cluster causes the Kubernetes API server to begin serving the specified custom resource.
When you create a new custom resource definition (CRD), the Kubernetes API Server reacts by creating a new RESTful resource path, that can be accessed by an entire cluster or a single project (namespace). As with existing built-in objects, deleting a project deletes all custom objects in that project.
Additional Reference:
https://docs.okd.io/latest/admin_guide/custom_resource_definitions.html
https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/
Custom Resources/ CRs:
A resource is an endpoint in the Kubernetes API that stores a collection of API objects of a certain kind. For example, the built-in pods resource contains a collection of Pod objects.
A custom resource is an extension of the Kubernetes API that is not necessarily available on every Kubernetes cluster. In other words, it represents a customization of a particular Kubernetes installation.
https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
Operators/Controllers :
An Operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and kubectl tooling.
To be able to make the most of Kubernetes, you need a set of cohesive APIs to extend in order to service and manage your applications that run on Kubernetes. You can think of Operators as the runtime that manages this type of application on Kubernetes.
https://coreos.com/operators/
Operator-sdk:
The SDK provides the tools to build, test and package Operators. Initially, the SDK facilitates the marriage of an application’s business logic (for example, how to scale, upgrade, or backup) with the Kubernetes API to execute those operations. Over time, the SDK can allow engineers to make applications smarter and have the user experience of cloud services. Leading practices and code patterns that are shared across Operators are included in the SDK to help prevent reinventing the wheel.
Enough theory, let’s get into the part of building an operator!
I would like to conclude by writing a sample operator in two parts than a single article. However we will get started here with the operator sdk framework and set up our system for further enhancements.
Step 1: Prepare a directory for the operator framework and then clone the sdk repo in it.
$ mkdir -p $GOPATH/src/github.com/operator-framework
$ cd $GOPATH/src/github.com/operator-framework
$ git clone https://github.com/operator-framework/operator-sdk
$ cd operator-sdk
Step 2: Let us check out the `v0.4.0` version of operator sdk and then make sure all the dependencies are in place and sdk is installed via the below command.
$ git checkout v0.4.0
$ make dep
$ make install
We will discuss more about how to set up a new project: We/You could name your controller in any name. However all the talks I attended on operator sdk talk about a sample project called `podSet` operator!! , so let us stick to that for now
Step 3: Create a new project
$ operator-sdk new podset-operator
# check the project structure
$ tree -I vendor
.
├── Gopkg.lock
├── Gopkg.toml
├── build
│ └── Dockerfile
├── cmd
│ └── manager
│ └── main.go
├── deploy
│ ├── operator.yaml
│ ├── role.yaml
│ ├── role_binding.yaml
│ └── service_account.yaml
├── pkg
│ ├── apis
│ │ └── apis.go
│ └── controller
│ └── controller.go
└── version
└── version.go
If you ran or created a new project using operator sdk, it would have kickstarted the project called `podSet` and then ran “dep ensure” and “git init” automatically as part of the above command
As we have the project ground ready let’s create a custom resource called `podSet` and a controller object for this CR ( podSet) using operator-sdk command as shown below.
Step 4: Create a custom resource and a controller object for sdk.
# Add a new API for the custom resource PodSet
$ operator-sdk add api –api-version=app.example.com/v1alpha1 –kind=PodSet
# Add a new controller that watches for PodSet
$ operator-sdk add controller –api-version=app.example.com/v1alpha1 –kind=PodSet
Let me stop here and explain the operator building in detail in another blog post soon.. so wait for `[part-2` of this series in this space. Meanwhile look around the files/directories available in this project namespace to get a feel of what’s available now. We will have a detailed explanation of the directory structure in the next blog post.
Copyright secured by Digiprove © 2019 Humble Chirammal