k8s暴露集群内和集群外服务的方法

admin

集群内服务

　　一般 pod 都是根据 service 资源来进行集群内的暴露，因为 k8s 在 pod 启动前就已经给调度节点上的 pod 分配好 ip 地址了，因此我们并不能提前知道提供服务的 pod 的 ip 地址。那么 service 服务提供的功能就是，使用者根本无需关心后端提供服务 pod 的数量，以及各自对应的 ip 地址。

服务资源会被 k8s 分配一个 cluster-ip 集群 ip，只能在集群内部可以被访问。而在集群内 k8s 如何配置服务网络的，可以参考之前的网络服务，实际上就是利用 iptables 来进行网络的配置。除此之外 k8s 还可以配置会话的亲和性，因为有可能需要请求落入容一个pod，设置服务的 sessionAffinity 属性为 clientIP。
apiVersion: v1
kind: Service
spec:
    sessionAffinity: ClientIP

这种方式会将服务代理将来自同一个 clientip 的所有请求转发到同一个 pod 上。k8s 仅仅支持两种形式的会话亲和性服务：None和ClientIP。但是不支持 cookie 的会话亲和性选项，因为 k8s 服务不是在 HTTP 层面上工作，服务处理 TCP 和 UDP 包，并不关心其中数据包内容，毕竟解包封包都是需要耗费资源的。

　　而且同一个服务还可以暴露多个端口，比如一个 pod 中监听两个端口，HTTP 监听 8080，HTTPS 监听 8443，可以使用一个服务从端口 80 和 443 转发到 pod 端口 8080 和 8443。比如声明 service 暴露多个端口

apiVersion: v1
kind: Service
metadata:
    name: kubia
spec:
    ports:
    - name: http
      port: 80
      targetPort: 8080    // pod 的8080端口映射成 80 端口
    - name: https
      port: 443
      targetPort: 8443
    selector:
      app: kubia

集群外暴露的服务

将服务暴露给外部客户端的方法有以下几种：

将服务类型设置成 NodePort：会在集群中节点内打开一个端口，外部可以直接从节点端口访问内部服务，k8s 将节点接受的流量冲定向到内部服务中。
将服务类型设置成 LoadBalance：NortPort 类型的一种扩展，这使得服务可以通过一个专用的负载均衡器来访问，这是由 k8s 提供的云基础设施来实现的，负载均衡负责将流量重定向到跨节点的节点端口，这里势必有路由策略和交换器相关。外部客户端直接通过负载均衡器IP来访问集群内部服务
创建一个 Ingress 资源。这是建立在 HTTP 层，也就是 7 层网络层上来进行分发工作，比原本 k8s 的四层网络的服务提供更多的功能。
创建 NodePort 类型的服务
apiVersion: v1
kind: Service
metadata:
    name: kubia-nodeport
spec:
    type: NodePort
    ports:
    - port: 80
      targetPort: 8080
      nodePort: 30123    // 通过部署的集群节点中的 30123 端口可以访问该服务
    selector:
        app: kubia


在集群内两个节点暴露了 30123 端口，到达任何一个节点上端口的传入连接将被重定向到一个随机选择的pod。



通过负载均衡器创建服务

　　k8s 必须在支持 LoadBalance 服务的环境下才能创建此类型的负载均衡器服务。声明如下
apiVersion: v1
kind: Service
metadata:
    name: kubia-loadbalancer
spec:
    type: LoadBalancer
    ports:
    - port: 80
      targetPort: 8080
    selector:
        app: kubia
那么 nodeport 和 LB 类型的有什么不同呢？
$ kubectl get svc kubia-nodeport
NAME               TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
kubia-nodeport   NodePort   10.99.194.15   <nodes>        9000:31090/TCP   1m

$ kubectl get svc kubia-nodeport
NAME               TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)          AGE
kubia-loadbalance   LoadBalancer   10.99.194.15   130.211.53.173        80:32143/TCP   1m
注意的是在

nodeport 类型和 LoadBalance 类型的服务在 external-ip 不一样的是，LB是有外部ip暴露的。通过访问 LB 的外部ip就可以访问到集群内部服务了。



创建 Igress 服务

为什么需要LB的服务，其实最重要的是有独立公有 ip 地址，当客户端向 Ingress 发送 HTTP 请求时，Ingress 会根据请求的主机名和路径决定请求转发到的服务。

Ingress 通过在网络栈 http 的应用层操作，可以提供一些服务不能实现的功能，比如 cookie 的会话亲和性等功能。

创建 Ingress 资源
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: kubia
spec:
    rules:
    - host: kubia.example.com    // ingress 将域名映射到你的服务上
      http:
        path: /
        backend:
            serviceName: kubia-nodeport         // 将请求发送到 kubia-nodeport 服务的 80 端口
            servicePort: 80   
要让 LB 正常工作，也就是通过 kubia.example.com 访问到对应的服务，必须确保在 k8s 集群内域名解析为 Ingress 的控制器，所以这需要基础设施的支持。

在 k8s 查看 ingress 资源
NAME    HOST                   ADDRESS         PORTS   AGE
kubia   kubia-example.com   192.168.99.100  80      75d
所以在集群中需要确保这样的解析，需要路由器支持配置
192.168.99.100    kubia.example.com

如图，首先客户端会对 kubia.example.com 执行 DNS 查找，DNS 服务器或者本地操作系统返回了 Ingress 控制器的 IP。客户端然后向 Ingress 控制器发送 HTTP 请求，并在 host 头中指定 kubia.example.com。控制器从该头部确定客户端应该访问哪个服务，通过与该服务关联的 endpoint 对象查看 podip，并将请求发送到某个 pod。

最后再说明一下将不同服务映射到相同主机的不同路径：
- host: kubia.example.com
  http:
     paths:
     - path: /kubia
       backend:
            serviceName: kubia
            servicePort: 80
     - path: /foo
       backend:
            serviceName: bar
            servicePort: 80