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

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

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

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

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

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

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

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

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

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

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

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

И така, отдавна ни интересува какво и как се съхранява в etcd в Kubernetes, какво можем да направим с това... И помислихме: "Защо просто не обновим данните в 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 и /etc/kubernetes.

Кратък план за действия по смяна на serviceCIDR:

• промяна на манифестите на 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\ngo get go.etcd.io\/etcd\/clientv3 k8s.io\/kubectl\/pkg\/scheme k8s.io\/apimachinery\/pkg\/runtime\ngo 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 на нова подсетка.

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. Да направим ако в etcdhelper, който няма да модифицира услугата kube-dns.
3. Да заменим в всички kubelet-ове адреса на ClusterDNS с новия, при това старата услуга ще продължи да работи паралелно с новата.
4. Да изчакаме, докато pod’овете с приложенията се преместят или сами по естествени причини, или в уговорено време.
5. Да изтрием услугата kube-dns-tmp и да променим serviceSubnetCIDR за услугата kube-dns.

Този план позволява да минимизираме времето на простоя до ~1 минута — за времето на изтриване на услугата 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