Kubernetes的Service运行原理

1、为何Servcie能定位到Pod

由于Pod的IP是不固定的，因此Kubernetes须要Service，除此以外它还能够在多个Pod间负载均衡
Service的访问入口，实际上是宿主机的kube-proxy生成的iptables规则 ，及kube-dns生成的DNS记录

Service经过label标签选中Pod，被选中的的Pod称为Service的Endpoints
示例以下

# kubectl get ep hostnames
NAME ENDPOINTS AGE
hostnames 10.244.0.241:9376,10.244.0.242:9376,10.244.0.243:9376 20m

能够看到，当咱们访问hostnames这个service时，会被定位到10.244.0.241:9376,10.244.0.242:9376,10.244.0.243:9376
注意：只有处于Running状态，且readlinessProbe检查经过的Pod，才会出如今Endpoints列表里

咱们再查看servcie

# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hostnames ClusterIP 10.111.15.33 <none> 80/TCP 23m

service列表的VIP（ClusterIP），是设置了一个固定的入口地址，并无真正的网络设备，ping是没有响应的
经过访问10.111.15.33，就能够访问到它所代理的Pod了
Service的实现原理是由kube-proxy组件，加上iptables来共同实现的，当提交service后，会建立这样一条iptables规则

-A KUBE-SERVICES -d 10.111.15.33/32 -p tcp -m comment --comment "default/hostnames: cluster IP" -m tcp --dport 80 -j KUBE-SVC-NWV5X2332I4OT4T3

iptables规则 的含义是：凡是上的地址是10.111.15.3三、目的端口是80的IP包，都会跳转到KUBE-SVC-NWV5X2332I4OT4T3的iptables链处理
KUBE-SVC-NWV5X2332I4OT4T3是一组集合，以下

-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.33332999982 -j KUBE-SEP-WNBA2IHDGP2BOBGZ
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-X3P2623AGDH6CDF3
-A KUBE-SVC-NWV5X2332I4OT4T3 -m comment --comment "default/hostnames:" -j KUBE-SEP-57KPRZ3JQVENLNBR

这是一组随机模式的iptables链，这三条链是DNAT规则，三条链指向的最终目的地是Service代理的三个Pod
iptables规则的匹配是从上到下逐条进行的，为了让每条几率都相同，probability分别被设置成了1/三、1/2和1

当访问Service的VIP的IP包通过上述iptables处理后，就变成了访问具体某一个后端Pod的IP包了，这些Endpoints对应的规则，是kube-proxy经过监听Pod的变化事件，在宿主机上生成并的维护

2、Servcie在外部访问的三种方式

1. nodePort模式

示例yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  type: NodePort
  ports:
  - nodePort: 8080
    targetPort: 80
    protocol: TCP
    name: http
  - nodePort: 443
    protocol: TCP
    name: https
  selector:
    run: my-nginx

访问方式： <任何一台宿主机的ip地址> :8080

宿主机上没有任何一个代理的Pod存在，不能直接访问经过IP访问Pod，只能由宿主机转发

2.LoadBalancer

示例yaml

kind: Service
apiVersion: v1
metadata:
  name: example-service
spec:
  ports:
  - port: 8765
    targetPort: 9376
  selector:
    app: example
  type: LoadBalancer

K8S使用了一个CloudProvier转接层，跟公有云api对拉，当LoadBalancer的Service被提交后，
K8S会在公有云建立一个负载均衡服务，把代理的Pod地址代理给负载均衡后端

3.ExternalName

示例yaml

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  type: ExternalName
  externalName: my.database.example.com

不须要label选择，至关于在kube-dns里添加了一条CNAME记录
访问my-servcie.default.svc.cluster.locl和访问my.database.example.com同样

另外，还容许配置公有IP地址

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 9376
  externalIPs:
  - 80.11.12.10

3、解决问题思路

1.DNS没法访问Service

在一个 Pod 里执行nslookup排查

$ nslookup kubernetes.default
Server:    10.0.0.10
Address 1: 10.0.0.10 kube-dns.kube-system.svc.cluster.local

Name:      kubernetes.default
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local

2. Service没法经过ClusterIP访问时

检查这个Service的Endpoints

kubectl get endpoints hostnames
NAME        ENDPOINTS
hostnames   10.244.0.5:9376,10.244.0.6:9376,10.244.0.7:9376

若是Pod的readniessProbe没经过，不会出如今Endpoints列表 若是Endpoints正常，再确认kube-proxy和宿主机的iptables是否正常