K8s暴露内部服务的多种方式

Posted 2023-03-18

参考技术A

测试yaml：

测试yaml：

端口转发利用的是Socat的功能，这是个神奇的工具，你值得拥有： Socat

之前都是直接将pod上的应用暴露出去，这种方式在实际的生产环境中基本不可取，标准的搞法是基于Service。

Service有三种类型：ClusterIP、NodePort、LoadBalancer。

首先，先了解下Service中端口的概念：

port/nodeport/targetport

port ——Service暴露在Cluster IP上的端口，也就是虚拟IP要绑定的端口。port是提供给集群内部客户端访问Service的入口。

nodeport ——K8s集群暴露给集群外部客户访问Service的入口。

targetport ——是Pod内容器的端口。从port和nodeport上进入的数据最终会经过Kube-proxy流入到后端pod里容器的端口，如果targetport没有显示声明，那么会默认转发到Service接受请求的端口（和port端口保持一致）。

通过Service暴露内部服务的方式有四种：ClusterIP、NodePort、LoadBalancer、Ingress

ClusterIP其实是Service的缺省类型，就是默认类型，例如之前部署的dashboard插件其实就使用是这种类型，可以通过如下指令来分辨：

所以，这种类型的Service本身是不会对集群外暴露服务的，但是却单单可以通过K8s Proxy API来访问。Proxy API是一种特殊的API，Kube-APIServer只代理这类API的HTTP请求，然后将请求转发到某个节点上的Kubelet进程监听的端口上，最后有该端口上的REST API响应请求。

在集群外部访问，需要借助于kubectl，所以集群外的节点必须配置了经过认证的kubectl，可以参看kubectl的配置章节：

这种方式要求访问节点必须具备受认证的kubectl，所以只能用做调试使用。

NodePort是基于ClusterIP的方式来暴露服务的，不过不需要kubectl的配置，他是在每一个node上都监听同一个端口，该端口的访问都会被引导到Service的ClusterIP，后续的方式和ClusterIP的方式是一样的，例子如下：

访问nodeIP:NodePort的时候出现了pod所在的node是OK的，其他的Node访问被拒绝,原因和Docker的版本有关，参看 kubernets nodeport 无法访问 ，解决方案就是在其他的Node上修改FORWARD的链生成规则：

这样就可以访问了：

只能在Service上定义，LoadBalancer是一些特定公有云提供的负载均衡器，需要特定的云服务商提供，比如：AWS、Azure、OpenStack 和 GCE (Google Container Engine) 。这里略过不谈。

与之前的暴露集群Service的方式都不同，Ingress其实不是一种服务。它位于多个服务之前，充当集群中的智能路由器或入口点。类似于Nginx提供的反向代理，其实官方推荐的方式就是Nginx的实现方式。这里以Nginx-Ingress的思路来构建。

Ingress的功能需要两个部分组成，一个是Nginx做网络的7层路由，一个是Ingress-controller来监听ingress rule的变化实时更新nginx的配置，所以在k8s的集群里为了实现Ingress都必须要部署一个Ingress-controller的pod，可以使用官网的套路：

到这一步，Ingress的集群配置已经做完了，接下来进行测试，通过Ingress暴露两个内部的Nginx服务：

然后，给这两个服务配置Ingress规则：