search

anitsh / til

Today I Learn (til) - Github `Issues` used as daily learning management system for taking notes and storing resource links.
https://anitshrestha.com.np
MIT License
76 stars 11 forks source link

Kubernetes Operators #162

Open anitsh opened 4 years ago

anitsh commented 4 years ago

Prerequisite

Kubernetes Operators

Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or submit patches to the Kubernetes project code.

Customization approaches can be broadly divided into configuration, which only involves changing flags, local configuration files, or API resources; and extensions, which involve running additional programs or services. Extensions are software components that extend and deeply integrate with Kubernetes. They adapt it to support new types and new kinds of hardware.

Kubernetes is designed to be automated by writing client programs. Any program that reads and/or writes to the Kubernetes API can provide useful automation. Automation can run on the cluster or off it.

Kubernetes is designed to be automated by writing client programs. Any program that reads and/or writes to the Kubernetes API can provide useful automation. Automation can run on the cluster or off it. Automation generally works with any Kubernetes cluster, including hosted clusters and managed installations.

There is a specific pattern for writing client programs that work well with Kubernetes called the Controller pattern. Controllers typically read an object's .spec, possibly do things, and then update the object's .status.

A controller is a client of Kubernetes. When Kubernetes is the client and calls out to a remote service, it is called a Webhook.

The Kubernetes scheduler decides which nodes to place pods on.

Users often interact with the Kubernetes API using kubectl. Kubectl plugins extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies.

The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the API Access Extensions section.

The apiserver serves various kinds of resources. Built-in resource kinds, like pods, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called Custom Resources, as explained in the Custom Resources section. Custom Resources are often used with API Access Extensions.

The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the Scheduler Extensions section.

Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources.

The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. Network Plugins allow for different implementations of pod networking.

The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via Storage Plugins.

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.

The combination of a custom resource API and a control loop is called the Operator pattern. The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies

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 in a default Kubernetes installation. It represents a customization of a particular Kubernetes installation. However, many core Kubernetes functions are now built using custom resources, making Kubernetes more modular.

Custom resources can appear and disappear in a running cluster through dynamic registration, and cluster admins can update custom resources independently of the cluster itself. Once a custom resource is installed, users can create and access its objects using kubectl, just as they do for built-in resources like Pods On their own, custom resources simply let you store and retrieve structured data. When you combine a custom resource with a custom controller, custom resources provide a true declarative API.

A declarative API allows you to declare or specify the desired state of your resource and tries to keep the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user's desired state, and continually maintains this state.

You can deploy and update a custom controller on a running cluster, independently of the cluster's lifecycle. Custom controllers can work with any kind of resource, but they are especially effective when combined with custom resources. The Operator pattern combines custom resources and custom controllers. You can use custom controllers to encode domain knowledge for specific applications into an extension of the Kubernetes API

The CustomResourceDefinition API resource allows you to define custom resources. Defining a CRD object creates a new custom resource with a name and schema that you specify. The Kubernetes API serves and handles the storage of your custom resource. The name of a CRD object must be a valid DNS subdomain name.

This frees you from writing your own API server to handle the custom resource, but the generic nature of the implementation means you have less flexibility than with API server aggregation.

Resources

anitsh commented 3 years ago

Charmed Operator

https://ubuntu.com/blog/kubecon-colocated-events-operator-day-2021 https://github.com/jnsgruk/hello-kubecon https://github.com/canonical/operator https://charmhub.io/hello-kubecon https://gist.github.com/jnsgruk/53313fa93475ff13a396e292100a3024

anitsh commented 2 years ago

Kubernetes Operator - Another Definition

Operator are a method of packaging and managing Kubernetes-native applications and software.

image

An Operator is itself a piece of software that offers a specific application or workload on demand or as a service, as well as the automation that surrounds the ongoing management of that application or workload.

Main objective Kubernetes Operators codify operational knowledge about applications and software. They can automate both day 1 and day 2 operations and react to cluster events to deliver a complete life-cycle experience for users. Developers can define stepwise automation for all types of applications and for complex operations.

How do Operators work? Operators extend the capabilities of Kubernetes through custom resource definitions that describe applications. They can automate nearly any task, including those beyond Kubernetes’ core capabilities, to provide a complete life-cycle management experience.

Once deployed, Operators continuously monitor your cluster for predefined trigger events like upgrade requests, reconfigurations, and low performance levels. When a trigger event occurs, Operators react according to their programming.

They also reconcile configurations to ensure applications and workloads remain in the desired state.

Operators take more time, effort, and knowledge to create, but can automate all aspects of application life cycles. They are typically written by application developers or others that have a deep understanding of how the application works.

Operators require detailed logic and code and are often written in Go, Helm, or as Ansible playbooks. ► Required knowledge: Detailed application behavior throughout its life cycle, as well as all components that
are part of your application ► Time to create: Typically weeks to months

Use Operators for applications and software that: ► Require a complete, integrated life-cycle management experience, including automation of day 1 and day 2 tasks. ► Require timed or stepwise automation or conditional logic to manage life-cycle tasks. ► Require or benefit from event-based automation. ► Cannot be modeled in Helm charts without manual steps.

image

Operators delivers a complete life-cycle experience: