本文共 1983 字，大约阅读时间需要 6 分钟。
Kubernetes中的基本管理单元并非是一个容器，而是一个叫做pod的东西。我们认为部署了一个或多个容器的环境是一个pod单元。通常情况下，它们代表了提供部分服务的单个功能端点。
举两个有效的pods单元为例：
pods具有以下常用的特性：
Kubernetes服务位于负载均衡器之后，负责管理多个相同的pods。客户端无需连接到每个pod的IP，而是直接连接负载均衡器的IP地址。Kubernetes服务会将你的应用程序定义为一个服务，使得Kubernetes可以根据定义的规则和实际可用资源动态扩展pod数量。
若想要应用程序被Kubernetes基础设施外部的客户端访问到，唯一的方法是将应用程序定义为服务的一部分。无论你是否扩展节点，都需要Kubernetes服务分配外部IP地址。
标签是Kubernetes中一组作用于对象（如pods）的键值对，需要具有实际意义且有相关性。
在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。
通过这种新方法，Kubernetes管理员可以导入所有预先准备的策略，开发者负责调整并根据需求自主选择策略，而所有这一切都会定义到pod中执行。
网络策略示例：
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: v1kind: Podmetadata: name: nginx labels: app: nginx segment: frontendspec: containers: - name: nginx image: nginx ports: - containerPort: 80
有了Kubernetes提供的功能，开发者现在拥有了完全定义应用程序及其依赖性所需的灵活性，并且可以在单个pod中使用多个容器。如果任何一个容器发生错误，Kubernetes能够确保将其对应的pod停用，自动用新的pod替换。此外，开发者还可以定义应用程序或者服务侦听的端口号，无论它是较大服务的一部分，或仅仅是一个独立实例。通过这样的操作，使用持续交付和部署方法论的快速开发和部署周期将会成为常态。
原文链接：
转载地址：http://vbae.baihongyu.com/