This post outlines details regarding Elasticsearch ECK Operator 1.3 deployment. It assumes that you have good understanding of Kubernetes and Elasticsearch.
If you have worked on Kubernetes, then you might remember one special thing, you kill a running pod, Kubernetes will spin another one. This is happening because of control loops. Control loop is a non-terminating loop that regulates the state of the system. Control Loop are managed by Kubernetes Controllers. Every Kubernetes Cluster run group of Controllers simultaneously. Each controller is responsible for a particular resource in the Kubernetes Cluster. Controller speaks to Kubernetes API to mimic the desired state until the current state becomes the desired state, according to the logic.
All controllers are packaged and shipped in a single daemon named kube-controller-manager.
A custom resource extends Kubernetes capabilities by adding new kinds of objects specific to your application requirement. By default, Kubernetes comes with multiple objects to support your deployment of containers e.g.: pod, deployment, job, etc. Using CRDs you can build your own object to perform specific tasks.
An operator is a way of packaging, deploying, and managing a Kubernetes application. Operators are the application-specific controllers.
Operator extends Kubernetes API to manage applications on behalf of users. It means instead of you manage the application components, Operator will manage that as per the requirement. Operators use the concept of custom resources to manage applications and their components.
Elastic Cloud on Kubernetes (ECK) extends the basic Kubernetes orchestration capabilities to support the deployment and management of Elasticsearch, Kibana, and APM Server on Kubernetes platform. It is built on the Kubernetes Operator.
You can deploy Elasticsearch on Kubernetes via multiple ways. Operator based mechanism is the most advanced way of doing that. It has simplified the deployment of Elasticsearch on Kubernetes.
This new release has a lot of improvements and features to watch out for. I am going to cover those which I find important to know. For full features please visit ECK release page.
Earlier Elasticsearch volumes were fixed at the point of deployment. In the case of size increase, existing deployment has to migrate to new. Elasticsearch volumes can be now dynamically expanded. In this case, if you want to update the volume, just update the manifest file. This feature totally depends upon your storage provisioner. Storage provisioner should support volume expansion. One more point, make sure you storage class to have property.
Earlier ECK operator deployment was performed using all in one YAML files.
> kubectl apply -f https://download.elastic.co/downloads/eck/1.3.0/all-in-one.yaml
Starting ECK 1.3.0 you can do it using the official Helm chart. This chart is in an experimental state but a good point to start.
> helm repo add elastic https://helm.elastic.co > helm repo update > kubectl create namespace elastic-system > helm install elastic-operator elastic/eck-operator -n elastic-system
If your Kubernetes Environment supports IPv6 then ECK has no issues now. This feature will be very useful where large K8s deployments are moving to IPv6.
In this release, ECK image for operator is based on Red Hat Universal Base Image(ubi-minimal), which is standard for OpenShift deployments. ECK is the certified operator on OperatorHub now.
In Helm Chart values.yaml, you can configure timeout to ECK Operator as well now. This can help in situations where ECK operator takes time to respond because of any ongoing platform issues.
That’s all for this post. In the next post, I will cover steps to deploy Elasticsearch/Kibana using operator.
Keep Learning and Stay Safe and Secure :)
Ref to Medium article