Advanced configuration
When you create an application service, you can enable advanced configuration for the pod template to optimize performance and increase flexibility. This topic describes the advanced configuration settings for pod templates.
hostNetwork configuration
When you use hostNetwork, mount a maximum of one pod to a node to avoid port listener conflicts.
In some scenarios, you may need to change the pod network from the container network to the host network. This can help resolve network connectivity issues.
If you use hostNetwork for network configuration, the pod IP address is the same as the node IP address after the application service is published.
Environment variables
You can configure environment variables for a pod as key-value pairs. This adds environment flags or passes configurations to the pod. The variables are passed to the application process when the container starts. For example: USER=tester. For more information, see Pod variable.
The following table describes the parameters.
Parameter name | Description |
|---|---|
Source | The source of the environment variable configuration. Valid values:
|
Variable name | The name of the environment variable. Note The name must consist of letters, digits, underscores (_), hyphens (-), or periods (.), and cannot start with a digit. |
Variable value/Variable reference | Configure a value or reference based on the selected source.
|
Volume configuration
You can configure the volumes that the container uses. Currently, you can only mount directories from the host where the container resides.
The following table describes the parameters.
Parameter Name | Description |
|---|---|
Type | The supported types are:
For more information, see Volumes. |
Permission | Supports Read/Write and Read-only. |
Container directory | The path of the volume in the container. |
Host directory/Configuration item reference/PVC name | Set the corresponding host directory or configuration item reference based on the selected volume type.
|
subPath/subPathExpr | Enter the subPath or subPathExpr name to specify a subpath within the referenced volume instead of its root. After the configuration is complete, existing files in the container directory are not overwritten. |
Health check configuration
A health check periodically checks the health of a container based on your configuration while the container is running. If you do not configure a health check, the container cannot detect business exceptions and will not automatically restart to recover the service. This may affect normal business operations.
Two check mechanisms are available: Readiness Probe and Liveness Probe. For more information, see Kubernetes Probe.
Readiness Probe: Checks if the container is ready to accept traffic.
If the check fails, the cluster blocks requests to the container.
If the check succeeds, access to the container is enabled.
Liveness Probe: Checks if the container is running normally. If the check fails, the cluster restarts the container.
The following table describes the parameters for Readiness Probes and Liveness Probes.
Parameter name | Description |
|---|---|
Check method |
|
Run a command | Required when Check method is set to HTTP Get method or Execute command in container.
|
Access port | Required when Check method is set to TCP Socket port or HTTP Get method.
|
Initial Check Delay | initialDelaySeconds. The number of seconds to wait after the container starts before the first probe is executed. The default value is 3 seconds. |
Timeout | timeoutSeconds. The probe timeout period. The default value is 1 second. The minimum value is 1 second. |
Health Check Interval | periodSeconds. The interval at which the probe is executed. The default value is 10 seconds. The minimum value is 1 second. |
Healthy Threshold | The minimum number of consecutive successful probes required to consider the container healthy after a failure. The default value is 1. The minimum value is 1. |
Unhealthy Threshold | The minimum number of consecutive failed probes required to consider the container unhealthy after a success. The default value is 3. The minimum value is 1. |
Lifecycle event callback configuration
You can add lifecycle event callbacks for the container. The callbacks are executed after the container starts and before it stops.
The following table describes the parameters for Post Start and Pre Stop.
Parameter | Description |
|---|---|
Callback method | Supports Execute command in container and HTTP GET method. |
Access path | Required when Callback method is set to HTTP Get method. Enter the access path, such as |
Access port | Required when Callback method is set to HTTP Get method. Enter an access port from 1 to 65535. |
Execute Command | Required when Callback method is set to Execute command in container. Enter the command to execute, such as |
Simple Log Service configuration
You can configure Simple Log Service. You can select an existing Logstore or create a new one.
The first time you use the Simple Log Service configuration feature, go to the Simple Log Service console to enable and configure indexes. For more information, see Configure indexes.
The following table describes the parameters.
Parameter name | Description |
|---|---|
Logstore | A Logstore is created in Simple Log Service to store the collected logs. Select an existing Logstore. If no Logstore is available, click Create Logstore to create one. |
Log type | Container text log. |
Path | Collects logs from a specified path in the container. For example: |