博客
关于我
应用开发者必须了解的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/

你可能感兴趣的文章
Mysql学习总结(6)——MySql之ALTER命令用法详细解读
查看>>
Mysql学习总结(70)——MySQL 优化实施方案
查看>>
Mysql学习总结(71)——MySQL 重复记录查询与删除总结
查看>>
Mysql学习总结(73)——MySQL 查询A表存在B表不存在的数据SQL总结
查看>>
Mysql学习总结(77)——温故Mysql数据库开发核心原则与规范
查看>>
Mysql学习总结(78)——MySQL各版本差异整理
查看>>
Mysql学习总结(79)——MySQL常用函数总结
查看>>
Mysql学习总结(7)——MySql索引原理与使用大全
查看>>
Mysql学习总结(80)——统计数据库的总记录数和库中各个表的数据量
查看>>
Mysql学习总结(81)——为什么MySQL不推荐使用uuid或者雪花id作为主键?
查看>>
Mysql学习总结(82)——MySQL逻辑删除与数据库唯一性约束如何解决?
查看>>
Mysql学习总结(83)——常用的几种分布式锁:ZK分布式锁、Redis分布式锁、数据库分布式锁、基于JDK的分布式锁方案对比总结
查看>>
Mysql学习总结(84)—— Mysql的主从复制延迟问题总结
查看>>
Mysql学习总结(85)——开发人员最应该明白的数据库设计原则
查看>>
Mysql学习总结(8)——MySql基本查询、连接查询、子查询、正则表达查询讲解
查看>>
MySQL学习笔记十七:复制特性
查看>>
Mysql学习第一课-mysql的定义及sql语句
查看>>
mysql安装卡在最后一步解决方案(附带万能安装方案)
查看>>
mysql安装和启动命令小结
查看>>
MySQL安装配置教程(非常详细),从零基础入门到精通,看完这一篇就够了
查看>>