11、网络Service

一、service

定义

Kubernetes 中 Service 是 将运行在一个或一组 Pod 上的网络应用程序公开为网络服务的方法。

Service API 是 Kubernetes 的组成部分，它是一种抽象，帮助你通过网络暴露 Pod 组合。 每个 Service 对象定义一个逻辑组的端点（通常这些端点是 Pod）以及如何才能访问这些 Pod 的策略。

Service 定义的抽象能够解耦这种关联。

Service 针对的这组 Pod 通常由你定义的选择算符来确定。 若想了解定义 Service 端点的其他方式，可以查阅不带选择算符的 Service。

service重要字段

FIELDS:
   allocateLoadBalancerNodePorts	<boolean>
     定义是否自动使用NodePorts，为LoadBalancer类型的服务分配。默认为true

   clusterIP	<string>
     clusterIP是服务的IP地址，通常会被分配随机。

   clusterIPs	<[]string>
    ClusterIPs是分配给该服务的IP地址列表，是通常是随机分配的。

   ports	<[]Object>
     服务公开的端口列表
      appProtocol	<string>该端口的应用协议。
   	  name	<string> service 名称
  	  nodePort	<integer> 当type为时，该服务在其上公开的每个节点上的端口NodePort或LoadBalancer。
      port	<integer> -required- 此服务将公开的端口。
      protocol	<string> 该端口的IP协议。支持“TCP”、“UDP”、“SCTP”。默认的TCP。
      targetPort	<string>服务所针对的pods上要访问的端口编号或名称。

   selector	<map[string]string>
     将服务流量路由到与此匹配的标签键和值的pod选择器。
     如果为空或不存在，则假定服务具有外部进程管理其端点，Kubernetes不会修改。
	只适用于ClusterIP、NodePort和LoadBalancer类型

   type	<string>
     ExternalName, ClusterIP, NodePort, and LoadBalancer
     ClusterIP分配一个用于负载均衡的集群内部IP地址port。port由选择器决定
     clusterIP为None，表示没有分配虚拟IP端点被发布为一组port，而不是虚拟IP。
     NodePort构建在ClusterIP上，并在每个节点上分配一个端口路由到与clusterIP相同的端点。
     LoadBalancer”是在此基础上构建的NodePort并创建一个外部负载平衡器(如果当前支持
     ExternalName将此服务别名化为指定的externalName。
     https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

service的创建

• yaml文件创建

  apiVersion: v1
  kind: Service
  metadata:
    name: my-service
  spec:
    selector:
      app.kubernetes.io/name: MyApp
    ports:
      - protocol: TCP
        port: 80
        targetPort: 9376
  

没有选择符的service

• 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。
• 希望服务指向另一个 名字空间（Namespace） 中或其它集群中的服务。
• 你正在将工作负载迁移到 Kubernetes。在评估该方法时，你仅在 Kubernetes 中运行一部分后端。

多端口的service

对于某些服务，你需要公开多个端口。 Kubernetes 允许你在 Service 对象上配置多个端口定义。 为服务使用多个端口时，必须提供所有端口名称，以使它们无歧义

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - name: http
      protocol: TCP
      port: 80
      targetPort: 9376
    - name: https
      protocol: TCP
      port: 443
      targetPort: 9377

类型服务

无头服务

有时不需要或不想要负载均衡，以及单独的 Service IP。 遇到这种情况，可以通过指定 Cluster IP（spec.clusterIP）的值为 "None" 来创建 Headless Service。

发布服务

对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部的 IP 地址。

Type 的取值以及行为如下：

• ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是你没有为服务显式指定 type 时使用的默认值。 你可以使用 Ingress 或者 Gateway API 向公众暴露服务。
• NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 为了让节点端口可用，Kubernetes 设置了集群 IP 地址，这等同于你请求 type: ClusterIP 的服务。
• LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
• ExternalName：通过返回 CNAME 记录和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。

nodeport

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    # 默认情况下，为了方便起见，`targetPort` 被设置为与 `port` 字段相同的值。
    - port: 80
      targetPort: 80
      # 可选字段
      # 默认情况下，为了方便起见，Kubernetes 控制平面会从某个范围内分配一个端口号（默认：30000-32767）
      nodePort: 30007

LoadBalancer 类型

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

二、ingress

定义

Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。Ingress 可以提供负载均衡、SSL 终结和基于名称的虚拟托管。

Ingress 公开从集群外部到集群内服务的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。

image-20230401173426576

安装ingress

wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v0.47.0/deploy/static/provider/baremetal/deploy.yaml

#修改镜像
vi deploy.yaml
#将image的值改为如下值：
registry.cn-hangzhou.aliyuncs.com/lfy_k8s_images/ingress-nginx-controller:v0.46.0

# 检查安装的结果
kubectl get pod,svc -n ingress-nginx

# 最后别忘记把svc暴露的端口要放行

ingress资源

每个rules都包含以下规则

• host 可选。提供了 host（例如 foo.bar.com），则 rules 适用于该 host。
• 路径列表。每个路径都有一个由 service.name 和 service.port.name 或 service.port.number 定义的关联后端。 在负载均衡器将流量定向到引用的服务之前，主机和路径都必须匹配传入请求的内容。
• backend。是 Service 文档中所述的服务和端口名称的组合， 或者是通过 CRD 方式来实现的自定义资源后端。 与规则的 host 和 path 匹配的对 Ingress 的 HTTP（和 HTTPS ）请求将发送到列出的 backend。

默认后端

没有设置规则的 Ingress 将所有流量发送到同一个默认后端，而 .spec.defaultBackend 则是在这种情况下处理请求的那个默认后端。 defaultBackend 通常是 Ingress 控制器的配置选项， 而非在 Ingress 资源中指定。 如果未设置任何的 .spec.rules，那么必须指定 .spec.defaultBackend。 如果未设置 defaultBackend，那么如何处理所有与规则不匹配的流量将交由 Ingress 控制器决定

资源后端

Resource 后端是一个引用，指向同一命名空间中的另一个 Kubernetes 资源，将其作为 Ingress 对象。 Resource 后端与 Service 后端是互斥的，在二者均被设置时会无法通过合法性检查。 Resource 后端的一种常见用法是将所有入站数据导向带有静态资产的对象存储后端。

路径类型

Ingress 中的每个路径都需要有对应的路径类型（Path Type）。未明确设置 pathType 的路径无法通过合法性检查。当前支持的路径类型有三种：

• ImplementationSpecific：对于这种路径类型，匹配方法取决于 IngressClass。 具体实现可以将其作为单独的 pathType 处理或者与 Prefix 或 Exact 类型作相同处理。
• Exact：精确匹配 URL 路径，且区分大小写。
• Prefix：基于以 / 分隔的 URL 路径前缀匹配。匹配区分大小写，并且对路径中的元素逐个完成。 路径元素指的是由 / 分隔符分隔的路径中的标签列表。 如果每个 p 都是请求路径 p 的元素前缀，则请求与路径 p 匹配。

简单示例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: minimal-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  ingressClassName: nginx-example
  rules:
  # http 规则
  - http:
      paths:
      - path: /testpath
        pathType: Prefix
        backend:
          service:
            name: test
            port:
              number: 80

三、calico网络组件