[Nativo en la nube | Aprendiendo Kubernetes desde cero] 17. Servicio de tecnología central de Kubernetes

Este artículo se ha incluido en la columna " Aprender k8s desde cero "
Artículo anterior: Detección de contenedores y estrategia de inicio de k8spod Haga clic saltar

inserte la descripción de la imagen aquí

Comprenda rápidamente el servicio

Anteriormente aprendimos que la implementación solo garantiza la cantidad de pods de microservicios que admiten servicios, pero no resuelve el problema de cómo acceder a estos servicios. Un Pod es solo una instancia de un servicio en ejecución, que puede detenerse en un nodo en cualquier momento e iniciar un nuevo Pod con una nueva IP en otro nodo, por lo que no puede proporcionar servicios con una IP y un número de puerto definidos.

Para proporcionar servicios de manera estable, se requieren capacidades de equilibrio de carga y detección de servicios. El trabajo realizado por el descubrimiento de servicios es encontrar la instancia de servicio de back-end correspondiente para el servicio al que accede el cliente. En el clúster K8S, el servicio al que el cliente necesita acceder es el objeto Servicio. Cada Servicio corresponde a una IP virtual válida dentro del clúster y se accede a un servicio dentro del clúster a través de la IP virtual.

En un clúster K8S, kube-proxy implementa el equilibrio de carga de los microservicios. kube-proxy es un equilibrador de carga dentro del clúster k8s. Es un servidor proxy distribuido, y hay uno en cada nodo de K8S; este diseño refleja sus ventajas de escalabilidad, cuantos más nodos necesitan acceder al servicio, más kube-proxy proporciona capacidades de equilibrio de carga, la cantidad de servidores de alta la disponibilidad de nodos también aumenta. Por el contrario, generalmente usamos el proxy inverso para equilibrar la carga en el lado del servidor, y necesitamos resolver aún más el problema de alta disponibilidad del proxy inverso.

El significado de la existencia del Servicio

Evitar que Pod se desconecte [Detección de servicios]

Debido a que cada vez que se crea un Pod, corresponde a una dirección IP, y esta dirección IP es de corta duración y cambiará cada vez que se actualice el Pod. Supongamos que cuando hay varios Pods en nuestra página de inicio y hay también múltiples Pods en el back-end, esto Cuando acceden entre sí, necesitan obtener la dirección IP del Pod a través del centro de registro y luego acceder al Pod correspondiente.
Por favor agregue la descripción de la imagen

Definir la política de acceso al pod [Saldo de carga]

El Pod en el extremo frontal de la página accede al Pod en el extremo posterior a través de la capa de Servicio, y el Servicio también puede realizar el equilibrio de carga aquí. Existen muchas estrategias de implementación para el equilibrio de carga, como:

  • aleatorio
  • votación
  • relación de respuesta
    Por favor agregue la descripción de la imagen

La relación entre Pod y Servicio

Aquí, la asociación entre el Pod y el Servicio todavía se basa en la etiqueta y el selector [igual que el Controlador]

Por favor agregue la descripción de la imagen
Cuando accedemos al servicio, en realidad necesitamos una dirección IP, esta IP definitivamente no es la dirección IP del pod, sino una IP virtual.vip

Tipos comunes de servicio

Hay tres tipos comunes de servicio

  • ClusterIp: Acceso dentro del clúster
  • NodePort: utilizado por aplicaciones de acceso externo
  • LoadBalancer: utilizado para aplicaciones de acceso externo, nube pública

Ejemplo

Podemos exportar un archivo que contiene la información de configuración del servicio

kubectl expose deployment web --port=80 --target-port=80 --dry-run -o yaml > service.yaml

service.yaml se ve así

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
status:
  loadBalancer: {
    
    }

Si no lo configuramos, el primer método, ClusterIp, se usa por defecto, es decir, solo se puede usar dentro del clúster.Podemos agregar un campo de tipo para configurar nuestro tipo de servicio.

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: null
  labels:
    app: web
  name: web
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: web
  type: NodePort
status:
  loadBalancer: {
    
    }

Después de modificar el comando, creamos un pod usando

kubectl apply -f service.yaml

Luego puede ver que se ha modificado con éxito al tipo NodePort, y la última forma restante es LoadBalanced: aplicaciones de acceso externo que usan la nube pública

El nodo generalmente se implementa en la intranet y la red externa generalmente es inaccesible, entonces, ¿cómo acceder a ella?

  • Encuentre una máquina a la que se pueda acceder a través de la red externa, instale nginx y proxy inverso
  • Agregar manualmente nodos accesibles a nginx

Si usamos LoadBalancer, habrá un controlador de equilibrio de carga, similar a la función de nginx, y no necesitamos agregarlo a nginx nosotros mismos.

Servicio de equilibrio de carga de capa 4: interpretación de conceptos y principios

¿Por qué tener Servicio?

En kubernetes, los Pods tienen un ciclo de vida y, si un Pod se reinicia, es probable que su IP cambie. Si todos nuestros servicios escriben la dirección IP del Pod hasta el final, el Pod se bloquea o se reinicia, otros servicios asociados con el pod recién reiniciado no podrán encontrar el Pod asociado con él. Para resolver este problema, defina en kubernetes Con el objeto de recurso de servicio, Servicio define una entrada de acceso al servicio, a través de la cual el cliente puede acceder a la instancia del clúster de aplicaciones detrás del servicio. Un servicio es una colección lógica de un grupo de Pods, a los que puede acceder un Servicio, generalmente implementado a través de selectores de etiquetas
Por favor agregue la descripción de la imagen
1. La ip del pod cambia con frecuencia. El servicio es el proxy del pod. Cuando nuestro cliente accede, solo necesitamos acceder al servicio, y la solicitud será enviada al pod.

2. No se puede acceder a la ip del módulo fuera del clúster k8s, por lo que se debe crear un servicio al que se pueda acceder fuera del clúster k8s.

Descripción general del servicio

El servicio es una capa de acceso fijo. El cliente puede acceder al pod de back-end asociado con el servicio accediendo a la ip y al puerto del servicio. El trabajo de este servicio depende de un accesorio implementado en el clúster de kubernetes, que es el servicio de dns de kubernetes. (diferentes servicios de dns de kubernetes). La versión de dns utilizada de forma predeterminada también es diferente. La versión anterior a la 1.11 usa kubeDNS y la versión más nueva usa coredns). La resolución de nombres del servicio depende del archivo adjunto de dns, por lo que debe implementarse después de implementar k8s.dns adjunto, kubernetes necesita depender de complementos de red de terceros (franela, calico, etc.) para proporcionar funciones de red (como asignar ip) a los clientes. Cada nodo de K8s tiene un componente llamado kube-proxy. Este componente de kube-proxy siempre monitoreará la información de cambio sobre los recursos de servicio en el servidor ap. Necesita interactuar con el servidor ap en el maestro y conectarse al servidor ap en cualquier momento para obtener cualquier El estado de cambio de recurso relacionado con los recursos del servicio, que se realiza a través de un método de solicitud de vigilancia (supervisión) inherente a kubernetes. Una vez que el contenido de los recursos del servicio cambia (como creación, eliminación), la operación se almacenará en etcd, y luego programe nuestras solicitudes a las reglas en los recursos de pod específicos de back-end. Esta regla puede ser iptables o ipvs, dependiendo de cómo se implemente el servicio (puede configurar las reglas usted mismo). Por ejemplo, si se crea un nuevo svc, el svc tendrá una ip y el segmento de red de esta ip se configura cuando se crea el clúster (el valor predeterminado es 10).

Cómo funciona el servicio

Cuando k8s crea un Servicio, buscará el Pod de acuerdo con el selector de etiquetas (selector de etiquetas) y creará un objeto de punto final con el mismo nombre que el Servicio en consecuencia. Cuando la dirección del Pod cambie, el punto final también cambiará y el El servicio recibe la solicitud del cliente front-end. Cuando , encontrará la dirección de qué Pod reenviar para acceder a través del punto final. (En cuanto al Pod reenviado a qué nodo, está determinado por el kube-proxy de balanceo de carga)

[root@k8smaster node]# kubectl get endpoints
NAME         ENDPOINTS             AGE
kubernetes   192.168.11.139:6443   15d
[root@k8smaster node]# kubectl get pods -n kube-system -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE     
kube-apiserver-k8smaster            1/1     Running   4          15d   192.168.11.139   k8smaster 
apiserver是绑定了宿主机的网络ip,apiserver这个pod,封装的k8sapiservice服务端口是443,这个service关联的pod是apiserver,ednpoints列表里编写的也是apiserverpod的ip和端口

Hay tres tipos de direcciones IP en un clúster de kubernetes

1、Node Network(节点网络):物理节点或者虚拟节点的网络,如 ens33 接口上的网路地址
[root@k8smaster node]# ip addr
ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 00:0c:29:94:59:0f brd ff:ff:ff:ff:ff:ff
    inet 192.168.11.139/24 brd 192.168.11.255 scope global noprefixroute dynamic ens3

2、Pod network(pod 网络),创建的 Pod 具有的 IP 地址 
[root@k8smaster node]#  kubectl get pods -o wide
NAME                        READY   STATUS    RESTARTS   AGE   IP            NODE       NOMINATED NODE  
frontend-d5tr9              1/1     Running   0          23h   10.244.2.30   k8snode    <none>          
Node Network 和 Pod network 这两种网络地址是我们实实在在配置的,其中节点网络地址是配置在节点接口之上,而 pod 网络地址是配置在 pod 资源之上的,因此这些地址都是配置在某些设备之上的,这些设备可能是硬件,也可能是软件模拟的 
 
3、Cluster Network(集群地址,也称为 service network),这个地址是虚拟的地址(virtual ip),没有配置在某个接口上,只是出现在 service 的规则当中。 
[root@xianchaomaster1 ~]# kubectl get svc 
[root@k8smaster node]# kubectl get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   15d

escribir al final

No es fácil de crear, si crees que el contenido es útil para ti, ¡por favor dame un seguimiento de tres enlaces para apoyarme! Si hay algún error, indíquelo en los comentarios y lo cambiaré a tiempo.
La serie que se está actualizando actualmente: aprende k8s desde cero.
Gracias por mirar. El artículo se mezcla con la comprensión personal. Si hay algún error, comuníquese conmigo e indíquelo ~
inserte la descripción de la imagen aquí

Supongo que te gusta

Origin blog.csdn.net/qq_45400861/article/details/126659678
Recomendado
Clasificación