11-k8s-service网络

一、网络相关资源介绍

1. Servcie介绍

   Service是对一组提供相同功能的Pods的抽象，并为它们提供一个统一的入口。借助Service，应用可以方便的实现服务发现与负载均衡，并实现应用的零宕机升级。Service通过标签来选取服务后端，一般配合Replication Controller或者Deployment来保证后端容器的正常运行。这些匹配标签的Pod IP和端口列表组成endpoints，由kubeproxy负责将服务IP负载均衡到这些endpoints上。即service不会直接到pod，service是直接到endpoint资源，就是地址加端口，再由endpoint再关联到pod。

2. Endpoint介绍

   Endpoint主要记录了每个pod的IP地址信息，当Pod的IP发生变化时，endpoints会进行更新。当我们创建Service的时候，会自动生成一个Endpoint。

3. Service的四种类型

   • ClusterIP：默认类型，自动分配一个仅cluster内部可以访问的虚拟IP

   • NodePort：通过每个 Node 上的 IP 和静态端口（NodePort）暴露服务，以便外部可以通过端口访问到该服务。

     如果不指定会随机指定端口，端口范围:30000~32767，端口范围配置在/usr/lib/systemd/system/kube-apiserver.service文件中

   • LoadBalancer：使用云提供商的负载均衡器，可以向外部暴露服务。外部的负载均衡器可以路由到 NodePort 服务和 ClusterIP 服务。

   • ExternalName：将服务通过DNS CNAME记录方式转发到指定的域名（通过 spec.externlName 设定） 。需要kube-dns版本在1.7以上。

4. kube-proxy

   Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则
   

   kube-proxy目前支持三种工作模式:

   • userspace ：userspace模式下，kube-proxy会为每一个Service创建一个监听端口，发向Cluster IP的请求被Iptables规则重定向到kube-proxy监听的端口上，kube-proxy根据LB算法选择一个提供服务的Pod并和其建立链接，以将请求转发到Pod上。 该模式下，kube-proxy充当了一个四层负责均衡器的角色。由于kube-proxy运行在userspace中，在进行转发处理时会增加内核和用户空间之间的数据拷贝，虽然比较稳定，但是效率比较低。
   • iptables：iptables模式下，kube-proxy为service后端的每个Pod创建对应的iptables规则，直接将发向Cluster IP的请求重定向到一个Pod IP。 该模式下kube-proxy不承担四层负责均衡器的角色，只负责创建iptables规则。该模式的优点是较userspace模式效率更高，但不能提供灵活的LB策略，当后端Pod不可用时也无法进行重试。
   • ipvs 模式(推荐)：ipvs模式和iptables类似，kube-proxy监控Pod的变化并创建相应的ipvs规则。ipvs相对iptables转发效率更高。除此以外，ipvs支持更多的LB算法。

二、开启ipvs

ps：master节点操作

1. 查看未开启状态：ipvsadm -Ln
   

2. 在Master节点修改，将mode: " "修改为mode: “ipvs”：kubectl edit -n kube-system cm kube-proxy

3. 查看kube-system命名空间下的kube-proxy：kubectl get pod -n kube-system
   

4. 删除：kubectl get pod -n kube-system |grep kube-proxy |awk ‘{system(“kubectl delete pod “$1” -n kube-system”)}’

5. 删除后，k8s会自动再次生成，新生成的kube-proxy会采用刚刚配置的ipvs模式，再次查看：kubectl get pod -n kube-system

6. 查看启动方式

   kubectl get pod -n kube-system | grep kube-proxy
   kubectl logs -n kube-system kube-proxy-4c5xj
   

7. 再次查看：ipvsadm -Ln
   

三、nginx网络示例

ps：master节点操作

1. 部署：kubectl create deployment nginx --image=nginx

2. 查看状态：watch -n 3 kubectl get pods -A
   

3. 本机访问

   1）查看默认生成的ClusterIP：kubectl get pod -o wide
   
   2）访问：curl 192.169.189.110
   

   3）查看路由：route -n
   

   4）查看192.168.248.12服务器的路由
   

   5）每个节点都会记录相应的CIN生成的IP，并且也会记录对应的源IP作为互联网关口。如上所见，我们在worker2（192.168.248.12）部署了pod，当我们访问189.*的时候，会跳转到worker2（192.168.248.12）网关。所以当我们访问 192.169.189.110时，实际上访问的是192.168.248.12上的nginx。

4. 创建供外部访问的ip和端口（NodePort）：kubectl expose deployment nginx --port=80 --type=NodePort

   ps：在最新的 Kubernetes 版本中，kubectl expose 不再支持 --node-port 参数来指定 NodePort 端口。如果需要指定端口，则需要编写yaml文件生成。

5. 查看端口：kubectl get pods,svc
   

6. 访问nginx页面：http://192.168.248.11:30579
   

四、pod之间的访问示例

1. pod之间的网络访问推荐通过service name进行访问

2. 创建busybox的pod并且进入： kubectl run -it --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh

   ps：busybox是一个聚成了一百多个最常用linux命令和工具的软件工具箱，它在单一的可执行文件中提供了精简的Unix工具集，便于测试。

3. 访问nginx：wget http://nginx
   

4. 跨空间访问其他的service（加上".空间名"）： wget http://nginx.default

五、service反向代理示例

1. 反向代理外部ip：创建service并且自定义endpoints

   1）编写service.yaml：vi /opt/edsvc.yaml

   ps：不指定空间的默认default空间

   apiVersion: v1
   kind: Service 
   metadata:
     name: nginx-svc-external 
     labels:
       app: nginx
   spec:
     ports: 
     - port: 80 
       targetPort: 80
       name: web 
     type: ClusterIP  
   

   解释

   apiVersion: v1
   kind: Service #资源类型为Service
   metadata:
     name: nginx-svc-external # Service 名字
     labels:
       app: nginx # Service 自己本身的标签
   spec:
     ports: #端口映射
     - port: 80 #service自己的端口，在使用内网ip访间时使用
       targetPort: 80 #目标pod的端口
       name: nginx-web #为端口起个名字
     type: ClusterIP  #主随机启动一个瑞口(3080-32767》，映射到ports 中的踏口，该端口是直接掷定在node 上的，且集群中的每一个node都会绑定这个端口
                     #也可以用于将服务暴露给外部访问，但是这种方式实际生产环境不推荐，效率较低，而且 Service 是四层负载
   

   2）编写endpoints.yaml：vi /opt/endpoints.yaml

   apiVersion: v1
   kind: Endpoints
   metadata:
     labels:
       app: nginx 
     name: nginx-svc-external 
     namespace: default 
   subsets:
   - addresses:
     - ip: 120.78.159.117 
     ports:  
     - name: nginx-web
       port: 80
       protocol: TCP
   

   解释

   apiVersion: v1
   kind: Endpoints
   metadata:
     labels:
       app: nginx # 与service一致
     name: nginx-svc-external #与service一致
     namespace: default #与service一致
   subsets:
   - addresses:
     - ip: 120.78.159.117 #目标ip 地址
     ports: #与service一致
     - name: web
       port: 80
       protocol: TCP
   

   3）创建资源

   kubectl apply -f  /opt/edsvc.yaml
   kubectl apply -f  /opt/endpoints.yaml
   

   4）查看代理地址：kubectl get ep
   

   4）测试访问：kubectl run -it --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh --> wget http://nginx-svc-external

   ps：可以看到，路径转发到外网ip去了
   

2. 反向代理外部域名

   1）创建资源：vi /opt/baidusvc.yaml

   apiVersion: v1
   kind: Service
   metadata:
     labels:
       app: wolfcode-external-domain
     name: wolfcode-external-domain
   spec:
     type: ExternalName 
     externalName: www.wolfcode.cn
   

   2）创建资源：kubectl apply -f /opt/baidusvc.yaml

   3）查看svc：kubectl get svc
   

   4）测试访问：kubectl run -it --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh --> wget wolfcode-external-domain