Introduction to Operators

In this lesson, we revisit some fundamental concepts from earlier in the course while focusing on how Kubernetes’s extensible API enables innovative resource management through operators.

Understanding Kubernetes

Kubernetes is an API that allows you to programmatically manage and interact with your infrastructure. Whether you use a Kubernetes manifest or an SDK, every operation with Kubernetes is performed via its API. One of the API's most powerful features is its extensibility—you can create new APIs that build upon its core functionalities.

For example, the core API group includes resources like deployments, while the networking group features resources such as ingress controllers provided by the networking.k8s.io API. Originally designed and implemented by engineers, Kubernetes is inherently extensible, paving the way for the use of operators.

A Kubernetes operator extends the functionality of the Kubernetes API. Operators simplify the process of creating, configuring, and managing any type of resource or containerized application on Kubernetes.

There are two primary approaches to extending the Kubernetes API:

1. Creating a dedicated, full-blown controller.
2. Utilizing a Custom Resource Definition (CRD).

Custom Resource Definitions (CRDs)

Custom Resource Definitions (CRDs) act as APIs for creating new APIs. They allow you to extend the Kubernetes API in a consistent and defined format. For instance, consider the following example CRD that defines a new custom resource called "Crontab":

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # The name must match the spec fields below and should be in the form: <plural>.<group>
  name: crontabs.stable.example.com
spec:
  # The group name to use for the REST API: /apis/<group>/<version>
  group: stable.example.com
  # List all versions supported by this CustomResourceDefinition
  versions:
    - name: v1
      # Each version can be enabled or disabled with the "served" flag.
      served: true
      # Exactly one version must be marked as the storage version.
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                cronSpec:
                  type: string
                image:
                  type: string
                replicas:
                  type: integer

This CRD allows you to create new resources defined by the above schema.

Viewing CRDs in Visual Studio Code

Open Visual Studio Code in your Kubernetes example repository—files like nginx.yaml will show you API version information, kind, and other deployment details. Consider opening a project created using KubeBuilder called "Custom Resource Definition."

KubeBuilder is a popular tool for creating CRDs. In the API files, you will see Go code that defines the types for your new API. Below is a simplified excerpt highlighting these definitions:

// Define the specification for MikesAPI
type MikesAPISpec struct {
    MikesPhoneNumber string `json:"mikesPhoneNumber"`
    MikesAge         string `json:"mikesAge"`
}

// MikesAPIStatus defines the observed state of the MikesAPI
type MikesAPIStatus struct {
    // INSERT ADDITIONAL STATUS FIELD - define observed state of the cluster
    // IMPORTANT: Run "make" to regenerate code after modifying this file
}

// MikesAPI is the Schema for the MikesAPI API
type MikesAPI struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   MikesAPISpec   `json:"spec,omitempty"`
    Status MikesAPIStatus `json:"status,omitempty"`
}

If you’re new to Go or CRDs, some of these details might be unfamiliar. However, the objective here is to illustrate how you can define new APIs that extend the Kubernetes API.

Controllers and the Reconciler

Next, let's examine controllers and their role in managing custom resources. In our project, the controller is implemented in Go and is tasked with reconciling the state of your custom resource (in this case, MikesAPI). Below is an excerpt from a reconciler:

package controllers

import (
    "context"

    "k8s.io/apimachinery/pkg/runtime"
    ctrl "sigs.k8s.io/controller-runtime"
    "sigs.k8s.io/controller-runtime/pkg/client"
    "sigs.k8s.io/controller-runtime/pkg/log"

    simplyanengineercomv1 "simplyanengineer.com/MikesAPI/api/v1"
)

// MikesAPIReconciler reconciles a MikesAPI object
type MikesAPIReconciler struct {
    client.Client
    Scheme *runtime.Scheme
}

All CRDs and their accompanying controllers are written in Go. Notice how the import paths and package structure reflect the project layout—a common practice in many Kubernetes projects leveraging tools like KubeBuilder.

Implementing Network Policies

Network policies are essential for controlling ingress and egress traffic for pods. Below is an example NetworkPolicy configuration:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ingress-nginx
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginxdeployment
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - ipBlock:
            cidr: 172.17.0.0/16
            except:
              - 172.17.1.0/24
        - namespaceSelector:
            matchLabels:
              environment: redis
        - podSelector:
            matchLabels:
              role: database

This configuration specifies allowed ingress traffic based on IP blocks, namespace selectors, and pod selectors.

Extending Kubernetes with OpenShift Operators

OpenShift further extends Kubernetes with a range of operators and controllers that enhance platform capabilities. In the OpenShift UI, navigating to "Operators" takes you to the OperatorHub, where you can explore and install operators for various purposes including monitoring (such as the Datadog operator) and security (like the CrowdStrike operator).

When you select an operator, for example, the Datadog operator, you can proceed with the installation by choosing the namespace, update channel, and update approval options. Once the configuration details are set, clicking the install button deploys the operator to your system.

Operators streamline the management of complex applications on Kubernetes and OpenShift. Instead of writing custom controllers from scratch, you can utilize pre-built operators to extend your cluster’s functionality for specific environments such as Azure or AWS.

Summary

Controllers and Custom Resource Definitions (CRDs) are powerful extensions of the Kubernetes API that allow you to create new functionalities and manage applications at scale. While developing your own operators and controllers may pose challenges, tools such as KubeBuilder make the process more accessible. Alternatively, leveraging existing operators from the OperatorHub simplifies deployment and management, especially in environments like OpenShift.

For more in-depth information, consider checking out the following resources:

• Kubernetes Documentation
• OpenShift Documentation
• KubeBuilder Overview
• Docker Hub

Embrace the power of Kubernetes and OpenShift operators to streamline your cluster management and enhance your application's capabilities.