博客
关于我
应用开发者必须了解的Kubernetes网络二三事
阅读量:365 次
发布时间:2019-03-04

本文共 1983 字,大约阅读时间需要 6 分钟。


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: 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/

你可能感兴趣的文章
NIFI从MySql中增量同步数据_通过Mysql的binlog功能_实时同步mysql数据_配置数据路由_实现数据插入数据到目标数据库_实际操作03---大数据之Nifi工作笔记0042
查看>>
NIFI从MySql中离线读取数据再导入到MySql中_03_来吧用NIFI实现_数据分页获取功能---大数据之Nifi工作笔记0038
查看>>
NIFI从MySql中离线读取数据再导入到MySql中_无分页功能_02_转换数据_分割数据_提取JSON数据_替换拼接SQL_添加分页---大数据之Nifi工作笔记0037
查看>>
NIFI从PostGresql中离线读取数据再导入到MySql中_带有数据分页获取功能_不带分页不能用_NIFI资料太少了---大数据之Nifi工作笔记0039
查看>>
nifi使用过程-常见问题-以及入门总结---大数据之Nifi工作笔记0012
查看>>
NIFI分页获取Mysql数据_导入到Hbase中_并可通过phoenix客户端查询_含金量很高的一篇_搞了好久_实际操作05---大数据之Nifi工作笔记0045
查看>>
NIFI同步MySql数据_到SqlServer_错误_驱动程序无法通过使用安全套接字层(SSL)加密与SQL Server_Navicat连接SqlServer---大数据之Nifi工作笔记0047
查看>>
Nifi同步过程中报错create_time字段找不到_实际目标表和源表中没有这个字段---大数据之Nifi工作笔记0066
查看>>
NIFI大数据进阶_FlowFile拓扑_对FlowFile内容和属性的修改删除添加_介绍和描述_以及实际操作---大数据之Nifi工作笔记0023
查看>>
NIFI大数据进阶_NIFI的模板和组的使用-介绍和实际操作_创建组_嵌套组_模板创建下载_导入---大数据之Nifi工作笔记0022
查看>>
NIFI大数据进阶_NIFI监控的强大功能介绍_处理器面板_进程组面板_summary监控_data_provenance事件源---大数据之Nifi工作笔记0025
查看>>
NIFI大数据进阶_NIFI集群知识点_认识NIFI集群以及集群的组成部分---大数据之Nifi工作笔记0014
查看>>
NIFI大数据进阶_NIFI集群知识点_集群的断开_重连_退役_卸载_总结---大数据之Nifi工作笔记0018
查看>>
NIFI大数据进阶_内嵌ZK模式集群1_搭建过程说明---大数据之Nifi工作笔记0015
查看>>
NIFI大数据进阶_外部ZK模式集群1_实际操作搭建NIFI外部ZK模式集群---大数据之Nifi工作笔记0017
查看>>
NIFI大数据进阶_离线同步MySql数据到HDFS_01_实际操作---大数据之Nifi工作笔记0029
查看>>
NIFI大数据进阶_离线同步MySql数据到HDFS_02_实际操作_splitjson处理器_puthdfs处理器_querydatabasetable处理器---大数据之Nifi工作笔记0030
查看>>
NIFI大数据进阶_连接与关系_设置数据流负载均衡_设置背压_设置展现弯曲_介绍以及实际操作---大数据之Nifi工作笔记0027
查看>>
NIFI数据库同步_多表_特定表同时同步_实际操作_MySqlToMysql_可推广到其他数据库_Postgresql_Hbase_SqlServer等----大数据之Nifi工作笔记0053
查看>>
NIFI汉化_替换logo_二次开发_Idea编译NIFI最新源码_详细过程记录_全解析_Maven编译NIFI避坑指南001---大数据之Nifi工作笔记0068
查看>>