Kubernetes is Google open source container choreographer, very suitable for the current hot micro-service architecture, in the Container choreography field, is gradually building a dominant position. This article mainly aims at the Kubernetes service to do some analysis, first briefly introduces the basic concept.
Basic concepts
The Pod:kubernetes minimum Dispatch unit is a set of containers that can be understood as a container.
Replication controller: Replica controller to ensure that the number of Pod is always consistent with the set value, if you encounter a pod failure, the node is off-line, the controller will remove these abnormal state pod, rescheduling the generation of new pod. By label matching pod, it plays an important role in elastic expansion and rolling upgrade.
Service: Services, is a virtual concept that logically proxies the back-end pod. As we all know, Pod's life cycle is short, the state is unstable, the new pod IP will change after pod anomaly, and the way of pod access is not up to. Through the service to the Pod agent, service has a fixed IP and port,ip:port combination of automatic association back-end pod, even if the pod changes, kubernetes internal Update This group of relationships, so that the service can match to the new pod. In this way, the fixed IP provided by the service, the user no longer care about the need to visit which pod, and whether the pod will change, greatly improve the quality of service. If the pod uses RC to create multiple replicas, then the service can proxy multiple identical pods and achieve load balancing through kube-proxy.
Define a service through the following template, this service agent all has "app": "MyApp" label of pod, service external port is 80, service IP when creating service, also can specify, this set of IP: The port stays fixed during the service life cycle. Traffic to the Ip:port is redirected to the 9376 port on the back-end pod, which is targetport specified.
{"Kind": "Service", "apiversion": "V1", "metadata": {"name": "My-service"}, "spec": {"sel" Ector ": {" app ":" MyApp "}," ports ": [{" Protocol ":" TCP ", "Port": "Targetport": 9376}]}}
When it comes to service, a component that doesn't work is kube-proxy, in fact this component is dedicated to service, and each minion node runs a kube-proxy. Through Kube-proxy, traffic from service to pod forwarding, kube-proxy can also achieve a simple load balancing function. Kube-proxy has a variety of proxy mode, the following is the userspace way, kube-proxy on the Minion node for each service to create a temporary port, the service Ip:port traffic forwarded to this temporary port, Kube-proxy uses an internal load-balancing mechanism (typically a round-finder), selects a back-end pod, and then builds iptables to import traffic into a pod.
Service discovery in the micro-service architecture, services often need to communicate, service discovery is to solve the problem of communication between different services. For example, a nginx pod, to access a MySQL service, you need to know the MySQL service IP port, access to IP and port is the process of service discovery. Kubernetes supports two types of service discovery modes, namely environment variables and DNS.
Environment variables: When the pod is created, the IP and port information of the service is injected into the pod in the form of an environment variable, such as when the pod is created with a redis-master service, The service IP address is 10.0.0.11,port 6379, the following series of environment variables are injected into the pod to access the Redis-master service through these environment variables. Redis_master_service_host=10.0.0.11redis_master_service_port=6379redis_master_port=tcp://10.0.0.11:6379redis_ master_port_6379_tcp=tcp://10.0.0.11:6379redis_master_port_6379_tcp_proto=tcpredis_master_port_6379_tcp_port= 6379redis_master_port_6379_tcp_addr=10.0.0.11
DNS server: A DNS server is built into the kubernetes cluster, and after the service is successfully created, some records are imported into the DNS server to access a service. The corresponding IP and port are resolved through the DNS server to achieve service access.
External services for some front-end applications, you may need to expose the service to the extranet, while the other services run only internally. The types field of the service can specify the types of services, and the default is the Clusterip type. This is the type of service within the cluster, and the service IP is an internal ip;nodeport and LoadBalancer are two types of external service. The
Nodeportnodeport type exposes a port to the service on each Minion node, which can be accessed through node IP and node port, while the service will still have clusterip type of IP and port. The interior is accessed through the Clusterip way, externally through the nodeport way. LoadBalancer If the Kubernetes cluster runs on the third Fang Yunping platform, such as OpenStack, the service can be exposed through an external loadbalancer, and the load balancing mechanism can be used to borrow the third-party load balancing mechanisms. Taking OpenStack as an example, with the help of Neutron's Lbaas, the traffic of the Access service is forwarded directly to the back-end pod, skipping the built-in kube-proxy load balancing.
