Kubernetes进阶之路（十）Service系列之LoadBalance

Posted 2023-04-12

参考技术A 通常需要第三方云提供商支持，有约束性

Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster. Traffic routing is controlled by rules defined on the Ingress resource.

可以发现，Ingress就是帮助我们访问集群内的服务的。为了彰显其优势，我们在使用Ingress之前，先以一个简单案例出发。

（也为了演示将service写在yaml文件中）

浏览器想要访问这个tomcat，也就是外部要访问该tomcat，用之前的Service-NodePort的方式是可以的，比如暴露一个端口，只需要访问 :即可。

01 创建yaml文件

02 创建service

显然，Service-NodePort的方式生产环境不推荐使用，那接下来就基于上述需求，使用Ingress实现访问tomcat的需求。下面就开始讲解使用ingress插件来实现外网访问集群pod。

4.2 使用ingress实现

4.2.1架构图

说明：

本文中采用的ingress-controller是nginx-ingress-controller，具体详情可以参考官网：https://www.nginx.com/products/nginx/kubernetes-ingress-controller；

大家也可以根据自己需要采用不同的ingress-controller，可参考https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

4.2.2 实例

(1)以Deployment方式创建Pod，该Pod为Ingress Nginx Controller，要想让外界访问，可以通过Service的NodePort或者HostPort方式，这里选择HostPort，比如指定henry002机器上运行：

(2)查看henry002的80和443端口

(3)创建tomcat的pod和service

记得将之前的tomcat删除：kubectl delete -f my-tomcat.yaml

kubectl get svc

kubectl get pods

(4)创建Ingress以及定义转发规则

1>创建 nginx-ingress.yaml文件

2>创建ingress并查看

(5)修改win的hosts文件，添加dns解析

(6)打开浏览器，访问tomcat.henry.com

总结：如果以后想要使用Ingress网络，其实只要定义ingress，service和pod即可，前提是要保证nginx ingress controller已经配置好了。

Kubernetes进阶之路（九）Service系列之ClusterIP&NodePort

参考技术A 在定义Service的时候可以指定一个自己需要的类型的Service，如果不指定的话默认是ClusterIP类型。

可以使用的服务类型如下：

通过集群的内部 IP 暴露服务，选择该值，服务只能够在集群内部可以访问，这也是默认的Service类型。ClusterIP类型的service创建时，k8s会通过etcd从可分配的IP池中分配一个IP，该IP全局唯一，且不可修改。所有访问该IP的请求，都会被iptables转发到后端的endpoints中。

通过每个 Node 节点上的 IP 和静态端口（NodePort）暴露服务。NodePort 服务会路由到 ClusterIP 服务，这个 ClusterIP 服务会自动创建。通过请求 :，可以从集群的外部访问一个 NodePort 服务。

需要外部支持（GCP and Azure），用户访问service.spec.external-ip,该IP对应到一个外部负载均衡的vip，外部服务对这个vip的请求，会被loadbalancer通过健康检查和转发，发送到一个运行着该服务pod的node上，并同样通过nodePort里的端口映射，发送给容器。

用户可以指定一个任意的名字，作为该service被解析的CNAME,这种类型的servcie不用指定clusterIP，因此kube-proxy不会管理这类service，这类service需要使用1.7版本以上的kubedns。

(1)创建whoami-deployment.yaml文件

(2)运行yaml文件并查看pod以及service

(3)在集群内正常访问

(4)创建whoami的service

注意：该地址只能在集群内部访问

**可以发现有一个Cluster IP类型的service，名称为whoami-deployment，IP地址为10.97.233.149

(5)通过Service的Cluster IP访问

(6)具体查看一下whoami-deployment的详情信息，发现有一个Endpoints连接了具体3个Pod

(7)下面通过deployment对whoami扩容成5个

(8)再次访问：curl 10.97.233.149:8000

(9)再次查看service具体信息：kubectl describe svc whoami-deployment

(10)其实对于Service的创建，不仅仅可以使用kubectl expose，也可以定义一个yaml文件

总结：其实Service存在的意义就是为了Pod的不稳定性，而上述探讨的就是关于Service的一种类型Cluster IP，只能供集群内访问。

因为外部能够访问到集群的物理机器IP，所以就是在集群中每台物理机器上暴露一个相同的IP，从给定的配置范围内（默认：30000-32767）分配端口

(1)根据whoami-deployment.yaml创建pod

(2)创建NodePort类型的service，名称为whoami-deployment

(3)注意上述的端口31999，实际上就是暴露在集群中物理机器上的端口

(4)浏览器通过物理机器的IP访问

使用浏览器访问：

总结：NodePort虽然能够实现外部访问Pod的需求，但这种方法有许多缺点：

1.每个端口只能是一种服务

2.端口范围只能是 30000-32767

3.如果节点/VM 的 IP 地址发生变化，你需要能处理这种情况

基于以上原因，我不建议在生产环境上用这种方式暴露服务。如果你运行的服务不要求一直可用，或者对成本比较敏感，你可以使用这种方法。这样的应用的最佳例子是 demo 应用，或者某些临时应用。

因篇幅太长分为两章来写。