第三方集成
Kubernetes核心概念

Kubernetes 核心概念

1.1 Pod

Pod 是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。 Pod 就像豌豆荚一样，其中包含着一组（一个或多个）容器；这些容器共享存储、网络、以及怎样运行这些容器的声明。

Pod就像一台物理服务器一样，其中包含一个或多个应用容器，这些容器中运行着用户应用程序。

举例说明 Pod、Container、应用程序三者之间的关系：麻屋子,红帐子,里面住着白胖子。Pod 就是麻屋子, Container 就是红帐子,应用程序就是里面的白胖子。

1.2 Controller

在 Kubernetes 中，用于管理和运行Pod的对象 在 Kubernetes 中，控制器通过监控集群的公共状态，并致力于将当前状态转变为期望的状态

举例说明 Controller (控制器)作用：房间里的温度自动调节器

当你设置了温度，告诉了温度自动调节器你的 期望状态（Desired State）。房间的实际温度是 当前状态（Current State）。 通过对设备的开关控制，温度自动调节器让其当前状态接近期望状态。

一个控制器至少追踪一种类型的 Kubernetes 资源。这些对象有一个代表期望状态的 spec 字段。该资源的控制器负责确保其当前状态接近期望状态。

不同的类型的控制器所实现的控制方式不一样，例如：

 - deployment
  - 部署无状态应用
  - 部署无状态应用: 认为 `Pod` 都一样，没有顺序要求，不用考虑在哪个 `Node` 运行，随意进行扩展和伸缩
  - 管理 `Pod` 和 `ReplicaSet`
  - 部署、滚动升级等
  - 典型的像 `Web` 服务、分布式服务等
 - StatefulSet
  - 部署有状态应用
  - 有状态应用，每个 `Pod` 都独立运行，保持 `Pod` 启动顺序和唯一性；有唯一的网络标识符，持久存储；有序，比如 `MySQL` 主从；主机名称固定。而且其扩容以及升级等操作也是按顺序进行的操作。
 - DaemonSet
  - 部署守护进程
  - `DaemonSet` 保证在每个 `Node` 上都运行一个容器副本，常用来部署一些集群的日志、监控或者其他系统管理应用。新加入的 `Node` 也同样运行在一个 `Pod` 里面。
 - Job
  - 一次性任务
  - `Job` 负责批量处理短暂的一次性任务 (short livedone-off tasks)，即仅执行一次的任务，它保证批处理任务的一个或多个 `Pod` 成功结束。
 - Cronjob
  - 周期性定时任务

1.3 Label

1.3.1 Label介绍

Label是附着到 object 上（例如 Pod）的键值对。可以在创建 object 的时候指定，也可以在 object 创建后随时指定。Labels的值对系统本身并没有什么含义，只是对用户才有意义。

一个Label是一个 key=value 的键值对，其中 key 与 value 由用户自己指定。

Label可以附加到各种资源对象上，例如 Node、Pod、Service、RC 等，一个资源对象可以定义任意数量的 Label，同一个 Label 也可以被添加到任意数量的资源对象上去，Label 通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。 我们可以通过指定的资源对象捆绑一个或多个不同的 Label 来实现多维度的资源分组管理功能，以便于灵活、方便地进行资源分配、调度、配置、部署等管理工作。例如：部署不同版本的应用到不同的环境中；或者监控和分析应用（日志记录、监控、告警）等。

一些常用abel示例如下所示:

  • 版本标签："release" : "stable" , "release" :"canary"...
  • 环境标签："environment" : "dev" , "environment": "production"
  • 架构标签："tier" : "frontend" , "tier" :"backend" , "tier" : "middleware"
  • 分区标签："partition" : "customerA" ,"partition" : "customerB"...
  • 质量管控标签："track" : "daily" , "track" :"weekly"

Label 相当于我们熟悉的“标签”，给某个资源对象定义一个 Label，就相当于给它打了一个标签，随后可以通过 Label Selector（标签选择器）查询和筛选拥有某些 Label 的资源对象，Kubernetes 通过这种方式实现了类似 SQL 的简单又通用的对象查询机制。

1.3.2 Label语法及字符集

Label key的组成：

  • 不得超过63个字符
  • 可以使用前缀，使用/分隔，前缀必须是DNS子域，不得超过253个字符，系统中的自动化组件创建的label必须指定前缀，kubernetes.io/由kubernetes保留
  • 起始必须是字母（大小写都可以）或数字，中间可以有连字符、下划线和点

Label value的组成：

  • 不得超过63个字符
  • 起始必须是字母（大小写都可以）或数字，中间可以有连字符、下划线和点

1.4 Label Selector

通过 label selector，客户端/用户可以指定一个 object 集合，通过 label selector 对 object 的集合进行操作。

Label selector有两种类型：

  • equality-based（基于等式） ：可以使用=、==、!=操作符，可以使用逗号分隔多个表达式
  • set-based（基于集合）：可以使用in、notin、!操作符，另外还可以没有操作符，直接写出某个label的key，表示过滤有某个key的object而不管该key的value是何值，!表示没有该label的object

举例说明Label Selector Label Selector可以被类比为 SQL 语句中的 where 查询条件，例如，name=redis-slave 这个 label Selector 作用于 Pod 时，可以被类比为 select * from pod where pod'sname = 'redis-slave' 这样的语句。

1.5 Service

将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。

由于 Pod 是非永久性资源对象，如果你使用 Controller 运行你的应用程序，你可以动态创建和销毁 Pod，这样就会导致无法准确访问到所想要访问的 Pod 例如：如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能，那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用提供工作负载的后端部分？ 是一组 iptables 或 ipvs 规划，通过把客户端的请求转发到服务端（Pod）,如有多个 Pod 情况，亦可实现负载均衡的效果。

例如：一个图片处理后端，它运行了 3 个副本（Pod）。这些副本是可互换的 —— 前端不需要关心它们调用了哪个后端副本。 然而组成这一组后端程序的 Pod 实际上可能会发生变化，前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。

1.6 Endpoints

为 Service 管理后端 Pod，当后端 Pod 被创建或销毁时，Endpoints 列表会更新 Pod 对应的 IP 地址，以便 Service 访问请求能够确保被响应。

1.7 DNS

为 Kubernetes 集群内资源对象的访问提供名称解析，这样就可以实现通过 DNS 名称而非 IP 地址来访问服务。

  • 实现集群内 Service 名称解析

  • 实现集群内 Pod 内 Container 中应用访问互联网提供域名解析

原文来自 https://community.yonyou.com/thread-228473-1-1.html (opens in a new tab)

OnlyOffice服务K3S系统简介