Introduction to this article
1. Detailed explanation and basic usage of Service
1. Definition of Service
Service is one of the core concepts of Kubernetes. Creating a Service can provide a unified entry address for a group of container applications with the same function, and distribute the request load to each container application in the backend.
The complete service definition file in yaml format is as follows:
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. Basic usage of Service
In general, applications that provide services to the outside need to be implemented through some mechanism. For container applications, the easiest way is to implement it through the TCP/UDP mechanism and listening on the IP port number.
The following case: Create a Service with basic functions;
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
Then use the kubectl get pods -l app=mywebapp -o yaml | grep podIPcommand to get the IP address and port number of the Pod, and finally use curl podIP:8080to access the Tomcat service.
But you must know that it is unreliable to access application services directly through the Pod IP and port number, because if the Node where the Pod is located fails, the Pod will be rescheduled to another Node by Kubenetes, which will cause the Pod address to occur. Change.
In order to avoid this problem, we can first configure a yaml file to define the Service, and then create it through kubectl create, so that we can access the backend Pod through the address of the Service.
The following case: first vimdefine a Service yaml file;
apiVersion: v1
kind: Service
metadata:
name: mywebapp-svc
spec:
ports:
- port: 8081
targetPort: 8080
selector:
app: mywebapp
Then kubectl get svcget ;
Finally use the command curl IP:8081to access the Pod.
Here I use the 8081 port number because we use 8081 to map 8080 in the file that defines the service.
3. Multi-port Service
Sometimes a container application may also need to provide services with multiple ports, so in the definition of Service, it can be set to multiple ports corresponding to multiple application services. The format is as follows:
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. External service Service
In some special service environments, the application system needs to connect an external database as a backend service, or use a service in another cluster as the backend of the service, which can be achieved by creating 无Label Selectora Service. The format is as follows:
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
It can be seen that the difference between a service without a Label Selector and a normal service is that it does not have a selector label to specify the Label, but needs to create a Endpointsspecified 同名metadata to map to the Pod you want to access.
2. The meaning of the existence of Service
1. Prevent Pod from being disconnected (service discovery)
Usually a website consists of two parts: front-end and back-end, and back-end services are accessed through operations on the front-end pages. For example, there are three Pods in the front-end and three Pods in the back-end, so this access process also enters the back-end Pod through the front-end Pod. The most common way is to access through the Pod's IP address.
However, the IP address of the Pod is not fixed. For example, if an upgrade rollback or update is performed, the IP address will change. When a Pod is accessed, and the Pod is accessed again after a few minutes, the IP does not exist due to some operations, which is called Pod disconnection.
And Service just solves this problem. The specific implementation method is that each Pod uses its own IP and name to make a "registration" in the Service (registration center) before operation. When accessing, first go to the Service to find the registration use the IP, and then visit again. If the IP of a Pod is changed, the service IP change will be notified as soon as possible, so that other services will use the new IP when accessing again.
2. Define a set of Pod access policies (load balancing)
If a Pod in the front end accesses the back end, and there are several Pods in the back end, then which Pod is accessed becomes a problem. At this time, Service is required to play a role, which enables access requests to be evenly distributed to different Pods, that is, implementation 负载均衡. The allocation rules can be based on 响应时间, 并发量allocated or allocated according to 空闲时间, etc. , which also implements the definition of Pod access policies.
3. Relationship between Pod and Service
First, Pod and Service are also linked through Label and selector labels, as follows.
#service中
selector:
app: redis
#pod中
labels:
app: redis
Second, Pod's service discovery and load balancing are implemented through Services.
Four, three common types of Service
- ClusterIP: Usually used inside the cluster.
- NodePort: used when accessing applications externally.
- LoadBalancer: Used when accessing applications externally, and can also be used in public cloud environments.