兰山网站建设公司,东莞网站建设价格,电子商务网站的建设论文,建德营销型网站建设一、什么是服务service#xff1f; 在k8s里面#xff0c;每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失#xff0c;重启pod的ip地址会发生变化#xff0c;此时客户如果访问原先的ip地址则会报错 #xff1b; Service (服务)就是用来解决这个问题的…一、什么是服务service 在k8s里面每个Pod都会被分配一个单独的IP地址,但这个IP地址会随着Pod的销毁而消失重启pod的ip地址会发生变化此时客户如果访问原先的ip地址则会报错 Service (服务)就是用来解决这个问题的, 对外服务的统一入口防止pod失联定义一组pod的访问策略服务发现、负载均衡 一个Service可以看作一组提供相同服务的Pod的对外访问接口作用于哪些Pod是通过标签选择器来定义的 Service是一个概念主要作用的是节点上的kube-proxy服务进程 举例来说定义了3个商品微服务由网关作为统一访问入口 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化 前端客户端不应该也没必要知道而且也不需要跟踪这一组后端的状态。 简而言之Service 定义的这种抽象能够解耦这种关联 二、service分类 根据使用场景的不同service可以分成下面几类 2.1 ClusterIP 默认类型自动分配一个【仅集群内部】可以访问的虚拟IP 2.2 NodePort 对外访问应用使用在ClusterIP基础上为Service在每台机器上绑定一个端口就可以通过: ipNodePort来访问该服务 在之前搭建k8s集群部署nginx的时候我们使用过 2.3 LoadBalancer付费方案
使在NodePort的基础上借助公有云创建一个外部负载均衡器并将请求转发到NodePort 可以实现集群外部访问服务的另外一种解决方案不过并不是所有的k8s集群都会支持大多是在公有云托管集群中会支持该类型 2.4 ExternalName 使用较少 把集群外部的服务引入到集群内部来在集群内部直接使用。没有任何类型代理被创建这只有 Kubernetes 1.7或更高版本的kube-dns才支持。 三、service和pod的关系 service和pod之间是通过 selector.app进行关联的 对应到yaml中的核心配置如下
spec: # 描述selector: # 标签选择器确定当前service代理控制哪些podapp: test-nginx yaml 配置模板文件
apiVersion: v1
kind: Service
metadata:creationTimestamp: nullname: test-svc
spec:ports:- port: 80 # service服务端口protocol: TCPtargetPort: 80 # pod端口常规和容器内部端口一致selector:app: test-nginx-pod
status:loadBalancer: {} 四、Service 之 ClusterIP 使用 ClusterIP 属于service的一种一般作为集群内部应用互相访问时使用接下来通过实际演示进行详细的说明 4.1 在当前目录下创建一个deploy-nginx-pod.yaml配置如下 apiVersion: apps/v1
kind: Deployment
metadata:name: congge-deploynamespace: dev
spec:replicas: 3selector: matchLabels:app: congge-nginx-podtemplate:metadata:labels:app: congge-nginx-podspec:containers:- name: congge-nginximage: nginx:1.23.0 使用apply命令创建pod
kubectl apply -f deploy-nginx-pod.yaml
可以看到成功创建了一个3副本的pod集群 4.2 暴露服务为 clusterIP 类型 kubectl expose deploy congge-deploy --namesvc-nginx1 --typeClusterIP --port80 --target-port80 -n default
执行成功之后可以看到创建了一个clusterIP类型的service 有了这个clusterIp服务之后后续不管nginx服务扩缩容还是nginx的pod的IP地址如何变化外部只需要统一访问这个clusterIP分配的这个IP端口即可 4.3 查看服务 多了个类型是ClusterIP的通过curl clusterIpport可以访问 kubectl get deployment,pod,svc -n dev -o wide 五、Service 之 NodePort 使用 上面了解到clusterIp这种方式一般作为集群内部各应用访问时使用但实际业务场景中有些应用服务需要暴露出去通过外网去访问这时候就需要创建NodePort这个在k8s搭建篇中最后部署nginx的时候有提到 5.1 关于NodePort
常规业务的场景不全是集群内访问也需要集群外业务访问 那么ClusterIP就满足不了了NodePort是其中的一种实现集群外部访问的方案 对外访问应用使用在ClusterIP基础上为Service在每台机器上绑定一个端口就可以通过: ipNodePort来访问该服务 5.2 创建NodePort类型的服务 在上面我们创建了一个基于clusterIp类型的service 使用下面的命令创建一个基于 NodePort 的service
kubectl expose deploy congge-deploy --namesvc-nodeport-nginx1 --typeNodePort --port80 --target-port80 -n default
执行完成之后就多了一个NodePort的service 使用浏览器访问下当前主机的公网IP就可以访问了master或者node节点都可以访问 查看服务详情
通过这个命令可以查看上述创建的NodePort详细信息
kubectl describe svc svc-nodeport-nginx1 -n default 关于NodePort暴露对外端口说明 Kubeadm部署暴露端口对外服务会随机选端口默认范围是30000~32767也可以手动修改和指定端口范围 关于Endpoint参数说明
是k8s中的一个资源对象存储在etcd中记录service对应的所有pod的访问地址 里面有个Endpoints列表就是当前service可以负载到的pod服务入口 service和pod之间的通信是通过endpoint实现的 可以使用下面的命令查看endpoint列表
kubectl get ep svc-nodeport-nginx1 -n default -o wide 关于Service如何分发请求到后端的多个Pod Service所处的位置就如同图中展示的处在客户端和pod之间这就很像nginx或者其他具备网关的组件的能力了事实上也差不多就是我们理解的那样一个Service的服务背后可能挂载着N多个Pod那么具体来说Service如何分发请求到后端的多个Pod的呢 kubernetes提供了两种负载均衡策略
默认kube-proxy的策略如随机、轮询 使用会话保持模式即同个客户端的请求固定到某个pod在spec中添加sessionAffinity:ClientIP即可 NodePort 负载均衡机制验证
查看pod信息显示了上面创建的以congge-deploy开头的3个nginx 其实来说这也就是对应了3个pod中的3个nginx容器如果使用curl的方式查看其中某个nginx可以正常输出nginx欢迎页面的内容 接下来我们只需要进入到nginx容器内部修改下nginx欢迎页的html内容就可以看出Service的负载均衡效果了 进入docker容器进行html内容的修改
#进入容器
kubectl exec -it congge-deploy-768455649c-2kv5r -n default /bin/sh
kubectl exec -it congge-deploy-768455649c-mfkbf -n default /bin/sh
kubectl exec -it congge-deploy-768455649c-xlh7s -n default /bin/sh#执行修改
echo hello this is node1 /usr/share/nginx/html/index.html
echo hello this is node2 /usr/share/nginx/html/index.html
echo hello this is node3 /usr/share/nginx/html/index.html 执行过程 接下来使用当前主机节点IP图中的端口在浏览器访问下 我们连续访问多次看下返回的内容如何 第一次 第二次 当然可以通过在当前节点上通过curl cluserIP的方式效果类似 其实也可以查看下当前创建这个SVC的时候默认的配置使用yaml格式输出一下
kubectl get svc svc-nodeport-nginx1 -n default -o yaml 总结通过上面的实际操作在默认情况下负载均衡为基于随机的这种策略
