Андрій Головін – Блог |

Розгортання HA Kubernetes кластера з зовнішньою топологією etcd на локальній машині

2026-01-12T06:30:00+00:00

У цьому посібнику ми розглянемо кроки для розгортання високодоступного (High Availability, HA) Kubernetes кластера з зовнішньою топологією розміщення бази даних налаштувань etcd, на локальній машині під керуванням macOS. Ми використаємо Multipass для створення віртуальних машин, cloud-init для їх ініціалізації, kubeadm для ініціалізації кластера, HAProxy як load balancer для вузлів панелі управління, Calico як Container Network Interface (CNI) та MetalLB для балансування трафіку до робочих вузлів.

Цей посібник призначений як для самостійного вивчення, так і для виконання перших кроків розгортання кластера промислового рівня. Кожен крок пояснено детально, з описом компонентів та їх ролей.

Архітектура кластера

Високодоступні кластери Kubernetes використовуються в промислових середовищах для забезпечення безперервної роботи застосунків. Резервування ключових компонентів кластера дозволяє уникнути простоїв у разі відмови окремих вузлів управління або etcd.

Компоненти

Ми будемо розгортати кластер за допомогою kubeadm на віртуальних машинах Ubuntu, створених Multipass та ініціалізованих з використанням cloud-init.

Multipass — це інструмент для швидкого створення віртуальних машин Ubuntu у хмарному стилі в операційних системах Linux, macOS та Windows. Він надає простий, але потужний інтерфейс командного рядка, який дозволяє швидко отримати доступ до Ubuntu або створити власну локальну мініхмару.

Локальна розробка та тестування можуть бути складними, але Multipass спрощує ці процеси, автоматизуючи процедуру розгортання та згортання інфраструктури. Multipass має бібліотеку готових образів, які можна використовувати для запуску спеціалізованих віртуальних машин або власних віртуальних машин, налаштованих за допомогою потужного інтерфейсу cloud-init.

Розробники можуть використовувати Multipass для створення прототипів хмарних розгортань та створення нових, налаштованих середовищ розробки Linux на будь-якій машині. Multipass — це найшвидший спосіб для користувачів Mac і Windows отримати командний рядок Ubuntu у своїх системах. Ви також можете використовувати його як пісочницю, щоб випробувати нові речі, не порушуючи роботу хост-машини та не потребуючи подвійного завантаження.
Cloud-init — це загальноприйнятий в галузі метод ініціалізації, присутній в багатьох дистрибутивах, для створення хмарних інстансів на різних платформах. Він підтримується всіма основними постачальниками публічних хмарних послуг, системами забезпечення приватної хмарної інфраструктури та інсталяціями на «голому залізі».

Під час завантаження cloud-init визначає хмару, в якій працює, і відповідно ініціалізує систему. Хмарні інстанси під час першого завантаження автоматично забезпечуються мережею, сховищем, ключами SSH, пакунками та іншими вже налаштованими системними компонентами.

Cloud-init забезпечує необхідний звʼязок між запуском хмарного екземпляра та підключенням до нього, щоб він працював як очікується.

Для користувачів хмари cloud-init забезпечує управління конфігурацією хмарного екземпляра під час першого завантаження без необхідності встановлення потрібних компонентів вручну. Для постачальників хмарних послуг він забезпечує налаштування екземпляра, який можна інтегрувати з вашою хмарою.

Якщо ви хочете дізнатися більше про те, що таке cloud-init, для чого він потрібен і як працює, прочитайте детальний опис в його документації.
Kubeadm — інструмент, створений для надання команд kubeadm init та kubeadm join як найкращих “швидких практичних способів” для створення кластерів Kubernetes.

Kubeadm виконує необхідні дії для запуску мінімального життєздатного кластера. За своєю концепцією, він займається лише процесом розгортання кластера, створення екземплярів машин не є його функцією. Встановлення різноманітних додаткових компонентів, таких як Kubernetes Dashboard, засобів моніторингу та специфічних для хмарних середовищ надбудов, також не входить в перелік його завдань.
Etcd з топологією зовнішнього розміщення. Etcd — це розподілене сховище ключів-значень із високою узгодженістю, яке забезпечує надійний спосіб зберігання даних, до яких потрібно отримати доступ розподіленій системі або кластеру машин. Воно коректно обробляє вибори лідерів під час мережевих розділень і може витримувати відмови машин, навіть вузлів-лідерів.

Kubernetes використовує etcd для зберігання всієї своєї конфігурації та стану кластера. Це включає інформацію про вузли, поди, конфігурацію мережі, секрети та інші ресурси Kubernetes. Топологія високодоступного кластера Kubernetes передбачає два варіанти розміщення etcd: топологія etcd зі спільним розміщенням (stacked) та зовнішнього розміщення (external) учасників кластера etcd. У цьому посібнику ми розглянемо топологію зовнішнього розміщення etcd, де etcd розгортається окремо від вузлів управління Kubernetes. Це забезпечує кращу ізоляцію, масштабованість та гнучкість у керуванні кластером.
HAProxy. Для розподілу трафіку до вузлів панелі управління будемо використовувати балансувальник навантаження HAProxy. Це дозволить нам забезпечити високу доступність API сервера Kubernetes. Крім того, ми розгорнемо локальні екземпляри HAProxy на кожному вузлі панелі управління для доступу до вузлів кластера etcd.
Calico. Оскільки kubeadm не створює мережу, в якій працюють поди, ми скористаємося Calico, популярним інструментом, що реалізує Container Network Interface (CNI) та забезпечує мережеві політики. Це уніфікована платформа для всіх потреб Kubernetes у сфері мережевих технологій, мережевої безпеки та спостережуваності, яка працює з будь-яким дистрибутивом Kubernetes. Calico спрощує забезпечення безпеки мережі за допомогою мережевих політик.

Топологія кластера

graph TB
  subgraph C [Control Plane and etcd]
    direction TB
    subgraph CP [Control Plane Nodes]
        direction LR
        CP1 --> CP2
        CP2 --> CP1
        CP1 --> CP3
        CP3 --> CP2
        CP2 --> CP3
        CP3 --> CP1
    end

    subgraph E [etcd cluster]
        direction LR
        E1 --> E2
        E2 --> E1
        E1 --> E3
        E3 --> E2
        E2 --> E3
        E3 --> E1
    end

    subgraph HA [Keepalived
    10.10.0.100]
      HA1(HAProxy
      10.10.0.101) <----->
      HA2(HAProxy
      10.10.0.102)
    end

    CP <--> HA
    E <--> CP

  end

    W1(Worker
    Node 1
    10.10.0.31)
    W2(Worker
    Node 2
    10.10.0.32)
    W3(Worker
    Node 3
    10.10.0.33)
    WN(Worker
    Node …
    10.10.0.9X)

    HA --> PN(Calico CNI)
    PN --> W1 & W2 & W3 & WN--> WLB <--> U(Users)

    CP1(Control Plane
    Node 1
    10.10.0.21)
    CP2(Control Plane
    Node 2
    10.10.0.22)
    CP3(Control Plane
    Node 3
    10.10.0.23)
    E1(etcd
    Node 1
    10.10.0.11)
    E2(etcd
    Node 2
    10.10.0.12)
    E3(etcd
    Node 3
    10.10.0.13)

    WLB(MetalLB
    10.10.0.200)

Попередні вимоги

Для розгортання кластера нам знадобляться:

Локальний компʼютер з встановленим Multipass. Для macOS його можна встановити за допомогою brew install multipass
kubectl — Інструмент командного рядка Kubernetes, kubectl, дозволяє вам виконувати команди відносно кластерів Kubernetes. Ви можете використовувати kubectl для розгортання застосунків, огляду та управління ресурсами кластера, а також перегляду логів (brew install kubectl)
Знання основ Kubernetes та Linux
yq (версія від mikefarah) — легкий і переносний процесор командного рядка для роботи з YAML, JSON, INI та XML.

Налаштування SSH ключів

Secure Shell, SSH (англ. Secure Shell — «безпечна оболонка») — мережевий протокол, що дозволяє проводити віддалене управління компʼютером. Він шифрує весь трафік, включаючи процес автентифікацій та передачу паролів та секретів. Для доступу до віртуальних машин потрібно налаштувати SSH ключі. Ми будемо використовувати ці ключі для підключення до всіх створених віртуальних машин та передачі між ними файлів.

Генерування SSH ключа

Щоб згенерувати пару ключів (публічний та приватний) виконайте наступну команду:

# Створіть нову пару SSH ключів (якщо у вас немає)
ssh-keygen -t rsa -b 4096 -C "k8s-cluster" -f ~/.ssh/k8s_cluster_key

# Перегляньте публічний ключ
cat ~/.ssh/k8s_cluster_key.pub

Оновлення конфігурацій cloud-init

Отриманий публічний ключ будемо використовувати у файлі snipets/cloud-init-users.yaml в секції ssh-authorized-keys:

users:
  - name: k8sadmin
    ssh_authorized_keys:
      # Замініть на ваш справжній публічний ключ
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC...

Також можна використовувати підставлення змінних під час виконання

$ multipass launch --cloud-init - <<EOF
users:
  - name: username
    sudo: ALL=(ALL) NOPASSWD:ALL
    ssh_authorized_keys:
      - $( cat ~/.ssh/id_rsa.pub )
EOF

Доступ до віртуальних машин через SSH

Після розгортання ми можемо отримати доступ до віртуальних машин за допомогою наступних команд:

multipass shell <імʼя-vm>
# або
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@<ip-vm>

Multipass має вбудовану команду shell, яка дозволяє нам підключатися до будь-якої створеної віртуальної машини без необхідності додаткових налаштувань SSH. Однак, вона використовує стандартного користувача ubuntu. Якщо ви хочете підʼєднатися як користувач k8sadmin, якого ми створимо за допомогою cloud-init, використовуйте ssh -i ~/.ssh/k8s_cluster_key k8sadmin@<ip-vm>.

Підготовка середовища

Створіть теку для проєкту та створіть необхідні файли.

mkdir k8s-ha-cluster
cd k8s-ha-cluster

Створення скриптів та конфігурацій

Параметри віртуальних машин

Для розгортання віртуальних машин нам потрібні наступні параметри:

Вузол	Кількість	`cpus`	`memory`	`disk`	`network`
etcd	3+ або (2n+1)^[1]	2	2G	5G	name=en0,mode=manual
панель управління	3	2	2.5G	8G	name=en0,mode=manual
робочі вузли	3+	2	2G	10G	name=en0,mode=manual
HAProxy+Keepalived	2	1	1G	5G	name=en0,mode=manual

Cloud-init конфігурації

Ми будемо використовувати попередньо створені конфігурації віртуальних машин у форматі cloud-init для прискорення їх розгортання.

Створення користувача

Створимо налаштування для користувача k8sadmin в snipets/cloud-init-user.yaml:

# Створимо теку, якщо її ще немає
mkdir -p snipets

cat << EOF > snipets/cloud-init-user.yaml
# Налаштування користувача
users:
  - name: k8sadmin
    sudo: "ALL=(ALL) NOPASSWD:ALL"
    groups: sudo,users,containerd
    homedir: /home/k8sadmin
    shell: /bin/bash
    lock_passwd: false
    ssh_authorized_keys:
      # Ваш SSH key
      - $( cat ~/.ssh/k8s_cluster_key.pub )
EOF

Про конфігурацію користувача ми вже говорили в налаштуваннях SSH ключів. Про інші параметри цього розділу можна прочитати в розділі Including users and groups документації cloud-init.

Базова конфігурація для вузлів кластера

Базова конфігурація cloud-init для вузлів нашого кластера буде знаходитись в snipets/cloud-init-base.yaml:

#cloud-config

# Додамо тут налаштування користувача з snipets/cloud-init-users.yaml

# Команди які виконується на ранній стадії boot для підготовки GPG ключа
bootcmd:
  - mkdir -p /etc/apt/keyrings
  - curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.34/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# Конфігурація apt репозиторіїв
apt:
  sources:
    kubernetes.list:
      source: "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /"

# Оновлення системи
package_update: true
package_upgrade: true

Для встановлення компонентів необхідних для роботи кластера нам потрібно використовувати репозиторій проєкту Kubernetes. В секції bootcmd, яка дуже схожа на runcmd, але команди з якої виконуються на самому початку процесу завантаження, ми отримуємо GPG ключ та зберігаємо його в /etc/apt/keyrings, а потім додаємо репозиторій Kubernetes до списку джерел apt в секції apt. Рядки package_update та package_upgrade забезпечують отримання останніх оновлень системи під час завантаження, що є еквівалентом виконання команд apt-get update та apt-get upgrade.

У розділі packages ми вкажемо всі необхідні пакунки, які потрібно встановити на кожній віртуальній машині кластера.

# Встановлення базових пакунків
packages:
  - apt-transport-https
  - ca-certificates
  - curl
  - gnupg
  - lsb-release
  - containerd
  - kubelet
  - kubeadm
  - kubectl # Окрім робочих вузлів

Окрім службових пакунків системи ми також встановимо containerd, kubelet, kubeadm та kubectl, які є основними компонентами для роботи Kubernetes кластера.

containerd — є рушієм виконання контейнерів, який використовується Kubernetes для запуску контейнеризованих застосунків. kubelet — це агент, який працює на кожному вузлі в кластері Kubernetes і відповідає за запуск контейнерів у подах. kubeadm — це інструмент для швидкого розгортання Kubernetes кластера, а kubectl — це інструмент командного рядка для взаємодії з кластером Kubernetes.

# Налаштування користувача
users:
  - name: k8sadmin
    groups: sudo,users,containerd

Наш користувач є учасником групи containerd, яку будемо використовувати для доступу до сокета /run/containerd/containerd.sock, щоб уможливити використання crictl без потреби використання sudo.

Інструкція write_files в cloud-init дозволяє створювати файли з вказаним вмістом під час ініціалізації віртуальної машини. Скористаємось нею для створення файлів для налаштування модулів ядра для роботи Kubernetes, увімкнення IP форвардингу, створення налаштувань для crictl та скрипту яким ми будемо ініціалізувати та запускати kubelet. (Дивіться розділ write_files у файлі cloud-init-base.yaml)

Після того як ми створили всі необхідні файли за допомогою write_files, ми можемо виконати вказані команди для налаштування системи в розділі runcmd. Тут ми можемо вказувати команди, які б ми мали виконати вручну після першого завантаження системи. У нашому випадку ми зафіксуємо версії kubeadm, kubelet та kubectl, вимкнемо swap, створимо файл налаштувань для containerd та запустимо його, а також активуємо та запустимо службу kubelet. (Дивіться розділ runcmd у файлі cloud-init-base.yaml)

Створіть два файли:

snipets/cloud-init-config.yaml — для встановлення статичної IP адреси нашим віртуальним машинам

cat << EOF > snipets/cloud-init-config.yaml
#cloud-config
timezone: Europe/Kyiv

write_files:
  # Призначення статичної IP адреси
  # Варіант з alias для bridge101 для другого мережевого інтерфесу
  - path: /etc/netplan/60-static-ip.yaml
    # Явним чином вкажемо тип значення
    # permissions: !!str "0755" # https://github.com/canonical/multipass/issues/4176
    permissions: !!str '0600'
    content: |
      network:
        version: 2
        ethernets:
          enp0s2:
            # Тут вказється IP адреса конкретної віртуальної машини
            addresses:
              # - 10.10.0.24/24
            routes:
              - to: 10.10.0.0/24
                scope: link
runcmd:
  # Застосування налаштувань для використання статичної IP адреси
  - netplan apply

  # Вибір vim як стандартного редактора (опціонально)
  - update-alternatives --set editor /usr/bin/vim.basic
EOF

☝️ Також тут вкажемо, що ми хочемо використовувати vim як наш стандартний редактор. Якщо ви надаєте перевагу nano закоментуйте чи приберіть рядок - update-alternatives --set editor /usr/bin/vim.basic

та, файл snipets/cloud-init-base.yaml з базовими налаштуваннями для віртуальних машин кластера

cat << 'EOF' > snipets/cloud-init-base.yaml
# Виконується на ранній стадії boot для підготовки GPG ключа
bootcmd:
  - mkdir -p /etc/apt/keyrings
  - curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.34/deb/Release.key | gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

# Конфігурація apt репозиторіїв
apt:
  sources:
    kubernetes.list:
      source: "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /"

# Оновлення системи
package_update: true
package_upgrade: true

# Встановлення базових пакунків
packages:
  - apt-transport-https
  - ca-certificates
  - curl
  - gnupg
  - lsb-release
  - containerd
  - kubelet
  - kubeadm
  - kubectl

write_files:
  #  Налаштування модулів ядра для роботи Kubernetes
  - path: /etc/modules-load.d/k8s.conf
    # permissions: !!str '0644'
    content: |
      overlay
      br_netfilter

  # Увімкнення маршрутизації IPv4 пакетів
  # https://andygol-k8s.netlify.app/uk/docs/setup/production-environment/container-runtimes/#prerequisite-ipv4-forwarding-optional
  - path: /etc/sysctl.d/k8s.conf
    # permissions: !!str '0644'
    content: |
      net.bridge.bridge-nf-call-iptables  = 1
      net.bridge.bridge-nf-call-ip6tables = 1
      net.ipv4.ip_forward                 = 1

  # Додаємо конфіг для crictl
  # https://github.com/containerd/containerd/blob/main/docs/cri/crictl.md#install-crictl
  # https://github.com/kubernetes-sigs/cri-tools/blob/master/docs/crictl.md
  - path: /etc/crictl.yaml
    # permissions: !!str '0644'
    content: |
      runtime-endpoint: unix:///run/containerd/containerd.sock
      image-endpoint: unix:///run/containerd/containerd.sock
      timeout: 10
      debug: false

  # Встановлюємо групу для сокета containerd
  - path: /etc/systemd/system/containerd.service.d/override.conf
    content: |
      [Service]
      ExecStartPost=/bin/sh -c "chgrp containerd /run/containerd/containerd.sock && chmod 660 /run/containerd/containerd.sock"

  # Скрипт для запуску kubelet
  - path: /usr/local/bin/kubelet-start.sh
    permissions: !!str "0755"
    content: |
      #!/bin/bash

      echo "Запуск служби kubelet та очікування готовності (ліміт 300с)..."

      # Вмикаємо та запускаємо службу
      sudo systemctl enable --now kubelet

      WAIT_LIMIT=300       # Максимальний час очікування в секундах
      ELAPSED_TIME=0       # Скільки вже пройшло часу
      SLEEP_INTERVAL=1     # Початковий інтервал (1 секунда)

      while ! systemctl is-active --quiet kubelet; do
          if [ "$ELAPSED_TIME" -ge "$WAIT_LIMIT" ]; then
              echo "-------------------------------------------------------------" >&2
              echo "АВАРІЙНИЙ ВИХІД: kubelet не запустився за $WAIT_LIMIT секунд." >&2
              echo "Останні логи помилок:"                                         >&2
              journalctl -u kubelet -n 20 --no-pager                               >&2
              echo "-------------------------------------------------------------" >&2
              exit 1
          fi

          echo "Очікування kubelet... (минуло $ELAPSED_TIME/$WAIT_LIMIT сек,"
          echo "наступна спроба через ${SLEEP_INTERVAL}с)"

          sleep $SLEEP_INTERVAL

          # Оновлюємо лічильники
          ELAPSED_TIME=$((ELAPSED_TIME + SLEEP_INTERVAL))

          # Збільшуємо інтервал вдвічі для наступного разу (прогресія)
          # Але не робимо інтервал більшим за 20 секунд, щоб не "проспати" готовність
          SLEEP_INTERVAL=$((SLEEP_INTERVAL * 2))
          if [ "$SLEEP_INTERVAL" -gt 20 ]; then
              SLEEP_INTERVAL=20
          fi
      done

      echo "Kubelet успішно запущено за $ELAPSED_TIME секунд. Продовжуємо..."

runcmd:
  # Фіксація версій пакунків Kubernetes
  - apt-mark hold kubelet kubeadm kubectl

  # Завантаження модулів ядра
  - modprobe overlay
  - modprobe br_netfilter

  # Застосування sysctl параметрів
  - sysctl --system

  # Налаштування containerd
  #
  # Налаштування драйвера cgroup systemd
  # https://andygol-k8s.netlify.app/uk/docs/setup/production-environment/container-runtimes/#containerd-systemd
  # https://github.com/containerd/containerd/blob/main/docs/cri/config.md#cgroup-drivercrictl pull
  #
  # Перевизначення образу пісочниці (pause)
  # https://andygol-k8s.netlify.app/uk/docs/setup/production-environment/container-runtimes/#override-pause-image-containerd

  - mkdir -p /etc/containerd
  - containerd config default | tee /etc/containerd/config.toml
  - sed -i 's|SystemdCgroup = false|SystemdCgroup = true|g; s|sandbox_image = "registry.k8s.io/pause.*"|sandbox_image = "registry.k8s.io/pause:3.10.1"|' /etc/containerd/config.toml
  - [ systemctl, daemon-reload ]
  - [ systemctl, restart, containerd ]
  - [ systemctl, enable, containerd ]

  # Вимкнення swap
  # https://andygol-k8s.netlify.app/uk/docs/concepts/cluster-administration/swap-memory-management/#swap-and-control-plane-nodes
  # https://andygol-k8s.netlify.app/uk/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#swap-configuration
  - swapoff -a
  - sed -i '/ swap / s/^/#/' /etc/fstab

  # Увімкнення kubelet
  - /usr/local/bin/kubelet-start.sh
EOF

Права доступу до файлів, які створює cloud-init, стандартно є 0644, якщо ви хочете вказати їх явно розкоментуйте відповідні рядки # permissions: !!str '0644'. Ми вказуємо тип даних явно (!!str '0644') через проблему описану в тікеті # 4176.

Конфігурація для etcd вузлів

Для вузлів etcd ми будемо використовувати базову конфігурацію з додатковими налаштуваннями, які специфічні для etcd. Створіть файл snipets/cloud-init-etcd.yaml:

# Розширимо cloud-init-base.yaml наступними налаштуваннями

cat << EOF > snipets/cloud-init-etcd.yaml
write_files:
  # https://andygol-k8s.netlify.app/uk/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/#setup-up-the-cluster
  - path: /etc/systemd/system/kubelet.service.d/kubelet.conf
    content: |
      apiVersion: kubelet.config.k8s.io/v1beta1
      kind: KubeletConfiguration
      authentication:
        anonymous:
          enabled: false
        webhook:
          enabled: false
      authorization:
        mode: AlwaysAllow
      cgroupDriver: systemd
      address: 127.0.0.1
      containerRuntimeEndpoint: unix:///var/run/containerd/containerd.sock
      staticPodPath: /etc/kubernetes/manifests

  - path: /etc/systemd/system/kubelet.service.d/20-etcd-service-manager.conf
    content: |
      [Service]
      ExecStart=
      ExecStart=/usr/bin/kubelet --config=/etc/systemd/system/kubelet.service.d/kubelet.conf
      Restart=always
EOF

Будемо використовувати базові налаштування, які ми створили раніше та додамо специфічні для etcd налаштування у розділі write_files, де ми створюємо файл конфігурації для kubelet, який налаштовує його для роботи з etcd, як про це йдеться в розділі «Налаштування високодоступного кластера etcd за допомогою kubeadm» документації Kubernetes.

Конфігурація вузла балансувальника HAProxy

Для вузлів балансувальника навантаження трафіку панелі управління створимо файл snipets/cloud-init-haproxy.yaml, який встановлюватиме зі стандартного репозиторію пакунки haproxy та keepalived та додаватиме налаштування. Для створення віртуальної машини для HAProxy використаємо базові налаштування з configs/cloud-init-user.yaml та розширимо їх інструкціями write_files: для створення файлу налаштувань балансувальника — /etc/haproxy/haproxy.cfg, /etc/keepalived/keepalived.conf. (Див. розділ «Налаштування балансувальника навантаження для вузлів панелі управління (HAProxy+Keepalived)»)

Вибір топології мережі

Для цієї демонстрації оберемо компактну мережу. (10.10.0.0/24)

10.10.0.0/24      - Головна підмережа (256 адрес)
├─ 10.10.0.1      - Gateway/Bridge (на хост-машині)
├─ 10.10.0.10-19  - etcd (3+ вузли)
├─ 10.10.0.20-29  - Control Plane (3+ masters)
├─ 10.10.0.30-50  - Workers (до 20 workers)
└─ 10.10.0.100    - HAProxy/Keepalived (два вузла 10.10.0.101/10.10.0.102)

Щоб задати статичні адреси віртуальним машинам Multipass скористаємось одним з варіантів про який йдеться в статті «Додавання статичної IP адреси віртуальним машинам Multipass на macOS».

У файл cloud-init додамо відповідний розділ з налаштуванням статичної мережевої адреси на другому мережевому інтерфейсі (див. snipets/cloud-init-config.yaml).

Створення etcd кластера

Почнемо зі створення кластера etcd, в якому наш високодоступний кластер Kubernetes буде зберігати налаштування та бажаний стан обʼєктів системи.

Розгортання першого вузла кластера etcd

Розпочнімо розгортання нашого кластера зі створення першого вузла etcd.

export VM_IP="10.10.0.11/24"

multipass launch --name ext-etcd-1 \
  --cpus 2 --memory 2G --disk 5G \
  --network name=en0,mode=manual \
  --cloud-init <( yq eval-all '
      # Злиття всіх файлів в один обʼєкт
      . as $item ireduce ({}; . *+ $item) |

      # Вилучення kubectl зі списку пакунків
      del(.packages[] | select(. == "kubectl")) |

      # Оновлення конфігурації мережі
      with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
        .content |= (
          from_yaml |
          .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] |
          to_yaml
        )
      ) ' \
      snipets/cloud-init-config.yaml \
      snipets/cloud-init-user.yaml \
      snipets/cloud-init-base.yaml \
      snipets/cloud-init-etcd.yaml )

Команда multipass launch --name ext-etcd-1 почне розгортання віртуальної машини з назвою вказаною в параметрі --name/-n, в цьому випадку ext-etcd-1; параметри --cpus 2 --memory 2G --disk 5G відповідно визначають кількість ядер процесора, памʼяті та дискового простору; --network name=en0,mode=manual створить ще один мережевий інтерфейс віртуальної машини, IP адресу якому буде призначено через змінну VM_IP.

Оскільки etcd активно пише дані на диск, продуктивність роботи бази даних напряму залежить від продуктивності дискової підсистеми. Для промислового використання наполегливо рекомендуються системи зберігання з SSD. Мінімальний розмір дискового простору стандартно має бути не менше 2Гб, відповідно, для уникнення розміщення даних у свопі розмір оперативної памʼяті має покривати цю квоту. 8Гб є рекомендованим максимумом для звичайних розгортань. Вимоги для машин etcd для невеликих промислових кластерів: 2 vCPU, 8 Гб памʼяті та 50-80Гб SSD. (Див. https://andygol-etcd.netlify.app/uk/docs/v3.5/op-guide/hardware/#small-cluster, https://andygol-etcd.netlify.app/uk/docs/v3.5/faq/#system-requirements)

Ми зберемо параметри cloud-init на льоту обʼєднуючи наші файли заготовки snipets/cloud-init-config.yaml, snipets/cloud-init-user.yaml, snipets/cloud-init-base.yaml, snipets/cloud-init-etcd.yaml за допомогою yq.

Якщо ви не створювали тимчасову віртуальну машину для ініціалізації bridge101 та не додавали аліас для нього, після розгортання віртуальної машини саме час зробити наступне. Виконайте на вашому хості наступне:

# Визначте назву bridge. Скоріш за все назва буде bridge101.
ifconfig -v | grep -B 20 "member: vmenet" | grep "bridge" | awk -F: '{print $1}' | tail -n 1

# Додайте адресу
sudo ifconfig bridge101 10.10.0.1/24 alias

# Перевірте що додалось
ifconfig bridge101 | grep "inet "

Якщо ви це 👆 зробили після створення тимчасової віртуальної машини, можете її зараз вилучити

multipass delete <temp-vm> --purge

Налаштування першого вузла etcd

Увійдемо до нашого вузла за допомогою SSH.

ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.11

Оскільки у нас ще немає сертифікатів ЦС нам потрібно згенерувати їх.

sudo kubeadm init phase certs etcd-ca

Ми отримаємо два файли ca.crt та ca.key в теці /etc/kubernetes/pki/etcd/

Тепер створимо конфігураційний файл для kubeadm kubeadmcfg.yaml використавши відповідні значення в змінних ETCD_HOST (IP адреса віртуальної машини) та ETCD_NAME (її коротка назва). Зверніть увагу на значення змінної ETCD_INITIAL_CLUSTER_STATE яка вказує на те що ми створюємо новий кластер etcd. Надалі ми будемо приєднувати до нього інші вузли.

ETCD_HOST=$(hostname -I | awk '{print $2}')
ETCD_NAME=$(hostname -a)
ETCD_INITIAL_CLUSTER=${ETCD_INITIAL_CLUSTER:-"${ETCD_NAME}=https://${ETCD_HOST}:2380"}
ETCD_INITIAL_CLUSTER_STATE=${ETCD_INITIAL_CLUSTER_STATE:-"new"}
cat << EOF > $HOME/kubeadmcfg.yaml
---
apiVersion: "kubeadm.k8s.io/v1beta4"
kind: InitConfiguration
nodeRegistration:
    name: ${ETCD_NAME}
localAPIEndpoint:
    advertiseAddress: ${ETCD_HOST}
---
apiVersion: "kubeadm.k8s.io/v1beta4"
kind: ClusterConfiguration
etcd:
    local:
        serverCertSANs:
        - "${ETCD_HOST}"
        peerCertSANs:
        - "${ETCD_HOST}"
        extraArgs:
        - name: initial-cluster
          value: ${ETCD_INITIAL_CLUSTER}
        - name: initial-cluster-state
          value: ${ETCD_INITIAL_CLUSTER_STATE}
        - name: name
          value: ${ETCD_NAME}
        - name: listen-peer-urls
          value: https://${ETCD_HOST}:2380
        - name: listen-client-urls
          value: https://${ETCD_HOST}:2379,https://127.0.0.1:2379
        - name: advertise-client-urls
          value: https://${ETCD_HOST}:2379
        - name: initial-advertise-peer-urls
          value: https://${ETCD_HOST}:2380
EOF

Використовуючи створений файл kubeadmcfg.yaml, який ми помістили в домашню теку користувача k8sadmin, виконаємо генерацію сертифікатів etcd та створимо маніфест статичного поду для вузла кластера etcd.

# 1. Генерація сертифікатів
sudo kubeadm init phase certs etcd-server --config=$HOME/kubeadmcfg.yaml
sudo kubeadm init phase certs etcd-peer --config=$HOME/kubeadmcfg.yaml
sudo kubeadm init phase certs etcd-healthcheck-client --config=$HOME/kubeadmcfg.yaml
sudo kubeadm init phase certs apiserver-etcd-client --config=$HOME/kubeadmcfg.yaml

Тепер у нас мають бути в наявності наступні ключі та сертифікати

/home/k8sadmin
└── kubeadmcfg.yaml
---
/etc/kubernetes/pki
├── apiserver-etcd-client.crt
├── apiserver-etcd-client.key
└── etcd
    ├── ca.crt
    ├── ca.key
    ├── healthcheck-client.crt
    ├── healthcheck-client.key
    ├── peer.crt
    ├── peer.key
    ├── server.crt
    └── server.key

Після створення відповідних сертифікатів настав час створити маніфест статичного пода. В результаті у нас маєте бути файл /etc/kubernetes/manifests/etcd.yaml.

# 2. Створення маніфесту статичного пода
sudo kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml

Отримавши маніфест /etc/kubernetes/manifests/etcd.yaml kubelet вузла має підхопити його, викачати образ контейнера та запустити под з etcd, після чого перший вузол нашого кластера має відповідати на проби справності

crictl exec $(crictl ps --label io.kubernetes.container.name=etcd --quiet) etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://10.10.0.11:2379 \
   endpoint health -w table

+-------------------------+--------+------------+-------+
|        ENDPOINT         | HEALTH |    TOOK    | ERROR |
+-------------------------+--------+------------+-------+
| https://10.10.0.11:2379 |   true | 7.777048ms |       |
+-------------------------+--------+------------+-------+

Розгортання наступних вузлів кластера etcd

Для розгортання наступних вузлів кластера etcd: ext-etcd-2, ext-etcd-3 й так далі (за потреби) змінимо значення VM_IP на "10.10.0.12/24" та імʼя віртуальної машини в параметрі --name на ext-etcd-2 відповідно.

export VM_IP="10.10.0.12/24"

multipass launch --name ext-etcd-2 \
  --cpus 2 --memory 2G --disk 5G \
  --network name=en0,mode=manual \
  --cloud-init <( yq eval-all '
      # Злиття всіх файлів в один обʼєкт
      . as $item ireduce ({}; . *+ $item) |

      # Вилучення kubectl зі списку пакунків
      del(.packages[] | select(. == "kubectl")) |

      # Оновлення конфігурації мережі
      with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
        .content |= (
          from_yaml |
          .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] |
          to_yaml
        )
      ) ' \
      snipets/cloud-init-config.yaml \
      snipets/cloud-init-user.yaml \
      snipets/cloud-init-base.yaml \
      snipets/cloud-init-etcd.yaml )

Після завершення розгортання вузла перевіримо чи є у нас SSH доступ до нього:

ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.12 -- ls -la

Налаштування вузлів etcd та їх приєднання до кластера

На нашому вузлі etcd ext-etcd-1, який вже працює, виконаємо наступну команду для отримання інструкцій для приєднання вузла ext-etcd-2 до кластера etcd. Після команди member add вкажемо назву вузла, який потрібно приєднати, а в параметрі --peer-urls шлях до нього

crictl exec $(crictl ps --label io.kubernetes.container.name=etcd --quiet) etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://10.10.0.11:2379 \
   member add ext-etcd-2 --peer-urls=https://10.10.0.12:2380

etcdctl зареєструє нового учасника кластера etcd, а у відповідь ми отримаємо його ID та рядок "ext-etcd-1=https://10.10.0.11:2380,ext-etcd-2=https://10.10.0.12:2380" з повним переліком вузлів кластера (разом з новим членом)

Member e3e9330902f761c3 added to cluster 3f0c3972eda275cb

ETCD_NAME="ext-etcd-2"
ETCD_INITIAL_CLUSTER="ext-etcd-1=https://10.10.0.11:2380,ext-etcd-2=https://10.10.0.12:2380"
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://10.10.0.12:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

Створення kubeadmcfg.yaml

Створіть файл налаштувань ~/kubeadmcfg.yaml на вузлі ext-etcd-2 замінивши значення змінних на ті що ви тільки що отримали після виконання команди … member add ….

Наступним обовʼязковим кроком є копіювання файлів ЦС з ext-etcd-1 на ext-etcd-2. Для зручності кроки з перенесення файлів ЦС було обʼєднано в скрипт який потрібно створити на вашій хост машині.

cat << 'EOF' > copy-etcd-ca.sh
#!/bin/bash

# --- Стандартні налаштування (змініть під себе) ---
DEFAULT_KEY="~/.ssh/k8s_cluster_key"
DEFAULT_SRC="10.10.0.11"
DEFAULT_DEST="10.10.0.12"
USER="k8sadmin"
CERT_PATH="/etc/kubernetes/pki/etcd"

# --- Присвоєння аргументів ---
# $1 - перший аргумент (хост-джерело), $2 - другий (хост-призначення), $3 - третій (шлях до ключа)
SRC_HOST=${1:-$DEFAULT_SRC}
DEST_HOST=${2:-$DEFAULT_DEST}
KEY=${3:-$DEFAULT_KEY}

echo "Використовуються параметри:"
echo "  Джерело:     ${SRC_HOST}"
echo "  Призначення: ${DEST_HOST}"
echo "  SSH Ключ:    ${KEY}"
echo "---------------------------------------"

# 1. Підготовка файлів на джерелі
echo "[1/4] Підготовка файлів на ${SRC_HOST}..."
ssh -i "${KEY}" "${USER}@${SRC_HOST}" "sudo cp $CERT_PATH/ca.* /tmp/ && sudo chown ${USER}:${USER} /tmp/ca.*" || exit 1

# 2. Передача файлів між хостами
echo "[2/4] Копіювання з ${SRC_HOST} на $DEST_HOST..."
scp -i "${KEY}" "${USER}@${SRC_HOST}:/tmp/ca.*" "${USER}@$DEST_HOST:/tmp/" || exit 1

# 3. Розміщення файлів на цільовому хості
echo "[3/4] Розміщення файлів на $DEST_HOST..."
ssh -i "${KEY}" "${USER}@$DEST_HOST" "sudo mkdir -p $CERT_PATH && sudo mv /tmp/ca.* $CERT_PATH/ && sudo chown root:root $CERT_PATH/ca.* && sudo chmod 600 $CERT_PATH/ca.key" || exit 1

# 4. Очищення
echo "[4/4] Видалення тимчасових файлів..."
ssh -i "${KEY}" "${USER}@${SRC_HOST}" "rm /tmp/ca.*"

echo "Файли ca.crt та ca.key успішно перенесено з ${SRC_HOST} до $DEST_HOST"
EOF

chmod +x copy-etcd-ca.sh

Виконайте перенесення файлів ЦС з хосту 10.10.0.11 до 10.10.0.12 командою (вкажіть ваші параметри за потреби):

./сopy-etcd-ca.sh 10.10.0.11 10.10.0.12

Тепер згенеруємо файли ключів та сертифікатів використовуючи створений файл kubeadmcfg.yaml на вузлі ext-etcd-2.

# 1. Генерація сертифікатів
sudo kubeadm init phase certs etcd-server --config=$HOME/kubeadmcfg.yaml
sudo kubeadm init phase certs etcd-peer --config=$HOME/kubeadmcfg.yaml
sudo kubeadm init phase certs etcd-healthcheck-client --config=$HOME/kubeadmcfg.yaml
sudo kubeadm init phase certs apiserver-etcd-client --config=$HOME/kubeadmcfg.yaml

Після створення необхідних файлів ключів та сертифікатів для другого вузла etcd видалимо файл з приватним ключем ЦС /etc/kubernetes/pki/etcd/ca.key, він тут більше не потрібен.

# 2. Видаляємо /etc/kubernetes/pki/etcd/ca.key
sudo rm -f /etc/kubernetes/pki/etcd/ca.key

Тепер коли ми маємо потрібні сертифікати на своїх місцях створимо маніфест для розгортання статичного пода.

sudo kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml

Через хвилину-дві переглянемо перелік вузлів нашого кластера etcd

crictl exec $(crictl ps --label io.kubernetes.container.name=etcd --quiet) etcdctl \
  --cert /etc/kubernetes/pki/etcd/peer.crt \
  --key /etc/kubernetes/pki/etcd/peer.key \
  --cacert /etc/kubernetes/pki/etcd/ca.crt \
  --endpoints https://10.10.0.11:2379  member list -w table

+------------------+---------+------------+-------------------------+-------------------------+------------+
|        ID        | STATUS  |    NAME    |       PEER ADDRS        |      CLIENT ADDRS       | IS LEARNER |
+------------------+---------+------------+-------------------------+-------------------------+------------+
| 86041dd24c0806ff | started | ext-etcd-1 | https://10.10.0.11:2380 | https://10.10.0.11:2379 |      false |
| e3e9330902f761c3 | started | ext-etcd-2 | https://10.10.0.12:2380 | https://10.10.0.12:2379 |      false |
+------------------+---------+------------+-------------------------+-------------------------+------------+

Для додавання наступного вузла кластера повторіть ті ж самі кроки що й для ext-etcd-2. Звертайте увагу на те що змінна ETCD_INITIAL_CLUSTER_STATE повинна мати значення "existing", а в змінній ETCD_INITIAL_CLUSTER для створення ~/kubeadmcfg.yaml на вузлі ext-etcd-3 потрібно буде зазначити всі вузли, які мають бути членами кластера. Для вузла ext-etcd-3 з IP 10.10.0.13 ця змінна матиме наступний вигляд:

ETCD_INITIAL_CLUSTER="ext-etcd-1=https://10.10.0.11:2380,ext-etcd-2=https://10.10.0.12:2380,ext-etcd-3=https://10.10.0.13:2380"
ETCD_INITIAL_CLUSTER_STATE="existing"

Скасування приєднання вузла до кластера

Якщо ви з будь-яких причин не хочете приєднувати вузол до кластера etcd, вам потрібно скасувати попередню команду приєднання. Для цього треба видалити цей вузол зі списку членів кластера за його ID. Навіть якщо вузол ще не запущений, він вже зареєстрований в кластері в стані unstarted.

Знайдіть ID потрібного вузла. Його можна знайти у першому рядку виводу команди приєднання, або ж через отримання списку всіх членів кластера:

crictl exec $(crictl ps --label io.kubernetes.container.name=etcd --quiet) etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://10.10.0.11:2379 \
   member list

У виводі ви побачите рядок, який виглядає приблизно так:
62f5145363dbf1b5, unstarted, ext-etcd-2, https://10.10.0.12:2380, ...

або в табличному вигляді

+------------------+-----------+------------+-------------------------+-------------------------+------------+
|        ID        |  STATUS   |    NAME    |       PEER ADDRS        |      CLIENT ADDRS       | IS LEARNER |
+------------------+-----------+------------+-------------------------+-------------------------+------------+
| 167ef81a292916d4 |   started | ext-etcd-2 | https://10.10.0.12:2380 | https://10.10.0.12:2379 |      false |
| 62f5145363dbf1b5 | unstarted |            | https://10.10.0.14:2380 |                         |      false |
| 86041dd24c0806ff |   started | ext-etcd-1 | https://10.10.0.11:2380 | https://10.10.0.11:2379 |      false |
| ba9a6c0afb514fec |   started | ext-etcd-3 | https://10.10.0.13:2380 | https://10.10.0.13:2379 |      false |
+------------------+-----------+------------+-------------------------+-------------------------+------------+

Скопіюйте ID (тут, 62f5145363dbf1b5) і виконайте команду видалення:

etcdctl \
   --cert /etc/kubernetes/pki/etcd/peer.crt \
   --key /etc/kubernetes/pki/etcd/peer.key \
   --cacert /etc/kubernetes/pki/etcd/ca.crt \
   --endpoints https://10.10.0.11:2379 \
   member remove <ID_ВУЗЛА>

💡 Так само відбувається видалення будь-якого вузла з переліку членів кластера. Якщо ви хочете замінити один вузол кластера іншим — спочатку видаліть “старий” вузол, після чого виконайте приєднання нового вузла.

Чому це важливо?

Якщо ви просто залишите вузол у статусі unstarted, etcd буде постійно намагатися з ним звʼязатися, що може призвести до збільшення затримок (latency) або проблем із досягненням кворуму в майбутньому.

Порада: Перед повторною спробою приєднання переконайтеся, що на новому вузлі (10.10.0.12) видалено стару теку даних etcd (data-dir), щоб він міг почати синхронізацію “з чистого аркуша” як новий член кластера.

Видалення data-dir

Шлях до теки даних (data-dir) залежить від того, як саме встановлено etcd (через kubeadm чи як окремий сервіс).

Якщо etcd працює як Static Pod (найчастіший випадок, kubeadm)

Перегляньте маніфест пода на вузлі, де etcd вже працює:
```
grep "data-dir" /etc/kubernetes/manifests/etcd.yaml
```
Зазвичай стандартний шлях у такому разі: /var/lib/etcd
Якщо etcd працює як системний сервіс (Systemd)

Якщо ви встановлювали etcd вручну або через бінарні файли, перевірте конфігурацію сервісу:
```
systemctl cat etcd | grep data-dir
```
Або подивіться у файлі конфігурації (якщо він є): /etc/etcd/etcd.conf.
Перевірка через інформацію про запущені процеси

Ви можете побачити шлях безпосередньо в аргументах запущеного процесу:
```
ps -ef | grep etcd | grep data-dir
```

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

Очистіть теку на вузлі перед його повторним запуском
```
rm -rf /var/lib/etcd/*
```
Зауваження: Переконайтеся, що ви видаляєте дані саме на потрібному вузлі.
Перевірте права доступу: Після очищення переконайтеся, що користувач, від якого працює etcd (зазвичай etcd або root), має права на запис у цю теку.

Налаштування балансувальника навантаження для вузлів панелі управління (HAProxy+Keepalived)

У кластері Kubernetes з HA-архітектурою балансувальник має бути піднятий ДО ініціалізації першого вузла панелі управління.

Це “правило першої цеглини”: ми не можемо побудувати стіну, якщо не визначили, де вона стоятиме. controlPlaneEndpoint — це точка входу, яка має бути доступною з першої секунди життя кластера.

Порядок дій, якому ми будемо слідувати:

Розгорнемо HAProxy+Keepalived (10.10.0.100)
- Не обовʼязково треба мати “живі” бекенди (вузли панелі управління) у цей момент, але балансувальник має слухати порт 6443 і бути доступним в мережі.
Додамо вузли панелі управління в конфіг HAProxy.
- Ми ще не запустили на першому вузлі kubeadm init, але додамо його та IP інших вузлів у бекенди HAProxy.
Запустимо kubeadm init на першому вузлі панелі управління.
- Коли kubeadm спробує “постукати” на 10.10.0.100:6443, балансувальник переспрямує цей запит на цей самий перший вузол (де API-сервер щойно піднявся), і операція ініціалізації завершиться успішно.
Приєднаємо інші вузли Control Plane.
- Використаємо kubeadm join ... --control-plane.

Тимчасовий “хак” (якщо не має можливості підняти HAProxy зараз)

Якщо у вас не має можливості розгорнути окрему машину для балансувальника прямо зараз, ви можете застосувати “маневр з IP-адресою”:

Тимчасово призначте IP 10.10.0.100 першому вузлу Control Plane як додаткову (через alias).
Виконайте kubeadm init. Система побачить “себе” за цією адресою і завершить налаштування.
Пізніше, коли ви розгорнете справжній HAProxy, перенесіть цей IP туди.

Створення налаштувань HAProxy+Keepalived

Для того щоб зробити наш балансувальник дійсно відмовостійким (High Availability), необхідно налаштувати Keepalived. Він дозволить двом вузлам HAProxy спільно використовувати одну “перехідну” IP-адресу (Virtual IP — VIP).

Налаштування Netplan

Залишимо адресу 10.10.0.100 для Keepalived, а в розділі мережевих налаштувань віртуальної машини HAProxy (у нас їх буде дві) зробимо наступне:

  - path: /etc/netplan/60-static-ip.yaml
    permissions: !!str '0600'
    content: |
      network:
        version: 2
        ethernets:
          enp0s2:
            addresses:
              - 10.10.0.101/24 # Реальна IP вузла LB1 (для другого буде .102)
            routes:
              - to: 10.10.0.0/24
                scope: link

вкажемо адресу 10.10.0.101 для основного балансувальника, а 10.10.0.102 — для резервного.

Конфігурація Keepalived

Додамо наступний блок у write_files. Ця конфігурація змусить Keepalived стежити за станом HAProxy і передавати VIP іншому вузлу, якщо сервіс або машина впаде.

write_files:
  - path: /etc/keepalived/keepalived.conf
    content: |
      vrrp_script check_haproxy {
          script "killall -0 haproxy" # Перевірка, чи живий процес
          interval 2
          weight 2
      }

      vrrp_instance VI_1 {
          state MASTER              # На другому вузлі вкажіть BACKUP
          interface enp0s2          # Назва вашого інтерфейсу
          virtual_router_id 51      # Має бути однаковим для обох LB
          priority 101              # На другому вузлі вкажіть 100
          advert_int 1

          authentication {
              auth_type PASS
              auth_pass k8s_secret  # Спільний пароль
          }

          virtual_ipaddress {
              10.10.0.100/24        # Ваша VIP адреса для Cluster Endpoint
          }

          track_script {
              check_haproxy
          }
      }

Налаштування ядра (Sysctl)

Щоб HAProxy міг “сісти” на IP-адресу 10.10.0.100, яка йому ще не належить (поки Keepalived не підняв її), потрібно дозволити nonlocal_bind.

Додамо це у write_files:

write_files:
  - path: /etc/sysctl.d/99-kubernetes-lb.conf
    content: |
      net.ipv4.ip_nonlocal_bind = 1

І додамо команди в runcmd для застосування:

runcmd:
  - sysctl --system
  - netplan apply
  - systemctl enable --now haproxy
  - systemctl enable --now keepalived

Як це працює разом

HAProxy слухає на порту 6443, але він “бачить” лише трафік, який приходить на VIP 10.10.0.100.
Keepalived тримає адресу 10.10.0.100 на активному вузлі (MASTER).
Коли ми запускаємо kubeadm init --control-plane-endpoint "10.10.0.100:6443", запит іде на VIP -> потрапляє в HAProxy -> перенаправляється на перший доступний вузол Control Plane.
Якщо перший балансувальник вимкнеться, другий (BACKUP) миттєво забере собі IP 10.10.0.100, і наш кластер Kubernetes продовжить роботу без розриву зʼєднання.

Для розгортання відмовостійкого балансувальника нам потрібно скласти до купи налаштування з:

snipets/cloud-init-config.yaml — налаштування часового поясу, та мережеві налаштування
snipets/cloud-init-user.yaml – будемо використовувати користувача k8sadmin, у якого групу containerd замінимо на haproxy
snipets/cloud-init-lb.yaml – налаштування специфічні для розгортання та запуску вузлів балансувальника

Створимо snipets/cloud-init-lb.yaml

cat << 'EOF' > snipets/cloud-init-lb.yaml

package_update: true
package_upgrade: true

packages:
  - haproxy
  - keepalived

write_files:
  - path: /etc/sysctl.d/99-haproxy.conf
    content: |
      net.ipv4.ip_nonlocal_bind = 1

  - path: /etc/haproxy/haproxy.cfg
    content: |
      global
          log /dev/log local0
          user haproxy
          group haproxy
          daemon
          stats socket /run/haproxy/admin.sock mode 660 level admin

      defaults
          log     global
          mode    tcp
          option  tcplog
          timeout connect 5000
          timeout client  50000
          timeout server  50000

      frontend k8s-api
          bind *:6443
          default_backend k8s-api-backend

      backend k8s-api-backend
          balance roundrobin
          option tcp-check
          timeout server 2h
          timeout client 2h
          # Тут ми прописуємо відомі нам параметри вузлів панелі управління
          server cp-1 10.10.0.21:6443 check check-ssl verify none fall 3 rise 2
          server cp-2 10.10.0.22:6443 check check-ssl verify none fall 3 rise 2
          server cp-3 10.10.0.23:6443 check check-ssl verify none fall 3 rise 2

      listen stats
          bind *:8404
          mode http
          stats enable
          stats uri /stats

  - path: /etc/keepalived/keepalived.conf
    content: |
      vrrp_script check_haproxy {
          script "killall -0 haproxy"
          interval 2
          weight 2
      }
      vrrp_instance VI_1 {
          state ${LB_STATE} # для lb1 буде MASTER, для lb2 буде BACKUP
          interface enp0s2
          virtual_router_id 51
          priority ${LB_PRIORITY} # для lb1 буде 101, для lb2 буде 100
          advert_int 1
          authentication {
              auth_type PASS
              auth_pass k8s_pwd # значення k8s_pwd потрібно замінити на найдійніший пароль
          }
          virtual_ipaddress {
              ${LB_IP} # загальна адреса балансувальника 10.10.0.100/24
          }
          track_script {
              check_haproxy
          }
      }

runcmd:
  - sysctl --system
  - systemctl enable --now haproxy
  - systemctl enable --now keepalived
EOF

Розгортання HAProxy+Keepalived

Створимо віртуальні машини для HAProxy+Keepalived:

Для створення відмовостійкого балансувальника нам знадобиться дві майже ідентичних команди для запуску. Основна різниця між ними полягає в налаштуваннях Keepalived (state та priority) та індивідуальних IP-адресах вузлів.

Запустимо перший вузол балансувальника

# Реальна IP адреса для інтерфейсу (netplan)
export VM_IP="10.10.0.101/24"

# Параметри для keepalived.conf
export LB_IP="10.10.0.100/24"
export LB_STATE="MASTER"
export LB_PRIORITY="101"

multipass launch --name lb1 \
  --cpus 1 --memory 1G --disk 5G \
  --network name=en0,mode=manual \
  --cloud-init <(yq eval-all '
    # 1. Злиття всіх файлів в один обʼєкт
    . as $item ireduce ({}; . *+ $item) |

    # 2. Виконання netplan apply після sysctl
    .runcmd |= (
      filter(. != "netplan apply") |
      (to_entries | .[] | select(.value == "sysctl --system") | .key) as $idx |
      .[:$idx+1] + ["netplan apply"] + .[$idx+1:]
    ) |
    .runcmd[].headComment = "" |

    # 3. Заміна групи користувача
    with(.users[] | select(.name == "k8sadmin");
      .groups |= sub("containerd", "haproxy")
    ) |

    # 4. Налаштування IP для застосування через Netplan
    with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
      .content |= (from_yaml | .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] | to_yaml)
    ) |

    # 5. Заміна змінних ${LB_...} у всіх файлах write_files
    with(.write_files[];
      .content |= sub("\${LB_STATE}", strenv(LB_STATE)) |
      .content |= sub("\${LB_PRIORITY}", strenv(LB_PRIORITY)) |
      .content |= sub("\${LB_IP}", strenv(LB_IP))
    )
  ' \
  snipets/cloud-init-config.yaml \
  snipets/cloud-init-user.yaml \
  snipets/cloud-init-lb.yaml)

І другий вузол балансувальника

# Реальна IP адреса для інтерфейсу (netplan)
export VM_IP="10.10.0.102/24"

# Параметри для keepalived.conf
export LB_IP="10.10.0.100/24"
export LB_STATE="BACKUP"
export LB_PRIORITY="100"

multipass launch --name lb2 \
  --cpus 1 --memory 1G --disk 5G \
  --network name=en0,mode=manual \
  --cloud-init <(yq eval-all '
    # 1. Злиття всіх файлів в один обʼєкт
    . as $item ireduce ({}; . *+ $item) |

    # 2. Виконання netplan apply після sysctl
    .runcmd |= (
      filter(. != "netplan apply") |
      (to_entries | .[] | select(.value == "sysctl --system") | .key) as $idx |
      .[:$idx+1] + ["netplan apply"] + .[$idx+1:]
    ) |
    .runcmd[].headComment = "" |

    # 3. Заміна групи користувача
    with(.users[] | select(.name == "k8sadmin");
      .groups |= sub("containerd", "haproxy")
    ) |

    # 4. Налаштування IP для застосування через Netplan
    with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
      .content |= (from_yaml | .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] | to_yaml)
    ) |

    # 5. Заміна змінних ${LB_...} у всіх файлах write_files
    with(.write_files[];
      .content |= sub("\${LB_STATE}", strenv(LB_STATE)) |
      .content |= sub("\${LB_PRIORITY}", strenv(LB_PRIORITY)) |
      .content |= sub("\${LB_IP}", strenv(LB_IP))
    )
  ' \
  snipets/cloud-init-config.yaml \
  snipets/cloud-init-user.yaml \
  snipets/cloud-init-lb.yaml)

Після запуску перевіримо наявність IP 10.10.0.100.

Зайдемо на будь-яку машину і перевіримо, чи зʼявилася адреса 10.10.0.100:

multipass exec lb1 -- ip addr show enp0s2

Що робити після запуску?

Перевірити статистику: Відкриємо в оглядачі http://10.10.0.100:8404/stats. Ми побачимо, що бекенди (наші вузли панелі управління) позначені червоним (бо вони ще не ініціалізовані) — це нормально.
Запуск Kubernetes: Тепер ми можемо запустити kubeadm init на першому вузлі Control Plane. Оскільки VIP 10.10.0.100 вже активний і HAProxy слухає порт 6443, помилка тайм-ауту не виникне.

Розгортання Control Plane

Зберемо налаштування cloud-init для розгортання вузлів нашої панелі управління. Вони будуть схожі на той що ми використовували для створення вузлів etcd але з деякими відмінностями.

Відповідно до рекомендацій виділимо вузлу панелі управління не менше ніж 2 ядра процесора та 2ГБ оперативної памʼяті. Для першого вузла панелі управління будемо використовувати IP адресу 10.10.0.21. Також встановимо HAProxy як локальний балансувальник навантаження для доступу до вузлів etcd.

Налаштування локального балансувальника навантаження для доступу до вузлів etcd

Для доступу до вузлів etcd розгорнемо локальний балансувальник навантаження. Кожен API-сервер буде звертатись до свого балансувальника навантаження (127.0.0.1:2379). Такий підхід називається “Sidecar Load Balancing” (або локальний проксі). Він забезпечує максимальну відмовостійкість: навіть якщо мережу між вузлами почне “штормити”, кожен API-сервер матиме свій локальний шлях до etcd.

Оскільки ми робимо це для кластера Kubernetes, найкращий спосіб реалізувати це — використати Static Pods. Керівник вузла (kubelet) сам запускатиме та підтримуватиме HAProxy.

Підготовка конфігурації HAProxy

Для вузлів панелі управління створимо файл з налаштуваннями HAProxy /etc/haproxy-lbaas/haproxy.cfg для балансування трафіку до вузлів etcd

cat << EOF > snipets/cloud-init-cp-haproxy.yaml
write_files:
  # Налаштування HAProxy для доступу до вузів etcd
  - path: /etc/haproxy-lbaas/haproxy.cfg
    content: |
      global
          log /dev/log local0
          user haproxy
          group haproxy

      defaults
          log global
          mode tcp
          option tcplog
          timeout connect 5000ms
          timeout client 50000ms
          timeout server 50000ms

      frontend etcd-local
          bind 127.0.0.1:2379
          description "Local proxy for etcd cluster"
          default_backend etcd-cluster

      backend etcd-cluster
          option tcp-check
          # Важливо: використовуємо roundrobin для розподілу навантаження
          balance roundrobin
          server etcd-1 10.10.0.11:2379 check inter 2000 rise 2 fall 3
          server etcd-2 10.10.0.12:2379 check inter 2000 rise 2 fall 3
          server etcd-3 10.10.0.13:2379 check inter 2000 rise 2 fall 3
EOF

Створення Static Pod для HAProxy

Змусимо kubelet запустити HAProxy. Створімо маніфест у теці статичних подів (стандартно це /etc/kubernetes/manifests/).

Створимо файл /etc/kubernetes/manifests/etcd-proxy.yaml з маніфестом статичного пода HAProxy:

cat << EOF > snipets/cloud-init-cp-haproxy-manifest.yaml
write_files:
  # Маніфест статичного пода HAProxy для балансування трафіку до вузлів etcd
  - path: /etc/kubernetes/manifests/etcd-haproxy.yaml
    content: |
      apiVersion: v1
      kind: Pod
      metadata:
        name: etcd-haproxy
        namespace: kube-system
        labels:
          component: etcd-haproxy
          tier: control-plane
      spec:
        containers:
        - name: etcd-haproxy
          image: haproxy:2.8-alpine # Використовуємо легкий образ
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
          volumeMounts:
          - name: haproxy-config
            mountPath: /usr/local/etc/haproxy/haproxy.cfg
            readOnly: true
        hostNetwork: true # Важливо: под має бачити 127.0.0.1 хоста
        volumes:
        - name: haproxy-config
          hostPath:
            path: /etc/haproxy-lbaas/haproxy.cfg
            type: File
EOF

Створення першого вузла панелі управління

Створимо перший вузол панелі управління cp-1 з IP 10.10.0.21/24

export VM_IP="10.10.0.21/24"

multipass launch --name cp-1 \
  --cpus 2 --memory 2.5G --disk 8G \
  --network name=en0,mode=manual \
  --cloud-init <( yq eval-all '
      # Злиття всіх файлів в один обʼєкт
      . as $item ireduce ({}; . *+ $item) |

      # Оновлення конфігурації мережі
      with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
        .content |= (
          from_yaml |
          .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] |
          to_yaml
        )
      ) ' \
      snipets/cloud-init-config.yaml \
      snipets/cloud-init-user.yaml \
      snipets/cloud-init-base.yaml \
      snipets/cloud-init-cp-haproxy.yaml \
      snipets/cloud-init-cp-haproxy-manifest.yaml)

Після створення вузла панелі управління скопіюємо наступні файли з будь-якого вузла etcd на перший вузол панелі управління (цього не треба буде робити для інших вузлів панелі управління впродовж перших двох годин після ініціалізації допоки Секрет з ключами не буде вилучений системою).

# 1. Підготуємо файли на початковому вузлі (10.10.0.11):
# Копіюємо у тимчасову теку і змінюємо власника на поточного користувача, щоб scp міг їх прочитати
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.11 " \
  mkdir -p /tmp/cert/ && \
  sudo cp /etc/kubernetes/pki/etcd/ca.crt /tmp/cert/ && \
  sudo cp /etc/kubernetes/pki/apiserver-etcd-client.* /tmp/cert/ && \
  sudo chown k8sadmin:k8sadmin /tmp/cert/* "

# 2. Перенесення файлів між вузлами через ваш локальний термінал:
# Використовуємо лапки для обробки wildcards (*) на віддаленому боці
scp -i ~/.ssh/k8s_cluster_key -r 'k8sadmin@10.10.0.11:/tmp/cert/' 'k8sadmin@10.10.0.21:/tmp'

# 3. Розміщення файлів на цільовому вузлі (10.10.0.21):
# Створюємо теку (якщо її немає), переміщуємо файли і повертаємо права root
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.21 " \
  sudo mkdir -p /etc/kubernetes/pki/etcd/ && \
  sudo mv /tmp/cert/ca.crt /etc/kubernetes/pki/etcd/ && \
  sudo chown root:root /etc/kubernetes/pki/etcd/ca.crt && \
  sudo mv /tmp/cert/apiserver-etcd-client.* /etc/kubernetes/pki/ && \
  sudo chown root:root /etc/kubernetes/pki/apiserver-etcd-client.*"

# 4. Очищення тимчасових файлів:
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.11 "rm -rf /tmp/cert"
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.21 "rm -rf /tmp/cert"

Перевірка використання Static Pods HAProxy

Ми поклали маніфест etcd-proxy.yaml у /etc/kubernetes/manifests/. Проте kubelet ігнорує цю теку, доки не отримає команду на запуск (це відбудеться після ініціалізації вузла панелі управління).

Крім того, на етапі preflight команда kubeadm намагається перевірити доступність etcd до того, як почне працювати будь-який компонент кластера. Оскільки наш HAProxy має працювати як Pod, він ще не запущений, порт 127.0.0.1:2379 закритий — і ми отримаємо connection refused під час спроби ініціалізації вузла панелі управління.

[preflight] Running pre-flight checks
	[WARNING ExternalEtcdVersion]: Get "https://127.0.0.1:2379/version": dial tcp 127.0.0.1:2379: connect: connection refused

Після ініціалізації вузла панелі управління є кілька способів перевірити працездатність звʼязку з etcd через локальний HAProxy:

Перевірка через cURL (найшвидший спосіб)

Оскільки ми використовуємо TLS, нам знадобляться сертифікати, які ми вже підготували для kubeadm. Спробуємо звернутися до etcd через локальний порт:
```
sudo curl --cacert /etc/kubernetes/pki/etcd/ca.crt \
     --cert /etc/kubernetes/pki/apiserver-etcd-client.crt \
     --key /etc/kubernetes/pki/apiserver-etcd-client.key \
     https://127.0.0.1:2379/health
```
Очікуваний результат: {"health":"true"}. Якщо у нас є ця відповідь, значить HAProxy успішно прокидає трафік до одного з вузлів нашого кластера etcd.
Перевірка стану Static Pod

Перевіримо, чи взагалі запустився контейнер HAProxy. Оскільки kubectl може не працювати, якщо etcd недоступний, використовуйте інструмент середовища виконання контейнерів (в нашому випадку crictl):
```
# Для containerd (стандарт для сучасних K8s)
sudo crictl ps | grep etcd-haproxy

# Перегляд логів проксі
sudo crictl logs $(sudo crictl ps -q --name etcd-haproxy)
```
У логах HAProxy ви мають бути записи про успішні перевірки справності (Health check passed) для бекенд-вузлів 10.10.0.11, .12, .13.
Перевірка через системні сокети

Переконаймося, що HAProxy дійсно слухає порт 2379 на локальному інтерфейсі:
```
sudo ss -tulpn | grep 2379
```
Ми маємо побачити, що процес (haproxy) слухає 127.0.0.1:2379.

Налаштування kubeadm

Створимо на першому візлі в домашній теці користувача k8sadmin файл kubeadm-config.yaml для ініціалізації панелі управління

ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.21 "cat << 'EOF' > \$HOME/kubeadm-config.yaml
---
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: \"v1.34.3\"
controlPlaneEndpoint: \"10.10.0.100:6443\"
etcd:
  external:
    endpoints:
      - https://127.0.0.1:2379
    caFile: /etc/kubernetes/pki/etcd/ca.crt
    certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
    keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
networking:
  serviceSubnet: \"10.96.0.0/16\"
  podSubnet: \"10.244.0.0/16\"
  dnsDomain: \"cluster.local\"
EOF"

Запуск ініціалізації та оминання перевірки ExternalEtcdVersion

Коли kubeadm init починає роботу він намагається перевірити доступ до зовнішнього кластера etcd. Однак ми «завернули» доступ до кластера у локальний HAProxy, який kubelet запускає як статичний под. Однак на цей момент у нас ще не запущено kube-apiserver який візьме на себе керування kubelet, який своєю чергою запустить под з haproxy. Тому нам потрібно вимкнути “передполітні перевірки” для etcd (--ignore-preflight-errors=ExternalEtcdVersion). Для ініціалізації кластера на вузлі панелі управління виконайте наступну команду:

sudo kubeadm init \
  --config $HOME/kubeadm-config.yaml \
  --upload-certs \
  --ignore-preflight-errors=ExternalEtcdVersion

На що звернути увагу під час ініціалізації:

Після запуску команди стежте за етапом [control-plane] Creating static pod manifest for "kube-apiserver". Якщо API-сервер успішно запуститься, це означатиме, що він зміг підключитися до etcd через ваш локальний проксі.

Якщо команда знову зупиниться на помилці, перевірте, чи не залишилося в системі процесів від попередніх спроб:

# Якщо потрібно повністю скинути стан перед новою спробою
sudo kubeadm reset -f
# Після reset треба буде знову перезапустити kubelet, щоб піднявся проксі
sudo systemctl restart kubelet

За нормальних обставин ви побачите наступний лог роботи kubeadm init

Подивитись лог

[init] Using Kubernetes version: v1.34.3
[preflight] Running pre-flight checks
	[WARNING ExternalEtcdVersion]: Get "https://127.0.0.1:2379/version": dial tcp 127.0.0.1:2379: connect: connection refused
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [cp-1 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.2.176 10.10.0.100]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] External etcd mode: Skipping etcd/ca certificate authority generation
[certs] External etcd mode: Skipping etcd/server certificate generation
[certs] External etcd mode: Skipping etcd/peer certificate generation
[certs] External etcd mode: Skipping etcd/healthcheck-client certificate generation
[certs] External etcd mode: Skipping apiserver-etcd-client certificate generation
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "super-admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/instance-config.yaml"
[patches] Applied patch of type "application/strategic-merge-patch+json" to target "kubeletconfiguration"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests"
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 501.932756ms
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://192.168.2.176:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-controller-manager is healthy after 1.515332016s
[control-plane-check] kube-scheduler is healthy after 19.381430245s
[control-plane-check] kube-apiserver is healthy after 21.504025006s
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
7a088e936453ab3143f25cdb9827b8cac60888c75f91b9d6c2d08d23a32a2bc9
[mark-control-plane] Marking the node cp-1 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node cp-1 as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: z28v5d.4vm6rzekoibear23
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of control-plane nodes running the following command on each as root:

  kubeadm join 10.10.0.100:6443 --token z28v5d.4vm6rzekoibear23 \
	--discovery-token-ca-cert-hash sha256:4c23033729b477d1fc30ae4b4041fe7dae70fa8defd5ecb57c571e969e00f8e0 \
	--control-plane --certificate-key 7a088e936453ab3143f25cdb9827b8cac60888c75f91b9d6c2d08d23a32a2bc9

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 10.10.0.100:6443 --token z28v5d.4vm6rzekoibear23 \
	--discovery-token-ca-cert-hash sha256:4c23033729b477d1fc30ae4b4041fe7dae70fa8defd5ecb57c571e969e00f8e0

Після запуску ініціалізації з ігноруванням помилок, нам важливо переконатися, що API-сервер дійсно зміг підключитися до бази даних, а не просто “висить” у стані очікування.

Головна перевірка: Стан API-сервера

Якщо kubeadm init пройшов далі етапу preflight, він спробує запустити kube-apiserver. Якщо API-сервер не може звʼязатися з etcd через наш проксі, він буде постійно перезавантажуватися.

Перевіримо логи API-сервера:

sudo tail -f /var/log/pods/kube-system_kube-apiserver-*/kube-apiserver/*.log

Подивитись лог API-сервера

k8sadmin@cp-1:~$ sudo tail -f /var/log/pods/kube-system_kube-apiserver-cp-1_70e58895431aff7a0cb441009519f1c6/kube-apiserver/0.log
2026-01-07T11:10:20.602046303+02:00 stderr F W0107 09:10:20.601902       1 logging.go:55] [core] [Channel #359 SubChannel #360]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: authentication handshake failed: context canceled"
2026-01-07T11:10:20.617773217+02:00 stderr F W0107 09:10:20.617570       1 logging.go:55] [core] [Channel #363 SubChannel #364]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:2379: operation was canceled"
2026-01-07T11:10:20.634721419+02:00 stderr F W0107 09:10:20.634607       1 logging.go:55] [core] [Channel #367 SubChannel #368]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: authentication handshake failed: context canceled"
2026-01-07T11:10:20.644114716+02:00 stderr F W0107 09:10:20.644002       1 logging.go:55] [core] [Channel #371 SubChannel #372]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:2379: operation was canceled"
2026-01-07T11:10:20.662781139+02:00 stderr F W0107 09:10:20.662426       1 logging.go:55] [core] [Channel #375 SubChannel #376]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:2379: operation was canceled"
2026-01-07T11:10:20.675026234+02:00 stderr F W0107 09:10:20.674872       1 logging.go:55] [core] [Channel #379 SubChannel #380]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: authentication handshake failed: context canceled"
2026-01-07T11:10:20.860920026+02:00 stderr F W0107 09:10:20.860664       1 logging.go:55] [core] [Channel #383 SubChannel #384]grpc: addrConn.createTransport failed to connect to {Addr: "127.0.0.1:2379", ServerName: "127.0.0.1:2379", BalancerAttributes: {"<%!p(pickfirstleaf.managedByPickfirstKeyType={})>": "<%!p(bool=true)>" }}. Err: connection error: desc = "transport: Error while dialing: dial tcp 127.0.0.1:2379: operation was canceled"
2026-01-07T11:11:10.4594371+02:00 stderr F I0107 09:11:10.459184       1 controller.go:667] quota admission added evaluator for: replicasets.apps
2026-01-07T11:19:59.613078541+02:00 stderr F I0107 09:19:59.612638       1 cidrallocator.go:277] updated ClusterIP allocator for Service CIDR 10.96.0.0/16

Цей лог свідчить про дуже важливий етап: наш kube-apiserver успішно запустився, але процес ініціалізації пройшов через “боротьбу” за звʼязок з etcd.

Ось що сталося:

Етап помилок (Handshake failed)

Перші рядки логу показують помилки: transport: authentication handshake failed: context canceled та dial tcp 127.0.0.1:2379: operation was canceled.

Це означає що:
- API-сервер намагався підключитися до вашого HAProxy (127.0.0.1:2379).
- Зʼєднання встановлювалося, але TLS-рукостискання (handshake) обривалося.
Причина: Це відбувалося в той самий момент, коли kubeadm ще генерував або підкладав сертифікати, або коли HAProxy ще не встиг встановити стабільну сесію з бекенд-вузлами etcd. Це нормальна поведінка під час “холодного” старту панелі управління.
Етап успіху (Стабілізація)

Зверніть увагу на останні рядки: I0107 09:11:10.459184 ... quota admission added evaluator for: replicasets.apps, I0107 09:19:59.612638 ... updated ClusterIP allocator for Service CIDR 10.96.0.0/16

Це перемога:
- API-сервер живий. Якби він не зміг підключитися до etcd, він би просто завершив роботу з помилкою (CrashLoopBackOff) і ви б не побачили логів про cidrallocator.
Повідомлення про ClusterIP allocator означає, що API-сервер вже почав записувати дані в etcd і керувати ресурсами кластера.

Інтервал між записами (10 хвилин) показує стабільну фонову роботу контролерів.

Стан компонентів

Те, що ви бачите теки для kube-controller-manager та kube-scheduler у /var/log/pods/, підтверджує, що kubeadm успішно пройшов фазу створення маніфестів і всі три основні компоненти Control Plane запущені.

k8sadmin@cp-1:~$ sudo ls -la /var/log/pods/
total 28
drwxr-x---  7 root root   4096 Jan  8 22:23 .
drwxr-xr-x 11 root syslog 4096 Jan  8 22:23 ..
drwxr-xr-x  3 root root   4096 Jan  8 22:23 kube-system_etcd-haproxy-cp-1_e2b3a81fe56706e845a17ba096c5dfad
drwxr-xr-x  3 root root   4096 Jan  8 22:23 kube-system_kube-apiserver-cp-1_e74afa6943effdf6bbdcfc384bd87bb6
drwxr-xr-x  3 root root   4096 Jan  8 22:23 kube-system_kube-controller-manager-cp-1_b635ba5e5439cc2c581bf61ca1e6fb9e
drwxr-xr-x  3 root root   4096 Jan  8 22:23 kube-system_kube-proxy-9qh54_9e21026d-0d6e-4f8c-a071-842149ffd24e
drwxr-xr-x  3 root root   4096 Jan  8 22:23 kube-system_kube-scheduler-cp-1_0cf013b3f4c49c84241ee3a56735a15d

Що перевірити зараз?

Оскільки API-сервер відповідає, виконайте наступні команди, щоб остаточно переконатися в справності першого вузла:

Перевірка вузлів: kubectl get nodes (Ви маєте побачити cp-1 у статусі NotReady — це нормально, бо ми ще не встановили Calico).
Перевірка працездатності проксі (через HAProxy): kubectl get --raw /healthz/etcd (Має повернути ok).
Перевірка точок доступу etcd: kubectl describe pod kube-apiserver-cp-1 -n kube-system | grep etcd (Переконайтеся, що там фігурує лише https://127.0.0.1:2379).
Перевірка HAProxy: перейдіть за посиланням http://10.10.0.100:8404/stats в інфопанель балансувальника навантаження панелі управління (В розділі k8s-api-backend статус першого вузла панелі управління має бути UP)

Далі рекомендується розгорнути CNI-втулок для мережі подів.

Встановлення Calico

Для створення мережі подів скористаємось Calico. Стаття «Install Calico networking and network policy for on-premises deployments» докладно описує процес встановлення Calico на власному обладнані.

Ми будемо використовувати Tigera Operator та визначення власних ресурсів (CRDs, custom resource definitions). Застосуємо наступні два маніфести:

kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.31.3/manifests/operator-crds.yaml
kubectl create -f https://raw.githubusercontent.com/projectcalico/calico/v3.31.3/manifests/tigera-operator.yaml

Після чого завантажимо файл з власними ресурсами потрібними для налаштування Calico.

curl -O https://raw.githubusercontent.com/projectcalico/calico/v3.31.3/manifests/custom-resources-bpf.yaml

та вкажемо CIDR мережі подів таке саме, що ми його вказали під час ініціалізації першого вузла панелі управління — 10.244.0.0/16 (стандартне значення в Calico — cidr: 192.168.0.0/16).

Після внесення змін застосуємо маніфест для встановлення Calico

kubectl create -f custom-resources-bpf.yaml

Відстежуватимемо встановлення за допомогою команді watch kubectl get tigerastatus. Через кілька хвилин (6-7 хвилин) усі компоненти Calico будуть мати значення True у стовпці AVAILABLE.

NAME                            AVAILABLE   PROGRESSING   DEGRADED   SINCE
apiserver                       True        False         False      4m9s
calico                          True        False         False      3m29s
goldmane                        True        False         False      3m39s
ippools                         True        False         False      6m4s
kubeproxy-monitor               True        False         False      6m15s
whisker                         True        False         False      3m19s

Як тільки компоненти Calico стануть доступними, вузол панелі управління перейде в стан READY.

Що роботи спочатку: розгортати Calico чи виконувати kubeadm join?

Технічно можна і так, і так, але варіант №1 (CNI перед Join) є кращою практикою.

Варіант 1: Спершу CNI, потім Join (Рекомендовано)

Коли ви встановлюєте CNI одразу після ініціалізації першого вузла (cp-1), мережа кластера стає робочою негайно.

Статус Node: Перший вузол швидко переходить у стан Ready.
CoreDNS: Поди CoreDNS, які зазвичай висять у стані Pending без мережі, запускаються.
Приєднання нових вузлів: Коли ви приєднуєте cp-2 та cp-3, вони одразу отримують мережеві налаштування. Системні поди на нових вузлах зможуть швидше почати комунікацію між собою.
Зручність: Ви бачите реальний стан справності кожного нового вузла одразу після його приєднання.

Варіант 2: Спершу Join, потім CNI

Це теж робочий сценарій, але він виглядає більш “тривожно” під час процесу.

Статус Node: Усі вузли (cp-1, cp-2, cp-3) будуть у стані NotReady.
CoreDNS: Всі системні мережеві компоненти будуть чекати.
Приєднання: kubeadm join пройде успішно, оскільки для самого процесу приєднання (TLS Bootstrap та копіювання конфігів) CNI не потрібен — тут використовується фізична мережа між вузлами.
Ризики: Якщо під час приєднання виникне проблема з мережевою комунікацією самих подів (наприклад, health-checks системних компонентів), вам буде складніше зрозуміти — чи це проблема join, чи просто відсутність CNI.

Рекомендується дотримуватися наступного порядку:

kubeadm init на cp-1.
Потрібні налаштування kubeconfig.
Встановлення CNI (наприклад, Cilium, Calico або Flannel).
Перевірка kubectl get nodes (має бути Ready).
Перенесення сертифікатів на нові вузли (за потреби).
kubeadm join для cp-2 та cp-3.

Розгортання та приєднання наступних вузлів панелі управління

Скористаймось вже готовою командою для першого вузла панелі управління. Замінимо IP адресу на відповідну для кожного вузла:

cp-2.yaml — 10.10.0.22
cp-3.yaml — 10.10.0.23

Створимо віртуальні машини:

export VM_IP="10.10.0.22/24"

multipass launch --name cp-2 \
  --cpus 2 --memory 2.5G --disk 8G \
  --network name=en0,mode=manual \
  --cloud-init <( yq eval-all '
      # Злиття всіх файлів в один обʼєкт
      . as $item ireduce ({}; . *+ $item) |

      # Оновлення конфігурації мережі
      with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
        .content |= (
          from_yaml |
          .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] |
          to_yaml
        )
      ) ' \
      snipets/cloud-init-config.yaml \
      snipets/cloud-init-user.yaml \
      snipets/cloud-init-base.yaml \
      snipets/cloud-init-cp-haproxy.yaml \
      snipets/cloud-init-cp-haproxy-manifest.yaml)

Дочекаємось готовності вузла та приєднаємо його як ще один вузол панелі управління. Скористаймось виводом отриманим під час ініціалізації першого вузла панелі управління та додамо до нього параметр --ignore-preflight-errors=ExternalEtcdVersion, так само як ми це робили під час ініціалізації першого вузла панелі управління:

sudo kubeadm join 10.10.0.100:6443 --token z28v5d.4vm6rzekoibear23 \
        --discovery-token-ca-cert-hash sha256:4c23033729b477d1fc30ae4b4041fe7dae70fa8defd5ecb57c571e969e00f8e0 \
        --control-plane --certificate-key 7a088e936453ab3143f25cdb9827b8cac60888c75f91b9d6c2d08d23a32a2bc9 \
        --ignore-preflight-errors=ExternalEtcdVersion

Лог виконання приєднання другого вузла панелі управління виглядатиме наступним чином

Подивитись лог приєднання другого вузла

k8sadmin@cp-2:~$ sudo kubeadm join 10.10.0.100:6443 --token z28v5d.4vm6rzekoibear23 \
        --discovery-token-ca-cert-hash sha256:4c23033729b477d1fc30ae4b4041fe7dae70fa8defd5ecb57c571e969e00f8e0 \
        --control-plane --certificate-key 7a088e936453ab3143f25cdb9827b8cac60888c75f91b9d6c2d08d23a32a2bc9 \
        --ignore-preflight-errors=ExternalEtcdVersion
[preflight] Running pre-flight checks
[preflight] Reading configuration from the "kubeadm-config" ConfigMap in namespace "kube-system"...
[preflight] Use 'kubeadm init phase upload-config kubeadm --config your-config-file' to re-upload it.
[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[download-certs] Saving the certificates to the folder: "/etc/kubernetes/pki"
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [cp-2 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.2.177 10.10.0.100]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Skipping etcd check in external mode
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/instance-config.yaml"
[patches] Applied patch of type "application/strategic-merge-patch+json" to target "kubeletconfiguration"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[control-plane-join] Using external etcd - no local stacked instance added
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 1.005951104s
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap
[mark-control-plane] Marking the node cp-2 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node cp-2 as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://192.168.2.177:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-controller-manager is healthy after 2.950097ms
[control-plane-check] kube-scheduler is healthy after 6.396945ms
[control-plane-check] kube-apiserver is healthy after 501.413278ms

This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.


To start administering your cluster from this node, you need to run the following as a regular user:

	mkdir -p $HOME/.kube
	sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
	sudo chown $(id -u):$(id -g) $HOME/.kube/config

Run 'kubectl get nodes' to see this node join the cluster.

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

[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
error: error execution phase control-plane-prepare/download-certs: error downloading certs: error downloading the secret: Secret "kubeadm-certs" was not found in the "kube-system" Namespace. This Secret might have expired. Please, run `kubeadm init phase upload-certs --upload-certs` on a control plane to generate a new one

Оскільки ми використовуємо зовнішній etcd (External Etcd), стандартна процедура upload-certs не працює так, як описано в більшості інструкцій, тому що Kubernetes з міркувань безпеки не зберігає ключі до зовнішньої бази даних у своїх секретах.

Якщо нам треба буде додати наступний вузол або відновити поточний потрібно виконати кілька додаткових кроків.

Цей метод використовується, коли автоматичне завантаження ключів (--certificate-key) неможливе або термін зберігання секрету з ключами сплив.

Підготовка файлової системи на новому вузлі

На новому вузлі (наприклад, cp-4) створіть необхідні теки для сертифікатів та маніфестів.
```
# На новому вузлі
sudo mkdir -p /etc/kubernetes/pki/etcd
sudo mkdir -p /etc/kubernetes/manifests
```

Ручне перенесення сертифікатів

Нам потрібно скопіювати 9 файлів з будь-якого працюючого вузла панелі управління (наприклад з cp-1) на новий вузол. Шляхи мають повністю збігатись.

Файл на джерелі (cp-1)	Куди класти на новому (cp-4)	Опис
`/etc/kubernetes/pki/ca.crt`	`/etc/kubernetes/pki/ca.crt`	CA кластера
`/etc/kubernetes/pki/ca.key`	`/etc/kubernetes/pki/ca.key`	Ключ CA
`/etc/kubernetes/pki/sa.pub`	`/etc/kubernetes/pki/sa.pub`	Ключ ServiceAccount (публічний)
`/etc/kubernetes/pki/sa.key`	`/etc/kubernetes/pki/sa.key`	Ключ ServiceAccount (приватний)
`/etc/kubernetes/pki/front-proxy-ca.crt`	`/etc/kubernetes/pki/front-proxy-ca.crt`	CA для агрегації API
`/etc/kubernetes/pki/front-proxy-ca.key`	`/etc/kubernetes/pki/front-proxy-ca.key`	Ключ Front Proxy
`/etc/kubernetes/pki/apiserver-etcd-client.crt`	`/etc/kubernetes/pki/apiserver-etcd-client.crt`	Клієнтський серт. для etcd
`/etc/kubernetes/pki/apiserver-etcd-client.key`	`/etc/kubernetes/pki/apiserver-etcd-client.key`	Клієнтський ключ для etcd
`/etc/kubernetes/pki/etcd/ca.crt`	`/etc/kubernetes/pki/etcd/ca.crt`	CA самого etcd

Важливо: Після копіювання встановіть правильні права на файли ключів (.key), інакше kubeadm може сваритися на безпеку:

sudo chmod 600 \
  /etc/kubernetes/pki/apiserver-etcd-client.key \
  /etc/kubernetes/pki/ca.key \
  /etc/kubernetes/pki/front-proxy-ca.key  \
  /etc/kubernetes/pki/sa.key

Примітка: Якщо ви не бажаєте вручну копіювати всі 9 файлів ключів та сертифікатів, а обмежитись лише копіюванням файлів /etc/kubernetes/pki/etcd/ca.crt, /etc/kubernetes/pki/apiserver-etcd-client.key та /etc/kubernetes/pki/apiserver-etcd-client.crt на цільову машину, ви можете спочатку запустити команду приєднання з параметром --certificate-key (як у випадку Stacked Etcd), що допоможе скопіювати більшість потрібних фалів тих якими опікується apiserver. Після цього скопіюйте вручну три файли для etcd та запустіть команду приєднання без параметра --certificate-key.

Для прискорення процесу копіювання можна скористатись наступним скриптом

cat << 'EOF' > k8s-transit.sh
#!/bin/bash

# Як використовувати
#  "Використання: $0 <SRC_IP> <DST_IP> <USER> [SSH_KEY_PATH]"
#  "Приклад: k8s-transit.sh 10.10.0.21 10.10.0.178 k8sadmin ~/.ssh/id_rsa"

# --- СТАНДАРТНІ ЗНАЧЕННЯ ---
DEFAULT_SRC="10.10.0.21"
DEFAULT_DST="10.10.0.178"
DEFAULT_USR="k8sadmin"
DEFAULT_KEY="~/.ssh/k8s_cluster_key"
# ---------------------------

SRC=${1:-$DEFAULT_SRC}
DST=${2:-$DEFAULT_DST}
USR=${3:-$DEFAULT_USR}
KEY_PATH=${4:-$DEFAULT_KEY}

# Формуємо опцію для SSH-ключа
SSH_OPTS=""
if [ -f "$(eval echo $KEY_PATH)" ]; then
    SSH_OPTS="-i $KEY_PATH"
fi

echo "🚀 Використовуємо конфігурацію:"
echo "   Джерело (SRC): $SRC"
echo "   Ціль (DST):    $DST"
echo "   Користувач:    $USR"
echo "   Ключ SSH:      ${KEY_PATH:-'стандартно'}"
echo "----------------------------------------------------"

# Список файлів
FILES=(
    "/etc/kubernetes/pki/ca.crt"
    "/etc/kubernetes/pki/ca.key"
    "/etc/kubernetes/pki/sa.pub"
    "/etc/kubernetes/pki/sa.key"
    "/etc/kubernetes/pki/front-proxy-ca.crt"
    "/etc/kubernetes/pki/front-proxy-ca.key"
    "/etc/kubernetes/pki/apiserver-etcd-client.crt"
    "/etc/kubernetes/pki/apiserver-etcd-client.key"
    "/etc/kubernetes/pki/etcd/ca.crt"
)

# 1. Підготовка тек
ssh $SSH_OPTS -t $USR@$DST "sudo mkdir -p /etc/kubernetes/pki/etcd"

# 2. Транзит файлів
for FILE in "${FILES[@]}"; do
    echo "Передаю: $FILE"
    ssh $SSH_OPTS $USR@$SRC "sudo cat $FILE" | ssh $SSH_OPTS $USR@$DST "sudo tee $FILE > /dev/null"
done

# 3. Налаштування власника та прав доступу
echo "🔒 Зміна власника на root та налаштування прав на $DST..."
ssh $SSH_OPTS -t $USR@$DST " \
    sudo chown -R root:root /etc/kubernetes/pki && \
    sudo chmod 644 /etc/kubernetes/pki/*.crt /etc/kubernetes/pki/sa.pub && \
    sudo chmod 600 /etc/kubernetes/pki/*.key /etc/kubernetes/pki/sa.key"

echo "✅ Успішно завершено!"
EOF

chmod +x k8s-transit.sh

Налаштування доступу до etcd (Local Proxy)

Оскільки ми використовуємо архітектуру, де кожен вузол спілкується з etcd через локальний проксі (HAProxy), переконаймося, що маніфест проксі вже лежить на новому вузлі.

Якщо ні — скопіюймо файл etcd-haproxy.yaml з cp-1 в теку /etc/kubernetes/manifests/ на новому вузлі. Це гарантує, що як тільки запуститься kubelet, він підніме зв’язок з базою даних.
Генерація команди Join (на працюючому вузлі)

На працюючому вузлі (cp-1) згенеруємо токен і хеш. Нам не потрібен ключ сертифіката, бо ми вже перенесли файли вручну.
```
# На cp-1
kubeadm token create --print-join-command
```
В результаті ми отримаємо команду вигляду: kubeadm join 10.10.0.100:6443 --token <token> --discovery-token-ca-cert-hash <hash>

Запуск приєднання (на новому вузлі)

Запустімо отриману команду на новому вузлі, додавши прапорець --control-plane. ⚠️ Не додавайте --certificate-key.

# На новому вузлі
sudo kubeadm join 10.10.0.100:6443 \
    --token <ваш_токен> \
    --discovery-token-ca-cert-hash sha256:<ваш_хеш> \
    --control-plane \
    --ignore-preflight-errors=ExternalEtcdVersion

Подивитись лог приєднання вузла

k8sadmin@cp-4:~$ sudo kubeadm join 10.10.0.100:6443 --token efwfq8.puh8nqqk3a3dqqdx --discovery-token-ca-cert-hash sha256:4c23033729b477d1fc30ae4b4041fe7dae70fa8defd5ecb57c571e969e00f8e0 --control-plane --ignore-preflight-errors=ExternalEtcdVersion
[preflight] Running pre-flight checks
[preflight] Reading configuration from the "kubeadm-config" ConfigMap in namespace "kube-system"...
[preflight] Use 'kubeadm init phase upload-config kubeadm --config your-config-file' to re-upload it.
[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [cp-4 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.2.179 10.10.0.100]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Skipping etcd check in external mode
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/instance-config.yaml"
[patches] Applied patch of type "application/strategic-merge-patch+json" to target "kubeletconfiguration"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[control-plane-join] Using external etcd - no local stacked instance added
[kubelet-check] Waiting for a healthy kubelet at http://127.0.0.1:10248/healthz. This can take up to 4m0s
[kubelet-check] The kubelet is healthy after 503.676345ms
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap
[mark-control-plane] Marking the node cp-4 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node cp-4 as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[control-plane-check] Waiting for healthy control plane components. This can take up to 4m0s
[control-plane-check] Checking kube-apiserver at https://192.168.2.179:6443/livez
[control-plane-check] Checking kube-controller-manager at https://127.0.0.1:10257/healthz
[control-plane-check] Checking kube-scheduler at https://127.0.0.1:10259/livez
[control-plane-check] kube-scheduler is healthy after 9.840373ms
[control-plane-check] kube-controller-manager is healthy after 11.326085ms
[control-plane-check] kube-apiserver is healthy after 21.681901ms

This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.


To start administering your cluster from this node, you need to run the following as a regular user:

	mkdir -p $HOME/.kube
	sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
	sudo chown $(id -u):$(id -g) $HOME/.kube/config

Run 'kubectl get nodes' to see this node join the cluster.

Якщо у вас Stacked Etcd наступної команди для отримання нових інструкцій для приєднання вузлів до кластера буде цілком достатньо. В такій архітектурі kubeadm повністю автоматизує процес: він завантажує всі необхідні сертифікати (включаючи ті, що потрібні для створення нового вузла члена etcd) у секрет kubeadm-certs.

# На вузлі cp-1
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.21
sudo -sE
$(kubeadm token create --print-join-command) --control-plane --certificate-key $(kubeadm init phase upload-certs --upload-certs | tail -1)

Це працює для Stacked Etcd:

upload-certs: На відміну від External Etcd, у Stacked-режимі kubeadm знає про всі локальні сертифікати etcd і упаковує їх у пакунок.
--certificate-key: Ви отримуєте ключ розшифрування, який дозволяє новому вузлу автоматично завантажити цей пакунок у свою теку /etc/kubernetes/pki/.
Автоматизація: Новому вузлу не потрібно нічого копіювати вручну — він сам створить і сертифікати Kubernetes, і локальну копію etcd, приєднавши її до наявних учасників.

Ця команда чудово працює, однак: kubeadm init phase upload-certs --upload-certs завантажує сертифікати в секрет лише на 2 години.

Якщо ви плануєте додавати вузли пізніше, вам доведеться запускати цю команду знову. Якщо ж ви робите це “тут і зараз” — це ідеальний і найшвидший спосіб.

Порада: Якщо на новому вузлі вже були невдалі спроби приєднання, перед запуском нової команди обовʼязково зробіть sudo kubeadm reset -f.

Відʼєднання та заміна вузла панелі управління

Виведення вузла панелі управління, якщо він вийшов з ладу, або для його заміни, в архітектурі з External Etcd має суттєву перевагу: оскільки база даних знаходиться поза межами вузлів Kubernetes, ви ризикуєте лише доступністю API, а не цілісністю даних.

Для видалення вузла панелі управління (наприклад, cp-2) з кластера виконайте наступні кроки.

Підготовка кластера

Виконуйте ці дії на іншому справному вузлі (наприклад, cp-1) або спілкуйтесь з панеллю управління через адресу балансувальника HAProxy.
- Видаліть навантаження з вузла: Дозвольте завершити поточні завдання та забороніть призначення нових подів
```
kubectl cordon cp-2
kubectl drain cp-2 --ignore-daemonsets --delete-emptydir-data
```
- Видаліть вузол з реєстру Kubernetes: Це видалить обʼєкт Node та відповідні сертифікати (якщо використовується авторотація).
```
kubectl delete node cp-2
```
Очищення самого вузла (на cp-2)

Тепер перейдіть на вузол, який потрібно відʼєднати.
- Скидання налаштувань kubeadm: Це видалить маніфести статичних подів (kube-apiserver, controller-manager тощо) та файли конфігурації в /etc/kubernetes.
```
sudo kubeadm reset -f
```
- Очищення IPVS/Iptables:
```
sudo iptables -F && sudo iptables -t nat -F && sudo iptables -t mangle -F && sudo iptables -X

# Якщо використовували IPVS:
sudo ipvsadm --clear
```
- Видалення залишкових файлів: Бажано видалити теку з сертифікатами, щоб при повторному приєднанні не виникло конфліктів.
```
sudo rm -rf /etc/kubernetes/pki
```
Очищення Etcd

Ось тут з’являється головна відмінність між архітектурами.

Для External Etcd:

Оскільки etcd працює окремо, нічого робити не потрібно. Зовнішній кластер etcd навіть не знає, що API-сервер на cp-2 перестав працювати. Ви просто видалили одного з клієнтів бази даних.

Для Stacked Etcd:

Це найважливіший крок. Оскільки etcd працював локально на cp-2, він був частиною кворуму. Якщо ви просто вимкнете вузол, etcd-кластер вважатиме його “впавшим” і чекатиме на повернення, що може негативно вплинути на кворум.
1. Потрібно зайти на інший майстер-вузол.
2. Знайти ID члена etcd для cp-2:
```
kubectl exec -n kube-system etcd-cp-1 -- etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member list
```
3. Видалити цей ID:
```
kubectl exec -n kube-system etcd-cp-1 -- etcdctl \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  member remove <MEMBER_ID>
```
Оновлення Load Balancer

Якщо у вас перед панеллю управління стоїть зовнішній балансувальник (наприклад, HAProxy або хмарний LB), обовʼязково видаліть IP-адресу cp-2 з конфігурації backend.

Якщо ви використовуєте локальний HAProxy на кожному вузлі (як ми налаштовували раніше), то інші вузли просто перестануть звертатися до cp-2, але конфігурацію на робочих вузлах (workers) варто оновити, щоб вони не витрачали час на спроби зʼєднатися з відсутнім вузлом панелі управління.
Заміна вузла (якщо потрібно)

Якщо ви хочете замінити cp-2 новим вузлом з такою ж назвою:
- Підготуйте нову ОС.
- Виконайте кроки з попередньої інструкції (копіювання 9 файлів сертифікатів + маніфест проксі).
- Запустіть kubeadm join.

Розгортання Worker Nodes

Для розгортання робочих вузлів будемо використовувати налаштування з snipets/cloud-init-config.yaml, snipets/cloud-init-user.yaml та snipets/cloud-init-base.yaml. Під час процесу обʼєднання файлів приберемо kubectl з переліку пакунків для встановлення. Для робочих вузлів використовуватимемо IP адреси з діапазону 10.10.0.30 — 10.10.0.99.

export VM_IP="10.10.0.31/24"

multipass launch --name wn-1 \
  --cpus 2 --memory 2G --disk 10G \
  --network name=en0,mode=manual \
  --cloud-init <( yq eval-all '
      # Злиття всіх файлів в один обʼєкт
      . as $item ireduce ({}; . *+ $item) |

      # Вилучення kubectl зі списку пакунків
      del(.packages[] | select(. == "kubectl")) |

      # Оновлення конфігурації мережі
      with(.write_files[] | select(.path == "/etc/netplan/60-static-ip.yaml");
        .content |= (
          from_yaml |
          .network.ethernets.enp0s2.addresses += [strenv(VM_IP)] |
          to_yaml
        )
      ) ' \
      snipets/cloud-init-config.yaml \
      snipets/cloud-init-user.yaml \
      snipets/cloud-init-base.yaml )

По завершенні створення віртуальної машини увійдемо до неї через ssh

ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.31

Та виконаємо її приєднання до кластера командою, яку ми отримали під час ініціалізації панелі управління:

sudo kubeadm join 10.10.0.100:6443 --token jfugsz.51c9pp44fwifcu94 \
  --discovery-token-ca-cert-hash sha256:736ca5cf47fca3f4c1fd9c414f6ba70e4fefdb2f52deec5e2526f5ebccf838d6

Оператор Calico (tigera-operator) виконає реєстрацію вузла в мережі подів і через хвилину-дві статус робочого вузла зміниться на READY. Вузол готовий для отримання робочого навантаження.

Встановлення MetalLB

Щодо встановлення MetalLB для балансування доступу до робочих вузлів скористайтесь інструкцією зі статті «Розгортання Kubernetes-кластера на локальному компʼютері: Повне покрокове керівництво».

Тепер ваш кластер готовий прийняти робоче навантаження.

Тестування кластера

multipass exec cp1 -- kubectl get nodes
multipass exec cp1 -- kubectl get pods -A

Підсумки

Цей посібник демонструє повне розгортання HA Kubernetes кластера з топологією external etcd. Кластер готовий до використання та може бути легко масштабований. Всі кроки дотримуються принципу DRY та можуть бути адаптовані для різних середовищ.

Додатки

Мережева архітектура для HA Kubernetes з external etcd

Подивитись…

Рекомендована топологія мережі — Підмережа: 10.10.0.0/22 (1024 адреси)

Ця підмережа достатньо велика для розширення та логічно поділена на блоки:

┌─────────────────────────────────────────────────────────┐
│ 10.10.0.0/22      - Головна підмережа Kubernetes        │
├─────────────────────────────────────────────────────────┤
│ 10.10.0.0/26      - Інфраструктура (64 адреси)          │
│   10.10.0.1       - Gateway (macOS host)                │
│   10.10.0.2       - DNS (опціонально)                   │
│   10.10.0.10      - HAProxy/Load Balancer               │
│   10.10.0.11-20   - Резерв для інфраструктури           │
├─────────────────────────────────────────────────────────┤
│ 10.10.0.64/26     - etcd кластер (64 адреси)            │
│   10.10.0.65      - etcd-1                              │
│   10.10.0.66      - etcd-2                              │
│   10.10.0.67      - etcd-3                              │
│   10.10.0.68-70   - Резерв для додаткових etcd          │
├─────────────────────────────────────────────────────────┤
│ 10.10.0.128/25    - Control Plane (128 адрес)           │
│   10.10.0.129     - k8s-master-1                        │
│   10.10.0.130     - k8s-master-2                        │
│   10.10.0.131     - k8s-master-3                        │
│   10.10.0.132-140 - Резерв для додаткових masters       │
├─────────────────────────────────────────────────────────┤
│ 10.10.1.0/24      - Worker Nodes (256 адрес)            │
│   10.10.1.10      - k8s-worker-1                        │
│   10.10.1.11      - k8s-worker-2                        │
│   10.10.1.12      - k8s-worker-3                        │
│   10.10.1.13      - k8s-worker-4                        │
│   10.10.1.14      - k8s-worker-5                        │
│   10.10.1.15-100  - Резерв для додаткових workers       │
├─────────────────────────────────────────────────────────┤
│ 10.10.2.0/24   - Pod Network (256 адрес) - опціонально  │
│   Використовується для тестування                       │
├─────────────────────────────────────────────────────────┤
│ 10.10.3.0/24   - Service Network - опціонально          │
│   Використовується для тестування                       │
└─────────────────────────────────────────────────────────┘

Детальний план IP адрес

1. Інфраструктура (10.10.0.0/26)

IP адреса	Hostname	Роль
10.10.0.1	macOS-host	Gateway/Bridge
10.10.0.10	haproxy-lb	Load Balancer (опціонально)

2. etcd Кластер (10.10.0.64/26)

IP адреса	Hostname	Роль	vCPU	RAM	Disk
10.10.0.65	etcd-1	etcd member	2	2GB	20GB
10.10.0.66	etcd-2	etcd member	2	2GB	20GB
10.10.0.67	etcd-3	etcd member	2	2GB	20GB

Мінімальна конфігурація etcd: 3 вузли для кворуму

3. Control Plane (10.10.0.128/25)

IP адреса	Hostname	Роль	vCPU	RAM	Disk
10.10.0.129	k8s-master-1	Control Plane (Primary)	2	4GB	40GB
10.10.0.130	k8s-master-2	Control Plane	2	4GB	40GB
10.10.0.131	k8s-master-3	Control Plane	2	4GB	40GB

Мінімальна конфігурація HA: 3 master вузли

4. Worker Nodes (10.10.1.0/24)

IP адреса	Hostname	Роль	vCPU	RAM	Disk
10.10.1.10	k8s-worker-1	Worker Node	2	4GB	50GB
10.10.1.11	k8s-worker-2	Worker Node	2	4GB	50GB
10.10.1.12	k8s-worker-3	Worker Node	2	4GB	50GB

Рекомендація: Мінімум 2-3 workers для тестування, можна масштабувати до 100+

Внутрішні мережі Kubernetes (не конфліктують з VM)

# Pod Network (CNI - Calico/Flannel/Weave)
--pod-network-cidr=192.168.0.0/16

# Service Network
--service-cidr=172.16.0.0/16

# Cluster DNS
--cluster-dns=172.16.0.10

Ці мережі віртуальні і не конфліктують з VM адресами 10.10.x.x

Альтернативні варіанти підмереж

Варіант 1: Компактна топологія (10.10.10.0/24)

Для невеликого кластеру (до 10 вузлів):

10.10.10.0/24 - Головна підмережа (256 адрес)
├─ 10.10.10.1      - Gateway
├─ 10.10.10.10-12  - etcd (3 вузли)
├─ 10.10.10.20-22  - Control Plane (3 masters)
└─ 10.10.10.30-50  - Workers (до 20 workers)

Варіант 2: Розширена топологія (10.10.0.0/16)

Для великого production кластеру:

10.10.0.0/16 - Вся мережа (65536 адрес)
├─ 10.10.1.0/24   - Інфраструктура
├─ 10.10.10.0/24  - etcd кластер
├─ 10.10.20.0/24  - Control Plane
├─ 10.10.30.0/22  - Workers (1024 адреси)
└─ 10.10.40.0/22  - Резерв для розширення

Варіант 3: Класична приватна мережа (172.16.0.0/16)

Альтернатива якщо 10.10.x.x зайнято:

172.16.0.0/16
├─ 172.16.1.0/24   - Інфраструктура + etcd
├─ 172.16.2.0/24   - Control Plane
└─ 172.16.10.0/23  - Workers (512 адрес)

DNS записи (рекомендовано)

Додайте в /etc/hosts на macOS:

# Kubernetes HA Cluster
10.0.1       gateway.k8s.local
10.0.10      lb.k8s.local haproxy.k8s.local

# etcd cluster
10.0.65      etcd-1.k8s.local
10.0.66      etcd-2.k8s.local
10.0.67      etcd-3.k8s.local

# Control Plane
10.0.129     master-1.k8s.local k8s-master-1
10.0.130     master-2.k8s.local k8s-master-2
10.0.131     master-3.k8s.local k8s-master-3

# Workers
10.1.10      worker-1.k8s.local k8s-worker-1
10.1.11      worker-2.k8s.local k8s-worker-2
10.1.12      worker-3.k8s.local k8s-worker-3

# API endpoint (вказує на LB або будь-який master)
10.0.10      api.k8s.local kubernetes.k8s.local

Виправлення проблем

Переглянути

Виправлення `--pod-network-cidr`

Q: після встановлення CNI-втулка (Flannel) я помітив що забув використати --pod-network-cidr=10.244.0.0/16 під час ініціалізації HA кластера з трьома control planes. Як це виправити без видалення кластера?

Відповідь

Щоб виправити CIDR мережі Pod-ів у діючому HA-кластері (3 control planes) без його повного перевстановлення, вам потрібно оновити конфігурацію kube-apiserver, налаштування kubeadm в ClusterConfiguration, параметри kube-proxy та конфігурацію самого Flannel.

1. Оновлення конфігурації ClusterConfiguration

Kubernetes зберігає налаштування ініціалізації у ConfigMap. Їх потрібно змінити, щоб майбутні операції (наприклад, приєднання нових вузлів) використовували правильний CIDR.

Відредагуйте ConfigMap:

kubectl edit configmap kubeadm-config -n kube-system

Знайдіть розділ networking і змініть або додайте параметр podSubnet:
```
networking:
  podSubnet: 10.244.0.0/16
```

2. Оновлення маніфестів Control Plane (на всіх 3-х вузлах)

На кожному з трьох control plane вузлів потрібно оновити статичний маніфест kube-controller-manager, щоб він правильно розподіляв IP-адреси для вузлів.

Відкрийте файл: sudo vim /etc/kubernetes/manifests/kube-controller-manager.yaml
Знайдіть прапорець --cluster-cidr і встановіть його:
```
 - --cluster-cidr=10.244.0.0/16
 - --allocate-node-cidrs=true
```
Після збереження файлу Kubelet автоматично перезапустить компонент. Повторіть це на всіх трьох master-вузлах.

3. Оновлення налаштувань kube-proxy

kube-proxy використовує CIDR для налаштування правил IPTables/IPVS.

Відредагуйте ConfigMap для kube-proxy:
```
kubectl edit configmap kube-proxy -n kube-system
```
Знайдіть параметр clusterCIDR і змініть його:
```
clusterCIDR: "10.244.0.0/16"
```
Перезапустіть всі Pod-и kube-proxy для застосування змін:
```
kubectl rollout restart daemonset kube-proxy -n kube-system
```
Далі має все запрацювати. Якщо цього не сталося, перейдіть до наступних кроків.

4. Перевстановлення Flannel з правильним CIDR

Оскільки Flannel вже встановлено з неправильними параметрами (або без них), його потрібно переналаштувати.

Завантажте актуальний маніфест Flannel з офіційного репозиторію:
```
 curl -sLO https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
```
Перевірте у завантаженому файлі секцію net-conf.json. Вона повинна містити:
```
"Network": "10.244.0.0/16"
```

Видаліть старий Flannel та встановіть оновлений:

kubectl delete -f kube-flannel.yml # якщо у вас є старий файл
kubectl apply -f kube-flannel.yml

5. Оновлення Spec вузлів (PodCIDR)

Це найкритичніший крок. Кожен вузол у кластері вже має призначений старий (або порожній) podCIDR у своїх властивостях. Їх потрібно оновити вручну.

Для кожного вузла (master та worker) виконайте:

kubectl patch node <node-name> -p '{"spec":{"podCIDR":"10.244.X.0/24", "podCIDRs":["10.244.X.0/24"]}}'

Де X — унікальне число для кожного вузла (наприклад, 0, 1, 2).

6. Фінальне перезавантаження

Щоб зміни вступили в силу і Pod-и отримали адреси з нового діапазону:

Перезавантажте вузли по черзі або видаліть всі існуючі Pod-и в усіх namespace, щоб вони перестворилися з новими IP.

Перевірте статус мережі:

kubectl get nodes -o jsonpath='{.items[*].spec.podCIDR}'

Важливо: Якщо у вас вже були запущені робочі навантаження (workloads), їхні IP-адреси не зміняться автоматично до моменту перестворення Pod-ів. На HA-кластері цей процес можна робити по черзі для кожного вузла (cordon -> drain -> reboot -> uncordon), щоб уникнути простою.

Скидання etcd до первісного стану

Q: Як очистити дані в кластері? Скинути його в первісний стан?

Відповідь

Щоб скинути etcd до «первісного» (порожнього) стану, необхідно повністю видалити його дані на кожному вузлі. Оскільки etcd є критичним компонентом Kubernetes, цей процес фактично знищить усю конфігурацію вашого кластера (Deployment, Services, Secrets тощо).

Покрокова інструкція для кластера, розгорнутого через kubeadm:

1. Зупиніть сервіси, що залежать від etcd

На кожній майстер-ноді (control-plane) необхідно тимчасово прибрати маніфести статичних подів, щоб Kubernetes припинив спроби перезапустити etcd та API-сервер:

sudo mv /etc/kubernetes/manifests/*.yaml /tmp/

Зачекайте кілька секунд, поки контейнери зупиняться. Перевірити можна через crictl ps або docker ps.

2. Очистіть дані на всіх вузлах

Видаліть вміст теки даних etcd (зазвичай це /var/lib/etcd). Це потрібно зробити на всіх вузлах, де працював etcd:

sudo rm -rf /var/lib/etcd/*

3. Ініціалізація нового “порожнього” кластера

Тепер вам потрібно змусити etcd запуститися як новий кластер.

Варіант А (Повне скидання кластера через kubeadm):

Якщо ви хочете почати все з нуля (включаючи сертифікати та конфігурацію K8s), виконайте на кожному вузлі:
```
sudo kubeadm reset -f
sudo rm -rf /etc/cni/net.d
# Після цього знову запустіть 'kubeadm init' на першій ноді
```
Варіант Б (Тільки очищення даних etcd без перевстановлення K8s):

Якщо сертифікати в /etc/kubernetes/pki/etcd/ ще валідні, ви можете спробувати перестворити лише базу. Поверніть маніфести назад:
```
sudo mv /tmp/etcd.yaml /etc/kubernetes/manifests/
```
Важливо: Якщо в etcd.yaml вказані параметри --initial-cluster-state=existing, вам може знадобитися вручну змінити їх на new або скористатися командою kubeadm init phase etcd local, щоб згенерувати коректний маніфест для нової ініціалізації.

4. Очищення через etcdctl (якщо кластер працює)

Якщо кластер «живий», але ви просто хочете видалити всі дані (ключі), не зупиняючи сервіси:

etcdctl \
  --endpoints https://127.0.0.1:2379 \
  --cacert /etc/kubernetes/pki/etcd/ca.crt \
  --cert /etc/kubernetes/pki/etcd/peer.crt \
  --key /etc/kubernetes/pki/etcd/peer.key \
  del "" --prefix

Це видалить усі обʼєкти Kubernetes, але збереже саму структуру кластера etcd.

Попередження: Після повного очищення даних /var/lib/etcd API-сервер не зможе запуститися, поки ви не виконаєте повторну ініціалізацію через kubeadm init.

Kubeconfig

Q: Як правильно перенести kubeconfig на локальний хост та додати кластер до переліку інших кластерів?

Відповідь

Щоб правильно перенести kubeconfig та об’єднати його з вашими існуючими кластерами, найкраще уникати ручного редагування основного файлу конфігурації, оскільки це часто призводить до помилок у відступах YAML.

1. Завантаження файлу на локальний хост

Використовуйте ssh для читання файлу безпосередньо в новий локальний файл. Замініть 10.10.0.21 на IP вашого cp-1.

# На вашій локальній машині
ssh -i ~/.ssh/k8s_cluster_key k8sadmin@10.10.0.21 "sudo cat /etc/kubernetes/admin.conf" > kubeconfig-new.yaml

2. Очищення конфігурації (Важливо)

Файл admin.conf, згенерований kubeadm, зазвичай має стандартні назви (kubernetes-admin, kubernetes). Якщо у вас кілька кластерів, ці назви будуть конфліктувати.

Відкрийте kubeconfig-new.yaml у редакторі та перейменуйте ключові поля. Наприклад, якщо ваш кластер називається prod-cluster:

clusters.name: kubernetes ➡️ prod-cluster
contexts.name: kubernetes-admin@kubernetes ➡️ admin@prod-cluster
contexts.context.cluster: kubernetes ➡️ prod-cluster
contexts.context.user: kubernetes-admin ➡️ admin-prod
users.name: kubernetes-admin ➡️ admin-prod

Порада: Якщо ви використовуєте Load Balancer (10.10.0.100), переконайтеся, що в полі server вказана саме ця IP-адреса, а не внутрішній IP cp-1.

3. Обʼєднання з основним kubeconfig

Замість того, щоб копіювати текст, скористайтеся можливістю kubectl обʼєднувати декілька файлів через змінну оточення.

Тимчасово об’єднайте файли в пам’яті:
```
export KUBECONFIG=~/.kube/config:./kubeconfig-new.yaml
```
Запишіть результат у новий файл (змерджений):
```
kubectl config view --flatten > ~/.kube/config_new
```

Замініть старий конфіг новим:

mv ~/.kube/config_new ~/.kube/config
chmod 600 ~/.kube/config

4. Перевірка та перемикання

Тепер ви можете побачити всі свої кластери:

# Список контекстів
kubectl config get-contexts

# Перемикання на новий кластер
kubectl config use-context admin@prod-cluster

# Перевірка зв'язку
kubectl get nodes

Альтернатива (якщо ви використовуєте кілька файлів)

Якщо ви не хочете змішувати все в один файл ~/.kube/config, ви можете просто тримати їх окремо в папці ~/.kube/configs/ і додавати шлях до них у ваш .bashrc або .zshrc:

export KUBECONFIG=$HOME/.kube/config:$HOME/.kube/configs/prod-cluster.yaml

Або інший варіант.

Набір команд kubectl config дозволяє маніпулювати конфігурацією набагато чистіше. Оскільки kubeadm завжди створює стандартні імена (kubernetes, kubernetes-admin), найкраща стратегія — це iмпортувати файл з новою назвою context, а kubectl автоматично підтягне повʼязані з ним кластер та користувача.

Скрипт для імпорту та перейменування

Цей підхід не редагує temp-k8s.yaml, а відразу вливає його в основний конфіг з новими іменами.

# 1. Завантажуємо файл
ssh k8sadmin@10.10.0.21 "sudo cat /etc/kubernetes/admin.conf" > temp-k8s.yaml

# 2. Визначаємо назву нового кластера
NEW_NAME="k8s-cluster-prod"

# 3. Додаємо кластер, користувача та контекст у ваш основний ~/.kube/config
# Ми витягуємо дані з тимчасового файлу за допомогою 'view'

# Додаємо кластер
kubectl config set-cluster "$NEW_NAME" \
  --server=$(kubectl config view --kubeconfig=temp-k8s.yaml -o jsonpath='{.clusters[0].cluster.server}') \
  --certificate-authority-data=$(kubectl config view --kubeconfig=temp-k8s.yaml --raw -o jsonpath='{.clusters[0].cluster.certificate-authority-data}')

# Додаємо користувача
kubectl config set-credentials "admin-$NEW_NAME" \
  --client-certificate-data=$(kubectl config view --kubeconfig=temp-k8s.yaml --raw -o jsonpath='{.users[0].user.client-certificate-data}') \
  --client-key-data=$(kubectl config view --kubeconfig=temp-k8s.yaml --raw -o jsonpath='{.users[0].user.client-key-data}')

# Створюємо контекст
kubectl config set-context "$NEW_NAME" \
  --cluster="$NEW_NAME" \
  --user="admin-$NEW_NAME"

# 4. Видаляємо тимчасовий файл
rm temp-k8s.yaml

Додавання статичної IP адреси віртуальним машинам Multipass на macOS

2025-12-26T06:30:00+00:00

Цей посібник містить докладний опис того як додати статичну IP адресу до віртуальної машини Multipass на macOS. Загальний опис того як це зробити ви можете знайти в офіційній документації в розділі Configure static IPs, однак на macOS без певних модифікацій повторити ці рекомендації не виходить.

Додавання IP адреси до першого мережевого інтерфейсу віртуальної машини

Пошук Multipass bridge

Для доступу до віртуальних машин Multipass (на macOS) створює міст з назвою bridge100. Цей міст використовується для доступу віртуальних машин до мережі хоста. IP адреси призначаються через DHCP і при (пере)створенні віртуальної машини їй надається наступна IP адреса з мережі моста.

Виконання команди multipass networks має показати вам перелік доступних мережевих інтерфейсів.

Як ви можете бачити в цьому переліку нашого моста немає. Результат multipass networks підтверджує головне обмеження Multipass на macOS: він “бачить” лише фізичні мережеві адаптери (Wi-Fi, Ethernet, USB). Створені віртуальні мости (bridge100) він ігнорує, оскільки вони не мають апаратного профілю, який очікує драйвер віртуалізації Apple.

Спробуємо знайти міст іншим шляхом.

# Знайдіть bridge (зазвичай bridge100)
ifconfig | grep -A 2 "^bridge"

Відподіь має бути схожа на наступне:

Запамʼятайте назву bridge (наприклад, bridge100). Ми будема далі її використовувати.

В моєму випадку міст доступний за адресою 192.168.2.1/24 і DHCP сервер виділяє адреси віртуальним машинам з діапазону 192.168.2.X.

ifconfig -v bridge100

Налаштування bridge на хості

Припустимо, що нам потрібно надавати віртуальним машинам статичні IP адреси для мережі 10.10.0.0/24. Для цього ми будемо створювати аліас до наявного у нас мосту.

# Додайте IP адресу до bridge
sudo ifconfig bridge100 10.10.0.1/24 alias

# Перевірте що додалось
ifconfig bridge100 | grep "inet "

Очікуваний результат:

inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255
inet 10.10.0.1 netmask 0xffffff00 broadcast 10.10.0.255

або за допомогою скрипта

TARGET_BRIDGE=$(ifconfig -v | grep -B 20 "member: vmenet" | grep "bridge" | awk -F: '{print $1}' | head -n 1)

if [ -z "$TARGET_BRIDGE" ]; then
    echo "Помилка: міст не знайдено. Перевірте, чи запущена ВМ."
else
    echo "ВМ знайдена на $TARGET_BRIDGE. Призначаємо 10.10.0.1..."
    sudo ifconfig $TARGET_BRIDGE 10.10.0.1/24 alias
fi

Створення cloud-init конфігурації для VM

Створимо наступний конфігураційний файл cloud-init, що містить налаштування для мережі 10.10.0.0/24

cat > multipass-static-ip.yaml << 'EOF'
#cloud-config

write_files:
  - path: /etc/netplan/60-static-ip.yaml
    permissions: '0600'
    content: |
      network:
        version: 2
        ethernets:
          default:
            dhcp4: true
            addresses:
              - 10.10.0.10/24
            routes:
              - to: default
                via: 10.10.0.1
                metric: 200

runcmd:
  - netplan apply

hostname: test-vm
EOF

Для налаштування роботи мережі в Ubuntu використовується Netplan, ми додаємо настройки для нього у файл /etc/netplan/60-static-ip.yaml. Вміст файлу знаходиться у полі content: Зверніть увагу на рядок permissions: '0600', ним ми встановлюємо права достпу на читання-запис тільки для користувача root. За наявності занадто дозвільних прав Netplan сповістить про це і не застосує налаштування. Команда netplan apply застосовує налаштування з теки /etc/netplan/. Поле hostname містить назву для нашої віртуальної машини, яка буде додано у файл /etc/hostname.

Запуск VM та перевірка роботи

Створимо нашу віртуальну машину

# Створіть VM з cloud-init конфігурацією
multipass launch --name test-vm --cloud-init multipass-static-ip.yaml

Multipass створить віртуальну машину з назвою вказаною в параметрі --name/-n та використає налаштування cloud-init з файла, вказаного в --cloud-init.

Перевіримо мережеві налаштування нашої віртуальної машини

# Перевірте IP адреси на VM
multipass exec -n test-vm -- ip addr show enp0s1

# або скористайтесь netplan
multipass exec -n test-vm -- netplan status

# Має показати два IP:
# - 192.168.2.x (DHCP)
# - 10.10.0.10 (static)

Тепер настав час переврити звʼязок

# З хоста до VM
ping -c 4 10.10.0.10

# З VM до хоста
multipass exec -n test-vm -- ping -c 4 10.10.0.1

# Перевірте доступ в інтернет з VM
multipass exec -n test-vm -- ping -c 4 8.8.8.8

✅ Статична IP адреса працює!

Технічні деталі

# Вивід переліку файлів конфігурації
multipass exec -n test-vm -- sudo ls -la /etc/netplan

# Отримання обʼєднаної конфігурації мережі
multipass exec -n test-vm -- sudo netplan get

Ми бачимо що у теці /etc/netplan знаходяться файли 50-cloud-init.yaml, який створюється cloud-init під час ініціалізації віртуальної машини, та файл 60-static-ip.yaml, який ми передали в налаштуваннях

Виконання команди sudo netplan get надасть нам обʼєднану конфігурацію мережі. Порівняйте її з вмістом файлу 50-cloud-init.yaml

# Отримайте вміст 50-cloud-init.yaml
multipass exec -n test-vm -- sudo cat /etc/netplan/50-cloud-init.yaml

Зверніть увагу на назву мережевого інтерйфесу що його використовує cloud-init. Саме його ми використовували в наших налаштуваннях (не enp0s1).

network:
  version: 2
  ethernets:
    default: # назва мережевого інтерфейсу
      match:
        macaddress: "52:54:00:ae:24:22"
      dhcp-identifier: "mac"
      dhcp4: true

Додавання статичної IP адреси до другого мережевого інтерфейсу віртуальної машини

Окрім додавання статчної IP адреси до першого мережевого інтерфейсу ми можемо робити це й для інших мережевих інтерфейсів вірутальної машини. Для цього на хості потрібно додати/створити відповідний мережевий міст.

Multipass bridge для другого мережевого інтерфейсу

Запустимо тимчасову ВМ для створення нового моста (bridge101)

multipass launch --name sandbox-vm --network name=en0,mode=manual

Параметр --network name=en0,mode=manual створить новий мережевий інтерфейс enp0s2 у віртуальній машині, який буде привʼзаний до нового bridge. Однак, після створення цей інтерфейс буде неактивним, оскільки йому не було призначено IP-адресу.

Недоліком чи перевагою такого підходу є те, що після видалення всіх віртуальних машин, привʼязаних до цього bridge його буде видалено з системи автоматично. Він існує допоки є віртуальні машини привʼязані до нього.

Ця команда дозволяє дізнатись назву цього bridge:

ifconfig -v | grep -B 20 "member: vmenet" | grep "bridge" | awk -F: '{print $1}' | tail -n 1

Скоріш за все назва буде bridge101.

Додамо аліас до мосту

# Додайте IP адресу до bridge
sudo ifconfig bridge101 10.10.1.1/24 alias

# Перевірте що додалось
ifconfig bridge101 | grep "inet "

Очікуваний результат:

inet 10.10.1.1 netmask 0xffffff00 broadcast 10.10.1.255

або

TARGET_BRIDGE=$(ifconfig -v | grep -B 20 "member: vmenet" | grep "bridge" | awk -F: '{print $1}' | tail -n 1)

if [ -z "$TARGET_BRIDGE" ]; then
    echo "Помилка: міст не знайдено. Перевірте, чи запущена ВМ."
else
    echo "ВМ знайдена на $TARGET_BRIDGE. Призначаємо 10.10.1.1..."
    sudo ifconfig $TARGET_BRIDGE 10.10.1.1/24 alias
fi

Створення cloud-init конфігурації для другого мережевого інтерфейсу VM

Так само, як і в першому випадку створимо конфігурацію cloud-init для налаштування мережевого інтерфейсу віртуальної машини.

cat > multipass-static-ip1.yaml << 'EOF'
#cloud-config

write_files:
  - path: /etc/netplan/60-custom-network.yaml
    permissions: '0600'
    content: |
      network:
        version: 2
        ethernets:
          enp0s2:
            addresses:
              - 10.10.1.20/24
            # МИ ВИДАЛЯЄМО "via: 10.10.0.1" (default gateway)
            # Замість цього просто дозволяємо прямий доступ до мережі 10.10.1.0/24
            routes:
              - to: 10.10.1.0/24
                scope: link
runcmd:
  - netplan apply
EOF

Запуск та перевірка роботи віртуальної машини

Запустимо віртуальну машину з назвою test-vm1.

# Створіть VM з cloud-init конфігурацією
multipass launch --name test-vm1 --network name=en0,mode=manual --cloud-init multipass-static-ip1.yaml

Дочекаємось завершення процесу створення та запуску VM. Після цього ми можемо видалити нашу тимчасову віртуальну машину, яку ми використовували для того, щоб система створила новий мережевий міст.

multipass delete sandbox-vm --purge

Створення віртуальної машини test-vm1 відбувається так само як і test-vm з тією відмінністю, що вона матиме два мережевих інтерфеси.

Тепер перевіримо налаштування мережевих інтерфейсів віртуальної машини

# Перевірте IP адреси на VM
multipass exec -n test-vm1 -- ip addr show

# або скористайтесь netplan
multipass exec -n test-vm1 -- netplan status

Ви маєте побачити два IP:

192.168.2.x (DHCP) на enp0s1
10.10.1.20 (static) на enp0s2

Перевіримо роботу звʼязку

# З хоста до VM1
ping -c 4 10.10.1.20

# З VM1 до хоста
multipass exec -n test-vm1 -- ping -c 4 10.10.1.1

# Трафік між VM та VM1
multipass exec -n test-vm1 -- ping -c 4 10.10.0.10
multipass exec -n test-vm -- ping -c 4 10.10.1.20

# Перевірте доступ в інтернет з VM1
multipass exec -n test-vm1 -- ping -c 4 8.8.8.8

✅ Статична IP адреса на другому мережевому інтерфейсі працює!

Очищення

Видаліть віртуальні машини командою multipass delete <name-vm> --purge або всі разом — multipass delete --all --purge.

Після видалення всіх віртуальних машин, які були привʼязані до мосту bridge101 його буде вилучено автоматично.

Рузультатом виконання ifconfig -v bridge101 буде

ifconfig: interface bridge101 does not exist

Для видалення аліасу з bridge100 виконайте sudo ifconfig bridge100 -alias 10.10.0.1, також можна очистити кеш sudo arp -d -a.

Підсумки

За допомогою цих настанов ви маєте можливість додавати статичні адреси віртуальним машинам Multipass. Це може бути корисно у випадках коли вам потрібно використовувати пул заздалегідь виділених адрес.

⚠️ Це керівництво було створено та протестовано для роботи на macOS. Робота з іншими операційними системами може мати відмінності, залежно від функцій та підходів, які ви будете використовувати.

Розгортання Kubernetes-кластера на локальному компʼютері: Повне покрокове керівництво

2025-12-12T06:30:00+00:00

💡 Такої детальної покрокової інструкції немає в офіційній документації Kubernetes! Те, що ви знайдете там, — це окремі рекомендації. Тут же все зібране в одному місці, щоб ви могли швидко та легко створити свій перший кластер.

Що ми будемо робити?

Ми створимо повноцінний Kubernetes-кластер на вашому локальному компʼютері. За наявності у вас окремого обладнання (компʼютерів), можна адаптувати це керівництво для фізичних машин. Для цього ми використаємо:

Multipass — інструмент для створення віртуальних машин Ubuntu
kubeadm — основний інструмент для ініціалізації кластера
Flannel — CNI-втулок для створення мережі між Pod’ами
MetalLB — балансувальник навантаження для нашого кластера

Наш кластер складатиметься з трьох вузлів:

1 вузла панелі управління (control plane)
2 робочих worker-вузлів

Передумови

Перед початком встановіть Multipass:

brew install multipass

Крок 1: Створення віртуальних машин

Визначаємо список вузлів

Створимо масив з іменами трьох віртуальних машин. Це як простий список — просто записуємо, які машини нам потрібні.

NODES=(k8s-control k8s-worker-1 k8s-worker-2)

Створюємо ВМ

Тепер за допомогою multipass створимо три віртуальні машини з Ubuntu на борту.

for NODE in "${NODES[@]}"; do
  multipass launch --name $NODE --cpus 2 --memory 4G --disk 20G
done

За допомогою циклу for NODE in "${NODES[@]}" проходимо по кожному імені в масиві; multipass launch --name $NODE створює віртуальну машину з відповідним імʼям та наступними параметрами:

--cpus 2 — виділяємо 2 процесорних ядра (мінімум для K8s)
--memory 4G — виділяємо 4 ГБ оперативної памʼяті
--disk 20G — виділяємо 20 ГБ дискового простору

Multipass автоматично завантажить Ubuntu. Це займе кілька хвилин ☕.

Крок 2: Підготовка всіх вузлів

Коли наші віртуальні машини створені, тепер почнемо налаштування. Ці кроки потрібно виконати на всіх трьох машинах.

2.1. Оновлення системи

echo "=== [1/7] Оновлення системи на всіх вузлах ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- bash -c "
    sudo apt-get update &&
    sudo apt-get upgrade -y
  "
done

multipass exec $NODE — виконує команду на віртуальній машині
sudo apt-get update — оновлює список доступних пакетів (як каталог програм)
sudo apt-get upgrade -y — встановлює всі оновлення, -y означає “так, згоден” у відповідях на всі питання

Перед початком роботи важливо мати актуальну систему з останніми виправленнями безпеки та оновленнями пакетів.

Після виконання цієї команди всі пакети в системі будуть оновлені до останніх версій.

2.2. Вимкнення firewall

echo "=== [2/7] Вимкнення firewall на всіх вузлах ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- sudo ufw disable
done

UFW — це вбудований брандмауер Ubuntu. Для навчального кластера ми вимикаємо брандмауер, щоб уникнути проблем з мережевим звʼязком між вузлами.

⚠️ У промисловій експлуатації потрібно правильно налаштувати firewall та відкрити відповідні порти!

2.3. Завантаження модулів ядра

echo "=== [3/7] Налаштування kernel-модулів ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- bash -c "
    echo -e 'overlay\nbr_netfilter' | sudo tee /etc/modules-load.d/k8s.conf
    sudo modprobe overlay
    sudo modprobe br_netfilter
  "
done

Для своєї роботи Kubernetes потребує щоб були увімкнені ці два модулі ядра Linux:

overlay — для файлової системи контейнерів (для роботи з шарами образів контейнерів)
br_netfilter — для мережевого звʼязку між контейнерами

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

2.4. Налаштування мережевих параметрів

echo "=== [4/7] Налаштування мережевих параметрів ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- bash -c "
    cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
    sudo sysctl --system
  "
done

Тут ми налаштовуємо параметри мережі на рівні ядра операційної системи:

bridge-nf-call-iptables — дозволяє iptables обробляти трафік, що проходить через мережеві мости (для IPv4 та IPv6)
ip_forward — дозволяє маршрутизацію пакетів між мережевими інтерфейсами (як поштове відділення, що пересилає листи)

Команда sysctl –system застосовує ці параметри негайно.

Це критично важливо для роботи мережі Kubernetes!

2.5. Встановлення containerd

echo "=== [5/7] Встановлення containerd ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- sudo apt-get install -y containerd
done

Containerd — це рушій для запуску та виконання контейнерів, тобто програма, яка фактично запускає та керує контейнерами. Це як двигун для автомобіля — без нього нічого не поїде. Kubernetes підтримує різні рушії, containerd — найпопулярніший та є рекомендованим варіантом.

2.6. Налаштування containerd

echo "=== [6/7] Налаштування containerd і CRI ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- bash -c "
    sudo mkdir -p /etc/containerd
    containerd config default | sudo tee /etc/containerd/config.toml

    # Оновлюємо sandbox image
    sudo sed -i 's/registry.k8s.io\\/pause:3.8/registry.k8s.io\\/pause:3.10.1/' /etc/containerd/config.toml

    # Увімкнення режиму cgroup через systemd
    sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml

    # Додаємо конфіг для crictl
    sudo tee /etc/crictl.yaml <<EOF
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false
EOF

    sudo systemctl restart containerd
    sudo systemctl enable containerd
  "
done

Що відбувається:

Генеруємо стандартний конфігураційний файл за допомогою containerd config default та записуємо його в /etc/containerd/config.toml
Kubernetes використовує спеціальний (інфраструктурний) “pause” контейнер для кожного Podʼа. Оновимо його до версії 3.10.1 (остання на момент написання)
Вмикаємо управління cgroups через systemd. Cgroups — це механізм обмеження ресурсів (CPU, памʼять) для контейнерів. Systemd — стандартний спосіб керування цим в Ubuntu
Налаштовуємо crictl (інструмент для відладки контейнерів). Ми вказуємо йому, як підключатися до containerd
Перезапускаємо containerd з новими налаштуваннями та додаємо його в автозапуск

2.7. Встановлення Kubernetes компонентів

echo "=== [7/7] Встановлення Kubernetes компонентів ==="
for NODE in "${NODES[@]}"; do
  multipass exec $NODE -- bash -c "
    sudo apt-get install -y apt-transport-https ca-certificates curl gpg

    curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.34/deb/Release.key \
      | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

    echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.34/deb/ /' \
      | sudo tee /etc/apt/sources.list.d/kubernetes.list

    sudo apt-get update
    sudo apt-get install -y kubelet kubeadm kubectl
    sudo apt-mark hold kubelet kubeadm kubectl
    sudo systemctl enable kubelet
  "
done

Підготовка: Встановлюємо інструменти для безпечного завантаження пакетів (HTTPS, сертифікати, GPG)
Додавання ключа: Завантажуємо криптографічний ключ від офіційного репозиторію Kubernetes. Це як печатка, що підтверджує автентичність пакетів
Додавання репозиторію: Додаємо офіційний репозиторій Kubernetes версії 1.34 до списку джерел пакетів
Встановлення:
- kubelet — агент на кожному вузлі, який запускає контейнери
- kubeadm — інструмент для ініціалізації кластера
- kubectl — клієнт командного рядка для управління кластером

‼️ apt-mark hold запобігає автоматичному оновленню зафіксованих пакетів. Версії всіх компонентів у кластері мають збігатися! Додаємо kubelet в автозапуск

2.8. Готово! ✅

Всі ці кроки можна обʼєднати в один скрипт, який виконає їх послідовно на всіх вузлах та підготує їх до створення кластера.

Всі три машини готові стати частиною Kubernetes-кластера!¹

Крок 3: Ініціалізація Control Plane

Підключаємось до control plane

multipass shell k8s-control

Ця команда відкриває термінал всередині віртуальної машини k8s-control. Тепер ми працюємо безпосередньо на цій машині, як якби сиділи за нею локально.

Отримання IP-адреси

CONTROL_IP=$(hostname -I | awk '{print $1}')

hostname -I — показує всі IP-адреси цієї машини
awk '{print $1}' — витягує першу адресу зі списку
$() — зберігає результат у змінну CONTROL_IP

Нам потрібна IP-адреса, щоб worker-вузли знали, куди підключатися.

Ініціалізуємо кластер 🚀

sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --apiserver-advertise-address=$CONTROL_IP

Kubeadm — це інструмент для швидкого створення Kubernetes-кластера. Команда kubeadm init ініціалізує панель управління (control plane), налаштовує API server, scheduler, controller manager та інші компоненти. В кінці виводиться команда kubeadm join, яку потрібно виконати на worker-вузлах, щоб приєднати їх до кластера.

Параметри:

--pod-network-cidr=10.244.0.0/16 — діапазон IP-адрес для Podʼів (для Flannel)
--apiserver-advertise-address — IP для підключення інших вузлів

⏱️ Це займе 1-2 хвилини.

📝 Збережіть команду kubeadm join, яку виведе команда!

Налаштовуємо kubectl

Крім виводу команди kubeadm join, виводиться інструкція для налаштування kubectl на панелі управління для керування кластером від імені поточного користувача.

mkdir -p ~/.kube
sudo cp /etc/kubernetes/admin.conf ~/.kube/config
sudo chown $(id -u):$(id -g) ~/.kube/config

kubectl потребує конфігураційний файл для підключення до кластера.

mkdir -p ~/.kube — створюємо папку для конфігурації (якщо її ще немає)
cp admin.conf ~/.kube/config — копіюємо файл з правами адміністратора
chown — змінюємо власника файлу на поточного користувача (щоб не потрібно було використовувати sudo для kubectl)

Крок 4: Встановлення мережевого втулка (CNI) — Flannel

kubectl apply -f https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml

Flannel — мережевий втулок (Container Network Interface, CNI), що дозволяє Podʼам на різних вузлах спілкуватися між собою.

Kubernetes сам по собі не знає, як організувати мережу. Flannel створює overlay-мережу, де всі Podʼи наче в одній локальній мережі 🌐

Ця команда завантажує та застосовує YAML-маніфест, який створює всі необхідні ресурси (DaemonSet, ConfigMap, ServiceAccount тощо).

Крок 5: Приєднання Worker-вузлів

Під час ініціалізації kubeadm init вивела команду kubeadm join, яку потрібно виконати на кожному worker-вузлі.

for NODE in k8s-worker-1 k8s-worker-2; do
  multipass exec $NODE -- sudo kubeadm join 192.168.2.26:6443 \
    --token bsw6fd.e7624wl2688fybjx \
    --discovery-token-ca-cert-hash sha256:7850aa1c6181277e284a08b81256979db25698a89982f0885540376a5376e0bd
done

⚠️ ВАЖЛИВО: У вашому випадку IP, токен та хеш будуть іншими! Використовуйте команду, яку ви отримали від kubeadm init.

Що тут:

multipass exec $NODE -- — виконуємо команду на кожному worker-вузлі
192.168.2.14:6443 — адреса API server (порт 6443 — стандартний)
--token — тимчасовий токен автентифікації (згенерований під час виконання kubeadm init)
--discovery-token-ca-cert-hash — SHA256-хеш сертифікату CA для перевірки автентичності (захист від атак типу man-in-the-middle)

Крок 6: Перевірка кластера

Повертаємося на вузол панелі управління (control plane) та перевіряємо статус вузлів.

multipass shell k8s-control
kubectl get nodes

Ви повинні побачити три вузли зі статусом Ready:

NAME            STATUS   ROLES           AGE   VERSION
k8s-control     Ready    control-plane   5m    v1.34.0
k8s-worker-1    Ready    <none>          2m    v1.34.0
k8s-worker-2    Ready    <none>          2m    v1.34.0

Якщо статус NotReady, почекайте хвилину — Flannel ще налаштовується ⏳

Крок 7: Встановлення MetalLB

Що таке MetalLB?

MetalLB — це load balancer для bare-metal кластерів. В керованих (managed) розгортаннях Kubernetes від хмарних провайдерів (AWS, GCP) сервіси типу LoadBalancer створюються автоматично. У нашому локальному кластері MetalLB надає цю функціональність. 🎯

Застосовуємо маніфести

kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.15.3/config/manifests/metallb-native.yaml

Чекаємо готовності

kubectl wait --namespace metallb-system \
  --for=condition=ready pod \
  --selector=app=metallb

Ця команда чекає, поки всі Pod’и MetalLB не перейдуть у стан готовності.

Маркування worker-вузлів

Для того щоб призначити мітки всім вузлам, імена яких починаються з k8s-worker-, можна використати команду kubectl get nodes разом із фільтрацією за допомогою grep та подальшим циклом for для застосування мітки до кожного знайденого вузла.

NODES=$(kubectl get nodes -o jsonpath='{.items[*].metadata.name}' | tr -s '[[:space:]]' '\n' | grep '^k8s-worker-')

for NODE in $NODES; do
  echo "Applying label to node: $NODE"
  kubectl label node "$NODE" metallb-role=worker --overwrite
done

Додаємо мітку metallb-role=worker до worker-вузлів. Мітки (labels) — це key-value пари, що допомагають організовувати та вибирати ресурси в Kubernetes. Ми використаємо цю мітку, щоб MetalLB працював тільки на worker-вузлах.

Налаштування IP-пулу та L2Advertisement

CONTROL_IP=$(hostname -I | awk '{print $1}')
BASE_IP=$(echo $CONTROL_IP | cut -d. -f1-3)

cat <<EOF | kubectl apply -f -
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: first-pool
  namespace: metallb-system
spec:
  addresses:
  - ${BASE_IP}.200-${BASE_IP}.250
---
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: worker-nodes-l2
  namespace: metallb-system
spec:
  ipAddressPools:
  - first-pool
  nodeSelectors:
  - matchLabels:
      metallb-role: worker
EOF

Що відбувається:

Отримання базової IP: Якщо IP control plane — 192.168.2.14, то BASE_IP буде 192.168.2
IPAddressPool — Визначає діапазон IP-адрес, які MetalLB може видавати LoadBalancer-сервісам. У нашому випадку — від .200 до .250 (51 адреса)
L2Advertisement — Налаштовує L2 (layer 2) режим. MetalLB оголошує IP-адреси через ARP-протокол, щоб мережа знала, де знаходяться ці адреси
nodeSelectors — Обмежує роботу MetalLB тільки вузлами з міткою metallb-role=worker

Крок 8: Демонстрація 🎉

Створюємо Deployment

kubectl create deployment hello \
  --image=nginxdemos/hello:plain-text \
  --replicas=3 \
  --port=80

Створюємо 3 репліки простого nginx-застосунку.

deployment — обʼєкт Kubernetes, що керує набором ідентичних Podʼів
--image — Docker-образ для контейнерів (простий nginx з текстовим виводом)
--replicas=3 — запустити 3 копії (для демонстрації балансування)
--port=80 — відкрити порт 80 у контейнері

Створюємо LoadBalancer Service

kubectl expose deployment hello \
  --type=LoadBalancer \
  --port=80

Service типу LoadBalancer — MetalLB виділить зовнішню IP-адресу для доступу до нашого застосунку! Service — це абстракція, що надає стабільний спосіб доступу до групи Podʼів:

expose deployment — ця команда створює Service для нашого Deployment
--type=LoadBalancer — цей параметр вказує, що потрібно використовувати зовнішній load balancer (MetalLB виділить IP)
--port=80 — порт, на якому Service буде доступний

Тестуємо балансування

EXTERNAL_IP=$(kubectl get svc hello -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
echo "LB IP: $EXTERNAL_IP"

for i in {1..10}; do
  echo "Request $i:"
  curl -s http://$EXTERNAL_IP | grep "Server address"
  echo "---"
done

Для тестування балансування нашого навантаження в змінну EXTERNAL_IP зберігаємо зовнішню IP-адресу, яку виділив MetalLB для сервісу hello; потім виконуємо 10 запитів до цієї IP-адреси та виводимо рядок з адресою сервера, який обробив кожен запит.

Результат: Ви побачите, що запити розподіляються між трьома різними Podʼами. Це балансування навантаження в дії! 🔄

Request 1:
Server address: 10.244.1.2:80
---
Request 2:
Server address: 10.244.2.3:80
---
Request 3:
Server address: 10.244.1.4:80
---

🚨 Важливо про SWAP

У стандартній конфігурації Multipass на віртуальних машинах swap вимкнений.

Kubelet стандартно відмовляється працювати, якщо swap увімкнений, тому що це може призвести до непередбачуваної поведінки Pod’ів. (контейнери можуть “виштовхуватись” на диск, що сповільнює їх роботу).

У нашому випадку все ок — swap вимкнений автоматично! ✅

Але якщо ви налаштовуєте K8s на інших системах, де swap увімкнений:

Варіант 1: Вимкніть swap

sudo swapoff -a
# І закоментуйте swap у /etc/fstab

Варіант 2: Налаштуйте kubelet для роботи зі swap (експериментально з K8s 1.28+)

Корисні команди

Перевірка статусу

kubectl get nodes
kubectl get pods -A
kubectl get svc

Перегляд логів

kubectl logs -n kube-system -l app=flannel
kubectl logs -n metallb-system -l app=metallb

Видалення ресурсів

kubectl delete svc hello
kubectl delete deployment hello

Зупинка кластера

# Зупинити всі ВМ
for NODE in "${NODES[@]}"; do
  multipass stop $NODE
done

# Запустити знову
for NODE in "${NODES[@]}"; do
  multipass start $NODE
done

Видалення кластера

for NODE in "${NODES[@]}"; do
  multipass delete $NODE
done
multipass purge

Підсумки

Вітаю! 🎉 Ми щойно створили повноцінний Kubernetes-кластер на своєму локальному компʼютері!

Що ми зробили:

✅ Створили 3 віртуальні машини
✅ Налаштували containerd та kernel-модулі
✅ Ініціалізували control plane
✅ Приєднали worker-вузли
✅ Встановили Flannel для мережі
✅ Налаштували MetalLB для LoadBalancer
✅ Розгорнули тестовий застосунок з балансуванням

Тепер у вас є локальне середовище для:

Експериментів з Kubernetes
Тестування маніфестів
Ознайомлення з архітектурою кластера
Підготовки до сертифікацій (CKA, CKAD)

Сподіваюсь, це керівництво було корисним!

Якщо у вас виникли питання або проблеми — пишіть у коментарях. Діліться цим постом з колегами, яким це може бути корисно 🚀

Happy Kubernetes! ☸️

Застереження 🚨

Цей кластер призначений для розробки та тестування.

Для промисловій експлуатації потрібні додаткові налаштування:

Firewall та Network Policies
RBAC (Role-Based Access Control)
Secrets Management
Моніторинг та логування
Резервне копіювання etcd
High Availability control plane
Сканування на вразливості

Скрипт для підготовки вузлів https://gist.github.com/Andygol/2944d08862d58e3c5a12becacd55b620 ↩

Від Docker до Kubernetes: коли контейнери перестають бути простими

2025-10-30T08:30:00+00:00

Ти це нарешті зробив.

Після днів, а може й тижнів роботи — твій застосунок повністю докеризований.

У тебе є Node.js API, React-фронтенд, Postgres база даних — кожен компонент охайно запакований у свій контейнер. Один docker-compose up, і все магічно оживає. Твоя локальна інфраструктура — мов оркестр: кожен контейнер грає свою партію, і ти — диригент.

Ти задоволений. Відчуваєш себе справжнім DevOps-чарівником.

Час для виходу в люди

На локальній машині все працює як годинник. Та коли настав час розгорнути все це на реальних серверах, ілюзія простоти швидко розсипається.

Ти хочеш надійності.
Ти хочеш масштабованості.
І здається, рішення очевидне:

«Я просто запущу ті самі контейнери на кількох серверах.»

Просто? Не зовсім.

Контейнери в хаосі

Ти стикаєшся з першим головним болем:

Як фронтенд знайде свій API, якщо IP контейнерів змінюються після кожного перезапуску?
Що буде, коли сервер впаде посеред ночі? Хто перезапустить контейнери?
Як оновити образ API, не зупинивши решту системи?

Ти починаєш писати Bash-скрипти, вручну копіюєш образи через SSH, намагаєшся якось балансувати трафік.
Але кожне оновлення — це ризик.
Кожен збій — це паніка.

Твій колись елегантний Docker-сетап перетворюється на хаотичну мережу костилів і ручних ритуалів.

Kubernetes — не просто Docker на стероїдах

Тут з’являється Kubernetes (або просто K8s)¹.

Можливо, ти вже чув: «Це щось складне», або «Це для корпорацій типу Google».
І дійсно — спочатку він здається надмірно громіздким.
Але це тому, що Kubernetes вирішує зовсім іншу проблему.

Docker — це спосіб упакувати застосунок. Kubernetes — це спосіб керувати цими застосунками в масштабі.

Він не просто запускає контейнери — він керує їхнім життєвим циклом: розміщення, масштабування, відновлення після збоїв, оновлення, доступність.

І головна ідея — у зміні мислення.

Декларативне мислення: “що”, а не “як”

Раніше ти працював імперативно:

“Запусти цей контейнер тут. Зупини цей — там.”

Kubernetes вимагає мислити декларативно:

“Хочу, щоб працювало три копії мого API з образом v1.2.
Кожна має мати 500 МБ пам’яті.
Вони мають бути доступні з іменем api-service.”

Ти не наказуєш — ти описуєш бажаний стан.
Kubernetes сам вирішує, як його досягти.
Його основна задача — постійно спостерігати за реальною системою і зводити її до бажаного стану.

Як Kubernetes вирішує справжні проблеми експлуатації

Автоматичне розміщення (Scheduling & Bin Packing)

Kubernetes бачить усі твої сервери (вони називаються вузлами — Nodes) і сам вирішує, де краще запустити контейнери. Він аналізує ресурси — CPU, RAM, дисковий простір і розподіляє навантаження оптимально. Жодних ручних призначень, жодних «цей контейнер — на цей сервер».

Самовідновлення (Self-Healing)

Контейнер впав? Kubernetes це помічає.
Фактичний стан — 2 копії, бажаний — 3.
Він просто запускає новий.

Жодних нічних викликів, жодних скриптів-відновлювачів.
Система лікує себе сама.

Горизонтальне масштабування

Трафік зростає — потрібно більше копій API.
Ти змінюєш один рядок у YAML:

spec:
  replicas: 12

І Kubernetes сам піднімає додаткові контейнери, розподіляючи їх між вузлами.

А якщо не хочеш робити це вручну — просто вкажи правила автоматичного масштабування. K8s сам збільшить кількість контейнерів, коли зросте навантаження, і зменшить — коли спаде.

Виявлення сервісів і балансування навантаження

У Kubernetes контейнери не шукають один одного за IP.
Ти створюєш Service — абстракцію, яка надає стабільне ім’я (наприклад, api-service) і внутрішню IP-адресу.

Фронтенд просто звертається до api-service, а Kubernetes сам визначає, на який контейнер API піде запит. Трафік автоматично розподіляється між справними екземплярами.

Жодних жорстко записаних в код IP, жодних ручних налаштувань балансування.

Автоматичні оновлення та відкати

Хочеш оновити свій API до версії v1.3?
Змінюєш версію образу в YAML — і все.

Kubernetes виконує rolling update — поступово запускає нові контейнери v1.3 і зупиняє старі v1.2.
Жодного простою. Користувачі навіть не помічають, як відбулось оновлення.

А якщо щось пішло не так — Kubernetes автоматично відкотиться до попередньої стабільної версії.

Kubernetes як операційна система для твоїх застосунків

Kubernetes — це не ще один інструмент DevOps. Це ціла операційна система для розподілених застосунків.

Він керує ресурсами, сервісами, оновленнями, трафіком, відновленням — усім, що раніше вимагало десятків ручних скриптів і безсонних ночей.

Ти більше не витрачаєш час на підтримку серверів. Ти зосереджуєшся на тому, що справді має значення — на розробці продукту.

Керованість

Kubernetes не обіцяє простоти — він дає керованість

Він дає тобі змогу описати, як має виглядати твоя система, а потім бере на себе все інше: розміщення, відновлення, масштабування, балансування, оновлення.

Docker був першим кроком.
Kubernetes — це наступний рівень зрілості інфраструктури.

Контейнери зробили розробку простішою.
Kubernetes робить експлуатацію передбачуваною.

Kubernetes — це переносима, розширювана та відкрита платформа для управління контейнеризованими навантаженнями та службами, яка полегшує як декларативне, так і автоматичне налаштування. Вона має велику та швидко зростаючу екосистему. Сервіси, підтримка та інструменти Kubernetes широко доступні.
https://andygol-k8s.netlify.app/uk/docs/concepts/overview/ ↩

Хвилинні зміни в OpenStreetMap не такі й хвилинні

2025-05-08T08:30:00+00:00

OpenStreetMap — це чудовий приклад проєкту зі спільного створення відкритої бази даних геопросторової інформації. Накопичення інформації це тільки частина справи. Її збирають для того, щоб нею можна було користуватись. Ви можете отримати дані для поточної ділянки на мапі скориставшись меню Експорт.

Однак можливості завантажити дані для поточної ділянки мають певні обмеження. Ви не зможете зробити це, якщо ви переглядаєте мапу в масштабі z11 та менше 👇. Бачите повідомлення в жовтому прямокутнику?

Планета OSM

У випадку, коли вам потрібні дані для більшої території, або навіть для всієї планети, вам пряма дорога до місця де проєкт пропонує дані для завантаження — дамп планети, https://planet.openstreetmap.org/

Тут ви можете завантажити дані для всієї планети, як у вигляді зрізу даних на певну дату або у вигляді дампу з повною історією змін, які генерується раз на тиждень.

Ці дані проєкт надає всім охочим безплатно, однак ви можете підтримати проєкт, зробивши пожертву чи ставши членом Фундації OpenStreetMap.

Файли змін даних

Для тих, хто не так глибоко знайомий з проєктом, diffs — це набори змін, що відбулись в даних, які публікуються OpenStreetMap кожного дня, години та хвилини. Ці файли містять перелік усіх змін, внесених до бази даних за обраний проміжок часу.

Розробники можуть використовувати ці diffs для оновлення своїх копій бази даних, які потім використовуються для геокодування, рендерингу мап та інших інструментів майже в режимі реального часу.

Однією з ключових особливостей, що дозволяє стежити за змінами в цій величезній базі даних, є концепція “хвилинних змін” (minute diffs). На перший погляд, назва натякає на майже миттєве відображення кожної зміненої деталі. Але чи справді все так? Звучить ідеально, правда? Але є кілька нюансів, які варто враховувати:

“Майже” реальний час — ключове слово. Хоча файли змін генеруються щохвилини, їхня фактична поява може затримуватися. Залежно від завантаженості серверів, процес генерації та публікації може зайняти трохи більше часу. Тож, хоча ви й можете побачити зміни протягом кількох хвилин, це не завжди буде рівно одна хвилина.
Обробка файлів змін — не миттєва. Отримання файлу змін — це лише перший крок. Потім програмне забезпечення повинно завантажити, розпарсити та застосувати ці зміни до локальної копії бази даних. Цей процес також займає певний час, який залежить від розміру файлу змін та продуктивності вашого обладнання. У хвилини пікового внесення змін до OpenStreetMap розмір таких файлів може значно зростати, уповільнюючи процес оновлення.
Порядок застосування змін має значення. Для забезпечення консистентності даних, зміни повинні застосовуватися в правильному порядку. Це означає, що якщо ви пропустили кілька хвилинних diffs (наприклад, через проблеми з мережею), вам доведеться обробити їх усі послідовно, перш ніж ваша база даних знов буде актуальною.

Використання файлів змін

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

Файл дампу планети в OpenStreetMap генерується раз на тиждень

На момент написання, 08 травня 2025 року, planet-latest.osm.bz2 було створено 2025-05-02 23:50, та його розмір був — 150G; ви також можете отримати дані у двійковому форматі pbf — planet-latest.osm.pbf, 2025-05-02 23:50, 81G; planet-250428.osm.pbf, 2025-05-02 23:50, 81G).

Цей, останній дамп містить дані станом на 25 квітня 2025 року, його було опубліковано — 02 травня 2025 року.

Виходить що на момент публікації дамп вже є на 7 діб застарілим, додайте до цього ще пару днів, коли ви захочете його завантажити, тож у вас на момент початку розгортання дані будуть застарілим на 1-2 тижні, додайте до цього ще час потрібний для завантаження дампу у вашу систему і ви можете виявити, що дані на момент початку їх використання втратили свою актуальність приблизно на 3-5 тижнів (якщо ми говоримо про масштаб планети). Для того щоб наздогнати це відставання та мати актуальні дані варто скористатись файлами реплікації https://planet.openstreetmap.org/replication/, нашими денними, годинними та хвилинними файлами змін.

Процес реплікації

Кожен файл змін містить має додатковий файл з метаданими про сам файл змін — state.txt.

Файл state.txt містить інформацію про часовий відбиток та номер в послідовності наборів змін, за цим номером ми можемо отримати сам файл зі змінами (717.osc.gz, 2025-05-08 17:01, 101K). Для зручності, номер набору змін розбивається на триплети 006/590/717.

Відомості про найсвіжіший файл набору змін міститься в корені відповідних змін, для хвилинних це — https://planet.openstreetmap.org/replication/minute/state.txt.

Для того щоб наздогнати стан ваших локальних даних з поточними даними, що є в OpenStreetMap, вам потрібно визначити часовий відбиток, що є останнім у вашому локальному дампі. Наприклад, у дампі станом на 24 березня 2025 останній відбиток часу був 2025-03-24T00:59:53Z.

Тепер коли у вас є цей час вам потрібно знайти відповідний файл змін (денних чи годинних) та його номер. В цьому вам може допомогти цей сервіс:

https://replicate-sequences.osm.mazdermind.de/?2013-01-01T10:00:00Z

або

curl "https://replicate-sequences.osm.mazdermind.de/?$(date -u -d "@$(stat -c "%Y" planet-latest.osm.pbf)" +"%FT%TZ")"

Пошук файлу змін вручну

Для денних та годинних змін ви також можете скористатись наступним підходом:

Початковий часовий відбиток (останній з файлу дампа) перетворюємо в Unix epoch time
```
date -d "2025-03-24T00:59:53Z" +%s
# або явно зазначивши формат часового відбитку
date -u -j -f "%Y-%m-%dT%H:%M:%SZ" "2025-03-24T00:59:53Z" +%s
```
отримуємо час Unix в секундах 1742777993.
Отримуємо часовий відбиток з останнього state.txt (відповідно для денних та годинних змін) разом з поточним номером в послідовності змін.
Обчислюємо різницю в часі (в днях та годинах), отримане значення віднімаємо від номера послідовності та отримуємо посилання для завантаження файлу змін з якого ми почнемо наздоганяти відставання в наших локальних даних.

DUMP_EPOCH_TS=$(date -d "2025-03-24T00:59:53Z" +%s)
REFERENCE_DATE=$(wget -q -O - https://planet.openstreetmap.org/replication/day/state.txt 2>/dev/null | grep "timestamp" | cut -d'=' -f2 | sed 's/T/ /;s/Z//; s/\\//g')
REFERENCE_SEQ=$(wget -q -O - https://planet.openstreetmap.org/replication/day/state.txt 2>/dev/null | grep "sequenceNumber" | cut -d'=' -f2 )
LAST_EPOCH_TS=$(date -d "$REFERENCE_DATE" +%s)

# Тут приклад для обчислення різниці в днях 86400 сек = 24 год
# Замініть на 3600 для обчислення різниці в годинах
DIFF_TS=$(( ($LAST_EPOCH_TS - DUMP_EPOCH_TS) / 86400 ))
TARGET_SEQ=$(( (10#$REFERENCE_SEQ - $DIFF_TS) + 1 ))
seq_padded=$(printf "%09d" "$TARGET_SEQ")
url="https://planet.openstreetmap.org/replication/day/${seq_padded:0:3}/${seq_padded:3:3}/${seq_padded:6:3}.state.txt"

Змінна $url міститиме посилання на state.txt файл для початку процесу реплікації. Цей файл потрібен для osmosis чи подібного інструменту. (Докладніше про сам процес реплікації даних дивіться: https://wiki.openstreetmap.org/wiki/Planet.osm/diffs)

Описаний вище підхід добре підходить для файлів денних та годинних змін, однак не спрацьовує для хвилинних змін.

Проблеми з обчисленням хвилинних змін

Описаний вище підхід для обчислення номера файлу змін для початку реплікації не працює для хвилинних змін. Чому? Тому що хвилинні зміни можуть створюватись більше ніж 60 секунд, через це відбувається “проковзування” в часовому ряді.

Так, якщо взяти діапазон хвилинних змін 6590000 — 6590227, отримаємо 233 хвилини та всього 227 файлів з хвилинними змінами.

На графіках ви можете побачити, скільки часу було витрачено на створення хвилинних змін, та в які хвилини вони були створені. Тут ми бачимо, що о 7:59, 8:02 та 8:05 змін не було створено, відбулося “проковзування”

Sequence	Timestamp	Epoch, seconds	Epoch, minutes	Time, sec	Clock
6590194	2025-05-08 8:12:08	1746681128	29111352	65	8:12
6590193	2025-05-08 8:11:05	1746681065	29111351	63	8:11
6590192	2025-05-08 8:10:01	1746681001	29111350	64	8:10
6590191	2025-05-08 8:09:01	1746680941	29111349	60	8:09
6590190	2025-05-08 8:08:01	1746680881	29111348	60	8:08
6590189	2025-05-08 8:07:02	1746680822	29111347	59	8:07
6590188	2025-05-08 8:06:00	1746680760	29111346	62	8:06
6590187	2025-05-08 8:04:59	1746680699	29111344	61	8:04
6590186	2025-05-08 8:04:00	1746680640	29111344	59	8:04
6590185	2025-05-08 8:03:00	1746680580	29111343	60	8:03
6590184	2025-05-08 8:01:59	1746680519	29111341	61	8:01
6590183	2025-05-08 8:00:58	1746680458	29111340	61	8:00
6590182	2025-05-08 8:00:00	1746680400	29111340	58	8:00
6590181	2025-05-08 7:58:56	1746680336	29111338	64	7:58
6590180	2025-05-08 7:57:51	1746680271	29111337	65	7:57

В цій таблиці також видно, що впродовж 15 хвилин відбулося 3 “проковзування”.

Чи є це критичним для повсякденного використання? Раз таке відбувається вже давно то схоже, що — ні. Наявні інструменти обробки змін цим не переймаються. Так, це може викликати трохи надлишкового трафіку, якщо для хвилинних змін ви відступите трохи далі в минуле ніж треба, однак це не вплине на фінальний результат. Ви отримаєте власний набір даних, що буде синхронізований з даними OpenStreetMap з відставанням до 2 хвилин.

Чи можна це виправити? Можливо

Обробка даних з привʼязкою в часі завжди є нетривіальним завданням. Для виправлення цього стану:

В метадані наборів змін в полі timestamp потрібно вказувати час початку (момент в часі на який припав початок створення набору змін), цей час в ідеалі має бути цілим (чи дуже близьким до цього) часом у хвилинах, годинах та днях:
- 13:00:00, 13:01:00, 13:02:00 — для хвилин;
- 14:00:00, 15:00:00 — для годин; та
- 00:00:00 — для днів.
Часом завершення процесу створення змін буде час модифікації самого файлу, хоча його можна також вказати в метаданих набору змін (це той час, який зараз міститься в timestamp).
Створення наступного набору змін має починатись в обумовлений час незалежно від того чи завершилось завдання зі створення попереднього набору змін. Певний час вони можуть виконуватись паралельно.
У разі відсутності змін — створювати пустий файл набору змін для підтримання монотонного порядку нумерування змін, щоб не було пропусків в часовому ряді.

Якщо вам дошкуляє такий стан справ, ви можете подати пропозиції щодо його виправлення супровідникам проєкту, можливо це буде виправлено. Як швидко? Важко сказати.

Підсумки

Файли змін залишаються надзвичайно цінним інструментом для підтримки актуальності даних OpenStreetMap. Однак важливо розуміти їхні обмеження та не сприймати назву буквально, особливо це стосується хвилинних змін.

Для розробників, які використовують хвилинні файли змін, це означає необхідність мати надійну інфраструктуру для їхньої обробки, враховувати можливі затримки та бути готовими до обробки великих обсягів даних у періоди активного редагування.

А для звичайних користувачів це просто цікавий факт про те, як працює “за лаштунками” улюблена ними відкрита мапа. Наступного разу, коли ви внесете невелику правку і не побачите її на своєму сервері з мапою миттєво, не хвилюйтеся — можливо, ваш “хвилинний” файл просто ще в дорозі!

Що ви думаєте про хвилинні зміни? Чи стикалися ви з затримками в оновленні даних? Поділіться своїм досвідом у коментарях!

Доступ до файлової системи хосту для Persistent Volume в Kind

2025-04-05T08:30:00+00:00

Кубернетіс вже перестає бути чимось таким з чим працюють лише інженери платформи. Все більше і більше застосунків загортаються в контейнери та запускаються в контейнерних середовищах. Що робити, якщо з певних причин у вас немає доступу до хмарної платформи, але треба вести розробку застосунку, який працюватиме в хмарі? Ви можете скористатись Kind для локального розгортання Кубернетіс.

Kind — це інструмент для запуску локальних кластерів Kubernetes з використанням «вузлів» контейнерів Docker. В першу чергу kind був розроблений для тестування самого Kubernetes, але може бути використаний для локальної розробки або CI.

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

Створення кластера

Отже, ми маємо встановлений Kind та середовище для роботи з контейнерами, kubectl – інструмент командного рядка для виконання маніпуляцій з кластером.

Для створення локального кластера скористаємось командою kind create cluster.

Ви завжди можете отримати потрібну довідку скориставшись командою виду kind [command] --help.

Ми створили свій локальний кластер з іменем kind-kind. Це стандартне імʼя, яке використовує kind, якщо параметр -n назва або --name назва не вказано.

Крім використання ключів для kind ми можемо використати маніфест для створення кластера з потрібними нам параметрами.

cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: my-super-cluster
nodes:
- role: control-plane
- role: worker
  extraMounts:
  - hostPath: /path/to/local/data
    containerPath: /data
# - role: worker
# - role: worker
#   extraMounts:
#   - hostPath: /path/to/local/data/dump
#     containerPath: /data/dump
#   - hostPath: /path/to/local/data/diff
#     containerPath: /data/diff

☝️ тут ми можемо зазначити кількість потрібних вузлів, їх роль та, головне, в нашому випадку, — шлях у локальній файловій системі, який ми будемо монтувати у вузли нашого кластера та використовувати, як систему зберігання для наших Постійних Томів (Persistent Volumes). Див Extra Mounts в документації Kind.

Застосуємо нашу конфігурацію для створення кластера

kind create cluster --config kind-config.yaml

Creating cluster "kind" ...
 ✓ Ensuring node image (kindest/node:v1.32.2) 🖼
 ✓ Preparing nodes 📦
 ✓ Writing configuration 📜
 ✓ Starting control-plane 🕹️
 ✓ Installing CNI 🔌
 ✓ Installing StorageClass 💾
Set kubectl context to "kind-my-super-cluster"
You can now use your cluster with:

kubectl cluster-info --context kind-my-super-cluster

Have a question, bug, or feature request? Let us know! https://kind.sigs.k8s.io/#community 🙂

Перевіримо, що файлову систему хосту змонтовано у вузол worker нашого кластера.

docker container inspect osm-cluster-worker \
  | jq '[{"Name": .[0].Name,
          "BindMounts": (
            .[] |
            .Mounts[] |
            select(.Type == "bind")
        )}]'

І бачимо, що все ОК, файлову систему змонтовано.

[
  {
    "Name": "/my-super-cluster-worker",
    "BindMounts": {
      "Type": "bind",
      "Source": "/host_mnt/path/to/local/data",
      "Destination": "/data",
      "Mode": "",
      "RW": true,
      "Propagation": "rprivate"
    }
  },
  {
    "Name": "/my-super-cluster-worker",
    "BindMounts": {
      "Type": "bind",
      "Source": "/lib/modules",
      "Destination": "/lib/modules",
      "Mode": "ro",
      "RW": false,
      "Propagation": "rprivate"
    }
  }
]

Створення PersistentVolume та PersistentVolumeClaim

Створимо маніфест для Постійного Тому

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-super-cluster-pv
spec:
  capacity:
    storage: 100Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  hostPath:
    path: "/data"
  storageClassName: my-storageclass

А також створимо Заявку PersistentVolumeClaim яку будемо використовувати для монтування Постійного Тому в робочі навантаження.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name:  my-super-cluster-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: my-storageclass

Тепер найголовніше 🥁, потрібно створити StorageClass, який дозволить нам явно повʼязати Заявку PVC з Постійним Томом PV.

Примітка: Зверніть увагу що kind створює стандартний StorageClass під час створення кластера. Однак цей StorageClass не задовольняє нашим вимогам маючи reclaimPolicy:Delete.

kubectl get storageclass

NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  80m

Це означає, що вміст нашого Постійного Тому буде очищатись після його розмонтування з пода, а це не те що нам треба.

Створимо наш StorageClass в кластері.

kubectl apply -f -  <<EOF
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storageclass
provisioner: rancher.io/local-path
parameters:
  nodePath: /data
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
EOF

storageclass.storage.k8s.io/my-storageclass created

Перевіримо наш StorageClass.

kubectl get storageclass

NAME                 PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
my-storageclass      rancher.io/local-path   Retain          WaitForFirstConsumer   false                  5m27s
standard (default)   rancher.io/local-path   Delete          WaitForFirstConsumer   false                  91m

І зробимо його типовим, на про всяк випадок

kubectl patch storageclass my-storageclass -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

а StorageClass standard навпаки, зробимо звичайним.

kubectl patch storageclass standard -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

Переглянемо поточні відомості про StorageClass

kubectl get storageclass

NAME                        PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
my-storageclass (default)   rancher.io/local-path   Retain          WaitForFirstConsumer   false                  12m
standard                    rancher.io/local-path   Delete          WaitForFirstConsumer   false                  98m

Використання PersistentVolumeClaim в поді

Застосуємо маніфести PV та PVC в кластері.

kubectl apply -f pv.yaml -f pvc.yaml

Створимо под, який використовує Заявку на постійний том для зберігання даних.

kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
  name: debug-pod
spec:
  containers:
  - name: debug-container
    image: busybox:latest
    command: ["sh", "-c", "sleep 3600"]
    volumeMounts:
    - mountPath: "/data"
      name: my-super-cluster
  volumes:
  - name: my-super-cluster
    persistentVolumeClaim:
      claimName: my-super-cluster-pvc
EOF

Перевіримо що Заявка PVC має привʼязку до PV та використовується в нашому тестовому поді

kubectl get pv

NAME                  CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                          STORAGECLASS      VOLUMEATTRIBUTESCLASS   REASON   AGE
my-super-cluster-pv   100Gi      RWO            Retain           Bound    default/my-super-cluster-pvc   my-storageclass   <unset>                          9m20s

kubectl get pvc

NAME                   STATUS   VOLUME                CAPACITY   ACCESS MODES   STORAGECLASS      VOLUMEATTRIBUTESCLASS   AGE
my-super-cluster-pvc   Bound    my-super-cluster-pv   100Gi      RWO            my-storageclass   <unset>                 8m48s

Зверніть увагу що статус PV та PVC має значення Bound, що означає що Заявку було успішно звʼязано з Постійним Томом.

kubectl describe pod

Name:             debug-pod
Namespace:        default
Priority:         0
Service Account:  default
Node:             kind-control-plane/172.20.0.4
Start Time:       Fri, 04 Apr 2025 18:17:09 +0300
Labels:           <none>
Annotations:      <none>
Status:           Running
IP:               10.244.0.5
IPs:
  IP:  10.244.0.5
Containers:
  debug-container:
    Container ID:  containerd://d030a6edfc13c314853f22efc505990bbbb8e3954ed1c9887b9c7b3be575a0be
    Image:         busybox:latest
    Image ID:      docker.io/library/busybox@sha256:37f7b378a29ceb4c551b1b5582e27747b855bbfaa73fa11914fe0df028dc581f
    Port:          <none>
    Host Port:     <none>
    Command:
      sh
      -c
      sleep 3600
    State:          Running
      Started:      Fri, 04 Apr 2025 18:17:13 +0300
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /data from my-super-cluster (rw)
      /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-5wdzj (ro)
Conditions:
  Type                        Status
  PodReadyToStartContainers   True
  Initialized                 True
  Ready                       True
  ContainersReady             True
  PodScheduled                True
Volumes:
  my-super-cluster:
    Type:       PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
    ClaimName:  my-super-cluster-pvc
    ReadOnly:   false
  kube-api-access-5wdzj:
    Type:                    Projected (a volume that contains injected data from multiple sources)
    TokenExpirationSeconds:  3607
    ConfigMapName:           kube-root-ca.crt
    ConfigMapOptional:       <nil>
    DownwardAPI:             true
QoS Class:                   BestEffort
Node-Selectors:              <none>
Tolerations:                 node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
                             node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
  Type    Reason     Age    From               Message
  ----    ------     ----   ----               -------
  Normal  Scheduled  8m36s  default-scheduler  Successfully assigned default/debug-pod to kind-control-plane
  Normal  Pulling    8m36s  kubelet            Pulling image "busybox:latest"
  Normal  Pulled     8m32s  kubelet            Successfully pulled image "busybox:latest" in 3.395s (3.395s including waiting). Image size: 1855985 bytes.
  Normal  Created    8m32s  kubelet            Created container: debug-container
  Normal  Started    8m32s  kubelet            Started container debug-container

Наш под було успішно створено і він працює.

Отримаємо доступ до термінала в нашому поді та перевіримо, що том змонтований у нашій файловій системі і все працює належним чином.

kubectl exec -it debug-pod -- sh

/ # ls -l / | grep data
drwxr-xr-x    2 root     root          4096 Apr  4 15:17 data
/ # touch /data/somefile.txt
/ # ls -l /data
total 0
-rw-r--r--    1 root     root             0 Apr  4 15:31 somefile.txt
/ #
/ # exit

Тепер перегляньте файлову систему хосту змонтовану у вузол worker нашого кластера і ви побачите там тільки що створений файл somefile.txt.

Підсумки

Ми створили Заявку на використання Постійного Тому в робочому навантажені, яка використовує Клас Зберігання (StorageClass) для звʼязування Заявки з Томом. Постійний том використовує систему зберігання наявну на вузлі нашого кластера. Система зберігання вузла кластера базується на файловій системі хосту, на якому розгорнуто наш кластер.

У такий спосіб ми можемо надійно зберігати та повторно використовувати дані розміщені в Постійному Томі в робочих навантаження нашого кластера, які за своєю природою мають обмежений життєвий цикл. Окрім цього ми також можемо передавати в наші робочі навантаження попередньо створені дані з нашого хосту та використовувати їх в подах.

Очищення

Для очищення (вилучення) кластера скористайтесь наступною командою.

kind delete cluster --name kind-my-super-cluster

Deleting cluster "kind-my-super-cluster" ...

Зачекайте допоки Kind видаліть кластер. За потреби видаліть створені файли у файловій системі хосту.

Додаткові матеріали

Kind Quick Start
Kind Persistent Volumes
Rancher Local Path Provisioner
Томи, Постійні Томи, Класи сховищ в Кубернетіс

Розгортаємо контейнер з приватного реєстру ghcr.io в Amazon ECS

2024-06-26T08:30:00+00:00

У кожного настає такий момент, коли вам потрібно розгорнути контейнер з приватного репозиторію на ECS. Документація від Amazon не є взірцем зрозумілості, тому я підготував для вас (в першу чергу для себе) опис того, що для цього потрібно зробити.

Передумови

Контейнер в ghcr.io

Для початку, вам потрібно завантажити контейнер на GitHub Container Registry. Це може бути як публічний, так і приватний репозиторій.

Входите в GitHub і переходите на сторінку репозиторію, в якому знаходиться ваш контейнер. В розділі Packages обираєте артефакт, який є створеним раніше контейнером.

Для доступу до вашого реєстру вам знадобиться токен доступу Private Access Token. Для створення PAT перейдіть в налаштування вашого облікового запису.

Внизу сторінки оберіть Developer settings

Далі, виберіть Personal access tokens/Tokens (classic)/Generate new token (classic).

або, перейдіть за цим посиланням для створення PAT — https://github.com/settings/tokens/new.

Додайте за потреби Примітку, оберіть час дії токена (через скільки днів він перестане бути валідним), та вкажіть потрібні права доступу – в цьому випадку нам потрібно лише мати права на отримання пакетів (read:packages — Download packages from GitHub Package Registry). Внизу сторінки натисніть кнопку Generate token.

Після цього ви побачите сторінку з вашим новим токеном. Скопіюйте його та збережіть у безпечному місці. Ми будемо його використовувати для доступу до реєстру.

ECS

У вас має бути налаштований обліковий запис в AWS, за бажанням локально встановлений AWS CLI та Amazon ECS CLI. Якщо ви не бажаєте встановлювати їх локально, ви можете використовувати AWS CloudShell.

Створення CMK в AWS KMS

Для початку, нам потрібно створити CMK (Customer Master Key) та аліасу для нього в AWS KMS. CMK використовується AWS Secret Manager для шифрування конвертів, даних які містять чутливу інформацію. Аліас виступає як назва для вашого CMK, її простіше запамʼятати та використовувати ніж сам ідентифікатор ключа. Також ви можете використовувати аліас у вашому коді. Ви можете змінювати ключ у майбутньому (на інший), залишаючи аліас незмінним.

aws kms create-key --query KeyMetadata.Arn --output text

у відповідь ви отримаєте ідентифікатор вашого ключа, у вигляді Amazon Resource Name (ARN) наприклад:

arn:aws:kms:eu-central-1:123456789012:key/abc123de-4567-89fa-0bcd-efgh12345678

Тепер ми створимо аліас для нашого ключа:

aws kms create-alias \
  --alias-name alias/ecs-ghcr \
  --target-key-id arn:aws:kms:eu-central-1:123456789012:key/abc123de-4567-89fa-0bcd-efgh12345678

Якщо ви не налаштовували собі локально AWS CLI, ви можете скористатись CloudShell та виконувати всі команди в командному рядку там.

Створення CMK ви можете зробити в Консолі AWS, перейшовши в AWS KMS та натиснувши кнопку Create key.

ARN CMK вам знадобиться при створенні документа політики довіри на наступному кроці.

Створення Secret в AWS Secrets Manager

На цьому етапі нам потрібно створити Secret, який буде містити ваш логін на пароль (код доступу) зашифровані за допомогою CMK для витягування образу вашого контейнера з приватного реєстру.

aws secretsmanager create-secret \
  --name ghcr_io_pat \
  --description "Secret to get packages from ghcr.io" \
  --kms-key-id alias/ecs-ghcr \
  --secret-string '{"username":"your_nickname", "password":"ghp_XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"}'

У відповідь ви маєте отримати наступне:

{
    "ARN": "arn:aws:secretsmanager:eu-central-1:123456789012:secret:ghcr_io_pat-abcdEF",
    "Name": "ghcr_io_pat",
    "VersionId": "4b43b832-df4c-48b3-b59a-bb18287e6c15"
}

ARN секрету повинен бути у виводі ☝️ попередньої команди – поле ARN. Вам потрібно буде посилатися на цей ARN під час створення документа політики довіри на наступному кроці.

Створення ролі в IAM для виконання завдання

У випадку наявності у вас ролі ecsTaskExecutionRole можете пропустити цей крок.

Спочатку вам потрібно буде створити документ політики довіри, щоб вказати виконавця, який візьме на себе роль, що в цьому випадку є ECS task:

cat << EOF > ecs-trust-policy.json
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "ecs-tasks.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
EOF

Створимо роль скориставшись AWS CLI та файлом ecs-trust-policy.json з описом ролі.

aws iam create-role \
  --role-name ecsTaskExecutionRole \
  --assume-role-policy-document file://ecs-trust-policy.json

Щоб додати основні дозволи до інших ресурсів сервісів AWS, які необхідні для запуску завдань Amazon ECS, прикріпіть політику ролі виконання завдань AWS ECS до новоствореної ролі:

aws iam attach-role-policy \
  --role-name ecsTaskExecutionRole \
  --policy-arn arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy

Тепер створимо документ політики дозволів, який дозволяє завданню ECS розшифрувати та отримати секрет, створений в AWS Secrets Manager.

cat << EOF > ecs-secret-permission.json 
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt",
        "secretsmanager:GetSecretValue"
      ],
      "Resource": [
        "arn:aws:secretsmanager:eu-central-1:123456789012:secret:ghcr_io_pat-abcdEF",
        "arn:aws:kms:eu-central-1:123456789012:key/abc123de-4567-89fa-0bcd-efgh12345678"
      ]
    }
  ]
}
EOF

☝️ вкажіть свої Secret та CMK в значення "Resource": [ <Secret>, <CMK> ].

Нарешті, додайте інтегровану політику дозволів, яка дозволить вашій задачі отримувати імʼя користувача та пароль до ghcr.io з AWS Secrets Manager. Зверніть увагу, що ви посилаєтеся на документ політики дозволів, створений на попередньому кроці. Змініть шлях до теки за необхідності, щоб визначити правильне розташування файлу:

aws iam put-role-policy \
  --role-name ecsTaskExecutionRole \
  --policy-name ECS-SecretsManager-Permission \
  --policy-document file://ecs-secret-permission.json

Налаштування ECS CLI (необовʼязково)

Інструмент командного рядка для Amazon ECS (ESC CLI) надає команди для спрощення створення кластера Amazon ECS та AWS ресурсів, необхідних для його налаштування. Після встановлення ECS CLI ви можете додатково налаштувати ваші AWS облікові дані в іменованому профілі ECS. Профілі зберігаються в файлі ~/.ecs/credentials.

ecs-cli configure profile \
  --access-key <AWS_ACCESS_KEY_ID> \
  --secret-key <AWS_SECRET_ACCESS_KEY> \
  --profile-name <PROFILE_NAME>

Ви також можете вказати стандартний профіль який використовувати для всіх команд ECS CLI:

ecs-cli configure profile default --profile-name <PROFILE_NAME>

Якщо ви не налаштовуєте профіль ECS або не встановлюєте змінні середовища, буде використано стандартний профіль AWS. Значення ключа доступу та секретного ключа доступу можна переглянути в AWS Management Console.

Ви можете додатково налаштувати назву кластера ECS, тип запуску та регіон AWS для використання з ECS CLI за допомогою команди ecs-cli configure. Значення змінної <LAUNCH_TYPE> можна встановити у FARGATE або EC2.

ecs-cli configure \
  --cluster <CLUSTER_NAME> \
  --default-launch-type <LAUNCH_TYPE> \
  --config-name <CONFIG_NAME> \
  --region <AWS_REGION>

Ці значення також можна визначити або перевизначити за допомогою прапорців команд, зазначених у наступних кроках.

Створення кластера Amazon ECS

Створимо кластер Amazon ECS за допомогою команди ecs-cli up, вказавши назву кластера, регіон AWS (наприклад, eu-central-1) та FARGATE як тип запуску:

ecs-cli up \
  --cluster <CLUSTER_NAME> \
  --region eu-central-1 \
  --launch-type FARGATE \

Використовуючи тип запуску FARGATE, ми використовуємо AWS Fargate для управління обчислювальними ресурсами від нашого імені, щоб нам не потрібно було вказувати власні екземпляри контейнера EC2. Типово ECS CLI також запустить стек AWS CloudFormation для створення нового VPC з прикріпленим Інтернет-шлюзом, 2 загальнодоступними підмережами та групою безпеки. Ви також можете вказати власні ресурси, використовуючи прапорці в команді вище.

Налаштування групи безпеки

Після успішного створення кластера ECS ви повинні побачити ідентифікатори VPC та підмережі, що відображаються в терміналі. Далі отримайте опис JSON новоствореної групи безпеки та занотуйте ідентифікатор групи безпеки або GroupId. Замініть змінну <VPC_ID> на ідентифікатор новоствореного VPC.

aws ec2 describe-security-groups \
  --filters Name=vpc-id,Values=<VPC_ID> \
  --region eu-central-1

У відповідь ви маєте отримати подібний вивід:

{
    "SecurityGroups": [
        {
            "Description": "default VPC security group",
            "GroupName": "default",
            "IpPermissions": [
                {
                    "IpProtocol": "-1",
                    "IpRanges": [],
                    "Ipv6Ranges": [],
                    "PrefixListIds": [],
                    "UserIdGroupPairs": [
                        {
                            "GroupId": "sg-04512c8a7bff9b34e",
                            "UserId": "123456789012"
                        }
                    ]
                },
                …
            ],
            …
        }
    ]
}

Додайте правило для вхідного трафіку до групи безпеки, що дозволяє HTTP-трафік з будь-якої адреси IPv4. Замініть змінну <SG_ID> на GroupId, отриману на попередньому кроці. Це вхідне правило дозволить вам підтвердити, що ваш сервер працює у вашому завданні та що образ з приватного реєстру було успішно отримано з GHCR.

aws ec2 authorize-security-group-ingress \
  --group-id <SG_ID> \
  --protocol tcp \
  --port 8080 \
  --cidr 0.0.0.0/0 \
  --region eu-central-1

Створення Service Amazon ECS

Service Amazon ECS дозволяє одночасно запускати та підтримувати кілька екземплярів визначення завдання. ECS CLI дозволяє створити Service за допомогою файлу Docker compose. Створіть наступний файл docker-compose.yml, який визначає контейнер, який надає порт 8080 для вхідного трафіку на сервер. Щоб посилатися на образ, який зберігається у вашому приватному реєстрі у GHCR, замініть змінну <USER_NAME> на ваше імʼя користувача GitHub, змінну <REPO_NAME> на імʼя вашого приватного репозиторію та змінну <TAG_NAME> на теґ, який ви використовували.

cat << EOF > docker-compose.yml
version: "3"
services:
    web:
        image: ghcr.io/<USER_NAME>/<REPO_NAME>:<TAG_NAME>
        ports:
            - 8080:8080
EOF

Так, якщо ви спробуєте розгорнути образ з прикладу на початку, значення змінної image буде наступним — ghcr.io/andygol/switch2osm-mkdocs:main.

Вам також потрібно буде створити наступний файл ecs-params.yml, щоб вказати додаткові параметри для вашого Service, специфічні для Amazon ECS. Зауважте, що поле services нижче відповідає полю services у файлі Docker Compose вище, що відповідає назві контейнера для запуску. Коли ECS CLI створює визначення завдання з файлу docker-compose.yml, поля web будуть обʼєднані в визначення контейнера ECS, включаючи образ контейнера, який він буде використовувати, та облікові дані сховища GHCR, які йому знадобляться для доступу до нього. Замініть змінну <SECRET_ARN> на ARN секрету AWS Secrets Manager, який ви створили раніше. Замініть змінні <SUB_1_ID>, <SUB_2_ID> та <SG_ID> ідентифікаторами 2 загальнодоступних підмереж та групи безпеки, які були створені разом з кластером ECS.

cat << EOF > ecs-params.yml
version: 1
task_definition:
  task_execution_role: ecsTaskExecutionRole
  ecs_network_mode: awsvpc
  task_size:
    mem_limit: 0.5GB
    cpu_limit: 256
  services:
    web:
        repository_credentials: 
            credentials_parameter: "<SECRET_ARN>"
run_params:
  network_configuration:
    awsvpc_configuration:
      subnets:
        - "<SUB_1_ID>"
        - "<SUB_2_ID>"
      security_groups:
        - "<SG_ID>"
      assign_public_ip: ENABLED
EOF

Далі створіть Service ECS зі свого файлу compose за допомогою команди ecs-cli compose service up. Ця команда шукатиме ваші файли docker-compose.yml та ecs-params.yml у поточній теці. Замініть змінну <CLUSTER_NAME> на імʼя вашого кластера ECS та змінну <PROJECT_NAME> на бажану назву вашого Service ECS.

ecs-cli compose \
  --project-name <PROJECT_NAME> \
  --cluster <CLUSTER_NAME> \
  service up \
  --launch-type FARGATE

Майте трохи часу на розгортання вашого Service ECS. Тепер ви можете перевірити стан вашого Service ECS за допомогою команди ecs-cli ps.

ecs-cli compose \
  --project-name <PROJECT_NAME> \
  --cluster <CLUSTER_NAME> \
  service ps

Перейшовши до IP-адреси, зазначеної на порту 8080, ви зможете переглянути головну сторінку нашого проєкту, підтверджуючи, що ваше завдання змогло успішно витягнути образ контейнера з реєстру GHCR, використовуючи ваші облікові дані для автентифікації.

Очищення

Припиніть роботу вашого Service ECS за допомогою команди ecs-cli compose service down.

ecs-cli compose \
  --project-name <PROJECT_NAME> \
  --cluster <CLUSTER_NAME> \
  service down

Видаліть стек AWS CloudFormation, який був створений ecs-cli up, та пов’язані з ним ресурси за допомогою команди ecs-cli down:

ecs-cli down --cluster <CLUSTER_NAME>

Розгортаємо застосунок React на GitHub Pages

2024-06-03T08:30:00+00:00

Тут я покажу вам, як розгорнути застосунок React на GitHub Pages за допомогою GitHub Actions. GitHub Pages — це сервіс хостингу статичних сайтів, який бере HTML, CSS та JavaScript файли безпосередньо з репозиторію на GitHub та робить їх доступними у вигляді вебсайту. GitHub Actions — це сервіс CI/CD, що дозволяє автоматизувати робочий процес публікації вашого статичного сайту на GitHub Pages.

Створення застосунку React

Спочатку створіть новий застосунок React за допомогою Create React App.

npx create-react-app react-app --template typescript
cd react-app

Ваш git-репозиторій має бути ініціалізований автоматично.

Створення репозиторію на GitHub

Перебуваючи у теці з новоствореним застосунком та створіть новий репозиторій на GitHub.

gh repo create

Налаштування репозиторію

Перейдіть до налаштувань репозиторію та увімкніть GitHub Pages. Оберіть джерело для Build and deployment — GitHub Actions.

Відкрийте меню Actions/General, прокрутіть до розділу Workflow permissions та надайте дозволи на читання та запис для робочого процесу GitHub Actions.

Додавання робочого процесу GitHub Actions

Створіть нову теку .github/workflows у корені вашого репозиторію.

mkdir -p .github/workflows

Створіть новий файл з назвою (наприклад) deploy.yml у теці .github/workflows.

Додайте назву вашого робочого процесу.

name: Deploy React App

Це дозволить вам вирізняти цей робочий процес серед інших.

Додайте наступний вміст до файлу deploy.yml.

…

on:
    push:
        branches: [main]
    pull_request:
        types:
            - closed
        branches: [main]
    workflow_dispatch:
…

Цей розділ описує події, що запускають робочий процес. У цьому випадку робочий процес буде запущений при безпосередньому внесенні змін в гілку main за допомогою git push, при виконанні pull request та при ручному запуску робочого процесу.

Додайте опис завдань до робочого процесу.

…
jobs:
  build:
    runs-on: ubuntu-latest
…

Наше завдання з ім’ям build буде виконуватись на останній версії Ubuntu.

Додайте кроки до завдання.

…
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '20'
…

Перший крок витягує код з репозиторію. Другий крок налаштовує Node.js.

Додайте більше кроків до завдання.

…
      - name: Install dependencies
        run: npm ci

      - name: Build
        run: npm run build
…

Третій крок встановлює залежності, а четвертий крок збирає застосунок React.

Додайте останні кроки до завдання.

…
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          name: 'github-pages'
          path: build
…

Тут ми використовуємо дію upload-pages-artifact для завантаження теки збірки як артефакту для подальшого розгортання.

Створіть кроки розгортання.

  deploy:
    if: github.event.pull_request.merged == true || github.event_name == 'push' || github.event_name == 'workflow_dispatch'
    needs: build

    permissions:
      pages: write
      id-token: write
      contents: read

    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}

Завдання розгортання буде виконуватись тільки якщо pull request обʼєднано з основною гілкою або робочий процес запускається через git push або вручну. Воно потребує завершення завдання build. Завдання розгортання має дозволи на запис до сторінок, запис токена id та читання вмісту. Ім’я середовища — github-pages, а URL — покаже вам адресу після завершення кроку розгортання.

Додайте кроки до завдання розгортання.

…
    runs-on: ubuntu-latest
    steps:
      - name: Setup Pages
        uses: actions/configure-pages@v5

      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          artifact_name: 'github-pages'

Перший крок налаштовує Pages. Другий крок розгортає теку збірки на GitHub Pages за допомогою deploy-pages. Ми використовуємо артефакт попередньо створений на етапі збірки (build) та GitHub token для автентифікації розгортання.

Тепер зробіть commit змін та надішліть їх у репозиторій.

git add .
git commit -m "Add GitHub Actions workflow"
git push

Налаштування `package.json`

Відкрийте файл package.json і додайте параметр homepage. Ви можете встановити його значення як . або надати URL вашого репо для GitHub Pages ("homepage": "https://andygol.github.io/react-app/").

{
  "name": "react-app",
  "version": "0.1.0",
  "private": true,
+  "homepage": ".",
  "dependencies": {
    …

Розгортання застосунку React

Будь-які зміни, які ви вносите до гілки main, запустять робочий процес GitHub Actions. Робочий процес збере застосунок React і розгорне його на GitHub Pages.

https://andygol.co.ua/react-app/

Ось і все! Ви успішно розгорнули застосунок React на GitHub Pages за допомогою GitHub Actions.

PS. Якщо ви хочете побачити повний файл робочого процесу, перегляньте репозиторій на GitHub.

OpenStreetMap — не Google Maps

2023-07-22T08:30:00+00:00

Тут мав би бути знімок з екрана з “Історії іграшок” де Баз намагається пояснити Вудді щось про зірки показуючи рукою вгору.

Десь років 20+ тому мені трапилось на очі коротеньке оповідання на навколокомпʼютерну тематику з елементами трилеру, в якому був момент, коли головний герой похапцем створював якісь геосервіси, застосунки, що їх використовують, майже на колінці, щоб вийти з ситуацій в якій він опинився. Тоді я не до кінця зрозумів всієї ідеї, бо з таким в житті ще не доводилось стикатись. І ось на дворі нове сторіччя/тисячоріччя у нас в кишені пристрій, який використовує ці загадкові геосервіси – смартфон.

Спробуємо визначитись з цими загадковими геосервісами. Насправді вони існували задовго до появи смартфонів, та і до появи компʼютерів взагалі. Найпростіший приклад – це поштові адреси. Знаючи номер будинку, назву вулиці ви можете дістатись до точки призначення. Спланувати (продумати) маршрут ви можете самотужки, намалювавши на клаптику паперу приблизну схему, або зробивши подібне у себе в голові. Насправді ми так робимо кожного разу як кудись виходимо з дому – плануємо свій маршрут і далі дотримуємося цього плану, навіть коли йдемо до найближчого магазину, щоб купити продуктів. Якщо ви вирушаєте в малознайоме, віддалене місце про яке у вас або мало відомостей, або ви там ніколи не бували, ви спитаєте у знайомих як туди краще дістатись, яким видом транспорту доїхати, на якій зупинці вийти, в якій бік далі йти і де й куди звернути. Можна взяти таксі і водій довезе вас за вказаною адресою чи орієнтирами. Якщо вам потрібно надіслати посилку в інше місто – поштова служба надасть вам таку послугу, однак ви все одно маєте зазначити отримувача та місце куди посилку треба доправити. Як бачите, нам потрібні відомості про знаходження якогось обʼєкта на місцевості (в просторі), тобто геопросторова інформація. Ця інформація лежить в основі всіх геосервісів.

… потім буде бурякове поле, потім лісосмуга, потім кукурудзяне поле, потім пшоничне поле, конопляне поле, за ним говоряща річка – вона і підкаже…

Геосервіси – це інформаційні та технологічні рішення, які забезпечують збір, обробку, зберігання та надання географічної (геолокаційної) інформації. Вони допомагають розуміти та використовувати просторові дані для різних цілей, таких як навігація, аналіз даних, планування, маркетинг і багато іншого. За допомогою геосервісів, користувачі можуть взаємодіяти з мапами, точними координатами, географічними обʼєктами та іншими геоданими.

І от зараз вже виклик таксі, замовлення доставки піци, розрахунок потенційного охоплення цільової аудиторії вже майже неможливо уявити без використання геопросторових даних та сервісів.

Мені неодноразово доводилось бачити коли люди плутали дані з сервісами. Це саме той випадок, який винесено в заголовок. Я бачив кілька різних аналізів де автори намагались порівнювати Google Maps саме з OpenStreetMap не маючи уявлення про те, що вони порівнювали. Нумо розбиратись.

Поговоримо спочатку про Google Maps

Історія Google Maps розпочалася в середині 2000-х років і є цікавим прикладом успішного поєднання інноваційної технології та практичного застосування.

Google Maps було запущено 8 лютого 2005 року. Мапи були створені як проєкт команди Google, яка прагнула створити картографічний вебсервіс з високою швидкістю завантаження мап та інтерактивними можливостями.

Перша версія Google Maps надавала можливість переглядати мапи, шукати місця, планувати маршрути та орієнтуватися за допомогою GPS. Інтерфейс був інтуїтивно зрозумілим та дружнім для користувачів, наскільки це можливо.

Вже у червні 2005 року Google представляє Google Maps API, який дозволив розробникам інтегрувати картографічні функції до своїх вебсайті та застосунків. Це відкрило широкі можливості для використання картографії в інших проєктах.

У 2007 році Google Maps був поповнений новим функціоналом - Street View, який дозволив користувачам переглядати фотографії вздовж доріг та вулиць, що надавало їм уявлення про реалістичний вигляд місцевості, зʼявилась можливість віртуально побувати в інших місцях, в яких ти ніколи не був, і може ніколи не будеш.

У 2008 році була запущена мобільна версія Google Maps для смартфонів, що дозволило користувачам отримувати доступ до мап та навігації прямо на своїх мобільних пристроях.

У 2010 році Google інтегрувала функціонал Google Maps з іншим продуктом - Google Earth, дозволяючи користувачам переглядати 3D-моделі та зображення з супутників.

Google Maps продовжував розвиватися, додаючи нові функції, такі як покрокова навігація, режим роботи в офлайн, оцінки та відгуки про місця, рекомендації про події та установи та інше.

Сьогодні, з точки зору пересічного користувача, Google Maps стали одним з найпопулярніших інструментів для навігації та дослідження світу. Вони використовуються мільйонами людей щодня для пошуку маршрутів, пошуку місць, перегляду фотографій та вивчення нових віддалених місць. Google Maps також стала важливим ресурсом для підприємств, дослідників та громадських організацій, що використовують їх послуги для розвʼязання різноманітних задач.

OpenStreetMap

Історія OpenStreetMap (OSM) починається у 2004 році і повʼязана з бажанням створити вільну, відкриту та доступну для всіх базу даних геопросторової інформації.

OpenStreetMap була заснована у Великобританії Стівом Костом (Steve Coast) у серпні 2004 року. У нього була ідея створити глобальну картографічну платформу, на якій користувачі можуть спільно створювати та редагувати геодані.

Головною причиною виникнення OpenStreetMap була нестача доступної та актуальної географічної інформації в деяких регіонах світу. Комерційні глобальні сервіси картографії, такі як Google Maps, не завжди надавали покриття достатньої якості або деталізації для певних територій.

OpenStreetMap висувала принцип відкритості даних та доступу до картографічної інформації. Проєкт став платформою для глобальної спільноти волонтерів, які могли долучитися до процесу створення та редагування геоданих будь-яких регіонів планети.

Згодом OpenStreetMap привернув до себе увагу все більшої кількості користувачів та розбудував активну спільноту. Волонтери почали активно вносити дані про дороги, місцевості, відомості про гідрографію, підприємства та інші географічні обʼєкти.

Спрямована на розвиток OpenStreetMap спільнота стала однією з найбільших та найактивніших вільних картографічних спільнот у світі. Завдяки вільному та безкоштовному доступу до даних, відкритості та колективним зусиллям, OSM стала джерелом цінної та актуальної геопросторової інформації, що використовується у різних галузях, включаючи туризм, дослідження, гуманітарну допомогу та планування міст.

Цілі та філософія

Google Maps – це комерційний продукт, створений компанією Google. Основна мета Google Maps – надавати користувачам зручні та швидкі інтерактивні мапи для навігації, пошуку місць та орієнтування. Google заробляє на цьому, відображаючи рекламу та надаючи платні послуги.

З іншого боку, OpenStreetMap – це проєкт, заснований на волонтерських засадах та філософії відкритості даних. Головна мета OSM – створити вільну та загальнодоступну базу геопросторових даних для всього світу. Кожен може внести свій внесок, додавши нові дані або виправивши помилки. Такий підхід дає можливість створити докладні та актуальні мапи там, де інші джерела можуть бути обмежені або застарілі.

Джерела даних

Google Maps використовує комерційні та пропрієтарні джерела даних, ліцензовані дані від сторонніх компаній, та алгоритми машинного навчання для обробки великих обсягів даних, які акумулюються компанією разом зі збором даних на місцевості за допомогою спеціалізованого обладнання та відстеження пристроїв клієнтів. Це дає їм перевагу у швидкості та охопленні, але приховує деталі та джерела інформації. (Так всі ми пересуваючись місцевістю не відаючи про це допомагаємо Google продавати нам послуги використовуючи дані отримані з наших смартфонів у вигляді автоматизованих звітів від застосунків чи ОС.)

OpenStreetMap використовує відкриті джерела даних, такі як супутникові знімки надані постачальниками для цілей проєкту, відкриті геопросторові дані, що поширюються урядами країн на вільних засадах, дані з інших вільних відкритих джерел, а також власні внески учасників проєкту. Це дозволяє створювати більш прозорі та перевірені дані, які можуть бути корисними для громадськості, дослідників та навіть гуманітарних організацій.

Актуальність даних

Google Maps має доступ до ресурсів, які дозволяють оновлювати їхню базу даних з певною періодичністю, особливо там де на них є підвищений попит і на послугах можна більше заробити. Це допомагає надавати користувачам актуальну інформацію, наприклад про дорожні затори, розваги та нові заклади. (Памʼятаєте про ваші смартфони за допомогою яких Google збирає про все це дані?)

OpenStreetMap, залежно від регіону, може мати різний рівень актуальності даних. Тут все залежить від кількості та активності волонтерів, які вносять зміни до бази даних. Однак там, де є активна спільнота учасників проєкту, дані можуть бути досить актуальними та детальними.

Ви можете зауважити що на головній і Google Maps, і OpenStreetMap знаходяться схожі елементи:

Мапа
Поле для пошуку
Можливість побудувати маршрут
Перегляд відомостей про обʼєкт на мапі…

Так в чому ж тоді різниця?

Головна різниця – це те, що Google Maps є комерційним продуктом метою якого є надання послуг клієнтам. OpenStreetMap, в першу чергу, націлений на збір та розповсюдження даних.

– А як же API? – можете сказати ви.
– Це не одне API, а збірка з різноманітних API, кожне з яких відповідає за надання тієї чи іншої послуги.

API для показу мап; API для пошуку (геокодуванню); API для прокладання маршрутів; API для ведення по маршруту та надавання покрокових інструкцій та інше – всі ці компоненти і створюють кінцевий продукт.

Перевага Google в централізації, всі API розробляються та підтримуються в середині компанії. Користуючись ними ви очікуєте отримати певний обсяг послуг з певним рівнем доступності та якості (SLA), за що ви готові заплатити певну суму, без потреби розгортання всієї інфраструктури у себе чи у клієнта. Розрахунок того в скільки вам вийде користування послугами зовсім нетривіальний, бо іноді досить важко вловити як одні послуги залежать від інших та спрогнозувати очікуваний рівень витрат.

Натомість API OpenStreetMap призначений для отримання, редагування та збереження даних в спільній базі геопросторових даних учасниками проєкту. Тобто єдине що гарантує вам OpenStreetMap – це те, що ви можете скористатись даними і вже використовуючи ці дані ви можете створити власну мапу, геокодер, пропонувати своїм клієнтам послуги навігації чи ще щось. Мапа, пошук, прокладання маршрутів на головній OpenStreetMap – це демонстрація того, що можна зробити з даними проєкту, всі ці елементи самі по собі є окремими незалежними проєктами і єдине, що їх повʼязує з OpenStreetMap – дані які OpenStreetMap надає всім охочім.

Мапа – тайловий сервер (Mapnik) та стиль подання даних (OSM-Carto) – 2 окремих проєкти, які жодним чином не залежать від OSMF (OpenStreetMap Foundation)
Бібліотека показу тайлів – leaflet.js, бібліотека JavaScript з відкритими сирцями для показу інтерактивних мап
Пошук – геокодер Nominatim, теж самостійний проєкт
Прокладання маршрутів – OSRM, Valhalla, GraphHopper, теж сторонні проєкти
Експорт/видобування даних - Overpass API (Overpass-Turbo), так само…
iD – редактор даних OSM (вбудований у Головну), зараз під управлінням OSMF.

Всі ці проєкти є вільними проєктами з відкритими сирцями і за потреби, можливості, за наявності відповідної кваліфікації ви можете зібрати з цього конструктора потрібне вам рішення. Тим більше, що у вас є вибір серед різних проєктів візуалізації даних, створення мапи; різних рушіїв геокодування, пошуку; рушіїв прокладання маршрутів та навігації. Крім того, ви можете використовувати дані OpenStreetMap для проведення аналізу у власних проєктах, поєднуючи їх з іншими вашим даним, це те що ви не можете робити з Google Maps.

Використання OpenStreetMap

OpenStreetMap використовується різними компаніями та організаціями, включаючи Meta, Apple, Amazon, TomTom та іншими.

Meta використовує дані OpenStreetMap для своїх функцій картографії та локаційної інтеграції. Для забезпечення своїх користувачів актуальною інформацією про місця та локації; Meta може використовувати дані OSM для показу місцезнаходження користувачів, мап та інтеграції з іншими функціями на своїх платформах.

Apple також використовує дані OpenStreetMap у деяких зі своїх послуг. Наприклад, в деяких країнах або регіонах, де дані від стороніх постачальників для Apple Maps можуть бути менш повними або неактуальними, або навпаки там де дані OpenStreetMap якісніші, вони можуть використовувати їх для підтримки навігації та картографії.

Amazon також використовує дані OpenStreetMap у своїх послугах, таких як AWS (Amazon Web Services). OSM може бути використаний у різних рішеннях для обробки географічних даних, аналізу та візуалізації на платформі AWS.

Поміж іншими виробниками навігаційного обладнання, TomTom також співпрацює з OpenStreetMap. Вони можуть використовувати дані OSM для забезпечення навігації та картографічних послуг у своїх пристроях та додатках.

Airbnb, популярна платформа для бронювання помешкань, також використовує дані OSM для відображення локацій та місць проживання на своїх мапах. Вони можуть використовувати OSM для надання точної інформації про розташування помешкань та їхнє оточення.

ESRI ArcGIS Online, дозволяє користувачам інтегрувати дані OpenStreetMap до своїх географічних інформаційних систем. Користувачі можуть імпортувати дані OSM до своїх проєктів, використовувати їх для аналізу, створення мап та візуалізації.

Ці приклади показують широкий спектр використання OpenStreetMap відомими компаніями та службами. Відкритість та доступність даних OSM дозволяють різним платформам та організаціям використовувати географічну інформацію для забезпечення якісних послуг та розвитку своїх продуктів.

Слід зазначити, що вибір того що використовувати, сервіси Google, чи дані та екосистему OpenStreetMap, залежить від конкретних вимог, повноти та актуальності покриття даним в тій чи іншій території, потребі у швидкому внесені зміни в дані, можливості впровадження процесів контролю якості даних та наявності у вас досвіду роботи з продуктами Google чи екосистемою та даними OpenStreetMap. Вибір за вами.

API OSM 2.0 з використанням git

2023-05-07T08:29:00+00:00

API OSM 2.0 (OpenStreetMap) – це інтерфейс, який надає доступ до геопросторових даних та історії їх змін, збережених за допомогою git. Основна структура даних в OSM має базуватись на розділенні Земної кулі на тайли, кожен з яких є окремим репозиторієм git.

Формат збереження даних обʼєктів OSM – це yaml (YAML Ain’t Markup Language). Yaml – зручний для читання та збереження формат даних, що базується на використанні відступів для представлення структури даних. Використання yaml в OSM дозволить зберігати різні багаторівневі атрибути у вигляді теґів для географічних обʼєктів.

Кожен обʼєкт зберігатиметься у вигляді окремого YAML-файлу, що відрізняється від попередніх версій API OSM, де дані зберігалися та передавалися у вигляді XML-файлів.

Кожен тайл в OSM є самостійним репозиторієм git. Git – це система керування версіями, яка дозволяє відстежувати історію змін у файловій системі та зберігати різні версії файлів. Використання git для OSM дозволяє відстежувати всі зміни, внесені до геопросторових даних, та зберігати їх історію.

Опис

API OSM має надавати різні методи для доступу до даних та їхньої модифікації. Деякі з них повинні включати:

Отримання даних по координатах або області.
Пошук обʼєктів за типом, атрибутами або теґами.
Отримання історії змін для конкретного обʼєкта.
Додавання нових обʼєктів або змін до наявних.
Видалення обʼєктів.

API OSM має надавати можливість виконувати запити на основі різних протоколів для зручного отримання та взаємодії з геопросторовими даними.

Загалом, API OSM, що використовує git для збереження геопросторових даних та їхньої історії змін, надає потужний механізм для спільної роботи та управління геопросторовими даними. Основні особливості API OSM з використанням git включають:

Контроль версій: Завдяки використанню git, API OSM дозволяє зберігати історію змін для кожного обʼєкта. Це означає, що ви можете відстежувати, хто, коли і які зміни вніс у конкретний обʼєкт, а також відновлювати попередні версії даних.

Розподілена структура даних: Земна куля розбивається на тайли, які є самостійними репозиторіями git. Це дозволяє ефективно керувати та розподіляти навантаження на різних серверах. Кожен тайл містить лише обʼєкти, що знаходяться у його межах, що полегшує доступ до конкретних даних.

Гнучкість формату даних: Використання формату yaml для зберігання даних обʼєктів дозволяє зберігати різноманітні атрибути та теґи, які допомагають описати географічні обʼєкти докладно. Це дає можливість додавати власні теґи та атрибути для більш гнучкого представлення даних.

Масштабованість: Розподілена структура даних та використання git дозволяють легко масштабувати систему для обробки великих обсягів геопросторових даних. Ви можете додавати нові тайли або сервери для розширення інфраструктури та підвищення продуктивності, розбивати великі тайли на менші з часом.

Зручний доступ до даних: API OSM надає різноманітні методи для доступу до даних OSM. Ви можете отримувати дані за координатами або областями, шукати обʼєкти за типом, атрибутами або теґами OSM, а також отримувати історію змін для конкретного обʼєкта. Це надає гнучкість та можливість вибирати лише необхідні дані.

Можливість спільної роботи: Використання git дозволяє кільком користувачам працювати з даними одночасно та вносити зміни. Завдяки контролю версій і можливості обʼєднання різних гілок, ви можете легко спільно працювати над проєктами, вносити та обʼєднувати зміни.

Інтеграція з іншими інструментами: Оскільки OSM використовує git, ви можете використовувати широкий спектр інструментів, які підтримують git, для роботи з геопросторовими даними. Це можуть бути різні системи контролю версій, редактори коду, інструменти аналізу даних та інші.

Крім цих можливостей API OSM з використанням git, дозволяє робити:

Розширення даних: Ви можете додавати власні дані до даних OSM, розширюючи поточну базу геопросторових даних. Це дозволяє створювати власні набори даних, додавати атрибути та розширювати функціональні можливості OSM.

Інтеграція з іншими сервісами: API OSM може бути легко інтегрований з іншими сервісами та інструментами, такими як геопросторові сервіси або системи аналізу даних. Це дозволяє поєднувати різні джерела даних та використовувати їх для створення потрібних рішень.

Розширені можливості редагування: API OSM дозволяє вносити зміни у геопросторові дані, включаючи додавання нових обʼєктів, редагування атрибутів та видалення обʼєктів. Це дає можливість активно співпрацювати з глобальною базою даних OSM і доповнювати її знаннями про конкретні обʼєкти або регіони.

Це лише кілька додаткових можливостей API OSM з використанням git. Загалом, API OSM має бути потужним інструментом для роботи з геопросторовими даними, забезпечуючи контроль версій, гнучкість формату даних та їх масштабування.

YAML – для збереження даних

Версія API OSM 2.0 передбачає використання формату yaml. Кожен обʼєкт зберігається у вигляді окремого YAML-файлу і це відрізняється від попередніх версій API OSM, де дані зберігалися у вигляді XML-файлів. Використання YAML-формату для зберігання окремих файлів обʼєктів має деякі переваги:

Простота читання та редагування: YAML-формат має зрозумілий синтаксис, який легко читається, що спрощує редагування даних вручну або їх перегляд. Використання відступів замість синтаксичних елементів XML спрощує роботу з даними та їх редагування

Гнучкість у виразності даних: YAML дозволяє зберігати додаткові властивості та інформацію про обʼєкти, яка необхідна для конкретного застосування. Він може включати прості значення, списки, асоціативні масиви та вкладені структури даних.

Пошук та фільтрація даних: Будучи окремими файлами, обʼєкти можуть бути легко знайдені та відфільтровані за різними параметрами. Ви можете використовувати бібліотеки або інструменти для роботи з YAML для здійснення пошуку та обробки даних за потребою.

Підтримка історії змін: Кожен обʼєкт представляться у вигляді власного файлу, що дозволяє зберігати історію змін та відстежувати розвиток даних. Git, як система контролю версій, може використовуватися для керування змінами та гілками, що сприяє ефективному співробітництву та управлінню версіями даних.

Розширення та валідація даних: Ви можете використовувати YAML-схеми для валідації та контролю правильності даних. Це дозволяє забезпечити те, що дані відповідають заданим правилам і структурі. Також, ви можете розширювати YAML-схеми для визначення додаткових властивостей та обмежень для обʼєктів, що зберігаються.

Інтеграція з іншими інструментами: YAML є популярним форматом обміну даними, що підтримується багатьма інструментами та платформами. Ви можете використовувати різні інструменти для імпорту та експорту даних, а також для обробки та аналізу геопросторових даних у форматі YAML.

Git-репозиторій як сховище даних

Форма (геометрія) тайлів кожного репозиторію може бути довільною.

В API OSM з використанням git, форма (геометрія) тайлів кожного репозиторію може бути довільною. Тайли можуть мати різні форми та розміри, залежно від потреб ваших геопросторових даних.

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

Крім того, існує майстер-репозиторій, який включає репозиторії-тайли у вигляді субмодулів git. Майстер-репозиторій слугує як вихідний пункт для управління та координації репозиторіями-тайлів. Він може містити додаткову інформацію про тайли, таку як індекси або посилання на кожен тайл.

Така архітектура дозволяє організувати та управляти геопросторовими даними, зберігаючи опис меж тайлів в самому репозиторії тайла та використовуючи майстер-репозиторій для координації та доступу до цих репозиторіїв-тайлів.

Цей підхід забезпечує гнучкість та масштабованість при роботі з геопросторовими даними, дозволяючи легко управляти окремими тайлами, а також забезпечує збереження історії змін та контроль версій за допомогою git.

Сегментація даних на репозиторії-тайли дозволяє запровадити:

Підтримку розподіленого співробітництва: Завдяки використанню git, API OSM забезпечує можливість розподіленого співробітництва. Різні користувачі можуть працювати з різними тайлами, внести зміни та взаємодіяти з базою даних OSM, використовуючи ті ж самі принципи що й для роботи з сирцевим кодом, а пізніше обʼєднати свої зміни за допомогою git.

Синхронізація та злиття змін: Завдяки використанню git, API OSM дозволяє легко синхронізувати та зливати зміни, які були внесені різними користувачами у власні копії репозиторіїв. Це дозволяє уникнути конфліктів та забезпечити цілісність даних під час обʼєднання змін. До того ж користувачі, можуть робити власні форки, для додавання своїх (переважно непублічних) даних поверх даних OSM. З часом, коли буде прийняте рішення передати власні закриті дані до суспільного надбання, це можна бути зробити за допомогою звичайної команди git push. Зміни можуть передаватись як вгору, від локальних копій до спільних репозиторіїв, так і вниз – від загальних до локальних репозиторіїв, що дозволяє підтримувати власні репозиторії користувачів в актуальному стані, отримуючи оновлення від спільноти, докладаючи менше зусиль для синхронізації даних.

Історія змін: Завдяки використанню git, API OSM зберігає історію змін обʼєктів в кожному тайлі, що дозволяє прослідковувати розвиток та зміни геопросторових даних. Це корисна функція для аналізу даних, відстеження внесених змін та відновлення попередніх версій.

Підтримка версій: Git дозволяє зберігати кожну версію обʼєкта (файлу) в окремому коміті, що дає можливість легко переглядати, відновлювати та відстежувати зміни в даних з часом. Ви можете проглядати історію змін та повертатися до попередніх версій в разі потреби.

Легка реплікація та розподіл: Оскільки кожен обʼєкт зберігається у власному файлі, їх можна легко реплікувати та розподіляти на різних серверах або тайлах. Це дозволяє покращити масштабованість та доступ до даних. Git надає можливість синхронізувати та реплікувати дані між різними серверами або тайлами. Ви можете використовувати функції git, такі як створення гілок та їх злиття, для керування змінами та оновленнями даних.

Керування конфліктами: У випадку одночасних змін в одному обʼєкті, git надає засоби для вирішення конфліктів змін та обʼєднання різних версій. Це дозволяє кільком користувачам працювати з одними й тими ж даними та ефективно обробляти конфлікти.

Відновлення даних: Завдяки контролю версій git, API OSM дозволяє відновлювати дані до попередніх версій або відновлювати видалені обʼєкти. Це забезпечує збереження та безпеку даних.

Набір змін OSM — коміт git

Так, в контексті збереження даних OSM в git, набір змін представляється як коміт (commit) в git. Коміт є фіксованою структурою даних, яка охоплює зміни, зроблені в конкретний момент часу.

Кожен коміт в git містить інформацію про зміни, що були внесені до репозиторію. У випадку з OSM, коміт може містити зміни, повʼязані з додаванням, видаленням або зміною геопросторових обʼєктів.

Коміти в git забезпечують історію змін і дозволяють відстежувати розвиток даних в часі. Кожен коміт має унікальний ідентифікатор (хеш), який служить для їх ідентифікації та відновлення певної версії даних.

Один коміт може містити зміни для одного або кількох геопросторових обʼєктів. Це дозволяє фіксувати зміни в окремих обʼєктах та управляти історією змін незалежно від інших обʼєктів.

Коміти можуть бути згруповані в гілки (branches) та злиті (merged) між собою, що дозволяє керувати паралельними гілками та обʼєднувати їх зміни в одну загальну версію даних.

Отже, коміти в git використовуються для збереження та керування змінами в геопросторових даних OSM у версії збереження даних за допомогою git.

Переваги використання git

Команди git: Ви можете використовувати стандартні команди git для керування репозиторіями-тайлами, такі як git clone, git pull, git push та інші. Це дозволяє вам працювати з геопросторовими даними API OSM, використовуючи знайомий та потужний інтерфейс git.

Розширені функції git: API OSM може використовувати додаткові функції та можливості git, такі як гілки (branches), теги (tags) та коміти (commits). Це дозволяє вам організовувати та керувати різними версіями, створювати позначення для важливих моментів та працювати з різними гілками.

Керування доступом: API OSM може надавати можливість обмеження доступу до окремих тайлів або даних, використовуючи функції контролю доступу git. Це дозволяє контролювати, хто має право на читання, запис або інші дії з геопросторовими даними.

Резервне копіювання та відновлення: Завдяки git, API OSM дозволяє створювати резервні копії даних та відновлювати їх в разі потреби. Це забезпечує додатковий рівень захисту та безпеки для ваших геопросторових даних без потреби розробки власних рішень для цього.

Розповсюдження змін: Ви можете легко поширювати зміни, внесені в репозиторії-тайл, на інші екземпляри або інсталяції API OSM використовуючи звичні методи роботи з git. Не потрібно витрачати ресурси сервера на створення дампів даних та даних для реплікації. Завдяки використанню git це відбувається шляхом отримання оновлених даних за потреби командою git pull. Це дозволяє співпрацювати з різними спільнотами або розподіленими системами, обмінюватись та синхронізувати геопросторові дані.

Інтеграція з іншими інструментами: API OSM з використанням git може бути легко інтегрований з іншими інструментами розробки, такими як системи управління проєктами, інструменти автоматизації, сервіси хмарних сховищ та інші. Це робить його важливим компонентом при розробці геопросторових застосунків та роботі з даними.

Синхронізація з іншими джерелами даних: За допомогою API OSM та git ви можете синхронізувати геопросторові дані з іншими джерелами даних. Це може бути корисно, якщо ви маєте додаткові джерела даних або хочете поєднати дані з різних джерел для створення повнішої та комплекснішої бази даних.

Розширення та налаштування: API OSM з git дозволяє розширювати та налаштовувати його функціональність згідно з власними потребами. Ви можете додавати додаткові модулі, функції та розширення для роботи з геоданими та взаємодії з API.

Використання API OSM з git надає потужні можливості управління геопросторовими даними, збереження їх історії змін та співпраці зі спільнотою.

Підсумок можливостей API OSM з використанням git

API OSM, що використовує git для збереження геопросторових даних та історії змін, має наступні характеристики:

Кожен тайл є самостійним репозиторієм git, що містить окремий набір геопросторових даних.
Тайли можуть мати різну форму (геометрію) і опис їх меж зберігається в самому репозиторії тайла та майстер-репозиторії.
Дані про окремі обʼєкти зберігаються у форматі YAML, що дозволяє зберігати додаткові властивості та інформацію про них, наслідуючи всю гнучкість системи теґування OSM.
API підтримує розподілене співробітництво, дозволяючи різним користувачам працювати з різними тайлами та зливати зміни з використанням git.
Зміни зберігаються в історії змін git-репозиторіїв, що дозволяє прослідковувати розвиток геопросторових даних.
За допомогою стандартних команд git, таких як clone, pull та push, можна керувати репозиторіями тайлів.
API надає розширені функції git, такі як гілки, git-теґи та коміти, що дозволяють керувати версіями та розвитком.
Існує можливість обмеження доступу до тайлів та даних за допомогою контролю доступу git.
API дозволяє відновлювати дані до попередніх версій та виконувати резервне копіювання та відновлення даних.
Зміни можна поширювати на інші екземпляри API OSM та співпрацювати зі спільнотою OpenStreetMap та іншими розробниками.

Розподіл великих обʼєктів між тайлами

Розподіл великих обʼєктів між тайлами є важливим аспектом при організації геопросторових даних в API OSM з використанням git. Це дозволяє ефективно управляти великими обсягами даних і забезпечувати оптимальну продуктивність та швидкість доступу до цих даних.

Існує кілька підходів до розподілу великих обʼєктів між тайлами в API OSM. Ось деякі з них:

Географічний розподіл: Обʼєкти можна розподілити між тайлами, використовуючи їх географічне розташування. Наприклад, великі регіональні обʼєкти можуть бути розподілені на окремі тайли, що охоплюють відповідну територію. Це дозволяє зберігати дані ближче до їх фізичного розташування та зменшує навантаження на окремі тайли.

Розподіл за категоріями: Обʼєкти можуть бути розподілені між тайлами в залежності від їх категорій або типів. Наприклад, дорожні або гідрографічні обʼєкти можуть бути збережені в окремих тайлах, що спрощує доступ до конкретних категорій даних.

Залежність від розміру: Обʼєкти можуть бути розподілені на тайли в залежності від їх розміру або складності. Наприклад, великі або складні обʼєкти можуть бути збережені в окремих тайлах для забезпечення оптимального управління та швидкого доступу до них. Це можуть бути контури океанів та континентів, кордони країн та таке інше.

Динамічний розподіл: API OSM може автоматично розподіляти великі обʼєкти між тайлами залежно від завантаження та потреби.

Альтернативним підходом може бути розподіл великих обʼєктів на основі віртуальних границь тайлів. Замість того, щоб розподіляти обʼєкти фізично між окремими репозиторіями тайлів, ви можете використовувати віртуальні границі, які обʼєднують обʼєкти, які логічно повʼязані між собою.

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

Відповідно, ви можете мати кожен тайл як окремий репозиторій git, але вони можуть посилатися один на одного, щоб утворити віртуальну групу обʼєктів. Це забезпечує зручний доступ та керування великими обʼєктами, розташованими у різних тайлах, зберігаючи при цьому гнучкість та швидкодію git.

Вибір підходу до розподілу великих обʼєктів між тайлами залежить від конкретних потреб та вимог до продуктивності, доступності та керованості даних.

Примітки

Важливо зазначити, що цей опис є загальним і певні деталі та реалізація можуть залежати від конкретної реалізації API OSM 2.0 та ваших потреб.

При роботі з API OSM з використанням git, переконайтесь, що ви дотримуєтеся правил та політик OSM щодо внесення змін до глобальної бази даних. Збереження історії змін та правильне використання git допоможуть управляти цими змінами та забезпечити безпеку даних.

Якщо ви маєте конкретні запитання щодо використання API OSM з git або потребуєте більш детальної інформації, будь ласка, уточніть, і я спробую надати вам більше деталей.

Андрій Головін – Блог |

Розгортання HA Kubernetes кластера з зовнішньою топологією etcd на локальній машині

Архітектура кластера

Компоненти

Топологія кластера

Попередні вимоги

Налаштування SSH ключів

Генерування SSH ключа

Оновлення конфігурацій cloud-init

Доступ до віртуальних машин через SSH

Підготовка середовища

Створення скриптів та конфігурацій

Параметри віртуальних машин

Cloud-init конфігурації

Створення користувача

Базова конфігурація для вузлів кластера

Конфігурація для etcd вузлів

Конфігурація вузла балансувальника HAProxy

Вибір топології мережі

Створення etcd кластера

Розгортання першого вузла кластера etcd

Налаштування першого вузла etcd

Розгортання наступних вузлів кластера etcd

Налаштування вузлів etcd та їх приєднання до кластера

Створення kubeadmcfg.yaml

Скасування приєднання вузла до кластера

Видалення data-dir

Налаштування балансувальника навантаження для вузлів панелі управління (HAProxy+Keepalived)

Тимчасовий “хак” (якщо не має можливості підняти HAProxy зараз)

Створення налаштувань HAProxy+Keepalived

Налаштування Netplan

Конфігурація Keepalived

Налаштування ядра (Sysctl)

Як це працює разом

Розгортання HAProxy+Keepalived

Що робити після запуску?

Розгортання Control Plane

Налаштування локального балансувальника навантаження для доступу до вузлів etcd

Підготовка конфігурації HAProxy

Створення Static Pod для HAProxy

Створення першого вузла панелі управління

Перевірка використання Static Pods HAProxy

Налаштування kubeadm

Запуск ініціалізації та оминання перевірки ExternalEtcdVersion

Встановлення Calico

Що роботи спочатку: розгортати Calico чи виконувати kubeadm join?

Варіант 1: Спершу CNI, потім Join (Рекомендовано)

Варіант 2: Спершу Join, потім CNI

Розгортання та приєднання наступних вузлів панелі управління

Відʼєднання та заміна вузла панелі управління

Розгортання Worker Nodes

Встановлення MetalLB

Тестування кластера

Підсумки

Додатки

Мережева архітектура для HA Kubernetes з external etcd

Рекомендована топологія мережі — Підмережа: 10.10.0.0/22 (1024 адреси)

1. Інфраструктура (10.10.0.0/26)

2. etcd Кластер (10.10.0.64/26)

3. Control Plane (10.10.0.128/25)

4. Worker Nodes (10.10.1.0/24)

Внутрішні мережі Kubernetes (не конфліктують з VM)

Альтернативні варіанти підмереж

Варіант 1: Компактна топологія (10.10.10.0/24)

Варіант 2: Розширена топологія (10.10.0.0/16)

Варіант 3: Класична приватна мережа (172.16.0.0/16)

DNS записи (рекомендовано)

Виправлення проблем

Виправлення --pod-network-cidr

1. Оновлення конфігурації ClusterConfiguration

2. Оновлення маніфестів Control Plane (на всіх 3-х вузлах)

3. Оновлення налаштувань kube-proxy

4. Перевстановлення Flannel з правильним CIDR

5. Оновлення Spec вузлів (PodCIDR)

6. Фінальне перезавантаження

Скидання etcd до первісного стану

1. Зупиніть сервіси, що залежать від etcd

2. Очистіть дані на всіх вузлах

3. Ініціалізація нового “порожнього” кластера

4. Очищення через etcdctl (якщо кластер працює)

Виправлення `--pod-network-cidr`