在容器领域内,Kubernetes已毋庸置疑成为了容器编排和管理的社区标准。若是你但愿你所搭建的应用程序能充分利用多云(multi-cloud)的优点,有一些与Kubernetes网络相关的基本内容是你必须了解与考虑的。python
Kubernetes中的基本管理单元并不是是一个容器,而是一个叫作pod的东西。咱们认为部署了一个或多个容器的环境是一个pod单元。一般状况下,它们表明了提供部分服务的单个功能端点。nginx
举两个有效的pods单元为例:数据库
pods具备如下经常使用的特性:api
Kubernetes服务位于负载均衡器以后,负责管理多个相同的pods。客户端无需链接到每一个pod的IP,而是直接链接负载均衡器的IP地址。Kubernetes服务会将你的应用程序定义为一个服务,使得Kubernetes能够根据定义的规则和实际可用资源动态扩展pod数量。安全
若想要应用程序被Kubernetes基础设施外部的客户端访问到,惟一的方法是将应用程序定义为服务的一部分。不管你是否扩展节点,都须要Kubernetes服务分配外部IP地址。网络
标签是Kubernetes中一组做用于对象(如pods)的键值对,须要具备实际意义且有相关性。app
在Kubernetes的标准配置中,标签并不直接影响与Kubernetes相关的核心操做,而是主要用于对对象的分组和识别。负载均衡
下面咱们将介绍一些Kubernetes推荐使用的网络插件,这些插件用到了咱们上一节提到的标签。利用标签,它们能够在容器运行时改变某些功能。在Kubernetes中,大多数使用的网络插件都是基于容器网络接口(Container Networking Interface ,CNI)规范,这项规范由Cloud Native Computing Foundation(CNCF)制定。CNI容许在多个容器平台中使用相同的网络插件。如今咱们使用一种调整网络安全策略的方法,该方法并不像传统的网络或者安全团队模型那样预先设置好一切,而是在容器运行时,利用标签来调整正确的网络策略(容器的动态变化太过频繁,很难进行手动干预),目前该方法已经成为了 Kubernetes Network Special Internet Group(Network SIG)的一部分。现在,咱们已经有多个可供使用的网络插件可以将网络策略应用于命名空间和pods中,这其中包括OpenContrail 和 Project Calico。frontend
经过这种新方法,Kubernetes管理员能够导入全部预先准备的策略,开发者负责调整并根据需求自主选择策略,而全部这一切都会定义到pod中执行。spa
网络策略示例:
POST /apis/net.alpha.kubernetes.io/v1alpha1/namespaces/tenant-a/networkpolicys/ { "kind": "NetworkPolicy", "metadata": { "name": "pol1" }, "spec": { "allowIncoming": { "from": [ { "pods": { "segment": "frontend" } } ], "toPorts": [ { "port": 80, "protocol": "TCP" } ] }, "podSelector": { "segment": "backend" } } }
有网络策略定义的pod配置示例:
apiVersion: v1 kind: Pod metadata: name: nginx labels: app: nginx segment: frontend spec: containers: - name: nginx image: nginx ports: - containerPort: 80
有了Kubernetes提供的功能,开发者如今拥有了彻底定义应用程序及其依赖性所需的灵活性,而且能够在单个pod中使用多个容器。若是任何一个容器发生错误,Kubernetes可以确保将其对应的pod停用,自动用新的pod替换。此外,开发者还能够定义应用程序或者服务侦听的端口号,不管它是较大服务的一部分,或仅仅是一个独立实例。经过这样的操做,使用持续交付和部署方法论的快速开发和部署周期将会成为常态。