
Service 定义了这样一种抽象:逻辑上的一组 Pod,一种可以访问它们的策略 。pod重新部署之后ip就会变,所以一般通过service来访问pod。将service和pod通过某种方式绑定,就可以通过service访问pod了。同时也可以简单看作service做了一个负载均衡。就像springcloud中Eureka服务发现,通过名字就可以与真实的服务绑定。k8s中其实endpoints主要定义了真实服务(pod)的访问地址,service给出自己的name,其他资源对象就可以通过service的name来访问真实的服务(pod)。
spec 定义 Service 的行为。https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status
将 Service 流量路由到具有与此 selector 匹配的标签键值对的 Pod。
Service 将公开的端口。
在 Service 所针对的 Pod 上要访问的端口号或名称。 编号必须在 1 到 65535 的范围内。
此端口的 IP 协议。支持 “TCP”、“UDP” 和 “SCTP”。默认为 TCP。
当类型为 NodePort 或 LoadBalancer 时,Service 公开在节点上的端口, 通常由系统分配。
如果指定了一个在范围内且未使用的值,则将使用该值,否则操作将失败。
如果在创建的 Service 需要该端口时未指定该字段,则会分配端口。
如果在创建不需要该端口的 Service时指定了该字段,则会创建失败。
当更新 Service 时,如果不再需要此字段(例如,将类型从 NodePort 更改为 ClusterIP),这个字段将被擦除。 更多信息
externalIPs 是一个 IP 列表,集群中的节点会为此 Service 接收针对这些 IP 地址的流量。
这些 IP 不被 Kubernetes 管理。用户需要确保流量可以到达具有此 IP 的节点。
一个常见的例子是不属于 Kubernetes 系统的外部负载均衡器。
支持 “ClientIP” 和 “None”。用于维护会话亲和性。 启用基于客户端 IP 的会话亲和性。必须是 ClientIP 或 None。默认为 None。 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies
仅适用于服务类型: LoadBalancer。此功能取决于底层云提供商是否支持负载均衡器。 如果云提供商不支持该功能,该字段将被忽略。 已弃用: 该字段信息不足,且其含义因实现而异,而且不支持双栈。 从 Kubernetes v1.24 开始,鼓励用户在可用时使用特定于实现的注释。在未来的 API 版本中可能会删除此字段。
例如,假定有一组 Pod,它们对外暴露了 9376 端口,同时还被打上 app=MyApp 标签:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector: #将 Service 流量路由到具有与此 selector 匹配的标签键值对的 Pod。
app.kubernetes.io/name: MyApp #代理的是label为该key:value的pod
ports:
- protocol: TCP #pod的端口使用tcp协议
port: 80 #通过该端口访问该service
targetPort: 9376 #被代理的端口,也就是pod上开放的端口
Pod 中的端口定义是有名字的,你可以在 Service 的 targetPort 属性中引用这些名称。
在新版本中更改 Pod 中后端软件公开的端口号,而不会破坏客户端。
apiVersion: v1
kind: Pod
metadata:
name: nginx
labels:
app.kubernetes.io/name: proxy
spec:
containers:
- name: nginx
image: nginx:stable
ports:
- containerPort: 80
name: http-web-svc
---
apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app.kubernetes.io/name: proxy
ports:
- name: name-of-service-port
protocol: TCP
port: 80
targetPort: http-web-svc
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
ports:
- protocol: TCP
port: 80
targetPort: 9376
由于此服务没有选择算符,因此不会自动创建相应的 Endpoints 对象。 你可以通过手动添加 Endpoints 对象,将服务手动映射到运行该服务的网络地址和端口:( 请求将被路由到用户定义的 Endpoint)
apiVersion: v1
kind: Endpoints
metadata:
# 这里的 name 要与 Service 的名字相同
name: my-service
subsets:
- addresses:
- ip: 192.0.2.42
ports:
- port: 9376
端点 IPs 必须不可以 是:本地回路(IPv4 的 127.0.0.0/8, IPv6 的 ::1/128) 或本地链接(IPv4 的 169.254.0.0/16 和 224.0.0.0/24,IPv6 的 fe80::/64)。
端点 IP 地址不能是其他 Kubernetes 服务的集群 IP,因为 kube-proxy 不支持将虚拟 IP 作为目标。
最近观察到的 Service 状态。由系统填充。只读。 更多信息
Endpoints 是实现实际服务的端点的集合
而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。
提供标记为就绪的相关端口的 IP 地址。 这些端点应该被认为是负载均衡器和客户端可以安全使用的。
端点主机名称。
可选:承载此端点的节点。此字段可用于确定一个节点的本地端点。
对提供端点的对象的引用。
提供相关端口但由于尚未完成启动、最近未通过就绪态检查或最近未通过活跃性检查而被标记为当前未就绪的 IP 地址。
端点的 IP。不可以是本地环路(127.0.0.0/8)、链路本地(169.254.0.0/16)或链路本地多播(224.0.0.0/24)地址。 IPv6 也被接受,但并非在所有平台上都完全支持。 此外,诸如 kube-proxy 等某些 Kubernetes 组件还没有准备好支持 IPv6。
端点主机名称。
可选:承载此端点的节点。此字段可用于确定节点的本地端点。
对提供端点的对象的引用。
相关 IP 地址上可用的端口号。
端点的端口号。
此端口的 IP 协议。必须是 UDP、TCP 或 SCTP。默认值为 TCP。
端口的名称。此字段必须与相应 ServicePort 中的 name 字段匹配。必须是 DNS_LABEL。 仅当定义了一个端口时才可选。
端口的应用程序协议。此字段遵循标准的 Kubernetes 标签语法。 未加前缀的名称保留给 IANA 标准服务名称(遵循 RFC-6335 和 https://www.iana.org/assignments/service-names)。 非标准协议应使用带前缀名称,如 mycompany.com/my-custom-protocol。
Ingress 是对集群中服务的外部访问进行管理(将集群的服务暴露给集群外访问,就像nginx)的 API 对象,典型的访问方式是 HTTP。
用于配置 Ingress 的主机规则列表。如果未指定或没有规则匹配,则所有流量都将发送到默认后端。
Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时,通常使用 Service.Type=NodePort 或 Service.Type=LoadBalancer 类型的 Service。
不允许 IP。当前 IngressRuleValue 只能应用于父 Ingress Spec 中的 IP。
由于不允许使用端口,因此不理会 “:” 分隔符。 当前 Ingress 的端口隐式为:
:80 用于 http
:443 用于 https
这两种情况在未来都可能发生变化
HTTPIngressRuleValue 是指向后端的 http 选择算符列表。例如 http:///
将请求映射到后端的路径集合。
将路径与后端关联。与路径匹配的传入 URL 将转发到后端。
backend 定义将流量转发到的引用服务端点。
IngressBackend
描述给定服务和端口的所有端点。
IngressServiceBackend 需要端口名或端口号。
IngressServiceBackend 引用一个 Kubernetes Service 作为后端。
service 引用一个 Service 作为后端。此字段是一个与 resource 互斥的设置。
name 是引用的服务。服务必须与 Ingress 对象位于同一命名空间中。
ServiceBackendPort 是被引用的服务的端口。
name 是服务上的端口名称。此字段是一个与 number 互斥的设置。
number 是服务上的数字形式端口号(例如 80)。此字段是一个与 name 互斥的设置。
决定如何解释 path 匹配
Exact:与 URL 路径完全匹配。
Prefix:根据按 “/” 拆分的 URL 路径前缀进行匹配。
匹配是按路径元素逐个元素完成。路径元素引用的是路径中由“/”分隔符拆分的标签列表。 如果每个 p 都是请求路径 p 的元素前缀,则请求与路径 p 匹配。 请注意,如果路径的最后一个元素是请求路径中的最后一个元素的子字符串,则匹配不成功 (例如 /foo/bar 匹配 /foo/bar/baz,但不匹配 /foo/barbaz)。
ImplementationSpecific:路径匹配的解释取决于 IngressClass。 实现可以将其视为单独的路径类型,也可以将其视为前缀或确切的路径类型。 实现需要支持所有路径类型。
path 要与传入请求的路径进行匹配。 目前,它可以包含 RFC 3986 定义的 URL 的常规 “路径” 部分所不允许的字符。 路径必须以 “/” 开头,并且在 pathType 值为 “Exact” 或 “Prefix” 时必须存在。
status 是 Ingress 的当前状态。 更多信息
IngressClass 代表 Ingress 的类,被 Ingress 的规约引用。
spec 是 IngressClass 的期望状态。更多信息
parameters 是指向控制器中包含额外配置的自定义资源的链接。 如果控制器不需要额外的属性,这是可选的。
IngressClassParametersReference 标识一个 API 对象。这可以用来指定一个集群或者命名空间范围的资源
kind 是被引用资源的类型。
name 是被引用资源的名称。
apiGroup 是被引用资源的组。 如果未指定 apiGroup,则被指定的 kind 必须在核心 API 组中。 对于任何其他第三方类型,apiGroup 是必需的。
namespace 是被引用资源的命名空间。 当范围被设置为 “namespace” 时,此字段是必需的; 当范围被设置为 “Cluster” 时,此字段必须不设置。
scope 表示是否引用集群或者命名空间范围的资源。 这可以设置为“集群”(默认)或者“命名空间”。
为了让 Ingress 资源工作,集群必须有一个正在运行的 Ingress 控制器。
必须拥有一个 Ingress 控制器 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。就像只有nginx配置文件没有nginx服务是不行的。
与作为 kube-controller-manager 可执行文件的一部分运行的其他类型的控制器不同, Ingress 控制器不是随集群自动启动的。 基于此页面,你可选择最适合你的集群的 ingress 控制器实现。
Kubernetes 作为一个项目,目前支持和维护 AWS、 GCE 和 Nginx Ingress 控制器。
k8s的service和endpoint
ingress,ingressController,ingressClass
service详解