#dns

Cilium 1.4：多集群服务路由，DNS授权，IPVLAN支持，透明加密，Flannel集成，与其他CNI的基准测试，…… 通告 我们很高兴地宣布Cilium 1.4版本。 该版本引入了几项新功能以及优化和可扩展性工作。 重点包括增加全局服务，提供跨多个集群的Kubernetes服务路由、DNS请求/响应感知授权和可见性、透明加密（beta）、IPVLAN支持以获得更好的性能和延迟（beta）、与Flannel集成、GKE在COS上支持、基于AWS元数据的策略实施（alpha）以及优化内存和CPU使用的重要工作。 像往常一样，感谢过去4个月中在版本1.3和1.4之间贡献了1048次提交的Cilium开发人员及整个社区。 Cilium是什么？ Cilium是一个开源软件，用于透明地提供和保护使用Kubernetes、Docker和Mesos等Linux容器管理平台部署的应用程序服务之间的网络和API连接。 Cilium的基础是一种名为BPF的新Linux内核技术，它可以在Linux本身内动态插入强大的安全性、可见性和网络控制逻辑。BPF用于提供诸如多集群路由，负载均衡以取代kube-proxy，使用X.509证书的透明加密以及网络和服务安全性等功能。除了提供传统的网络级安全性之外，BPF的灵活性还可以通过应用程序协议和DNS请求/响应的上下文实现安全性。Cilium与Envoy紧密集成，并提供基于Go的扩展框架。由于BPF在Linux内核中运行，因此可以应用所有Cilium功能，而无需对应用程序代码或容器配置进行任何更改。 有关 Cilium 的更详细的介绍， 请参阅Cilium简介 一节。 多集群服务路由 Cilium 1.3在多个集群之间引入了基本的pod IP路由功能。Cilium 1.4引入了基于标准Kubernetes服务的全局服务概念。全局服务允许用户指定Kubernetes服务在多个集群中可用。然后，该服务可以在多个集群中具有后端pod。 用户体验就像在每个集群中定义具有相同名称和命名空间的Kubernetes服务并添加注释以将其标记为全局一样简单。 当pod向上或向下扩展或变得不健康时，Kubernetes运行状态检查信息可用于自动添加和删除后端服务。 控制平面建立在etcd之上，类似于Kubernetes原生的操作方式，具有弹性和简单性作为其基本设计模式。每个集群继续运行其自己的etcd集群，并且复制以只读方式进行，这可确保集群中的故障不会影响其他集群。 将集群连接在一起就像使用云供应商的标准路由API或基于常规IP地址的VPN网关和隧道的本地基础设施在VPC之间提供路由，然后通过内部Kubernetes负载均衡器暴露Cilium控制平面以将其暴露给内部VPC一样简单。TLS用于使用作为Kubernetes Secret管理的证书和密钥对客户端和服务器进行身份验证。 IPVLAN支持（测试版） 添加了一种新的基于IPVLAN的数据路径模式。与基于veth的体系结构相比，IPVLAN具有低延迟优势。使用netperf在3.40Ghz Xeon上的两个本地容器之间测量了以下基准测试，并使用单核禁用超线程。与veth相比，IPVLAN的P99延迟相对较低（越低越好）： IPVLAN和veth之间的最大吞吐量（越高越好）非常相似，但是通过从内核编译netfilter/iptables可以实现非常显着的性能提升。如果您不使用NodePort服务并且在离开Kubernete worker node时不需要伪装网络流量，则已经可以完全运行您的Kubernetes集群。我们将在接下来的几周内提供有关如何运行iptables和kube-proxy的指南。 IPVLAN是1.4中的beta级功能，有关如何启用和配置该功能的说明，请参阅 IPVLAN入门指南 。 DNS请求/响应的安全性和可见性 Cilium 1.4扩展了现有的DNS安全策略模型，以了解各个pod发出的DNS请求以及它们收到的DNS响应。 这显着提高了访问集群外部服务的pod的安全性： 在执行DNS查找时，可以将Pod限制为具有最小权限，即 pod可以仅限于查找匹配模式的DNS名称，例如 *.domain.com 。 任何超出允许模式的请求都将收到 request refused DNS响应。 DNS查找后的通信可以限制为特定pod接收的DNS响应中返回的IP地址。 这显着降低了受损应用程序的权限，并提高了基于DNS的策略规则的可靠性，因为执行逻辑不再需要知道DNS名称可以映射到的所有可能的IP地址。 特别是对于云供应商提供的流行存储，消息传递和数据库服务，单个DNS名称可以映射到数百或数千个IP地址。 现在可以通过API访问的Cilium授权日志记录层记录DNS查找和响应。 这提供了pod执行的每个DNS请求和响应的精确日志。 上面的示例显示了一个成功的DNS序列，然后是DNS服务器响应的对IP的HTTP请求。 这是应用程序的行为方式和允许的方式。 后续HTTP请求可以使用缓存的DNS信息，允许此类请求。 DNS信息将根据记录中的TTL信息超时。 右侧是应用程序在允许的DNS策略之外执行DNS查找的序列。 它还显示，如果应用程序无法执行DNS查找，则在应用程序无法在以下位置查找DNS名称时，即使IP地址实际映射到允许的DNS名称，也会阻止任何尝试联系IP地址的尝试。一点。 策略示例 apiVersion: "cilium.io/v2" kind: CiliumNetworkPolicy metadata: name: "egress-domain-wildcard" spec: endpointSelector: matchLabels: app: myService egress: - toEndpoints: - matchLabels: 'k8s:io. [Read More]