流量接入方案Kuberentes社区通过为集群增加入口来解决对外流量的管理。通过kube-proxy代理通常在最简单的测试或个人开发环境下，可以使用kubectlport-forward启动一个kube-proxy进程代理内部服务到执行命令的主机节点，如果主机有公网IP，转发监听端口为0.0.0.0，实现公网访问服务。这个方法可以代理单个Pod，或者Deployment，或者Servcie。$kubectlport-forward-hForward一个或多个本地端口到pod。此命令要求节点安装“socat”。使用资源类型/名称（例如deployment/mydeployment）选择一个pod。如果省略，资源类型默认为'pod'。如果有多个符合条件的pod，将自动选择一个pod。转发会话结束了所选的POD终止，并且需要重新恢复命令的重新恢复。恢复转发。例证：＃在本地端口5000和6000上收听，将数据转发到/从端口5000和6000中的podkubectlport-fort-ford-ford-fordPod/mypod中的pod和600050006000#在本地监听5000和6000端口，在deployment选择的pod中向/从端口5000和6000转发数据kubectlport-forwarddeployment/mydeployment50006000#在本地监听8443端口，转发到服务端口的targetPort在服务选择的pod中命名为“https”kubectlport-forwardservice/myservice8443:https#监听端口本地8888，转发到pod中的5000kubectlport-forwardpod/mypod8888:5000#在所有地址上监听8888端口，转发到pod中的5000kubectlport-forward--address0.0.0.0pod/mypod8888:5000#在本地主机和选定IP上监听端口8888，转发到pod中的5000kubectlport-forward--addresslocalhost,10.19.21.23pod/mypod8888:5000#在本地随机监听端口，转发到podkubectl中的5000port-forwardpod/mypod:5000NodePort模式是第二种最常用的NodePort模式。将K8s中的服务类型改为NodePort方式，会得到一个主机端口，端口范围为30000-32767个端口。同一主机有公网IP可以实现服务的暴露，但是NodePort会占用主机端口，一个Service对应一个NodePort。这种方法只有四层，无法实现SSL证书的卸载。如果将服务转发到单个Node节点的NodePort，则无法实现高可用，一般需要在NodePort前面使用负载均衡，增加多个后端NodePort实现高可用LoadBalancer四层四层流量转发一个LB的端口只能对应一个Service，Servcie的Type为NodePort。例如下图，LoadBalancer上的88端口对应转发给后端NodePort的32111端口，对应servcieA；LB上的8080对应端口转发到后端NodePort32001端口；该方案可以通过增加多个NodePort来实现高可用，但是因为是4层，所以无法卸载SSL，对应的NodePort需要在LB中占用一个端口。七层七层可以使用LB的域名转发，实现一个域名端口对应多个服务，如图，根据路径，/cmp对应NodePort32111，/gateway对应NodePort32000端口，不仅可以实现高可用，而且七层可以实现SSL卸载。目前通用公有云的LB层级有四层和七层的功能，配合使用可以实现灵活的业务流量暴露。Ingress在K8s中有一个Ingress资源，根据不同的路径或者其他配置规则，将单个域名转发到K8集群内的不同Service，但是用户请求需要访问Ingress实现控制器的NodePort，比如Service的Ingress-nginx的Controller针对具体的业务域名，NodePort一般没有端口，所以前面一般需要一层80/443端口转发。总的来说，业界对于IngressController实现的方案有很多，比如大家熟知的Ingress——nginx/Ingress-traefik等。LoadBalancer+Ingress，如下图，前面有一个四层LB，将80/443端口转发到ingress-provider服务的NodePort。K8s集群内部配置了多个服务。Ingress-nginx详解在以上几种方案中，都使用了Ingress。Nginx-ingress是Nginx官方提供的一个实现K8singress资源的方案。同时，Kubernetes官方提供了基于Nginx的Ingress方案。NginxIngress由三部分组成：资源对象Ingress、Ingress控制器、Nginx。Ingresscontroller的目标是建立一个配置文件（nginx.conf），主要是通过检测到配置文件发生变化后重新加载Nginx来实现的，而不仅仅是在Upstream发生变化（部署应用时修改Endpoints）时ReloadNginx，使用lua-nginx-module实现。根据下图，可以更好的理解Ingress-nginx的使用场景。图中显示如下信息：一个K8s集群集群用户管理，用户A和用户B，他们通过KubernetesAPI使用集群。客户端A和客户端B，分别连接到用户部署的应用程序A和B。IC，由管理员部署在命名空间nginx-ingress中的pod中，并通过ConfigMapnginx-ingress配置。管理员通常会部署至少两个pod以实现冗余。IC使用KubernetesAPI获取集群中创建的最新入口资源，然后根据这些资源配置NGINX。应用程序A由用户A在命名空间A中部署两个Pod。为了通过主机A.example.com将应用程序暴露给其客户端（客户端A），用户A创建门户A。用户B在命名空间B中部署应用程序B的一个Pod。通过主机B.example.com将应用程序公开给其客户端（客户端B），用户B创建VirtualServerB。公共终端，位于ICpod前面。这通常是一个TCP负载均衡器（云、软件或硬件），或此类负载均衡器和NodePort服务的组合。客户端A和B通过公共端点连接到他们的应用程序。黄色和紫色箭头代表与客户端流量相关的连接，黑色箭头代表对KubernetesAPI的访问。为简单起见，许多必要的Kubernetes资源（例如部署和服务）未显示，管理员和用户也需要创建这些资源。其他在K8s中，云厂商的LB通常会提供自适应CNI，在创建K8s集群时会自动创建LB类型的servcie，比如阿里的ACK，腾讯的TKE，华为的CCE等，但是在我们自己构建或者亲测场景，开源的Metallb[1]是一个不错的选择。它通过K8s原生方式提供LB类型的服务支持，开箱即用。OpenELB[2]是一个为物理机（Bare-metal）、边缘（Edge）和私有化环境设计的负载均衡器插件。可以作为Kubernetes、K3s、KubeSphere的LB插件，在集群外暴露“LoadBalancer”类型的服务。2021年11月，已进入CNCF沙箱（Sandbox）托管。也解决了用户在裸机或私有化环境，尤其是物理机或边缘集群上部署Kubernetes集群的痛点。Kubernetes不提供LoadBalancer。与云负载均衡器相同的用户体验。
