Что такое халвинг Bitcoin?
Халвинг (halving) это уполовинивание Bitcoin, оно происходит после добычи каждых 210 000 блоков, или примерно каждые четыре года, уменьшая вдвое количество Bitcoin, вознаграждаемых за проверку одного блока транзакций. Первоначально майнеры получали по 50 BTC за блок перед первым событием сокращения пополам в 2012 году. Таким образом, три последующих сокращения пополам привели к текущему вознаграждению за блок в размере 6,25 Bitcoin. Этот процесс ограничивает предложение Bitcoin, что увеличивает их дефицит и потенциально повышает их стоимость.
Первое сокращение произошло 28 ноября 2012 года, в результате чего майнеры получили 25 BTC за добытый блок. После второго халвинга 9 июля 2016 года вознаграждение было уменьшено до 12,5 BTC за добытый блок. 11 мая 2020 года последнее сокращение вдвое принесло вознаграждение в размере 6,25 BTC, а следующее событие сокращения произойдет в 2024 году. Последующие сокращения будут продолжаться до тех пор, пока последний из 21 миллиона Bitcoin не будет полностью добыт, что, по оценкам, произойдет где-то в 2140 году.
Какова цель халвинга Bitcoin?
Концепция разделения Bitcoin вдвое была введена как часть исходного протокола Bitcoin. В нем воплощена идея дефляционной крипто валюты, используемой в первую очередь для контроля и сокращения предложения новых Bitcoin, поступающих в рыночное обращение. При ограниченном общем объеме поставок BTC никакие организации, правительства, органы власти или центральные банки не могут создавать больше Bitcoin. В результате в игру вступает идея экономики спроса и предложения.
Тем не менее, протокол Bitcoin был разработан таким образом по разным причинам. Давайте рассмотрим некоторые из них. (далее…)
Ресурс Kubernetes Job
Задания (Job) применяются для нерегулярных задач, где важно, чтобы задача закончилась правильно. Примером такого задания может служить хранение данных в каком-либо месте, а также их преобразование и экспорт.
Для определения ресурса Job создайте манифест ресурса Job:
apiVersion: batch/v1 (далее…)
kind: Job
metadata:
name: batch-job
spec:
template:
metadata:
labels:
app: batch-job
spec:
restartPolicy: OnFailure
containers:
– name: main
image: vasya/batch-job
В статье пойдет речь о запуске только одного модуля на каждом узле с помощью набора демонов (DaemonSet).
Наборы реплик (ReplicaSet) используются для запуска определенного количества модулей, развернутых в кластерной инфраструктуре Kubernetes. Но существуют случаи, когда требуется, чтобы модули связанные с обеспечением работы инфраструктуры, выполняющие операции системного уровня работали на каждом узле в кластере. Например, когда требуется на каждом узле запустить сборщик логов или монитор ресурсов. Еще одним хорошим примером является собственный процесс kube-proxy системы Kubernetes, который должен работать на всех узлах, чтобы заставлять службы работать. Наборы демонов (DaemonSet) запускают только одну реплику модуля на каждом узле, в то время как наборы реплик (replicaset) разбрасывают их по всему кластеру случайным образом.
Для запуска модуля на всех узлах кластера создается объект DaemonSet, который похож на объекты ReplicaSet, за исключением того, что модули, созданные набором демонов, уже имеют заданный целевой узел и пропускают планировщик Kubernetes, т.е. они не разбросаны по кластеру случайным образом. Набор демонов гарантированно создает модули по количеству узлов, и разворачивает каждый на своем узле. Падение узла не заставляет объект DaemonSet создавать модуль в другом месте. Но когда новый узел добавляется в кластер, набор демонов немедленно развертывает в нем новый экземпляр модуля.
Объяснение наборов демонов на примере
Развернем демон ssd-monitor, который должен работать на всех узлах, содержащих твердотельный накопитель (SSD). Создадим объект DaemonSet, который запускает этот демон на всех узлах, помеченных как имеющие SSD. Подразумевается, что администраторы кластера добавили метку disk=ssd во все такие узлы, поэтому создадим объект DaemonSet с помощью селектора узлов, который выбирает только узлы с этой меткой.
Создание YAML-определения ресурса DaemonSet (создайте файл с именем ssd-monitor-daemonset.yaml): (далее…)
Создание контроллера репликации.
Контроллер репликации (ReplicationController) – это ресурс Kubernetes, который обеспечивает поддержание постоянной работы его модулей. Если модуль исчезает по любой причине, например, в случае исчезновения узла из кластера или потому, что модуль был вытеснен из узла, контроллер репликации замечает отсутствующий модуль и создает сменный модуль.
Контроллер репликации состоит из трех основных частей:
- селектор меток, определяющий, какие модули находятся в области действия контроллера репликации;
- количество реплик, указывающее на требуемое количество модулей, которые должны быть запущены;
- шаблон модуля, используемый при создании новых реплик модуля.
Подобно модулям и другим ресурсам Kubernetes, создается контроллер репликации при помощи отправки дескриптора JSON или YAML на сервер API Kubernetes ($ kubectl create -f kubia-rc.yaml). Содержимое файла kubia-rc.yaml: (далее…)
Kubernetes может проверить текущую работоспособность контейнера посредством проверок работоспособности (livenessProbe). Kubernetes будет периодически выполнять проверку и перезапускать контейнер в случае неуспешной проверки.
Kubernetes может исследовать контейнер с помощью одного из трех механизмов:
- Запрос HTTP GET на IP-адрес, порт и путь контейнера, которые вы укажете. Если код отклика HTTP будет 2xx или 3xx, проверка считается успешной. Если сервер возвращает отклик с кодом ошибки или вообще не отвечает, то проверка считается неуспешной, и в результате контейнер будет перезапущен;
Добавление проверки работоспособности в модуль: kubia-liveness-probe.yaml
apiVersion: v1
kind: pod
metadata:
name: kubia-liveness
spec:
containers:
– image: vasya/kubia-unhealthy
name: kubia
livenessProbe:
httpGet:
path: /
port: 8080
initialDelaySeconds: 15 (далее…)
0