Задний план: Я пытаюсь настроить модуль регистрации Bitcoin Core на Google Cloud Platform. Я позаимствовал код из https://gist.github.com/zquestz/0007d1ede543478d44556280fdf238c9, отредактировав его так, чтобы вместо использования Bitcoin ABC (другая реализация клиента) он использовал Bitcoin Core, и изменил имя пользователя и пароль RPC на «тестовые». Я также добавил некоторые аргументы команды для сценария docker-entrypoint.sh для пересылки в bitcoind, демон для узлов, которые я запускаю. При попытке развернуть следующие три файла YAML на панели «рабочие нагрузки» отображается, что биткойн не имеет минимальной доступности. Правильное развертывание модуля важно, поэтому я могу отправлять команды RPC в Load Balancer. Ниже приведены мои используемые файлы YAML. Я не очень знаком с Kubernetes, и я занимаюсь исследовательским проектом по масштабируемости, который влечет за собой запуск команд RPC для этого модуля. Попросите соответствующие журналы, и я предоставлю их в отдельных папках. Прямо сейчас у меня в кластере всего три машины, так как я все еще настраиваю их. Зона us-east1-d, тип машины n1-standard-2.
Вопрос: Учитывая эти файлы ниже, что заставляет GCP Kubernetes Engine отвечать «Не имеет минимальной доступности» и как это можно исправить?
bitcoin-deployment.sh
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
namespace: default
labels:
service: bitcoin
name: bitcoin
spec:
strategy:
type: Recreate
replicas: 1
template:
metadata:
labels:
service: bitcoin
spec:
containers:
- env:
- name: BITCOIN_RPC_USER
valueFrom:
secretKeyRef:
name: test
key: test
- name: BITCOIN_RPC_PASSWORD
valueFrom:
secretKeyRef:
name: test
key: test
image: ruimarinho/bitcoin-core:0.17.0
name: bitcoin
ports:
- containerPort: 18443
protocol: TCP
volumeMounts:
- mountPath: /data
name: bitcoin-data
resources:
requests:
memory: "1.5Gi"
command: ["./entrypoint.sh"]
args: ["-server", "-daemon", "-regtest", "-rpcbind=127.0.0.1", "-rpcallowip=0.0.0.0/0", "-rpcport=18443", "-rpcuser=test", "-rpcpassport=test"]
restartPolicy: Always
volumes:
- name: bitcoin-data
gcePersistentDisk:
pdName: disk-bitcoincore-1
fsType: ext4
bitcoin-secrets.yml
apiVersion: v1
kind: Secret
metadata:
name: bitcoin
type: Opaque
data:
rpcuser: dGVzdAo=
rpcpass: dGVzdAo=
биткойн-srv.yml
apiVersion: v1
kind: Service
metadata:
name: bitcoin
namespace: default
spec:
ports:
- port: 18443
targetPort: 18443
selector:
service: bitcoin
type: LoadBalancer
externalTrafficPolicy: Local


Я сталкивался с этой проблемой несколько раз. Решения, которые я использовал:
Пример был ранее в этом месяце. Не смог запустить новые ресурсы в us-west1-a. Думаю только что перешли на us-east4-c. Все запустили.
Я действительно не знаю, почему это происходит под прикрытием с Google. Я лично сталкивался с этой проблемой трижды за последние три месяца, и я видел эту проблему несколько раз в StackOverflow. Настоящий ответ может быть простым: Google Cloud действительно начал расти быстрее, чем их инфраструктура. Это хорошо для Google, поскольку я знаю, что они инвестируют в новые крупные ресурсы для облака. Лично мне очень нравится работать с их облаком.
Сообщение об ошибке, о котором вы упомянули, прямо не указывает на дефицит; это больше ресурсов, недоступных в кластере. Вы можете повторить попытку после добавления еще одного узла в кластер и т. д. Кроме того, этот руководство по устранению неполадок предполагает, что у ваших узлов достаточно ресурсов, но у вас все еще есть сообщение «Нет минимальной доступности», проверьте, имеют ли узлы статус SchedulingDisabled или Cordoned: в этом случае они не Не принимаю новые капсулы.
Причин такой неудачи может быть много:
Я столкнулся с этой ошибкой в GKE. Причина в том, что модуль не собирался найти конфигурационную карту из-за несоответствия имени. Поэтому убедитесь, что модуль обнаруживает все ресурсы.