Hard Drives Monitoring Automation Approach for Kubernetes Container

Hard Drives Monitoring Automation Approach for Kubernetes Container Orchestration System A. S. Shemyakinskaya I. V. Nikiforov 4 -th year student Professor assistant, Ph. D Peter the Great St. Petersburg Polytechnic University 29. 05. 2020

Introduction • Container Orchestration (COs) systems are gaining in popularity for application deployment • Applications often need to store some data on hard drives, such as a database, log files, etc. • Container orchestration systems need to know the state of bare-metal drives in order to create volumes. • System administrators and administrators of container orchestration systems need to monitor the state of hard drive in the system. Therefore, the task of hard drive monitoring in the system is relevant 2

Existing approaches “+” - the software meets the criterion “-” - the software does not meet the criterion Software Cross platform Hardware independence GUI Free license Kubernetes integration smartctl + + - ipmi + - - lsblk - + - Considering the approaches disadvantages, the implementation of Kubernetes “operator” of the disk monitoring tool is proposed. 3

Containerization App 1 App 2 App 3 App 4 VM 1 VM 2 VM 3 App App Guest OS Hypervisor Docker Engine Host OS Hardware Containerization Virtualization Modern applications include many containers and distributed servers require complex management and deployment of applications, there is a need for container orchestration systems. 4

Container orchestration systems Kubernetes is the open source software needed to manage and deploy a Docker container cluster. Master node Worker nodes 5

Operator pattern GET apis / GROUP / VERSION / RESOURCETYPE provides information about the resource type "RESOURCETYPE" with the version of "VERSION" and the group "GROUP". GET apis/crd. com/v 1 alpha/example/ 6

Proposed approach ~# kubectl get disks NAME disk-node 1 -dev-sda disk-node 2 -dev-sdb disk- node 3 -dev-sdc disk- node 4 -dev-sdb NODE node 1 node 2 node 3 node 4 HEALTH_GOOD HEALTH_UNKNOWN HEALTH_FAILED The use of the “operator” allows to reduce the time of analyzing disk information, working with the Kubernetes API, which allows to take advantage of Kubernetes. 7

Implementation: Architecture Implementation of an operator pattern for Kubernetes container orchestration system. The proposed approach is better, because of efficient and automatic provision of hard drives state without creating additional load on the Kubernetes cluster. 8

Implementation • Programming language: Golang Code generation type Disk. Spec struct { Disk. ID string `json: "disk_id"` Node. ID string `json: "node_id"` Path string `json: "path"` Capacity int `json: "capacity"` Serial. Number string `json: "serial. Number"` Driver. Health string `json: "drive. Health"` } Example of Disk object 9

Implementation: Building docker image Dockerfile is a text document that contains all the commands that a user can call on the command line to build an image FROM registry. access. redhat. com/ubi 7/ubi-minimal: latest ENV OPERATOR=/usr/local/bin/operator USER_UID=1001 USER_NAME=operator # install operator binary Command to build COPY build/_output/bin/operator ${OPERATOR} docker image COPY build/bin /usr/local/bin RUN /usr/local/bin/user_setup ENTRYPOINT ["/usr/local/bin/entrypoint"] USER ${USER_UID} 10

Implementation: Deploying in cluster Helm is a Kubernetes package (charts) management tool. • operator - release name. • charts/operator - path to the directory with configuration files (charts). Configuration file example: api. Version: apps/v 1 kind: Deployment metadata: name: operator spec: replicas: 1 … template: spec: … service. Account. Name: operator containers: - name: operator image: {{. Values. image. repository }}: {{. Values. image. tag }} command: - operator 11

Results TimeApproach Smartctl utility ipmi (IDRAC) Using operator 5 7 5 10 2 2 60 36 28 12

Conclusion • Investigated approaches to monitoring the status of disks • A drive monitoring operator architecture for kubernetes has been proposed • The software was implemented and tested on a real system (4 nodes, each has 4 hard drives: SSD 112 Gb and 3 HDD 8 Tb) • A comparative analysis of the proposed concept with existing approaches was conducted 13