Часто встречающиеся проблемы и пути их устранения#

Ошибка CreateContainerConfigError#

Эта ошибка обычно возникает из-за отсутствия ConfigMap или secret (объекты DropApp, содержащие конфиденциальные данные, такие как, учетные данные для входа).

Проблема может заключаться в проблеме с аутентификацией в реестре контейнеров или в использовании неправильного имени или тега образа. Можно определить эти проблемы, выполнив соответствующие команды:

  1. Для идентификации проблемы выполните команду:

    kubectl get pods -n [namespace]

    Изучите вывод команды, чтобы определить, имеет ли pod статус CreateContainerConfigError.

  2. Для получения подробной информации по pod и решения проблемы, выполните команду:

    kubectl describe pod [podname] -n [namespace] # здесь может быть указан отсутствующий элемент или ошибка ConfigMap

    Просмотрите поле Events, которое будет содержать события pod, подобные следующему выводу:

    ~ kubectl describe pod [podname] -n [namespace] 

Name:             [podname]
Namespace:        [namespace]
Priority:         0
Service Account:  default
Node:             <node-details>
Start Time:       Wed, 25 Jan 2023 10:00:00 +0100
Labels:           app.DropApp.io/instance=my-service
                  app.DropApp.io/name=my-service
                  pod-template-hash=00000000
Annotations:      <annotations>
Status:           Pending
IP:               
IPs:
  IP:           
Controlled By:  ReplicaSet/
Containers:
  my-service:
    Container ID:
    Image:          <image-name>
    Image ID:
    Port:           80/TCP
    Host Port:      0/TCP
    State:          Waiting
      Reason:       CreateContainerConfigError
    Ready:          False
    Restart Count:  0
    Limits:
      cpu:     100m
      memory:  128Mi
    Requests:
      cpu:      100m
      memory:   128Mi
    Liveness:   http-get http://:http/ delay=15s timeout=60s period=60s #success=1 #failure=3
    Readiness:  http-get http://:http/ delay=15s timeout=60s period=60s #success=1 #failure=3
    Environment:
    (...)
      WebJobsStorage:                                                       <set to the key 'JobsStorage' in secret '[namespace]'>                                     Optional: false
      AccessKey:                                                            <set to the key 'AccessKey' in secret '[namespace]'>                                       Optional: false
      TopicEndpoint:                                                        <set to the key 'TopicEndpoint' in secret '[namespace]'>                                   Optional: false
      ClientId:                                                             <set to the key 'ClientId' in secret '[namespace]'>                                        Optional: false
    (...)
    State:          Waiting
    (...)
Events:
  Type     Reason     Age                From               Message
  ----     ------     ----               ----               -------
  Normal   Scheduled  94s                default-scheduler  Successfully assigned [namespace]/ to <node-name>
  Normal   Pulled     94s                kubelet            Successfully pulled image "image" in 165.014261ms
  Warning  Failed     77s (x4 over 94s)  kubelet            Error: couldn't find key ClientId in Secret my-service/my-service
(...)

    В разделе Events отображается список всех событий, произошедших в процессе создания pod.

    В приведенном выводе отсутствует secret ClientId, который необходимо запустить.

  3. Запустите эту команду, чтобы увидеть, существует ли ConfigMap в кластере DropApp. Например:

    kubectl get configmap [name]

    Если результатом будет являться null, значит ConfigMap отсутствует, и необходимо его создать.

  4. Убедитесь, что ConfigMap доступен, выполнив команду:

    get configmap [name]

  5. Если необходимо просмотреть содержимое ConfigMap в формате YAML, добавьте флаг -o yaml.

  6. Убедитесь, что ConfigMap существует, выполнив команду:

    kubectl get configmap [name]

  7. Убедитесь, что pod находится в состоянии Running выполнив команду:

    kubectl get pods -n [namespace]

Ошибка CrashLoopBackOff#

Эта ошибка возникает, когда pod не запланирован на узле. Это может произойти из-за того, что ресурсов на узле недостаточно для запуска pod, которому не удалось подключить запрошенные тома. Исправляется при перезапуске.

  1. Для идентификации проблемы выполните команду:

    kubectl get pods -n [namespace]

  2. Проверьте результат вывода и определите, имеет ли pod статус CrashLoopBackOff.

  3. Для получения подробной информации и решения проблемы выполните команду:

    kubectl describe pod [name]

    Вывод поможет определить причину проблемы. Ниже приведены общие причины:

    • Недостаточно ресурсов. Если на узле недостаточно ресурсов, можно вручную исключить pod или масштабировать кластер DropApp, чтобы обеспечить доступность дополнительных узлов для pod.

    • Подключение тома. Если видите, что проблема заключается в подключении тома хранилища, проверьте, какой том pod пытается подключить. Убедитесь, что он правильно определен в манифесте pod, и проверьте доступность тома хранилища.

    • Использование hostPort - если pod привязаны к hostPort, можно запланировать только один pod для каждого узла. В большинстве случаев, можно не использовать hostPort, а использовать объект Service для обеспечения связи с pod.

Узел DropApp не готов#

Это происходит, когда рабочий узел завершает работу или происходит сбой, что приводит к недоступности всех pod с отслеживанием состояния, находящихся на узле завершения работы. Проблема решается переносом на pod с отслеживанием состояния другого работающего узла.

Для устранения неполадок в DropApp pod требуется выполнить следующие шаги:

  • изучите выходные данные команды pod описания Kubectl;

  • проверьте наличие ошибки в описании pod;

  • проверьте несоответствие между сервером API и локальным манифестом pod (и диагностируйте другие проблемы pod с помощью журналов pod) и выполните отладку контейнера Exec, отладку контейнера Ephemeral Debug и команду pod отладки на узле.

Несовместимость Cilium версии 1.18 и выше в режиме snat с ядром 4.xx#

В Cilium версии 1.18 и выше nodePort не работает в режиме snat на ядре 4.xx, использующемся в Platform V SberLinux OS Server 8-го поколения.

Для совместимости настройте:

  • протокол виртуальной сети: значение geneve для параметра tunnelProtocol;

  • для loadBalancer:

    • режим Direct Server Return (DSR): значение dsr для параметра loadBalancer.mode;

    • протокол виртуальной сети: значение geneve для параметра loadBalancer.dsrDispatch.

Пример Helm-чарта:

helm install cilium cilium/cilium --version <version> \
    --namespace kube-system \
    --set routingMode=native \
    --set tunnelProtocol=geneve \
    --set kubeProxyReplacement=true \
    --set loadBalancer.mode=dsr \
    --set loadBalancer.dsrDispatch=geneve \
    --set k8sServiceHost=${API_SERVER_IP} \
    --set k8sServicePort=${API_SERVER_PORT}

Несовместимость интеграции MetalLB-FRR с runc версии 1.2 и выше#

Интеграция MetalLB-FRRouting не совместима с OCI Runtime (Open Container Initiative Runtime) runc версии 1.2 и выше и должна быть запущена на отдельном OCI Runtime - crun.

Для совместимости:

  1. Настройте конфигурацию Cri-O, например:

    [crio.runtime]
selinux = true
default_runtime = "runc"
[crio.runtime.runtimes]
  [crio.runtime.runtimes.crun]
    runtime_path = "/usr/bin/crun"
    runtime_type = "oci"
    runtime_root = "/run/crun"
  [crio.runtime.runtimes.runc]
    runtime_path = "/usr/bin/runc"
    runtime_type = "oci"
    runtime_root = "/run/runc"

  2. Добавьте в кластер сущность RuntimeClass:

    Пример конфигурационного файла FRRouting:

    apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: crun
handler: crun

  3. Измените runtimeClass для daemonSet speaker на crun.

    Пример конфигурационного файла Metallb:

    spec.template.spec.runtimeClassName: crun

Cri-O версии 1.28 не может быть запущен на runc версии 1.3 и выше#

Чтобы избежать несовместимости с более младшими версиями в конфигурационный файл /etc/crio/crio.conf нужно добавить любое значение параметра pids_limit, например, pids_limit = 2500. Явное указание pids_limit необходимо при использовании runc версии 1.4.0 и выше.

Пример конфигурации Cri-O:

- path: /etc/crio/crio.conf
  owner: root:root
  permissions: '0644'
  content: |
    [crio]
    [crio.api]
    [crio.runtime]
    selinux = true
    pids_limit = 2500
    default_runtime = "runc"
    [crio.runtime.runtimes]
    [crio.runtime.runtimes.crun]
    runtime_path = "/usr/bin/crun"
    runtime_type = "oci"
    runtime_root = "/run/crun"
    [crio.runtime.runtimes.runc]
    runtime_path = "/usr/bin/runc"
    runtime_type = "oci"
    runtime_root = "/run/runc"
    [crio.image]
    registries = [ "dzo.sw.sbc.space" ]
    insecure_registries = [ "registry.slo:5000" ]
    global_auth_file = "/var/lib/kubelet/config.json"
    pause_image = "{{dappK8sImageRegistry}}/k8sc/4.2.0/dapp-kubernetes/pause:3.9"
    pause_image_auth_file = "/var/lib/kubelet/config.json"
    [crio.network]
    plugin_dirs = [ "/opt/cni/bin", "/usr/libexec/cni" ]
    [crio.metrics]
    enable_metrics = true
    metrics_port = 9537
    [crio.tracing]
    [crio.stats]
    selinux = true
    plugin_dirs = [ "/opt/cni/bin", "/usr/libexec/cni" ]
    enable_metrics = true
    metrics_port = 9537

Важно

Для ядра версии 5.хх и выше, использующемся в Platform V SberLinux OS Server 9-го поколения, в файле конфигурации Cri-O /etc/crio/crio.conf установите crun для runtime, например: default_runtime = "crun"

Версию ядра можно узнать командой uname -r.