Service 基本概念
用户在 Kubernetes 中可以部署各种容器,其中一部分是通过 HTTP、HTTPS 协议对外提供七层网络服务,另一部分是通过 TCP、UDP 协议提供四层网络服务。而 Kubernetes 定义的 Service 资源就是用来管理集群中四层网络的服务访问。
Kubernetes 的 ServiceTypes 允许指定 Service 类型,默认为 ClusterIP 类型。ServiceTypes 的可取值以及行为描述如下:
可取值 | 说明 |
ClusterIP | 通过集群的内部 IP 暴露服务。当您的服务只需要在集群内部被访问时,请使用该类型。该类型为默认的 ServiceType。 |
NodePort | 通过每个集群节点上的 IP 和静态端口(NodePort)暴露服务。NodePort 服务会路由到 ClusterIP 服务,该 ClusterIP 服务会自动创建。通过请求 <NodeIP>:<NodePort> ,可从集群的外部访问该 NodePort 服务。除了测试以及非生产环境以外,不推荐在生产环境中直接通过集群节点对外甚至公网提供服务。从安全上考虑,使用该类型会直接暴露集群节点,容易受到攻击。通常认为集群节点是动态的、可伸缩的,使用该类型使得对外提供服务的地址和集群节点产生了耦合。 |
LoadBalancer | 使用腾讯云的负载均衡器,可以向公网或者内网暴露服务。负载均衡器可以路由到 NodePort 服务,或直接转发到处于 VPC-CNI 网络条件下的容器中。 |
ClusterIP 和 NodePort 类型的 Service,在不同云服务商或是自建集群中的行为表现通常情况下相同。而 LoadBalancer 类型的 Service,由于使用了云服务商的负载均衡进行服务暴露,云服务商会围绕其负载均衡的能力提供不同的额外功能。例如,控制负载均衡的网络类型,后端绑定的权重调节等,详情请参见 Service 功能文档。
服务访问方式
根据上述
ServiceTypes
定义,您可以使用腾讯云容器服务 TKE 提供的以下四种服务访问方式:访问方式 | Service 类型 | 说明 |
公网 | LoadBalancer | 使用 Service 的 LoadBalancer 模式,公网 IP 可直接访问到后端的 Pod,适用于 Web 前台类的服务。 创建完成后的服务在集群外可通过负载均衡域名或 IP + 服务端口访问服务,集群内可通过服务名 + 服务端口访问服务。
|
VPC 内网 | LoadBalancer | 使用 Service 的 LoadBalancer 模式,指定注解 service.kubernetes.io/qcloud-loadbalancer-internal-subnetid: subnet-xxxxxxxx ,即可通过内网 IP 直接访问到后端的 Pod。创建完成后的服务在集群外可通过负载均衡域名或 IP + 服务端口访问服务,集群内可通过服务名 + 服务端口访问服务。 |
主机端口访问 | NodePort | 提供一个主机端口映射到容器的访问方式,支持 TCP、UDP、Ingress。可用于业务定制上层 LB 转发到 Node。 创建完成后的服务可以通过云服务器 IP + 主机端口访问服务。 |
仅集群内访问 | ClusterIP | 使用 Service 的 ClusterIP 模式,自动分配 Service 网段中的 IP,用于集群内访问。数据库类等服务如 MySQL 可以选择集群内访问,以保证服务网络隔离。 创建完成后的服务可以通过服务名 + 服务端口访问服务。 |
负载均衡相关概念
Service 工作原理
腾讯云容器集群中的 Service Controller 组件负责用户 Service 资源的同步。当用户创建、修改或删除 Service 资源时、集群节点或 Service Endpoints 出现变化时、组件容器发生飘移重启时,组件都会对用户的 Service 资源进行同步。
Service Controller 会依照用户 Service 资源的描述创建对应的负载均衡资源,并对监听器及其后端进行配置。当用户删除集群 Service 资源时,也会回收对应负载均衡资源。
Service 生命周期管理
Service 对外服务的能力依赖于负载均衡所提供的资源,服务资源管理也是 Service 的重要工作之一。Service 在资源的生命周期管理中会使用以下标签:
tke-createdBy-flag = yes
:标识该资源是由容器服务创建。tke-clusterId = <ClusterId>
:标识该资源被哪一个 Cluster 所使用的。tke-lifecycle-owner = tke|user
:标识 CLB 的控制权是 TKE 还是用户,如果值是 user,删除 Service 时不会删除负载均衡。说明:
tke-createdBy-flag
和 tke-clusterId
这两个标签对用户只读,请不要修改或删除这些标签,否则可能导致资源泄漏。若用户使用了已有负载均衡,则 Service 仅会使用该负载均衡,而不会删除该负载均衡。
若用户将
tke-lifecycle-owner
置为 user,或者使用 私有连接,则删除 Service 时,不会删除该负载均衡。当 LoadBalancer 类型的 Service 集群资源被创建时,对应负载均衡的生命周期就开始了。直到 Service 资源被删除或是负载均衡被重建时,负载均衡的生命周期就结束了。在此期间负载均衡会持续根据 Service 资源的描述进行同步。当用户切换 Service 的网络访问时,例如公网 > Cluster IP、VPC 内网 > Cluster IP、Cluster IP 切换成使用的已有负载均衡,此类操作都会涉及到负载均衡的删除或销毁。LoadBalancer 类型 Service 工作原理如下图所示:
Service 注意事项
请勿在负载均衡控制台手动删除 Service 所关联的 CLB 实例,也不能手动修改 CLB 的配置,一切 CLB 相关操作都应在 TKE 侧进行。
Service 有一个字段:
.spec.externalTrafficPolicy
。kube-proxy 基于 spec.internalTrafficPolicy 的设置来过滤路由的目标服务端点。当它的值设为 Local
时,只会选择节点本地的服务端点。当它的值设为 Cluster
或缺省时,Kubernetes 会选择所有的服务端点。更多请参见 Kubernetes 文档。如果 Service 使用了 Local
方式,当 Pod 从 TKE 节点调度到超级节点,或者从超级节点调度到 TKE 节点的时候会出现断流,因为 Service 仅会选择本地的服务端点。Service 功能
Service 相关操作及功能如下,您可参考以下文档进一步了解:
Pod 优雅删除