What Do I Do If an Event Indicating That the Container Failed to Be Restarted Occurs?
If the details page of a workload shows an event indicating that the container fails to be restarted, perform the following operations to locate the fault:
Check Item 1: Port Conflict
- Configure the kubectl. For details, see Using Native kubectl.
- On the CCI console, click the name of the workload whose container failed to restart. In the Pod List area of the workload details page, obtain the pod name.
- View the name of the failed container.
kubectl describe pod $name -n $namespace | grep "Error syncing pod failed to"
Figure 1 Viewing the name of the failed container
- View the logs of the container.
kubectl logs $podName -n $namespace -c $containerName
Solution: Re-create a workload and configure correct ports to avoid port conflicts.
Check Item 2: Workload Bugs
Check whether the workload startup command is correctly executed or whether the workload has a bug.
- Configure the kubectl. For details, see Using Native kubectl.
- On the CCI console, click the name of the workload whose container failed to restart. In the Pod List area of the workload details page, obtain the pod name.
- View the name of the failed container.
kubectl describe pod $name -n $namespace | grep "Error syncing pod failed to"
Figure 2 Viewing the name of the failed container
- View the logs of the container.
kubectl logs $podName -n $namespace -c $containerName
Fix the workload bugs indicated in logs.
Figure 3 Incorrect startup command configuration of the container
Solution: Re-create a workload and configure a correct startup command.
Check Item 3: Workload Health Check
If the liveness probing (a type of health check) is enabled for the workload and the number of health check failures exceeds the threshold, the workload details page shows the Kubernetes event Liveness probe failed: ...... and containers in the workload instance will be restarted. In this case, reconfigure the health check policies.
Check Item 4: Resource Type of the Namespace
Check whether the resource type selected during namespace creation is correct. General-computing and GPU-accelerated resources support x86 images.
- Log in to the CCI console and click the name of the workload whose container failed to restart. The workload details page is displayed.
- In Pod List, click View Logs in the Operation column of the abnormal pod.
- View the displayed error messages.
ERROR: exec failed: Exec format error
ERROR: hyper send process initiated event: error
Other Check Items
A workload fault may be caused by the failure to start the workload inside the container. In this case, you can manually run the startup command inside the pod to which the container belongs and rectify the fault based on the error message. The specific procedure is as follows:
- Configure the following startup command for the workload. In this way, the application will not be started after the pod is started and no operation will be performed.
- After the pod is started, run the kubectl exec command to enter the inside of the pod. Then, manually run the startup command inside the pod, and rectify the fault based on the error message.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot