应用开发者必须了解的Kubernetes网络二三事

Kubernetes网络基本的部署调度单元：Pod

Kubernetes中的基本管理单元并非是一个容器，而是一个叫做pod的东西。我们认为部署了一个或多个容器的环境是一个pod单元。通常情况下，它们代表了提供部分服务的单个功能端点。

举两个有效的pods单元为例：
数据库pod — 一个单一MySQL容器
Web pod — 包含一个python实例的容器及包含Redis数据库的容器

pods具有以下常用的特性：
它们共享资源 — 包括了网络栈和命名空间
pod包含了一个IP地址，用于客户端连接
pod的配置定义了任意公共端口以及哪个容器占用该端口
pod中的全部容器可以通过网络中的任意端口进行交互（这些容器都会被本地引用，因此需要确保pod中的服务都有唯一的端口）

Kubernetes服务（Kubernetes Services）

Kubernetes服务位于负载均衡器之后，负责管理多个相同的pods。客户端无需连接到每个pod的IP，而是直接连接负载均衡器的IP地址。Kubernetes服务会将你的应用程序定义为一个服务，使得Kubernetes可以根据定义的规则和实际可用资源动态扩展pod数量。

若想要应用程序被Kubernetes基础设施外部的客户端访问到，唯一的方法是将应用程序定义为服务的一部分。无论你是否扩展节点，都需要Kubernetes服务分配外部IP地址。

标签（Labels）

标签是Kubernetes中一组作用于对象（如pods）的键值对，需要具有实际意义且有相关性。

在Kubernetes的标准配置中，标签并不直接影响与Kubernetes相关的核心操作，而是主要用于对对象的分组和识别。

网络安全（Network Security）

下面我们将介绍一些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: 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替换。此外，开发者还可以定义应用程序或者服务侦听的端口号，无论它是较大服务的一部分，或仅仅是一个独立实例。通过这样的操作，使用持续交付和部署方法论的快速开发和部署周期将会成为常态。