k8s ~ k8s in service Service

k8s with namespaces namespaceto isolate resources, by default, the same namespace services can communicate with each other, and vice versa isolation.

Services Service

1.1 Service

Kubernetes an application service instances have one or more (Pod, Pod multiple replicas may be established through rs), each instance (Pod) of the IP address assigned by the network a dynamic random plug (Pod restart after IP address change ). These dynamic changes to shield the rear end of an example of load balancing and multi-instance, the introduction of the Service resource object, as follows:

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
  labels:
    app: nginx
spec:
  type: ClusterIP
  ports:
    - port: 80
       targetPort: 80
  selector:  #service通过selector和pod建立关联
    app: nginx

Depending on the type of Service to create the type, can be divided into four modes:

• ClusterIP: Default. Depending on whether generated ClusterIP can be divided into ordinary Service and Headless Service categories:
  • Normal Service: By assigning an internal clusters Kubernetes of Service accessible 固定虚拟IP(Cluster IP), to achieve access to the cluster. It is the most common way.
  • Headless Service: The service does not allocate Cluster IP, nor do the reverse proxy and load balancing kube-proxy. But to provide a stable network ID by DNS to access back-end DNS headless service will be directly resolved to podIP list. The main use for StatefulSet.
• NodePort: In addition to using Cluster IP, but also implemented by the service nodeIP by mapping to the same port one port of each node in the cluster,: nodePort from 集群外访问服service.
• LoadBalancer: NodePort and the like, but in addition to the use of a Cluster IP and nodePort outside, but also to the public cloud is used to apply a load balancer (rear load balancer nodePort mapped to all the nodes), from outside of the cluster is achieved by access LB service.
• ExternalName: Service is a special case. This mode is mainly oriented services running outside the cluster, through which the service may be mapped into the external k8s clusters, and includes a number of features and services within k8s (e.g., namespace includes attributes) to provide services within the cluster. This mode requires kube-dns version 1.7 or above. This model and the former three modes (except headless service) the biggest difference is dependent redirect dns level, rather than kube-proxy.
  For example, the value "my.database.example.com" specified in the service definition externalName:

At this service name in the DNS service will cluster within the cluster k8s . .svc.cluster.local create a CNAME record, specify the value of "my.database.example.com".
When tracking my-service.prod.svc.cluster.local in k8s cluster, the cluster DNS service will return the CNAME record "foo.bar.example.com" map.

Note:
The first three models, defined by specifying the service when the service corresponding pods selector, create the address pods of the endpoints as a back-end service; Endpoints Controller will watch changes in Service and pod, maintenance Endpoint corresponding information. kube-proxy in accordance with Service and Endpoint maintains local routing rules. When Endpoint change, i.e. Service pod and associated changes, kube-proxy iptables updated on each node, to achieve load balancing layer.
ExternalName not specify the mode selector, there is no corresponding port and endpoints.
ExternalName and ClusterIP in Headles Service belong to the two cases Headless Service. Headless Service mainly refers to not assign Service IP, and does not do reverse proxy and load balancing services through kube-proxy.

1.2 Port

Service mainly involves three Port: * portPort herein represent service exposed on clusterIP port clusterIP:Port 是提供给集群内部entrance access kubernetes services.

• TARGETPORT
  containerPort, TARGETPORT is the port on the pod, the incoming data from the port and eventually after nodePort kube-proxy TARGETPORT flows to the rear end of the pod into the container.

• nodePort
  nodeIP: nodePort is provided to the entrance accessible from outside kubernetes cluster service.

Overall, port and nodePort all service ports, former exposed to access from within the cluster service, which is exposed to access from outside the cluster service. These two ports incoming data need to go through the reverse proxy targetPort kube-proxy flowing into the rear end of the pod particular, to enter into the container the pod.

1.3 IP

Use Service service also involves several IP:

• ClusterIP
  Pod IP address is actually present in a network card (can be a virtual device) on, but clusterIP not the same, no network devices carrying this address. It is a virtual address, used by kube-proxy iptables rules to redirect its local port, balanced-to-back again Pod. When kube-proxy discover a new service, it will open a random port on the local node, create the appropriate iptables rules, clusterIP redirection services and port to the new port, began to accept the arrival of the service connection.

• Pod the IP
  Pod of the IP, each Pod starts, it creates a mirror image gcr.io/google_containers/pause container, the internal network mode Pod other container use the container model, and is designated as the container ID pause, i.e.: network_mode : "container: pause container ID", so that all containers within the container pause Pod shared network, via which the communication with the outside of the container proxy, the IP pause container may also be referred Pod IP.

• Node IP
  the Node-IP, Service Objects in Cluster IP range assigned to the pool of IP can only be accessed internally, if the level of service as an internal application, is very appropriate. If this service as a front-end service, ready to provide services to customers outside the cluster, we need to provide this service to the public IP. Specifies the service of spec.type = NodePort, this type of service, the system will assign it a node level on each node in the cluster of proxy port, access to the proxy node clients can access this port, to access to services .