Shulou(Shulou.com)06/01 Report--

Based on Kubernetes ESaaS architecture and implementation details, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can get something.

Overview

ESaaS (ElasticSearch as a Service) is a product implementation of ElasticSearch on Kubernetes, which uses container virtualization and orchestration and scheduling systems such as Docker and Kubernetes to abstract ElasticSearch as a service on the CaaS (Container as a Service) platform to create and scale up a user-defined ElasticSerach cluster in seconds, and ensure high availability and data security.

Key components

ElasticSearch 2.x

Kubernetes 1.9

Docker 1.12.6

Pain points to be resolved:

The initialization and deployment cycle of the ES cluster is long, and it may take several days from applying for the server to delivery.

The degree of automation of the deployment process is not high, in the development and test environment, pure manual deployment, online semi-automatic deployment, often errors need to debug the environment.

The expansion of the cluster is also artificial, inefficient and easy to make mistakes.

ES servers are often faced with waste of resources.

The installation of various plug-ins is troublesome, and some nodes need to be restarted, so improper human operation will bring risks.

There is no perfect monitoring and alarm scheme for ES cluster and server.

No matching Kibana service is provided, so it is inefficient to deploy Kibana manually and interface with ES.

There is no resource isolation between ES clusters, physical isolation of rack cabinets, etc.

Without access to the log system, it is very inconvenient to view the system and ES cluster logs.

target

Cluster unified management Portal, providing ES cluster self-help application and cluster information Kanban

Provide user quota management

Expansion and reduction of capacity in seconds

Complete platform and ES cluster monitoring and alarm capabilities

Provides a unified entry for ES cluster configuration modification

Self-service deployment of peripheral plug-ins

Self-service security restart of nodes, etc.

Architecture highly available deployment architecture

Necessary explanation

ESaaS Portal provides an entrance for users to apply for ES cluster and operation and maintenance on the cloud. ESaaS performs relevant business logic capabilities, and finally calls back-end Kubernetes API to create and manage ES cluster. ESaaS Portal requires interfacing with rights management system to verify user login and control permissions.

In order to ensure the high availability of ElasticSearch clusters, in the development and test environment, the ES nodes of the same role (such as client/master/data) of the same ES cluster cannot be deployed on the same server; in the production environment, the above situations require cross-rack deployment.

ES clusters currently consider using local storage instead of distributed storage in Kubernetes.

The data node Pod of the ES cluster needs to mount two hostpath volume, namely, the data volume for storing data and the plugin volume for storing ES plugin, and the corresponding hostpath / es/$cluser-name/data/data and / es/$cluser-name/data/plugin on the server.

The master and client node Pod of the ES cluster need to mount a hostpath volume to store the plugin volume of the ES plugin, corresponding to the hostpath / es/$cluser-name/client (or master) / plugin on the server.

The ESaaS platform provides Apache httpd services for hosting common plug-ins, called ES Plugin Repository, and currently gives priority to hosting the jar type plugin. When an ES cluster installs jar plugins for one or some ES nodes, it downloads the plugin file from ES Plugin Repository to the corresponding / es/$cluser-name/client (or data,master) / plugin

Logical architecture

Necessary explanation

The deployment of data nodes for each ES cluster is managed by a Kubernetes StatefulSet

The deployment of master nodes for each ES cluster is managed by a Kubernetes Deployment, and a Kubernetes Headless Service is used as a reverse proxy for master nodes, so that the Headless Service Name corresponds to the IP address of each ES master nodes Pod in KubeDNS.

The deployment of client nodes for each ES cluster is managed by Kubernetes Deployment, and a Kubernetes NodePort Service is used as the reverse proxy for client nodes (after the number of subsequent ES clusters is large, consider using Ingress Nginx to proxy ES client), and each ES cluster exposes $Client-IP:$NodePort to the public.

The elasticsearch.yml of all nodes in the same ES cluster is configured using some of the following rules:

Cluster.name: "elasticsearch-$ {NAMESPACE}" node.name: "${POD_NAME}-${NAMESPACE}" network.host: ${POD_IP} # hosts fill in the Headless Service Name discovery.zen.ping.unicast.hosts of ES master: "es-$ {NAMESPACE}" will it help you to read the above? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.