The content of this article has been validated based on k8s v1.8.8. K8s Service defines the access entry address of a server, the front-end application accesses a cluster of pod replicas behind it through this entry address, and the access requests from outside are load balanced to each container application on the back end. Between the service and the back-end pod replica cluster, the docking is done through the label selector. The function of RC is to ensure service ability and service quality is always in the expected standard. A Service definition can request Apiserver to create a new instance based on the POST method. A Service is a REST object in the Kubernetes. This paper gives a detailed description of service usage, including load balancing of service, extranet access, establishment of DNS service, INGRESS7 layer routing mechanism and so on.
1, service definition detailed
full content of service definition file in 1.1 yaml formatAPIVERSION:V1 Kind:service matadata:name:string namespace:string Labels:-name:string annotations:-NA Me:string spec:selector: [] type:string clusterip:string sessionaffinity:string ports:-name:string Protocol:string port:int targetport:int nodeport:int status:loadbalancer:ingress:i P:string hostname:string
1.2 Description Table of each attribute in the service definition file
| Property name |
value type |
Whether you must select |
Value Description |
| Version |
String |
Required |
V1 |
| Kind |
String |
Required |
Service |
| Metadata |
Object |
Required |
Meta data |
| Metadata.name |
String |
Required |
Service Name |
| Metadata.namespace |
String |
Required |
namespace, default defaults |
| Metadata.labels[] |
List |
|
Custom Label Properties List |
| Metadata.annotation[] |
List |
|
Custom annotation Attributes List |
| Spec |
Object |
Required |
Detailed description |
| Spec.selector[] |
List |
Required |
Label selector configuration, which will select the pod with the specified label label as the administrative scope |
| Spec.type |
String |
Required |
The type of service that specifies how the service is accessed, and the default value is Clusterip. The value range is as follows: Clusterip: The IP of the virtual service, which is used for pod access within the k8s cluster, and is forwarded kube-proxy through the set Iptables rules on node. Nodeport: Use the host port to access the service through node's IP address and port via an external client that has access to each node. LoadBalancer: Using an external load balancer to perform load distribution to the service, you need to specify the IP address of the external load balancer in the Spec.status.loadBalancer field, and define both Nodeport and Clusterip for the public cloud environment. |
| Spec.clusterip |
String |
|
The IP address of the virtual service, if not specified when Type=clusterip, the system is automatically allocated. can also be specified manually. When Type=loadbalancer, you need to specify. |
| Spec.sessionaffinity |
String |
|
If session is supported, the optional value is ClientIP, which means that client access requests for the same source IP address are forwarded to the same back-end pod. The default value is null. |
| Spec.ports[] |
List |
|
List of ports that the service needs to expose |
| Spec.ports[].name |
String |
|
Port Name |
| Spec.ports[].protocol |
String |
|
Port protocol, TCP and UDP support, default value is TCP |
| Spec.ports[].port |
Int |
|
Port number on which the service listens |
| Spec.ports[].targetport |
Int |
|
Port number that needs to be forwarded to the back-end pod |
| Spec.ports[].nodeport |
Int |
|
Specifies the port number to be mapped to the physical machine when Spec.type=nodeport |
| Status |
Object |
|
When Spec.type=loadbalancer, set the address of the external load balancer for the public cloud environment |
| Status.loadbalancer |
Object |
|
External Load Balancer |
| Status.loadBalancer.ingress |
Object |
|
External Load Balancer |
| Status.loadBalancer.ingress.ip |
String |
|
IP address of external load balancer |
| Status.loadBalancer.ingress.hostname |
String |
|
Host name of external load balancer |
2. Service,rc,pod Architecture Hierarchy Relationship
3, VIP and Service agentThe kube-proxy process running on each node is actually an intelligent software load balancer that forwards requests for service to one of the pod instances on the back end and implements the load balancing of services within the session retention mechanism. Service is not a shared load balancer IP, but is assigned a globally unique virtual IP address, called cluster IP. Its cluster IP does not change throughout the service lifecycle. Kube-proxy is responsible for the implementation of a VIP (virtual IP) in the form of Service, rather than the form of externalname. The default is to use userspace to provide the VIP agent service before the K8s v1.2 version, and the v1.2 proxy is used by default from Kubernetes iptables.
Iptables proxy mode, Kube-proxy monitors kubernetes Master's addition and removal of Service objects and endpoints objects. For each Service, it creates a related iptables rule to capture a request to the Clusterip (virtual IP) and port of the service, which in turn redirects the request to one of the service's set of backend. For each endpoints object, it also creates a iptables rule, which selects a backend Pod. The default policy is to randomly select a backend. To implement session affinity based on client IP, you can set the value of Service.spec.sessionAffinity to "ClientIP" (The default is "None"). Similar to the userspace proxy, the result of the network return is that any request to the ip:port that arrives at the Service is delegated to a suitable backend, and no client is required to know anything about kubernetes, Service, or Pod. This should be faster and more reliable than the userspace agent. However, unlike the userspace agent, if the initial selected pod is not responding, the iptables agent can automatically retry another pod, so it needs to rely on readiness probes.
4, Publishing Service--type typeFor some applications, the Service is expected to be exposed via an external (kubernetes cluster external) IP address. Kubernetes Servicetypes allows you to specify a required type of Service, which defaults to the Clusterip type. The value of Type and the behavior are as follows: Clusterip: Through the cluster's internal IP exposure service, select this value, the service can only be accessed within the cluster, which is also the default servicetype. Nodeport: Exposes services through the IP and static ports (Nodeport) on each Node. The Nodeport service is routed to the Clusterip service, which is created automatically by the Clusterip service. By requesting <NODEIP>:<NODEPORT>, you can access a Nodeport service from outside the cluster. LoadBalancer: Using a cloud provider's load board, you can expose services to the outside. External load balancers can be routed to the Nodeport service and the Clusterip service. Externalname: By returning CNAME and its values, you can map the service to the contents of the Externalname field (for example, foo.bar.example.com). No type of proxy is created, which is supported only by Kubernetes 1.7 or later kube-dns.
There are 3 kinds of IP addresses in k8s: node Ip:node nodes IP address, this is the IP address of the physical network card of each node in the cluster, the IP address of Pod Ip:pod, this is Docker engine according to the IP address segment of DOCKER0 Network Bridge, is usually a virtual two-layer network; Cluster ip:service IP address, which is also a virtual IP, but it is more like a "fake" IP address, because it does not have an entity network object, so can not respond to the ping command. It can only combine service port to form a specific communication service ports, the individual cluster IP does not have the basis of TCP/IP communication. Within the k8s cluster, the communication between Node IP network, Pod IP network and cluster IP network is a special routing rule designed by k8s itself, different from the common IP routing implementation.
5, Service discovery The Kubernetes supports 2 basic service discovery modes-environment variables and DNS. Environment variables when Pod runs on Node , Kubelet adds a set of environment variables for each active Service . It also supports docker links compatibility variables, simple {SVCNAME}_SERVICE_HOST and {SVCNAME}_SERVICE_PORT variables, here The Service name needs to be capitalized and the horizontal line is converted to an underscore. For example, a service called "Redis-master" exposes TCP Port 6379 and assigns it a Cluster IP address 10.0.0.11, which generates the following environment variables: redis_ master_service_host=10.0.0.11 redis_master_service_port=6379 redis_master_port=tcp://10.0.0.11:6379 REDIS_MASTER_ port_6379_tcp=tcp://10.0.0.11:6379 redis_master_port_6379_tcp_proto=tcp redis_master_port_6379_tcp_port=6379 redis_master_port_6379_tcp_addr=10.0.0.11 This means that there is a need for sequential requirements -- Pod any Service you want to access must be Pod are created before, otherwise these environment variables will not be assigned values. DNS does not have this restriction. DNS A strongly recommended cluster plug-in is a DNS server. The DNS server monitors the creation of a new Service kubernetes API to create a set of DNS records for each Service . If the entire cluster's DNS has been enabled, then all Pod should be able to automatically name-resolve Service . For example, there is a name called "My-service" service, which in the Kubernetes cluster named "My-ns" Namespace , created a section for "My-service.my-ns" DNS Records. Pod in the Namespace named "My-ns" should be able to simply find the "My-service" by name query. Pod in another Namespace must be qualified with the name "My-service.my-ns". The result of these name queries is Cluster IP. Kubernetes also supports DNS SRV (Service) records for port names. If the name is called "My-service.my-ns" Service has a port named "http" TCP , it can be used for "_ Http._tcp.my-service.my-ns " performs DNS SRV queries and obtains the port number of " http " . The Kubernetes DNS server is the only way to access the ExternalName type of Service. For more information, DNS Pod and Service can be viewed. Kubernetes from version 1.3, DNS is a built-in service that is automatically started through the Plug-in manager cluster plug-in. Kubernetes DNS Dispatches DNS pods and Service in the cluster, configuring Kubelet to notify individual containers to use DNS service IP resolution DNS names.
6, the basic usage of serviceIn general, external service delivery applications need some mechanism to implement, the easiest way for container applications is through the TCP/IP mechanism and the listening IP and port number to achieve. Create a basic function service (1) For example, we define an RC that provides a Web service, consisting of two Tomcat container replicas, each of which provides a service number through the Containerport setting 8080:webapp-rc.yaml Apiversion:v1 Kind:replicationcontroller Metadata:name:webapp spec:replicas:2 Template:metadata:na Me:webapp Labels:app:webapp spec:containers:-Name:webapp Image:tomcat Ports:-containerport:8080 Create this RC: #kubectl create-f webapp-rc.yaml Obtain the IP address of the pod: #kubectl get pods-l app=webap P-o Yaml|grep Podip podip:172.17.0.2
