Notes d'étude de classe ouverte sur la technologie native du cloud: concept de réseau K8 et contrôle des politiques, service Kubernetes

10. Concept de réseau Kubernetes et contrôle des politiques

1. Modèle de réseau de base Kubernetes

Parce que la complexité du développement du réseau de conteneurs est qu'il est en fait parasite sur le réseau hôte. De ce point de vue, la solution de réseau de conteneurs peut être grossièrement divisée en deux factions principales: Underlay / Overlay :

• Le standard du calque sous-jacent est qu'il se trouve sur la même couche que le réseau hôte. Une caractéristique visible de l'extérieur est de savoir s'il utilise le même segment de réseau du réseau hôte, l'équipement de base d'entrée et de sortie et l'adresse IP du conteneur. Doit-il coopérer avec le réseau hôte? (à partir de la même distribution centrale ou division unifiée). C'est Underlay
• La différence entre Overlay est qu'il n'a pas besoin de demander une adresse IP à partir du composant de gestion IPM du réseau hôte. En règle générale, il suffit de ne pas entrer en conflit avec le réseau hôte et cette adresse IP peut être attribuée librement.

2. Explorer les réseaux

La base du noyau pour l'implémentation réseau dans l'espace de noms réseau. Au sens strict, la technologie de conteneur runC ne dépend d'aucun matériel. Sa base d'exécution est son noyau. Le noyau représentatif du processus est task. S'il ne nécessite pas d'isolation, il utilise l'espace hôte (espace de noms). Données d'isolation d'espace structure qui doit être spécialement définie (proxy nsproxy-namespace)

Au contraire, s'il s'agit d'un proxy réseau indépendant, ou d'un proxy de montage, il doit être rempli de vraies données privées. La structure de données qu'il peut voir est illustrée dans la figure ci-dessus

Du point de vue sensoriel, un espace réseau isolé aura sa propre carte réseau ou équipement réseau. La carte réseau peut être virtuelle ou physique. Elle aura sa propre adresse IP, sa propre table IP et sa table de routage, ainsi que son propre état de pile de protocoles. Cela fait spécifiquement référence à la pile de protocoles TCP / Ip, qui a son propre statut, et ses propres iptables, ipvs

Au sens général, cela équivaut à avoir un réseau complètement indépendant, qui est isolé du réseau hôte. Bien sûr, le code de la pile de protocoles est toujours public, mais la structure des données est différente

La figure ci-dessus montre clairement la relation entre Netns dans les pods. Chaque pod dispose d'un espace réseau indépendant et le conteneur de réseau de pod partagera cet espace réseau. En règle générale, K8s recommande d'utiliser l'interface de bouclage pour communiquer entre les conteneurs de réseau de pods, et tous les conteneurs fournissent des services externes via l'adresse IP du pod. De plus, Root Netns sur l'hôte peut être considéré comme un espace réseau spécial, sauf que son Pid est 1.

3. Présentation des solutions de réseau grand public

Le schéma Flannel est actuellement le plus utilisé. Comme le montre la figure ci-dessus, vous pouvez voir une solution de réseau de conteneurs typique. La première chose à résoudre est de savoir comment le paquet conteneur atteint l'hôte, voici la méthode d'ajout d'un pont. Son backend est en fait indépendant, c'est-à-dire que la façon dont le package quitte l'hôte, quelle méthode d'encapsulation est utilisée, ou ne nécessite pas d'encapsulation, sont toutes optionnelles

Présentons maintenant les trois principaux backends:

• L'un est udp en mode utilisateur, qui est la première implémentation
• Ensuite, il y a le Vxlan du noyau, qui sont tous deux considérés comme des solutions de superposition. Les performances de Vxlan seront meilleures, mais il a des exigences pour la version du noyau, et le noyau doit prendre en charge les caractéristiques de Vxlan.
• Si votre cluster n'est pas assez grand et se trouve dans le même domaine de second niveau, vous pouvez également choisir d'utiliser host-gw. Le backend de cette manière est fondamentalement démarré par une règle de routage de diffusion, et les performances sont relativement élevées.

4. Utilité de la politique du réseau

Je viens de mentionner que le modèle de base du réseau Kubernetes nécessite une interconnexion complète entre les pods, ce qui posera quelques problèmes: dans un cluster K8s, certaines chaînes d'appels ne sont pas directement appelées. Par exemple, entre deux départements, alors j'espère que le département A ne visitera pas les services du département B. A ce moment, le concept de stratégie peut être utilisé.

Fondamentalement, son idée est la suivante: il utilise divers sélecteurs (balises ou espace de noms) pour trouver un groupe de pods, ou trouver les deux extrémités de la communication, puis utiliser la description des fonctionnalités du flux pour déterminer s'ils peuvent être connectés., Peut être compris comme un mécanisme de liste blanche

Avant d'utiliser la stratégie de réseau, veuillez noter qu'apiserver doit activer ces commutateurs comme indiqué dans la figure ci-dessus. Une autre chose plus importante est que le plug-in réseau que nous choisissons doit prendre en charge la mise en œuvre de la politique de réseau. La stratégie de réseau n'est qu'un objet fourni par K8 et il n'y a pas de composants intégrés pour l'implémentation. Cela dépend si la solution de réseau de conteneur que vous choisissez prend en charge cette norme et son exhaustivité. Si vous choisissez Flannel ou similaire, ce n'est pas vraiment go. Si cette politique est mise en œuvre, elle ne sera d'aucune utilité si vous essayez ceci

Ensuite, parlons d'un exemple de configuration, ou que faire lors de la conception d'une stratégie réseau?

• La première chose à faire est de contrôler l'objet, tout comme la partie spec dans cette instance. Dans les spécifications, via podSelector ou le sélecteur d'espace de noms, vous pouvez choisir de créer un ensemble spécifique de pods pour accepter notre contrôle
• La seconde est de réfléchir clairement à la direction du flux, avez-vous besoin de contrôler la direction entrante ou sortante? Il faut encore contrôler dans les deux sens
• La partie la plus importante est la troisième partie. Si vous souhaitez ajouter un objet de contrôle à la direction sélectionnée pour décrire son flux, quel flux peut être inséré ou sorti? Comme pour le cinq-uplet de cette fonctionnalité de flux, nous pouvons utiliser certains sélecteurs pour déterminer lesquels peuvent être ma télécommande. C'est le choix de l'objet; nous pouvons également utiliser le mécanisme d'IPBlock pour obtenir les adresses IP qui peuvent être libérées. Le dernier est Quels protocoles ou quels ports. En fait, la combinaison des caractéristiques de débit est un cinq-uplet, qui sélectionnera un débit acceptable spécifique

11. Service Kubernetes

1. Source de la demande

1) Pourquoi la découverte de services est-elle nécessaire?

Dans le cluster K8, les applications sont déployées via des pods. Contrairement au déploiement traditionnel des applications, les applications traditionnelles sont déployées sur une machine donnée. Nous savons comment appeler les adresses IP d'autres machines. Cependant, les applications du cluster K8 sont déployées via des pods et le cycle de vie des pods est de courte durée. Au cours du cycle de vie d'un pod, tel que sa création ou sa destruction, son adresse IP changera, de sorte que les méthodes de déploiement traditionnelles ne peuvent pas être utilisées, et l'adresse IP ne peut pas être spécifiée pour accéder à l'application spécifiée

De plus, dans le déploiement d'applications de K8, bien que j'aie appris le mode de déploiement du déploiement auparavant, il est toujours nécessaire de créer un groupe de pods, puis ces groupes de pods doivent fournir une entrée d'accès unifiée et comment contrôler l'équilibrage de la charge du trafic à ce groupe. Par exemple, l'environnement de test, l'environnement de pré-version et l'environnement en ligne doivent conserver le même modèle de déploiement et la même méthode d'accès pendant le processus de déploiement. Parce que de cette manière, vous pouvez utiliser le même ensemble de modèles d'application pour publier directement dans différents environnements

Enfin, le service d'application doit être exposé à l'extérieur pour l'accès et doit être fourni aux utilisateurs externes pour qu'ils puissent appeler. Le réseau du pod et la machine ne sont pas dans le même segment du réseau, alors comment le réseau du pod peut-il être exposé à un accès externe? Découverte de service

2) Service: découverte de service et équilibrage de charge dans Kubernetes

Dans K8s, la découverte de services et l'équilibrage de charge sont des services K8s. L'image ci-dessus est la structure du service dans K8s. K8s Service fournit un accès au réseau externe et au réseau de pod, c'est-à-dire que le réseau externe est accessible via le service, et le réseau de pod est également accessible via le service K8s.

Vers le bas, K8s est connecté à un autre ensemble de pods, c'est-à-dire qu'il peut être équilibré en charge avec un ensemble de pods via K8s Service, qui fournit non seulement un portail d'accès unifié pour la découverte de services, mais fournit également un accès à des réseaux externes. Accès entre différents pods, fournissez une adresse d'accès unifiée

2. Utiliser l'interprétation de cas

1), syntaxe du service

Examinez d'abord une grammaire du service K8. La figure ci-dessus est en fait une structure de déclaration de K8. Il existe de nombreuses syntaxes dans cette structure, et il existe de nombreuses similitudes avec certains des objets standard de K8 introduits plus tôt. Par exemple, sélecteur pour faire certains choix, étiquette pour déclarer certaines de ses étiquettes d'étiquette, etc.

Il y a un nouveau point de connaissance ici, qui consiste à définir un protocole et un port pour la découverte de service K8s Service. Continuez à regarder ce modèle, déclarez un service K8s nommé my-service, il a une app:my-serviceétiquette, il choisit app:MyAppun tel pod d'étiquette comme backend

Le dernier est le protocole et le port de découverte de service définis. Dans cet exemple, le protocole TCP est défini. Le port est 80 et le port de destination est 9376. L'effet est que l'accès au port de service 80 sera acheminé vers le back-end targetPort, c'est-à-dire tant que vous accédez à ce service, le port 80 sera équilibré en charge avec le app:MyAppport 9376 du pod d'étiquette dorsal

2), créer et afficher le service

Créer un service: kubectl apply -f service.yamloukubectl created -f service.yaml

Visualisez le résultat après la création du service:kubectl discribe service

Une fois le service créé, vous pouvez voir que son nom est mon-service. L'espace de noms, l'étiquette et le sélecteur sont les mêmes que nos déclarations précédentes. Après la déclaration, une adresse IP sera générée. Cette adresse IP est l'adresse IP du service. Cette adresse IP est accessible par d'autres pods du cluster, qui équivaut à transmettre l'adresse IP fournit un accès unifié à un pod et à la découverte de services

Il existe également une propriété d'Endpoints, qui peut être vue via Endpoints: Quels pods sont sélectionnés via le sélecteur précédemment déclaré? Et quel est l'état de ces pods? Par exemple, via selector, on voit qu'il a sélectionné une IP de ces pods et un port du targetPort déclaré par ces pods

L'architecture réelle est illustrée dans la figure ci-dessus. Une fois le service créé, il créera une adresse IP virtuelle et un port dans le cluster. Dans le cluster, tous les pods et nœuds peuvent accéder au service via une telle adresse IP et un tel port. Ce service montera le pod qu'il sélectionne et son adresse IP sur le backend. De cette façon, lors de l'accès via l'adresse IP du service, vous pouvez équilibrer la charge de ces pods back-end.

Lorsque le cycle de vie d'un pod change, par exemple, l'un des pods est détruit, le service supprime automatiquement le pod du backend. Ceci est réalisé: même si le cycle de vie du pod change, les points de terminaison auxquels il accède ne changeront pas

3) Accès au service dans le cluster

Dans le cluster, comment les autres pods accèdent-ils au service que nous avons créé? Il y a trois manières:

• Tout d'abord, vous pouvez passer par l'accès au service IP virtuel, par exemple, mon-service ce service que vous venez de créer, via kubectl get svcou kubectl discribe servicepeut voir que son adresse IP virtuelle est 172.29.3.27, le port est 80, puis vous pouvez utiliser cette adresse IP virtuelle et port Accédez à l'adresse de ce service directement dans le pod

• La deuxième méthode consiste à accéder directement au nom du service, en s'appuyant sur la résolution DNS, c'est-à-dire que les pods du même espace de noms peuvent accéder directement au service qui vient d'être déclaré via le nom du service. Dans différents espaces de noms, nous pouvons ajouter le nom du service ., puis ajouter l'espace de noms où se trouve le service pour accéder au service. Par exemple, utilisez curl pour accéder directement au service, c'est-à-dire mon-service: 80 peuvent accéder au un service.

• La troisième consiste à accéder via des variables d'environnement.Lorsque le pod dans le même espace de noms est démarré, les K8 placent des adresses IP, des ports et quelques configurations simples du service dans le pod des K8 via des variables d'environnement. Une fois le conteneur de pod K8s démarré, en lisant les variables d'environnement du système, vous pouvez lire une adresse configurée par d'autres services dans l'espace de noms, ou son numéro de port, etc. Par exemple, dans un pod du cluster, vous pouvez directement obtenir la valeur d'une variable d'environnement via curl $. Par exemple, obtenir MY_SERVICE_SERVICE_HOST est son adresse IP, MY_SERVICE est le MY_SERVICE que nous venons de déclarer et SERVICE_PORT est son numéro de port. Vous pouvez demander le service MY_SERVICE dans le cluster

4） 、 Service sans tête

Une forme spéciale de service est le service sans tête. Lorsque le service est créé, vous pouvez spécifier clusterIP: None pour indiquer à K8 que je n'ai pas besoin de clusterIP, puis K8 n'attribuera pas d'adresse IP virtuelle au service. Comment peut-il réaliser l'équilibrage de charge et un accès unifié sans adresse IP virtuelle adresse?

Le pod peut résoudre directement l'adresse IP de tous les pods principaux via nom_service à l'aide de DNS et résoudre les adresses de tous les pods principaux via l'enregistrement A de DNS. Le client sélectionne une adresse IP principale, et cette record will À mesure que le cycle de vie du pod change, la liste d'enregistrements A renvoyée change également. L'application cliente doit renvoyer tous les DNS de l'enregistrement A à l'adresse IP de la liste d'enregistrements A, et le client choisit une adresse appropriée. Allez visiter le pod

5), exposez le service à l'extérieur du cluster

L'introduction précédente est que le nœud ou le pod du cluster accède au service. Comment le service peut-il être exposé à l'extérieur? Comment exposer réellement l'application au réseau public pour y accéder? Il existe également deux types de services pour résoudre ce problème, l'un est NodePort et l'autre est LoadBalancer

• La méthode de NodePort consiste à exposer un port sur le nœud sur le nœud du cluster (c'est-à-dire sur l'hôte du nœud du cluster), ce qui équivaut à une couche de transfert après avoir été accédé sur un port du nœud , et le transfert vers Au-dessus de l'adresse IP virtuelle est l'adresse IP virtuelle du service sur l'hôte à l'instant

• Le type LoadBalancer est une autre couche de conversion sur le NodePort. Le NodePort mentionné tout à l'heure est en fait un port sur chaque nœud du cluster. LoadBalancer consiste à ajouter un équilibreur de charge devant tous les nœuds. Par exemple, si vous accrochez un SLB sur Alibaba Cloud, l'équilibreur de charge fournira une entrée unifiée et équilibrera la charge de tout le trafic qu'il touche au module de nœuds de chaque nœud de cluster. Ensuite, le pod de nœud est converti en ClusterIP pour accéder au pod réel

3. Démonstration du fonctionnement

1) Accès au service dans le cluster

service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx    

server.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  replicas: 2
  selector:
   matchLabels:
    run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f server.yaml 
deployment.apps/nginx created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-79699b7df9-jn5p4   1/1     Running   0          46s
nginx-79699b7df9-th5hj   1/1     Running   0          46s
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod -o wide -l run=nginx
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES
nginx-79699b7df9-jn5p4   1/1     Running   0          77s   10.1.0.139   docker-desktop   <none>           <none>
nginx-79699b7df9-th5hj   1/1     Running   0          77s   10.1.0.140   docker-desktop   <none>           <none>

Créer un ensemble de pods consiste d'abord à créer ce déploiement K8. Une fois le déploiement créé, voyons si le pod est créé. Vous pouvez voir l'adresse IP via kubectl get pod -o wide. Filtrer via -l, c'est-à-dire label, run = nginx. Ces deux pods sont respectivement des adresses IP 10.1.0.139 et 10.1.0.140, et tous deux ont le libellé run = nginx

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f service.yaml 
service/nginx created
hanxiantaodeMBP:yamls hanxiantao$ kubectl describe svc
Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.96.0.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         192.168.65.3:6443
Session Affinity:  None
Events:            <none>


Name:              nginx
Namespace:         default
Labels:            run=nginx
Annotations:       <none>
Selector:          run=nginx
Type:              ClusterIP
IP:                10.108.96.80
Port:              <unset>  80/TCP
TargetPort:        80/TCP
Endpoints:         10.1.0.139:80,10.1.0.140:80
Session Affinity:  None
Events:            <none>

Créons à nouveau le service K8. Vous pouvez voir l'état réel de ce service via kubectl describe svc. Pour le service nginx créé, son sélecteur est run = nginx et l'adresse du pod vers le backend est sélectionnée via le sélecteur de run = nginx, qui est l'adresse des deux pods que nous venons de voir: 10.1.0.139 et 10.1.0.140. Ici, vous pouvez voir que K8s a généré une adresse IP virtuelle dans le cluster pour cela. Grâce à cette adresse IP virtuelle, il peut équilibrer la charge vers les deux pods suivants.

pod1.yaml：

apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  namespace: default
  labels:
    env: dev
    tie: front  
spec:
  containers:
  - name : nginx
    image: nginx:1.8
    ports:
    - containerPort: 80      

Créer un pod client pour tester comment accéder au service

hanxiantaodeMBP:yamls hanxiantao$ kubectl create -f pod1.yaml 
pod/nginx1 created
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-79699b7df9-jn5p4   1/1     Running   0          10m
nginx-79699b7df9-th5hj   1/1     Running   0          10m
nginx1                   1/1     Running   0          39s

Utilisez kubectl exec -it nginx1 sh pour entrer dans ce pod et installer curl

先 添加 163 源
tee /etc/apt/sources.list << EOF
deb http://mirrors.163.com/debian/ jessie main non-ffree contrib
deb http://mirrirs.163.com/dobian/ jessie- met à jour la principale contribution non gratuite
EOF

hanxiantaodeMBP:yamls hanxiantao$ kubectl exec -it nginx1 sh
# apt-get update && apt-get install -y curl

Accès via ClusterIP

# curl http://10.108.96.80:80
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Accès via {service name}. {Namespace}

# curl http://nginx     
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Accès par nom de service

# curl http://nginx.default
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Accès via des variables d'environnement

# env
KUBERNETES_PORT=tcp://10.96.0.1:443
KUBERNETES_SERVICE_PORT=443
HOSTNAME=nginx1
HOME=/root
NGINX_PORT_80_TCP=tcp://10.108.96.80:80
TERM=xterm
KUBERNETES_PORT_443_TCP_ADDR=10.96.0.1
NGINX_VERSION=1.8.1-1~jessie
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
NGINX_SERVICE_HOST=10.108.96.80
KUBERNETES_PORT_443_TCP_PORT=443
KUBERNETES_PORT_443_TCP_PROTO=tcp
NGINX_SERVICE_PORT=80
NGINX_PORT=tcp://10.108.96.80:80
KUBERNETES_SERVICE_PORT_HTTPS=443
KUBERNETES_PORT_443_TCP=tcp://10.96.0.1:443
KUBERNETES_SERVICE_HOST=10.96.0.1
PWD=/
NGINX_PORT_80_TCP_ADDR=10.108.96.80
NGINX_PORT_80_TCP_PORT=80
NGINX_PORT_80_TCP_PROTO=tcp
# curl $NGINX_SERVICE_HOST
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

2) Exposer le service à l'extérieur du cluster

service.yaml ajoutertype: LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    run: nginx
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    run: nginx
  type: LoadBalancer  

hanxiantaodeMBP:yamls hanxiantao$ kubectl apply -f service.yaml 
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
service/nginx configured
hanxiantaodeMBP:yamls hanxiantao$ kubectl get svc -o wide
NAME         TYPE           CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE   SELECTOR
kubernetes   ClusterIP      10.96.0.1      <none>        443/TCP        29d   <none>
nginx        LoadBalancer   10.108.96.80   localhost     80:31943/TCP   29m   run=nginx

Il y a une IP EXTERNE supplémentaire ici, vous pouvez accéder au service via http: // localhost /

3) L'adresse d'accès au service n'a rien à voir avec le cycle de vie du pod

hanxiantaodeMBP:yamls hanxiantao$ kubectl describe svc nginx
Name:                     nginx
Namespace:                default
Labels:                   run=nginx
Annotations:              <none>
Selector:                 run=nginx
Type:                     LoadBalancer
IP:                       10.108.96.80
LoadBalancer Ingress:     localhost
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31943/TCP
Endpoints:                10.1.0.139:80,10.1.0.140:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason  Age    From                Message
  ----    ------  ----   ----                -------
  Normal  Type    4m49s  service-controller  ClusterIP -> LoadBalancer

Désormais, les adresses IP principales du mappage de services sont 10.1.0.139 et 10.1.0.140

hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod
NAME                     READY   STATUS    RESTARTS   AGE
nginx-79699b7df9-jn5p4   1/1     Running   0          35m
nginx-79699b7df9-th5hj   1/1     Running   0          35m
nginx1                   1/1     Running   0          25m
hanxiantaodeMBP:yamls hanxiantao$ kubectl delete pod nginx-79699b7df9-jn5p4
pod "nginx-79699b7df9-jn5p4" deleted
hanxiantaodeMBP:yamls hanxiantao$ kubectl get pod -o wide
NAME                     READY   STATUS    RESTARTS   AGE   IP           NODE             NOMINATED NODE   READINESS GATES
nginx-79699b7df9-bb95z   1/1     Running   0          37s   10.1.0.142   docker-desktop   <none>           <none>
nginx-79699b7df9-th5hj   1/1     Running   0          36m   10.1.0.140   docker-desktop   <none>           <none>
nginx1                   1/1     Running   0          26m   10.1.0.141   docker-desktop   <none>           <none>
hanxiantaodeMBP:yamls hanxiantao$ kubectl describe svc nginx
Name:                     nginx
Namespace:                default
Labels:                   run=nginx
Annotations:              <none>
Selector:                 run=nginx
Type:                     LoadBalancer
IP:                       10.108.96.80
LoadBalancer Ingress:     localhost
Port:                     <unset>  80/TCP
TargetPort:               80/TCP
NodePort:                 <unset>  31943/TCP
Endpoints:                10.1.0.140:80,10.1.0.142:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:
  Type    Reason  Age   From                Message
  ----    ------  ----  ----                -------
  Normal  Type    6m2s  service-controller  ClusterIP -> LoadBalancer

Supprimez l'un des pods, maintenant l'adresse IP du pod est devenue 10.1.0.140 et 10.1.0.142, et l'adresse IP principale du mappage de service est également devenue 10.1.0.140 et 10.1.0.142

4. Conception de l'architecture

Comme le montre la figure ci-dessus, la découverte de service K8s et le service K8s sont une telle architecture globale

K8s est divisé en nœud maître et nœud de travail:

• Le contenu principal du master est le contrôle K8s
• Le nœud worker est l'endroit où l'application utilisateur s'exécute réellement

Il y a un APIServer dans le nœud maître K8s, qui est l'endroit pour gérer uniformément tous les objets K8s. Tous les composants seront enregistrés sur l'APIServer pour surveiller les modifications de cet objet. Par exemple, le cycle de vie de notre module de composants change, ces événements

Il y a trois éléments clés:

• L'un est Cloud Controller Manager, responsable de la configuration d'un équilibreur de charge de LoadBalancer pour l'accès externe
• L'autre est Coredns, qui utilise Coredns pour observer un changement dans le pod backend du service dans l'APIServer, pour configurer la résolution DNS du service, de sorte que l'adresse IP virtuelle du service soit directement accessible via le nom du service, ou le headless type de service. Analyse de la liste d'adresses IP
• Ensuite, il y aura un composant kube-proxy dans chaque nœud, qui surveille les changements de service et de pod, puis configure réellement le pod de nœud dans le cluster ou un accès à l'adresse IP virtuelle

Quel est le lien d'accès réel? Par exemple, l'accès au service à partir d'un pod client3 à l'intérieur du cluster est similaire à l'effet qui vient d'être démontré. Le module client3 résout d'abord le ServiceIP via Coredns. Coredns lui retournera l'adresse IP du service correspondant à ServiceName. Ce module client3 utilisera cette adresse IP de service pour effectuer une requête. Une fois que sa requête aura atteint le réseau de l'hôte, il affichera l'iptables ou IPVS configuré par kube-proxy effectuer une couche de traitement d'interception, puis équilibrer la charge sur chaque pod back-end réel, réalisant ainsi un équilibrage de charge et une découverte de service

Pour le trafic externe, par exemple, une demande qui a été accédée via le réseau public tout à l'heure. Il utilise un équilibreur de charge externe Cloud Controller Manager pour surveiller les modifications de service, configure un équilibreur de charge, puis le transmet à un NodePort sur le nœud. Le NodePort sera également configuré par kube-proxy. Iptables convertit le trafic NodePort en ClusterIP, puis dans l'adresse IP d'un pod sur le backend pour l'équilibrage de charge et la découverte de services. Il s'agit de l'ensemble de la découverte du service K8s et de la structure globale du service K8s

Adresse du cours : https://edu.aliyun.com/roadmap/cloudnative?spm=5176.11399608.aliyun-edu-index-014.4.dc2c4679O3eIId#suit