Help Center/ Cloud Container Engine/ FAQs/ Workload/ Workload Exception Troubleshooting/ What Should I Do If a Workload Appears to Be Normal But Is Not Functioning Properly?
Updated on 2025-04-25 GMT+08:00

What Should I Do If a Workload Appears to Be Normal But Is Not Functioning Properly?

Symptom

A pod is in the Running state, but it is not functioning properly or the access result does not meet the expectations.

Possible Cause

There could be errors in your YAML files, including those related to pods, Deployments, and StatefulSets. Such errors include:

  • The image version is not updated. This could be due to using an incorrect image version or having both the old and new images as the latest version. In some cases, even if an image of the old version exists on the node, the new version is not pulled if the imagePullPolicy of the workload is set to IfNotPresent. As a result, the container continues to run with the old version of the image.
  • The environment variables are incorrectly configured. For example, if the word command is misspelled as commnd in the YAML file, the workload can still be created using that YAML file. However, when the container is running, it executes the default EntryPoint command from the image instead of the intended command.

Solution

  1. Check the pod configuration and verify if the container configuration within the pod aligns with the desired expectations. For details, see Checking Pod Configurations.
  2. To check whether a key in an environment variable is misspelled, perform the following operations: (The following takes the example of misspelling the word command as commnd to show how to identify spelling issues.)
    1. Before running kubectl apply -f, add --validate to it and then run the kubectl apply --validate -f XXX.yaml command. If you spelled command as commnd, you will see an error message similar to the following:
      I0805 10:43:25.129850   46757 schema.go:126] unknown field: commnd
      I0805 10:43:25.129973   46757 schema.go:129] this may be a false alarm, see https://github.com/kubernetes/kubernetes/issues/6842/pods/mypod
    2. Compare the pod.yaml file in the command output with the file used for creating the pod:
      kubectl get pods/$mypod  yaml > mypod.yaml
      $mypod specifies the name of the abnormal pod. You can run the kubectl get pods command to view the pod name.
      • If the mypod.yaml file has more lines than the pod file used for creation, then the created pod meets the expected configuration.
      • If some code lines are missing in the mypod.yaml file compared with those in the file used for creating the pod, it indicates a spelling error in the YAML file.
  3. View the pod logs and locate the fault based on the logs. For details, see Viewing Container Logs.
  4. Access the container through the terminal and check whether the local files in the container meet the expectation. For details, see Logging In to a Container.