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

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

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

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

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

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

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

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

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

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

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

• Използва се фланел;
• Има клъстери както в облаците, така и на хардуера;
• Бих искал да избегна повторното разполагане на всички услуги в клъстера;
• Има нужда да се прави всичко с минимален брой проблеми;
• Версията на 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 към нова подмрежа.

Практика

Промяна на услугата CIDR

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

Подготвителни стъпки:

• инсталиране на необходимия софтуер и асемблиране на patched etcdhelper;
• архивиране и т.н. и /etc/kubernetes.

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

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

Следва пълна последователност от действия в детайли.

1. Инсталирайте etcd-клиент за дъмп на данни:

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. Направете резервно копие и т.н.:

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. Във файлове /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 и ключ, тъй като без това новият сертификат няма да бъде издаден:

   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 

   Внимание! В този момент резолюцията на домейна спира да работи в клъстера, тъй като в съществуващите под /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. Всичко, което остава, е да рестартирате всички подове в клъстера:

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

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

Мисли как да сведете до минимум времето за престой:

1. След като промените манифестите на контролната равнина, създайте нова услуга kube-dns, например с името kube-dns-tmp и нов адрес 172.24.0.10.
2. правя if в etcdhelper, което няма да промени услугата kube-dns.
3. Заменете адреса във всички kubelets ClusterDNS към нова, докато старата услуга ще продължи да работи едновременно с новата.
4. Изчакайте, докато модулите с приложения се преобърнат сами по естествени причини или в уговорено време.
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. Променете манифеста на контролер-мениджър:

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 няма да може да стартира и подовете в клъстера няма да бъдат планирани.

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

Общо

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

PS

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

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

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