Hardoman

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

И всё-таки проблема в в DNS.
Если при ручном преобразовании в резервирование, то значит с mac/ip все хорошо и нет конфликтов в dhcp.

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

Иногда требуется удалить УЗ компьютера из AD

У вас под ещё не поднялся, висит в Pending.
Посмотрите describe и events пода, чтобы понять, в чем проблема.

kubectl describe pod <pod-name>
kubectl get events --field-selector involvedObject.name=<pod-name>

А зачем катить на стенд что-то если он выключен?
Почему не убедиться в его включении? CICD подразумевает, что конечный стенд в момент деплоя включен, это априори.
Можно это сделать и в пайплайне проверку на доступность стенда. Если вам нужно катить обязательно асинхронно, то CICD в классике не применим. Вам нужно публиковать прошивки или что вы там собираете на каком-то сервере, а стенд при запуске оттуда скриптом должен забирать, но это уже не CICD процесс.

У него прописан только внешний белый IP, локальные адреса не прописаны

Скорее всего это утверждение неверно. Если хост находится в локальной сети, то у него 100% есть IP адрес из этой сети. белый внешний IP скорее всего настроен не на самом хосте, а на шлюзе/роутере. В на конкретно данном хосте вряд ли сетевой интерфейс прям с белым IP - если это так - немедленно исправьте, это огромная дыра в безопасности.
1. Проверьте, резолвится ли домен из вашей сети (nslookup) и в какой IP
2. Выполните трейсы до домена (tracert, traceroute)
3. Проверьте все интерфейсы на сервере, если там есть внутренний, то ходите по его IP

Также непонятно, какие функции выполняет ваш сервер, но если там сайт или веб приложение, то да, возможно, там на веб сервере привязка только к конкретному сетевому интерфейсу, это можно исправить.

Если же у вас действительно резолвинг по внешний IP, то, вероятно, дело в настройках файрвола и маршрутизации в вашей сети. Обычно на сетевых устройствах, подключение с локального адреса на внешний интерйес запрещено, между ними только NAT и в обратную сторону эту не работает, т.к. это тепля.

Puppy Linux - самый лёгкий, основан на Debian
Linux lite - судя по их базе данных, заработает на Atom
Damn Small Linux 2024 - занимает до 700 Мбайт
Lubuntu - убунта с лёгкой FXCE оболочкой, но все равно тяжелее конкурентов. Зато больше современных возможностей.

Если у вас git и код в WSL, то IDE тоже надо запускать из WSL, а не из Windows
В примере с VSCode

sudo apt install code
cd ~/my-git-project
code .

VScode в WSL имеет свои настройки, плагины и т.п., которые лежат отдельно в папке вашего юзера WSL ~/.vscode-server/, отличающиеся от инсталляция в винде.

Для диагностики во время пропадения интернета выполните трассировку.
например (для Windows)
tracert ya.ru
Где обвалится - там и проблема (исключение - хопы трассировки за IX узлами, там иногда 1 или 2 узла могут не отвечать на ICMP, но за ними трейс должен продолжиться!).
Если при этом не резолвится ya.ru, то значит DNS не доступен, что само по себе может не являться корнем проблемы, если вы на клиентах используете сторонний DNS, который без интернета не доступен.
Попробуйте трейс до 77.88.8.8 - это DNS Яндекса, он при рабочем интернете должен быть доступен всегда.

Также пингуете каждый узел на пути до интернета по цепочке. Если пинги уходят за периметр вашей сети, то проблема не у вас. Например, пингуется ваш шлюз в интернет, но за ним не пингуется гейтвей провайдера.
Для пинга хорошо бы узнать IP гейтвея провайдера и их DNS, каждый из них проверить (обычно они видны на вашем WAN интерфейсе).

Вероятно, не хватает ресурсов для корректной работы
1. Ограничьте память и cpu в файле .wslconfig
2. Используйте Hyper-V (с любой осью), а не wsl

Я не думаю, что дело в nginx, но это легко проверить передавая запросы в docker напрямую, минуя nginx

Здесь неплохо описано
https://hww.ru/2008/11/remont-i-vosstanovlenie-kla...

Нет смысла защищать секреты внутри контейнеров, как уже было сказано, если есть доступ к контейнеру, их в любом случае раскроют.
Озаботьтесь тем, чтобы при сборке и деплое контейнера секреты не передавались в открытом виде (в зависимости от инструмента деплоя - разные методы защиты, например в ansible используйте ansible-vault, если docker-compose, используйте файлы, которые маунтят секрет, чтобы не писать в compose файле секрет в открытом виде) :

version: '3.8'
    secrets:
      db_password:
        file: ./secrets/db_password.txt # Путь к локальному файлу с секретами 
    services:
      database:
        image: postgres
        environment:
          POSTGRES_PASSWORD_FILE: /run/secrets/db_password
        secrets:
          - db_password

Секрет у вас будет маунтиться в /run/secrets/, но надо все равно использовать внешний файл с паролем.

В swarm чуть более удобно - пароль берётся из секрета, который создаётся заранее

docker swarm init
docker secret create <secret_name> <file_path>

или

echo "mysecretvalue" | docker secret create <secret_name> -

version: '3.8'
    secrets:
      db_password:
        external: true # Указывает, что секрет уже создан в swarm
    services:
      database:
        image: postgres
        environment:
          POSTGRES_PASSWORD_FILE: /run/secrets/db_password
        secrets:
          - db_password

Написать простой скрипт, который на как сервере, так и на клиентах в течение дня все время проверяет доступность инета.
Но первое, на что бы я грешил - tplink

Вероятно, дело в BranchCache, и его надо локально отключить

Никогда, никогда не пишите логи в базу напрямую. В первую очередь из-за скорости, во-вторых, это синхронное действие процесса и оно должно выполняться всегда, а при недоступности базы повесит процесс в wait.
Если надо парсить большой объем логов (не ваш случай), то их отдельно можно стримить куда угодно, хоть в кафку, хоть в elasticsearch специально предназначенными для этого сервиса и типа vector.
Ротировать локальные логи logrotate'ом

Если я правильно понял, то скорость по wifi у вас выше, чем по кабелю на ПК?
В таком случае, проверяйте:
- что ОС показывает подключение к порту 1000 Мбит
- что на l2 порты 1000М
- категория кабеля 5е
- кабель правильно обжат и все 8 жил правильно звонятся в нужном порядке. 100М использует только 4 жилы.

Если вы можете подключиться к порту 5678, то проблема не в докере. Вероятно, ваш сервис слушает только на 127.0.0.1 внутри контейнера, а не на 0.0.0.0
Также может быть проблема в файрволе
Пробуйте следующие тесты:
- curl -v 127.0.0.1:5678
- curl -v host_ip:5678