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 采用标准的 Kubernetes 控制器模式，根据 Service 当前属性持续同步 CLB 实例配置，以最终一致性机制确保云上负载均衡资源与 Kubernetes 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 时，会先删除自动创建的 CLB 实例，再删除 Service。对于已有删除时间戳的标记的 Service ，组件会不断重试删除自动创建的 CLB 实例资源。使用已有 CLB 时，删除 Service 时不会删除 CLB 实例。
Service 功能
Service 相关操作及功能如下，您可参考以下文档进一步了解：
Pod 优雅删除
