从 Kubernetes 谈容器网络

原创 2015年06月10日 16:54:06

基本概念

在 Kubernetes 中,资源从管理粒度上分为三级:容器、Pod、Service。

容器

即 Docker 或者 Rocket 容器(1.0 中仅支持这两种容器)。

容器是最低粒度的资源,但是不能被直接操作。

Pod

Kubernetes 中的基本操作单元(非单个容器)。

Pod 是一组共享了下面资源的(运行在同一节点上的)容器:

  • 进程命名空间
  • 网络命名空间
  • IPC 命名空间(可以 SystemV IPC 或 POSIX 消息队列通信)
  • UTS 命名空间(同一主机名称)

可以将一个 Pod 当作是一个抽象的“虚拟机”,里面运行若干个不同的进程(每个进程实际上就是一个容器)。

比如某个后端应用是若干处理组件组成,可以作为一个后端 Pod。

一个 Pod,往往带有若干 label,比如 type=prod, app=nginx 之类,并且被 kubelet 汇报到 Endpoints 中记录。

实现上,是先创建一个 gcr.io/google_containers/pause 容器,然后创建同一个 Pod 中的其它容器,共享 pause 容器的命名空间。

Kubernetes 要干的事情是要把这些 Pod 给互相连接起来,是不是联想到了什么了?跟虚拟机网络的基本需求是相同的。

Service

Service 是一类运行相同/相似应用(通过 label 来过滤)的 Pod,组成一个完整的服务。比如一组前端 Pod,形成一个前端 Service。

Service 主要是为了: 解耦直接对 Pod 的访问(Pod 是动态的,随时可能停止或变化) 提供隐式的负载均衡(可以配置均衡策略到后端真实的 Pod)

访问其实是以 Service 为单位的,可以通过 DNS 或者(写入环境变量的) Cluster 地址来解耦掉实际的 Pod 地址。实现上是通过 Kube-Proxy 进程。

kube-proxy

实际上,每个节点上都会运行一个 Kube-Proxy 进程,负责将到某个 Service 的访问给代理或者均衡(仅支持 TCP)到具体的 Pod 上去。

具体的,对每一个 service 的访问地址(比如:10.0.0.2:80),Kube-Proxy 都会配置 DNAT 规则(从容器出来的访问,从本地主机的访问两方面),将到这个地址的访问映射到本地的一个随机端口。然后 Kube-Proxy 会监听在本地的对应端口,将到这个端口的访问给代理到远端真实的 pod 地址上去。

Replication-Controller

Replication-Controller 主要是为了实现对 Pod 的自动化运维管理(类似 Linux/Nodejs 等平台上的 sueprvisor 工具)。它可以保障集群内某个 Pod 的运行实例的个数。

这样,当某 Pod 出现故障停止时候,可以自动启动新的同样类型的 Pod 来避免服务受到影响。一般推荐通过 Replication-Controller 来创建和管理 Pod。Pod 需要设置 RestartPolicy = Always,同时也是默认值。

设计理念

其实 Docker 默认采用 NAT 的方式已经组成了简单的网络了。但Kubernetes 认为 Docker 的默认网络采用了 NAT 方式,跨节点通信就需要进行端口映射,这会给服务的访问带来麻烦。

设计理念包括如下几点:

  • 所有容器不使用 NAT 就可以互相通信(这跟 Docker 的默认实现是不同的);
  • 所有节点跟容器之间不使用 NAT 就可以互相通信;
  • 容器自己看到的地址,跟其他人访问自己使用的地址应该是一样的(其实还是在说不要有 NAT)。

实现

要满足上面的要求,也不难,最简单的方法,容器网络地址空间跟外部网络的数据空间打通即可,即容器内网络地址直接暴露到物理网上去。

Kubernetes 的基于 GCE 的实现就是这种机制,给每个物理节点直接分配一个内部子网(默认是 /24 的),这样每个 Pod 就能分到一个地址了(意味着每个节点最多 256 个 Pod)。这个地址是直接暴露到物理网络上的,可以直接进行路由。

想让 Pod 访问外网也很简单,在通往外部网络的网关上做一把 SNAT 即可。

扩展

当然,在此基础上还可以进行扩展,比如下面几种方案:

CoreOS 的 Flannel

Flannel内部流量出到物理网之前,非本地的流量过一下整个内部网的网关,然后用 UDP/VXLAN 封装下,直接 tunnel 到对端后进行解包。

Weave

Weave

Weave 的网络设计也是对承载网这部分进行改进,对这部分流量进行封装,发送到对端的 peer 上,但不清楚封装协议类型。

socketplane

SocketPlane 的思路也是大同小异,在主机之间建 Tunnel,本地网桥默认使用 OpenvSwitch。

不同的主机发现采用 mDNS。

这家被 Docker 给收购了,很奇怪,背后应该有一些故事。

OpenStack Neutron

其实,现在的面向虚拟机的网络方案(比如 OpenStack Neutron)早就已经实现了上面的几点,而且使用网络虚拟化的手段,能做到比上面具有更加丰富和灵活的特性。例如,不同物理机上的容器可以拥有任意相同或者不同的子网,并且可以实现多租户的概念。

如果使用 Nova-Docker 来管容器的话,默认采用的就是 Neutron 网络。

结论和展望

网络的设计离不开对需求的深入分析。

从目前的几个项目来看,大家都是在模仿虚拟机的网络来实现容器的网络,甚至还有不少地方没有达到虚拟机网络的成熟度。

未来至少应该从下面两个方面去考虑设计容器网络:

  • 本地的优化:虚拟机的本地网络经过多年优化已经逼近了线速,但容器网络在这方面还有不少坑,特别对物理设备虚拟化技术的支持等。挖掘性能,降低对主机资源的消耗,仍有一些工作要做;
  • 网络特性的优化:容器网络根本上跟虚拟机网络存在很大的差异,这体现在容器的生命周期和使用行为上有很大的不同,传统的网络特性并不能很好地满足这些需求。

转载请注明:http://blog.csdn.net/yeasy/article/details/46443933


kubernetes容器启动详解

如果大家对kubernetes组件以及架构相关分析,可以看我之前的源码阅读,今天只从一个函数分析容器的启动过程,这个函数就是SyncPod,这个是创建kubelet里面最核心的一个函数了。这个方法分为...

Kubernetes1.3:POD生命周期管理

(一)  核心概念 Pod是kubernetes中的核心概念,kubernetes对于Pod的管理也就是对Pod生命周期的管理,对Pod生命周期的管理也就是对Pod状态的管理,我们通过下面Pod相关...

Kubernetes用户指南(一)--快速开始、使用k8s配置文件

一、快速开始 1、启动一个简单的容器。 一旦在Container中打包好应用并将其commit为Image之后,你就可以将其部署在k8s集群上。 一个简单的nginx服务器例子: 先决...

工作日志——k8s job

本次迭代的功能是基于k8s job实现的。与大家分享一下相关内容。

[Kubernetes]Kubernetes的网络模型

Kubernetes的网络模型从内至外由四个部分组成: Pod内部的容器之间通信的网络Pod和Pod之间通信的网络Pod和Service之间通信的网络外界与Service之间通信的网络...

Kubernetes网络配置方案

Kubernetes网络配置方案

Kubernetes入门(三) - 网络

http://dockone.io/article/520 这是我在国外的博客上看到的一系列关于Docker和Kubernetes网络分析的文章,感觉描述得比较清晰,便于刚接触Doc...

kubernetes 网络

在同一pod内的container In kubernetes, every pod gets assigned an IP address, and every container in the ...
  • hbian
  • hbian
  • 2016年03月29日 04:09
  • 376

Kubernetes技术分析之网络

概述Docker的流行激活了一直不温不火的PaaS,随着而来的是各类Micro-PaaS的出现,Kubernetes是其中最具代表性的一员,它是Google多年大规模容器管理技术的开源版本。本系列文章...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:从 Kubernetes 谈容器网络
举报原因:
原因补充:

(最多只允许输入30个字)