Component Basic Operation

Basic Component Operation

Let’s first explain the basic operations that the component can perform:

Basic operationDescription
BuildThe build operation will trigger the component to obtain the latest code or mirror the new version of the build component from the build source.
By default, the rolling upgrade will be triggered after the successful build.
Update (rolling upgrade)The update operation will perform a rolling upgrade of the component instances running in the cluster with the latest component attribute configuration
StartA component with at least one available build version can be started
StopAll cluster resources are released when the component is stopped
AccessThe running component can be accessed, if it is an HTTP component, it will jump to the URL, not HTTP
Web terminalEnter the current component Web terminal control page, select the container to be controlled to open the container control terminal
RestartThe running component can be restarted. Under normal circumstances, we recommend using the update operation to complete the restart of the component. If any properties of the component have not changed, the update cannot be used.
Modify the applicationThe component can be flexibly adjusted to the application
DeleteDeleting a component is a dangerous operation, please proceed with caution. After the component is deleted, the persistent data will be retained for 7 days by default.

Build Operation

Applicable scenario: any state of the component

For different types of components, triggering the build operation has different meanings. The following table describes the different types of components:

Component TypeDescription
Components built from source codePull the latest source code, build component versions based on pre-identified language types and perform rolling upgrades
Component built from Docker imageRe-pull the image of the specified image address, build a new version of the component and perform a rolling upgrade
Components built from the Gridworkz Cloud applicationIf there is no updated version of the Gridworkz Cloud application, the build operation will remind the user that no action is required. If there are multiple updated versions, the user will be prompted to select the version number to be obtained. Obtain component media according to the selected version to generate a build version and perform a rolling upgrade
  • Dockerfile source code component is a service created by placing Dockerfile and required files in the code repository (Git/Svn) through source code.
  • After the build, if everything goes well, the component will automatically switch to the new version and go online. The build operation defaults and updates and upgrades. You can also set the process of not upgrading after the build in other settings.
  • The rolling upgrade process has no theoretical impact on multi-node components. For single-node components, if business-level health detection is normally configured, it can also be done without Affect the upgrade.
  • After the component is in the closed state, after triggering the build operation, if the build is normal, the platform will run the component.

Attributes Supported by Gridworkz Cloud Component Upgrade

When upgrading the cloud components, not all attributes support the upgrade; when upgrading, the processing methods of various attributes will be different. The details are shown in the following table:

PropertiesSupport upgradesMetadata (upgrade method)Description
Example optionsYesUpdate
Memory optionsYesUpdate
DependencyYesAddIf the dependent component is in the same application, add the dependency; otherwise, no processing is performed
PortYesUpdate, addFor port upgrade, you can update the existing port information, or add a new port; but you cannot delete the existing port
StorageYesAddFor storage upgrades, only new storage can be added; existing storage cannot be deleted, or modified
Health CheckYesUpdateFor the health check upgrade, modify the existing health check information, you cannot delete or add it (a component can only have one health check information)
MirrorYesUpdateDirectly change to a new mirror
Environment VariablesYesAddUpgrade of environment variables, only supports adding new environment variables; you cannot modify or delete existing environment variables
Startup ParametersYesUpdate
Dependent storageYesIf the component of the dependent storage is in the same application, add the dependency; otherwise, no processing is performed
Is there a state typeNo

Update Operation

Usage scenario: running components

When the component’s dependencies, storage, environment variables, characteristics, health monitoring and other operating attributes are changed, you must manually trigger an update operation to configure the latest attributes in the operating environment of the applied component. In this update process, rolling is used by default. The upgrade strategy upgrades component instances.

There are two types of control strategies for rolling upgrades:

Stateless Components

For stateless components, a disorderly start-and-stop strategy is adopted, that is, the running instance of the new version is started first, and the running instance of the old version is closed when it is in a healthy running state. It should be noted that this process will have multiple versions working at the same time. If your business components cannot tolerate multiple versions working at the same time, please use the restart strategy.

Stateful Components

For stateful components, an orderly shutdown and then stop strategy is adopted, that is, according to the running instance number, the instance is closed first and then the new version instance is started.

This kind of control is essential for components like database, so don’t deploy database components as stateless components.

Start Operation

Usage scenario: successfully constructed and closed components

The startup operation will start the last successfully built component version. After startup, you can see the detailed operation log of the platform scheduling and processing component in the Operation Log on the component overview page. When the scheduling is completed, the component will enter the startup phase. View the startup log of the component through the Log page.

Especially for the components that are started on Kato for the first time, you need to pay attention to the following points:

What should I do if the component startup or update timeout?

Currently Kato has determined a fixed timeout period for asynchronous tasks, so please note that the timeout is not a failure. You need to optimize the component configuration according to the actual situation. If there is a timeout, please follow the following path to troubleshoot:

  • Query component log to determine the startup of the component, if your component log is not output to stdout or stderr, please enter the component container Check your log. For example, for some Java components, if the allocated memory is insufficient, the startup will be very slow, or it may be found from the log whether the running environment of the component is normal, such as relying on the database, whether the database can be accessed normally, etc.
  • If the components built by source code do not enter the normal business startup process for a long time after startup, please optimize the code and ignore the redundant source code files to reduce the running code decompression time. Refer to [slugignore file usage](/docs/user-manual /component-create/language-support/etc/slugignore/)
  • Make sure the component listening address is not or localhost
  • If the component’s listening address is correct and it has been monitored normally, please check whether the configuration of Component Health Check is correct. Generally, the default configuration is likely to appear if the component has multiple ports Wrong question.
  • If the possible failures of the above components have been eliminated or the startup has timed out and have been in the startup state, please use the operation and maintenance tools grctl cluster and grctl service get <service_name> -t <tenant_name> to query the actual operation of the cluster and components status.

What should I do if the component runs abnormally?

Abnormal component operation refers to the abnormal exit of the component process. Generally, there are several reasons:

  • The component code is faulty and cannot operate normally
  • The component uses an unsupported image, such as a base operating system image, and cannot be run in the foreground.
  • Insufficient component memory allocation leads to OOM
  • The component health check configuration is incorrect, causing the component to fail the health check.

If this is the case, please handle your component configuration. If you exit Kato abnormally during component operation, it will automatically guard and restart your component

What should I do if the component cannot be accessed?

When the component cannot be accessed, please check the following reasons:

  • The component is not running normally, please confirm according to the running status and component log
  • The component port configuration is incorrect, the component port configuration must be consistent with the component’s real listening port
  • The component’s accessible port is not open. External component switch
  • The component is not configured with the correct and accessible domain name

Close Operation

Usage scenario: components in operation or abnormal operation

After triggering the shutdown operation, the component will first go offline from the application gateway or ServiceMesh network, and then shut down all running instances to release cluster resources.

Restart Operation

Usage scenario: components in operation or abnormal operation

After triggering the restart operation, the platform will shut down all existing component running instances, and start it after the shutdown is complete. If there is a shutdown timeout, the restart operation will exit, and the control of component startup will be given to the user.

  • Restarting the component will not update the component code or image, it needs to be distinguished from the build operation.
  • Restart operation will interrupt the component

Access Operation

Usage scenario: running component && (opened external component | internal component port)

For components of different protocols, the commands triggered after clicking the access button are different:

Component AgreementOperations after clicking the access button
HTTPThe browser opens a new window and opens the default domain name of the component. If multiple domain names are bound, a list of domain names will be displayed for users to choose
TCPPop-up access information window

HTTP Protocol Components

TCP Protocol Components

Copy the recommended access address to the browser to access