Notas de estudio de clase abierta de tecnología nativa de la nube: concepto de red y control de políticas de K8, servicio de Kubernetes

10. Concepto de red y control de políticas de Kubernetes

1. Modelo de red básico de Kubernetes

Porque la complejidad del desarrollo de la red de contenedores es que en realidad es un parásito de la red del Host. Desde esta perspectiva, la solución de red de contenedores se puede dividir aproximadamente en dos facciones principales: subyacente / superpuesto :

• El estándar subyacente es que está en la misma capa que la red del Host. Una característica visible externamente es si utiliza el mismo segmento de red de la red del Host, el equipo básico de entrada y salida y la dirección IP del contenedor. ¿Es necesario ¿cooperar con la red del Host? (De la misma distribución central o división unificada). Esto es subyacente
• La diferencia entre Overlay es que no necesita solicitar una IP del componente de administración de IPM de la red del Host. En términos generales, solo necesita no entrar en conflicto con la red del Host, y esta IP se puede asignar libremente.

2. Exploración de redes

La base del kernel para la implementación de la red en el espacio de nombres de red. En un sentido estricto, la tecnología de contenedor runC no depende de ningún hardware. Su base de ejecución es su kernel. El kernel representativo del proceso es la tarea. Si no necesita aislamiento, utiliza el espacio del host (espacio de nombres). Datos de aislamiento del espacio estructura que debe configurarse especialmente (nsproxy-namespace proxy)

Por el contrario, si es un proxy de red independiente, o un proxy de montaje, debe estar lleno de datos privados reales. La estructura de datos que puede ver se muestra en la figura anterior.

Desde el punto de vista sensorial, un espacio de red aislado tendrá su propia tarjeta de red o equipo de red. La tarjeta de red puede ser virtual o física, tendrá su propia dirección IP, tabla de IP y tabla de enrutamiento, y su propio estado de pila de protocolos. Esto se refiere específicamente a la pila de protocolos TCP / Ip, que tiene su propio estado, y sus propias iptables, ipvs

Desde el punto de vista general, esto equivale a tener una red completamente independiente, que está aislada de la red del host. Por supuesto, el código de la pila de protocolos sigue siendo público, pero la estructura de datos es diferente.

La figura anterior puede mostrar claramente la relación de Netns en pods. Cada pod tiene un espacio de red independiente, y el contenedor de red de pods compartirá este espacio de red. Generalmente, K8s recomienda usar la interfaz Loopback para comunicarse entre contenedores de red de pod, y todos los contenedores brindan servicios externos a través de la IP del pod. Además, las redes raíz en el host se pueden considerar como un espacio de red especial, excepto que su Pid es 1.

3. Introducción a las soluciones de red convencionales

El esquema de franela es actualmente el más utilizado. Como se muestra en la figura anterior, puede ver una solución de red de contenedores típica. Lo primero que tiene que resolver es cómo llega el paquete contenedor al Host, aquí está el método de agregar un Bridge. Su backend es realmente independiente, es decir, cómo el paquete sale del Host, qué método de encapsulación se usa o no requiere encapsulación, son todos opcionales

Ahora, introduzcamos los tres backends principales:

• Uno es udp en modo de usuario, que es la primera implementación
• Luego está el Vxlan del kernel, los cuales se consideran soluciones de superposición. El rendimiento de Vxlan será mejor, pero tiene requisitos para la versión del kernel y el kernel debe admitir las características de Vxlan.
• Si su clúster no es lo suficientemente grande y está en el mismo dominio de segundo nivel, también puede optar por usar host-gw. El backend de esta manera se inicia básicamente mediante una regla de enrutamiento de transmisión y el rendimiento es relativamente alto.

4. Utilidad de la política de red

Acabo de mencionar que el modelo básico de la red de Kubernetes requiere una interconexión completa entre los pods. Esto causará algunos problemas: en un clúster de K8s, algunas cadenas de llamadas no se llaman directamente. Por ejemplo, entre dos departamentos, espero que el departamento A no visite los servicios del departamento B. En este momento, se puede utilizar el concepto de estrategia.

Básicamente, su idea es la siguiente: utiliza varios selectores (etiquetas o espacio de nombres) para encontrar un grupo de pods, o encontrar los dos extremos de la comunicación, y luego usa la descripción de la función de la transmisión para determinar si se pueden conectar. Puede entenderse como un mecanismo de lista blanca.

Antes de utilizar la política de red, tenga en cuenta que un servidor debe activar estos conmutadores como se muestra en la figura anterior. Otra cosa más importante es que el complemento de red que elegimos debe admitir la implementación de la Política de red. La política de red es solo un objeto proporcionado por K8s, y no hay componentes integrados para la implementación. Depende de si la solución de red de contenedores que elija es compatible con este estándar y su integridad. Si elige Flannel o similar, realmente no ir. Si se implementa esta Política, no servirá de nada si prueba esta

A continuación, hablemos de un ejemplo de configuración o ¿qué hacer al diseñar una política de red?

• Lo primero es controlar el objeto, al igual que la parte de especificaciones en este caso. En las especificaciones, a través de podSelector o el selector de espacio de nombres, puede optar por crear un conjunto específico de pods para aceptar nuestro control
• La segunda es pensar claramente en la dirección del flujo, ¿necesita controlar la dirección entrante o saliente? Todavía necesito controlar en ambas direcciones
• La parte más importante es la tercera parte. Si desea agregar un objeto de control a la dirección seleccionada para describir su flujo, ¿qué corriente puede entrar o salir? De manera análoga a la tupla de cinco de esta función de transmisión, podemos usar algunos selectores para determinar cuáles pueden ser mi control remoto. Esta es la elección del objeto; también podemos usar el mecanismo de IPBlock para obtener qué IP se pueden liberar; el el último es qué protocolos o qué puertos. De hecho, la combinación de características de flujo es una tupla de cinco, que seleccionará un flujo aceptable específico

11. Servicio de Kubernetes

1. Fuente de demanda

1) ¿Por qué es necesario el descubrimiento de servicios?

En el clúster K8s, las aplicaciones se implementan a través de pods. A diferencia de la implementación de aplicaciones tradicionales, las aplicaciones tradicionales se implementan en una máquina determinada. Sabemos cómo llamar a las direcciones IP de otras máquinas. Sin embargo, las aplicaciones en el clúster K8s se implementan a través de pods y el ciclo de vida del pod es de corta duración. Durante el ciclo de vida de un pod, como su creación o destrucción, su dirección IP cambiará, por lo que no se pueden utilizar los métodos de implementación tradicionales y no se puede especificar la IP para acceder a la aplicación especificada.

Además, en la implementación de aplicaciones de K8, aunque aprendí el modo de implementación de implementación antes, todavía es necesario crear un grupo de pod, y luego estos grupos de pod deben proporcionar una entrada de acceso unificada y cómo controlar el equilibrio de carga del tráfico. a este grupo. Por ejemplo, el entorno de prueba, el entorno previo al lanzamiento y el entorno en línea deben mantener la misma plantilla de implementación y método de acceso durante el proceso de implementación. Porque de esta forma, puedes usar el mismo conjunto de plantillas de aplicación para publicar directamente en diferentes entornos

Por último, el servicio de la aplicación debe estar expuesto al exterior para su acceso y debe proporcionarse a los usuarios externos para que lo llamen. La red del pod y la máquina no están en el mismo segmento de la red, entonces, ¿cómo se puede exponer la red del pod al acceso externo? Descubrimiento de servicios

2) Servicio: descubrimiento de servicios y equilibrio de carga en Kubernetes

En K8, el descubrimiento de servicios y el equilibrio de carga son servicios de K8. La imagen de arriba es la estructura del servicio en K8s. El servicio K8s proporciona acceso a la red externa y a la red del pod, es decir, se puede acceder a la red externa a través del servicio, y también se puede acceder a la red del pod a través del servicio K8s.

Hacia abajo, K8s está conectado a otro conjunto de pods, es decir, se puede equilibrar la carga a un conjunto de pods a través del servicio K8s, que no solo proporciona un portal de acceso unificado para el descubrimiento de servicios, sino que también proporciona acceso a redes externas. entre diferentes pods, proporcione una dirección de acceso unificada

2. Interpretación de casos de uso

1), sintaxis del servicio

Primero observe una gramática de K8s Service. La figura anterior es en realidad una estructura de declaración de K8s. Hay muchas sintaxis en esta estructura y hay muchas similitudes con algunos de los objetos estándar de K8 presentados anteriormente. Por ejemplo, selector para hacer algunas elecciones, etiqueta para declarar algunas de sus etiquetas, etc.

Hay un nuevo punto de conocimiento aquí, que es definir un protocolo y un puerto para el descubrimiento del servicio de K8s Service. Continúe mirando esta plantilla, declare un servicio K8s llamado my-service, tiene una app:my-serviceetiqueta, elige app:MyAppun pod de etiquetas como su backend

El último es el puerto y el protocolo de detección de servicios definidos. En este ejemplo, se define el protocolo TCP. El puerto es 80 y el puerto de destino es 9376. El efecto es que el acceso al puerto de servicio 80 se enrutará al back-end targetPort, es decir, siempre que acceda a este servicio, el puerto 80 tendrá una carga equilibrada con el app:MyApppuerto 9376 del módulo de etiquetas de back-end

2), crear y ver el servicio

Crear servicio: kubectl apply -f service.yamlokubectl created -f service.yaml

Ver el resultado después de la creación del servicio:kubectl discribe service

Una vez creado el servicio, puede ver que su nombre es my-service. El espacio de nombres, la etiqueta y el selector son los mismos que en nuestras declaraciones anteriores. Después de la declaración, se generará una dirección IP. Esta dirección IP es la dirección IP del servicio. Otros pods del clúster pueden acceder a esta dirección IP. es equivalente a pasar esto La dirección IP proporciona un acceso unificado a un pod y descubrimiento de servicios

También hay una propiedad de Endpoints, que se puede ver a través de Endpoints: ¿Qué pods se seleccionan a través del selector previamente declarado? ¿Y cuál es el estado de estas vainas? Por ejemplo, a través del selector, vemos que ha seleccionado una IP de estos pods y un puerto del targetPort declarado por estos pods.

La arquitectura real se muestra en la figura anterior. Una vez creado el servicio, se creará una dirección IP virtual y un puerto en el clúster. En el clúster, todos los pods y nodos pueden acceder al servicio a través de dicha dirección IP y puerto. Este servicio montará el pod que seleccione y su dirección IP en el backend. De esta forma, al acceder a través de la dirección IP del servicio, puede cargar balance a estos pods back-end.

Cuando el ciclo de vida de un pod cambia, por ejemplo, uno de los pods se destruye, el servicio eliminará automáticamente el pod del backend. Esto se logra: incluso si cambia el ciclo de vida del pod, los puntos finales a los que accede no cambiarán

3) Acceso al servicio en el clúster

En el clúster, ¿cómo acceden otros pods al servicio que creamos? Hay tres formas:

• Primero, puede pasar por el acceso al servicio de IP virtual, por ejemplo, my-service, este servicio que acaba de crear, a través kubectl get svco kubectl discribe servicepuede ver que su dirección IP virtual es 172.29.3.27, el puerto es 80, luego puede usar esta IP virtual y puerto Accede a la dirección de este servicio directamente en el pod

• La segunda forma es acceder directamente al nombre del servicio, confiando en la resolución de DNS, es decir, los pods en el mismo espacio de nombres pueden acceder directamente al servicio recién declarado a través del nombre del servicio. En diferentes espacios de nombres, podemos agregar el nombre del servicio ., y luego agregar el espacio de nombres donde se encuentra el servicio para acceder al servicio. Por ejemplo, use curl para acceder al servicio directamente, es decir, my-service: 80 puede acceder al Servicio.

• El tercero es acceder a través de variables de entorno.Cuando se inicia el pod en el mismo espacio de nombres, K8 colocará algunas direcciones IP, puertos y algunas configuraciones simples del servicio en el pod de K8 a través de variables de entorno. Después de que se inicia el contenedor de pod de K8s, al leer las variables de entorno del sistema, puede leer una dirección configurada por otros servicios en el espacio de nombres, o su número de puerto, etc. Por ejemplo, en un pod en el clúster, puede obtener directamente el valor de una variable de entorno a través de curl $. Por ejemplo, obtener MY_SERVICE_SERVICE_HOST es su dirección IP, MY_SERVICE es el MY_SERVICE que acabamos de declarar y SERVICE_PORT es su número de puerto. Puedes solicitar el servicio MY_SERVICE en el clúster

4） 、 Servicio sin cabeza

Una forma especial de servicio es el servicio sin cabeza. Cuando se crea el servicio, puede especificar clusterIP: None para decirle a K8s que no necesito clusterIP, y luego K8s no asignará una dirección IP virtual al servicio. ¿Cómo se puede lograr el equilibrio de carga y el acceso unificado sin una IP virtual? ¿dirección?

El pod puede resolver directamente la dirección IP de todos los pods de back-end a través de service_name usando DNS, y resolver las direcciones de todos los pods de back-end a través del registro A de DNS. El cliente selecciona una dirección IP de back-end y esta A record will A medida que cambia el ciclo de vida del pod, también cambia la lista de registros A devuelta. Esto requiere que la aplicación cliente devuelva todos los DNS del registro A a la dirección IP en la lista de registros A, y el cliente elige una dirección adecuada. Ir a visitar la vaina

5), exponer el servicio al exterior del clúster

La introducción anterior es que el nodo o pod en el clúster accede al servicio ¿Cómo se puede exponer el servicio al exterior? ¿Cómo exponer realmente la aplicación a la red pública para su acceso? También existen dos tipos de servicio para solucionar este problema, uno es NodePort y el otro es LoadBalancer

• El método de NodePort es exponer un puerto en el nodo en el nodo del clúster (es decir, en el host del nodo del clúster), que es equivalente a una capa de reenvío después de acceder a un puerto del nodo. , y reenviar a Arriba de la dirección IP virtual está la dirección IP virtual del servicio en el host en este momento

• El tipo LoadBalancer es otra capa de conversión en el NodePort. El NodePort mencionado ahora es en realidad un puerto en cada nodo en el clúster. LoadBalancer es agregar un balanceador de carga delante de todos los nodos. Por ejemplo, si cuelga un SLB en Alibaba Cloud, el balanceador de carga proporcionará una entrada unificada y balanceará la carga de todo el tráfico que toca al pod de nodo de cada nodo del clúster. Luego, el pod de nodo se convierte a ClusterIP para acceder al pod real

3. Demostración de la operación

1) Acceso al servicio en el clúster

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>

Crear un conjunto de pods primero es crear esta implementación de K8. Una vez creada la implementación, veamos si se crea el pod. Puede ver la dirección IP a través de kubectl get pod -o wide. Filtrar a través de -l, es decir, etiqueta, ejecutar = nginx. Estos dos pods son direcciones IP 10.1.0.139 y 10.1.0.140 respectivamente, y ambos tienen la etiqueta 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>

Creemos el servicio K8s nuevamente. Puede ver el estado real de este servicio a través de kubectl describe svc. Para el servicio nginx creado, su selector es run = nginx, y la dirección del pod al backend se selecciona a través del selector de run = nginx, que es la dirección de los dos pods que se acaban de ver: 10.1.0.139 y 10.1.0.140. Aquí puede ver que K8s ha generado una dirección IP virtual en el clúster para él. A través de esta dirección IP virtual, puede equilibrar la carga en los siguientes dos pods.

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      

Cree un pod de cliente para probar cómo acceder al servicio

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

Use kubectl exec -it nginx1 sh para ingresar a este pod e instalar 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- actualiza el
EOF de contribuciones principales no gratuitas

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

Acceso a través de 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>

Acceda a través de {nombre del servicio}. {Espacio de nombres}

# 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>

Acceso por nombre de servicio

# 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>

Acceso a través de variables de entorno

# 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) Exponer el servicio fuera del clúster

service.yaml agregartype: 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

Hay una IP EXTERNA adicional aquí, puede acceder al servicio a través de http: // localhost /

3) La dirección de acceso al servicio no tiene nada que ver con el ciclo de vida del 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

Ahora las direcciones IP de back-end del mapeo de servicios son 10.1.0.139 y 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

Elimine uno de los pods, ahora la dirección IP del pod se ha convertido en 10.1.0.140 y 10.1.0.142, y la dirección IP de back-end del mapeo de servicios también se ha convertido en 10.1.0.140 y 10.1.0.142

4. Diseño de arquitectura

Como se muestra en la figura anterior, el descubrimiento de servicios de K8 y el servicio de K8 son una arquitectura tan general

K8s se divide en nodo maestro y nodo trabajador:

• El contenido principal del maestro es el control de K8.
• El nodo trabajador es donde realmente se ejecuta la aplicación de usuario.

Hay un APIServer en el nodo maestro de K8s, que es el lugar para administrar de manera uniforme todos los objetos de K8s. Todos los componentes se registrarán en el APIServer para monitorear los cambios de este objeto. Por ejemplo, el ciclo de vida de nuestro pod de componentes cambia, estos eventos

Hay tres componentes clave:

• Uno es Cloud Controller Manager, responsable de configurar un balanceador de carga de LoadBalancer para acceso externo
• El otro es Coredns, que utiliza Coredns para observar un cambio en el pod backend del servicio en el APIServer, para configurar la resolución DNS del servicio, de modo que se pueda acceder directamente a la IP virtual del servicio a través del nombre del servicio, o el headless tipo de servicio. Análisis de la lista de IP
• Luego, habrá un componente kube-proxy en cada nodo, que monitorea los cambios de servicio y pod, y luego configura el pod de nodo en el clúster o un acceso a la dirección IP virtual.

¿Cuál es el enlace de acceso real? Por ejemplo, acceder al Servicio desde un Client Pod3 dentro del clúster es similar al efecto que se acaba de demostrar. Client Pod3 primero resuelve el ServiceIP a través de Coredns. Coredns le devolverá cuál es la IP de servicio correspondiente a ServiceName. Este Client Pod3 usará esta IP de servicio para realizar una solicitud. Después de que su solicitud llegue a la red del host, se enviará a las iptables o IPVS configurado por kube-proxy, realice una capa de procesamiento de interceptación y luego equilibre la carga en cada pod de back-end real, logrando así un equilibrio de carga y descubrimiento de servicios

Para el tráfico externo, por ejemplo, una solicitud a la que se accedió a través de la red pública hace un momento. Utiliza un balanceador de carga externo Cloud Controller Manager para monitorear los cambios en el servicio, configura un balanceador de carga y luego lo reenvía a un NodePort en el nodo. El NodePort también será configurado por kube-proxy. Iptables convierte el tráfico de NodePort en ClusterIP, y luego en la dirección IP de un pod en el backend para el equilibrio de carga y el descubrimiento de servicios. Este es el descubrimiento completo del servicio K8s y la estructura general del servicio K8s.

Dirección del curso : https://edu.aliyun.com/roadmap/cloudnative?spm=5176.11399608.aliyun-edu-index-014.4.dc2c4679O3eIId#suit