Kubernetes架构设计与组件
Kubernetes简述
简介：
- 一套容器集群管理系统
- 一个开源平台
- 实现容器集群的自动化部署、自动扩缩容、维护等功能
两个核心角色：
- Master：Master管理Node
- Node：Node管理容器
Master
主要负责整个集群的管理控制。
通常Master会占用一台独立的服务器，基于高可用原因，也有可能是多台。
组成：
- kube-apiserver
- etcd
- kube-scheduler
- kube-controller-manager
kube-apiserver
为Kubernetes中各类资源对象提供了增删改查等HTTP REST接口。
于资源的任何操作，都需要经过API Server进程来处理。
访问API Server进程的3种方式：
- REST Request的方式
- 官方提供的客户端
- 命令行工具kubectl
etcd
Kubernetes的“数据库”。
一种轻量级的分布式键值存储。
可以在单台Master服务器上配置，也可以配置到多台服务器。
保存集群中所有的配置和各个对象的状态信息
只有API Server进程才能直接访问和操作etcd。
kube-scheduler
kube-scheduler是Pod资源的调度器。
监听最近创建但还未分配Node的Pod资源，会为Pod自动分配相应的Node。
一个实例的运作原理：
- 通过API Server进程的Watch接口监听新建的Pod。
- 搜索所有满足Pod需求的Node列表。
- 执行Pod调度逻辑。
- 会将Pod绑定到目标Node上。
Pod：Kubernetes的最小可操作单元，一个Pod包含一个或多个容器。
kube-controller-manager
大部分功能是由控制器执行的。
为了方便使用和学习，控制器由多个功能模块组合到一起，合成一个进程。
这些功能模块原本应该是各个独立的进程。
功能模块：
- Node控制器：Node出现故障时做出响应
- Replication控制器：对系统中的每个ReplicationController对象维护正确数量的Pod
- Endpoint控制器：生成和维护所有Endpoint对象的控制器
- ServiceAccount及Token控制器：为新的命名空间创建默认账户和API访问令牌
Endpoint：用于监听Service和对应的Pod副本的变化。
kube-controller-manager所执行的各项操作也是基于API Server进程。
Node
Kubernetes集群中的各个工作节点。
Node由Master管理，提供运行容器所需的各种环境，对容器进行实际的控制，而这些容器会提供实际的应用服务。
组成：
- kubelet
- kube-proxy
- 容器运行时
kubelet
每个Node上都运行的主要代理进程。
kubelet负责维护容器的生命周期。
也负责存储卷（volume）等资源的管理。
以PodSpec为单位来运行任务。
kubelet会定期向API Server进程报告自身状态，API Server进程将状态更新到etcd中。
PodSpec是一种描述Pod的YAML或JSON对象。
不是Kubernetes创建的容器将不属于kubelet的管理范围。
kube-proxy
主要用于管理Service的访问入口。
- 集群内的其他Pod到Service的访问。
- 从集群外访问Service。
容器运行时
负责运行容器的软件。
Kubernetes支持多种运行时，例如：
- Docker
- containerd
- cri-o（Podman 原来是 CRI-O 项目的一部分）
- rktlet
任何基于Kubernetes CRI（容器运行时接口）的实现都支持
Pod创建时各组件协作流程
- 使用kubectl创建Pod。
- kubectl命令将转换为对API Server的调用。
- API Server验证请求并将其保存到etcd中。
- etcd通知API Server新Pod产生。
- API Server调用调度器。
- 调度器决定在哪个节点运行Pod，并将其返回给API Server。
- API Server将对应节点保存到etcd中。
- etcd通知API Server。
- API Server在相应的节点中调用kubelet。
- kubelet与容器运行时API发生交互，与容器守护进程通信以创建容器。
- kubelet将Pod状态更新到API Server中。
- API Server把最新的状态保存到etcd中。
Kubernetes的核心对象
虽然底层为容器。
为了屏蔽底层的技术细节，
Kubernetes抽象出各种对象实例（概念），
用户操作对象实例，便可以操控容器。
Pod
Kubernetes处理的最基本单元。
容器本身并不会直接分配到主机上，而是会封装到名为Pod的对象中。
特性：
- 一个Pod代表单个应用程序。
- 一个Pod由一个或多个关系紧密的容器构成。
- 一个Pod中的容器拥有同样的生命周期。
- 一个Pod中的容器作为一个整体一起编排到Node上。
- 一个Pod中的容器共享环境、存储卷和IP空间。
注意：用户不应自行管理Pod，因为Pod并没有提供应用程序通常会用到的一些特性，如复杂的生命周期管理及动态伸缩。
控制器
Pod由控制器来管理。
在控制器中定义Pod的部署方式（如有多少个副本、需要在哪种Node上运行等）。
根据不同的业务场景，Kubernetes提供了多种控制器：
- ReplicationController和ReplicaSet控制器
- Deployment控制器
- StatefulSet控制器
- DaemonSet控制器
- Job控制器和CronJob控制器
ReplicationController和ReplicaSet控制器
ReplicationController和ReplicaSet控制器功能类似。
相同功能：
- 定义Pod模板
- 保证在集群中部署的Pod数量与配置中的Pod数量一致。
ReplicationController更多的功能：
- 执行滚动更新，将一组Pod逐个切换到最新版本。
ReplicaSet更多的功能：
- Pod识别功能。
- 副本筛选功能。
都没有的功能：
- 更细粒度的生命周期管理功能。
Deployment控制器
基于ReplicaSet控制器。
有部分功能和ReplicationController相似。
最常用的工作负载对象之一。
优势：
- 增加了更灵活的生命周期管理功能。
- 管理应用程序不同版本之间的切换。
- 自动维护事件历史记录及自动撤销功能。
Deployment控制器可能是使用频率最高的对象。
StatefulSet控制器
提供了排序和唯一性保证的特殊Pod控制器。
部署顺序、持久数据或固定网络等相关的特殊需求时使用。
可以通过Pod转移持久性数据卷。即使删除了Pod，这些卷也依然存在，以防止数据意外丢失。
虽然各个Pod的定义是一样的，但是因为其数据的不同，所以提供的服务是有差异的。
- 分布式存储系统。
- 服务端会话，不同会话的Pod提供的服务也不尽相同。
主要用于有状态的应用（例如，数据库）。
DaemonSet控制器
在集群的各个节点上运行单一的Pod副本。
非常适合部署那些为节点本身提供服务或执行维护的Pod。
- 日志收集和转发、监控
- 运行以增加节点本身功能为目的的服务
用于提供基本服务的，并且每个节点都需要。
可以绕过某些用于阻止控制器将Pod分配给某些主机的调度限制。
例如：原本Master服务器不可用于常规的Pod调度，但DaemonSet控制器可以越过基于Pod的限制，确保基础服务的运行。
Job控制器和CronJob控制器
Job控制器：
- 基于特定任务而运行。
- 运行任务的容器完成工作后，Job就会成功退出。
- 适合执行一次性的任务。
CronJob控制器：
- 在Job控制器的基础上增加了时间调度。
- 在给定的时间点运行一个任务。
- 也可以周期性地在给定时间点运行一个任务。
服务与存储
Service组件和Ingress
Service组件：
- 内部负载均衡器中的一种组件。
- 将相同功能的Pod在逻辑上组合到一起，让它们表现得如同一个单一的实体。
- 通过Service组件可以发布服务。
- 跟踪并路由到所有指定类型的后端容器。
当需要给另一个应用程序或外部用户提供某些Pod的访问权限时，就可以配置一个Service组件。
Ingress：
- 通过Ingress来整合Service组件。
- 充当多个Service组件的统一入口。
- 支持将路由规则合并到单个资源中。
通过同一域名或IP地址下不同的路径来访问不同的Service组件。
存储卷和持久存储卷
存储卷（volume）:
- 允许Pod中的所有容器共享数据。
- 在Pod终止之前一直保持可用。
- Pod中的容器故障不会影响对共享文件的访问。
- Pod终止后，共享的存储卷会被销毁。
持久存储卷（persistent volume）：
- 允许管理员为集群配置存储资源。
- 用户可以为正在运行的Pod请求和声明存储资源。
- 可预防节点级的故障。
- 分配比本地更多的可用存储空间。
持久存储卷的Pod一旦使用完毕，存储卷的回收策略将决定是保留存储卷（直到手动删除），还是立即删除数据。
资源划分
命名空间
对Kubernetes集群资源进行划分。
实现多租户的资源隔离。
逻辑划分
标签和注解
标签（label）：一种语义化标记。
附加到Kubernetes对象上，对它们进行标记或划分。
针对不同的实例进行管理或路由，可以用标签来进行选择。
每种基于控制器的对象都可以使用标签来识别需要操作的Pod。
Service组件也可以使用标签来确定应该将请求路由到哪些后端Pod。
每个单元可以拥有多个标签。
每个单元对于每个键只能拥有一个值。
键值对形式。标签的使用更像是对资源进行划分细类。
注解（annotation）也是一种类似的机制。
将任意键值信息附加到某一对象中。
可以包含少量结构化数据。
向对象添加更多元数据的一种方式，但并不用于筛选。