Component Basic Operation
Basic Component Operation
Let’s first explain the basic operations that the component can perform:
|Build||The 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|
|Start||A component with at least one available build version can be started|
|Stop||All cluster resources are released when the component is stopped|
|Access||The running component can be accessed, if it is an HTTP component, it will jump to the URL, not HTTP|
|Web terminal||Enter the current component Web terminal control page, select the container to be controlled to open the container control terminal|
|Restart||The 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 application||The component can be flexibly adjusted to the application|
|Delete||Deleting 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.|
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:
|Components built from source code||Pull the latest source code, build component versions based on pre-identified language types and perform rolling upgrades|
|Component built from Docker image||Re-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 application||If 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:
|Properties||Support upgrades||Metadata (upgrade method)||Description|
|Dependency||Yes||Add||If the dependent component is in the same application, add the dependency; otherwise, no processing is performed|
|Port||Yes||Update, add||For port upgrade, you can update the existing port information, or add a new port; but you cannot delete the existing port|
|Storage||Yes||Add||For storage upgrades, only new storage can be added; existing storage cannot be deleted, or modified|
|Health Check||Yes||Update||For 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)|
|Mirror||Yes||Update||Directly change to a new mirror|
|Environment Variables||Yes||Add||Upgrade of environment variables, only supports adding new environment variables; you cannot modify or delete existing environment variables|
|Dependent storage||Yes||If the component of the dependent storage is in the same application, add the dependency; otherwise, no processing is performed|
|Is there a state type||No|
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:
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.
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.
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
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 127.0.0.1 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 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
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.
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
- Restart operation will interrupt the component
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 Agreement||Operations after clicking the access button|
|HTTP||The 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|
|TCP||Pop-up access information window|
HTTP Protocol Components
TCP Protocol Components
Copy the recommended access address to the browser to access