Узлы кластера движка Google не готовы после работы

Question

Я пытаюсь создать кластер на сервере контейнеров Google для размещения:

• база данных postgresql с постоянным диском (образ mdillon/postgis: последний)
• пользовательский образ nginx/php-fpm для размещения проекта Symfony2 php

Проект phm symfony2 содержится в образе docker со всеми зависимостями ("composer install" запускается внутри файла docker при сборке образа).

При запуске точка входа генерирует кэш начальной загрузки и кэш прогрева, затем запускает php-fpm и nginx.

Я делаю следующее для создания кластера:

Создайте кластер с 1,2 или более узлами:

например:

gcloud container clusters create cluster-standard-1 --disk-size 20 --machine-type n1-standard-1 --num-nodes 1 --scopes storage-rw

gcloud container clusters create cluster-micro --disk-size 20 --machine-type f1-micro --num-nodes 3 --scopes storage-rw

Я сделал много тестов во многих конфигурациях.

Создайте контроллеры и службы репликации:

kubectl create -f pggis-rc.yaml

kubectl create -f pggis-service.yaml

kubectl create -f app-rc.yaml

kubectl create -f app-service.yaml

Приложение-сервис выставляет балансировщик нагрузки.

Есть только контейнеры с одним контейнером с репликами = 1.

Он работал очень хорошо с кластером из 2 узлов g1-small. Сегодня утром он работал с кластером из 1 узла f1-micro (да!).

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

В случае f1-micro и g1-small я вижу следующее сообщение (во всех узлах):

kubelet: ошибка выделения страницы: порядок:0, режим:0x120

или же

Докер: ошибка выделения страницы: порядок:0, режим:0x120

(в зависимости от узла) Затем следует дамп ядра... так что я подумал, что это проблема с памятью.

В случае стандартного узла 1 это сообщение отсутствует.

Во всех случаях за этим следует множество таких сообщений (постоянно):

21 октября, 19:59:22 gke-cluster-standard-1-2f01f811-node-k8m6 account-from-metadata: ошибка ПРЕДУПРЕЖДЕНИЯ при попытке обновить учетные записи: [Errno 104] Сброс соединения по пиру 21 октября 19:59:27 gke-cluster-standard-1-2f01f811-node-k8m6 account-from-metadata: ошибка ПРЕДУПРЕЖДЕНИЯ при попытке обновить учетные записи: '' 21 октября 19:59:32 gke-cluster-standard-1-2f01f811-node-k8m6 account- from-metadata: ошибка WARNING при попытке обновить учетные записи: '' 21 октября 19:59:37 gke-cluster-standard-1-2f01f811-node-k8m6 accounts-from-metadata: ошибка WARNING при попытке обновить учетные записи: '' 21 октября 19:59:42 gke-cluster-standard-1-2f01f811-node-k8m6 account-from-metadata: ошибка ПРЕДУПРЕЖДЕНИЯ при попытке обновить учетные записи: '' 21 октября 19:59:47 gke-cluster-standard-1 -2f01f811-node-k8m6 метаданных учетных записей от: ошибка ПРЕДУПРЕЖДЕНИЕ при попытке обновить учетные записи: '' 21 октября 19:59:52 gke-cluster-standard-1-2f01f811-узел-k8m6 метаданных учетных записей от: ошибка ПРЕДУПРЕЖДЕНИЕ при попытке обновить учетные записи: '' 21 октября 19:59:57 gke-cluster-standard-1-2f0 1f811-node-k8m6 account-from-metadata: ошибка ПРЕДУПРЕЖДЕНИЯ при попытке обновить учетные записи: '' 21 октября 20:00:02 gke-cluster-standard-1-2f01f811-node-k8m6 accounts-from-metadata: ошибка WARNING во время при попытке обновить учетные записи: '' 21 октября 20:00:07 gke-cluster-standard-1-2f01f811-node-k8m6 account-from-metadata: ПРЕДУПРЕЖДЕНИЕ: ошибка при попытке обновить учетные записи: '' 21 октября 20:00:12 gke-cluster-standard-1-2f01f811-node-k8m6 account-from-metadata: ошибка ПРЕДУПРЕЖДЕНИЯ при попытке обновить учетные записи: ''

Затем узел остается в статусе: NotReady (kubectl получить узлы), а модули остаются в состоянии ожидания.

Поэтому я попытался удалить сбойный экземпляр vm (после более чем 20-минутной недоступности) и вернулся новый экземпляр с теми же сообщениями, что и выше.

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

Answer 1

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

Обратите внимание, что системные издержки довольно высоки на типе машины f1-micro, потому что даже перед тем, как вы запустите ваше приложение, будет запущено множество системных демонов (docker, kubelet, kube-proxy) вместе с любыми надстройками кластера (dns, kube). -ui, ведение журнала, мониторинг), которые были развернуты.