Случайные проблемы с подключением к MySQL?

Я могу запускать одну и ту же команду снова и снова, и иногда это работает, иногда нет:

root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
ERROR 2002 (HY000): Can't connect to MySQL server on '10.245.54.251' (115)
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
ERROR 2002 (HY000): Can't connect to MySQL server on '10.245.54.251' (115)
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
ERROR 2002 (HY000): Can't connect to MySQL server on '10.245.54.251' (115)
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
ERROR 2002 (HY000): Can't connect to MySQL server on '10.245.54.251' (115)
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
ERROR 2002 (HY000): Can't connect to MySQL server on '10.245.54.251' (115)
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
#mysql50#lost+found
busman
demo_busman
information_schema
mysql
performance_schema
root@bak-rrk9m:/# mysql -Bsuroot -p"$MYSQL_ROOT_PASSWORD" -h"$KMB_MARIADB_SERVICE_SERVICE_HOST" -e "show databases"
ERROR 2002 (HY000): Can't connect to MySQL server on '10.245.54.251' (115)

На моем веб-сайте OTOH, похоже, нет ошибок.

В чем дело? Как это исправить?

Это та же проблема, использую ли я имя хоста или внутренний / кластерный IP-адрес.

Получил журналы из модуля MariaDB. Это могло быть так:

2020-06-15 0:51:51 12069 [Предупреждение] Прервано соединение 12069 с db: 'demo_kmbookings' user: 'root' host: '10 .244.0.84 '(Получена ошибка записи коммуникационных пакетов)

Нашел какая-то статья с некоторыми предложениями, но ничего конкретного.

Подумал, может быть, у него заканчивается ОЗУ при создании этих дампов, так как я удешевил и дал ему только 1 ГиБ или около того. К счастью, Kubernetes позволил легко перестроить весь мой кластер на более крупный узел, но это не помогло.

Теперь заметил, что мой сервис MariaDB selector на самом деле не соответствует моему шаблону развертывания. Я исправил это, и теперь он успешно работает. Придется попробовать еще несколько раз, чтобы быть уверенным, но это заставляет меня задаться вопросом, как это вообще работало.

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

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

Я извлек несколько очков из документация:

Поле .spec.selector определяет, как Deployment находит, какими модулями нужно управлять. В этом случае вы просто выбираете метку, которая определена в шаблоне Pod (app: nginx). Однако возможны более сложные правила выбора, если сам шаблон Pod удовлетворяет этому правилу.

Примечание. Вы должны указать соответствующий селектор и метки шаблона Pod в развертывании (в данном случае app: nginx). Не перекрывайте метки или селекторы с другими контроллерами (включая другие развертывания и StatefulSets). Kubernetes не мешает вам перекрываться, и если несколько контроллеров имеют перекрывающиеся селекторы, эти контроллеры могут конфликтовать и вести себя неожиданно.

Я почти уверен, что это проблема конфигурации Kubernetes. Мое развертывание MariaDB выглядело так:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: mariadb-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      pod: b437e465-2526-41bb-ae19-534b3a60f2eb
  template:
    metadata:
      labels:
        pod: b437e465-2526-41bb-ae19-534b3a60f2eb
    spec:
      containers:
        - name: mariadb
          image: mariadb
          ports:
            - containerPort: 3306
          envFrom:
            - secretRef:
                name: mariadb-env
          volumeMounts:
            - name: mariadb-volume
              mountPath: /var/lib/mysql
            - name: config-volume
              mountPath: /etc/mysql/mariadb.conf.d/zzz-kymark.cnf
              subPath: my.cnf
      volumes:
        - name: mariadb-volume
          persistentVolumeClaim:
            claimName: mariadb-pvc
        - name: config-volume
          configMap:
            name: mariadb-config

Но мое определение службы выглядело так:

apiVersion: v1
kind: Service
metadata:
  name: mariadb-service
spec:
  selector:
    app: kymark-mariadb-pod
  ports:
    - protocol: TCP
      port: 3306

Обратите внимание на selector не совпадает.

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

Я не понимаю, почему это все равно будет работать иногда. Куда Kubernetes перенаправлял весь трафик? Почему мой сайт все еще работал?

Думаю, вот уроки:

Проверьте журналы для своего база данных. Ошибка клиента не содержит много информации.
Дважды проверьте конфигурацию и селекторы Kubernetes

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