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 get一把，会看到：
其中，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 DNS说，刚刚谁念叨起本宫了？
一言以蔽之，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：List/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功能，保证了功能的灵活、易扩展。尽管资历不深，但却“集万千宠爱于一身”，自然是有两把刷子的。
| Services (with 1% change per minute*) | Max QPS | Latency (Median) | CoreDNS memory (at max QPS) | CoreDNS CPU (at max QPS) |
| 1,000 | 18,000 | 0.1 ms | 38 MB | 95% |
| 5,000 | 16,000 | 0.1 ms | 73 MB | 93% |
| 10,000 | 10,000 | 0.1 ms | 115 MB | 78% |
值得一提的是，以上性能测试数据是不带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的流量进出。和Ingress一副德行的是，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，请关注本公众号，我们会不定期推送相关技术干货。
