kubernetes基础知识之ingress和External IP

在kubernetes中，ingress可以配置提供服务外部访问的URL。

Ingress有两大组件：ingress-controller和ingress。ingress-controller通过与kubernetes API去交互，动态去感知集群中ingress的规则变化，然后读取它，按照它自己的模板，生成一段Nginx配置，再写入Nginx Pod里面，最后reload一下。最新版本中，kubernetes已经将nginx与ingress-controller合并为一个组件，所以nginx无需单独部署，只需要部署ingress-controller即可。

Ingress的工作原理：

1.ingress-controller通过和kubernetes API-Server去交互，动态地去感知kubernetes集群中ingress的规则变化。

2.然后读取它，按照自定义的规则，规则就是写明了哪个域名对应哪个service，生成一段nginx配置。

3.再写到nginx-ingress-controller的pod里面，这个ingress-controller的pod里面运行着一个nginx服务，控制器会把生成的配置写入/etc/nginx.conf配置文件中。

4.然后reload一下，使配置生效。以达到域名区分配置和动态更新的作用。

在使用普通的service的时候，集群中每个节点的kube-proxy在监听service和endpoint的变化时，会动态地修改相关的iptables的转发规则。客户端在访问时通过iptables设置的规则进行路由转发达到访问服务的目的。

而ingress跳过了kube-proxy这一层，通过ingress-controller中的代理配置进行路由转发达到访问目标服务的目的。

实际上可以把ingress controller 看成一个拥有默认处理后端的代理。根据ingress的配置动态修改代理的配置文件，以实现按照ingress规则转发请求的功能。

每创建一个service,kubernetes会自动创建一个同名的endpoint出来，我们可以通过命令查看：

kubectl get endpoints --all-namespaces

External IP是为了解决如何从外部访问集群服务的问题。

对于NodePort类型的服务，PORT表示的内容是集群IP的内部端口:节点端口/TCP。可以通过以下方式访问服务：

①：CLUSTER-IP:集群内部端口

②：任意一个node IP的节点端口。

对于LoadBalancer类型的服务，负载均衡器的对外IP地址为：EXTERNAL-IP。可以通过这个地址访问服务：

curl http://EXTERNAL-IP。

External IP是为了解决如何从外部访问service服务的问题。外部访问服务有两种方法：

1.通过设置NodePort到物理机，同时设置service的类型为NortPort。

2.通过设置LoadBalancer映射到云服务上提供的LoadBalancer地址。这种用法仅用于公有云服务提供商的云平台设置service的场景。对这个service的请求会通过LoadBalancer转发到后端pod上，负载分发的实现方式依赖于云服务商提供的LoadBalancer的实现机制。

-----我是华丽的分隔线-----

需要service的原因：

1.pod ip会变化，比如删除之后。service是pod的代理，我们客户端需要访问pod中部署的应用，只需要访问service ，service就会把请求代理到pod。

2.pod IP在kubernetes集群之外无法访问，只能创建service。这个service是可以在外部访问的，service的类型需要创建为NodePort的类型。

service可以理解成一个固定的接入层，客户端可以访问service的IP:Port，这样service可以代理请求到service关联的后端pod上。

一般四层代理用service,七层代理用Ingress。

service依赖于组件coredns，coredns是一个dns服务器，创建的service可以通过coredns把请求的服务service生成一个FQDN全质量域名。FQDN的格式是：

${Service_name}.${namespace}.svc.cluster.local

请求这个FQDN全质量域名的时候，和请求CLUSTER-IP是一个效果。

service还依赖一个组件，是kube-proxy组件。创建的service是有IP的，是一个虚拟的IP地址。创建的这个虚拟的IP是存在IPVS或者是iptables规则里面的。kube-proxy负责监听创建的service，kube-proxy会把新创建的service生成的IP保存到ipvs或者iptables规则里面。一般ipvs比iptables效率高，开启了ipvs就会存在ipvs规则里面，否则存在iptables规则里面。

Service找pod需要标签选择器label selector。service靠kube-proxy把客户端的请求代理到后端pod上面。kube-proxy是一个代理，可以做一些负载均衡策略，比如轮询、加权轮训等来决定把service的客户端请求代理到哪个后端的pod里面。并且kube-proxy会把service的IP转发到ipvs或者iptables规则里面。

service的工作原理：

基于同一个模板，也就是控制器创建的pod都有一样的标签。

创建service的时候，在service里面定义了一个label selector标签选择器。标签选择器会选择标签关联的pod。

客户端访问service，service通过label selector标签选择器找到关联的pod。

创建service的时候，也会创建一个endpoint的资源。

可以通过kubectl get endpoints --all-namespaces查看到。

创建service的时候，会创建一个同名的endpoint的资源对象。endpoint里面注册的是pod的IP和端口。

只要创建的service，关联了pod的标签，那么注册的pod的IP和端口，就会写到endpoint的对象里面。只要创建的pod能被service关联到，就会写入endpoint对象里。

访问的时候，请求到达service。一般会由endpoint把请求代理到pod后端。具体把请求代理到哪个后端pod，是通过kube-proxy组件去实现的。kube-proxy组件，相当于负载均衡的组件，会生成iptables规则。service和哪个pod关联，靠轮询、加权轮询等，是靠kube-proxy实现，service里面定义的label selector是用来查找pod的。查找到pod之后，会保存到endpoint这个资源对象里。service接收请求后会根据endpoint里面记录的对象，把请求分发到多个pod上，endpoint里面有多个pod。

分发请求的时候，具体按照什么策略分发，靠kube-proxy负载均衡实现。

老虎tiger

鼓励的话语：有识才有胆，有胆才有识。知识要和胆量相结合！