k8s集群service外部流量策略如何优雅的处理Pod终止过程中的流量丢失问题？

k8s集群service外部流量策略如何优雅的处理Pod终止过程中的流量丢失问题？

面试官："k8s集群service外部流量策略如何优雅的处理Pod终止过程中的流量丢失问题？"

面试官："service是如何实现服务发现的？"

面试官："环境变量模式发布能够访问 `ExternalName` 类型的 Service嘛？"

面试官："可以指定哪些服务类型允许 Kubernetes 集群向外暴露服务？"

面试官："Ingress同样可以暴露k8s服务属于service类型服务嘛？"

囧么肥事-胡说八道

k8s集群service服务代理流量策略了解嘛？

service流量策略可以划分为两类：外部流量策略和内部流量策略

外部流量策略如何优雅的处理Pod终止过程中的流量丢失？

首先说说什么是外部流量策略

通过设置 spec.externalTrafficPolicy 字段，来控制来自于外部的流量是如何路由的。 可选值有 Cluster 和 Local。字段设为 Cluster 会将外部流量路由到所有就绪的端点， 设为 Local 会只路由到当前节点上就绪的端点。 如果流量策略设置为 Local，而且当前节点上没有就绪的端点，kube-proxy 不会转发请求相关服务的任何流量。

关于流量丢失问题，需要启用 kube-proxy 的 ProxyTerminatingEndpoints 特性，实现检查转发。

如果你启用了 kube-proxy 的 ProxyTerminatingEndpoints 特性， kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。

如果本地有端点，而且所有端点处于终止中的状态，那么 kube-proxy 会忽略任何设为 Local 的外部流量策略。 在所有本地端点处于终止中的状态的同时，kube-proxy 将请求指定服务的流量转发到位于其它节点的 状态健康的端点，如同外部流量策略设为 Cluster。

针对处于正被终止状态的端点，这一转发行为使得外部负载均衡器可以优雅地排出由 NodePort 服务支持的连接，就算是健康检查节点端口开始失败也是如此。 否则，当节点还在负载均衡器的节点池内，在 Pod 终止过程中的流量会被丢掉，这些流量可能会丢失。

内部流量策略

通过设置 spec.internalTrafficPolicy 字段来控制内部来源的流量是如何转发的。可设置的值有 Cluster 和 Local。 将字段设置为 Cluster 会将内部流量路由到所有就绪端点，设置为 Local 只会路由到当前节点上就绪的端点。 如果流量策略是 Local，而且当前节点上没有就绪的端点，那么 kube-proxy 会丢弃流量。

service是如何实现服务发现的？

Kubernetes 支持两种基本的服务发现模式 —— 环境变量和 DNS。

首先是环境变量

当 Pod 运行在 Node 上，kubelet 会为每个活跃的 Service 添加一组环境变量。 还有一点的好处就是它同时支持Docker links兼容变量 、 以及简单的 {SVCNAME}_SERVICE_HOST 和 {SVCNAME}_SERVICE_PORT 变量。需要注意的是，Service 的名称需大写，横线被转换成下划线。

举个例子，一个名称为 redis-master 的 Service 暴露了 TCP 端口 6379， 同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量：

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379
REDIS_MASTER_PORT=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP=tcp://10.0.0.11:6379
REDIS_MASTER_PORT_6379_TCP_PROTO=tcp
REDIS_MASTER_PORT_6379_TCP_PORT=6379
REDIS_MASTER_PORT_6379_TCP_ADDR=10.0.0.11

注意

如果使用的是环境变量方法将端口和集群 IP 发布到客户端 Pod 时，需要在客户端Pod出现前，完成需要访问的服务的Pod的创建。否则，这些客户端 Pod 将不会设定其环境变量。

当然了，如果仅使用 DNS 查找服务的集群 IP，则无需担心此设定问题。

在看看DNS方式

支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 如果在整个集群中都启用了 DNS，则所有 Pod 都应该能够通过其 DNS 名称自动解析服务。

例如，如果你在 Kubernetes 命名空间 my-ns 中有一个名为 my-service 的服务， 则控制平面和 DNS 服务共同为 my-service.my-ns 创建 DNS 记录。 my-ns 命名空间中的 Pod 应该能够通过按名检索 my-service 来找到服务 （my-service.my-ns 也可以工作）。

其他命名空间中的 Pod 必须将名称限定为 my-service.my-ns，这些名称将解析为服务分配的集群 IP。

Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 如果 my-service.my-ns 服务具有名为 http　的端口，且协议设置为 TCP， 则可以对 _http._tcp.my-service.my-ns 执行 DNS SRV 查询查询以发现该端口号, "http" 以及 IP 地址。

Kubernetes DNS 服务器是唯一的一种能够访问 ExternalName 类型的 Service 的方式。

注意：给Kubernetes 集群设置 DNS 服务是一个刚需，钢铁刚需。

可以指定哪些服务类型允许 Kubernetes 集群向外暴露服务？

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

Kubernetes ServiceTypes 允许指定你所需要的 Service 类型，默认是 ClusterIP。

Type 的取值以及行为如下：

• ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType。
• NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。
• LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
• ExternalName：通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。注意：kube-dns 1.7 及以上版本或者 CoreDNS 0.0.8 及以上版本才支持 ExternalName。

你也可以使用 Ingress 来暴露自己的服务。 Ingress 不是一种服务类型，但它充当集群的入口点。 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。可以类比 Nginx 。

k8s系列所有问题更新记录： GitHub ,  Gitee