Elastic Cloud on Kubernetes.
El Impresionante K8s Operator de Elasticsearch
Intro: Porque Debería Usar ECK ?
En general, dentro de cualquier clúster de Kubernetes, la instalaciones mediante el uso de operators se han ido convirtiendo en el estándar para gestionar deployments y configuraciones de objetos custom (es decir objetos no contemplados en la API nativa de K8s) y también claro para automatizar sus ciclos de vida y operarlos en el día a día.
El esquema de funcionamiento de cualquier K8s Operator es prácticamente el mismo, se instalan Custom Resources Definitions (CRD) que básicamente nos permiten extender la API de Kubernetes dentro de nuestro cluster, y luego se levanta un Controller también personalizado que será el encargado de “operar” sobre estos recursos personalizados.
En el caso de Elastic Cloud on Kubernetes o “ECK”, este operador nos permite automatizar el proceso de gestión de un cluster de Elasticsearch con absolutamente todo su set de configuración y algunos otros objetos satélites miembros de su ecosistema (kibana, beats, autoscalers y más), por nombrar algunas de las otras ventajas concretas:
- Gestión de múltiples instalaciones de Elasticsearch
- Gestión de despliegues de Kibana y APM
- Actualizaciones de versión sencillas, rápidas y masivas (en caso de múltiples clusters)
- Automatización y control de la capacidad del clúster y escalado de recursos
- Control de la configuración del clúster
- Cambios de topología de clúster seguros (por ej incrementar data nodes sin downtimes)
- Escalado dinámico de almacenamiento (siempre que tengamos un SC que lo soporte en nuestro k8s cluster)
- Gestión de IndexTemplates, ILM, SLM y snapshot repos
- Gestión de certificados TLS
- Gestión de configuración de nodos y parámetros de cada nodo
- Actualizaciones seguras de Keystores
Instalando CRDs y Operator
Hay que instalar los CRDs y el Operator, en ese orden, ya que el operator no arranca sin tener preconfigurados los CRDs, la versión de ECK que utilizamos a fecha de creación de este post es la 2.7.0 y las versiones de ES (Elasticsearch) desplegadas fueron la 8.5.0 y la 8.7.0 (latest), vamos a instalar ambas cosas con los comandos:
$ kubectl create -f https://download.elastic.co/downloads/eck/2.8.0/crds.yaml
$ kubectl apply -f https://download.elastic.co/downloads/eck/2.8.0/operator.yaml
NOTA: el deploy manual con kubectl es solo con fines de prueba y primeros pasos con ECK, para el uso de esto en Prod Envs se recomienda automatizar todo el proceso de instalación, el uso de ECK se adapta perfectamente al modelo Gitops, de hecho en producción lo he instalado en 2 empresas distintas, una instalación utilizando ArgoCD con Kustomize para deployar a GKE (Google Cloud K8s svc) y otra utilizando ArgoCD con Helm para deployar a EKS (AWS K8s svc), traten de seguir el camino Gitops siempre que puedan.
Objetos Custom Disponibles:
Si finalizan la instalacion correctamente, tendran la posibilidad de manejar estos nuevos objetos de API dentro de su cluster:
NAME SHORTNAMES APIVERSION NAMESPACED KIND
agents agent agent.k8s.elastic.co/v1alpha1 true Agent
apmservers apm apm.k8s.elastic.co/v1 true ApmServer
elasticsearchautoscalers esa autoscaling.k8s.elastic.co/v1alpha1 true ElasticsearchAutoscaler
beats beat beat.k8s.elastic.co/v1beta1 true Beat
elasticsearches es elasticsearch.k8s.elastic.co/v1 true Elasticsearch
enterprisesearches ent enterprisesearch.k8s.elastic.co/v1 true EnterpriseSearch
kibanas kb kibana.k8s.elastic.co/v1 true Kibana
elasticmapsservers ems maps.k8s.elastic.co/v1alpha1 true ElasticMapsServer
stackconfigpolicies scp stackconfigpolicy.k8s.elastic.co/v1alpha1 true StackConfigPolicy
Probemos el Operator: Instalando Elasticsearch
El despliegue de un cluster de Elasticsearch usando ECK se realiza a través de la definición del CR (custom resource) Elasticsearch, este acepta todas las configuraciones permitidas en el clásico archivo de configuración elasticsearch.yml, aunque las configuraciones básicas están claras en la documentación oficial de Elastic, para las configuraciones avanzadas se requiere recurrir a pruebas y a usuarios de la comunidad para tener un poco más claro algunos errores que surgen al desplegar cosas distintas a la “quickstar” que nos muestra la doc oficial.
Probemos la potencia de este operator instalando un cluster de Elasticsearch con 3 nodos maestros y 3 nodos de datos agrupados por temperatura de datos:
apiVersion: elasticsearch.k8s.elastic.co/v1
kind: Elasticsearch
metadata:
name: eck-post
namespace: elastic-system
spec:
version: 8.7.0
nodeSets:
- name: master-nodes
count: 3
config:
node.store.allow_mmap: false
node.roles: ["master"]
- name: data-hot-nodes
count: 1
config:
node.store.allow_mmap: false
node.roles: ["data_hot", "data_content"]
- name: data-warm-nodes
count: 1
config:
node.store.allow_mmap: false
node.roles: ["data_warm", "data_content"]
- name: data-cold-nodes
count: 1
config:
node.store.allow_mmap: false
node.roles: ["data_cold", "data_content"]
Vamos con Kibana
El despliegue de la herramienta de visualización Kibana es bastante sencillo, y también bastante versátil en cuanto a su conexión con el clúster Elasticsearch destino:.
- Pueden configurar Kibana para conectarse directamente a un clúster creado con ECK Operator en el mismo clúster K8s.
- Pueden configurar Kibana para conectarse a un clúster desplegado con ECK Operator pero que esté en un clúster externo.
- Puede configurar Kibana para conectarse a un clúster externo que no está desplegado con ECK Operator.
Vamos a instalar Kibana con el siguiente manifest, en donde simplemente vamos a referenciar a que cluster se tiene que conectar utilizando simplemente el nombre de nuestro CR creado previamente:
apiVersion: kibana.k8s.elastic.co/v1
kind: Kibana
metadata:
name: eck-kibana
namespace: elastic-system
spec:
version: 8.4.0
count: 1
elasticsearchRef:
name: eck-post
namespace: elastic-system
Checkeando…
Al finalizar nuestro get pods debería tener esta facha:
o sea por si no se dieron cuenta lo que acaba de pasar, levantamos EK (Elasticsearch y Kibana) con 6 nodos ES contemplando temperatura de datos, en DOS minutos, ECK sos un crack!!!
ahora armamos un ingress object apuntando al kibana y voilà:
Stack Config Policy (SCP) - LO MEJOR DE USAR ECK
Stack Configuration Policies o (SCP) es un potente CR que concentra prácticamente todas o la mayoría de las configuraciones necesarias para operar nuestro cluster de Elasticsearch en el día a día y sus configuraciones a corto, mediano y largo plazo, algunas de las configuraciones son:
- indexLifecyclePolicies (ILM)
- indexTemplates
- ingestPipelines
- securityRoleMappings
- snapshotLifecyclePolicies (SLM)
Los que alguna vez lidiaron con instalaciones, o incluso solamente con la operación de un cluster Elasticsearch saben que tener un objeto que concentre todas estas configuraciones es un gran tesoro, ya que se pueden olvidar de esas interminables gestiones por API a traves de terminal o del dev-tool de Kibana etc, les dejo un pequeño ejemplo de este hermoso CR:
apiVersion: stackconfigpolicy.k8s.elastic.co/v1alpha1
kind: StackConfigPolicy
metadata:
name: post-scp
namespace: elastic-system
spec:
resourceSelector:
matchLabels:
env: blogenv
secureSettings:
- secretName: "blog-secret"
elasticsearch:
clusterSettings:
indices.recovery.max_bytes_per_sec: "100mb"
snapshotRepositories:
test-repo:
type: gcs
settings:
bucket: gcs-blog
snapshotLifecyclePolicies:
test-slm:
schedule: "0 1 2 3 4 ?"
name: "<blog-snap-{now/d}>"
repository: blog-repo
config:
indices: ["*"]
ignore_unavailable: true
include_global_state: false
retention:
expire_after: "7d"
min_count: 1
max_count: 20
Fuente
Material Extra: Curso “Devops en 5 Pasos” Disponible en Udemy
Temas:
- Docker
- Kubernetes
- MultiCloud Orientado a Contenedores (AWS - Azure - GCP)
- IaC (Terraform, Cloud Formation, ARM Templates, Cloud Resource Manager)
- CI/CD Pipelines (GitlabCI, Azure Devops, CircleCI)
Descripción completa: Detalle y enlaces del curso
