[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Kubernetes](../index.md) > FAQ > Troubleshooting

# Troubleshooting in Managed Service for Kubernetes

* [Error creating a cluster in a different folder's cloud network](#neighbour-catalog-permission-denied)

* [Namespace fails to delete and remains _Terminating_](#namespace-terminating)

* [I am using Yandex Network Load Balancer together with an ingress controller. Why are some of my cluster's nodes _UNHEALTHY_?](#nlb-ingress)

* [Why does the newly created PersistentVolumeClaim remain _Pending_?](#pvc-pending)

* [Why does my Managed Service for Kubernetes cluster fail to start after I update its node configuration?](#not-starting)

* [Error updating ingress controller certificate](#ingress-certificate)

* [Why is DNS resolution not working in my cluster?](#not-resolve-dns)

* [Creating a node group with the CLI results in a parameter conflict. How do I fix it?](#conflicting-flags)

* [Error connecting to a cluster using kubectl](#connect-to-cluster)

* [Errors connecting to a node over SSH](#node-connect)

* [How do I provide internet access to my Managed Service for Kubernetes cluster nodes?](#internet)

* [Why cannot I choose Docker as the container runtime?](#docker-runtime)

* [Error connecting a GitLab repository to Argo CD](#argo-cd)

* [Traffic loss when deploying app updates in a cluster with Yandex Application Load Balancer](#alb-traffic-lost)

* [System time displayed incorrectly in the Linux console, as well as in container and Managed Service for Kubernetes cluster pod logs](#time)

* [What should I do if I deleted my Yandex Network Load Balancer or its target groups that were automatically created for a LoadBalancer service?](#deleted-loadbalancer-service)

* [Error connecting a Yandex Compute Cloud VM instance as an external Managed Service for Kubernetes node](#vm-as-external-node)

This section describes typical issues you may encounter while using Managed Service for Kubernetes and gives troubleshooting recommendations.

#### Error creating a cluster in a different folder's cloud network {#neighbour-catalog-permission-denied}

Error message:

```text
Permission denied
```

This error occurs when the [resource service account](../security/index.md#sa-annotation) has no required [roles](../../iam/concepts/access-control/roles.md) in the [folder](../../resource-manager/concepts/resources-hierarchy.md#folder) that contains the [cloud network](../../vpc/concepts/network.md#network) selected when creating the cluster.

To create a [Managed Service for Kubernetes cluster](../concepts/index.md#kubernetes-cluster) in a cloud network of another folder, [assign](../../iam/operations/sa/assign-role-for-sa.md) the resource [service account](../../iam/concepts/users/service-accounts.md) the following roles in that folder:
* [vpc.privateAdmin](../../vpc/security/index.md#vpc-private-admin)
* [vpc.user](../../vpc/security/index.md#vpc-user)

To use a [public IP address](../../vpc/concepts/address.md#public-addresses), also [assign](../../iam/operations/sa/assign-role-for-sa.md) the [vpc.publicAdmin](../../vpc/security/index.md#vpc-public-admin) role.

#### Namespace fails to delete and remains _Terminating_ {#namespace-terminating}

This issue occurs when your [namespace](../concepts/index.md#namespace) contains stuck resources that the namespace controller cannot delete.

To fix it, delete the stuck resources manually.

{% list tabs %}

- CLI

  If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install).

  The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id <folder_ID>` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

  1. [Connect to the Managed Service for Kubernetes cluster](../operations/connect/index.md).
  1. Get the list of resources remaining in the namespace:

     ```bash
     kubectl api-resources --verbs=list --namespaced --output=name \
       | xargs --max-args=1 kubectl get --show-kind \
       --ignore-not-found --namespace=<namespace>
     ```

  1. Delete the listed resources:

     ```bash
     kubectl delete <resource_type> <resource_name> --namespace=<namespace>
     ```

  If the namespace is still in the `Terminating` status and cannot be deleted, delete it forcibly using `finalizer`:
  1. Run a local proxy to the Kubernetes API:

     ```bash
     kubectl proxy
     ```

  1. Delete the namespace:

     ```bash
     kubectl get namespace <namespace> --output=json \
       | jq '.spec = {"finalizers":[]}' > temp.json && \
     curl --insecure --header "Content-Type: application/json" \
       --request PUT --data-binary @temp.json \
       127.0.0.1:8001/api/v1/namespaces/<namespace>/finalize
     ```

    We do not recommend deleting the namespace with the `Terminating` status using `finalizer` right away, as this may cause the stuck resources to remain in your Managed Service for Kubernetes cluster.

{% endlist %}

#### I am using Yandex Network Load Balancer together with an ingress controller. Why are some of my cluster's nodes _UNHEALTHY_? {#nlb-ingress}

This is normal behavior for a [load balancer](../../network-load-balancer/concepts/index.md) with `External Traffic Policy: Local` enabled. Only the [Managed Service for Kubernetes nodes](../concepts/index.md#node-group) whose [pods](../concepts/index.md#pod) are ready to handle user traffic get the `HEALTHY` status. All other nodes are labeled as `UNHEALTHY`.

To check the policy type of a load balancer created using a `LoadBalancer` service, run this command:

```bash
kubectl describe svc <LoadBalancer_service_name> \
| grep 'External Traffic Policy'
```

For more information, see [Parameters of a LoadBalancer service](../operations/create-load-balancer.md#advanced).

#### Why does the newly created PersistentVolumeClaim remain _Pending_? {#pvc-pending}

This is normal for a [PersistentVolumeClaim](../concepts/volume.md#persistent-volume) (PVC). The newly created PVC remains **Pending** until you create a pod that will use it.

To change the PVC status to **Running**:
1. View the PVC details:

   ```bash
   kubectl describe pvc <PVC_name> \
     --namespace=<namespace>
   ```

   Where `--namespace` is the namespace containing the PVC.

   The `waiting for first consumer to be created before binding` message means that the PVC is awaiting pod creation.
1. [Create a pod](../operations/volumes/dynamic-create-pv.md#create-pod) for this PVC.

#### Why does my Managed Service for Kubernetes cluster fail to start after I update its node configuration? {#not-starting}

Make sure the new configuration of Managed Service for Kubernetes nodes is within the [quota](../concepts/limits.md):

{% list tabs %}

- CLI

  If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install).

  The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id <folder_ID>` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

  To run diagnostics for your Managed Service for Kubernetes cluster nodes:
  1. [Connect to the Managed Service for Kubernetes cluster](../operations/connect/index.md).
  1. Check the state of Managed Service for Kubernetes nodes:

     ```bash
     yc managed-kubernetes cluster list-nodes <cluster_ID>
     ```

     A message saying that the limit of Managed Service for Kubernetes cluster resources has been exceeded appears in the first column of the command output. Here is an example:

     ```text
     +--------------------------------+-----------------+------------------+-------------+--------------+
     |         CLOUD INSTANCE         | KUBERNETES NODE |     RESOURCES    |     DISK    |    STATUS    |
     +--------------------------------+-----------------+------------------+-------------+--------------+
     | fhmil14sdienhr5uh89no          |                 | 2 100% core(s),  | 64.0 GB hdd | PROVISIONING |
     | CREATING_INSTANCE              |                 | 4.0 GB of memory |             |              |
     | [RESOURCE_EXHAUSTED] The limit |                 |                  |             |              |
     | on total size of network-hdd   |                 |                  |             |              |
     | disks has exceeded.,           |                 |                  |             |              |
     | [RESOURCE_EXHAUSTED] The limit |                 |                  |             |              |
     | on total size of network-hdd   |                 |                  |             |              |
     | disks has exceeded.            |                 |                  |             |              |
     +--------------------------------+-----------------+------------------+-------------+--------------+
     ```

{% endlist %}

To start your Managed Service for Kubernetes cluster, [increase the quotas](../concepts/limits.md).

#### After changing the node subnet mask in the cluster settings, the number of pods per node is not as expected {#count-pods}

**Solution**: Recreate the node group.

#### Error updating ingress controller certificate {#ingress-certificate}

Error message:

```text
ERROR controller-runtime.manager.controller.ingressgroup Reconciler error
{"name": "some-prod", "namespace": , "error": "rpc error: code = InvalidArgument
desc = Validation error:\nlistener_specs[1].tls.sni_handlers[2].handler.certificate_ids:
Number of elements must be less than or equal to 1"}
```

The error occurs if different certificates are specified for the same ingress controller handler.

**Solution**: Edit and apply the ingress controller specifications so that each handler has only one certificate.

#### Why is DNS resolution not working in my cluster? {#not-resolve-dns}

A Managed Service for Kubernetes cluster may fail to resolve internal and external DNS requests for several reasons. To fix the issue:
1. [Check the version of your Managed Service for Kubernetes cluster and node groups](#check-version).
1. [Make sure CoreDNS is up and running](#check-coredns).
1. [Make sure your Managed Service for Kubernetes cluster has enough CPU resources available](#check-cpu).
1. [Set up autoscaling](#dns-autoscaler).
1. [Set up local DNS caching](#node-local-dns).

##### Check the version of your cluster and node groups {#check-version}

1. Get the list of current Kubernetes versions:

   ```bash
   yc managed-kubernetes list-versions
   ```

1. Get the Managed Service for Kubernetes cluster version:

   ```bash
   yc managed-kubernetes cluster get <cluster_name_or_ID> | grep version:
   ```

   You can get the Managed Service for Kubernetes cluster ID and name with the [list of clusters in the folder](../operations/kubernetes-cluster/kubernetes-cluster-list.md#list).
1. Get the Managed Service for Kubernetes node group version:

   ```bash
   yc managed-kubernetes node-group get <node_group_name_or_ID> | grep version:
   ```

   You can get the Managed Service for Kubernetes node group ID and name with the [list of node groups in the cluster](../operations/node-group/node-group-list.md#list).
1. If the versions of your Managed Service for Kubernetes cluster and node groups are not on the list of current Kubernetes versions, [upgrade them](../operations/update-kubernetes.md).

##### Make sure CoreDNS is up and running {#check-coredns}

Get the list of CoreDNS pods and their statuses:

```bash
kubectl get pods -n kube-system -l k8s-app=kube-dns -o wide
```

Make sure all pods have the `Running` status.

##### Make sure your cluster has enough CPU resources available {#check-cpu}

1. Navigate to the [folder dashboard](https://console.yandex.cloud) and select **Managed Service for&nbsp;Kubernetes**.
1. Click the name of the Managed Service for Kubernetes cluster you need and select the **Node management** tab.
1. Go to the **Nodes** tab and click the name of any Managed Service for Kubernetes node.
1. Navigate to the **Monitoring** tab.
1. Make sure that, in the **CPU, [cores]** chart, the `used` CPU values have not reached the `total` available CPU values. Check this for each Managed Service for Kubernetes cluster node.

##### Set up autoscaling {#dns-autoscaler}

Set up [DNS autoscaling based on the Managed Service for Kubernetes cluster size](../tutorials/dns-autoscaler.md).

##### Set up local DNS caching {#node-local-dns}

[Set up NodeLocal DNS Cache](../tutorials/node-local-dns.md). For optimal settings, [install NodeLocal DNS Cache from Yandex Cloud Marketplace](../operations/applications/node-local-dns.md#marketplace-install).

#### Creating a node group with the CLI results in a parameter conflict. How do I fix it? {#conflicting-flags}

Check whether you are specifying the `--location`, `--network-interface`, and `--public-ip` parameters in the same command. Providing them together causes the following errors:
* For the `--location` and `--public-ip` or `--location` and `--network-interface` pairs:

  ```text
  ERROR: rpc error: code = InvalidArgument desc = Validation error:
  allocation_policy.locations[0].subnet_id: can't use "allocation_policy.locations[0].subnet_id" together with "node_template.network_interface_specs"
  ```

* For the `--network-interface` and `--public-ip` pair:

  ```text
  ERROR: flag --public-ip cannot be used together with --network-interface. Use '--network-interface' option 'nat' to get public address
  ```

Make sure you only provide one of the three parameters in a command. It is enough to specify the location of a Managed Service for Kubernetes node group either in `--location` or in `--network-interface`.

To grant internet access to Managed Service for Kubernetes cluster nodes, do one of the following:
* Assign a [public IP address](../../vpc/concepts/address.md#public-addresses) to the cluster nodes, specifying `--network-interface ipv4-address=nat` or `--network-interface ipv6-address=nat`.
* [Enable access to Managed Service for Kubernetes nodes from the internet](../operations/node-group/node-group-update.md#node-internet-access) after creating a node group.

#### Error connecting to a cluster using kubectl {#connect-to-cluster}

Error message:

```text
ERROR: cluster has empty endpoint
```

This error occurs if you try to [connect to a cluster](../operations/connect/index.md#kubectl-connect) with no public IP address and get `kubectl` credentials for a public IP address using this command:

```bash
yc managed-kubernetes cluster \
   get-credentials <cluster_name_or_ID> \
   --external
```

To connect to the cluster's private IP address from a VM in the same network, get `kubectl` credentials using this command:

```bash
yc managed-kubernetes cluster \
   get-credentials <cluster_name_or_ID> \
   --internal
```

If you need to connect to a cluster from the internet, [recreate the cluster and assign](../operations/kubernetes-cluster/kubernetes-cluster-create.md) it a public IP address.

#### Errors connecting to a node over SSH {#node-connect}

Error messages:

```text
Permission denied (publickey,password)
```

```text
Too many authentication failures
```

The following situations cause errors [when connecting to a Managed Service for Kubernetes node](../operations/node-connect-ssh.md):
* No public SSH key is added to the Managed Service for Kubernetes node group metadata.

  **Solution**: [Update the Managed Service for Kubernetes node group keys](../operations/node-connect-ssh.md#node-add-metadata).
* An invalid public SSH key is added to the Managed Service for Kubernetes node group metadata.

  **Solution**: [Change the format of the public key file to the appropriate one](../operations/node-connect-ssh.md#key-format) and [update the Managed Service for Kubernetes node group keys](../operations/node-connect-ssh.md#node-add-metadata).
* No private SSH key is added to an authentication agent (`ssh-agent`).

  **Solution**: Add a private key by running the `ssh-add <path_to_private_key_file>` command.

#### How do I provide internet access to my Managed Service for Kubernetes cluster nodes? {#internet}

If Managed Service for Kubernetes cluster nodes have no internet access, the following error occurs when trying to connect to the internet:

```text
Failed to pull image "cr.yandex/***": rpc error: code = Unknown desc = Error response from daemon: Gethttps://cr.yandex/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
```

You can provide internet access to your Managed Service for Kubernetes cluster nodes in several ways:
* Set up a [NAT gateway](../../vpc/operations/create-nat-gateway.md) or [NAT instance](../../vpc/tutorials/nat-instance/index.md). With [static routing](../../vpc/concepts/routing.md) in place, traffic will go through a gateway or a separate NAT instance.
* [Assign a public IP addresses to your Managed Service for Kubernetes node group](../operations/node-group/node-group-update.md#node-internet-access).

{% note info %}

If you assign public IP addresses to your cluster nodes and then configure a NAT gateway or NAT instance, you will lose internet access via the public addresses. For more information, see [this Yandex Virtual Private Cloud guide](../../vpc/concepts/routing.md#internet-routes).

{% endnote %}

#### Why cannot I choose Docker as the container runtime? {#docker-runtime}

Clusters running Kubernetes 1.24 or higher do not support the Docker container runtime. [containerd](https://containerd.io/) is the only available runtime.

#### Error connecting a GitLab repository to Argo CD {#argo-cd}

Error message:

```text
FATA[0000] rpc error: code = Unknown desc = error testing repository connectivity: authorization failed
```

This error occurs if access to GitLab over HTTP(S) is disabled.

**Solution**: Enable HTTP(S) access. Proceed as follows:

  1. In GitLab, in the left-hand panel, select **Admin → Settings → General**.
  1. Under **Visibility and access controls**, find the **Enabled Git access protocols** setting.
  1. In the list, select the item which allows access over HTTP(S).

  For more information, see [this GitLab guide](https://docs.gitlab.com/administration/settings/visibility_and_access_controls/#configure-enabled-git-access-protocols).

#### Traffic loss when deploying app updates in a cluster with Yandex Application Load Balancer {#alb-traffic-lost}

When your app traffic is managed by an Application Load Balancer and the load balancer's ingress controller [traffic policy](../nlb-ref/service.md#servicespec) is set to `externalTrafficPolicy: Local`, the app processes requests on the same node they were delivered to by the load balancer. There is no traffic flow between nodes.

The [default health check](../../network-load-balancer/concepts/health-check.md) monitors the status of the node, not application. Therefore, Application Load Balancer traffic may go to a node where there is no application running. When you deploy a new app version in a cluster, the [Application Load Balancer ingress controller](../../application-load-balancer/tools/k8s-ingress-controller/index.md) requests the load balancer to update the backend group configuration. It takes at least 30 seconds to process the request, and the app may not receive any user traffic during that time.

To prevent this, we recommend setting up backend health checks on your Application Load Balancer. With health checks, the load balancer timely spots unavailable backends and reroutes traffic to healthy backends. Once the application is updated, traffic will again be distributed across all backends.

For more information, see [Tips for configuring Yandex Application Load Balancer health checks](../../application-load-balancer/concepts/best-practices.md) and [Metadata.annotations](../../application-load-balancer/k8s-ref/service-for-ingress.md#annotations).

#### System time displayed incorrectly on nodes, as well as in container and Managed Service for Kubernetes cluster pod logs {#time}

Managed Service for Kubernetes cluster time may not match the time of other resources, such as VMs, if they use different time synchronization sources. For example, a Managed Service for Kubernetes cluster synchronizes with a time server (by default), whereas a VM synchronizes with a private or public NTP server.

**Solution**: Set up Managed Service for Kubernetes cluster time synchronization with your private NTP server. Proceed as follows:

1. Specify the NTP server addresses in the [DHCP settings](../../vpc/concepts/dhcp-options.md) of the master subnets.

   {% list tabs group=instructions %}

   - Management console {#console}

     1. Navigate to the folder dashboard and select **Managed Service for&nbsp;Kubernetes**.
     1. Click the name of the Kubernetes cluster.
     1. Under **Master configuration**, click the subnet name.
     1. Click ![subnets](../../_assets/console-icons/pencil.svg) **Edit** in the top-right corner.
     1. In the window that opens, expand the **DHCP settings** section.
     1. Click **Add** and specify the IP address of your NTP server.
     1. Click **Save changes**.

   - CLI {#cli}

     If you do not have the Yandex Cloud CLI yet, [install and initialize it](../../cli/quickstart.md#install).

     The folder used by default is the one specified when [creating](../../cli/operations/profile/profile-create.md) the CLI profile. To change the default folder, use the `yc config set folder-id <folder_ID>` command. You can also specify a different folder for any command using `--folder-name` or `--folder-id`. If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

     1. See the description of the CLI command for updating subnet settings:

         ```bash
         yc vpc subnet update --help
         ```

     1. Run the `subnet` command, specifying the NTP server IP address in the `--ntp-server` parameter: 

         ```bash
         yc vpc subnet update <subnet_ID> --ntp-server <server_address>
         ```

     {% note tip %}
     
     To find out the IDs of the subnets containing the cluster, [get detailed information about the cluster](../operations/kubernetes-cluster/kubernetes-cluster-list.md#get).
     
     {% endnote %}

   - Terraform {#tf}

     1. In the Terraform configuration file, change the cluster subnet description. Add the `dhcp_options` section (if missing) with the `ntp_servers` parameter specifying the IP address of your NTP server:

        ```hcl
        ...
        resource "yandex_vpc_subnet" "lab-subnet-a" {
          ...
          v4_cidr_blocks = ["<IPv4_address>"]
          network_id     = "<network_ID>"
          ...
          dhcp_options {
            ntp_servers = ["<IPv4_address>"]
            ...
          }
        }
        ...
        ```

        For more information about `yandex_vpc_subnet` properties in Terraform, see [this provider guide](../../terraform/resources/vpc_subnet.md).

     1. Apply the changes:

        1. In the terminal, navigate to the configuration file directory.
        1. Make sure the configuration is correct using this command:
        
           ```bash
           terraform validate
           ```
        
           If the configuration is valid, you will get this message:
        
           ```bash
           Success! The configuration is valid.
           ```
        
        1. Run this command:
        
           ```bash
           terraform plan
           ```
        
           You will see a list of resources and their properties. No changes will be made at this step. Terraform will show any errors in the configuration.
        1. Apply the configuration changes:
        
           ```bash
           terraform apply
           ```
        
        1. Type `yes` and press **Enter** to confirm the changes.
        
        Terraform will update all required resources. You can check the subnet update using the [management console](https://console.yandex.cloud) or this [CLI](../../cli/quickstart.md) command:

        ```bash
        yc vpc subnet get <subnet_name>
        ```
     
   - API {#api}
   
     Use the [update](../../vpc/api-ref/Subnet/update.md) method for the [Subnet](../../vpc/api-ref/Subnet/index.md) resource and provide the following in the request:

     * NTP server IP address in the `dhcpOptions.ntpServers` parameter.
     * `dhcpOptions.ntpServers` parameter to update in the `updateMask` parameter.
     
     {% note tip %}
     
     To find out the IDs of the subnets containing the cluster, [get detailed information about the cluster](../operations/kubernetes-cluster/kubernetes-cluster-list.md#get).
     
     {% endnote %}

   {% endlist %}

   {% note warning %}

   For a highly available master hosted across three availability zones, you need to update each of the three subnets.

   {% endnote %}

1. Enable connections from the cluster to NTP servers.
   
   [Create a rule](../../vpc/operations/security-group-add-rule.md) for outbound traffic in the [cluster and node group security group](../operations/connect/security-groups.md#rules-internal-cluster):

   * **Port range**: `123`. If your NTP server uses a port other than `123`, specify that port.
   * **Protocol**: `UDP`.
   * **Destination name**: `Address range`.
   * **IPv4 CIDR**: `<NTP_server_IP_address>/32`. For a master hosted across three availability zones, specify three sections: `<NTP_server_IP_address_in_subnet1>/32`, `<NTP_server_IP_address_in_subnet2>/32`, and `<NTP_server_IP_address_in_subnet3>/32`.

1. Update the network settings in the cluster node group using one of the following methods:

   * Connect to each node in the group [over SSH](../operations/node-connect-ssh.md) or [via OS Login](../operations/node-connect-oslogin.md) and run the `sudo dhclient -v -r && sudo dhclient` command.
   * Reboot the group nodes at any convenient time.

   {% note warning %}

   Updating network settings may cause the services within the cluster to become unavailable for a few minutes.

   {% endnote %}

#### What should I do if I deleted my Yandex Network Load Balancer or its target groups that were automatically created for a LoadBalancer service? {#deleted-loadbalancer-service}

You cannot manually restore a Network Load Balancer or its target groups. [Recreate](../operations/create-load-balancer.md#lb-create) your `LoadBalancer` service. This will automatically create a load balancer and target groups.

#### Error connecting a Yandex Compute Cloud VM instance as an external Managed Service for Kubernetes node {#vm-as-external-node}

Error message:

```text
Unable to create remote dir /home/kubernetes/bin/: ssh run `mkdir -p -m 0644 /home/kubernetes/bin/': Process exited with status 142
Please login as the user "NONE" rather than the user "root".
```

To fix the issue, [recreate](../../compute/operations/index.md#vm-create) the VM instance, specifying `disable_root: false` in the metadata for the `user-data` key.

{% cut "Metadata example" %}

```yaml
#cloud-config
datasource:
 Ec2:
  strict_id: false
disable_root: false
users:
- name: <username>
  sudo: ALL=(ALL) NOPASSWD:ALL
  shell: /bin/bash
  ssh_authorized_keys:
  - ssh-rsa <public_key_for_VM_access>
```

{% endcut %}