[Kubernetes nativo en la nube] Tecnología central de kubernetes - Servicio


inserte la descripción de la imagen aquí


1. Explicación detallada y uso básico del Servicio

1. Definición de Servicio

El servicio es uno de los conceptos centrales de Kubernetes. La creación de un servicio puede proporcionar una dirección de entrada unificada para un grupo de aplicaciones de contenedor con la misma función y distribuir la carga de solicitudes a cada aplicación de contenedor en el backend.

El archivo de definición de servicio completo en formato yaml es el siguiente:

apiVersion: v1                    #版本号
kind: Service 
metadata:                         #元数据
    name: string                  #Service名称
    namespace: string             #命名空间,默认为default
    labels:                       #自定义标签属性列表
        - name: string
    annotations:                  #自定义注解属性列表
        - name: string
spec:                             #详细描述
    selector: []                  #Label Selector配置
    type: string                  #Service的类型
    clusterIP: string             #虚拟服务的IP地址
    sessionAffinity: string       #是否支持Session
    ports:                        #Service需要暴露的端口列表
    - name: string                #端口名称
        protocol: string          #端口协议,支持TCP/UDP,默认TCP
        port: int                 #服务监听的端口号
        targetPort: int           #需要转发到后端Pod的端口号
        nodePort: int
    status:
        loadBalancer:             #外部负载均衡器
            ingress:
                ip: string 	      #外部负载均衡器IP地址
                hostname: string  #主机名

2. Uso básico del Servicio

En general, las aplicaciones que brindan servicios al exterior deben implementarse a través de algún mecanismo. Para las aplicaciones de contenedor, la forma más sencilla es implementarlo a través del mecanismo TCP/UDP y escuchar en el número de puerto IP.

El siguiente caso: Crear un Servicio con funciones básicas;

apiVersion: v1
kind: ReplicationController
metadata:
    name: mywebapp
spec:
	replicas: 2
	template:
	  metadata: 
	    name: mywebapp
	    labels:
	      app: mywebapp
	  spec:
	    containers:
	    - name: mywebapp
	    image: tomcat
	    ports:
	    - containerPort: 8080

Luego use el kubectl get pods -l app=mywebapp -o yaml | grep podIPcomando para obtener la dirección IP y el número de puerto del Pod, y finalmente use curl podIP:8080para acceder al servicio Tomcat.

Pero debe saber que no es confiable acceder a los servicios de la aplicación directamente a través de la IP del Pod y el número de puerto, ya que si el Nodo donde se encuentra el Pod falla, Kubenetes reprogramará el Pod a otro Nodo, lo que hará que la dirección del Pod cambie. ocurrir Cambiar.

Para evitar este problema, primero podemos configurar un archivo yaml para definir el Servicio y luego crearlo a través de kubectl create, de modo que podamos acceder al Pod de backend a través de la dirección del Servicio.

El siguiente caso: primero vimdefina un archivo Service yaml;

apiVersion: v1
kind: Service
metadata:
  name: mywebapp-svc
spec:
  ports:
  - port: 8081
    targetPort: 8080
  selector:
    app: mywebapp

Luego kubectl get svcobtenga ;

Finalmente use el comando curl IP:8081para acceder al Pod.

Aquí uso el número de puerto 8081 porque usamos 8081 para mapear 8080 en el archivo que define el servicio.

3. Servicio multipuerto

A veces, una aplicación de contenedor también puede necesitar proporcionar servicios con múltiples puertos, por lo que en la definición de Servicio, se puede establecer en múltiples puertos correspondientes a múltiples servicios de aplicación. El formato es el siguiente:

apiVersion: v1
kind: Service
metadata:
  name: mywebappService
spec:
  ports:
  - port: 8080
    targetPort: 8080
    name: web
  - port: 8005
    targetPort: 8005
    name: management
  selector:
    app: mywebapp

4. Servicio de servicio externo

En algunos entornos de servicios especiales, el sistema de la aplicación necesita conectarse a una base de datos externa como un servicio de back-end, o usar un servicio en otro clúster como el back-end del servicio, lo que se puede lograr creando 无Label Selectorun Servicio. El formato es el siguiente:

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80 
-----------------------
apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
- addresses:
  - IP: 目标pod IP
  ports: 
    port: 8080

Se puede ver que la diferencia entre un servicio sin Selector de etiquetas y un servicio normal es que no tiene una etiqueta de selector para especificar la Etiqueta, pero necesita Endpointscrear 同名metadatos específicos para mapear al Pod al que desea acceder.

2. El significado de la existencia del Servicio

1. Evitar que Pod se desconecte (detección de servicios)

Por lo general, un sitio web consta de dos partes: front-end y back-end, y se accede a los servicios de back-end a través de operaciones en las páginas de front-end. Por ejemplo, hay tres Pods en el front-end y tres Pods en el back-end, por lo que este proceso de acceso también ingresa al Pod del back-end a través del Pod del front-end, la forma más común es acceder a través de la IP del Pod. Dirección.

Sin embargo, la dirección IP del Pod no es fija. Por ejemplo, si se realiza una actualización o reversión de actualización, la dirección IP cambiará. Cuando se accede a un Pod y se vuelve a acceder al Pod después de unos minutos, la IP no existe debido a algunas operaciones, lo que se denomina desconexión del Pod.

Y el Servicio simplemente resuelve este problema. El método de implementación específico es que cada Pod usa su propia IP y nombre para hacer un "registro" en el Servicio (centro de registro) antes de la operación. Al acceder, primero vaya al Servicio para encontrar el uso del registro la IP, y luego vuelva a visitarla. Si se cambia la IP de un Pod, el cambio de IP del servicio será notificado lo antes posible, para que otros servicios utilicen la nueva IP al acceder nuevamente.

2. Definir un conjunto de políticas de acceso al Pod (equilibrio de carga)

Si un Pod en el front-end accede al back-end, y hay varios Pods en el back-end, entonces el Pod al que se accede se convierte en un problema. En este momento, se requiere que el Servicio desempeñe un papel, lo que permite que las solicitudes de acceso se distribuyan uniformemente a diferentes Pods, es decir, la implementación 负载均衡. Las reglas de asignación pueden basarse en 响应时间, 并发量asignarse o asignarse según 空闲时间, etc. , lo que también implementa la definición de políticas de acceso de Pod.

3. Relación entre Pod y Servicio

En primer lugar, el pod y el servicio también están vinculados a través de etiquetas de etiquetas y selectores, de la siguiente manera.

#service中
selector:
  app: redis

#pod中
labels:
  app: redis

En segundo lugar, el equilibrio de carga y el descubrimiento de servicios de Pod se implementan a través de Servicios.

Cuatro, tres tipos comunes de Servicio

  • ClusterIP: generalmente se usa dentro del clúster.
  • NodePort: se utiliza al acceder a aplicaciones de forma externa.
  • LoadBalancer: se utiliza al acceder a aplicaciones de forma externa y también se puede utilizar en entornos de nube pública.

Supongo que te gusta

Origin blog.csdn.net/weixin_53072519/article/details/126608253
Recomendado
Clasificación