Нашият опит с данни в etcd Kubernetes клъстера директно (без K8s API)

Все по-често клиентите се обръщат към нас с искане да осигурим достъп до Kubernetes клъстера, за да могат да се свързват със сервисите вътре в клъстера: за да се свържат директно с определена база данни или сервис, за свързване на локалното приложение с приложенията вътре в клъстера…

Например, възниква необходимост да се свържеш от локалната си машина със сервиса memcached.staging.svc.cluster.local. Ние предоставяме такава възможност чрез VPN в клъстера, към който се свързва клиентът. За целта анонсираме подсетите на pod'овете, сервисите и предаваме кластерните DNS на клиента. Така, когато клиентът опитва да се свърже със сервиса memcached.staging.svc.cluster.local, заявката отива в DNS на клъстера и в отговор получава адреса на съответния сервис от сервисната мрежа на клъстера или адреса на pod'а.

K8s клъстери конфигурираме с помощта на kubeadm, където по подразбиране сервисната подсет е 192.168.0.0/16, а мрежата на pod'овете е 10.244.0.0/16. Обикновено всичко работи добре, но има няколко момента:

• Подсетите 192.168.*.* често се използват в офисните мрежи на клиентите, а още по-често — в домашните мрежи на разработчиците. И тогава получаваме конфликти: домашните рутери работят в тази подсет и VPN предава тези подсети от клъстера на клиента.
• Имаме няколко клъстера (продуктови, етапни и/или няколко dev клъстера). Тогава във всички тях по подразбиране ще има идентични подсети за pod'ове и сървиси, което създава големи трудности при работа със сървиси в няколко клъстера едновременно.

Вече от доста време практикуваме използването на различни подсети за сервисите и pod'овете в рамките на един проект — общо взето, за да са всички клъстери с различни мрежи. Въпреки това, има голям брой работещи клъстери, които не искаме да преинсталираме от нулата, тъй като в тях функционират много сървиси, stateful приложения и т.н.

И тогава си зададохме въпроса: как да променим подсета в съществуващия клъстер?

Търсене на решения

Най-разпространената практика е да се пресъздадат всичко сървиси с тип ClusterIP. Като вариант, може да препоръчат и такова:

Следният процес има проблем: след като всичко е конфигурирано, pod'овете идват с стария IP като DNS nameserver в /etc/resolv.conf.
Тъй като все още не намерих решение, трябваше да нулирам целия клъстер с kubeadm reset и да го инициализирам отново.

Но не на всички това им подхожда… Ето и по-подробна информация за нашия случай:

• Използва се Flannel;
• Има клъстери както в облака, така и на физически сървъри;
• Искаше ми се да избегна повторния деплой на всички услуги в кластера;
• Има нужда да направим всичко с минимално количество проблеми;
• Версията на Kubernetes е 1.16.6 (впрочем, следващите действия ще бъдат аналогични и за други версии);
• Основната задача е да заменим сервисната подсеть в кластера, разположен с помощта на kubeadm 192.168.0.0/16, с 172.24.0.0/16.

И така се случи, че отдавна ни беше интересно да видим как се съхраняват данни в Kubernetes в etcd и какво можем да направим с това… Помислихме си: «Защо просто да не обновим данните в etcd, заменяйки старите IP адреси (подсеть) с нови??»

След като търсихме готови инструменти за работа с данни в etcd, не намерихме нищо, което напълно да решава поставената задача. (Между другото, ако знаете за някакви утилити за работа с данни директно в etcd – ще сме благодарни за линкове.) Но добра отправна точка беше etcdhelper от OpenShift (благодарим на неговите автори!).

Тази утилита може да се свързва с etcd чрез сертификати и да чете данни оттам с помощта на командите ls, get, dump.

Добавяме etcdhelper

Следващата мисъл е логична: «Какво пречи да допишем тази утилита, добавяйки възможност за запис на данни в etcd?»

Това се реализира в модифицирана версия на etcdhelper с две нови функции changeServiceCIDR и changePodCIDR. Кодът на нея може да се види Какво правят новите функции? Алгоритъмът тук.

създава десериализатор; changeServiceCIDR:

• компилира регулярна израз за замяна на CIDR;
• обхожда всички услуги с тип ClusterIP в кластера:
• декодира стойността от etcd в Go-обект;
  • с помощта на регулярния израз заменя първите два байта на адреса;
  • присвоява на услугата IP адрес от новата подсеть;
  • създава сериализатор, преобразува Go-обекта в protobuf, записва новите данни в etcd.
  • по същество е аналогично

Функция changePodCIDR — само вместо редактиране на спецификациите на услугите, правим това за възела и променяме changeServiceCIDR .spec.PodCIDR на новата подсеть. Смяна на serviceCIDR

Практика

Планът за реализиране на поставената задача е много прост, но предполага даунтайм по време на преосъществяването на всички podове в кластера. След описание на основните стъпки, ще споделим и мисли как теоретично може да се минимизира този просто.

Подготвителни действия:

инсталиране на необходимия софтуер и компилиране на пропатчения etcdhelper;

• бекъп на etcd и
• Кратък план за действия по смяна на serviceCIDR: /etc/kubernetes.

изменение на манифестите на apiserver-a и controller-manager-a;

• изменение манифестов apiserver’а и controller-manager’а;
• планиране на нови сертификати;
• промяна на ClusterIP услуги в etcd;
• рестартиране на всички pod-ове в клъстера.

По-долу е представена пълната последователност от действия в детайли.

1. Инсталираме etcd-client за архивиране на данни:

apt install etcd-client

2. Създаваме etcdhelper:

• Инсталираме golang:

  GOPATH=\/root\/golang
  mkdir -p $GOPATH\/local
  curl -sSL https:\/\/dl.google.com\/go\/go1.14.1.linux-amd64.tar.gz | tar -xzvC $GOPATH\/local
  echo "export GOPATH="$GOPATH"" >> ~\/\.bashrc
  echo 'export GOROOT="$GOPATH\/local\/go"' >> ~\/\.bashrc
  echo 'export PATH="$PATH:$GOPATH\/local\/go\/bin"' >> ~\/\.bashrc

• Запазваме си etcdhelper.go, изтегляме зависимости, компилираме:

  wget https:\/\/raw.githubusercontent.com\/flant\/examples\/master\/2020\/04-etcdhelper\/etcdhelper.go
  go get go.etcd.io\/etcd\/clientv3 k8s.io\/kubectl\/pkg\/scheme k8s.io\/apimachinery\/pkg\/runtime
  go build -o etcdhelper etcdhelper.go

3. Правим архив на etcd:

backup_dir=\/root\/backup
mkdir ${backup_dir}
cp -rL \/etc\/kubernetes ${backup_dir}
ETCDCTL_API=3 etcdctl --cacert=\/etc\/kubernetes\/pki\/etcd\/ca.crt --key=\/etc\/kubernetes\/pki\/etcd\/server.key --cert=\/etc\/kubernetes\/pki\/etcd\/server.crt --endpoints https:\/\/192.168.199.100:2379 snapshot save ${backup_dir}\/etcd.snapshot

4. Променяме мрежовата подсетка в манифестите на Kubernetes control plane. В файловете /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml променяме параметъра --service-cluster-ip-range на новата подсетка: 172.24.0.0/16 вместо 192.168.0.0/16.

5. Тъй като променяме мрежовата подсетка, за която kubeadm издава сертификати за apiserver-а (включително), необходимо е да ги преиздадем:

1. Нека видим за кои домейни и IP адреси е издаден текущият сертификат:

   openssl x509 -noout -ext subjectAltName <\/etc\/kubernetes\/pki\/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:dev-1-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:apiserver, IP Address:192.168.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

2. Подготвяме минимален конфиг за kubeadm:

   cat kubeadm-config.yaml
   apiVersion: kubeadm.k8s.io\/v1beta1
   kind: ClusterConfiguration
   networking:
     podSubnet: "10.244.0.0\/16"
     serviceSubnet: "172.24.0.0\/16"
   apiServer:
     certSANs:
     - "192.168.199.100" # IP адрес на майсторския възел

3. Изтриваме старите crt и key, тъй като без това новият сертификат няма да бъде издаден:

   rm \/etc\/kubernetes\/pki\/apiserver.{key,crt}

4. Преиздаваме сертификатите за API сървъра:

   kubeadm init phase certs apiserver --config=kubeadm-config.yaml

5. Проверяваме, че сертификатът е издаден за новата подсетка:

   openssl x509 -noout -ext subjectAltName <\/etc\/kubernetes\/pki\/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:kube-2-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:172.24.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

6. След преиздаването на сертификата на API сървъра, рестартираме контейнера му:

   docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart

7. Преогенерираме конфигурацията за admin.conf:

   kubeadm alpha certs renew admin.conf

8. Редактираме данните в etcd:

   .\/etcdhelper -cacert \/etc\/kubernetes\/pki\/etcd\/ca.crt -cert \/etc\/kubernetes\/pki\/etcd\/server.crt -key \/etc\/kubernetes\/pki\/etcd\/server.key -endpoint https:\/\/127.0.0.1:2379 change-service-cidr 172.24.0.0\/16 

   Внимание! В този момент в клъстера спира работата на резолвинг на домейни, тъй като в вече съществуващите pod’ове е /etc/resolv.conf записан старият адрес CoreDNS (kube-dns), а kube-proxy е променил правилата на iptables от старата подсет на новата. По-долу в статията са описани възможните варианти за минимизиране на престоя.

9. Ще коригираме ConfigMap-ите в пространството на имената kube-system:

   kubectl -n kube-system edit cm kubelet-config-1.16

   — тук ще заменим clusterDNS с новия IP адрес на услугата kube-dns: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   — ще коригираме data.ClusterConfiguration.networking.serviceSubnet Смяна на serviceCIDR

10. Тъй като адресът на kube-dns се е променил, е необходимо да се актуализира конфигурацията на kubelet на всички възли:

    kubeadm upgrade node phase kubelet-config && systemctl restart kubelet

11. Остана да рестартираме всички pod’ове в клъстера:

    kubectl get pods --no-headers=true --all-namespaces |sed -r 's\/(S+)s+(S+).*\/kubectl --namespace 1 delete pod 2\/e'

Минимизиране на престоя

Размисли, как можем да минимизираме времето на停留:

1. След промените на манифестите на control plane, създайте нова услуга kube-dns, например, с името kube-dns-tmp и нов адрес 172.24.0.10.
2. Направете if в etcdhelper, който няма да модифицира услугата kube-dns.
3. Заменете адреса на всички kubelet-ы ClusterDNS с новия, при което старата услуга ще продължи да работи паралелно с новата.
4. Изчакайте, докато pod’овете с приложенията се презаредят, или сами по естествени причини, или в уговореното време.
5. Премахнете услугата kube-dns-tmp и променете serviceSubnetCIDR за услугата kube-dns.

Този план ще позволи да се минимизира времето на停留 до ~минути — за времето на премахване на услугата kube-dns-tmp и замяна на подсетите за услугата kube-dns.

Модификация на podNetwork

Също така решихме да видим как да модифицираме podNetwork с помощта на полученото etcdhelper. Последователността на действията е следната:

• коригираме конфигурациите в kube-system;
• коригираме манифеста kube-controller-manager’а;
• променяме podCIDR директно в etcd;
• рестартираме всички възли на клъстера.

Сега по-подробно за тези действия:

1. Модифицираме ConfigMap-ите в пространството на имената kube-system:

kubectl -n kube-system edit cm kubeadm-config

— коригираме data.ClusterConfiguration.networking.podSubnet на новата подсетка 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

— коригираме data.config.conf.clusterCIDR: 10.55.0.0/16.

2. Модифицираме манифеста на controller-manager’а:

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

— коригираме --cluster-cidr=10.55.0.0/16.

3. Наблюдаваме текущите стойности .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses за всички възли на клъстера:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

4. Ще сменим podCIDR, правейки промени директно в etcd:

.\/etcdhelper -cacert \/etc\/kubernetes\/pki\/etcd\/ca.crt -cert \/etc\/kubernetes\/pki\/etcd\/server.crt -key \/etc\/kubernetes\/pki\/etcd\/server.key -endpoint https:\/\/127.0.0.1:2379 change-pod-cidr 10.55.0.0\/16

5. Ще проверим дали podCIDR наистина е променен:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

6. По реда, ще рестартираме всички възли в клъстера.

7. Ако поне на един възел оставим стария podCIDR, kube-controller-manager няма да може да стартира, а pod-овете в клъстера няма да бъдат планирани.

Всъщност, промяната на podCIDR може да се направи и по-лесно (например, така). Но ние искахме да се научим как да работим с etcd директно, защото има случаи, когато редактирането на обекти в Kubernetes в etcd — единственото възможно решение. (Например, не можете просто така без престой да промените полето на Service spec.clusterIP.)

Резюме

Статията разглежда възможността за работа с данни в etcd директно, т.е. извън Kubernetes API. Понякога такъв подход позволява да се правят "хитри неща". Операциите, описани в текста, бяха тествани на реални K8s клъстери. Въпреки това, статусът им на готовност за широко приложение — PoC (доказателство за концепцията). Затова, ако искате да използвате модифицирана версия на утилитата etcdhelper на вашите клъстери, правите го на свой риск.

P.S.

Прочетете също в нашия блог:

• «etcd 3.4.3: проучване на надеждността и сигурността на хранилището»;
• «Calico за мрежи в Kubernetes: запознаване и малко от опита»;
• «6 интересни системни грешки при експлоатация на Kubernetes [и тяхното решение]»;
• «Визуално ръководство за диагностика на проблеми в Kubernetes».

Източник: habr.com