devbox
很楠不爱3
这个屌丝很懒，什么也没留下！
关注作者
热门标签
热门文章
当前位置:   article > 正文

K8S之Service_k8s创建service

作者：很楠不爱3 | 2024-03-05 06:53:32

赞

踩

k8s创建service

目录

Service 的概念

Service 的类型

VIP 和 Service 代理

代理模式的分类

I、userspace 代理模式

II、iptables 代理模式

III、ipvs 代理模式

service实验讲解：

ClusterIP

Headless Service（无头服务）

NodePort

LoadBalancer

ExternalName

Service 的概念

        Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务，这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector

        访问service就可以通过负载均衡访问到对应的pod，并且当pod挂了以后，新创建的pod也会更新到service中去

Service能够提供负载均衡的能力，但是在使用上有以下限制：

        只能基于ip地址和端口进行请求的转发

Service 的类型

Service 在 K8s 中有以下四种类型：

  • ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP

  • NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务

  • LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort
  • ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

VIP 和 Service 代理

        在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。 在 Kubernetes v1.0 版本，代理完全在 userspace。在Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是iptables 代理。 在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理
        在 Kubernetes 1.14 版本开始默认使用 ipvs 代理
        在 Kubernetes v1.0 版本， Service 是 “4层”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了Ingress API（beta 版），用来表示 “7层”（HTTP）服务

！为何不使用 round-robin DNS？缓存问题

代理模式的分类

I、userspace 代理模式

        Client pod 访问 Server pod1，首先要访问到防火墙iptables，防火墙iptables访问到kube-proxy，然后通过kube-proxy进行代理访问到Server pod1

        缺点：kube-proxy压力会比较大

II、iptables 代理模式

        Client pod 访问 Server pod1，首先要访问到防火墙iptables，防火墙iptables直接访问到Server pod1，同时kube-apiserver会监听kube-proxy实现防火墙iptables端点的更新和维护

        优点：减轻了kube-proxy的压力，提高了kube-proxy的稳定性

        缺点：防火墙iptables性能不高

III、ipvs 代理模式

        这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod

        与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

  • rr ：轮询调度
  • lc ：最小连接数
  • dh ：目标哈希
  • sh ：源哈希
  • sed ：最短期望延迟
  • nq ： 不排队调度

 示例：

 

service实验讲解：

ClusterIP

        clusterIP 主要在每个 node 节点使用 iptables，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地址和端口

 为了实现图上的功能，主要需要以下几个组件的协同工作：

apiserver ：用户通过kubectl命令向apiserver发送创建service的命令，apiserver接收到请求后将数据存储到etcd中
kube-proxy ：kubernetes的每个节点中都有一个叫做kube-porxy的进程，这个进程负责感知service，pod的变化，并将变化的信息写入本地的iptables规则中
iptables ：使用NAT等技术将virtualIP的流量转至endpoint中，即将请求负载均衡到后端的pod

1.创建 myapp-deploy.yaml 文件：vim myapp-deploy.yaml

  1. apiVersion: apps/v1
  2. kind: Deployment
  3. metadata:
  4.   name: myapp-deploy
  5.   namespace: default
  6. spec:
  7.   replicas: 3
  8.   selector:
  9.     matchLabels:
  10.       app: myapp
  11.       release: stabel
  12.   template:
  13.     metadata:
  14.       labels:
  15.         app: myapp
  16.         release: stabel
  17.         env: test
  18.     spec:
  19.       containers:
  20.       - name: myapp
  21.       image: wangyanglinux/myapp:v2
  22.       imagePullPolicy: IfNotPresent #镜像的下载策略，如果有就不下载
  23.       ports:
  24.       - name: http #端口的名称为http
  25.         containerPort: 80 #端口为80

2.创建pod集群

 3.创建 Service 信息：vim myapp-service.yaml

  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: myapp #service的名称为myapp
  5.   namespace: default #命名空间为default
  6. spec:
  7.   type: ClusterIP 
  8.   selector:
  9.     app: myapp #容器的app、release与这里的相等，那么容器就可以通过这个Service访问
  10.     release: stabel
  11. ports:
  12. - name: http #端口名称为http
  13.   port: 80 #service的端口
  14.   targetPort: 80 #后端pod实际的端口

4.创建service

 

Headless Service（无头服务）

        有时不需要或不想要负载均衡，以及单独的 Service IP 。遇到这种情况，可以通过指定 ClusterIP(spec.clusterIP) 的值为 “None” 来创建 Headless Service 。这类 Service 并不会分配 Cluster IP， kube-proxy 不会处理它们，而且平台也不会为它们进行负载均衡和路由

示例：

1.创建一个Headless Service：vim myapp-svc-headless.yaml

  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: myapp-headless
  5.   namespace: default
  6. spec:
  7.   selector:
  8.     app: myapp
  9.   clusterIP: "None" #指定为None，表示Service就是无头服务
  10. ports:
  11. - port: 80
  12. targetPort: 80

 2.查看Headless Service

 3.解析Headless Service

 

NodePort

        nodePort 的原理在于在 node 上开了一个端口，将向该端口的流量导入到 kube-proxy，然后由 kube-proxy 进一步给到对应的 pod（这里指的iptables模式）

示例：

1.创建一个Service：vim nodeport.yaml

  1. apiVersion: v1
  2. kind: Service
  3. metadata:
  4.   name: myapp
  5.   namespace: default
  6. spec:
  7.   type: NodePort
  8.   selector:
  9.     app: myapp
  10.     release: stable 
  11. ports:
  12. - name: http
  13.   port: 80
  14.   targetPort: 80

流程：从外部通过30175端口访问到service服务，service会把请求转发到绑定到该service的pod上，其中30175端口是基于NodePort模式的service在K8s每个节点上开放了一个30175端口供外部访问

注意：pod可以同时绑定到多种类型的service

 

 

LoadBalancer

        loadBalancer 和 nodePort 其实是同一种方式，区别在于 loadBalancer 比 nodePort 多了一步，就是可以调用cloud provider 去创建 LB 来向节点导流

ExternalName

        这种类型的 Service 通过返回 CNAME 和它的值，可以将服务映射到 externalName 字段的内容( 例如：hub.atguigu.com )。ExternalName Service 是 Service 的特例，它没有 selector，也没有定义任何的端口和Endpoint。相反的，对于运行在集群外部的服务，它通过返回该外部服务的别名这种方式来提供服务

        当查询主机 my-service.defalut.svc.cluster.local ( SVC_NAME.NAMESPACE.svc.cluster.local )时，集群的DNS 服务将返回一个值 hub.atguigu.com 的 CNAME 记录。访问这个服务的工作方式和其他的相同，唯一不同的是重定向发生在 DNS 层，而且不会进行代理或转发

示例1：

1.创建ex.yaml文件：vim ex.yaml

  1. kind: Service
  2. apiVersion: v1
  3. metadata:
  4.   name: my-service-1
  5.   namespace: default
  6. spec:
  7.   type: ExternalName #Service的类型为ExternalName
  8.   externalName: hub.atguigu.com

2.创建Service

 3.解析service域名

 

示例2：

1.编辑external_name.yaml文件如下：

  1. apiVersion: v1
  2. kind: Namespace
  3. metadata:
  4.   name: dev
  5.  
  6. ---
  7.  
  8. apiVersion: v1
  9. kind: Service
  10. metadata:
  11.   name: search
  12.   namespace: dev
  13. spec:
  14.   type: ExternalName
  15.   externalName: www.baidu.com

2.使用如下命令创建资源：

  1. [root@master service]# kubectl apply -f external_name.yaml
  2. namespace/dev created
  3. service/search created
  4. [root@master service]#

3.查看资源下：

  1. [root@master service]# kubectl get service -n dev
  2. NAME     TYPE           CLUSTER-IP   EXTERNAL-IP     PORT(S)   AGE
  3. search   ExternalName   <none>       www.baidu.com   <none>    11s
  4. [root@master service]#

4.此时，在集群内部的pod中就可以通过 search.dev.svc.cluster.local 访问www.baidu.com了
下面验证一下，首先登录一个pod查看 /etc/resolve.conf

  1. [root@master service]# dig @10.96.0.10 search.dev.svc.cluster.local
  2.  
  3. ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 <<>> @10.96.0.10 search.dev.svc.cluster.local
  4. ; (1 server found)
  5. ;; global options: +cmd
  6. ;; Got answer:
  7. ;; WARNING: .local is reserved for Multicast DNS
  8. ;; You are currently testing what happens when an mDNS query is leaked to DNS
  9. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62861
  10. ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
  11. ;; WARNING: recursion requested but not available
  12.  
  13. ;; OPT PSEUDOSECTION:
  14. ; EDNS: version: 0, flags:; udp: 4096
  15. ;; QUESTION SECTION:
  16. ;search.dev.svc.cluster.local.  IN      A
  17.  
  18. ;; ANSWER SECTION:
  19. search.dev.svc.cluster.local. 30 IN     CNAME   www.baidu.com.
  20. www.baidu.com.          30      IN      CNAME   www.a.shifen.com.
  21. www.a.shifen.com.       30      IN      A       110.242.68.3
  22. www.a.shifen.com.       30      IN      A       110.242.68.4
  23.  
  24. ;; Query time: 5 msec
  25. ;; SERVER: 10.96.0.10#53(10.96.0.10)
  26. ;; WHEN: Wed Apr 06 23:48:14 CST 2022
  27. ;; MSG SIZE  rcvd: 219
  28.  
  29. [root@master service]#

5.使用dig命令验证：

  1. [root@master service]# dig @10.96.0.10 search.dev.svc.cluster.local
  2.  
  3. ; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.el7_9.9 <<>> @10.96.0.10 search.dev.svc.cluster.local
  4. ; (1 server found)
  5. ;; global options: +cmd
  6. ;; Got answer:
  7. ;; WARNING: .local is reserved for Multicast DNS
  8. ;; You are currently testing what happens when an mDNS query is leaked to DNS
  9. ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62861
  10. ;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
  11. ;; WARNING: recursion requested but not available
  12.  
  13. ;; OPT PSEUDOSECTION:
  14. ; EDNS: version: 0, flags:; udp: 4096
  15. ;; QUESTION SECTION:
  16. ;search.dev.svc.cluster.local.  IN      A
  17.  
  18. ;; ANSWER SECTION:
  19. search.dev.svc.cluster.local. 30 IN     CNAME   www.baidu.com.
  20. www.baidu.com.          30      IN      CNAME   www.a.shifen.com.
  21. www.a.shifen.com.       30      IN      A       110.242.68.3
  22. www.a.shifen.com.       30      IN      A       110.242.68.4
  23.  
  24. ;; Query time: 5 msec
  25. ;; SERVER: 10.96.0.10#53(10.96.0.10)
  26. ;; WHEN: Wed Apr 06 23:48:14 CST 2022
  27. ;; MSG SIZE  rcvd: 219
  28.  
  29. [root@master service]#

6.使用如下命令可以删除资源：

  1. [root@master service]# kubectl delete -f external_name.yaml
  2. namespace "dev" deleted
  3. service "search" deleted
  4. [root@master service]#
声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/很楠不爱3/article/detail/189828
推荐阅读
相关标签

Copyright © 2003-2013 www.wpsshop.cn 版权所有，并保留所有权利。

  

闽ICP备14008679号