Skip to main content

Troubleshooting

This page describes how to resolve issues that may occur while using Deployflow.

Pod remains Pending​

After synchronization with Deployflow, a Pod may remain in Pending status and the application status may be displayed as Missing.

If the target cluster has no worker nodes, Pods cannot be scheduled. In this case, the event may show the no nodes available to schedule pods message.

▶️ Solution: Create a node pool in Kubernetes Engine or set the number of nodes in an existing node pool to at least 1, then check whether the Pod is scheduled again.

ImagePullBackOff occurs​

ImagePullBackOff may occur in a Pod deployed with Deployflow.

If you use a private Container Registry image, the image cannot be pulled when the target namespace does not have an image pull secret or the Deployment does not specify imagePullSecrets.

▶️ Solution: Create an image pull secret in the namespace where the Pod is deployed, and specify the secret name in imagePullSecrets of the Deployment.

Create Application button is disabled​

The [Create] button may be disabled on the application creation screen.

If required fields for application creation are missing, the [Create] button is not enabled.

▶️ Solution: Check whether application name, deployment cluster, namespace, source repository, source branch, deployment method, and deployment path are all entered.

Status is not updated after synchronization​

Status may not be updated immediately after synchronization.

The synchronization operation may be complete, but status lookup on the screen can be delayed.

▶️ Solution: Click [Refresh] to query the status again. If the status remains abnormal, check the failure reason in the Events and Logs tabs of the resource.

Manifest path cannot be found​

Deployflow may fail to find the manifest path.

The deployment path must be entered as a relative path from the repository root.

▶️ Solution: Enter the deployment path as a relative path from the repository root. For example, if the manifest is in the k8s directory of the repository, enter k8s.

Screen does not change after Blue/Green traffic switching​

After Blue/Green traffic switching, the screen may still show the existing version.

If traffic switching is not complete or the browser still has a previous response, the existing screen may continue to appear.

▶️ Solution: Check whether the deployment strategy status is Green Active, then refresh the browser with the same Service URL and connect again.

Service EXTERNAL-IP remains pending​

Among deployed resources, a LoadBalancer type Service may not receive an EXTERNAL-IP and may remain in the <pending> status.

If load balancer creation is delayed, quota is insufficient, or public IP settings are missing, EXTERNAL-IP can remain <pending>. This is likely an issue with the Kubernetes Engine (K8sE) settings connected to the target cluster, not an issue with Deployflow itself.

▶️ Solution: Wait 1 to 2 minutes and check the status again. If the Service requires a public IP, check whether openstack-internal-load-balancer: 'false' is applied and check Service events for load balancer creation failure messages. For Kubernetes Engine settings such as cluster and node status, see Kubernetes Engine troubleshooting.

Green Pod becomes CrashLoopBackOff​

In a Blue/Green deployment, a Green Pod may become CrashLoopBackOff.

The Pod may restart repeatedly due to an application error in the Green version or environment variable/secret configuration issues.

▶️ Solution: Check the failure reason in the Logs and Events tabs of the resource details. If you check locally, you can use kubectl logs and kubectl describe pod.