L'utilisation d'IPVS présente certains avantages en termes de performances dans les clusters à grande échelle, mais elle nécessite également certaines conditions pour le prendre en charge. Si elles ne sont pas remplies, il sera automatiquement rétrogradé pour utiliser le mode iptables. L'environnement actuel est que la version du noyau est 3.10.0 à Au début, et le système est CentOS.7.6, le noyau est mis à niveau vers la version 4.1 pour le prendre entièrement en charge.

1. Présentation de SVC

1.1 Présentation du mode proxy

Dans un cluster Kubernetes, chaque nœud exécute un processus Kube-proxy. kube-proxy est responsable de l'implémentation d'une forme de VIP (IP virtuelle) pour le service au lieu d'ExternalName.

Dans Kubernetes v1.0, le proxy se trouve entièrement dans l'espace utilisateur. Dans la version Kubernetes v1.1, le proxy iptables est nouveau, mais ce n'est pas le mode de fonctionnement par défaut. Depuis Kubernetes v1.2, la valeur par défaut est le proxy iptables. Dans Kubernetes v1.8.0-beta.0, le proxy ipvs a été ajouté. À partir de Kubernetes version 1.14, le proxy ipvs est utilisé par défaut.

Découverte du service Kubernetes - Mode proxy

1.2 Avantages de l'IPVS

Pourquoi choisir IPVS pour Kubernetes ?

À mesure que l’utilisation de Kubernetes se développe, l’évolutivité de ses ressources devient de plus en plus importante. En particulier, l’évolutivité des services est essentielle à l’adoption de Kubernetes par les développeurs/entreprises exécutant de grandes charges de travail.

Kube-proxy est l'élément constitutif du routage de services, qui s'appuie sur des iptables renforcés pour prendre en charge les types de services de base tels que ClusterIP et NodePort. Cependant, iptables a du mal à s'adapter à des milliers de services car il est conçu uniquement pour le pare-feu et est basé sur des listes de règles du noyau.

Bien que Kubernetes prenne déjà en charge 5 000 nœuds dans la version v1.6, Kube-proxy utilisant iptables est en fait le goulot d'étranglement pour faire évoluer le cluster jusqu'à 5 000 nœuds. Un exemple est qu'en utilisant les services NodePort dans un cluster de 5 000 nœuds, si nous avons 2 000 services et que chaque service a 10 pods, cela générera au moins 20 000 enregistrements iptables sur chaque nœud de travail, ce qui peut rendre le noyau très occupé.

D’un autre côté, l’utilisation de l’équilibrage de charge des services intra-cluster basé sur IPVS peut être très utile dans ce cas. IPVS est conçu pour l'équilibrage de charge et utilise une structure de données plus efficace (table de hachage) qui permet une mise à l'échelle presque illimitée.

taper	Présentation de l'application
`rr`	tournoi à la ronde
`lc`	Nombre minimum de connexions
`dh`	hachage cible
`sh`	hachage source
`sed`	délai minimum attendu
`nq`	pas de planification de file d'attente

2. Mettez à niveau le noyau

Si la version du noyau est déjà supérieure à 4.1, cette étape peut être ignorée, car cette version du noyau peut parfaitement prendre en charge IPVS. En prenant comme exemple ma version actuelle du noyau, si le mode Service passe d'iptables à ipvs, les problèmes suivants peuvent survenir :

Le nœud back-end pointé par ipvs est incorrect, et il est correct si le svc est supprimé et reconstruit à nouveau
Lorsque le nombre de répliques change, les IPV ne peuvent pas immédiatement percevoir
Si vous utilisez directement le nom de domaine pour accéder à svc, la résolution échouera.

# 开始环境的系统信息
# uname -r 
3.10.0-1160.41.1.el7.x86_64
# cat /etc/redhat-release 
CentOS Linux release 7.9.2009 (Core)

# 在 3.10 内核版本中改用ipvs，kube-proxy 会报如下错误

# kubectl -n kube-system logs kube-proxy-6pp2d
E0415 09:46:55.397466       1 proxier.go:1192] Failed to sync endpoint for service: 172.16.0.82:30080/TCP, err: parseIP Error ip=[172 16 100 7 0 0 0 0 0 0 0 0 0 0 0 0]
E0415 09:46:55.398639       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[172 16 100 7 0 0 0 0 0 0 0 0 0 0 0 0]
E0415 09:46:55.398658       1 proxier.go:1533] Failed to sync endpoint for service: 10.10.1.35:30080/TCP, err: parseIP Error ip=[172 16 100 7 0 0 0 0 0 0 0 0 0 0 0 0]
E0415 09:46:55.398751       1 proxier.go:1950] Failed to list IPVS destinations, error: parseIP Error ip=[172 16 100 7 0 0 0 0 0 0 0 0 0 0 0 0]
...

2.1 Téléchargement du package du noyau

1) Télécharger depuis Alibaba Cloud

2.2 Installation du paquet du noyau

# 更新内核时，对系统的cpu的负载很高，因此建议一台一台更新

# yum install kernel-4.9.215-36.el7.x86_64.rpm -y
# init 6 

# uname -r
4.9.215-36.el7.x86_64

3. Changer de mode

3.1 Ouvrir les IPV

Vérifiez si le noyau a chargé ipvs, sinon, chargez-le et installez-le séparément.

# lsmod | grep -e ip_vs
ip_vs_sh               16384  0 
ip_vs_wrr              16384  0 
ip_vs_rr               16384  9 
ip_vs                 147456  15 ip_vs_wrr,ip_vs_rr,ip_vs_sh
nf_conntrack          106496  8 ip_vs,nf_conntrack_proto_sctp,nf_conntrack_ipv4,nf_conntrack_netlink,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
libcrc32c              16384  2 ip_vs,xfs

# lsmod |grep nf_conntrack_ipv4
nf_conntrack_ipv4      16384  8 
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_conntrack          106496  8 ip_vs,nf_conntrack_proto_sctp,nf_conntrack_ipv4,nf_conntrack_netlink,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_na

# cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack_ipv4
EOF

# chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4

# yum -y install ipset ipvsadm

3.2 Modification du mode SVC

# kubectl edit configmap kube-proxy -n kube-system
...
    kind: KubeProxyConfiguration
    metricsBindAddress: ""
    mode: "ipvs"                        # "" 改成 ipvs
    nodePortAddresses: null
    oomScoreAdj: null
...

configmap/kube-proxy edited

--
# 删除现有的 kube-proxy pod,相当于重启后才会变更成 ipvs
# kubectl get pods -n kube-system|grep kube-proxy
kube-proxy-6pp2d                          1/1     Running   1          8h
kube-proxy-mcfp6                          1/1     Running   1          8h
kube-proxy-qmdhp                          1/1     Running   1          8h

# kubectl delete pod/kube-proxy-6pp2d -n kube-system
pod "kube-proxy-6pp2d" deleted
# kubectl delete pod/kube-proxy-mcfp6-n kube-system
pod "kube-proxy-mcfp6" deleted
# kubectl delete pod/kube-proxy-qmdhp -n kube-system
pod "kube-proxy-qmdhp" deleted

3.3 Afficher la vérification

# kubectl -n kube-system logs kube-proxy-qmdhp|grep ipvs
I0415 10:48:49.984477       1 server_others.go:259] Using ipvs Proxier.

# 在 kube-proxy pod 看到如上信息后说明是启用ipvs的

# 测试使用的是 deployment 2个nginx, 一个 svc 指向 nginx pod

# ipvsadm -Ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  127.0.0.1:30080 rr
  -> 172.16.100.8:80              Masq    1      0          0         
  -> 172.16.100.197:80            Masq    1      0          0         
TCP  172.16.0.1:443 rr
  -> 10.10.1.35:6443              Masq    1      4          0         
TCP  172.16.0.10:53 rr
  -> 172.16.100.9:53              Masq    1      0          0         
  -> 172.16.100.10:53             Masq    1      0          0         
TCP  172.16.0.10:9153 rr
  -> 172.16.100.9:9153            Masq    1      0          0         
  -> 172.16.100.10:9153           Masq    1      0          0               
...

Remarque : ipvs n'est pas encore stable, veuillez l'utiliser avec prudence ; et l'option --masquerade-all n'est pas compatible avec le contrôle de la politique de sécurité de Calico, veuillez envisager de l'utiliser de manière appropriée (Calico exige que cette option ne puisse pas être activée lors de l'élaboration de la politique réseau. restrictions)

Référence:

https://blog.csdn.net/weixin_43936969/article/details/106175580
https://blog.csdn.net/qq_25854057/article/details/122469765
https://kubernetes.io/zh/blog/2018/07/ 09/ipvs-based-in-cluster-load-balancing-deep-dive/

Le mode de fonctionnement du service Kubernetes passe de iptables à ipvs