This article is based on kubernetes 1.5.2 version
Configuration method
When the kubernetes version is greater than or equal to 1.2, the way to access the cluster IP from the external network (that is, the network that is not in the K8S cluster) is to
modify the master's /etc/kubernetes/proxy and change KUBE_PROXY_ARGS="" to KUBE_PROXY_ARGS="--proxy-mode =userspace" to
restart the kube-proxy service
to add a route on the core routing device or the source host, and the route to access the cluster IP segment points to the master.
When the kubernetes version is less than 1.2, add routes directly
Two modes of kube-proxy forwarding
A simple network proxy and load balancer, responsible for the implementation of services, each service will be reflected on all Kube-proxy nodes. Specifically, it realizes internal access from pod to service and external access from node port to service.
kube-proxy mainly has two modes Userspace and Iptables when forwarding.
kuer-proxy currently has two implementations: userspace and iptables.
Userspace (as shown in the figure below) is the proxy service of LB through kuber-proxy in user space. Before the K8S1.2 version, it was the default mode of kube-proxy, and all forwarding was implemented through kube-proxy. This is the initial version of kube-proxy, which is relatively stable, but naturally not very efficient.
Another way is the iptables way (as shown below). It is purely using iptables to implement LB. After the K8S1.2 version, kube-proxy is the default mode. All forwarding is implemented through the Iptables kernel module, and kube-proxy is only responsible for generating the corresponding Iptables rules.
Using Userspace mode (the default mode before k8s version 1.2), the external network can directly access the cluster IP.
Using the Iptables mode (the default mode after the k8s version is 1.2), the external network cannot directly access the cluster IP.
Four ways to forward K8S backend services
ClusterIP
This type will provide a virtual IP within the cluster (not on the same network segment as the Pod) for communication between pods within the cluster. ClusterIP is also the default type of Kubernetes service.
In order to realize the functions on the diagram, the following components are mainly required to work together:
apiserver: When creating a service, the apiserver stores the data in etcd after receiving the request.
kube-proxy: This process exists in each node of k8s and is responsible for implementing the service function. This process is responsible for sensing changes in services and pods, and writing the changed information into the local iptables.
iptables: Use technologies such as NAT to transfer virtualIP traffic to endpoints.
NodePort
In addition to using cluster ip, NodePort mode also maps the port of the service to a specified internal port of each node, and the internal port of each mapped node is the same.
Expose a port for each node, and the service can be accessed through nodeip + nodeport, and the service will still have a cluster-type ip+port. Internal access is through clusterip, and external access is through nodeport.
loadbalance
LoadBalancer is based on NodePort, K8S can request the underlying cloud platform to create a load balancer, and use each Node as a backend for service distribution. This mode requires the support of the underlying cloud platform (eg GCE).
Ingress
Ingress is an HTTP-based routing and forwarding mechanism, which is composed of an Ingress Controller and an HTTP proxy server. The Ingress Controller monitors the Kubernetes API in real time and updates the forwarding rules of the HTTP proxy server in real time. HTTP proxy servers include GCE Load-Balancer, HaProxy, Nginx and other open source solutions.
For details, please see http://blog.csdn.net/liyingke112/article/details/77066814
Three ports of service
port
The port exposed by the service on the cluster ip, :port is the entry provided to the internal customers of the cluster to access the service.
nodePort
nodePort is a way for k8s to provide external clients of the cluster to access the service entry. :nodePort is the entry for external clients to access the service.
targetPort
The targetPort is the port on the pod. The data from port and nodePort finally flows into the targetPort of the backend pod through kube-proxy and enters the container.
port, nodePort summary
In general, port and nodePort are both service ports. The former is exposed to the client access service within the cluster, and the latter is exposed to the client access service outside the cluster. The data coming from these two ports needs to flow into the targetPod of the backend pod through the reverse proxy kube-proxy, so as to reach the container on the pod.