OpenShift Troubleshooting

Автор: | 05/09/2023
Нет комментариев

Я расскажу о двух важных аспектах устранения неполадок OpenShift:

  1. Демоны OpenShift (OpenShift daemons)
  2. Поды (Pods) — наименьшая вычислительная единица

Кластер Openshift состоит из нескольких узлов, каждый из которых играет определенную роль.

MASTER node :

Мастер узел(ы) — это узел, содержащая плоскость управления. Плоскость управления включает в себя: сервер API, сервер controller manager и etcd. Мастер узел управляет узлами приложений/вычислений в кластере и планирует запуск подов на них.

Мастер ноды в основном обрабатывают запросы от клиентов (Нод, Пользователей, Администраторов и других инфраструктурных систем, развернутых (задеплоинных) в Openshift).

INFRASTRUCTURE (инфраструктурная) node :

На этих узлах выполняются специфичные для инфраструктуры службы, такие как маршрутизатор, реестр образов и другие инфраструктурные службы.

APPLICATION / COMPUTE (вычислительная) node :

Узел предоставляет среду выполнения для контейнеров. По сути, на этих узлах выполняется контейнерное приложение, а планирование работы этих модулей осуществляется мастер нодами.

BASTION node:

Этот узел служит основным сервером развертывания и управления кластером OpenShift. Он в основном используется администратором кластера для операций управления и развертывания.

Все узлы OpenShift (кроме Bastion) запускают службы «docker» и «atomic-openshift-node» под SystemD. Проверьте состояние этих служб, используя:

$ systemctl status atomic-openshift-node.service
$ systemctl status docker.service

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

$ journalctl -u atomic-openshift-node 
$ journalctl -u docker.service

Учитывая, что обе вышеупомянутые службы показывают статусы работы, пришло время посмотреть, все ли узлы общаются друг с другом и образуют кластер. Чтобы получить текущий статус и подробную информацию обо всех узлах OpenShift, выполните приведенную ниже команду на одном из узлов инфраструктуры. В приведенном ниже выводе обратите внимание на статус каждого узла: вы должны увидеть «Ready», что означает, что все в порядке. Вы также можете проверить, правильно ли сопоставлены роли с соответствующими узлами.

    $ oc get nodes -o wide

    NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
    appnode01 Ready compute 69d v1.11.0+d4cacc0 192.168.122.10 <none> Red Hat Enterprise Linux 3.10.0-957.1.3.el7.x86_64 docker://1.13.1

    appnode02 Ready compute 69d v1.11.0+d4cacc0 192.168.122.11 <none> Red Hat Enterprise Linux 3.10.0-957.1.3.el7.x86_64 docker://1.13.1

    infrnode01 Ready infra,master 69d v1.11.0+d4cacc0 192.168.122.12 <none> Red Hat Enterprise Linux 3.10.0-957.1.3.el7.x86_64 docker://1.13.1

    infrnode02 Ready infra,master 69d v1.11.0+d4cacc0 192.168.122.13 <none> Red Hat Enterprise Linux 3.10.0-957.1.3.el7.x86_64 docker://1.13.1

    infrnode03 Ready infra,master 69d v1.11.0+d4cacc0 192.168.122.14 <none> Red Hat Enterprise Linux 3.10.0-957.1.3.el7.x86_64 docker://1.13.1

Более подробную информацию о каждом узле можно получить с помощью команды: oc describe node. Несколько важных деталей, которые вы можете отметить:

  1. Какая роль (compute или infra) сопоставлена хосту
  2. Сведения об операционной системе этого хоста
  3. Можно ли запланировать поды, если это вычислительный (compute) хост
  4. Статус ресурсов (диск, память, процессор и Pid).
  5. Текущее использование ресурсов на этом хосте.
  6. Какие поды работают на этом хосте
  7. Подробности о компонентах kubelet и kube-proxy
    # oc describe node appnode01
    Name: appnode01
    Roles: compute
    Labels: beta.kubernetes.io/arch=amd64
    beta.kubernetes.io/instance-type=Standard_DS13_v2
    beta.kubernetes.io/os=linux
    ...
    node-role.kubernetes.io/compute=true
    ...
    Taints: <none>
    Unschedulable: false

    Conditions:
    Type Status LastHeartbeatTime LastTransitionTime Reason Message
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    OutOfDisk False Fri, 24 Apr 2020 12:23:43 +0000 Wed, 11 Mar 2020 13:57:02 +0000 KubeletHasSufficientDisk kubelet has sufficient disk space available
    MemoryPressure False Fri, 24 Apr 2020 12:23:43 +0000 Wed, 11 Mar 2020 13:57:02 +0000 KubeletHasSufficientMemory kubelet has sufficient memory available
    DiskPressure False Fri, 24 Apr 2020 12:23:43 +0000 Wed, 11 Mar 2020 13:57:02 +0000 KubeletHasNoDiskPressure kubelet has no disk pressure
    PIDPressure False Fri, 24 Apr 2020 12:23:43 +0000 Wed, 06 Feb 2019 18:17:16 +0000 KubeletHasSufficientPID kubelet has sufficient PID available

    Ready True Fri, 24 Apr 2020 12:23:43 +0000 Wed, 11 Mar 2020 13:57:02 +0000 KubeletReady kubelet is posting ready status

    Addresses:
    InternalIP: 192.168.122.10
    Hostname: appnode01
    Capacity:
    cpu: 8
    hugepages-1Gi: 0
    hugepages-2Mi: 0
    memory: 57700476Ki
    pods: 250
    Allocatable:
    cpu: 8
    hugepages-1Gi: 0
    hugepages-2Mi: 0
    memory: 57598076Ki
    pods: 250

    System Info:
    Machine ID: 6xa77495007y44b5z7983fa8f0e34d11
    ...
    Operating System: linux
    Architecture: amd64
    Container Runtime Version: docker://1.13.1
    Kubelet Version: v1.11.0+d4cacc0
    Kube-Proxy Version: v1.11.0+d4cacc0

    ProviderID: azure:///subscriptions/adf9a38a26-d202–51d7–8405–9711d283af5c/resourceGroups/ajit-ktv-RG01-prod/providers/Microsoft.Compute/virtualMachines/APPNODE01

    Non-terminated Pods: (14 in total)

    Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits
    - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    ewc-1 docker-registry-1–4xm2r 100m (1%) 0 (0%) 256Mi (0%) 0 (0%)
    ewc-1 ec-api-2–8qgzs 0 (0%) 0 (0%) 2G (3%) 2G (3%)
    ...
    test-project-2 cakephp-mysql-persistent-1-nktd6 0 (0%) 0 (0%) 512Mi (0%) 512Mi (0%)
    test-project-2 mysql-1-nh8xc 0 (0%) 0 (0%) 512Mi (0%) 512Mi (0%)

    Allocated resources:
    (Total limits may be over 100 percent, i.e., overcommitted.)
    Resource Requests Limits
    - - - - - - - - - - -
    cpu 410m (5%) 220m (2%)
    memory 27680160256 (46%) 27327838720 (46%)

    Events: <none>

Как упоминалось выше, мастер ноды запускают наиболее важные процессы управления. Проверка состояния и журналов этих процессов отличается от описанной выше, поскольку все эти процессы выполняются как статический под на мастер нодах.

Вы можете получить журналы для каждой службы:

API master-logs api api
Controller master-logs controllers controllers
ETCD master-logs etcd etcd

Теперь самое интересное, связанное с подами отладки, которые являются наименьшим вычислительным юнитом openshift/K8s.

Я классифицирую отладку подов (pod debugging) двумя способами:

  1. Под не запускается
  2. Под запустился, но не работает должным образом или выдает ошибки.

Я обнаружил, что oc debug POD_NAME — один из лучших подходов для обработки любого из вышеупомянутых этапов пода. Эта команда запускает новый под и использует оболочку в качестве точки входа. Это позволяет вам проверить, что происходит во время выполнения фактической точки входа пода, и получить полезную информацию для устранения проблемы.

Чтобы просмотреть подробную информацию о работающем поде, используйте oc describe POD_NAME. В приведенном ниже выводе следует отметить несколько важных вещей:

  1. Событие  (Event) — это самый важный раздел, в котором нужно проверить, работает ли что-то в этом поде не так, как ожидалось. В большинстве случаев это даст вам представление о том, в чем может быть проблема.
  2. На каком хосте работает этот под
  3. Статус базового контейнера(ов)
    $ oc describe pod ec-api-2-mlr9b
    Name: ec-api-2-mlr9b
    Namespace: ewc-1
    Priority: 0
    PriorityClassName: <none>
    Node: appnode01/192.168.122.20
    Start Time: Tue, 09 Apr 2019 22:22:36 +0000
    Labels: deployment=ec-api-2
    deploymentconfig=ec-api
    name=ec-api
    Annotations: openshift.io/deployment-config.latest-version=2
    openshift.io/deployment-config.name=ec-api
    openshift.io/deployment.name=ec-api-2
    openshift.io/scc=restricted
    Status: Running
    IP: 10.128.3.20
    Controlled By: ReplicationController/ec-api-2
    Containers:
    ec-api:
    Container ID: docker://e83868f45c9a0a7032d3b410fd0f736cbca9edf731ad8b66bf92d2a6f5b6484

    Image: docker-registry.default.svc:5000/ewc-1/ec-api@sha256:7ce495cd097f52c3ee53cc72bbbb9943714f16868da264d60492b93148198a7d
    Image ID: docker-pullable://docker-registry.default.svc:5000/ewc-1/ec-api@sha256:7ce495cd097f52c3ee53cc72bbbb9943714f16868da264d60492b93148198a7d
    Port: 8080/TCP
    Host Port: 0/TCP
    State: Running
    Started: Tue, 09 Apr 2019 22:22:43 +0000
    Ready: True
    Restart Count: 0
    Limits:
    memory: 2G
    Requests:
    memory: 2G
    Liveness: http-get http://:8080/ delay=60s timeout=5s period=10s #success=1 #failure=3
    Readiness: http-get http://:8080/ delay=30s timeout=5s period=10s #success=1 #failure=3

    Environment:
    DB_USERNAME: <set to the key 'username' in secret 'ec-db'> Optional: false
    DB_PASSWORD: <set to the key 'password' in secret 'ec-db'> Optional: false
    ...
    Dkapua.config.dir=/etc/opt/ec/defaults

    Mounts:
    /var/run/secrets/kubernetes.io/serviceaccount from default-token-dwdbk (ro)

    Volumes:

    default-token-dwdbk:
    Type: Secret (a volume populated by a Secret)
    SecretName: default-token-dwdbk
    Optional: false
    QoS Class: Burstable
    Node-Selectors: node-role.kubernetes.io/compute=true
    Tolerations: node.kubernetes.io/memory-pressure:NoSchedule

    Events: <none>

Вы можете просмотреть журналы запущенного пода, выполняющего один контейнер внутри себя:

$ oc -n <PROJECT_NAME> logs <POD_NAME>

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

Если вы хотите отслеживать текущие журналы (аналогично команде tail -f), используйте опцию -f вместе с приведенной выше командой.

$ oc -n <PROJECT_NAME> logs -f <POD_NAME>

Вы можете изучить несколько дополнительных опций для просмотра журналов за определенный период времени, начиная с определенной даты и времени и т. д.

https://blog.clairvoyantsoft.com/openshift-troubleshooting-aa7cc67b0334?gi=a750f4a08f39

Примечание:

Для поиска работающих служб origin на сервере, удобно использовать поиск по процессам:

sudo systemctl list-units | grep origin

origin-master-api.service
Atomic OpenShift Master API
origin-master-controllers.service
Atomic OpenShift Master Controllers

Страница с рекомендациями еще будет дополняться…