Giriş
Açıklaması şöyle. Custom Resource ve Custom Controller kavramı vardır
The basic idea of a Kubernetes Operator is to extend the Kubernetes’s level-driven reconciliation loop and API set towards running stateful application workloads natively on Kubernetes. A Kubernetes Operator consists of Kubernetes Custom Resource(s) / API(s) and Kubernetes Custom Controller(s).
Açıklaması şöyle.
An Operator is packaged as a container image and is deployed in a Kubernetes cluster using Kubernetes YAMLs.
Custom Resource Nedir?
Açıklaması şöyle.
The Custom Resources represent an API that takes declarative inputs on the workload being abstracted and the Custom Controller implements corresponding actions on the workload. Kubernetes Operators are typically implemented in a standard programming language (Golang, Python, Java, etc.).
Açıklaması şöyle. Yani veri tabanı gibi şeyler Custom Resource oluyor
Once deployed, new Custom Resources (e.g. Mysql, Cassandra, etc.) are available to the end users similar to built-in Resources (e.g. Pod, Service, etc.). This allows them to orchestrate their application workflows more effectively leveraging additional Custom Resources.
Custom Resource, Kubernetes'e CRD metaPI kullanılarak tanıtılır. Açıklaması şöyle.
In order for the Custom Resources to be recognized in a cluster, they need to be first registered in the cluster using Kubernetes’s meta API of ‘Custom Resource Definition (CRD)’. The CRD itself is a Kubernetes resource.
Helm ile kullanmak
Örnek - Vitess- Register Custom Resource Definitions in Helm chart (and not in Operator code)
- Make sure Custom Resource Definitions are getting installed prior to the Operator deployment
- Define Custom Resource validation rules in CRD YAML
- Use values.yaml or ConfigMaps for Operator configurables
- Add Platform-as-Code annotations to enable easy discovery and consumption of Operator’s Custom Resources
Şöyle yaparız
git clone git@github.com:vitessio/vitess.gitcd vitess/examples/operatorkubectl apply -f operator.yaml
Hiç yorum yok:
Yorum Gönder