8 服务发现_我的服务发现搜索服务 jau 点击"发现",探索更多服务发现-CSDN博客

本文链接：https://blog.csdn.net/xzpdxz/article/details/116051567

本文概述了Kubernetes中的Service对象如何实现服务发现和负载均衡，以及Ingress如何作为集群外部访问的入口。介绍了Service的使用、Endpoints的工作原理，并对比了不同版本的kube-proxy代理。重点讲解了Ingress的配置和其在7层服务中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Ingress服务发现

Kubernetes中为了实现服务实例间的负载均衡和不同服务间的服务发现，创造了Serivce对象，同时又为从集群外部访问集群创建了Ingress对象。

Service

service就是访问一组pod的策略，可以理解为在扩容时，有多个pod，那么访问这些pod时，我们访问service，由service去负载均衡，这样我们也不用关心pod内分配的ip是什么。简单理解就是一种ninx的负载均衡器

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector: # 属性选择器，关联到pod上
     app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

以下这种是关联外部应用，相当于service仅仅用做负载均衡器

kind: Endpoints
apiVersion: v1
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 1.2.3.4
    ports:
      - port: 9376

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

在 Kubernetes v1.0 版本，代理完全在 userspace，Service 是 “4层”（TCP/UDP over IP）概念。

在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。新增了 Ingress API（beta 版），用来表示 “7层”（HTTP）服务。

Ingress

Ingress 是从Kubernetes集群外部访问集群内部服务的入口

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: s1
          servicePort: 80
  - host: bar.foo.com
    http:
      paths:
      - backend:
          serviceName: s2
          servicePort: 80