• 欢迎访问蜷缩的蜗牛博客 蜷缩的蜗牛
  • 微信搜索: 蜷缩的蜗牛 | 联系站长 kbsonlong@qq.com
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

理解Kubernetes核心概念

Docker 蜷缩的蜗牛 3个月前 (06-22) 16次浏览 已收录

Kubernetes 是在群集中管理跨多台主机容器化应用的开源系统。它为容器化应用提供了资源调度、部署、服务发现、扩展等功能。

主要功能用途

  • 使用 Docker 对我们的应用进行打包、实例化和运行。
  • 以集群的方式运行和管理跨主机的容器。
  • 解决跨主机容器的通讯问题。
  • 提供自我修复的功能,保证系统运行的健壮性。

核心概念

Kubernetes 的架构图

核心组件

  • Master

Master 节点运行着集群管理相关的一组进程:etcdkube-apiserverkube-controller-managerscheduler。这些进程实现了整个集群的资源管理、Pod 调度、弹性伸缩、安全控制、系统监控、纠错等管理功能。

  • Node(节点)

节点是 Kubernates 系统中的一台工作机器(之前的版本叫做 Minion),既从属主机。它可以是物理机,也可以是虚拟机。每一个节点都包含了 Pod 运行所需的必要服务,例如 Docker、kubelet 和网络代理(proxy),节点受 Kubernates 系统中的主节点控制。

和 Pod、Service 不一样,节点本身并不属于 Kubernates 的概念,它是云平台中的虚拟机或实体机。所以当一个节点加入到 Kubernates 系统中时,它将会创建一个数据结构来记录该节点的信息。另外,不是所有节点都能加入到 Kubernates 系统中,只有那些通过验证的节点才能成为 Kubernates 节点。

你可以通过下面的命令获取节点运行情况列表:

$ kubectl get nodes

NAME LABELS STATUS
172.19.17.99 kubernetes.io/hostname=172.19.17.99 Ready
  • Pod(容器组)

Pod 是一组并置的应用容器,是 Kubernetes 中可以被创建,调度的最小单元。

一个 Pod 可以被一个容器化的环境看做是应用层的逻辑宿主机(Logical Host),通常一个 Node 中可以运行几百个 Pod,每个 Pod 中有多个容器应用,同一个 Pod 中的多个容器应用通常是紧密耦合的(相当于多个业务容器组成的一个逻辑虚拟机)。

一个 Pod 中的多个容器应用通常是紧耦合的。Pod 在 Node 上被创建、启动或者销毁。

每个 Pod 中有一个特殊的 Pause 容器,其他的成为业务容器,这些业务容器共享 Pause 容器的网络栈以及 Volume 挂载卷,因而他们之间的通信及数据交互更为高效。

同一个 pod 中的业务容器共享如下资源:

  1. PID 命名空间(不同应用程序可以看到其他应用程序的 PID)
  2. 网络命名空间(pod 中多个容器可以访问同一个 IP 和端口范围)
  3. IPC 命名空间(能够使用 SystemV IPC 或者 POSIX 消息队列进行通信)
  4. UTS 命名空间(共享同一个主机名)
  5. Volumes(访问定义在 pod 级别的存储卷)

Pod 可以单独创建。由于 Pods 没有可控的生命周期,如果他们进程死掉了,他们将不会重新创建。出于这个原因,建议您使用复制控制器。

  • Replication Controller(复制控制器)

Replication Controller 是 Kubernetes 系统中的核心概念,用于管理 Pod 的生命周期。在 Master 内,Controller Manager 进程通过 RC 的定义来完成 Pod 的创建、监控、启停等操作。

Kubernetes 通过 RC 中定义的 Label 筛选出对应的 Pod 实例并实时监控其状态和数量,如果实例数量少于定义的副本数量,则会根据 RC 中定义的 Pod 模板来创建一个新的 Pod,然后 Scheduler 将此 Pod 调度到合适的 Node 上启动运行,直到 Pod 实例数量达到预定目标。这个过程完全是自动化的。

  • Replica Set

Replica Sets 能够确保在某个时间点上,一定数量的 Pod 在运行。RelicaSet 是 Replication Controller 的升级版本,两者的区别主要在选择器 selector,Replica 支持集合级别的选择器,而前期的 Replication Controller 支持在等号描述的选择器。目前 Replica Sets 主要用于 Deployment 中。

  • Deployment

Deployment 是 Kubernetes 1.2 起一个新引入的概念,Deployment 是 Replica Sets 更高一层的抽象。Kubernetes Deployment 提供了官方的用于更新 Pod 和 Replica Set 的方法,您可以在 Deployment 对象中只描述您所期望的理想状态(预期的运行状态),Deployment 控制器为您将现在的实际状态转换成您期望的状态。

Deployment 集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线任务,回滚到以前某一版本(成功/稳定)的 Deployment 等功能,在某种程度上,Deployment 可以帮我们实现无人值守的上线,大大降低我们的上线过程的复杂沟通、操作风险。

Deployment 的使用场景

  1. 使用 Deployment 来启动(上线/部署)一个 Pod 或者 ReplicaSet
  2. 检查一个 Deployment 是否成功执行
  3. 更新 Deployment 来重新创建相应的 Pods(例如,需要使用一个新的 Image)
  4. 如果现有的 Deployment 不稳定,那么回滚到一个早期的稳定的 Deployment 版本
  5. 暂停或者恢复一个 Deployment
  • Service(服务)

服务为一组 Pod 提供单一稳定的名称和地址。他们作为基本负载均衡器而存在。是一系列 Pod 以及这些 Pod 的访问策略的抽象。

Service 具有如下特征:

  1. 拥有一个唯一指定的名字
  2. 拥有一个虚拟 IP 和端口号
  3. 能够提供某种远程服务能力
  4. 被映射到提供这种服务能力的一组容器上
  5. Service 的服务进程目前都基于 socket 通信方式对外提供服务

Service 的服务进程目前都基于 socket 通信方式对外提供服务,Kubernetes 内置了透明的负载均衡以及故障恢复的机制。

  • Label(标签)

Label(标签)是一组附加在对象上的键值对,主要解决 Service 与 Pod 之间的关联问题。

标签常用来从一组对象中选取符合条件的对象,这也是 Kubernates 中目前为止最重要的节点分组方法。标签的本质是附属在对象上的非系统属性类的元数据, 即它不是名字、Id 以及对象的硬件属性,而是一些附加的键值对。

  • Annotation(注解)

Annotation 与 Label 类似,也使用 key/value 键值对的形式进行定义。Label 具有严格的命名规则,它定义的是 Kubernetes 对象的元数据(Metadata),并且用于 Label Selector。Annotation 则是用户任意定义的”附加”信息,以便于外部工具进行查找。

用 Annotation 来记录的信息包括:

  1. build 信息、release 信息、Docker 镜像信息等,例如时间戳、release id 号、PR 号、镜像 hash 值、docker registry 地址等;
  2. 日志库、监控库、分析库等资源库的地址信息;
  3. 程序调试工具信息,例如工具名称、版本号等;
  4. 团队的联系信息,例如电话号码、负责人名称、网址等。
  • Namespace(命名空间)

使用 Namespace 来组织 kubernetes 的各种对象,可以实现用户的分组(多租户),对不同的租户还可以进行单独的资源设置和管理,是的整个集群的资源配置非常灵活。

  • Scheduler

将 Pod 调度到合适的 Node 上启动运行

  • Volume(容器共享存储卷)

Volume 是 Pod 中能够被多个容器访问的共享目录。Kubernetes 的 Volume 概念与 Docker 的 Volume 比较类似,但不完全相同。Kubernetes 中的 Volume 与 Pod 生命周期相同,但与容器的生命周期不相关。当容器终止或者重启时,Volume 中的数据也不会丢失。另外,Kubernetes 支持多种类型的 Volume,并且一个 Pod 可以同时使用任意多个 Volume。

  • Persistent Volume(持久卷)

Persistent Volume(PV)是集群之中的一块网络存储。跟 Node 一样,也是集群的资源。PV 跟 Volume (卷)类似,不过会有独立于 Pod 的生命周期。这一 API 对象包含了存储的实现细节,例如 NFS、iSCSI 或者其他的云提供商的存储系统。

  • Persistent Volume Claims(持久卷申请)

用户通过持久卷请求(PVC)申请存储资源。它跟 Pod 类似,Pod 消费 Node 的资源,PVC 消费 PV 的资源。Pod 能够申请特定的资源(CPU 和内存);PVC 可以申请大小、访问方式(例如 mount rw 一次或 mount ro 多次等多种方式)。

  • Horizontal Pod Autoscaling(Pod 自动扩容)

Horizontal Pod Autoscaler 简称 HPA,意思是 Pod 横向自动扩容。可以实现基于 CPU 使用率的 Pod 自动伸缩的功能。

与之前的 RC、Deployment 一样,也属于一种 Kubernetes 资源对象。通过追踪分析 RC 控制的所有目标 Pod 的负载变化情况,来确定是否需要针对性的调整目标 Pod 数,这是 HPA 的实现原理。

HPA 有两种方式作为 Pod 负载的度量指标:CPUUtilizationPercentage 和应用程序自定义度量指标。

  • Proxy(代理)

反向代理,Proxy 会根据 Load Balancer 规则将外网请求分发到后端正确的容器处理。

上述这些组件是 Kubernetes 系统的核心组件,它们共同构成了 Kubernetes 系统的框架和计算模型。通过对它们进行灵活组合,用户就可以快速、方便地对容器集群进行配置、创建和管理。

参考文档

http://lihaoquan.me/2016/7/9/learning-k8s-1.html
http://www.jianshu.com/p/63ffc2214788
https://segmentfault.com/a/1190000004858278

本文转载自 理解 Kubernetes 核心概念


蜷缩的蜗牛 , 版权所有丨如未注明 , 均为原创丨 转载请注明理解 Kubernetes 核心概念
喜欢 (0)
[]
分享 (0)