Component resource cleanup
The purpose of resource cleanup is to clean up the useless data on the disk and reduce the pressure on the disk. The objects to be cleaned up are mainly images that are no longer used and data generated by deleted components. Cleaned data includes: source code, slug packages, database metadata, logs, storage and mirroring.
source code
In the code detection phase, the corresponding source code will be cleaned up immediately after the detection is completed.
slug package
The components built from the source code will generate a slug package according to the source code before building into an image. This slug package is no longer needed after the image is built and will be cleaned up immediately. The slug package is located in /grdata/build/ tenant/{tenant_id}/slug/{service_id}, tenant_id and service_id are tenant ID and component ID respectively.
database metadata
The metadata of the component is stored in two databases, namely the region and the console. They store the component's environment variables, ports, health checks, resource configuration and gateway policies and other information; when you actively initiate the operation to delete the component, these two The corresponding data in the database will also be deleted.
log
The log includes event log and container log, event log , which is the log generated by the component construction, startup, update, stop and other operations; container log is the log output to the standard output when the component is running, such as access log, error log.
The event log cleaning policy is to keep the latest 30 and the last 30 days logs. The container log policy is to keep the last 7 days.
These log files are located in the
/grdata/download/log/directory.
storage
The storage is divided into local storage, shared storage and memory file storageThe local storage and shared storage will be persisted to the disk. When they are deleted in the console, they will not be deleted on the disk. , just delete its metadata in database You can no longer see the store in the console, in fact it is still on disk. For stateless components, its persistent file is located in /gradata/tenant /{tenant_id}/service/{service_id}/{volume name} ; For stateful components, its persistence file is located at /gradata/tenant/{tenant_id}/service/{service_id}/{pod name}/{volume name}.
So when will these stored persistent data be deleted? The answer is When component is deleted, when you actively delete a component, all its corresponding stored persistent data will be deleted.
mirror
Image cleaning is done by kubelet in Kubernetes. Kubelet's garbage collection function can clean up containers and images that are no longer in use. The frequency of kubelet garbage collection of containers is once every minute, and the frequency of garbage collection of images is every five minutes. once.For details, please check Kubernetes official documentation