Notre expérience de travail avec les données du cluster Kubernetes etcd directement (sans l'API K8s)

De plus en plus, des clients nous contactent pour demander l'accès à un cluster Kubernetes afin d'accéder aux services à l'intérieur du cluster : pour pouvoir se connecter directement à une base de données ou à un service, pour relier une application locale aux applications à l'intérieur du cluster…

Par exemple, il est nécessaire de se connecter depuis sa machine locale au service memcached.staging.svc.cluster.local. Nous offrons cette possibilité grâce à un VPN à l'intérieur du cluster, auquel le client se connecte. Pour cela, nous annonçons les sous-réseaux des pods, des services et nous mettons à jour le DNS du cluster pour le client. Ainsi, lorsque le client essaie de se connecter à un service memcached.staging.svc.cluster.local, la requête part vers le DNS du cluster et en retour obtient l'adresse de ce service depuis le réseau de service du cluster ou l'adresse du pod.

Nous configurons les clusters K8s avec kubeadm, où par défaut, le sous-réseau des services est 192.168.0.0/16, et le réseau des pods est 10.244.0.0/16. En général, tout fonctionne bien, mais il y a quelques points :

• Le sous-réseau 192.168.*.* est souvent utilisé dans les réseaux d'entreprise des clients, et encore plus souvent — dans les réseaux domestiques des développeurs. Et cela provoque des conflits : les routeurs domestiques fonctionnent dans ce sous-réseau et le VPN pousse ces sous-réseaux du cluster au client.
• Nous avons plusieurs clusters (clusters de production, de stage et/ou plusieurs clusters dev). Dans ce cas, tous auront par défaut les mêmes sous-réseaux pour les pods et les services, ce qui crée de grandes complications pour travailler simultanément avec des services dans plusieurs clusters.

Nous avons depuis longtemps adopté la pratique d'utiliser différents sous-réseaux pour les services et les pods dans le cadre d'un même projet - en gros, pour que tous les clusters aient des réseaux différents. Cependant, il existe un grand nombre de clusters en opération que nous préférerions ne pas refondre depuis le début, car de nombreux services, applications stateful, etc., y sont déjà déployés.

Et donc, nous nous sommes posé la question : comment changer le sous-réseau dans un cluster existant ?

Recherche de solutions

La pratique la plus courante est de recréer tout les services de type ClusterIP. En alternative, on peut recommander et ceci :

Le processus suivant a un problème : après avoir tout configuré, les pods apparaissent avec l'ancien IP comme serveur de noms DNS dans /etc/resolv.conf.
Comme je n'ai toujours pas trouvé la solution, j'ai dû réinitialiser l'ensemble du cluster avec kubeadm reset et le réinitialiser à nouveau.

Mais cela ne convient pas à tout le monde… Voici des informations plus détaillées pour notre cas :

• Flannel est utilisé ;
• Il y a des clusters aussi bien dans le cloud que sur le matériel ;
• Nous aimerions éviter de redéployer tous les services dans le cluster;
• Il est nécessaire de tout faire avec un minimum de problèmes;
• La version de Kubernetes est 1.16.6 (d'ailleurs, les actions suivantes seront analogues pour d'autres versions);
• La tâche principale consiste à remplacer dans le cluster, déployé avec kubeadm, le sous-réseau de services 192.168.0.0/16, par 172.24.0.0/16.

Et il se trouve que nous avons depuis longtemps été curieux de voir ce qui est stocké dans Kubernetes dans etcd, ce qui peut être fait avec cela... Nous avons donc pensé : «Pourquoi ne pas simplement mettre à jour les données dans etcd, en remplaçant les anciennes adresses IP (sous-réseau) par les nouvelles?»

Après avoir cherché des outils prêts à l'emploi pour travailler avec les données dans etcd, nous n'avons trouvé rien qui résolve complètement la tâche posée. (Au fait, si vous connaissez des utilitaires pour manipuler les données directement dans etcd, nous vous serions reconnaissants pour des liens.) Cependant, un bon point de départ a été etcdhelper de OpenShift (merci à ses auteurs!).

Cet utilitaire peut se connecter à etcd à l'aide de certificats et lire les données à partir de là à l'aide de commandes ls, obtenir, dump.

Nous complétons etcdhelper

La pensée suivante est évidente : « Qu'est-ce qui nous empêche d'ajouter cette fonctionnalité à l'utilitaire, en y ajoutant la possibilité d'écrire des données dans etcd ? »

Elle s'est incarnée dans une version modifiée d'etcdhelper avec deux nouvelles fonctionnalités changeServiceCIDR et changePodCIDR. Son code peut être consulté ici.

Que font les nouvelles fonctionnalités ? L'algorithme changeServiceCIDR:

• crée un désérialiseur;
• compile une expression régulière pour remplacer le CIDR;
• parcourt tous les services de type ClusterIP dans le cluster :
  • décodons la valeur d'etcd en objet Go;
  • à l'aide de l'expression régulière, remplaçons les deux premiers octets de l'adresse;
  • assignons à chaque service une adresse IP du nouveau sous-réseau;
  • créons un sérialiseur, transformons l'objet Go en protobuf, écrivons les nouvelles données dans etcd.

Fonction changePodCIDR est essentiellement similaire changeServiceCIDR — seulement au lieu de modifier les spécifications des services, nous faisons cela pour le nœud et changeons .spec.PodCIDR en un nouveau sous-réseau.

Pratique

Changement de serviceCIDR

Le plan pour réaliser la tâche posée est très simple, mais implique un temps d'arrêt lors de la recréation de tous les pod dans le cluster. Après la description des étapes principales, nous partagerons également nos réflexions sur la façon de minimiser théoriquement ce temps d'arrêt.

Actions préparatoires :

• installation du logiciel nécessaire et compilation de etcdhelper patché;
• sauvegarde d'etcd et /etc/kubernetes.

Un bref plan d'action pour changer le serviceCIDR :

• modification des manifests de apiserver et controller-manager ;
• re-certification;
• modification des services ClusterIP dans etcd;
• redémarrage de tous les pod dans le cluster.

Voici la séquence complète des actions en détail.

1. Installer le client etcd pour le dump des données :

apt install etcd-client

2. Rassembler etcdhelper :

• Installer 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

• Enregistrer etcdhelper.go, télécharger les dépendances, compiler :

  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. Faire une sauvegarde 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. Changer le sous-réseau de service dans les manifests du plan de contrôle Kubernetes. Dans les fichiers /etc/kubernetes/manifests/kube-apiserver.yaml et /etc/kubernetes/manifests/kube-controller-manager.yaml modifier le paramètre --service-cluster-ip-range vers le nouveau sous-réseau : 172.24.0.0/16 au lieu de 192.168.0.0/16.

5. Puisque nous modifions le sous-réseau de service, pour lequel kubeadm émet des certificats pour le serveur API (y compris), ils doivent être réémis :

1. Voyons pour quels domaines et adresses IP le certificat actuel a été émis :

   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. Préparons une configuration minimale pour 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" # Adresse IP du nœud maître

3. Supprimer les anciens crt et key, car sans cela le nouveau certificat ne sera pas émis :

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

4. Réémettre les certificats pour le serveur API :

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

5. Vérifions que le certificat a été émis pour le nouveau sous-réseau :

   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. Après la réémission du certificat du serveur API, redémarrons son conteneur :

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

7. Regénérer la config pour admin.conf:

   kubeadm alpha certs renew admin.conf

8. Modifier les données dans 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 

   Attention ! À ce moment, la résolution de noms de domaine dans le cluster cesse de fonctionner, car les adresses anciennes de CoreDNS (kube-dns) sont inscrites dans les pods existants, et kube-proxy a modifié les règles iptables en passant de l'ancienne sous-réseau à la nouvelle. L'article suivant aborde les différentes manières de minimiser les temps d'arrêt. /etc/resolv.conf Corrigeons les ConfigMaps dans l'espace de noms

9. kubectl -n kube-system edit cm kubelet-config-1.16 kube-system:

   — ici, remplaçons

   clusterDNS par la nouvelle adresse IP du service kube-dns : kubectl -n kube-system get svc kube-dns kubectl -n kube-system edit cm kubeadm-config.

   — modifions

   data.ClusterConfiguration.networking.serviceSubnet Puisque l'adresse de kube-dns a changé, il est nécessaire de mettre à jour la configuration kubelet sur tous les nœuds : en un nouveau sous-réseau.

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

    Il reste à redémarrer tous les pods du cluster :

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

    Minimisation des temps d'arrêt

Idées sur la manière d'atténuer le temps d'arrêt :

Après avoir modifié les manifests du control plane, créez un nouveau service kube-dns, par exemple, nommé

1. kube-dns-tmp et avec une nouvelle adresse Créer 172.24.0.10.
2. dans etcdhelper, qui ne modifiera pas le service kube-dns. if Remplacer dans tous les kubelets l'adresse
3. ClusterDNS par la nouvelle, tout en laissant l'ancien service fonctionner en même temps que le nouveau. Attendez que les pods des applications soient remplacés, soit par leurs propres moyens, soit à un moment convenu.
4. Supprimer le service
5. et changer et avec une nouvelle adresse serviceSubnetCIDR pour le service kube-dns. Ce plan permettra de minimiser le temps d'arrêt à environ une minute — le temps de suppression du service

et de changement de sous-réseau pour le service et avec une nouvelle adresse Modification de podNetwork . La cause la plus intéressante et nouvelle pour moi a été l'augmentation significative du trafic des requêtes DNS. C'est ce dont je vais parler dans mon post, et ce qu'il convient d'en faire..

Par la même occasion, nous avons décidé de voir comment modifier podNetwork à l'aide du etcdhelper obtenu. Le déroulement des actions est le suivant :

corrigeons les configs dans

• corrigeons le manifest du kube-controller-manager ; kube-system;
• modifions podCIDR directement dans etcd ;
• redémarrons tous les nœuds du cluster.
• Maintenant, examinons plus en détail ces actions :

1. Modifions les ConfigMaps dans l'espace de noms

— corrigeons kube-system:

— modifions

data.ClusterConfiguration.networking.podSubnet par la nouvelle sous-réseau kubectl -n kube-system edit cm kube-proxy 10.55.0.0/16.

data.config.conf.clusterCIDR: 10.55.0.0/16

data.ClusterConfiguration.networking.podSubnet 2. Modifions le manifest du controller-manager :.

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

--cluster-cidr=10.55.0.0/16

data.ClusterConfiguration.networking.podSubnet 3. Vérifions les valeurs actuelles.

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

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. Nous allons remplacer le podCIDR en modifiant directement 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. Vérifions que le podCIDR a bien été changé :

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. Nous allons redémarrer chaque nœud du cluster un à un.

7. Si l'un des nœuds garde l'ancien podCIDR, alors le kube-controller-manager ne pourra pas démarrer, et les pods dans le cluster ne seront pas planifiés.

En réalité, il est possible de modifier le podCIDR de manière plus simple (par exemple, ainsi). Mais nous souhaitions vraiment apprendre à travailler directement avec etcd, car il existe des cas où modifier des objets Kubernetes dans etcd est la seule option possible. (Par exemple, il n'est pas simplement possible de modifier le champ spec.clusterIP d'un Service sans temps d'arrêt..)

Conclusion

Cet article aborde la possibilité de travailler avec les données dans etcd directement, c'est-à-dire en contournant l'API Kubernetes. Parfois, cette approche permet de faire des « trucs malins ». Les opérations présentées dans le texte ont été testées sur de réels clusters K8s. Cependant, leur état de préparation à une utilisation générale est PoC (preuve de concept). Par conséquent, si vous souhaitez utiliser une version modifiée de l'outil etcdhelper sur vos clusters, faites-le à vos propres risques.

P.S.

Lisez aussi dans notre blog :

• «etcd 3.4.3 : étude de la fiabilité et de la sécurité du stockage»;
• «Calico pour le réseau dans Kubernetes : introduction et quelques expériences»;
• «6 bogues système intéressants lors de l'exploitation de Kubernetes [et leurs solutions]»;
• «Guide visuel pour le diagnostic des erreurs dans Kubernetes».

Source : habr.com