您的位置: 首页  >  文章  >  01-Kubernetes架构概述及组件介绍

01-Kubernetes架构概述及组件介绍

分类: 文章 • 2024-02-26 19:42:40

Kubernetes架构概述及组件介绍

Kubernetes特性

  • 自动装箱
    kubernetes构建于容器之上，基于资源依赖及其它约束自动完成容器部署且不影响其可用性，同时，为了提高利用率和节省更多资源，将关键和最佳工作量结合在一起。
  • 自我修复
    支持容器故障后自动重启、节点故障后重新调度容器，以及其它可用节点，健康检测失败后关闭容器并重新创建灯自我修复机制。
  • 水平扩展
    支持通过简单命令或UI手动水平扩展，以及基于CPU等资源负载率的自动水平扩展机制。
  • 服务发现和负载均衡
    kubernetes通过附加组件之一的 KubeDNS/CoreDNS 为系统内置了服务发现功能，它会为每个Service配置DNS名称，并允许集群内的客户端直接使用此名称发出访问请求，而Service则通过iptables或ipvs内建了负载均衡机制。
  • 自动发布和回滚
    kubernetes支持 灰度 更新应用程序或配置信息，它会监控更新过程中应用程序的健康状态，以确保它不会在同一时间杀掉所有pods，而此过程中一旦有故障发生，就会立即自动执行回滚操作。
  • **和配置管理
    kubernetes的Config Map实现了配置数据与Docker镜像解耦，需要时，仅对配置做出变更而无需重新构建Docker镜像，这为应用开发部署带来了很大的灵活性。刺猬，对于应用所依赖的一些敏感数据，如用户名和密码、令牌、**等信息，kubernetes专门提供了Secret对象为其解耦，即便利了应用快速开发和交付，又提供了一定程度上的安全保障。
  • 存储编排
    kubernetes 支持 pod 对象按需自动挂载不同类型的存储系统，这包括节点本地存储，网络存储，云存储等。
  • 批量处理执行
    除了服务器型应用，kubernetes还支持批处理作业及CI(持续集成)，如果需要，一样可以实现容器故障后恢复。

Kubernetes概念和术语

Kubernetes采用Master/Node结构，Master为管理控制节点，Node为正在运行应用的节点；
Master可以有一台或多台(三台以上Master可以做HA用来高可用，效果与Keepalived雷同)，Master节点被称为控制平面，Node为数据平面。
01-Kubernetes架构概述及组件介绍

概念讲解

  • 1.Master
    Master 是集群的网关和中心，负责注入为用户和客户端暴露 API、跟踪其他服务器的健康状态、以最优方式调度工作负载，以及编排其它组件之间的通信等任务，它是用户或客户端之间的核心联络点，并负责Kubernetes系统的大多数集中式管控逻辑。单个 Master节点即可完成所有功能，但是出于负载均衡及高可用目的，生产环境通常需要部署多个此类主机。
  • 2.Node
    Node 是 Kubernetes 集群的工作节点，负责接收来自 Master 的工作指令并根据指令相应地创建和销毁 Pod 对象，以及调整网络规则以合理地路由和转发流量等。理论上讲，Node可以使任何形式的计算设备，不过 Master 会统一将其抽象为 Node 对象进行管理。

Kubernetes 将所有Node的资源集结于一处形成一台更加强大的 “服务器”，如下图所示，在用户将应用部署到 Node 上时，Master使用调度算法 Scheduler将其自动指派至某个特定的 Node 运行，在 Node加入集群或从集群中移除时，Master也会按需重新编排影响到Pod(容器)。于是，我们无需关心应用到底在哪个Node上。
01-Kubernetes架构概述及组件介绍

术语讲解

  • 1.Pod
    Kubernetes并不直接运行容器，而是使用一个抽象的资源对象来封装一个或多个容器，这个抽象就被称为 Pod，它也是 Kubernetes 的最小调度单元，在Kubernetes中，容器不称为我们之前在Docker中所谓的容器，而是被称为 Pod。同一个 Pod 中可以有多个容器并且同一个Pod中的多个容器共享网络名称和存储资源，这些容器可通过本地回环接口 lo 直接通信，但彼此之间又在 Mount、User、PID等名称空间上保持了隔离。尽管 Pod 中可以包含多个容器，但是作为最小调度单元，它应该尽可能的保持 “小”，所以通常一个Pod中只有一个主容器和其它辅助容器，辅助容器指的是（Filebeats、zabbix_agent客户端等）。
    我的理解为：“一个Node可以包含多个Pod，一个Pod可以包含多个容器，一个Node为一台主机（物理机/虚拟机/云主机。。。。），一个Pod基于Node之上，又可以在一个Pod中运行多个容器，但我们通常只运行一个主容器，其余为辅助容器”。
  • 2.Label/资源标签
    标签（Label）是将资源进行分类的标识符，表面意思可以与Docker中的tag一致，在Docker中我们给容器打标签tag，但是在Kubernetes中我们需要给 Pod 来打标签。资源标签是一个键值型 （Key/Values）格式的数据。添加标签的主要作用是为了增加辨识度，添加的标签对用户存在特定的意义。标签可以在 Pod 创建的时候指定，也可以在创建 Pod 后任意时间进行添加和修改。
    一个 Pod 可以拥有多个标签Lable，一个标签也可以属于多个 Pod。通常用法如下图所示。
    01-Kubernetes架构概述及组件介绍
  • 3.标签选择器
    标签选择器(Selector)，全称为 ”Label Selector“，标签选择器通过 Label来过滤符合条件的 Pod，例如附有标签 ”application：nginx“的所有 Pod 挑选出来归纳为一类，并为归纳出的这组标签的 Pod 创建为 Service的端点。
    01-Kubernetes架构概述及组件介绍
  • 4.Pod控制器
    尽管 Pod 是 Kubernetes的最小调度单元，但是我们也不会直接部署及管理 Pod 对象，而是借助另外一类抽象，这类抽象被称为——》控制器（Controller）对其进行管理。
    用于工作负载的控制器是一种管理 Pod 生命周期的资源抽象，他们是 Kubernetes 上的一类对象，而非单个资源对象，，控制器包括以下
    ReplicationController
    ReplicaSet
    Deployment
    StatefulSet
    Job
    下图中以 Deployment控制器为例，我们在其中定义了 Pod 对象的副本数量（就是一个Pod的副本，可以作为高可用使用的副本）为3，就必须精确为3各 Pod，否则”多退少补“。使用控制器之后就不再需要手动管理Pod对象了，用户只需要声明应用的期望状态，控制器就会自动对其进行进程管理。
    01-Kubernetes架构概述及组件介绍
  • 5.服务资源(Service)
    Service 是建立在一组 Pod 对象之上的资源抽象，Kubernetes通过标签选择器 Label Selector选择后的一组 Pod 对象，并为这组 Pod对象定义一个统一且固定的访问入口（通常是一个IP地址），若Kubernetes集群存在 DNS附件，它就会在Service创建时为其自动配置一个DNS名称以便客户端进行服务发现。到达Service IP的请求将被负载均衡至其后的端点——各个Pod对象之上，因此 Service从本质上来讲是一个四层代理服务。另外Service还可以将集群外部流量引入到集群中来。
    扩展：因为Pod是动态的，Pod IP地址也是非常不固定的，所以当外部资源直接访问Pod IP时，当Pod被销毁了之后那么将会出不可描述的问题，所以在相同功能的Pod前加入 Service 进行代理，Service 通过标签选择器 Label Selector 来自动代理我们预定好的Pod。
  • 6.存储卷
    存储卷（Volume）是独立于容器文件系统之外的存储空间，常用于扩展容器的存储空间并为容器提供持久存储能力。Kubernetes集群上的存储卷大体可以分为临时卷、本地卷和网络卷。临时卷和本地卷都位于 Node 本地，一旦 Pod 被调度至其他 Node，此种类型的存储卷将无法访问到，因此临时卷和本地卷常用语数据缓存，持久化的数据则需要放置于持久卷（presistent volume）之上。
  • 7.Name和NameSpace
    名称（Name）是Kubernetes集群中资源对象的标识符，他们的作用于通常是名称空间（NameSpace），因此名称空间是名称的额外限定机制。在用一个名称空间中（同一名称空间一般为：Node与Node之间名称,Service与Service之间名称,Pod与Pod之间名称,同一Pod下容器名称），同一类型资源对象的名称必须具备唯一性。名称空间常用于实现租户或项目的资源隔离，从而形成逻辑分组，如下图所示，创建的 Pod 和 Service 等资源对象都属于名称空间级别，未指定时，他们都属于默认名称空间 ”default“
    下图中的三个 Pod ，分为为：默认 Pod 名称空间，公开 Pod 名称空间，系统 Pod 名称空间。
    01-Kubernetes架构概述及组件介绍
  • 8.Annotation
    Annotation(注解)是一种附加在 Pod 对象之上的键值类型数据，但它拥有更大的数据容量。Annotation 常用于将各种非标识型元数据（matedata）附加到对象上，但它不能用于标识和选择对象。常规之意即为 ”注释“
  • 9.Ingress
    Kubernetes将Pod对象和外部网络环境进行了隔离，Pod 和 Service等对象间的通信都使用其内部专用地址进行，加入需要开放某些 Pod 对象提供给外部用户访问，则需要为其请求流量打开一个通往 Kubernetes集群内部的通道，除了 Service 之外，Ingress也是这类通道的实现方式之一。Ingrss被称为入口。

Kubernetes系统组件

一个Kubernetes集群由多个工作节点(worker node)和一个或多个集群控制节点(Master)以及一个集群状态存储系(etcd)组成。
01-Kubernetes架构概述及组件介绍

Master系统组件

Master主要负责整个集群的管理工作，为集群提供管理接口，并监控和编排集群中的各个工作节点。各节点负责以 Pod 形式运行Docker容器。
Master节点主要由 apiserver、scheduler、contrller三个系统组件以及一个集群存储系统 etcd 组成。而API、UI、CLI则为管理员客户端操作方式。
01-Kubernetes架构概述及组件介绍

API： Kubernetes的Master提供了API来用向Master内部调用操作，我们可以通过调用API来对Kubernetes集群进行操作。
UI： UI是Kubernetes提供的一个Web界面的操作接口，通过Web的UI界面即可进行对Kubernetes集群的控制操作。
CLI： CLI是Kuberntes提供的一个命令为 kuberctl 的客户端操作命令，通过此命令也可以完成对Kubernetes集群的控制操作，此命令就像是Docker中的客户端,Docker组件分为 Docker Daemon Docker Client还有Registry，CLI命令就如同 docker 客户端命令一样。

  • API Server
    目前应用程序提供了共两种API方式，第一种为陈述式API，第二种为声明式API。
    举一个陈述式API例子：假如你要运行一个容器，你要指定运行什么容器，指定容器使用的镜像位置，指定通过怎么方式运行等等，陈述式API是需要你写清楚每一步的步骤，然后让运行容器的人按照你的步骤去做。
    而生明式API则是：你直接指定运行什么样的容器即可，剩下的全部交给运行容器的人去做。
    Kubernetes提供的API则为后者声明式API。Kubernetes中定义API的方式则在yaml文件中写入你想要的结果即可，然后Kubernetes将会执行相应操作，完成你的结果。
    API Server为唯一接受客户端组件请求的入口，无论我们使用API、UI、以及CLI方式操作的事件，都会发送给API Server，API Server进行接收并校验客户端请求。

  • Scheduler
    Scheduler为调度器；假如你通过API或UI更或则是CLI方式运行一个容器(目前这里介绍为容器，后面将过Pod后将替换为Pod)，Scheduler用来计算将容器运行在哪个Node节点之上，这就需要Scheduler去进行评估哪台Node节点最适合运行你创建的容器。

  • Controller

    Controller为控制器；在Kubernetes中，集群级别的大多数功能都是由几个被称为控制器的进程所实现的，这几个进程被集成于 kube-controller-manager守护进程中。由控制器完成的功能主要包括生命周期和API业务逻辑，具体如下：

    1. 生命周期功能：包括 Namespace 创建和生命周期、Event 垃圾回收、Pod 终止相关的垃圾回收、及 Node 垃圾回收等。
    2. API 业务逻辑：例如，由 RepliaSet 执行的 Pod 扩展等。

  • etcd
    etcd被称为集群状态存储(Cluster State Store)，Kubernetes集群的所有状态信息都需要持久存储到etcd系统中，不过，etcd是由 CoreOS 公司 基于 Raft 协议开发的分布式键值key=vaule存储，可用于服务发现、共享配置以及一致性保障。因此，etcd是独立的服务组件，并不属于Kubernetes集群自身组件。生产环境中应用以 etcd 集群的方式运行以确保其服务可用性。
    etcd不仅能够提供键值数据存储，而且还为其提供了监听 （watch）机制，用于监听和推送变更。Kubernetes集群系统中，etcd中的键值发生变化时会通知到 API Server，并由其通过 watch API向客户端输出。基于watch机制，Kubernetes集群的各个组件实现了高效协同。

Kubernetes Master节点的工作原理

  1. 我们使用客户端组件向API Server发出指令创建一个容器。
  2. API Server收到客户端发送的指令后将会先进行校验你发出的指令，校验成功后将状态持久存储到 etcd 中。
  3. API Server只提供接受客户端组件的指令并进行校验然后将数据持久存储到etcd中，那么谁来执行客户端组件发出的指令呢？
  4. API Server校验成功后将状态持久存储到etcd的同时将会告知 Controller 控制器，Controller也会始终监听API Server的资源变动，一旦有了变动，Controller立刻执行相关的变动状态。Controller控制器将按照指令进行创建或则销毁容器。
  5. 如果是创建容器，那么Controller控制器要在哪台Node上进行创建呢？Scheduler 也与 Controller一样始终监听着 API Server的变化状态，这时候就需要 Scheduler 调度器进行评估直接在评估后的Node上创建，Scheduler也会将调度结果和创建状态存储到 etcd中。
  6. 在Kubernetes中有两种状态，第一种为客户端指令中期望的状态，例如我们期望创建一个NGINX容器，第二种状态为Controller执行后的状态，Controller将下载容器镜像并确保NGINX容器运行起来，这个是正真运行的容器，运行成功后Controller会将运行后容器的状态与用户期望的状态进行对比，如果状态不一致，Controller则重启或则重建容器等等方法，使运行后的容器与用户期望的容器状态一致。

Node系统组件

Node节点主要负责提供运行容器的各种依赖环境，并接受 Master 管理。每个Node主要由 Kubelet、容器、kube-proxy三个组件组成。

01-Kubernetes架构概述及组件介绍

  • kube-proxy
    每个Node节点都需要运行一个 kube-proxy 的守护进程，它能够按需为 Service(后面会讲Service是什么) 资源对象生成 iptables 或 ipvs 规则，从而捕获当前 Service的ClusterIP流量并将其转发至正确的后端 Pod 对象。
  • kubelet
    kubelet时运行在Node节点之上的守护进程，kubelet也会始终监听着Master上 API Server组件的资源变动，如果发现 Master 上的Scheduler组件有调度到自身Node来的指令，Kubelet 将会调用自身的 Container Engine，Container Engine 将会寻找镜像仓库并执行操作。kubelet 也会在 API Server上注册当前工作节点，定期向 Master 汇报当前节点资源使用情况，并通过 cAdvisor 监控容器和节点的资源占用情况。
  • Container Engine
    Container Engine为容器引擎，容器引擎有很多，如常用的 Docker 和RKT、cir-o 、Fraki等，这些都是容器引擎，都可以被Kubernetes锁托管，只是我们目前主流的为Docker，容器引擎负责接收来自kubelet的指令并执行它。

附加组件

Kubernetes集群还依赖于一组称为 “附件” 的组件以提供完整的功能，他们通常是由第三方提供的特定应用程序，且托管运行于 Kubernetes 集群之上，如上图中的 kube-system-namespace块中所示。

  • DNS：在Kubernetes集群中调度运行提供DNS服务的 Pod，同一集群中的其它 Pod 可使用此 DNS 服务解决主机名，Kubernetes自 1.11 版本开始默认使用CoreDNS项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是 KubeDNS 项目，而 SykDNS 则是更早一代的项目。
  • Dashhoard：Kubernetes 集群的全部功能都要基于 Web 的 UI 来管理集群中的应用甚至集群自身。
  • Heapster：容器和节点对的性能监控与分析系统，它手机并解析多种指标数据，如资源利用率、生命周期事件等。新版本的 Kubernetes 中，功能会慢慢由 Prometheus 结合其它组件所取代。
  • Ingress Controller：Service 是一种工作与传统的负载均衡器，而 Ingress 是在应用层实现的 HTTP/HTTPS负载均衡机制，不过 Ingress 资源自身并不能进行 “流量穿透”，它仅是一组路由规则的集合，这些规则需要通过 Ingress 控制器（Ingress Controller）发挥作用，目前，此类的可用项目用 Nginx、HAProxy、Traefik、Envoy等。

Kubernetes网络模型

云计算的核心是虚拟化技术，网络虚拟化技术又是最重要的组成部分，用于在物理网络上虚拟多个相互隔离的虚拟网络，实现网络资源切片，提高网络资源利用率，实现弹性化网络。Kubernetes作为容器云技术栈中的容器编排组件，必然需要在多租户（名称空间）的基础上实现弹性网络管理，这也是 ”基础设置“ 的要求之一。

网络模型概述

Kubernetes的网络主要存在四种类型的通信：
1）同一 Pod 内容器之间通信
2）各个 Pod 之间彼此通信
3）Pod 与 Service 之间的通信
4）集群外部流量与 Service之间的通信

Kubernetes为 Pod 和 Service 资源对象分别使用了各自的专用网络， Pod 网络由 Kubernetes的网络插件（常用的网络插件为 Flannel）指定。而 Service 的网络则由 Kubernetes 集群直接指定，为了提供更灵活的解决方式，Kubernetes的网络模型需要借助外部插件实现，它要求任何实现机制都必须满足以下需求。
1）所有 Pod 间都可以不经过 NAT 转换而直接通信
2）所有节点都可以不经过 NAT 转换而直接与所有容器通信。
3）容器自己使用的 IP 也是其它容器或节点可以直接看到的地址，所有 Pod 对象都位于同一网络平面/同一网络中，而且可以使用 Pod 自身的地址直接通信。

Kubernetes 使用的网络插件必须能为 Pod 提供满足以上要求的网络，它需要为每个 Pod 上配置至少一个特定地址，即 Pod IP，Pod IP实际存在某个网络（可以是虚拟设备）上，而 Service 的地址却是一个虚拟 IP 地址，不在任何网络接口上，它由 kube-proxy 借助 iptables 规则或 ipvs 规则重定向到本地端口，再将其调度至后端 Pod IP上。
Service 的 IP 地址是集群提供的接口，也被称为 Cluster IP。

Pod 网络及 Pod IP由 Kubernetes 的网络插件Flannel来配置和管理，具体使用的网络地址可以在配置管理插件的时候指定，默认为 10.244.0.0/16 网络。而 Cluster/Service 网络和 IP 则是由 Kubernetes 集群负责配置和管理，默认为 10.96.0.0/12网络。

Kubernetes集群至少应该包含三个网络，如下图所示：
网络一：各个宿主机 Master、Node、etcd 之间的网络，用于宿主机之间的通信。

网络二：Kubernetes 集群上专用于 Pod 资源对象的网络，它是一个虚拟网络，用于为各个 Pod 对象设定Ip地址等网络参数，其地址配置于 Pod 中容器的网络接口之上。Pod 网络需要借助 kubenet 插件或 CNI （Container Network Interface：容器网络接口）实现，Flannel亦是基于CNI协议之上的网络插件，该插件可独立部署与 Kubernetes 集群之外，也可以以 Pod 的形式托管在 Kubernetes 之上，他需要在构建 Kubernetes 集群时由管理员进行定义，而后在穿件 Pod 对象时由其自动完成各网络参数的动态配置。

网络三：用于 Service 资源对象的网络，它属于一个虚拟网络，却不在任何网络接口上，用于为 Kubernetes 集群之中的 Service 配置 IP 地址，但此地址并不配置与任何主机或容器的接口之上，而是通过 Node 之上的 kube-proxy 配置为 iptables 或者 ipvs 规则，从而发往此地址的所有流量调度至其后端的各 Pod 对象之上。Service 网络/网段在 Kubernetes 集群创建时给予指定，而各 Service 的IP地址则在用户创建 Service时给予动态指定配置。

01-Kubernetes架构概述及组件介绍

集群上的网络通信

Kubernetes 集群的客户端大概可以分为两类：API Server 客户端和应用程序（运行为 Pod 中的容器）客户端，如下图所示。
第一类客户端即是图中的 开发/运维 所通过 APIServer 使用 kubectl 或 Web 图形 UI (例如 Kubernetes Dashboard)进行对Kubernetes集群的管理任务，例如，管理集群上的各种资源对象。
第二类客户端即为图中的 应用客户端，他们访问的目标是 Pod 上运行于容器中的应用程序所提供的服务，如 Redis、Nginx等，不过这些访问请求要由 Server 或 Ingress资源对象转发给 Pod进行。
01-Kubernetes架构概述及组件介绍

Kubernetes 的核心对象

API Server 提供了一个 RESTful 风格的编程接口，其管理的资源是 Kubernetes API 中的端点，用于存储某种API对象的集合，例如内置 Pod 资源 是包含了所有 Pod 对象的集合。资源对象是用于表现集群状态的实体，常用于描述应于哪个节点进行容器化应用、需要为其配置什么资源以及应用程序的管理策略等，例如，重启、升级、及容错机制。另外一个对象也是一种 ”意向记录“ ———— 一旦创建，Kubernetes 就需要一直确保对象始终存在。 Pod、Deployment 和 Service 等都是最常用的核心对象。

Pod 资源对象

Pod 资源对象集合了一个或者多个应用容器、存储资源、专用 IP 及支持容器运行的其他逻辑组件。
Kubernetes 网络模型要求其各 Pod 对象的 IP 地址位于同一 IP 网段内，各个 Pod 之间可使用其 IP 直接通信，无论他们运行于集群内的哪个工作节之上，这些 Pod 对象都像是运行于同一局域网中的多个主机。Pod 对象中的各进程均运行于彼此隔离的容器中，并于同一 Pod 中各容器间共享两种关键资源：网络和存储卷。

  • 网络(networking)：每个 Pod 对象都会被分配一个集群内专用的 IP 地址，也称为 Pod IP，同一 Pod 内部的所有容器共享 Pod 对象的 Network 和 UTS 名称空间，其中包含主机名、IP 地址和端口等。因此这些容器间的通信可以基于本地回环接口直接进行，而与 Pod 外的其他组件通信则需要使用 Service 资源对象的 Cluster IP 及相应的端口进行实现。
  • 存储卷(volume)：用户可以为 Pod 对象配置一组 ”存储卷“ 资源，这些资源可以共享给其内部所有容器使用，从而完成同容器间数据的共享。存储卷还可以确保在容器终止后被重启，甚至是删除后也确保数据不丢失，从而保证了生命周期内的 Pod 对象数据持久化存储。

一个 Pod 对象代表某个应用程序的一个特定实例，如果需要扩展应用程序，那么即为此程序同时创建多个 Pod 实例，每个实例均代表应用程序的一个 ”副本“。这些容器 “副本” 的创建和管理操作通常由另一组称为 “控制器(Controller)” 的对象实现，例如，Deployment 控制器对象。

创建Pod 时，还可以使用 Pod Preset 对象为 Pod 注入特定的信息，如 ConfigMap、Secret、存储卷、卷挂载和环境变量等。有了 Pod Preset 对象，Pod 模板的创建者久无需为每个模板显式提供所有信息，因此，也就无须事先了解需要配置的每个应用的细节即可完成模板定义。

Controller

Kubernetes 集群设计中，Pod 是由生命周期的对象，用户通过手工创建或由 Controller(控制器) 直接创建的 Pod 对象会被 “调度器（Scheduler）” 调度至集群中的某工作节点运行，待到容器应用进程运行结束之后正常终止，随后就会被删除。另外，节点资源耗尽也会导致 Pod 对象被回收。

Pod 对象本身不具备 “自愈” 功能，若是因为工作节点甚至是调度器自身导致运行失败，那么它将会被删除；同样，资源耗尽或节点故障导致的回收操作也会删除相关的 Pod 对象，在设计上，Kubernetes使用 “控制器” 实现对一次性的（用后即弃） Pod 对象的管理操作，例如：要确保 Pod 副本数量严格反映用户期望的数目，以及基于 Pod 模板来重建的 Pod 对象等，从而实现 Pod 对象的扩缩容，滚动更新和自愈能力。例如某 Pod 节点发生故障时，相关控制器会将此节点上运行的 Pod 对象重新调度到其它节点进行重建。

控制器本身也是一种资源类型，它有着多种实现，其中与工作负载相关的实现如 Replication、Controller、Deployment、StatefulSet、DaemonSet、DaemonSet、和 Jobs 等，也可统称他们为 Pod 控制器，如下图中Deployment 就是这类控制器的代表实现，是目前最常用的管理无状态应用的 Pod 控制器。

01-Kubernetes架构概述及组件介绍
Pod 控制器的定义是由期望的副本数量、Pod 模板和标签选择器(Label Selector)组成。Pod 控制器会根据标签选择器对 Pod 对象的标签进行匹配检查，所有满足条件的 Pod 对象都将受控于当前控制器并计入其副本总数，并确保此数目能够精确反映期望的副本数量。

在实际的应用场景中，在接收到请求流量负载明显低于或者接近已用 Pod 副本的整体承载能力时，用户需要手动修改 Pod 控制器中的期望副本数量以实现应用规模的扩容或缩容。如果集群中部署了 HeapSter 或 Prometheus 一类的资源指标监控附件时，用户可以使用 “HorizontalPodAutoscaler”(HPA) 计算出合适的 Pod 副本数量，并自动修改 Pod 控制器中期望的副本数以实现应用规模的动态伸缩，提高集群资源利用率。
Kubernetes 集群中的每个节点都运行着 cAdvisor 用来收集容器及 Pod 节点的 CPU、内存及磁盘资源的利用率指标数据，这些统计数据由 Heapster 聚合后可通过 API Server 访问。HorizontalPodAutoscaler 基于这些统计数据监控容器健康状态并作出扩展决定。

Service

虽然 Pod 对象可以拥有 IP 地址，但是 Pod 地址无法确保在 Pod 对象重启或重建后保持不变，对此解决办法为，Service 资源被用于在被访问的 Pod 对象中添加一个有固定 IP 地址的中间层，客户端向此地址发起访问请求后由相关的 Service 资源调度并代理至后端的 Pod 对象。Service 是通过定义出多个 Pod 对象组合而成的逻辑组合，并附带访问这组 Pod 对象的策略。Service 对象挑选关联 Pod 对象的方式同 Pod 控制器已用，都是基于 标签选择器 Label Selector 进行定义。

01-Kubernetes架构概述及组件介绍

Service IP 是一种虚拟IP，也称为 Cluster IP，它专用于集群内通信，通常使用专用的地址段，如 “10.96.0.0/12“网络，各 Service 对象的 IP 地址在此范围内由系统动态分配。
集群内的 Pod 对象可直接请求 Cluster IP，例如上图中来自 pod client 的访问请求即可以 Service 的 Cluster IP作为目标地址，但集群网络属于私有的网络地址，他们仅在集群内部可达，将集群外部的访问流量引入集群内部的常用方法是通过节点网络进行，实现方法是通过工作节点的 IP 地址和某端口（NodePort）接入请求并将其代理至相应的 Service 对象和 Cluster IP 上的服务端口，而后由 Service 对象将请求代理至后端的 Pod 对象的 Pod IP 及应用程序监听的端口，因此，上图中 External Clients 这种来自集群外部的客户端无法直接请求此 Service 听得服务，而是需要事先经由某一个工作节点（如 Node Y）的 IP 地址进行，这类请求需要两次才能到达目标 Pod 对象，因此在通信效率上必然存在负面影响。
NodePort 会部署于集群中的每一个节点，这就意味着，集群外部的客户端通过任何一个工作节点的 IP 地址来访问定义好的 NodePort 都可以到达相应的 Service对象。此种场景中，如果存在集群外部一个负载均衡器，即可将用用户请求负载均衡至集群中的部分或所有节点，这是一种称为 ”LoadBalancer“ 类型的 Service，它通常是由 Cloud Provider 自动创建并提供的软件负载均衡器。例如 Nginx、HAProxy或者硬件负载 F5等。

简单来说，Service 主要由三种常用类型；
第一种是仅用于集群内部通信的 Cluster IP类型。
第二种是接入集群外部请求的 NodePort 类型，它工作与每个节点的主机 IP 之上。
第三种是 LoadBalancer 类型，它可以把外部请求负责均衡至多个 Node 主机IP的NodePort之上。
Cloud Provider 自动创建并提供的软件负载均衡器。例如 Nginx、HAProxy或者硬件负载 F5等。

简单来说，Service 主要由三种常用类型；
第一种是仅用于集群内部通信的 Cluster IP类型。
第二种是接入集群外部请求的 NodePort 类型，它工作与每个节点的主机 IP 之上。
第三种是 LoadBalancer 类型，它可以把外部请求负责均衡至多个 Node 主机IP的NodePort之上。
三种类型中，每一种都以其前一种为基础才能实现，而且第三种类型中的 LoadBalancer 需要协同集群外部的组件才能实现，并且此外部组件不接受 Kubernetes 的管理。

相关推荐