共计 3613 个字符，预计需要花费 10 分钟才能阅读完成。
k8s 服务拓扑设置定向流量有哪些常见场景？
面试官："说说你对 Kubernetes 网络模型的了解？设计这种网络模型有什么益处？"面试官："Kubernetes 网络次要解决哪四方面的问题？"面试官："k8s 利用服务拓扑的流量路由策略来设置定向流量，拓扑键的匹配规定是什么？"面试官："日常应用拓扑键有什么束缚？"面试官："简略说说服务拓扑设置定向流量有哪些常见场景？试举例说明？"
囧么肥事 - 胡言乱语
说说你对 Kubernetes 网络模型的了解？设计这种网络模型有什么益处？
集群网络系统是 Kubernetes 的外围局部，Kubernetes 的主旨就是 在利用之间共享机器。
要解决的问题？
通常来说，共享机器须要两个利用之间 不能应用雷同的端口 ，然而在多个利用开发者之间 去 大规模地协调端口是件很艰难的事件 ，尤其是还要 让用户裸露在他们管制范畴之外的集群级别的问题上。
动态分配端口 也会给零碎带来很多复杂度 – 每个利用都须要设置一个端口的参数，而 API 服务器还须要晓得如何将动静端口数值插入到配置模块中，服务也须要晓得如何找到对方等等。
针对这些问题，Kubernetes 设计了一种洁净的、向后兼容的网络模型，即 IP-per-pod 模型。怎么说？
首先，Kubernetes 强制规定了一种简略粗犷的网络模型设计根底准则：每个 Pod 都领有一个独立的 IP 地址。
Kubernetes 强制要求所有网络设施都满足以下根本要求（从而 排除了无意隔离网络的策略）：
节点上的 Pod 能够不通过 NAT 和其余任何节点上的 Pod 通信节点上的代理（比方：零碎守护过程、kubelet）能够和节点上的所有 Pod 通信
另外，对于反对在 主机网络中运行 Pod 的平台（比方：Linux）：
运行在节点主机网络里的 Pod 能够不通过 NAT 和所有节点上的 Pod 通信须要留神的是：在 K8S 集群中，IP 地址调配是以 Pod 对象为单位，而非容器，同一 Pod 内的所有容器共享同一网络名称空间。
Kubernetes 的 IP 地址存在于
Pod范畴内 – 容器共享它们的网络命名空间 – 包含它们的 IP 地址和 MAC 地址
这意味着什么？
意味着 k8s 假设所有 Pod 都在一个能够间接连通的、扁平的网络空间中也就是说，无论容器运行在集群中的哪个节点 ，所有容器之间都能通过一个扁平的网络立体进行通信。不论它们是否运行在同一个 Node 节点 (宿主机) 上，都要求它们能够 间接通过对方的 IP 进行拜访 。每一个 Pod 都有它本人的 IP 地址，益处就是你不须要再显式地在 Pod 之间创立链接，简直 不须要解决容器端口到主机端口之间的映射。
从端口调配、命名、服务发现、负载平衡、利用配置和迁徙的角度来看在这个模型，所有的
Pod都能够被视作虚拟机或者物理主机。
Kubernetes 网络次要解决哪四方面的问题？
首先，k8s 的架构体系决定了在 K8S 上的网络通信四大类：
- 第一类：高度耦合的容器之间的通信：同一个 Pod 内的多个容器之间通过本地回路（loopback）通信。
- 第二类：Pod 之间的通信：集群网络在不同 pod 之间通过 Pod IP 地址进行通信。
- 第三类：Pod 和 Service 之间的通信：Pod IP 地址和 Service IP 进行通信，两者并不属于同一网络，应用 Services 来公布仅供集群外部应用的服务，实现形式是通过 IPVS 或 iptables 规定转发。
- 第四类：Service 和集群内部客户端之间的通信，Service 容许对外裸露 Pods 中运行的应用程序，以反对来自于集群内部的拜访，实现形式：Ingress、NodePort、Loadbalance
k8s 利用服务拓扑的流量路由策略来设置定向流量，拓扑键的匹配规定是什么？
在说拓扑键的匹配规定之前，先理解下什么是服务拓扑的流量路由策略？
服务拓扑（Service Topology）能够让一个服务基 于集群的 Node 拓扑 进行流量路由。
例如，一个服务能够指定流量是被优先路由到一个和客户端在同一个 Node 或者在同一可用区域的端点。
默认状况下，发往 ClusterIP 或者 NodePort 服务的流量可能会被路由到服务的 任一后端的地址。
Kubernetes 1.7 容许将“内部”流量路由到接管到流量的 节点上的 Pod。对于 ClusterIP 服务，无奈实现同节点优先的路由 ，你也 无奈配置集群优选路由到同一可用区中的端点。
流量路由拓扑策略了解
通过在 Service 上配置 topologyKeys，对源和目标之间的标签匹配 ，能够 基于起源节点和指标节点的标签来定义流量路由策略。
对于拓扑键，能够依据节点间彼此“较近”和“较远”来定义节点汇合，能够基于合乎本身需要的任何度量值来定义标签，来匹配定向流量。
应用服务拓扑，拓扑键的匹配规定是什么？
如果集群启用了 ServiceTopology个性，你就能够在 Service 规约中设定 topologyKeys 字段，从而管制其流量路由。此字段是 Node 标签的 优先程序字段 ，将用于在拜访这个 Service 时 对端点进行排序 。流量会被 定向到第一个标签值 和源 Node 标签值相匹配的 Node。如果这个 Service 没有匹配的后端 Node，那么 第二个标签会被应用做匹配，以此类推，直到没有标签。
如果没有匹配到，流量会被回绝 ，就如同这个 Service 基本没有后端。换言之，零碎依据可用 后端的第一个拓扑键来抉择端点 。如果这个字段被配置了而没有后端能够匹配客户端拓扑，那么这个 Service 对那个客户端是没有后端的，链接应该是失败的。这个字段配置为 "*" 意味着 任意拓扑 。这个通配符值如果应用了，那么只有作为配置值列表中的 最初一个才有用。
如果 topologyKeys 没有指定或者为空，就没有启用这个拓扑束缚。
拓扑键有什么束缚？
拓扑键的束缚，其实就是应用拓扑键须要留神躲避的一些准则，在规定上更好的实现流量管制：
- 服务拓扑和
externalTrafficPolicy=Local是不兼容的，所以Service不能同时应用这两种个性。然而在同一个集群的不同Service上是 能够别离应用这两种个性 的，只有不在同一个Service上就能够。 - 无效的拓扑键目前只有：
kubernetes.io/hostname、topology.kubernetes.io/zone和topology.kubernetes.io/region，然而将来会推广到其它的Node标签。 - 拓扑键必须是 无效的标签，并且最多指定 16 个。
- 通配符：
"*"，如果要用，则 必须是拓扑键值的最初一个值。
简略说说服务拓扑设置定向流量有哪些常见场景？试举例说明？
在一个集群中，其 Node 的标签被打为其 主机名，区域名和地区名。那么就能够设置 Service 的 topologyKeys 的值，管制流量路由。
例如，在私有云上，你可能更偏差于把流量管制在同一区内，因为区间流量是有费用老本的，而区内流量则没有。
常见需要还包含把流量路由到由
DaemonSet治理的本地 Pod 上，或者把将流量转发到连贯在同一机架交换机的节点上，以取得低延时。
以下是应用服务拓扑性能的一些经典的常见示例
- 第一种：仅路由到节点本地端点，如果节点上不存在端点，流量则被抛弃，只定向到同一个
Node上的端点，Node上没有端点存在时就失败：配置["kubernetes.io/hostname"]。 - 第二种：首先节点本地端点，如果节点本地端点不存在，则回退到集群范畴端点：配置[“kubernetes.io/hostname”, “*”]
- 第三种：偏差定向到同一个
Node上的端点，回退同一区域的端点上，而后是同一地区，其它状况下就失败。例如，数据局部性很重要的状况下或者就很有用：配置["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region"]。 - 第四种：偏差于同一区域 ，但如果此区域中没有可用的终结点，则 回退到任何可用的终结点：配置
["topology.kubernetes.io/zone", "*"]。 - 第五种：仅地区或区域端点，首选地区端点而不是区域端点的一种服务，如果以上两种范畴内均不存在端点，流量则被抛弃。配置：[“topology.kubernetes.io/zone”, “topology.kubernetes.io/region”]
- 第六种：优先选择节点本地端点、地区端点，而后是区域端点，最初才是集群范畴端点。配置：
["kubernetes.io/hostname", "topology.kubernetes.io/zone", "topology.kubernetes.io/region", "*"]。
Kubernetes 举荐学习书
Kubernetes 权威指南 PDF
链接:https://pan.baidu.com/s/11huL… 提取码:sa88
k8s 系列所有问题更新记录：GitHub Gitee
