Servicio de servicio Kubernetes (SVC)
El servicio puede proporcionar capacidades de equilibrio de carga, pero tiene las siguientes limitaciones de uso:
K8s tiene cuatro servicios.
Introducción a los conocimientos básicos de svc
En un clúster de Kubernetes, cada nodo ejecuta un proceso kube-proxy. Kube-proxy es responsable de implementar una forma de VIP (IP virtual) para el servicio en lugar de la forma de ExternalName. En Kubernetes v1.0, el agente está completamente en el espacio del usuario. El proxy Iptables se agregó en Kubernetes v1.1, pero no es el modo de ejecución predeterminado. A partir de Kubernetes v1.2, es un proxy de iptables de forma predeterminada. En Kubernetes v 1.8.0-beta 0, se agregó el proxy IPVS.
El proxy IPvs se utiliza de forma predeterminada en la versión 1.14 de Kubernetes.
En Kubernetes v1.0, el servicio es el concepto de "TCP/UDP sobre IP". En Kubernetes v1.1, se agregó la API de Ingress (versión beta) para representar los servicios de "Capa 7" (HTTP).
¿Por qué no utilizar DNS por turnos?
El DNS se almacenará en caché en muchos clientes. Muchos servicios no borrarán el caché después de acceder al DNS para resolver el nombre de dominio y obtener la dirección, por lo tanto, una vez que tengan la información de su dirección, no importa cuántas veces lo hagan. se accede a ellos, el equilibrio de carga fallará.
En este modo, kube-proxy monitoreará los objetos de servicio y los puntos finales de Kubernetes, llamará a la interfaz netlink para crear reglas de ipvs en consecuencia y sincronizará periódicamente las reglas de ipvs con los objetos de servicio y los objetos de puntos finales de Kubernetes para garantizar que el estado de ipvs sea como se esperaba. Al acceder al servicio, el tráfico se redirigirá a uno de los pods de backend.
Al igual que iptables, ipvs es similar a la función de enlace de netfilter, pero utiliza una tabla hash como estructura de datos subyacente y funciona en el espacio del kernel. Esto significa que IPv puede redirigir el tráfico más rápido y tener un mejor rendimiento al sincronizar reglas de proxy. Además, ipvs proporciona más opciones para algoritmos de equilibrio de carga, como:
Nota: el modo ipvs supone que el módulo del kernel IPVS se ha instalado en todos los nodos antes de ejecutar kube-proxy. Cuando kube-proxy se inicia en modo proxy ipvs, kube-proxy verificará que el módulo IPVS esté instalado en el nodo y, de lo contrario, kube-proxy volverá al modo proxy iptables.
ClusterIP utiliza principalmente iptables en cada nodo para reenviar los datos enviados al puerto correspondiente de clusterIP a kube-proxy. Luego, kube-proxy implementa internamente un método de equilibrio de carga. Puede consultar la dirección y el puerto del pod correspondiente en este servicio y luego reenviar los datos a la dirección y el puerto del pod correspondiente.
Para realizar las funciones en el diagrama, los siguientes componentes necesitan trabajar juntos principalmente:
Cree el archivo myapp-deploy.yaml.
Crear información de servicio
A veces no necesitas o no quieres equilibrio de carga y una IP de servicio separada. En este caso, puede crear un servicio sin cabeza especificando el valor de ClusterIP (spec.clusterIP) como "Ninguno".
Dichos servicios no asignan direcciones IP de clúster, kube-proxy no las maneja y la plataforma no las equilibra ni las enruta.
La característica principal es resolver el problema de cambiar el nombre del host y el nombre del puerto a través del servicio sin cabeza, es decir, vincularlo a través de él.
Para svc, una vez creado correctamente, se escribirá coreDNS. Cuando se crea nuestro svc, se escribirá un nombre de host en coreDNS en el formato del nombre del svc, el nombre del espacio de nombres y el nombre de dominio del clúster actual.
Esto significa que en un servicio sin cabeza, aunque no tenga una IP, aún puede acceder a los pods bajo el servicio accediendo al nombre de dominio.
El principio de nodePort es abrir un puerto en el nodo, importar el tráfico del puerto a kube-proxy y luego enviarlo al pod correspondiente mediante kube-proxy.
Los balanceadores de carga y los puertos de nodo son en realidad de la misma manera. La diferencia es que loadBalancer tiene un paso más que nodePort, es decir, puede llamar al proveedor de la nube para crear un equilibrio de carga LB y distribuir el tráfico a los nodos.
Este tipo de servicio puede asignar el servicio al contenido del campo externalName (por ejemplo, hub.yibo.cn) devolviendo el CNAME y su valor. El servicio ExternalName es un caso especial de servicio. No tiene selectores ni puertos ni puntos finales definidos. En cambio, para los servicios que se ejecutan fuera del clúster, proporciona servicios devolviendo el alias del servicio externo.
Al consultar el host my-service. default .cluster .local (SVC_name.namespace.SVC.cluster.local), el servicio DNS del clúster devolverá un registro CNAME con el valor my.database.example.com. El acceso a este servicio es el mismo que para otros servicios, la única diferencia es que la redirección se produce en la capa DNS y no se realiza proxy ni reenvío.
Explicación detallada de Iptables: blogs.com/hongdada/p/9758939.html
blogs.com/LiuQizhong/p/11573173.html Explicación detallada de LVS
blogs.com/fanqisoft/p/11579061.html