Plug-in Production

This article mainly introduces the plug-in design and plug-in creation process. It allows users to have a certain understanding of Kato plug-ins and be able to make simple plug-ins.

Plug-in System Design

Kato’s plug-in system abstraction focuses on the business level of the platform, and the theoretical foundation is derived from the pod mechanism of Kubernetes and part of the container concept. The process of abstracting kubernetes container orchestration at the platform business level and transforming it into a user-friendly Kato plug-in product is convenient for users to use without understanding the principles of Kubernetes.

Design Principles

The design of the Kato plug-in system follows the principles of easy to understand and easy to use:

Easy to Understand

In the Kato plug-in system, the process of plug-in use is the process of combining the main container with init or sidecar containers. The principle is to arrange the plug-in container in the form of a sidecar container (mostly) into the pod of the main application, sharing the main application container Network and environment variables, so you can plug-in to achieve some additional functions, such as traffic analysis of the main application.

Init Container

A pod can encapsulate multiple containers and the application runs in these containers; at the same time, the pod can have one or more init containers, which are started before the application container starts. If the init container of a pod fails to start and run, Kubernetes will continue to restart the pod until the init container starts and runs successfully. Of course, we can set the restartPolicy value of the pod to Never to prevent it from restarting.

Sidecar Container

Taking advantage of the ability of containers in pods to share storage and network, sidecar containers can be extended and enhanced the “main” container, coexist with it and make it work better.

Easy to Use

The easy-to-use principle of Kato plug-in system is embodied in the aspects of class application, binding use, and unique variable scope.

Class Application

The Kato plug-in system has designed a life cycle similar to that of an application for plug-ins, including creation, enabling, and closing modes, which are consistent with the user’s habit of operating applications on the Kato platform. At the same time, the Kato plug-in system simplifies the type of plug-in creation and supports creation based on docker image and dockerfile. Creating plug-ins is easier than creating applications.

The plug-in creation process design is shown in the following figure:

It should be noted that when a plug-in version is fixed, its memory, version information, and plug-in variables can no longer be modified. These elements only affect the current plug-in version. When you need to modify the plugin variables and other elements, you can rebuild the plugin and repeat the creation process.

After the creation is complete, the user can set specific plug-ins. Currently, variables, whether plug-ins are valid or not, and memory settings can be set. The memory limit will be limited when the pod is created, and the plugin variable validation and real-time modification will continue to be introduced below.

Unique Variable Scope

The variables injected into the container are designed to have two types: shared variables and plugin variables.

Common variables are the variables of the main container. In order to allow the plug-in to participate in or even extend the functions of the main application, the environment variables of the main application are injected into the plug-in container during the pod creation process; the plug-in variables are only used inside the plug-in container to prevent plug-ins The variables are repeated and mixed.

Plugin Configuration

The plug-in information is divided into two parts, Basic version information and Configuration group management. Specify the build source of the plug-in and the configuration of the plug-in variables respectively.

Version Basic Information

The version information specifies the installation source of the plug-in, plug-in type and minimum memory limit.

Installation source

Kato provides two installation sources: Mirror and Dockerfile. When using mirroring, provide the mirroring address. When using Dockerfile file, provide the project source code address.

Plug-in type

The plug-in types include entry network, export network, export and entry shared governance network, performance analysis, initialization type and general type.

The four plug-in types of Entry Network, Export Network, Export Entrance Common Governance Network and Performance Analysis have Kato’s default support and are used as the default plug-in types. When creating a new plug-in, users can use two completely open types, initial type and general type.

Plug-in Variable Configuration

Plug-in variables include dependent metadata type, injection type and configuration item settings

Plug-in variables are set in the way of configuration management group. The settings of plugin variables are different between different configuration management groups. The settings of plugin variables include dependency metadata type, injection type and configuration item.

Depends on metadata type

Depending on the metadata type, you can choose from three options: not dependent, component port, and downstream component port.

When making network management and plug-ins, you can use component ports and downstream component ports to monitor them to meet the needs of network management. The general type and initialization type plug-ins are not dependent on default use.

Injection type

When the dependent metadata type is not dependent, the injection types include environment variable and active discovery. Users can use environment variables to set configuration items, or use active discovery to dynamically set configuration items.

Configuration items

The configuration item supports setting protocol and parameter type.

The purpose of protocol setting is to support different port protocols. After the configuration in the configuration item sets the protocol, if it is inconsistent with the protocol of the listening port, the configuration cannot be performed, and naturally it cannot take effect during use.

The parameter type supports three types: string, single selection and multiple selection, providing a wealth of parameter configuration for selection when using the plug-in. If the parameter type is single-selected, when using the plug-in to configure the parameters, you can select the required value from the set value.

Plug-in Production

Here takes the default plugin Ali Cloud Log Service Collection Plugin as an example to introduce how to make a plugin.

Refer to the log collection configuration template officially provided by Alibaba Cloud:

apiVersion: batch/v1
kind: Job
  name: nginx-log-sidecar-demo
  namespace: default
      name: nginx-log-sidecar-demo
      restartPolicy: Never
      -name: nginx-log-demo
        command: ["/bin/mock_log"]
        args: ["--log-type=nginx", "--stdout=false", "--stderr=true", "--path=/var/log/nginx/access.log", "--total -count=1000000000", "--logs-per-sec=100"]
        -name: nginx-log
          mountPath: /var/log/nginx
      ##### logtail sidecar container
      -name: logtail
        # more info:
        # this images is released for every region
        # when recevie sigterm, logtail will delay 10 seconds and then stop
        -/usr/local/ilogtail/ 10
          initialDelaySeconds: 30
          periodSeconds: 30
            memory: 512Mi
            cpu: 10m
            memory: 30Mi
          ##### base config
          # user id
          -name: "ALIYUN_LOGTAIL_USER_ID"
            value: "${your_aliyun_user_id}"
          # user defined id
            value: "${your_machine_group_user_defined_id}"
          # config file path in logtail's container
          -name: "ALIYUN_LOGTAIL_CONFIG"
            value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
          ##### env tags config
          -name: "ALIYUN_LOG_ENV_TAGS"
            value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
          -name: "_pod_name_"
          -name: "_pod_ip_"
                fieldPath: status.podIP
          -name: "_namespace_"
                fieldPath: metadata.namespace
          -name: "_node_name_"
                fieldPath: spec.nodeName
          -name: "_node_ip_"
                fieldPath: status.hostIP
        -name: nginx-log
          mountPath: /var/log/nginx
      ##### share this volume
      -name: nginx-log
        emptyDir: {}

The template is divided into two containers, one is the log generation service and the other is the log collection service. The two realize shared storage by mounting the nginx-log storage at the same time, so that the log collection service can collect logs.

In addition to the mirror provided by the log collection service, environment variables such as ALIYUN_LOGTAIL_USER_ID, ALIYUN_LOGTAIL_USER_DEFINED_ID, ALIYUN_LOGTAIL_CONFIG, ALIYUN_LOG_ENV_TAGS, etc. need to be specified to configure the log collection service.

With the above template, the idea of ​​building a plug-in will be very clear. First, you need to create a new plug-in by mirroring, and secondly, set the required environment variables in advance.

Plugin build

On the plug-in page of the team management page, select the new plug-in, the installation source selects mirror, fill in the mirror address in the template, and use the general type plug-in type to build the plug-in.

Plug-in variable setting

In the plugin management page, add the plugin configuration management group. Add the environment variables in the template to the configuration management group of the plug-in in the form of environment variable and use the string parameter type. After the plug-in is installed and activated, you can configure these environment variables to make it Take effect in the plugin container.

Such a log collection plug-in is completed, and it can be installed in a component that generates log files to collect logs on the Alibaba Cloud platform for testing.

For the use of plug-ins, please refer to Best Practices chapter.

Common Problems

Failed to build the plugin

Pull image, source code build

When the plug-in is built, it will print the build log to the page. The log analysis can be used to pull the mirror image, or the source code compilation problem during the source code build process.

The plug-in cannot be run after installation

Check the image or Dockerfile of the plug-in to make sure it can run independently, or you can use the log page in the component management page to troubleshoot the reason why the plug-in cannot run through real-time logs.