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

何谓 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对象应该定义成：