---
title: "Deployment troubleshooting"
slug: "k8s-troubleshoot-deploying"
updated: 2026-09-17T09:31:39Z
published: 2026-09-17T09:31:39Z
canonical: "guide.ncloud-docs.com/k8s-troubleshoot-deploying"
stale: true
---

> ## Documentation Index
> Fetch the complete documentation index at: https://guide.ncloud-docs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment troubleshooting

Available in VPC

You might run into the following problems when using Ncloud Kubernetes. Find out causes and possible solutions.

## Occurrence of ImagePullBackOff status when creating pods

When creating a pod, an ImagePullBackOff status occurs.

#### Cause

The ImagePullBackOff status means that the pod is unable to retrieve the image to use. You must identify the detailed causes.

#### Solution

- If the image name and tag are incorrect, you are unable to retrieve the image. Check the image name and tag.
- If you are retrieving an image from a private registry and authentication cannot be performed, you are unable to retrieve the image. Check whether a correct `imagePullSecrets` was used. If you are using the Container Registry service, see [Check and manage Container Registry information](/docs/en/container-ncr-1-3) when creating `imagePullSecrets`.
- You may not be able to use certain images that are restricted by DockerHub's [image download policy](https://docs.docker.com/docker-hub/download-rate-limit/). Use the paid subscription model or the private registry.
- In the case of a Kubernetes Cluster that uses a Private Subnet, you must have the outbound traffic enabled to use an external image. To enable outbound traffic:
  - NAT Gateway (Old)
    1. From the NAVER Cloud Platform console, navigate to **Menu** > **All Services** > **Networking** > **VPC** > **NAT Gateway(Old)**.
    2. Create a NAT Gateway.
    3. From the VPC environment of the NAVER Cloud Platform console, navigate to **Menu** > **All Services** > **Networking** > **VPC** > **Route Table**.
    4. Select the route table of the private subnet that needs Internet communication, and then click **[Routes settings]**.
    5. Add the route rules for external communication.
      - Destination: Enter the destination point’s public IP address in the CIDR format (for example, if the entire Internet is the destination point, enter 0.0.0.0/0).
      - Target Type: Select the next hop type to communicate with the destination point (NAT Gateway).
      - Target Name: Select the created NAT Gateway name.
    6. Click **[Create]**.
  - NAT Gateway (New)
    1. From the VPC environment of the NAVER Cloud Platform console, navigate to **Menu** > **All Services** > **Networking** > **VPC** > **NAT Gateway(New)**.
    2. Create a public NAT Gateway.
    3. From the VPC environment of the NAVER Cloud Platform console, navigate to **Menu** > **All Services** > **Networking** > **VPC** > **Route Table**.
    4. Set the network path to communicate through the NAT Gateway.
      - See the [Route table setting guide](/docs/en/networking-vpc-vpcdetailedroutetable).

## Intermittent failed DNS lookup and task delays in a specific pod

DNS lookup intermittently failed or took a long time in a specific pod.

#### Cause

This problem occurs when the image used by the corresponding pod has problems.

#### Solution

If DNS lookup failed or there is an issue with query processing, check the image used by the corresponding pod.

- [Alpine Linux-based container image](https://github.com/kubernetes/kubernetes/issues/56903)

```
spec:
...
  dnsConfig:
    options:
    - name: single-request-reopen
```
  - Apply [dnsConfig](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config) to resolve the issue.
- [BusyBox-based container image](https://github.com/kubernetes/kubernetes/issues/66924)
  - Use the BusyBox 1.28 based images to resolve the issue.

Using the above images may cause issues in DNS query processing. NAVER Cloud Platform is unable to help resolve technical issues concerning images, so use other container images or edit the DNS settings for such issues.

## Delayed resources deletion

Resources inside the cluster are not deleted or take a long time.

#### Cause

This is usually caused by the resource you are deleting having a finalizer set on it, or by dependencies between resources.

#### Solution

If the deletion of resources is delayed, check and modify the resources settings. Run the commands below.

```
$ kubectl edit [resource-type] [resource-name]
```

1. Check the resources' finalizer, and remove it if necessary.
2. If resources have ownerReferences settings, adjust the deletion order to resolve dependency issues.
  - [Finalizers](https://kubernetes.io/docs/concepts/overview/working-with-objects/finalizers/)
  - [Owners and Dependents](https://kubernetes.io/docs/concepts/overview/working-with-objects/owners-dependents/)

              Note

              

If you're still having trouble finding what you need, click on the feedback icon and send us your thoughts and requests. We’ll use your feedback to improve this guide.