Kubernetes网络一年发展动态与未来趋势（下）

前言

书接上回，上回讲到K8S网络模型，CNI和Service，并留了一个开放性问题：如何从集群外访问K8S集群内的服务？这时候就轮到Ingress粉墨登场了。

K8S Ingress

何谓 Ingress？从字面意思解读，就是“入站流量”。K8S 的 Ingress 资源对象是指授权入站连接到达集群内服务的规则集合。具体含义看下面这个例子便一目了然：

通常情况下，Service 和 Pod 仅可在集群内部网络中通过 IP 地址访问。所有到达边界路由的流量或被丢弃或被转发到其他地方。Ingress 就是在边界路由处开个口子，放你进来。因此，Ingress 是建立在 Service 之上的 L7 访问入口，它支持通过 URL 方式将 Service 暴露到 K8S 集群外；支持自定义 Service 的访问策略；提供按域名访问的虚拟主机功能；支持 TLS 通信。

在上面这个例子，Ingress 就可以基于客户端请求的 URL 来做流量分发，转发给不同的 Service 后端。 我们来看下Ingress资源对象的API定义:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test-ingress
spec:
  tls:
  - secretName: testsecret
  backend:
    serviceName: testsvc
    servicePort: 80
复制代码

把上面这个 Ingress 对象创建起来后，kubectl ge 一把，会看到：

其中，ADDRESS 即 Ingress 的访问入口地址，由 Ingress Controller 分配，一般是 Ingress 的底层实现 LB 的 IP 地址，例如：Ingress，GCE LB，F5 等；BACKEND 是 Ingress 对接的后端 K8S Service IP + Port；RULE 是自定义的访问策略，主要是基于 URL 的转发策略，若为空，则访问 ADDRESS 的所有流量都转发给 BACKEND。

下面给出一个Ingress的rules不为空的例子。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: s1
          servicePort: 80
      - path: /bar
        backend:
          serviceName: s2
          servicePort: 80
复制代码

这个例子和上面那个最明显的区别在于，rules 定义了 path 分别为 /foo和 /bar 的分发规则，分别转发给 s1:80 和 s2:80。Kubectl get 一把一目了然：

需要注意的是，当底层 LB 准备就绪时，Ingress Controller 把 LB 的 IP 填充到 ADDRESS 字段。而在我们的例子中，这个 LB 显然还未 ready。

Ingress 是一个非常“极客”和需要 DIY 的产物，K8S 只负责提供一个 API 定义，具体的 Ingress Controller 需要用户自己实现！官方倒是提供了 Nginx 和 GCE 的 Ingress Controller 示例供开发者参考。实现一个 Ingress Controller 的大致框架无非是，List/Watch K8S 的 Service，Endpoints，Ingress 对象，刷新外部LB的规则和配置。

这还不算，如果想要通过域名访问 Ingress？需要用户自己配置域名和 Ingress IP 的映射关系，比如：host 文件，自己的 DNS（不是 kube-dns）。下文会讲到，“高冷”的 kube-dns 只会负责集群内的域名解析，集群外的一概不管。如果嫌麻烦，懒得开发/配置 Ingress？Huawei CCE了解一下？ Ingress + 高性能ELB ：）

K8S DNS

K8S DN S说，刚刚谁念叨起本宫了？

一言以蔽之，K8S 的 DNS，就是用来解析 K8S 集群内的 Pod 和 Service 域名的，而且一般是供 Pod 内的进程使用的！血统高贵，一般不给外人使用。那可能会有人好奇问一句，Pod 到底怎么使用K8S DNS呢？原来，kubelet配置--cluster-dns把DNS的静态IP传递给每个容器。K8S DNS 一般通过插件方式部署到 K8S 上，并为之绑定一个 Service，而 Service 的 Cluster IP往往是固定的。

K8S DNS 目前有两个实现，分别是 kube-dns 和 CoreDNS。

对于 Service，K8S DNS 服务器会生成两类 DNS 记录，分别是：A 记录和SRV记录。而 A 记录又对普通 Service 和 headless Service有所区别。

普通 Service 的 A 记录是：

{service name}.{service namespace}.svc.cluster.local -> Cluster IP 的映射关系。后面域名后面一串子域名：svc.cluster.local 是 Kubelet 通过 --cluster-domain 配置的伪域名。

Headless Service的A记录是：

{service name}.{service namespace}.svc.cluster.local -> 后端 Pod IP 列表的映射关系。

至于SRV记录，则是按照一个约定俗称的规定：

_{port name}._{port protocol}.{service name}.{service namespace}.svc.cluster.local –> Service Port 实现了对服务端口的查询。

对于Pod，A记录是：

{pod-ip}.{pod namespace}.pod.cluster.local -> Pod IP 如果Pod IP 是 1.2.3.4，上面的 {pod-ip} 即 1-2-3-4。Pod的A记录其实没什么用，因为如果都知道 Pod IP 了，还用查 DNS 吗？如果在 Pod Spec 指定 hostname 和 subdomain，那么 K8S DNS 会额外生成Pod的A记录就是： {hostname}.{subdomain}.{pod namespace}.pod.cluster.local –> Pod IP 同样，后面那一串子域名 pod.cluster.local 是 kubelet 配置的伪域名。

让我们看下kube-dns的架构吧。

如上图所示，kube-dns是“三进程”架构。

kubedns：/Watch K8S Service 和 Endpoints 变化。接入 SkyDNS，在内存中维护 DNS 记录，是 dnsmasq 的上游。
dnsmasq： DNS 配置工具，监听 53 端口，为集群提供 DNS 查询服务。提供 DNS 缓存，降低 kubedns 压力。
exechealthz： 健康检查，检查 kube-dns 和 dnsmasq 的健康需要注意的是，dnsmasq 是个 C++ 写的一个小程序，内存泄露的“老毛病”。虽然 kube-dns 血统纯正，而且早早地进入到 K8S 的“后宫”，也早有“名分”，但近来 CoreDNS 却独得 K8S SIG Network 的圣宠。CoreDNS 是个 DNS 服务器，原生支持 K8S，而且居然还是一个 CNCF 的项目！

与 kube-dns 的三进程架构不同，CoreDNS 就一个进程，运维起来更加简单。而且采用 Go 语言编写，内存安全，高性能。值得称道的是，CoreDNS 采用的是“插件链”架构，每个插件挂载一个 DNS 功能，保证了功能的灵活、易扩展。尽管资历不深，但却“集万千宠爱于一身”，自然是有两把刷子的。

值得一提的是，以上性能测试数据是不带 cache 情况下取得的，明显要高于 kube-dns。那么为什么建议使用 CoreDNS 呢？

K8S 官方已经将 CoreDNS 扶正，成为了默认模式。除了性能好以外，还有什么其他优势吗？Core DNS修复了 kube-dns 的一些“令人讨厌”的“老生常谈”的问题：

dns#55 - Allow custom DNS entries for kube-dns
dns#116 - Missing ‘A’ records for headless service with pods sharing * hostname
dns#131 - ExternalName not using stubDomains settings
dns#167 - Enable round robin A/AAAA records
dns#190 - kube-dns cannot run as non-root user
dns#232 - Use pod’s name instead of pod’s hostname in DNS SRV records

同时，还有一些吸引人的特性：

Zone transfers - list all records, or copy records to another server
Namespace and label filtering - expose a limited set of services
Adjustable TTL - adjust up/down default service record TTL
Negative Caching - By default caches negative responses (e.g. NXDOMAIN)

其中，原生支持基于 namespace 隔离和过滤 Service 和 Pod 的 DNS 记录这一条特性，在多租户场景下格外有用。

Network Policy

K8S默认情况下，底层网络是“全连通”的。但如果我们需要实现以下愿景：

即，只允许访问 default namespace 的 Label 是 app = web 的 Pod，default namespace 的其他 Pod 都不允许外面访问。这个隔离需求在多租户的场景下十分普遍。K8S 的解决方案是 Network Policy。

Network Policy 说白了就是基于 Pod 源 IP（所以 K8S 网络不能随随便便做SNAT啊！）的访问控制列表，限制 Pod 的进/出流量，用白名单实现了一个访问控制列表（ACL）。Network Policy 作为 Pod 网络隔离的一层抽象，允许使用 Label Selector，namespace selector，端口，CIDR 这四个维度限制 Pod 的流量进出。和I ngress 一副德行的是，K8S 对 Netowrk Policy 还是只提供了 API 定义，不负责实现！

一般情况下，Policy Controller 是由网络插件提供的。支持 Network Policy 的网络插件有 Calico，Cilium，Weave Net，Kube-router，Romana。需要注意的是，flannel 不在这个名单之列，似乎又找到了一个不用 flannel 的理由？

让我们先来见识几个默认网络策略：

注：{}代表允许所有，[]代表拒绝所有。

如果要拒绝所有流量进入呢？比如，场景长这样：

那么 Network Policy 对象应该定义成：

如果要限制部分流量进入呢？比如，场景长这样：

那么 Network Policy 对象应该定义成：

如果只允许特定 namespace 的 Pod 流量进入呢？比如，场景长这样：

那么 Network Policy 对象应该定义成：

如果限制流量从指定端口进入呢？比如，场景长这样：

那么，Network Policy对象应该定义成：

未来工作

最后，畅想下K8S网络后面的发展趋势。

首先，kubenet 会被废弃。 Kubenet 本来就是一个特定时期的产物，那时候 CNI 尚未成熟，让 K8S 亲自去干底层网络这种“苦差事”，尽管 K8S 是有一万个不愿意，但如果完全没有网络连通方案，又会让用户诟病“过于高冷”，“易用性差”，甚至会让那时的竞争对手 docker swarm 有机可图。因此K8S 写了一个简单的网络插件，即 kubenet，一个 bridge 模型的容器连通性解决方案。但随着 CNI 强势崛起，以及kubenet并不支持网络策略等硬伤，社区已经没了继续维护 kubenet 的热情，因此废弃 kubenet 也就被提上了议程。
IPv4/IPv6双栈支持。 经过大半年社区开发者的齐心协力，K8S 总算支持了 IPv6。但目前的支持比较初级，IPv6 还不能和IPv4 混用。IPv4/IPv6 的双栈支持，势在必行。 Pod Ready++。Pod 有 Ready 和非 Ready 状态之分，为何还要搞出个 Ready++ 这种“量子化”的模糊界限呢？原因在于，一个Pod能否真的对外提供服务，除了依赖容器内进程ready（我们会放置探针，检查进程状态）这类内部条件外，还依赖诸如：Ingress，Service，网络策略，外部LB等一系列外部因素。Pod Ready++ 的提出，就是为了将外部因素一齐纳入 Pod 状态的考量。
多网络。 也许是 K8S 的“单 Pod 单 IP”的网络模型过于深入人心了，以至于在实现过程中都谨遵这一“金科玉律”。但我们知道，网络的世界纷繁复杂，一块网卡怎么可能 cover 所有场景呢？据最简单的例子，一般我们会为一个 IO 密集型的作业配两块网络，一块网卡作为数据信道，另一块网卡则作为控制信道。从单网络到多网络的迁移，道路并不平坦，甚至是处处荆棘和沼泽，且不说网络插件，Service，DNS，Ingress 等实现要大改，光 API 兼容性就让你头疼。好消息是经过整整两年的拉锯，社区 Network Plumbing WG终于取得了阶段性成果，如不出意外的话，应该是 CRD + 多网路插件的形式支持K8S的多网络，保持 K8S 原生 API 的稳定。支持多网络的 CNI 插件有几个，但真真落到生产的没几个，CNI-genie 是其中一个有众多粉丝基础和经过生产环境检验的 K8S 多网络插件，了解一下？
最后，谈下Service Mesh。 严格说来，Service Mesh 并不在 K8S 核心的范围之内。但是，在 K8S 的帮助下，应用上云后，还面临着服务治理的难题。现在大多数云原生的应用都是微服务架构，微服务的注册，服务之间的相互调用关系，服务异常后的熔断、降级，调用链的跟踪、分析等待一系列现实问题摆在各机构面前。Service Mesh（服务网络）就是解决这类微服务发现和治理问题的一个概念。在我看来，Service Mesh 之于微服务架构就像 TCP 协议之于 web 应用。我们大部分人写web应用，关心的是 RESTful，HTTP 等上层协议，很少需要我们自己操心网络报文超时重传、分割组装、内容校验等底层细节。正是因为有了 Service Mesh，企业在云原生和微服务架构的实践道路上只需根据自己业务做适当的微服务拆分即可，无需过多关注底层服务发现和治理的复杂度。而 Istio 的出现，使得有些“学院派”的 Service Mesh 概念真正得到了落地，并且提供了真正可供操作、非侵入式的方案，让诸如 Spring Cloud，Dubbo 这些“老古董”第一次有了被淘汰的危机感。

如果你想深入学习 Service Mesh 和 Istio，请关注本公众号，我们会不定期推送相关技术干货。