云原生环境网络方案2 --- Service和Service Mesh

在之前的文章中，我们描述了容器环境的底层网络实现原理以及一些常见的k8s网络插件。这些组件利用Linux系统的内核网络协议栈完成容器与容器之间网络互连的工作。到了这一步，我们仅仅解决了容器与容器之间互连，在微服务架构中，网络层面的互连仅仅是基础，我们还需要从网络层面解决：服务发现，负载均衡，访问控制，服务监控，端到端加密等问题。

本文的目的在于描述基于Service的k8s网络的原理，首先，我们需要了解以下概念：

• Pod & Deployment & EndPoints
• Service
  • ClusterIP
  • Headless
  • NodePort
  • LoadBalancer
  • ExternalName
• Ingress
• ServiceMesh

Pod

Pod是K8S的基本调度单位，我们可以理解其为一组共享命名空间的容器，这一组容器共享PID，IPC，网络，存储，UTC命名空间，相互之间可以通过localhost访问，访问相同的文件等。每个Pod中的容器会共用一个IP地址，该IP地址由K8S底层的网络方案决定如何分配。

一般来说，Pod不会被单独使用，一般会通过Deployment对象进行编排，以实现：

• 定制Pod的版本，副本数
• 通过k8s状态控制器恢复失败的Pod
• 通过控制器完成指定的策略控制，如滚动更新，重新生成，回滚等

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-nginx
spec:
  selector:
    matchLabels:
      run: my-nginx
  replicas: 2
  template:
    metadata:
      labels:
        run: my-nginx
    spec:
      containers:
      - name: my-nginx
        image: nginx
        ports:
        - containerPort: 80

上面是官网上的一个deployment的例子，其中可以看到，其设置了一个名为my-nginx的deployment，副本数为2，其模板是一个名为my-nginx的pod。

k8s-Service.png

这里其实隐含了一个EndPoint对象，在k8s中我们一般不会直接与EndPoint对象打交道。EndPoint代表的是一组可供访问的Pod对象，在创建deployment的过程中，后台会自动创建EndPoint对象。kube-proxy会监控Service和Pod的变化，创建相关的iptables规则从网络层对数据包以路由的方式做负载均衡。

Service

Pod是可变且易变，如果像传统的开发中使用IP地址来标识是不靠谱的，需要一个稳定的访问地址来访问Pod的实例，在K8S中使用Service对象来实现这一点。服务与服务之间的访问，会通过服务名进行。通过配置Service对象，K8S会在内部DNS系统（默认coreDNS）中添加相关的PTR与反向PTR。在集群内部任何地方，可以通过服务名来访问相关的服务。

apiVersion: v1
kind: Service
metadata:
  name: my-nginx
  labels:
    run: my-nginx
spec:
  ports:
  - port: 80
    protocol: TCP
  selector:
    run: my-nginx

以上的yaml文件创建了一个名为my-nginx的service，关联到之前创建的名为my-nginx的pod组。

$ kubectl get svc my-nginx
NAME       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)   AGE
my-nginx   ClusterIP   10.0.162.149   <none>        80/TCP    21s

$ kubectl describe svc my-nginx
Name:                my-nginx
Namespace:           default
Labels:              run=my-nginx
Annotations:         <none>
Selector:            run=my-nginx
Type:                ClusterIP
IP:                  10.0.162.149
Port:                <unset> 80/TCP
Endpoints:           10.244.2.5:80,10.244.3.4:80
Session Affinity:    None
Events:              <none>

以上例子创建了一个ClusterIP类型的Service，这是Service的默认类型，ClusterIP是一个虚拟IP，kube-proxy在系统层面以iptables 路由规则或者LVS的形式，将访问发送给后端的pod。在K8S环境中，也是可以显示指定不生产ClusterIP，这种情况被称为Headless Service。Service共有有5种类型：

• Headless
• ClusterIP
• NodePort
• LoadBalance
• ExternalService

ClusterIP的原理上面已经大致提过。Headless Service就是上面提到的不设置ClusterIP的情况。在配置ClusterIP的情况下，CoreDNS中的记录的Service名指向的是ClusterIP，而在不设置ClusterIP的情况下，CoreDNS中的Service名会直接指向多个后台Pod的地址。

其中，NodePort是在将某Service暴露到集群外部的情况下使用。在设置Service类型为NodePort的情况下，会在每个Node上设置NAT规则暴露服务。如下图所示：

k8s-NodePort.png

集群的80端口被映射为ServiceA，那么集群的两个对外IP：222.111.98.2和222.111.98.3的80端口都可以开启，可以通过这两个IP：port在集群外访问ServiceA。

apiVersion: v1
kind: Service
metadata:
  name: ServiceA
spec:
  ports:
  - port: 3000
    protocol: TCP
    targetPort: 443
    nodePort: 80
  selector:
    run: PodA
  type: NodePort

同时，节点也有内部节点，内部的Pod可以从内部节点的80端口来访问ServiceA。

LoadBalancer指的是外部的Loadbalancer，即云平台提供者的集群外部负载均衡服务。除了NodePort所做的事情之外，LoadBalancer对象会将集群所有对外接口的IP地址提供给外部Loadbalancer服务。

k8s-LoadBalancer.png

还有一个是ExternalName，主要用来让内部POD访问外部服务。

apiVersion: v1
kind: Service
metadata:
  name: External-ElasticSearch
  namespace: prod
spec:
  type: ExternalName
  externalName: my.elasticsearch.org:9200

上面是官方文档中的一个例子，该例子里面，将一个外部的服务 my.database.example.com映射为一个内部的服务名my-service，内部POD可以用my-service来访问该外部服务。

k8s-External Service.png

通过External-Service，我们可以把一些有状态的资源如各类数据库进行外置，集群内部的各Pod可以通过其进行访问。

Ingress

以上NodePort以及LoadBalancer实现的是从外部对机器内部进行L4网络访问。在公有云环境中，LoadBalancer需要配合云服务提供商的负载均衡器使用，每个暴露出去的服务需要搭配一个负载均衡器，代价比较昂贵。那有没有比较便宜一些的解决方案呢？答案是Ingress对象。在集群内部搭建Ingress服务，提供反向代理能力，实现负载均衡能力，一方面对基于http的流量可以进行更细粒度的控制，此外，不需要额外的LoadBalancer设备的费用。Ingress对象需要配合Ingress controller来进行使用。

从使用方面来讲，Ingress对象是集群级别的metadata，其定义了路由规则，证书等Ingress Controller所需的参数。Ingress Controller是实际执行这些参数的实例。从面向对象的角度来说，Ingress是接口，Ingress Controller是其对应的实现。接口只有一个，实现可以有很多。实际上来讲，Ingress Controller的实现有很多，比如Nginx Ingress，Traefik，envoy等。集群内可能存在多个Ingress对象和Ingress Controller，Ingress对象可以指定使用某个Ingress Controller。

从功能上来看，Ingress一般会具有以下能力：对外提供访问入口，TLS卸载，http路由，负载均衡，身份认证，限流等，这些基本上都是针对http协议提供的。这些能力会通过Ingress Controller提供。

Ingress Controller需要部署为Service或者DaemonSet，一般来说有三种部署方式：

1. 以Deployment方式部署为LoadBalancer类型的Service，一般在公有云场景下使用，相应云服务商会提供外置的LoadBalancer将流量分发到Ingress Controller的地址上。
2. 以Deployment方式部署为NodePort类型的Service，这种情况下会在所有节点上打开相应端口，这种情况，外部访问会比较麻烦，一般来说需要外置一个Ngnix或者其他类型的负载均衡器来分发请求，这样其实就变得和情况1类似，但是可能会更麻烦。
3. 以DaemonSet的形式部署在指定的几个对外节点上。在部署过程中，可以给边缘节点打上相应的tag，在配置是使用NodeSelector来指定边缘节点，在每个边缘节点上部署Ingress Controller。外界可以通过这些边缘节点上的Ingress Controller来访问集群内部的服务。

总体而言，Ingress的作用是对外部访问进行细粒度的网络控制。目前市面上有几种产品形态，如API Gateway以及ServiceMesh Gateway都可以在这个生态位工作。

ServiceMesh

在原生k8s环境中，kube-proxy组件会通过watch-list接口观察Service和EndPoints的变化，动态调整iptables/LVS规则，实现端到端的请求路由。在ServiceMesh环境中，会在每个POD中注入一个Sidecar容器来实现流量代理能力。在istio中，往往会使用强大的envoy来完成这件事情。所有的这一切都是通过修改底层基础设施来完成的，上层应用不感知。

arch-sec.png

上图是istio mesh的架构图，在基于istio的service mesh中，底层的Service和EndPoints还是基于k8s的原生机制，但是编排能力由istio进行了接管，原生的基于kube-proxy的网络层编排，变成了有istio控制面进行编排，各个Pod中的SideCar代理同步配置。POD与POD之间的流量由SideCar代理进行了劫持，变成了代理与代理之间端到端的流量通讯。

基于这样的机制，一方面出入的流量都会经过envoy代理，对比仅仅由内核iptables和LVS进行转发，envoy代理有更多机会和更强大的能力对流量进行控制。代理与代理之间的通信可以进行加密，解决了以往站内通信都是明文的问题。

同样，我们可以看到，由于出入都需要代理，天生比仅通过内核转发多出了两个用户态的环节，在性能上必然有一定的衰减。

envoy-sidecar-traffic-interception-20190111.png

借用上面一张图，我们可以看到，进入POD的请求，首先是在内核态的PREROUTING链上进行判断，符合条件的流量会被导入到ISTIO_INBOUND链，然后被重定向到用户态的Envoy SideCar进行处理，处理完成之后，被重新注回到内核，再被重新定向到用户态的真实的APP中进行业务上的处理。其返回数据，同样先进入内核然后被劫持到用户态SideCar中处理，最后又被重新发回内核态发生出去。

在两个被SideCar代理托管的服务之间通信，需要被SideCar代理处理4次，数据包有8次内核态与用户态之间的切换，其带来的延时可想而知。安全从来都不是没有代价的，需要从性能，部署复杂度等方面进行取舍。

小结

本文介绍了k8s环境下，基于服务的网络原理。并且比较了k8s原生的和基于服务网格的服务架构。两者对比如下，供参考：

ServiceMesh在给我们带来很多便利的同时，也带来了性能上的降低，以及ServiceMesh本身的复杂性。在选型过程中，需要注意结合自身情况作出选择。