网站排名公司哪家好,成都微信开发小程序,做个普通的网站在上海做要多少钱,网站建设与网页设计的区别文章目录 一、为什么需要 Service二、Kubernetes 中的服务发现与负载均衡 -- Service三、用例解读1、Service 语法2、创建和查看 Service 四、Headless Service五、集群内访问 Service六、向集群外暴露 Service七、操作示例1、获取集群状态信息2、创建 Service、Deployment3、创… 文章目录 一、为什么需要 Service二、Kubernetes 中的服务发现与负载均衡 -- Service三、用例解读1、Service 语法2、创建和查看 Service 四、Headless Service五、集群内访问 Service六、向集群外暴露 Service七、操作示例1、获取集群状态信息2、创建 Service、Deployment3、创建客户端的测试 Pod4、集群内访问 Service 的三种方式4.1、直接通过 Service 的 clusterIP 访问4.2、直接访问 Service 名4.3、通过环境变量访问 5、集群外部访问服务5.1、NodePort5.1.1、创建 NodePort 类型的 ServiceNodePort的端口范围是 30000-327675.1.2、创建 Deployment 模拟后端一组应用 Pod5.1.3、创建并查看5.1.4、通过节点 IP:port 访问5.1.5、通过nodename 也可以访问 5.2、LoadBalancer5.2.1、安装METALLB5.2.2、查看MetalLB的安装方式Installation by manifest5.2.3、创建 MetalLB 的命名空间5.2.4、下载 MetalLB 的安装文件5.2.5、查看 MetalLB 需要的镜像5.2.6、修改 metallb.yaml 文件5.2.7、worker节点提前下载speaker和controller镜像5.2.8、安装 MetalLB5.2.9、查看 Pod 验证安装情况5.2.10、配置地址池5.2.11、创建地址池5.2.12、创建 LoadBalancer 类型的 SVC5.2.13、通过 svc 的 EXTERNAL-IP 访问集群内部的服务 5.3、Ingress5.4、HostNetwork5.4.1、给 node 节点添加 role 标签5.4.2、创建使用 hostnetwork 的 Deployment5.4.3、通过节点 ip 访问 5.5、HostPort5.5.1、给 node 节点添加 role 标签5.5.2、创建使用 hostport 的deployment5.5.3、通过标签节点 ip port / pod ip 访问 5.6、ExternalName5.6.1、创建 ExternalName 类型的 Service5.6.2、启动临时 pod 测试 DNS 解析5.6.3、域名解析 八、架构设计1、Kubernetes 服务发现架构1.1、组件1.2、实际访问链路 一、为什么需要 Service
在 K8s 集群里面会通过 pod 去部署应用与传统的应用部署不同传统应用部署在给定的机器上面去部署我们知道怎么去调用别的机器的 IP 地址但是在 K8s 集群里面应用是通过 pod 去部署的 而 pod 生命周期是短暂的。在 pod 的生命周期过程中比如它创建或销毁它的 IP 地址都会发生变化这样就不能使用传统的部署方式不能指定 IP 去访问指定的应用。
另外在 K8s 的应用部署里之前虽然学习了 deployment 的应用部署模式但还是需要创建一个 pod 组这些 pod 组需要提供一个统一的访问入口以及怎么去控制流量负载均衡到这个组里面。
比如说测试环境、预发环境和线上环境其实在部署的过程中需要保持同样的一个部署模板以及访问方式。因为这样就可以用同一套应用的模板在不同的环境中直接发布。
二、Kubernetes 中的服务发现与负载均衡 – Service
最后应用服务需要暴露到外部去访问需要提供给外部的用户去调用的。我们知道 pod 的网络跟机器不是同一个段的网络那怎么让 pod 网络暴露到去给外部访问呢这时就需要服务发现。 在 K8s 里面服务发现与负载均衡就是 K8s Service。
上图就是在 K8s 里 Service 的架构K8s Service 向上提供了外部网络以及 pod 网络的访问即外部网络可以通过 service 去访问pod 网络也可以通过 K8s Service 去访问。
向下K8s 对接了另外一组 pod可以通过 K8s Service 的方式去负载均衡到一组 pod 上面去这样相当于解决了前面所说的复发性问题或者提供了统一的访问入口去做服务发现然后又可以给外部网络访问解决不同的 pod 之间的访问提供统一的访问地址。
三、用例解读
1、Service 语法
cat my-service.yaml EOF
apiVersion: v1
kind: Service
metadata:name: my-servicelabels:app: my-service
spec:selector:app: MyAppports:- protocol: TCPport: 80targetPort: 9376
EOF定义了用于 K8s Service 服务发现的一个协议以及端口。声明了一个名叫 my-service 的一个 K8s Service它有一个 app:my-service 的 label它选择了 app:MyApp 这样一个 label 的 pod 作为它的后端。
最后是定义的服务发现的协议以及端口我们定义的是 TCP 协议端口是 80目的端口是 9376效果是访问到这个 service 80 端口会被路由到后端的 targetPort就是只要访问到这个 service 80 端口的都会负载均衡到后端 appMyApp 这种 label 的 pod 的 9376 端口。
2、创建和查看 Service
kubectl apply -f my-service.yamlkubectl describe svc my-serviceservice 创建好之后可以看到它的名字是 my-service。Namespace、Label、Selector 这些都跟我们之前声明的一样这里声明完之后会生成一个 IP 地址这个 IP 地址就是 service 的 IP 地址它在集群里面可以被其它 pod 所访问相当于通过这个 IP 地址提供了统一的一个 pod 的访问入口以及服务发现。
这里还有一个 Endpoints 的属性就是我们通过 Endpoints 可以看到通过前面所声明的 selector 去选择了哪些 pod以及这些 pod 都是什么样一个状态比如说通过 selector我们看到它选择了这些 pod 的一个 IP以及这些 pod 所声明的 targetPort 的一个端口。 在 service 创建之后它会在集群里面创建一个虚拟的 IP 地址以及端口在集群里所有的 pod 和 node 都可以通过这样一个 IP 地址和端口去访问到这个 service。这个 service 会把它选择的 pod 及其 IP 地址都挂载到后端这样通过 service 的 IP 地址访问时就可以负载均衡到后端这些 pod 上面去。
当 pod 的生命周期有变化时比如说其中一个 pod 销毁service 就会自动从后端摘除这个 pod。这样实现了就算 pod 的生命周期有变化它访问的端点是不会发生变化的。
四、Headless Service
service 创建的时候可以指定 clusterIP:None告诉 K8s 说我不需要 clusterIP就是刚才所说的集群里面的一个虚拟 IP然后 K8s 就不会分配给这个 service 一个虚拟 IP 地址它没有虚拟 IP 地址怎么做到负载均衡以及统一的访问入口呢
它是这样来操作的pod 可以直接通过 service_name 用 DNS 的方式解析到所有后端 pod 的 IP 地址通过 DNS 的 A 记录的方式会解析到所有后端的 Pod 的地址由客户端选择一个后端的 IP 地址这个 A 记录会随着 pod 的生命周期变化返回的 A 记录列表也发生变化这样就要求客户端应用要从 A 记录把所有 DNS 返回到 A 记录的列表里面 IP 地址中客户端自己去选择一个合适的地址去访问 pod。
apiVersion: v1
kind: Service
metadata:name: my-servicelabels:app: my-service
spec:clusterIP: Noneselector:app: MyAppports:- protocol: TCPport: 80targetPort: 9376可以从看到跟刚才我们声明的模板的区别就是在spec下加了一个 clusterIP:None即表明不需要虚拟 IP。 Headless Service 实际效果就是集群的 pod 访问 my-service 时会直接解析到所有的 service 对应 pod 的 IP 地址返回给 pod然后 pod 里面自己去选择一个 IP 地址去直接访问。
五、集群内访问 Service
在集群里面其他 pod 要怎么访问到我们所创建的这个 service 呢
有三种方式
首先我们可以通过 service 的虚拟 IP 去访问比如说刚创建的 my-service 这个服务通过 kubectl get svc 或者 kubectl discribe service 都可以看到它的虚拟 IP 地址是 10.96.47.23端口是 80然后就可以通过这个虚拟 IP 及端口在 pod 里面直接访问到这个 service 的地址第二种方式直接访问服务名依靠 DNS 解析就是同一个 namespace 里 pod 可以直接通过 service 的名字去访问到刚才所声明的这个 service。不同的 namespace 里面我们可以通过 service 名字加“.”然后加 service 所在的哪个 namespace 去访问这个 service例如我们直接用 curl 去访问就是 my-service:80 就可以访问到这个 service第三种是通过环境变量访问在同一个 namespace 里的 pod 启动时K8s 会把 service 的一些 IP 地址、端口以及一些简单的配置通过环境变量的方式放到 K8s 的 pod 里面。在 K8s pod 的容器启动之后通过读取系统的环境变量比读取到 namespace 里面其他 service 配置的一个地址或者是它的端口号等等。
比如在集群的某一个 pod 里面可以直接通过 curl $ 取到一个环境变量的值比如取到 MY_SERVICE_SERVICE_HOST 就是它的一个 IP 地址MY_SERVICE 就是刚才我们声明的 my-serviceSERVICE_PORT 就是它的端口号这样也可以请求到集群里面的 MY_SERVICE 这个 service。
kubectl get pods -l appMyAppkubectl exec -it my-deployment-6866788946-8v9m6 /bin/bashecho $MY_SERVICE_SERVICE_HOSTecho $MY_SERVICE_SERVICE_PORT六、向集群外暴露 Service
前面介绍的都是在集群里面 node 或者 pod 去访问 serviceservice 怎么去向外暴露呢怎么把应用实际暴露给公网去访问呢
NodePort这种方法会在集群的所有节点上开放一个端口称为 NodePort外部可以通过任意节点的 IP 地址加上这个端口号来访问服务。NodePort 的端口范围默认是 30000-32767。例如如果你有一个名为 my-service 的服务Kubernetes 可能会随机分配一个端口比如 30001那么你可以通过 :30001 来访问服务 。
LoadBalancer在支持外部负载均衡器的云服务提供商如 AWS、Azure、GCP 等上你可以创建一个 LoadBalancer 类型的服务。这将自动创建一个外部负载均衡器并将外部流量转发到服务。LoadBalancer 类型的服务会在云提供商的负载均衡器上配置一个公共 IP 地址你可以通过这个 IP 地址访问服务 。
ExternalName这种方式通过 CNAME 记录将服务映射到一个外部域名。这意味着当请求发送到 Kubernetes 集群时DNS 服务会返回一个 CNAME 记录指向你指定的外部域名。这种方法不涉及流量的转发而是在 DNS 层面上进行重定向 。
External IP为服务分配一个或多个外部可访问的 IP 地址。这些 IP 地址通常由云服务提供商管理可以是静态或动态分配。通过 Service 的 externalIPs 字段指定外部 IP 地址外部流量可以通过指定的 IP 地址访问 Service。
IngressIngress 是 Kubernetes 的一种 API 对象它管理外部访问到集群内服务的 HTTP 流量。通过定义 Ingress 规则你可以控制如何将外部请求路由到集群内的服务。Ingress 通常与 Ingress Controller 一起使用后者负责实现 Ingress 规则并将流量转发到正确的服务 。
HostPort在 Pod 级别使用将 Pod 内的端口映射到宿主机的特定端口。这种方式不是通过 Service 资源实现的而是在 Pod 定义中使用 hostPort 字段。
HostNetwork在 Pod 级别使用允许 Pod 直接使用宿主机的网络命名空间。这意味着 Pod 会绕过 Kubernetes 的网络代理直接在宿主机上监听网络请求。这种方式不是通过 Service 资源实现的而是在 Pod 定义中设置 hostNetwork: true。
七、操作示例
1、获取集群状态信息
kubectl get cs2、创建 Service、Deployment
cat service.yaml EOF
apiVersion: v1
kind: Service
metadata:name: nginx-testlabels:run: nginx
spec:selector:run: nginxports:- protocol: TCPport: 80targetPort: 80
EOF
cat server.yaml EOF
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-testlabels:run: nginx
spec:replicas: 2selector:matchLabels:run: nginxtemplate:metadata:labels:run: nginxspec:containers:- name: nginximage: nginx:1.16.0imagePullPolicy: IfNotPresent
EOFkubectl apply -f service.yaml -f server.yamlkubectl get pods -o wide -l runnginxkubectl describe svc nginx-test3、创建客户端的测试 Pod
现在去创建一个客户端的 pod 实际去感受一下如何去访问这个 K8s Service
cat client-test.yaml EOF
apiVersion: v1
kind: Pod
metadata:name: test-client
spec:containers:- name: client-testimage: busybox:1.31.0command:- sleep- 3600
EOF4、集群内访问 Service 的三种方式
4.1、直接通过 Service 的 clusterIP 访问
kubectl exec -it test-client /bin/shwget -qO- 10.96.252.194.2、直接访问 Service 名
wget -qO- nginx-test不同命名空间时也可以通过 .namespace 来访问 service 4.3、通过环境变量访问
通过执行 env 命令看一下它实际注入的环境变量的情况。看一下 nginx-test 的 service 的各种配置已经注册进来了。
envwget -qO- $NGINX_TEST_SERVICE_HOST5、集群外部访问服务
5.1、NodePort
NodePort 类型的 Service 提供了一种将集群内部的服务暴露给外部客户端访问的方式。通过创建一个类型为 NodePort 的 ServiceKubernetes 控制器会在每个运行中的节点上打开一个固定的端口默认范围是30000-32767但可以根据需要进行配置。外部流量可以通过这个节点端口访问到集群内的服务。 5.1.1、创建 NodePort 类型的 ServiceNodePort的端口范围是 30000-32767
cat nodeport-svc.yaml EOF
apiVersion: v1
kind: Service
metadata:name: nodeport-service
spec:type: NodePortports:- port: 8080targetPort: 80nodePort: 30120selector:app: nginx
EOF5.1.2、创建 Deployment 模拟后端一组应用 Pod
cat nodeport-deploy.yaml EOF
apiVersion: apps/v1
kind: Deployment
metadata:name: nodeport-deploy
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.16.0ports:- containerPort: 80
EOF5.1.3、创建并查看
kubectl apply -f nodeport-deploy.yaml -f nodeport-svc.yamlkubectl get pods -l appnginxkubectl get svckubectl describe svc nodeport-service5.1.4、通过节点 IP:port 访问
curl 192.168.112.10:30120 5.1.5、通过nodename 也可以访问 5.2、LoadBalancer
当创建一个 LoadBalancer 类型的服务时Kubernetes 会尝试通过云提供商或第三方负载均衡解决方案来创建一个负载均衡器。这个负载均衡器会分配一个静态的外部IP地址或 DNS 名称并会将外部流量路由到集群内的服务。 5.2.1、安装METALLB
使用LoadBalancer的方式进行服务发布需要借助第三方的工具(METALLB)。
每个svc都有一个私有地址只能在集群内部访问如果我们把svc的类型设置为LoadBalancer则svc会获取到一个外部IP这个外部IP来自地址池示例使用METALLB配置地址池。
METALLB官网 5.2.2、查看MetalLB的安装方式Installation by manifest 5.2.3、创建 MetalLB 的命名空间
kubectl create ns metallb-system5.2.4、下载 MetalLB 的安装文件
wget https://raw.githubusercontent.com/metallb/metallb/v0.11.0/manifests/metallb.yamlwget https://raw.githubusercontent.com/metallb/metallb/v0.11.0/manifests/namespace.yaml5.2.5、查看 MetalLB 需要的镜像
grep image metallb.yaml5.2.6、修改 metallb.yaml 文件
image同级下添加如下字段
imagePullPolicy: IfNotPresent5.2.7、worker节点提前下载speaker和controller镜像 所有节点都执行拉取操作 docker pull quay.io/metallb/speaker:v0.11.0docker pull quay.io/metallb/controller:v0.11.05.2.8、安装 MetalLB
kubectl apply -f namespace.yaml -f metallb.yaml 5.2.9、查看 Pod 验证安装情况
kubectl get pods -n metallb-system5.2.10、配置地址池 cat IPAddressPool.yaml EOF
apiVersion: v1
kind: ConfigMap
metadata:namespace: metallb-systemname: config
data:config: |address-pools:- name: defaultprotocol: layer2addresses:- 192.168.112.100-192.168.112.200
EOF5.2.11、创建地址池
kubectl apply -f IPAddressPool.yaml 5.2.12、创建 LoadBalancer 类型的 SVC
cat EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: podtestlabels:app: podtest
spec:containers:- name: nginximage: nginx:1.16.0ports:- containerPort: 80
EOFkubectl expose pod podtest --nameloadbalancer-svc --port80 --target-port80 --typeLoadBalancer --selectorapppodtest查看svcEXTERNAL-IP地址是从地址池里分配的默认为首个可分配的ip地址
5.2.13、通过 svc 的 EXTERNAL-IP 访问集群内部的服务 浏览器访问 192.168.112.100curl 192.168.112.1005.3、Ingress
Ingress 是 Kubernetes 中另一种将集群内部的服务暴露给外部的方式。不同于 Service 类型如 NodePort 和 LoadBalancerIngress 提供了一个更高级别的抽象允许管理员定义更加复杂的路由规则以便于管理和扩展HTTP和HTTPS服务。 TODO 下一篇单独讲讲吧 5.4、HostNetwork
hostNetwork 是 Kubernetes 中的一个特性选项但它并不是直接用于将集群内部服务暴露给外部访问的方式而是指在创建 Pod 时是否使用宿主机的网络栈来进行网络通信。当在 Pod 的规格中设置了 hostNetwork: true 时Pod 将直接使用宿主机的网络接口而不是 Kubernetes 的服务网络。
5.4.1、给 node 节点添加 role 标签
kubectl label nodes k8s-node1 rolenode1kubectl get nodes -L role5.4.2、创建使用 hostnetwork 的 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: nginx-deployment
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:nodeSelector: role: node1hostNetwork: truecontainers:- image: nginx:1.16.0imagePullPolicy: IfNotPresentname: nginxports:- containerPort: 80805.4.3、通过节点 ip 访问 在和containers 同级的 hostNetwork: true,表示pod使用宿主机网络配合 nodeSelector把pod实例化在固定节点如上给node1节点加上标签role: node1 , 通过nodeSelector,nginx就会实例化在node1节点这样就可以通过node1节点的ip就可以访问这个nginx了。
5.5、HostPort
在 Kubernetes 中hostPort 是一种配置 Pod 的方式使得 Pod 内部的应用可以通过特定的端口监听宿主机的网络接口。当 Pod 的容器配置了 hostPort它将能够接收来自宿主机对应端口的流量。这种方式可以实现外部服务访问集群内部服务的需求但需要注意的是使用 hostPort 需要注意端口冲突及安全性问题。
5.5.1、给 node 节点添加 role 标签
kubectl label k8s-node2 rolenode2kubectl get nodes -L role5.5.2、创建使用 hostport 的deployment
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginxname: hostport-deploy
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec: nodeSelector:role: node2containers:- image: nginx:1.16.0imagePullPolicy: IfNotPresentname: nginxports:- containerPort: 8080hostPort: 805.5.3、通过标签节点 ip port / pod ip 访问 和hostNetwork相比多了映射能力可以把容器端口映射为node节点不同端口hostPort,当然也需要nodeSelector来固定节点不然每次创建节点不同ip也会改变
5.6、ExternalName
ExternalName 类型的 Service 是 Kubernetes 中用于提供从集群内部访问外部 DNS 名称的一种方式。它的主要目的是简化集群内部应用访问外部服务的过程。当你创建一个类型为 ExternalName 的 Service 时Kubernetes 会为这个 Service 创建一个 DNS 条目该条目将解析为指定的外部 DNS 名称。
与 NodePort 或 LoadBalancer 类型的 Service 不同ExternalName 类型的 Service 不会暴露任何集群内部的服务到外部网络而是相反它让集群内部的服务可以访问外部的服务。 5.6.1、创建 ExternalName 类型的 Service
cat EOF | kubectl apply -f -
apiVersion: v1
kind: Service
metadata:name: service-externalnamelabels:type: externalname
spec:type: ExternalNameexternalName: www.baidu.com
EOFkubectl get svc -l typeexternalname5.6.2、启动临时 pod 测试 DNS 解析 可以看到集群内部是可以访问外部服务www.baidu.com kubectl run -it --rm --imagealpine:latest dns-test -- sh5.6.3、域名解析
查看 kube-dns 的 ip 地址
kubectl get svc kube-dns -n kube-system -o custom-columnsClusterIP:.spec.clusterIP安装 dig 命令
yum provides digyum install -y bind-utils-9.11.4-26.P2.el7_9.16.x86_64从集群内部解析 ExternalName 类型的 Service
dig 172.16.0.10 service-externalname.default.svc.cluster.local八、架构设计
1、Kubernetes 服务发现架构 如上图所示K8s 服务发现以及 K8s Service 是这样整体的一个架构。
K8s 分为 master 节点和 worker 节点
master 里面主要是 K8s 管控的内容worker 节点里面是实际跑用户应用的一个地方。
在 K8s master 节点里面有 APIServer就是统一管理 K8s 所有对象的地方所有的组件都会注册到 APIServer 上面去监听这个对象的变化比如说我们刚才的组件 pod 生命周期发生变化这些事件。
1.1、组件
这里面最关键的有三个组件 一个是 Cloud Controller Manager负责去配置 LoadBalancer 的一个负载均衡器给外部去访问 另外一个就是 Coredns通过 Coredns 去观测 APIServer 里面的 service 后端 pod 的一个变化去配置 service 的 DNS 解析实现可以通过 service 的名字直接访问到 service 的虚拟 IP或者是 Headless 类型的 Service 中的 IP 列表的解析 在每个 node 里面会有 kube-proxy 这个组件它通过监听 service 以及 pod 变化然后实际去配置集群里面的 node pod 或者是虚拟 IP 地址的一个访问。
1.2、实际访问链路
比如说从集群内部的一个 Client Pod3 去访问 Service
Client Pod3 首先通过 Coredns 这里去解析出 ServiceIPCoredns 会返回给它 ServiceName 所对应的 service IP 是什么这个 Client Pod3 就会拿这个 Service IP 去做请求它的请求到宿主机的网络之后就会被 kube-proxy 所配置的 iptables 或者 IPVS 去做一层拦截处理之后去负载均衡到每一个实际的后端 pod 上面去这样就实现了一个负载均衡以及服务发现。
对于外部的流量比如说刚才通过公网访问的一个请求。它是通过外部的一个负载均衡器 Cloud Controller Manager 去监听 service 的变化之后去配置的一个负载均衡器然后转发到节点上的一个 NodePort 上面去NodePort 也会经过 kube-proxy 配置的一个 iptables把 NodePort 的流量转换成 ClusterIP紧接着转换成后端的一个 pod 的 IP 地址去做负载均衡以及服务发现。
