目录

kube-proxy会一直watch api-service关于service的变动, 只要有变化就会生成可以调度到后端pod的iptables或者ipvs规则

问题

==访问k8s集群中的pod， 客户端需要知道pod地址，需要感知pod的状态。那如何获取各个pod的地址？若某一node上的pod故障，客户端如何感知？==

解决方案: service

什么是service?

通过selector发现后端发现具有同一label的pod;

为这些pod提供统一的入口地址;

将请求进行负载分发到后端的各个容器应用上的控制器;

service类型

1. ClusterIP:

   提供一个集群内部的虚拟IP以供Pod访问

   

   apiVersion: v1kind: Servicemetadata:    name: redis    namespace: defaultspec:    selector:        app: redis        role: logstor    clusterIP: 10.97.97.97    type: ClusterIP    ports:    - port: 6379      targetPort: 6379

2. NodePort:

   用来对集群外暴露service, 你可以通过访问集群内的每个NodeIP:NodePort的方式访问到对应的service后端的Endpoint

   

   apiVersion: v1 kind: Service metadata:     name: myapp     namespace: default spec:     selector:         app: myapp         release: canary     clusterIP: 10.99.99.99     type: NodePort     ports:     - port: 80       targetPort: 80       #nodePort: 30080 nodePort可以自己指定, 如果没有指定, k8s会自动生成一个端口, 指定的好处是便于记忆, 坏处是容易冲突

   kubectl patch svc myapp -p '{"spec":{"sessionAffinity":"ClientIP"}}' #会话亲和性，同一个client的访问调度到同一个podkubectl patch svc myapp -p '{"spec":{"sessionAffinity":"None"}}'

3. ExternalName

   是 Service 的特例。此模式主要面向运行在集群外部的服务，通过它可以将外部服务映射进k8s集群，且具备k8s内服务的一些特征（如具备namespace等属性），来为集群内部提供服务。此模式要求kube-dns的版本为1.7或以上。这种模式和前三种模式（除headless service）最大的不同是重定向依赖的是dns层次，而不是通过kube-proxy。

4. LoadBalancer

   这是将k8s集群部署在公有云上的一种service类型, 会调用公有云loadbalance接口

5. Headless

   Headless Service也是一种Service，但不同的是会定义spec:clusterIP: None，也就是不需要Cluster IP的Service。

   apiVersion: v1kind: Servicemetadata:    name: myapp-headless    namespace: defaultspec:    selector:        app: myapp        release: canary    clusterIP: None    ports:    - port: 80      targetPort: 80

   • headless直接解析到podIP

     [root@master manifest]# dig -t A myapp-headless.default.svc.cluster.local @10.96.0.10

     ; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.2 <<>> -t A myapp-headless.default.svc.cluster.local @10.96.0.10

     ;; global options: +cmd

     ;; Got answer:

     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64730

     ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

     ;; WARNING: recursion requested but not available

     ;; OPT PSEUDOSECTION:

     ; EDNS: version: 0, flags:; udp: 4096

     ;; QUESTION SECTION:

     ;myapp-headless.default.svc.cluster.local. IN A

     ;; ANSWER SECTION:

     ==myapp-headless.default.svc.cluster.local. 30 IN A 10.244.2.9==

     ==myapp-headless.default.svc.cluster.local. 30 IN A 10.244.1.10==

     ;; Query time: 22 msec

     ;; SERVER: 10.96.0.10#53(10.96.0.10)

     ;; WHEN: Mon Sep 02 22:06:19 CST 2019

     ;; MSG SIZE rcvd: 181

   • 普通的svc则解析到service的clusterIP

     [root@master manifest]# dig -t A myapp.default.svc.cluster.local @10.96.0.10

     ; <<>> DiG 9.9.4-RedHat-9.9.4-74.el7_6.2 <<>> -t A myapp.default.svc.cluster.local @10.96.0.10

     ;; global options: +cmd

     ;; Got answer:

     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6282

     ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

     ;; WARNING: recursion requested but not available

     ;; OPT PSEUDOSECTION:

     ; EDNS: version: 0, flags:; udp: 4096

     ;; QUESTION SECTION:

     ;myapp.default.svc.cluster.local. IN A

     ;; ANSWER SECTION:

     ==myapp.default.svc.cluster.local. 30 IN A 10.99.99.99==

     ;; Query time: 1 msec

     ;; SERVER: 10.96.0.10#53(10.96.0.10)

     ;; WHEN: Mon Sep 02 22:06:41 CST 2019

     ;; MSG SIZE rcvd: 107