After a lapse of years, and began to play csdn.
the service in k8s is a virtual concept, completely by Kube-proxy implementation
for each service you create, you need to define three variables: Clusterip port targetport nodeport
which
Clusterip + port is used for internal pod Access service and is then assigned
Targetport is the port of the container.
Nodeport is the back-end pod for the external Access service, and can be accessed by any node-nodeport;
Userspace mode:
when creating a service:
1 api-server Create service object, and service-bound pod address: called Endpoints
2 the Kube-proxy on each node gets the service from Api-server and creates a tcpsocketserver_for_servicea that uses the immediate port
3) Tcpsocketserver_for_servicea, real-time from the Apiservice, get endpoint updates, any access to the service will be forwarded to the back-end pod;
when accessing a service:
Internal POD Access cluster: Automatically created good iptables rules by Kube-proxy, redirected to Tcpsocketserver_for_servicea, forwarded to back-end pod via round algorithm
External Access nodeip+ Nodeport: Automatically be kube-proxy automatically create a good iptables rule, redirect to Tcpsocketserver_for_servicea, which is forwarded to the back-end pod via the round algorithm
$ sudo iptables-s-t nat ...
-a kube-nodeport-container-p tcp-m comment--comment "Default/ssh-service1:"-M TCP--dport 30239-j REDIRECT--to-ports 36463
-A kube-nodeport-host-p tcp-m Comment--comment "Default/ssh-service1:"-M TCP--dport 30239-j dnat--to-des Tination 10.0.0.5:36463
-A kube-portals-container-d 10.254.132.107/32-p tcp-m comment--comment "default/ Ssh-service1: "-M TCP--dport 2222-j REDIRECT--to-ports 36463
-A kube-portals-host-d 10.254.132.107/32-p TCP-M Co Mment--comment "Default/ssh-service1:"-M TCP--dport 2222-j dnat--to-destination 10.0.0.5:36463
iptables mode: when creating a service:
Kuberpeoxy creates a good iptables rule on each node
when accessing a service:
Directly redirected by iptables rules (iptables probability can achieve balance)