写在后面
自从在生产环境引入容器当前,目前直观感触最大的两个长处:
- 部署疾速,挪动、扩大便捷。
- 节俭了 15% 左右的硬件资源。
随着线上容器数量的增多,也遇到了治理工作量加大的状况,便呈现了前文的 DockerSwarm 的应用调研以及 portainer 工具的引入,在治理难度上确实加重很多。
然而容器治理的精华:主动实现服务的部署、更新、卸载和扩容、缩容 等,DockerSwarm 并没有提供。包含将来想进行服务基础设施和利用拆散,并且从现有的基于 springcloud 的 Java 语言微服务转向语言无关的云原生微服务的落地等等指标都指向了 Kubernetes。接下来的次要学习方向也放在这里,摸索云原生的生态链,一边学习一边总结。
对于 Kubernetes 的学习思路如下:
- 首先理解大略
- 实操部署集群
- 深入研究原理,浏览相干书籍
Kubernetes 是什么
Kubernetes 是谷歌开源的容器集群管理系统,是 Google 多年大规模容器治理技术 Borg 的开源版本,官网称其是:
Kubernetes is an open source system for managing containerized applications across multiple hosts. It provides basic mechanisms for deployment, maintenance, and scaling of applications.
用于主动部署、扩大和治理“容器化(containerized)应用程序”的开源零碎。
次要性能包含:
- 基于容器的利用部署、保护和滚动降级
- 负载平衡和服务发现
- 跨机器和跨地区的集群调度
- 主动伸缩
- 无状态服务和有状态服务
- 宽泛的 Volume 反对
- 插件机制保障扩展性
Kubernetes 架构
整体架构
下图清晰表明了 Kubernetes 的架构设计以及组件之间的通信协议。
图中一些协定名称后续再深究,临时先理解大略。
上面是更形象的一个视图:
Kubernetes 是属于 主从设施模型(Master-Slave 架构),在 Kubernetes 中,主节点个别被称为Master,而从节点则被称为Node。
Master 和 Node 是别离装置了 Kubernetes 的 Master 组件 和 Node 组件的实体服务器,每个 Node 都对应了一台实体服务器(尽管 Master 能够和其中一个 Node 装置在同一台服务器,然而倡议 Master 独自部署),所有 Master 和 Node 组成了 Kubernetes 集群,同一个集群可能存在多个 Master 和 Node,满足高可用诉求。
Master 节点架构
Master节点主要职责包含:
- 集群的“大脑”,负责管理所有节点(Node)。
- 负责调度 Pod 在哪些节点上运行。
- 负责管制集群运行过程中的所有状态。
Master组件次要包含:
-
API Server
又叫 kube-apiserver,kube-apiserver 是 Kubernetes 最重要的外围组件之一,次要提供以下的性能
- 提供集群治理的 REST API 接口,包含认证受权、数据校验以及集群状态变更等
- 提供其余模块之间的数据交互和通信的枢纽(其余模块通过 API Server 查问或批改数据,只有 API Server 才间接操作 etcd)
-
Scheduler
kube-scheduler 负责调配调度 Pod 到集群内的节点上,它监听 kube-apiserver,查问还未调配 Node 的 Pod,而后依据调度策略为这些 Pod 调配节点(更新 Pod 的
NodeName
字段)。 -
Controller Manager
Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成,是 Kubernetes 的大脑,它通过 apiserver 监控整个集群的状态,并确保集群处于预期的工作状态。
Controller Manager 有很多具体的 Controller,例如:Node Controller、Replication Controller、Endpoints Controller、Service Account and Token Controllers、Service Controller、Volume Controller 等等。
-
etcd
etcd 是 CoreOS 基于 Raft 开发的分布式 key-value 存储,可用于服务发现、共享配置以及一致性保障(如数据库选主、分布式锁等)
etcd 存储了 Kubernetes 的要害配置和用户配置,Kubernetes 中仅 API Server 才具备读写权限,其余组件必须通过 API Server 的接口能力读写数据(见 Kubernetes Works Like an Operating System)。
Node 节点架构
本图来自 HOW DO APPLICATIONS RUN ON KUBERNETES
Node节点主要职责包含:
- 负责管理所有容器(Container)。
- 负责监控 / 上报所有 Pod 的运行状态。
Node节点次要组件包含:
-
kubelet
每个 Node 节点上都运行一个 Kubelet 服务过程,默认监听 10250 端口,接管并执行 Master 发来的指令,治理 Pod 及 Pod 中的容器。每个 Kubelet 过程会在 API Server 上注册所在 Node 节点的信息,定期向 Master 节点汇报该节点的资源应用状况,并通过 cAdvisor 监控节点和容器的资源。
-
kube-proxy
每台机器上都运行一个 kube-proxy 服务,它监听 API server 中 service 和 endpoint 的变动状况,并通过 iptables 等来为服务配置负载平衡(仅反对 TCP 和 UDP)。
-
Container Runtime
即装置了容器化所需的软件环境确保容器化程序可能跑起来,比方 Docker Engine。
-
Logging Layer
Logging Layer 负责采集 Node 上所有服务的 CPU、内存、磁盘、网络等监控项信息。
-
Add-Ons:
Kubernetes 治理运维 Node 的插件组件,例如:
- CoreDNS 负责为整个集群提供 DNS 服务
- Ingress Controller 为服务提供外网入口
- Prometheus 提供资源监控
- Dashboard 提供 GUI
- Federation 提供跨可用区的集群
Kubernates 设计理念
这部分也就是先理解一下,Kubernetes 设计理念和性能其实就是一个相似 Linux 的分层架构,如下图所示:
- 核心层:Kubernetes 最外围的性能,对外提供 API 构建高层的利用,对内提供插件式利用执行环境
- 应用层:部署(无状态利用、有状态利用、批处理工作、集群利用等)和路由(服务发现、DNS 解析等)
- 管理层:零碎度量(如基础设施、容器和网络的度量),自动化(如主动扩大、动静 Provision 等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy 等)
- 接口层:kubectl 命令行工具、客户端 SDK 以及集群联邦
-
生态系统:在接口层之上的宏大容器集群治理调度的生态系统,能够划分为两个领域
- Kubernetes 内部:日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS 利用、ChatOps 等
- Kubernetes 外部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群本身的配置和治理等