From ea88f3065a6b44d9b29bceaff9e890802e0b1d42 Mon Sep 17 00:00:00 2001 From: erjemin Date: Fri, 28 Feb 2025 17:13:00 +0300 Subject: [PATCH] =?UTF-8?q?add:=20k3s=20(=D1=80=D0=B5=D0=BF=D0=BB=D0=B8?= =?UTF-8?q?=D0=BA=D0=B0=20coredn=202)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- raspberry-and-orange-pi/k3s.md | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/raspberry-and-orange-pi/k3s.md b/raspberry-and-orange-pi/k3s.md index 6c13384..0729178 100644 --- a/raspberry-and-orange-pi/k3s.md +++ b/raspberry-and-orange-pi/k3s.md @@ -375,6 +375,8 @@ sudo k3s kubectl delete pod svclb-traefik-xxxxxxxxx-xxxxx -n kube-system --force при добавлении можно в флаге `--server` указать IP как первого, так и второго мастера. И не забудьте в `--tls-san` указать IP хоста нового (третьего) мастера. +### Тюнинг kube-dns + После установки можно попробовать отключить один из мастеров и убедиться, что кластер остаётся работоспособным, а спустя некоторое время (иногда 10-15 минут) поды с погашенного мастера перезапустятся на других нодах. Например: ```text @@ -396,7 +398,7 @@ traefik-6c979cd89d-z6wwm 1/1 Running 0 2 приложения(ий) развернутых внутри k3s предполагает переподключение с использованием имен подов или обнаружение подов, то это тоже перестанет работать. -Решением может быть использование двух реплик `coredns` (вместо одной). Откроем файл конфигурации k3s: +Решением может быть использование двух реплик `coredns` (вместо одной). Откроем файл конфигурации k3s на редактирование: ```bash sudo k3s kubectl edit deployment coredns -n kube-system ``` @@ -417,6 +419,7 @@ spec: replicas: 2 revisionHistoryLimit: 0 ``` + Сохраним изменения и выйдем из редактора. Изменения сразу применятся, и k3s создаст вторую реплику `coredns`: ```text NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES @@ -433,3 +436,28 @@ coredns-ccb96694c-wzh96 1/1 Running 0 3h10 ... ``` +**Как это будет работать?** Обе реплики `coredns` привязаны к сервису `kube-dns` в пространстве имён `kube-system`. +Он имеет фиксированный *Cluster IP* (внутренний IP-адрес кластера) и балансирует запросы между всеми зарегистрированными +подами `coredns` (у нас теперь две реплики). Каждый под `coredns` регистрируется как endpoint в `kube-dns` при старте. + +Посмотеть endpoint'ы сервиса `kube-dns` можно командой: +```bash +sudo k3s kubectl get endpoints kube-dns -n kube-system +``` + +И увидим, что у `kube-dns` несколько endpoint'ов (IP-адресов подов `coredns`) включая оба новых и старые, которые +гасили при экспериментах с устойчивостью кластера: +```text +NAME ENDPOINTS AGE +kube-dns 10.42.1.8:53,10.42.2.6:53,10.42.1.8:53 + 3 more... 5d23h +``` + +Каждый под `coredns` -- самостоятельный DNS-сервер. Они не взаимодействуют друг с другом и не обмениваются данными. Это +просто экземпляры одного и того же сервиса, работающие параллельно. Они независимы, получают данные из API Kubernetes +и отвечают на запросы параллельно. В каждом поде кластера в качестве DNS настроен `kube-dns` (задаётся в файле +`/etc/resolv.conf` внутри пода). Когда под отправляет DNS-запрос, его получит `kube-dns` и перенаправит запрос +к одному из доступных `coredns`. Балансировка происходит по случайного выбора (Round-Robin). Если один из `coredns` +недоступен (например, узел выключен), `kube-dns` не получит ответа, и направит запросы к живому `coredns`. + +### Разные архитектуры на узлах кластера (гетерогенность) +